 |
nRF51 SDK
|
|
nRF51 SDK
|
User Guide for Gazell Pairing library. More...
The Gazell Pairing library for the nRF51 enables applications to use the Gazell Link Layer to provide a secure wireless link between Gazell nodes. The library is customized for pairing a Gazell Device (e.g. a mouse, keyboard or remote control) with a Gazell Host (typically a USB dongle).
The Gazell Pairing library has the following features:
Secure key exchange in Gazell Pairing is based on a Secret Key which is factory programmed. Only nodes that share the same Secret Key, i.e. for a desktop ecosystem, can form an encrypted link. After a pair of nodes have authenticated each other's Secret Key, the Gazell Host generates a random key termed the "Host ID". This is encrypted with the Secret Key and sent to the Gazell Device. This Host ID key is used to transmit a Dynamic Key which is used for encrypting subsequent data.
All encrypted exchanges of keys and data use a session token, which is equivalent to AES counter mode and provides protection against ciphertext attacks. In addition, all encrypted packets include an encrypted packet validation ID in order that all packets are authenticated.
The security features of Gazell provide counter measures against a range of potential attacks, including:
The following explains the function of the key exchange sequences that are required to exchange encrypted data.
A feature of Gazell Pairing is to only allow pairing when Host and Device are in close proximity of each other. The Received Signal Strength Indication (RSSI) is used on the Host side of the nRF51 so that only Devices residing close (<30cm) to the Host will be allowed to pair. (On nRF24L Host nodes the carrier detect functionality is employed.)
Proximity estimation is essential to avoid confusion when pairing in certain environments, for example in an office.
When requesting a System Address, the Device sets the TX power to a low level as set by GZP_POWER. 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.
The pairing and key exchange process consists of the following stages:
Each of 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 is required in order to send unencrypted data on pipes 2-8.
In order for pairing and key exchange to occur, an unpaired Host and Device must share the following factory preset parameters:
| Parameter | Secret? | Bytes | Purpose | Set |
| Secret Key | Yes | 16 | Encrypting Host ID when sent from Host to Device | Factory preset |
| Pairing Address | No | 5 | Sending of System Address from Host to Device | Factory preset |
| Packet Validation ID | No | 3 | Authentication of packets | Factory preset |
In addition, every Host has the following unique parameters which are generated at runtime:
| Parameter | Secret? | Bytes | Purpose | Set |
| System Address | No | 5 | Address used for all transmission. Seed for generating channel set. | Runtime. Generated when first system address request received. |
| Host ID | Yes | 5 | Encrypting Dynamic Key when sent from Device to Host | Runtime. Generated when first Host ID request is received. |
The System Address and Host ID are stored in non-volatile memory (NVM) and apply for the lifetime of the Host unless the NVM is erased.
For a Device to pair with a Host it must first obtain the System Address which all subsequent key exchange and data transfer occurs on. This transaction occurs on the pipe 0 and is transmitted in cleartext on the air as it is not a secret.
Once the Device has the System Address it can request the Host ID on the pipe GZP_DATA_PIPE. The Host ID is used to generate subsequent "dynamic keys" for encrypted data transfer.
After receiving a Host ID request, the Host generates the Host ID if it has not already done so. The Host ID is generated using the random Session Token received from the Device in the Host ID request as well as the session counter.
The Device sends a packet to fetch the Host ID and the secret Host ID is transmitted on the encrypted pipe GZP_DATA_PIPE using the shared Secret Key.
The following security precautions are taken for the Host ID exchange:
The Host ID can be compromised if the attacker has knowledge of the Secret Key. The attacker could in that case eavesdrop the Host ID exchange and obtain the Host ID or attempt to pair as a malicious device and obtain the Host ID. Before the Host ID is sent from the Host to the Device, it is possible for the application to add a 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:
As the same session token is used throughout the entire validation stage, the data exchange in the validation stage will have the following properties:
The Dynamic Key is used for encrypting user data. Each Device is required to have a unique Dynamic Key, and the Host is required to know the Dynamic Key for each Device is communicates with.
A Device can initialize the update of the Dynamic Key at any time. The Dynamic Key is generated randomly on the Device and then communicated to the Host. The Host ID is used for encrypting the Dynamic Key.
The Dynamic Key is considered a secret, and the following security precautions are taken:
The main reasons for using a dynamic key for encryption of user data are:
The secrecy of the Dynamic Key is dependent on the secrecy of the Host ID. The Dynamic Key can be compromised if both these conditions are met:
Once the Device and Host share a Dynamic key, encrypted data exchange can occur. When sending Encrypted User Data the following security precautions are being taken:
The secrecy of the Encrypted User Data is dependent on the secrecy of the Dynamic Key. Therefore the Encrypted User Data may be compromised if both these conditions are met:
As Gazell Pairing employs the Gazell Link Layer precompiled library, it requires exclusive access to the Radio peripheral as well as the Timer and software interrupt used by the Gazell Link Layer. These are specified precisely in the Gazell Link Layer documentation (see Resources in the Gazell Link Layer documentation).
Gazell Pairing also employs three nRF51 peripherals:
In addition Gazell Pairing employs the following Gazell Link Layer resources.
Since GZP requires exclusive access to pipes 0 and GZP_DATA_PIPE (default pipe 1), and it must control the internal Gazell Link Layer variables base_address_0, base_address_1 and prefix_address_byte for pipes GZP_PAIRING_PIPE (always pipe 0) and GZP_DATA_PIPE (configurable). The remaining six pipes can be used freely by the main application. Note that base_address_1 applies for pipes 2-7. Gazell Pairing must also determine whether the RX pipes 0 and 1 are enabled. So care should be taken to not affect the rx_enabled status of these pipes.
It follows that the the following Gazell Link Layer API functions should not be accessed.
Every Host generates its own unique System Address and channel table resulting in minimizing the interference between desktops.
The System Address also determines the Gazell channel table on the Host and Device for subsequent transactions. The System Address is generated on the Host side. On nRF51 and nRF24LE1 chips, the system address is randomly generated while on the nRF24LU1 chips this is generated from the chip ID in the info page. This gives a unique System Address. Both the Device and Host use the System Address to generate the same channel table.
When sending the System Address request, the Device knows only the lowest and highest RF channels in the Host's channel table (i.e. GZP_CHANNEL_LOW and GZP_CHANNEL_HIGH). This is sufficient for the System Address transaction as the Device and Host will eventually change channels so that they can communicate. In an environment with many desktops using Gazell Pairing, the Device and Host will find another channel to communicate on.
Frequency analysis attacks
Frequency analysis is the study of the frequency of letters, or groups of letters, in the ciphertext. Even the most advanced ciphers such as AES, do not provide security against this type of attack unless precautions for such an attack have being taken. Frequency analysis is based on the fact that certain letters and combinations of letters occur with varying frequencies. Knowing these properties of a given language, it can be possible to decipher the packets sent from the keyboard without having to break the cipher itself.
The encrypted user data in Gazell pairing is protected against frequency analysis attacks by using a session token, which is incremented for every packet. This is equivalent to AES "counter" mode. As the keys can take on any value they can not be compromised by a frequency analysis attack.
"Hostile" Device attack
Here, we have defined a "hostile" Device attack as the scenario where a hostile third party Device has been able to pair with the Host and start sending data that will be interpreted as trusted user data by the Host. The hostile device may also obtain any keys shared with other devices in order to eavesdrop communications.
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 during key exchanges 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.
One method to prevent this attack is for the communicating parties have a shared secret to authenticate the source of the transmission. In Gazell pairing this is provided by the factory programmed Secret Key.
Replay attacks
A replay attack is an attack where previously sent packets are recorded by a third party and resent to the receiver.
Here, the third party is not actually deciphering the keyboard packets, but repeats 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.
In Gazell pairing, the use of dynamic keys and session tokens prevent this kind of 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
