Skip to content

Security management in local sessions

This section describes the security settings for TapNLink, TapNPass and Bluefer (Schneider) during local sessions.

It does NOT describe security management for remote exchanges: single-packets (tokens) or MQTT sessions with a server.

Risks

TapNLink must be protected from two main risks:

Takeover by unauthorized third party (hackers) UHF Radio protocols (WiFi, BLE, …) present the (dis)advantage of having a long range (more than several hundred meters). A hacker « hidden behind the wall » could connect his mobile as easily as someone located near to the system. TapNLink provides two types of defense against this hacker:
  • Proximity: selecting "NFC mandatory pairing" option ensures a close proximity of the user is mandatory. This is sufficient if the system is physically protected (located in a private, lockable room).
  • Authentication: connection is possible as anonymous, but this leaves a backdoor open if the anonymous profile has limited or no rights. Security is guaranteed by the login/password mechanism. To avoid a robot trying to login multiple times (to discover a login/password pair), TapNLink disconnects after 3 failed login tries, and refuses any further attempts for a minute.
Eavesdropping by a third party when an authorized person is connected (Spying) Radio signals can be heard by any receiver ('Man In The Middle') located in the range of the transmitter:
  • For NFC, this risk is minimum due to its very short range.
  • BLE and WiFi communication is very easy to read. The risk of spying on monitoring applications is not normally critical: the hacker may discover the temperature of the system, which is probably not secret. However, if the attacker captures the login and password the risk becomes much higher.
To remove this risk, communication is encrypted. The TapNLink uses a shared key to encrypt, which must also be protected and cannot just be sent directly from a user. In practice, a new key is generated each session. Two methods are provided to protect the shared key:
  • The key generation uses classic industry mechanisms to ensure that the « Man In The Middle » cannot discover the key, even if he records the whole exchange.
  • Double protection can be provided by encrypting the information exchanged for key generation (public keys, random number, etc) using an initial key built during the NFC exchange. This double protection reduces the risk of shared key discovery even more, and NFC presents the advantage of being "Out Of Band".

Security mechanisms

Security is often a compromise between comfort and risk, and may be inconvenient
  • Users/supervisors must manage and store their login/password information.
  • Encryption means calculations which increase connection and communication duration.
  • Making 'NFC pairing mandatory » reinforces security, but excludes all non-NFC mobiles.

TapNLink provides two types of security mechanism: access control, and physical/algorithmic security.

Access control: profiles and rights

Taps use Profiles to provide access control for users.

Some profiles are predefined and permanent:
  • Administrator has all possible rights, including the right to replace the whole configuration file.
  • Supervisor can modify:
    • Login/password information of all users (except administrators).
    • Security settings (for example NFC pairing mandatory).
  • Anonymous has the minimum rights and does not require any login/password. It is the default profile after connection and allows all users (even the administrator) to login just after connecting. The permissions assigned to anonymous are automatically applicable to all other profiles.
Profiles can be created:
  • Each profile (except anonymous) has a login/password that can be modified only by a supervisor or administrator.
  • Users can be specified as derivatives of a profile. They have the same rights as their profile, but have their own password that they can modify (but they cannot modify the password of their profile).
  • Users can have the right to:
    • Access bundles (sets of variables) either with read and/or write access. These accesses do not make sense for transparent serial modes, and are applicable only for "variables protocols" such as: Modbus, SWD or S3P.
    • Communicate thru a serial port (for non-variable protocols).
    • Run advanced features such as modifying security settings, transferring data-logging information, and others.
