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.

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

  • Phase 2 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 is designed for scenarios where both devices have a communication module operating in another band, like NFC. The information exchanged includes discovery information (such as the Bluetooth Device Address), as well as cryptographic information. In order to be effective from a security point of view, the Out of Band channel should provide different physical properties in terms of security compared to the Bluetooth radio channel. In the NFC case, eavesdropping on the communication link is extremely difficult because of the weak signal that can be only received in very short distances, and in effect the key exchange process would be made very reliable.

  • Numeric Comparison: In this scenario both devices have a display unit capable of displaying a six-digit number and are also capable of having the user enter “yes” or “no”. Both displays output the same number and the user is asked to confirm that these numbers match. This association model is only applicable in the LE Secure Connections architecture.

  • Passkey Entry: Sometimes also called “PIN Entry Method”, the Passkey Entry is primarily intented for the case that one device has a keyboard but no display unit, and the other device has at least a display unit, for example a PC and a BLE keyboard scenario. The user is shown a six digit number (from “000000” to “999999”) on the device with a display, and then is asked to enter the number on the other device. If the value entered on the second device is correct, the pairing is successful. Although similar to the numeric comparison method, the Passkey Entry can also be used in LE Legacy Pairing.

  • Just Works: This model is primarily intended for the most constrained devices in terms of I/O. The Just Works association model uses the Numeric Comparison protocol but the user is never shown a number and the application may simply ask the user to accept the connection. This method doesn’t offer protection against a MITM attack, but it offers the same protection level against passive eavesdropping as the Numeric Comparison.

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

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

2.4. Security modes

The security requirements of a device, a service or a service request are expressed in terms of a security mode and security level. Each service or service request may have its own security requirement, and in addition the device may also have a security requirement. A physical connection between two devices operates in only one 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.