Improving Security with Bluetooth Low Energy 4.2

With version 4.2, Bluetooth Low Energy (BLE) offers new features to enhance privacy and security to address vulnerabilities of earlier versions of BLE as well as to improve energy efficiency.

Protecting a user’s private information is important for every wireless device, from fitness monitors to payment systems. Privacy mechanisms prevent devices from being tracked by untrusted devices. Secure communications keep data safe while also preventing unauthorized devices from injecting data to trigger unintended operation of the system.

To maintain the privacy of the BLE devices, trusted BLE devices use a shared secret called the Identity Resolving Key (IRK) to generate and resolve a random address known as the Resolvable Private Address (RPA). Only if a device has the advertising device’s IRK can it track the movement of the advertising BLE device.

The IRK is shared between devices at the time of pairing and is stored in the internal memory of the devices during bonding in a list called the Resolving List. Thus, devices that have bonded earlier can resolve a peer device’s private address.

In Bluetooth 4.1, the Resolving List is maintained in the Host. Address resolution is also done by the Host. This requires Host intervention every time an advertisement packet with an RPA is received. In Bluetooth 4.2, the Resolving List is maintained in the Controller. Since the Controller resolves the private address, the Host does not need to wake up in devices where the Host is implemented using a separate CPU. This lowers overall power consumption. Even in the devices where both the Controller and the Host are implemented using the same CPU, power consumption shrinks as the address does not need to go through the various protocol layers, thus reducing the number of CPU cycles needed to resolve the address.

The RPA can also be changed over time, making it more difficult to track a private device. In the case of Privacy 1.1 (Bluetooth 4.1), the recommended RPA timeout is 15 minutes. However, such privacy had limited usability because of the impact on connection time and power consumption. In addition, features like device filtering and Directed Connectable Advertisement (DCA) cannot be used in Privacy 1.1 while using RPA, as the address cannot be resolved at the Link Layer.

Privacy 1.2 in Bluetooth 4.2 allows for an RPA timeout period from 1 second up to 11.5 hours. As BLE 4.2 supports address resolution at the Link Layer, DCA can be used to speed connection between devices and consume less energy doing so.

Passive Eavesdropping
To protect communications from unauthorized access, wireless systems must prevent passive eavesdropping and man-in-the-middle (MITM) attacks. In passive eavesdropping, a third device quietly listens to the private communication between two devices (see Figure 1). Protection against passive eavesdropping is important in applications like payment solutions where confidentiality of information like passwords is of utmost importance.

Figure 1: In a passive eavesdropping attack, a third device listens in on the communications between two devices.

Figure 1: In a passive eavesdropping attack, a third device listens in on the communications between two devices.

Systems can protect against passive eavesdropping by using a key to encrypt data. LE Secure Connections, introduced in Bluetooth Low Energy 4.2, uses the Federal Information Processing Standard (FIPS) compliant Elliptic Curve Diffie-Hellman (ECDH) algorithm for key generation (Diffie-Hellman Key—DHKey). This key is used to generate other keys like Long Term Keys (LTK) and DHKey but is itself never shared over the air. As the DHKey is never exchanged over the air, it becomes very difficult for a third device to guess the encryption key. Earlier versions of Bluetooth Low Energy (Bluetooth 4.1 or older) devices used easy-to-guess Temporary Keys (TK) to encrypt the link for the first time. Long Term Keys (LTK), along with other keys, were then exchanged between devices over this encrypted but potentially compromised link.

MITM is a scenario where, as two devices try to communicate with each other, a third device inserts itself between them and emulates both devices to the other (see Figure 2). Authentication protects against MITM by ensuring that the device a system is communicating with is actually the intended device and not an unauthorized device emulating as the intended one.


Figure 2: During a Man-in-the-Middle attack, a third device inserts itself into a connection and emulates both devices as if they are directly connected.

In Bluetooth, an association model is a mechanism that two devices use to authenticate each other and then securely exchange data. In Bluetooth, pairing is the process of key exchange. However, before keys are exchanged, both devices must share pairing parameters that include authentication requirements. If authentication is required, both devices must authenticate each other using one of the association models.

Which model to use is based on three parameters:

  1. Is MITM protection required?
  2. Can the device receive data from a user (such as a button or keyboard) or output data to the user (such as an LCD display capable of displaying a 6-digit decimal number)? Involving the user in the pairing process is an important element in the secure transfer of data
  3. Can the device communicate Out-of-Band (OOB)? For example, if part of the security key can be transferred between the two devices over Near-Field Communication (NFC), an eavesdropper will not be able to make sense of the final data.