User / Profile relationship:
  • A user is derived from only one profile.
  • It is not possible to delete a user. However, it is possible to disable it (by setting a blank password, and to modify the login.
  • A user can be derived from Supervisor or anonymous (when disabled), but not from Admin.
  • Each user and profile has a unique *password*, except anonymous.
    • for convenience, the password can be stored on mobiles by apps, so that there is no need to enter them at every connection.
    • the passwords are used to build keys and must be managed with care, especially the password of the Admin profile (see IoTize Studio for further details).
    • they are stored on the Tap as hashed (encrypted) values, the Tap can only check their compliance (not their exact contents).

The following diagram shows the relationship between users and profiles.

image

Physical and algorithmic security

When connecting locally, proximity, authentication and encryption features guarantee communication confidentiality:
  • Proximity: hackers cannot connect using NFC when they are not close to the target system. Making NFC pairing mandatory removes many risks, but this mode excludes users who don't have NFC capability on their mobile (for example Iphones).
  • Authentication and access control: access rights linked to profiles guarantee that only authorized people can access sensitive data/commands.
  • Data encryption: communications are encrypted with a shared key.
    • This key is built during a negotiation stage. It can also be derived from an initial key generated during NFC connection (which reinforces the security level).
    • The encryption functions used by TapNLink conform to the industry standard AES128/256 algorithms.
    • The key is generated during authentication and is derived from the user password, the tap SerialNumber and some random data (called "salt"). Secure-proven hash functions and hardware random generators are used to derive the key.
    • Authentication and key generation is performed without exchanging the key or password by running a "Salted Challenge Response Authentication Mechanism" (see SCRAM-SHA-256-PLUS, RFC 7677 at [ietf.org](https://tools.ietf.org/html/rfc7677)).
The SCRAM mechanism presents several advantages:
  • SCRAM can be handled from end to end, whatever the media or intermediate relays.
  • If some secret keys are shared, they are not sent.
  • The keys are generated dynamically, mixing serial numbers (issued from both ends), secret shared information and public information.
  • The packets (commands) exchanged during a session are encrypted, signed (each end knows that the other end shares the same secret) and checked with a CRC mechanism.
  • The shared information (login/password) will never be sent (nor stored).
  • The packets (commands) cannot be replayed, since the keys depend on two hardware random generators.
  • Remote sessions with a mobile device as relay are also secured.

Security settings in IoTize Studio

Security is defined in IoTize Studio configuration software. More detailed information is available in IoTize Studio reference manual, including screen shots.

Profile definitions
  • The anonymous, admin and supervisor profiles are predefined in any new project, but you are free to modify the parameters.
  • You can also create your own profiles (main menu | Add | New Profile), rename them (popup menu) and change some information (password, etc.).

Permissions (ACL) Once profiles are defined, you can associate a profile with a bundle by "dragging and dropping" a profile into a bundle. This defines the type of access (read, write or 'read and write') the profile has to the resources in the bundle.

NFC Pairing The **NFC Pairing mandatory** option is accessible from the menu IoTized Application/Tap, and can have 3 values:
  • No: users can freely establish a remote connection with BLE (NFC pairing remains generally more convenient and available, but is no mandatory)
  • Pairing: BLE advertises ONLY after NFC connection, so the only way to connect is to tap with NFC. Note that as long as the NFC communication is active, the NFC channel could be maintained.
  • Pairing + Login: the login mechanism (authentication and key sharing) is applied during the NFC connection. BLE is launched only after this stage.
Encryption and authentication A boolean option (yes/no) specifies whether the authentication/encryption will be active for the BLE channel.
  • No: passwords are sent without encryption. This situation is not critical when 'NFC pairing mandatory' has been set to level 2 ('Pairing + login') because the password will be protected by the proximity, but sending a password over BLE without protection is not recommended.
  • Yes: SCRAM ("Salted Challenge Response Authentication Mechanism") manages the authentication by checking the validity of the pair 'login/password', and encryption of the communication.

Protected resources (variables or features) in Bundles

Protected variables When TapNLink connects to an MCU based target system, the variables can be:
  • Global variables of the target application, retrieved from the executable file (.ELF).
  • Registers of the target MCU, which can be retrieved from an XML file (.**SVD** file for a Cortex MCU).
  • Custom variables (symbols), defined manually in IoTize Studio.
When TapLink or TapNPass access a ModBus system:
  • you use ModBus registers in a similar way to variables.
  • future versions will handle these ModBus registers from an XML file (.svd compliant) which can be edited and loaded into IoTize Studio.
Protected features Permissions assigned to a bundle can also access special modes. At the moment, there are 3 'protected features':
  • Serial (for TapNPass): covers send and get functions (for simple serial communication between the mobile device and the target system).
  • Modbus direct (for TapNLink and TapNPass): allows to access any Modbus register (the address has to be passed as parameter).
  • SWD direct (for TapNLink): can access any address in the memory of a Cortex MCU based system. Permits to debug or program using the SWD port.

Connection procedure

The Tap answers commands sent by the mobile device so the connection sequence varies depending on the configuration, type of active channel (NFC / BLE) and the mobile's software.

Common goals during connection are normally:

  • Logging-in (being authenticated),
  • Having an encryption key to make the communication confidential.

We could summarize this goal by the following state machine: image

We always enter the state machine with the "anonymous" login and without active encryption. To reach the state "Logged in + encryption" we can either:

  • Use NFC to start by exchanging a hidden key that is used to authenticate.
  • Launch the authentication process (SCRAM) directly which authenticates and encrypts the connection.

The most secure method would be to do both: connect with NFC to exchange a first random key that is used by the SCRAM process. A solution "without encryption" is NOT recommended.

Simplified connection procedure for NFC and BLE

image

This chart shows a simplified example process followed at connection. It is simplified because most of the stages are driven by the mobile, and the sequence may differ depending on the mobile.

  • In yellow, NFC commands to the Tap,
  • In blue, BLE commands to the Tap,
  • In green, actions made by the mobile device.
Back to top