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.

The Bluetooth SIG maintains several good pages covering BLE Security:

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.

Each connection starts its lifetime in Security Mode 1, Level 1 (see below).

To keep it simple, when two devices which initially do not have security, wish to do something which 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 (STK), and then distributing long-term keys (LTK) (for faster reconnection in the future, i.e. Bonding) used for encryption, as shown:

pairing-bonding.png


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.

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

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

Pairing and Bonding

Pairing involves authenticating the identity of the 2 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.

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.

Pairing Methods

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

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.

Passkey Display

One of the peers displays a randomly generated 6-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.

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 table below 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:

pairing-summary-table.png

Bonding Modes and Procedures

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

bonding-modes-procedures.png

Non-Bondable Mode

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

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.

Bondable Procedure

If a Central 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.

© 2016 Microchip Technology, Inc.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.