This is a library for adding dynamic pairing functionality to an application using the Gazell Link Layer.
The library is customized for pairing a Gazell Host (typically a USB dongle) with one or more Gazell Devices (e.g. a mouse, keyboard or remote control). The pairing information is dynamically exchanged during runtime, enabling any Device to pair with any Host.
Pairing concept
Features
- Proximity pairing
- Advanced security
- AES encryption
- Counter measures against a range of potential attacks:
- Frequency analysis attacks
- "Hostile" Device attacks
- Known-plaintext attacks
- Man-in-the-middle attacks
- Passive eavesdropping
- Replay attacks
- Dynamically change of encryption key during runtime
- Storage of pairing parameters in non volatile memory
- One time programmable (OTP) device compatibility
Contents
- Gazell Link Layer restrictions
- Proximity pairing
- Data exchange stages
- System address exchange
- Host ID exchange
- Dynamic Key exchange
- Encrypted user data exchange
- Terminology
- Application Programming Interface (API) for the Gazell pairing library
Functional description
Gazell Link Layer restrictions
The pairing library implies a few restrictions on how the Gazell link layer can be used by the main application:
- Two of the nRF Multiceiver pipes (pipe 0 and 1) are reserved by the pairing library for exchanging pairing parameters and encrypted user data. These two pipes should not be accessed directly by the main application. The remaining four pipes (2-5) can be used freely by the main application.
- As the setup of the RF channels and addresses is handled by the Gazell pairing library the application is not allowed to use the following Gazell Link Layer API functions directly:
- gzll_set_channels()
- gzll_set_param(), modyfing the parameters GZLL_PARAM_RX_PIPES
- gzll_set_address()
Proximity pairing
The carrier detect functionality of nRF24L01+/nRF24LE1/nRF24LU1+ is employed for implementing close-proximity pairing. By measuring the receive signal strength when a pairing request is received from a Device, the Host is able to estimate the relative proximity of the requesting Device.
Proximity estimation is essential to avoid confusion when pairing in certain environments, for example in an office.
It is only Devices residing close (10-30cm) to the Host that will be allowed to pair. Deliberately limiting the range during pairing will prevent the "pairing to the Host next door" situation.
Data exchange stages
The operations performed by the pairing library can be divided into the following main stages:
All these stages are required in order to send encrypted user data from a Device to a Host. If encryption is not required, only the "system address exchange" stage needs to be committed before uncrypted user data can be sent on pipe 2-5.
Factory presets
An unpaired Host and Device share the following factory preset parameters:
- Secret key
- Pairing address
- Packet validation id
In addition, every Host has the following unique parameters:
- System address
- Host ID
The System Address will be used as address when a paired Device is communicating with the Host. In addition, the System Address serves as a seed for generating the subset of RF channels to be used.
The following are considered a secret:
- Secret key
- Host ID
The Secret Key will be common for all Devices and Hosts.
The "Dongle ID" will be unique for every individual Host.
Factory presets
System address exchange
During system address exchange the Host provides its unique system address to a Device.
The system address is not considered a secret and can be distributed without any particular security precautions.
System address exchange
Host ID exchange
The Host ID is considered a secret, and the following security precautions are being taken:
- Passive eavesdropping prevented by using AES encryption
- Replay attacks prevented by using session tokens sent from keyboard
- Man-in-the-middle attacks / "hostile" Device attacks may be prevented by requiring that the user validates the exchange before the Host ID is sent to Device (optional).
Host ID exchange
About the validation stage
Before the Host ID is sent from the Host to the Device, it is possible for the application to add an additional validation stage. This validation stage would typically contain some kind of user intervention, for example that the user is requested to write a keycode on the Device, displayed on a screen on the Host.
This requires the Device to be able to send user data before all parameters normally used for encrypting user data have been exchanged. Nevertheless, it is still possible to send encrypted data during the validation stage. This data will be encrypted in the same fashion as normal user data, described in Encrypted user data exchange, except for the following differences:
- Secret Key will be used instead of Dynamic Key
- Session token update will not be sent from the Device to the Host
As the same session token is used through the entire validation stage, the data exchange in the validation stage will have the following properties:
- Only the same Device as the one initializing the Host ID exchange will be able to send data that will be accepted by the Host
- Only the Device used for sending user data during the validation stage will be able to decrypt the Host ID sent from the Host
Security considerations for Host ID exchange
Main security weakness:
- Security dependent on secrecy of Secret Key
The Host ID may be compromised if all of the following criteria are fulfilled:
- Secret Key is compromised
- Attacker eavesdrops the Host ID exchange
Dynamic Key exchange
The Dynamic Key will be used for encrypting user data. Update of the Dynamic Key can at any time be initialized by a Device.
The Dynamic Key is considered a secret, and the following security precautions are being taken:
- Passive eavesdropping prevented by using AES encryption of the key exchange sequence
- Replay attacks prevented by using session tokens sent from Host
- Only Devices knowing the Host ID will be able to update the Dynamic Key in the Host
Dynamic Key exchange
The main reasons for using a dynamic key for encryption of user data are:
- A Host must be able to be paired with multiple Devices at the same time, and none of these should be using the same key for encryption of user data.
- The solution must be able to implement on OTP devices, where storing of keys in non volatile memory during runtime is not desired.
Security considerations for Dynamic Key exchange
Main security weakness:
- Security dependent on secrecy of Host ID
The Dynamic Key may be compromised if all of the following criteria are fulfilled:
- Attacker eavesdrops the exchange of the Dynamic Key.
- The Host ID has been compromised. See Security considerations for Host ID exchange.
Encrypted user data exchange
When sending encrypted user data the following security precautions are being taken:
- Passive eavesdropping prevented by AES encryption using Dynamic Key
- "Hostile" Device attacks prevented as only Devices knowing the current Dynamic Key will be able to send user data that will be accepted by the Host
- Known plaintext/ciphertext attacks prevented by AES encryption
- Replay attacks prevented by using session tokens sent from Host
- Frequency analyses attacks prevented by updating session token for every packet
Encrypted user data exchange
Security considerations for encrypted user data exchange
Main security weakness:
- Security dependent on secrecy of Dynamic Key
The data exchange may be compromised if all of the following criteria are fulfilled:
- Attacker eavesdrop the user data exchange.
- The current Dynamic Key has been compromised. See Security considerations for Dynamic Key exchange.
Terminology
Frequency analysis attacks
Frequency analysis is the study of the frequency of letters, or groups of letters, in the chiphertext. Even the most advanced and "unbreakable" ciphers, as for example AES, does not necessarily provide security against this type of attack, unless precautions for such an attack is being taken. Frequency analysis is based on the fact that certain letters and combinations of letters occur with varying frequencies. Moreover, there is a characteristic distribution of letters that is roughly the same for almost all samples of a given language. For instance, for the English language, "e" tends to be very common, while "X" is very rare. Knowing these properties of a given language, it can be possible to decipher the packets sent from the keyboard, based on analysis of previous sent chiphertext packets, without having to break the cipher itself
"Hostile" Device attack
Here, we have defined a "hostile" Device attack as the scenario where a hostile third part Device has been able to pair with the Host and start sending data that will be interpreted as trusted user data by the Host.
For example, having such an capability with a wireless keyboard, an attacker can easily perform a range of operations on the host PC, like damaging contents on the PC or install spy-ware or key-logging software.
Man-in-the-middle attack
The man-in-the-middle attack is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them, making them believe that they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker.
Replay attacks
A replay attack is an attack where previously sent packets, or groups of packets, are recorded by a third part, and re-sent to the receiver.
Here, the third part is not actually deciphering the keyboard packets, but can still able to repeat commands previously sent to the receiver.
For example, a typical "log in" sequence on a PC consisting of entering a username and a password is in particular vulnerable for a replay attack.
Session token
Here, a session token is a random, or pseudo random, number used for adding randomness to encryption of data packets. The session token is not assumed as a secret.
The session token is generated prior to every new session and discarded after the session has ended.
Here, a session consists of one message being sent from a transmitter to a recipient and one message being sent in return from the recipient to the transmitter