Four association models are available in BLE 4.2:

  1. Numeric Comparison—Both devices display a six-digit number and the user authenticates by selecting ‘Yes’ if both devices are displaying the same number. This association model is introduced in LE Secure Connections in Bluetooth 4.2. With legacy pairing (Bluetooth Low Energy 4.1 or older), these IO capabilities would have led to a Just Works association model (unauthenticated).
  2. Passkey Entry—The user either inputs an identical Passkey into both devices, or one device displays the Passkey and the user enters that Passkey into the other device. Exchange of the Passkey one bit at a time in Bluetooth 4.2 is an important enhancement over the legacy Passkey entry model (Bluetooth 4.1 or older) where the whole Passkey is exchanged in a single confirm operation. Such bit-by-bit disclosure enforces not more than two bits of unguessed Passkey to leak before the protocol fails the pairing procedure.
  3. Out of Band (OOB)—The OOB association model is the model to use if at least one device with OOB capability already has cryptographic information exchanged out of band. Here, protection against MITM depends on the MITM resistance of the OOB protocol used for sharing the information. In BLE 4.1 or older (legacy pairing), both devices needed to have OOB capabilities for the OOB association model to be used.
  4. Just Works—This association model is used either when MITM protection is not needed or when devices have IO capabilities as mentioned in Table 1.

Table 1 shows the association model that can be used based on the IO capabilities when LE Secure Connections is used for pairing. However, when either MITM protection is not required or OOB data is available with any of the BLE devices, IO capabilities can be ignored.


Table 1: The appropriate association model to use depends upon the I/O capabilities of the two devices.

Bluetooth Low Energy 4.2 has three association models that protect against MITM and one for applications that don’t need MITM protection. The Numeric Association model is not available in BLE version 4.1 and older. This leaves only the Passkey entry association model for authenticated pairing if OOB data is not available. The Passkey association model requires a keypad to be available to enter the passkey, and that may not be possible in many systems, limiting the use of this MITM protection capability. However, the Numeric comparison can be used when just a yes/no option is available with display capabilities, thus extending MITM protection capability to more applications.


Pairing is the process of key exchange and authentication. There are two types of pairing that are dependent on Bluetooth Low Energy version: LE Secure Connections (introduced in Bluetooth 4.2) and LE Legacy Pairing (supported in Bluetooth 4.0 onwards). LE Secure Connections significantly improves security over previous versions.

Pairing in Bluetooth Low Energy is divided into three phases. During the first phase, devices exchange their pairing parameters. Pairing parameters are the capabilities and security requirements that are used to determine the association model to be used. The pairing parameters consist of various fields, as shown in Figure 3.


Figure 3: Pairing parameters exchanged during phase 1 of pairing in BLE 4.2.

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 is P-256, which implies that the private key generated by the devices is 256 bits (or 32 bytes) in length.

Prior to executing the ECDH algorithm, both devices must settle upon a certain set of domain parameters. In the case of LE Secure connection, both devices know the parameters by default as they are 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 is a part of the domain parameter.

After this, 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. Without one of the private keys, it cannot generate the shared key that is used for further encryption. In this way, ECDH can generate a shared key over an insecure channel and encrypt the link.

Figure 4 shows how two devices can establish a shared secret when a third device is listening to the communication between them.


Figure 4: Establishment of a shared secret when a third device is listening.

In phase 2, the ECDH key pair is generated and public keys are shared to authenticate devices and establish link encryption. To ensure that the device with which a device is communicating is the intended device, authentication is performed using one of the association models. The devices generate a Long Term Key (LTK) from the shared key of the ECDH process and proceed towards the second stage of the authentication check, which involves checking the DHKey.

In 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 parameters (e.g., the IRK that is needed if the RPA is used).

Data Signing
Data signing is another feature available in BLE that helps add another level of security. BLE can use a Connection Signature Resolving Key (CSRK) to authenticate data when encryption is not used. To do this, a signature is generated using the signing algorithm and a counter. The counter is incremented with each Data PDU to avoid any replay attack. Note that Data Signing does not protect against passive eavesdropping. Rather, it verifies to the receiving device the authenticity of the device from where the data originated.

Bluetooth Low Energy 4.2 offers strong security mechanisms to enable secure wireless systems. Although BLE 4.1 and 4.2 offered features to guard 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 the OOB association model protects against passive eavesdropping. Bluetooth 4.2 also includes an additional association model called Numeric Comparison and uses an Elliptic Curve Diffie-Hellman algorithm to ensure privacy and data security.

For more details on Bluetooth 4.2 privacy and security features, see application note AN99209 or the Bluetooth Core Specification for more details on Bluetooth 4.2 features.

sachin-author-smSachin Gupta is a Staff Engineer, Product Marketing with Cypress Semiconductor. He loves working on different types of analog and digital circuits, as well as synthesizable codes. He holds a diploma in Electronics and Communications from Vaish Technical Institute and a Bachelors in Electronics and Communications from Guru Gobind Signh Indarprastha University, Delhi. He has eight years experience in SoC applications. He can be reached at

richa-author-smRicha Dham is Sr Marketing and Applications Manager with Cypress Semiconductor. Her interests lie in defining new solutions especially in the connectivity and IoT area. She completed her Masters in Technology in Communications Engineering from Indian Institute of Technology, Delhi (IITD).

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google