Generic Access Profile (GAP) Security

Last modified by Microchip on 2023/11/09 08:53

Bluetooth® Low Energy Security Modes and Procedures

Along with the previously outlined Bluetooth® Low Energy (BLE) Generic Access Profile (GAP) discovery/connection modes and procedures, GAP also defines modes and procedures for security establishment and enforcement. These modes and procedures build upon rules and algorithms implemented in the Security Manager (SM) layer.

Overview

A BLE connection is said to operate at a specific Security mode. Within each mode are several security levels. The required security mode/level of a connection may change from time to time, leading to procedures to increase that level.

Note: Each connection starts its lifetime in Security mode 1, Level 1.

To keep it simple, when two devices that initially do not have security wish to do something that requires security, the devices must pair first. This process could be triggered, for example, by a central device that is attempting to access a data value (a "characteristic") on a peripheral device that requires authenticated access. Pairing involves authenticating the identity of two devices, encrypting the link using a Short-Term Key (STKs), and then distributing Long-Term Keys (LTKs) (for faster reconnection in the future, i.e., bonding) used for encryption, as shown:

Pairing and bonding illustration

The new security level of the connection is based on the method of pairing performed and this is selected based on the I/O capabilities of each device. The security level of any subsequent reconnections is based on the level achieved during the initial pairing.

The role each device plays is defined in the Security Manager (SM) portion of the BLE stack. They are:

  • Initiator: Always corresponds to the Link Layer Master and therefore the GAP central.
  • Responder: Always corresponds to the Link Layer Slave and therefore the GAP peripheral.

Back to top

Security Modes/Levels of a Connection

For a BLE connection, GAP defines two security modes, along with several security levels per mode.

Security Mode 1

This mode enforces security by means of encryption, and contains four levels:

  • Level 1: No Security (No authentication and no encryption)
  • Level 2: Unauthenticated pairing with encryption
  • Level 3: Authenticated pairing with encryption
  • Level 4: Authenticated LE Secure Connections pairing with encryption

Back to top

Security Mode 2

This mode enforces security by means of data signing, and contains two levels:

  • Level 1: Unauthenticated pairing with data signing
  • Level 2: Authenticated pairing with data signing

Each connection starts its lifetime in Security mode 1, Level 1, and can later be upgraded to any security level by means of an authentication procedure discussed below.

When pairing, the method/algorithm chosen determines if the pairing performed a strong authentication or not. Unauthenticated pairing occurs in situations where the device could not authenticate itself (for example, if it has no input/output capabilities).

Refer to Vol. 3, Part C, Section 10 of the BLE v4.2 Core Specification for a more detailed discussion of connection security modes/levels.

Back to top

Pairing and Bonding

Pairing involves authenticating the identity of the two devices to be paired, usually through a process of sharing a secret. Once authenticated, the link is encrypted and keys distributed to allow security to be restarted on a reconnection much more quickly. If these keys are saved for a future time, the devices are said to be bonded.

Back to top

Exchange of Pairing Information

The first phase of pairing involves a feature exchange that is used to determine how to pair the two devices, and what keys are distributed during the last phase. Each device first determines its peer's input and output capabilities, selected from one of the following possibilities:

  • No Input No Output
  • Display Only
  • Display Yes/No
  • Keyboard Only
  • Keyboard Display

These capabilities are communicated between the devices by using the Security Manager (SM) Pairing Request message.

Back to top

Pairing Methods

A pairing procedure involves an exchange of Security Manager Protocol packets to generate a temporary encryption key, the STK as depicted in the diagram above. During the packet exchange, the two peers negotiate one of the following STK generation methods.

Back to top

Just Works

The STK is generated on both sides, based on the packets exchanged in plain text. This method provides no security against Man-In-The-Middle (MITM) attacks.

Back to top

Passkey Display

One of the peers displays a randomly generated six-digit passkey and the other side as asked to enter it. In certain cases both sides enter the key, if no display is available. This method provides protection against MITM attacks.

Out of Band (OOB)

This method has the additional data transferred by means other than the BLE radio (such as another wireless technology like NFC). This method also provides protection against MITM attacks.

Back to top

Numeric Comparison (Also Called LE Secure Connections Pairing in BLE v4.2)

This method uses an algorithm called Elliptic curve Diffie–Hellman (ECDH) for key generation, and a new pairing procedure for the key exchange.

The accompanying table is a reference for determining the pairing method based on the two devices I/O capabilities and the role each device plays in the process.

Reference table for determining the pairing method

Back to top

Bonding Modes and Procedures

These are concerned with security establishment and enforcement. There are two modes, and one procedure.

Ther are two modes and one procedure shown

Back to top

Non-Bondable Mode

This is the default Bondable mode for devices. This means the device will not accept the bonding. No keys will be exchanged or stored by the device.

Back to top

Bondable Mode

To accept a bonding request, the peripheral must set the bonding bit in the authentication requirements of the Pairing Request message during pairing. The device exchanges security keys and stores them.

Back to top

Bondable Procedure

If a central device wants to bond with a peripheral device it believes is bondable, it uses the bondable procedure. It initiates pairing with the same bonding bit set in the authentication requirements of the Pairing Request message. If the peripheral device is bondable, it will respond with the bonding bit set.

If all this happens, the keys will be distributed after the link is encrypted, and then the keys are stored.

Once the keys have been distributed and stored, the pair of devices are said to be bonded.

Back to top