Gazell Pairing User Guide

Contents

• Close Proximity Pairing
• Pairing and key exchange stages
  • Factory preset parameters
  • System Address exchange
  • Host ID exchange
  • Dynamic Key exchange
• Encrypted User Data exchange
• Resource Requirements
• Terminology

Introduction

The Gazell pairing library for the nRF51 Series enables applications to use the Gazell Link Layer to provide a secure wireless link between Gazell nodes. The library is customized for pairing a device (for example, a mouse, keyboard, or remote control) with a host (typically a USB dongle) using Gazell.

The Gazell Pairing library has the following features:

• Close proximity pairing
• AES-128 encryption
• Secure key exchange
• Dynamic update of key during runtime
• Storage of pairing parameters in non-volatile memory
• One time programmable (OTP) device compatibility
• Backwards compatible with Gazell Pairing library for nRF24L devices.

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 so that all packets are authenticated.

The security features of Gazell provide counter measures against a range of potential attacks, including:

• Frequency analysis attacks
• Hostile Device attacks
• Known-plaintext attacks
• Man-in-the-middle attacks
• Passive eavesdropping
• Replay attacks

Close Proximity Pairing

Gazell only allows pairing when Host and Device are in close proximity to each other. The Received Signal Strength Indication (RSSI) is used on the Host side of the nRF51 so that only Devices residing close (<30 cm) 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.

Pairing and key exchange stages

The pairing and key exchange process consists of the following stages:

• System Address exchange
• Host ID exchange
• Dynamic Key exchange
• Encrypted User Data exchange

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 to send unencrypted data on pipes 2-8.

Factory preset parameters

For pairing and key exchange to occur, an unpaired Host and Device must share the following factory preset parameters in the following table:

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 unique parameters which are generated at runtime shown in the following table:

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.

Initial pairing parameters

System Address exchange

The system address is a individual host's private address. For a device to communicate with an individual Host, the Device needs to know the Host's system address. 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.

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.

System address exchange

Host ID exchange

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:

• Passive eavesdropping is prevented by using AES encryption.
• Replay attacks are prevented by using session tokens.
• Man-in-the-middle and malicious device attacks can be prevented by implementing a user validation stage before the Host ID is sent to the Device (discussed in the next section).

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.

Optional Host ID 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:

• The Secret Key will be used instead of the Dynamic Key.
• Session token update will not be sent from the Device to the Host.

As the same session token is used throughout 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

Dynamic Key exchange

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

• Passive eavesdropping is prevented by using AES encryption.
• 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.

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:

• Attacker eavesdrops the exchange of the Dynamic Key
• The Host ID has been compromised.

Encrypted User Data exchange

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:

• Passive eavesdropping prevented by AES encryption.
• "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 analysis attacks prevented by updating session token for every packet.

Encrypted user data exchange

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:

• Attacker eavesdrops the user data exchange.
• The current Dynamic Key has been compromised.

Resource Requirements

In addition to the resources required by the Gazell Link Layer (see Resources), Gazell Pairing also employs three nRF51 peripherals:

• Random Number Generator, for generation of keys and tokens.
• AES Electronic Codebook (ECB), for encryption/decryption.
• Non-Volatile Memory Controller (NVMC), for storing of pairing parameters.

In addition Gazell Pairing employs the following Gazell Link Layer resources:

• Two pipes: one for pairing and one for encrypted data transmission.
• Gazell pairing determines the channel set used by Gazell.

Since GZP requires exclusive access to pipes 0 and GZP_DATA_PIPE (default pipe 1), 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 pipes 2-7 can be used by the main application. Note that base_address_1 applies for these pipes. 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 following Gazell Link Layer API functions should not be accessed.

• nrf_gzll_set_base_address_0()
• nrf_gzll_set_base_address_1()
• nrf_gzll_set_address_prefix_byte() (for pipes 0 and 1)
• nrf_gzll_set_rx_pipes_enabled() (can be used but the enabled status of pipes 0 and 1 should not be modified)
• nrf_gzll_set_channel_table().

System Address and Channel Table Generation

The System Address determines the Gazell channel table on the Host and Device for subsequent transactions.

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.

Terminology

Name	Description
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 login 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.