Security management in local sessions
This section describes the security settings for TapNLink radio modules during local sessions (it also applies to Bluefer and TapNPass equipment which embed a TapNLink).
It does NOT describe security management for remote exchanges: single-packets (tokens) or MQTT sessions with a server.
TapNLink must be protected from two main risks; Takeover and Eavesdropping:
- Takeover by an unauthorized third party.
- Spying by a third party when an authorized person is connected.
Takeover by hackers
UHF radio protocols (Wi-Fi, BLE, …) present the (dis)advantage of having a long range that could be 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 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. The defense is guaranteed by the login/password mechanism. To avoid a robot trying multiple times to login (to discover a login/password pair), TapNlink disconnects after 3 failed login tries, and refuses any further attempts for a minute.
Radio 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.
- For BLE or Wi-Fi, it is very easy to hear communications. The risk of spying on monitoring applications is not normally critical: the hacker may discover the temperature of the system, which is probably not very secret. However, if the attacker captures the login and password the risk becomes be much higher.
To remove this risk, communication is encrypted. The TapNLink uses a shared key to encrypt, so this shared key must also be protected and cannot just be sent directly from a user. In practive, a new key is generated at 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 even more the risk of shared key discovery and NFC presents the advantage of being "Out Of Band".
Security is often a compromise between comfort and risk, depending on the context. Security constraints could be inconvenient:
- Users/supervisors must manage and store their login/password information.
- Encryption means calculation which could 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: profile and permissions
Taps provide several access control features to assign permissions to users, using 'Profiles'which are specified in the configuration file.
Some profiles are predefined and exist whatever the contents of the configuration file:
- The administrator profile has all possible rights, including the right to replace the whole configuration file.
- The supervisor profile can modify access conditions for other users (but not administrators):
- The login/password information of all users (except administrator).
- General security settings.
- The anonymous profile 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. Note that the permissions assigned to anonymous are automatically applicable to all other profiles without restriction.
Profiles can be created to give users specific permission 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 modes).
- Run advanced features such as modifying security settings, transferring datalogging information, …
Each profile (except anonymous) has a login/password that can be modified only by the 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).
The following diagram shows the relationship between 'users' and 'profiles':
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.
Physical and algorithmic security
When connecting locally, several additional features guarantee the confidentiality of the communication:
- Proximity: hackers cannot connect using NFC when they are out of range of a few centimeters. Making « NFC pairing mandatory" removes many risks and NFC can be limited to only secure pairing. However, this mode excludes users who don't have NFC capability on their mobile.
- Authentication and access control: the access rights definition linked to profiles allows to 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 be also derived from an initial key generated during NFC connection. The encryption functions used by TapNLink are 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). The SCRAM mechanism presents several advantages:
SCRAM can be handled from end to end, whatever the media, and the intermediate relays,
- if some secrete keys are shared, they are not sent.
- the keys are generated dynamically, mixing serial numbers (issued from both ends), secrete shared information and public information.
- the packets exchanged during a session will be encrypted, signed (each knows that the other share the same secrete) and checked with a CRC mechanism.
- the whole shared information (login/password) will never be sent (nor stored).
- the packets could not be replayed, since the keys depend on two hardware random generators,
- remote session with a mobile device as relay are also secured.
Security settings in IoTize Studio
Security is mainly defined in the configuration file that you can easily edit within "IoTize Studio":
The anonymous, admin and supervisor profiles are predefined in any new project, but you are free to modify the parameters.
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 on the resources in the bundle.
A bundle contains a set of 'protected variables' or 'protected features'.
- When TapNLink is connected with a MCU based target system, the variables can be:
- Global variables of the target application, retreived from the executable file (.ELF).
- Registers of the target MCU, which can be retreived from an XML file (.SVD file for a Cortex MCU),
- Custom variables (symbols), defined manually in IoTize Studio.
- When your TapLink ou TapNpass access a ModBus system, the concept of variables symbols is also relevant:
- In this case, your handle ModBus register in a similar way as variables
- In a future version it will be possible to handle these ModBus registers from an XML file (.svd compliant) can be edited and loaded into IoTize Studio.
Permissions assigned to a bundle can also be addressed to execute or to set some special modes. At the moment, there are 3 'protected features':
- covers send and get functions (for simple serial communication between the mobile device and the target system).
- this option only applies to TapNPass
- 'Modbus direct'
- allows to access any Modbus register (the address has to be passed as parameter)
- this option applies to both TapNlink and TapNPass
- 'SWD direct'
- allows to access any address in the memory of a Cortex MCU based system
- this function generally permits to debug or program (using the SWD port).
- this option only applies to TapNLink
Note that the option 'TapNPass control' can be ignored.
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 both the authentication by checking the validity of the pair 'login/password' and encryption of the communication.
The passwords are used to build keys. This secret information must be managed with care. They are stored on the Tap as hashed (encrypted) values, the Tap can only check their compliance (not their exact contents).
The connection procedure executes a set of commands which depend on:
- the configuration file settings (see chapter above),
- the type of active channel (NFC / BLE),
- the mobile's software. The Tap answers to commands from the mobile, and these commands could be implemented in different ways (there is no unique sequence executed at connection).
The first goal at connection time is normally:
- logging-in i.e. being authenticated,
- Having an encryption key to make the communication confidential.
We could summarize this goal by the following state machine:
We always enter in the state machine as "anonymous login" without any active encryption. To reach the state 'Logged in + encryption", we can:
- With NFC, start by exchanging a hidden key that is used to authenticate.
- Or launch directly the authentication process (SCRAM) that allows to be both 'logged and encrypted'.
But the most secure would be to do both: connecting with NFC to exchange a first random key that will be used for the overall SCRAM process. The goal of this dual strategy is to add and security to security (and complexity to complexity).
Note that the red solution "without encryption" is NOT recommended.
The following chart shows a simplified process followed at connection (either via NFC or BLE):
- In yellow, NFC commands to the TAP,
- In blue, BLE commands to the TAP,
- In green, actions made by the mobile device.
The following chart is 'simplified', because most of the stages are driven by the mobile's commands, and the mobile can organize the sequence of these commands in different ways.