Skip to content

Security management in local sessions

This section describes the security settings for TapNLink during local sessions (it also applies to Bluefer and TapNPass products, which both embed a TapNLink).

It does NOT cover the following subjects, Integration with external IAM (identity and external management) components, Token management, Connection with MQTT brokers.


TapNLink must be protected from two main risks:

  • Takeover by 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 (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. 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 signals can be read 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, the risk of spying on the radio signals is (much) higher:
    • when the exchanged information are sensor values, it could be critical in some cases (in relation to data privacy)
    • when the exchanged data is login or password information, any spying could be extremely critical

To remove this risk, communication between the Tap and the mobile device 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 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 even more the risk of shared key discovery and NFC presents the advantage of being "Out Of Band".

Security mechanisms

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" mobile devices

Access control: profiles and rights

The TapNLink provides several access control features to assign rights to users, using Profiles .

Some profiles are predefined and permanent:

  • The administrator profile has all possible rights, including the right to replace the whole configuration file.
  • The supervisor profile can modify:
  • Login/password information of all users (except administrators).
  • Security settings (for example NFC pairing mandatory or not)
  • 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.

Profiles can be created to give users 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 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.
  • 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).

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 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

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 mainly defined in the configuration that you can edit from IoTize Studio configuration software. Note that more detailed information is available from IoTize Studio reference manual, including screen shots. The related section and concepts of IoTize Studio are as follows:

  • Profiles
  • Bundles
  • Resources (symbols and feaures)
  • Permissions / ACL (access control levels) which apply to combinations of bundle, profiles and ressources
  • Tap options (2nd branch of the the IoTized Application menu, in IOTZ explorer)
  • NFC Pairing mandatory (Yes/No)
    • No, users can freely establish a remote connection with BLE
    • 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 maintaine
    • Pairing + Login (level2), the login mechanism (authentication and key sharing) is applied during the NFC connection. BLE will be launched only after this stage
  • Security (Yes/No)
    • No: passwords are sent without encryption. This situation is not critical when NFC pairing mandatory is 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 manages both authentication (by checking the validity of the pair login/password) and encryption of the communication.

Connection procedure

The connection procedure executes a set of commands which depend on:

  • The configuration (see previous chapter),
  • The type of active channel (NFC / BLE),
  • The mobile software:
    • the Tap answers commands sent by the mobile device
    • these commands can be implemented in different ways (there is no unique sequence executed at connection).

The first goal at connection time is normally:

  • Logging-in (being authenticated),
  • Building 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 allows to authenticate and to encrypt the connection

The most secure method 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 reinforce the security. Note that the solution (in red in the previous picture) "without encryption" is NOT recommended.

Simplified connection procedure for NFC and BLE


This chart shows an example process followed at connection (either via NFC or BLE).

It is a simplified example because most of the stages are driven by the mobile, so the sequence of these commands may differ depending on the mobile being used.

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