2. BLE Security

2.1. Security features

The security architecture of Bluetooth has five distinct features: pairing, bonding, device authentication, encryption and message integrity.

  • Pairing is the process for creating one or more shared secret keys

  • Bonding is the act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair.

  • Device authentication is the verification that the two devices have the same keys

  • Encryption is the process that provides message confidentiality

  • Message integrity protects against message forgeries.

The Bluetooth specification has undergone several changes over the years, each one increasing the security strength of the protocol. Version 4.2 of the protocol has added the Secure Connections feature, which enables devices to use FIPS-approved algorithms on the BLE physical transport. LE pairing as defined in versions 4.0 and 4.1 of the specification are referred to as LE Legacy Pairing.

To have a more complete description of the Seurity overview please refer to Security Overview.

2.2. Pairing phases

In BLE, the process used to generate the keys and encrypt the link is called pairing, and it consists of three phases:

  • Phase 1: Pairing Feature exchange

  • Phase 2:

    • In LE Legacy Pairing: Short Term Key (STK) Generation.

    • In LE Secure Connections: Long Term Key (LTK) Generation.

  • Phase 3: Transport Specific Key Distribution

Pairing begins only after the devices have connected with each other. After that they exchange information about their I/O capabilities. Embedded devices are usually quite limited in their input and output capabilities, which poses another problem for designing the procedure for a secure connection.

In the next phase the user will assist, if possible, in the identification of the device, and based on whether we use LE Legacy Pairing or Secure connections, the appropriate scheme will be used to generate the link key. All subsequent communications will be encrypted with this key. When the link is encrypted, specific keys will be exchanged that aid in resolving the private address of the device, or signing and authenticating the data. In the next sections we will cover this process in detail.

2.3. Association models

Before the devices begin to communicate securely, we need to make certain that the other end is indeed the one we expect. BLE is a protocol intended for embedded devices and in many cases these devices can’t interact with a user or that means of interaction are very constrained. During the pairing phase each device informs the other end about its I/O capabilities and, based on this information, they agree on a association model for the identification, bearing in mind the I/O capabilities of the most constrained device.

There are four association models defined:

  • Out of Band (OOB): This scenario is tailored for instances where both devices incorporate a communication module, like NFC, operating in a distinct band. The exchanged information encompasses discovery details (e.g., Bluetooth Device Address) and cryptographic data. To enhance security, the Out of Band channel must possess distinct physical properties compared to the Bluetooth radio channel. In NFC, eavesdropping is highly challenging due to the weak signal confined to very short distances, ensuring a robust and reliable key exchange process.

  • Numeric Comparison: In this scenario, devices equipped with display units present a matching six-digit number to users. Users confirm the match by entering “yes” or “no.” This association model is exclusive to the LE Secure Connections architecture.

  • Passkey Entry: The Passkey Entry, also known as the “PIN Entry Method,” is designed for scenarios where one device has a keyboard but lacks a display, while the other device has a display unit, as seen in a scenario involving a PC and a BLE keyboard. Users are presented with a six-digit number (ranging from “000000” to “999999”) on the display-equipped device. They then enter this number on the other device to complete the pairing process successfully. This method, akin to numeric comparison, is versatile and applicable in both LE Secure Connections and LE Legacy Pairing.

  • Just Works: Designed for highly constrained devices in terms of I/O, the Just Works association model utilizes the Numeric Comparison protocol. Not requiring the user to view or input any numbers, it may prompt a simple connection acceptance. While vulnerable to MITM attacks, it provides the same protection against passive eavesdropping as the Numeric Comparison method. During the Pairing Feature Exchange process each device transmits its I/O capabilities as one of DisplayOnly, DisplayYesNo, KeyboardOnly, NoInputNoOutput, or KeyboardDisplay, as well as a field with Authentication Requirements Flags and a flag on whether or not they have received Out of Band data.

The association model that will be used is always deterministic and will be picked according to the next table and some simple rules. If both devices have not set the MITM option in the Authentication Requirements Flags, then the IO capabilities will be ignored and the Just Works association model will be used. If both devices have received the Out of Band authentication data (or at least one in the case of LE Secure Connections), then the OOB pairing will be used. In any other case, the I/O capabilities will be checked and the association model will be picked accordingly.

_images/mapping_io.svg

Figure 3 Mapping of I/O capabilities to key generation method

2.4. Security modes

Security requirements for devices, services, or service requests are specified by a combination of security mode and security level. Each service or service request, as well as the device itself, may have unique security requirements. It’s crucial to note that a physical connection between two devices operates exclusively in a single security mode.

There are two LE security modes, LE security mode 1 and LE security mode 2.

Apart from the first option, if a device uses LE security mode 1, the link will be encrypted. LE security mode 1 has the following security levels:

  1. No security (No authentication and no encryption)

  2. Unauthenticated pairing with encryption

  3. Authenticated pairing with encryption

  4. Authenticated LE Secure Connections pairing with encryption using a 128-bit strength encryption key.

LE Security mode 2 is only used for connection based data signing (more will be explained later), and it has two security levels:

  1. Unauthenticated pairing with data signing

  2. Authenticated pairing with data signing

When a device receives a service request, it will check the access rights of the service. If security is not required, the request will be serviced with LE security mode level 1 and this way no encryption or authentication will be needed. If the service can be accessed, but an elevated security level is required, the receiving device will check if it has performed pairing some time in the past with the same device, i.e. if a bond exists. A bond could have been performed in the past with inadequate security strength; for example some keys may not have been exchanged or their length may be short. In this case, the pairing procedure would be reinitiated with the correct security level. But if the security strength that had been established is adequate or even more, the existing information will be reused. The physical link will use the minimal security level required. If, for example, only data signing is needed and not encryption, security mode 2 will be used.

In the next page we’ll take a closer look on how this pairing procedure works.