BLE v4.2: Creating Faster, More Secure, Power-Efficient Designs—Part 4

1. The pairing parameters used in phase one of BLE pairing consist of various fields.

In this phase, the master sends a Pairing Request (which may be in response to a slave initiated request) to the slave device with its own pairing parameters. In response, the slave device sends a Pairing Response to the master device, containing its own pairing parameters. Subsequently, both devices choose the pairing method based on the values from the parameters exchanged.

Pairing parameters include:

• Code is fixed to 0x01 for a pairing request and 0x02 for a pairing response.

• I/O capability describes the BLE device's input and output capabilities. The following options are available in I/O capability:

     - Display only

     - Display and Yes/No input

     - Keyboard only

     - No input and no output

     - Display and keyboard

• OOB Data Flag indicates if out-of-band (OOB) authentication data is present from the remote device.

• Authentication Requirement Flag has several fields. Bonding Flags specify if bonding is requested.  MITM indicates if man-in-the-middle protection is needed. SC shows if there’s a request for Secure Connection. Keypress indicates the requirement to send a keypress notification during passkey entry. SC and Keypress are highlighted, as these are available only in LE Secure connections pairing (Bluetooth 4.2).

• Maximum Encryption Key Size provides the maximum encryption key size that can be supported by the device.

• Initiator Key Distribution is used to request which keys are distributed from initiator to the responder.

• Responder Key Distribution is used to request the keys that are distributed from the responder to the initiator.

After exchange of the parameters, phase 2 kicks in. Phase 2 deals with device authentication and link encryption. This phase is important because it sets the right environment to send data securely between two devices. In LE Secure connection, a series of messages are communicated between the devices before completion of authentication and generation of the final security key for encryption.

What is LE Secure?

Before we talk about these steps, let’s take a look at the underlying mechanism that’s the backbone for protection against passive eavesdropping in Bluetooth 4.2. As mentioned earlier, LE Secure connection uses a Federal Information Processing Standard (FIPS) compliant Elliptic Curve Diffie-Hellman (ECDH) algorithm that allows devices to establish a shared key between two devices over an unsecured channel. The form of ECDH used here is P-256, which implies that the private key generated by the devices is 256 bits (or 32 bytes) in length.

2. Two devices can establish a shared secret when a third device is listening to the communication between them.

Prior to executing the ECDH algorithm, both devices must settle on a certain set of domain parameters. In the case of LE Secure connection, both devices know the parameters by default since they’re following the FIPS-compliant P-256 ECDH mechanism. After this, each device generates a pair of keys. The first is called a private key, which the device never shares or sends over the air. The second is called the public key. This is generated from the device key and a generator function that’s part of the domain parameter.

Afterward, each device sends its own public key to the other device. Using the public key received from the other device, its own public key, and its own private key, both devices are able to generate a shared key. Note that a passive eavesdropper can only sniff the public key exchanged between the devices. But without one of the private keys from any device, it can’t generate the shared key used for further encryption. In this way, ECDH is able to generate a shared key over an insecure channel and encrypt the link.

Figure 2 shows an example that demonstrates how two devices establish a shared secret when a third device is listening to the communication between them.

In phase 2, the ECDH key pair is generated and public keys are shared. To ensure that the device is communicating with the intended device, authentication is performed using one of the association models discussed in Part 3 of this series. Based on the association model/IO capabilities, the user input could be an input method, an output method, or OOB. Once that’s complete, the following steps take place (Fig. 3):

• A random number is generated in the device.

• With the user input value, the public key is generated as part of the ECDH and the random number.

• A confirmation value is calculated using an AES-CMAC function and then exchanged with the other device.

• The random number used for calculation is then exchanged with the other device.

3. These are the steps taken for the first stage of authentication.

The receiving device uses the user input value, the received public key, and the received random number to generate another confirmation value. If this generated confirmation value is same as the one received from other device, it completes the first stage of authentication. Based on the association model, the parameters used for calculating the confirm value changes slightly. In addition, the steps to compute the confirm value are repeated multiple times in case of passkey entry, as is done for each bit one by one.

After that, the devices generate the Long Term Key (LTK) from the shared key of the ECDH process and proceed toward the second stage of the authentication check, which involves checking the DHKey (Fig. 4). Once the DHKey check is successful on both sides, the devices enter phase 3.

4. The second stage of authentication involves checking the DHKey.

During pairing phase 3, the LTK is used to encrypt the link. Once the link is encrypted, keys are shared as indicated by Initiator Key Distribution/Responder Key Distribution flags in the Pairing Parameter (e.g., the Identity Resolving Key, or IRK, that’s needed when using the Resolvable Private Address).

Data Signing

The data signing feature available in BLE helps add another level of security to the system. BLE can employ a Connection Signature Resolving Key (CSRK) to authenticate data when encryption isn’t used. To do this, a signature is generated with the signing algorithm and a counter. That signature is placed next to the Data PDU. The counter is incremented with each Data PDU to avoid any replay attack. The data-signing feature doesn’t provide any protection against passive eavesdropping—it just ensures the authenticity of the receiving device from where the data originated.

In a nutshell, Bluetooth Low Energy offers strong security methods to prevent unauthorized read/write access to user data to enable secure wireless systems. Though features are available in both Bluetooth 4.1 and Bluetooth 4.2 to provide protection against MITM, a truly secure BLE system can be implemented only using Bluetooth 4.2. When LE Legacy pairing is used (Bluetooth 4.1), only OOB provides protection against passive eavesdropping.

Bluetooth 4.2 includes an additional association model called Numeric Comparison and implements an Elliptic Curve Diffie-Hellman algorithm. Parameters used to generate the Long Term Key (LTK) are never shared over the air to provide protection against passive eavesdropping. Because the private key is never shared over-the-air in Bluetooth LE 4.2, this makes it very difficult for an eavesdropper to decrypt the data being transferred between two BLE devices.

In next part of this series, we will talk about several updates needed to support Bluetooth Low Energy 4.2 features compared to the older versions. It will also discuss how to select a Bluetooth 4.2-compliant Bluetooth Low Energy device for your application.

Refer to application note AN99209 or the Bluetooth Core Specification (PDF download) for more details on Bluetooth 4.2 features.