Understanding Security Keys in Bluetooth Low Energy

Before diving into the specifics of how Bluetooth Low Energy (LE) technology uses security keys (Figure 1), let's take a step back and lay the groundwork by understanding what a security key is, especially for those just venturing into the intriguing world of cryptography.

Cryptography, in the simplest terms, is the practice and study of techniques used to secure communication in the presence of adversaries. The goal is to ensure that the intended information is accessible only to those who are meant to have access to it. One of the fundamental tools used in cryptography to achieve this goal is a "security key."

 

Figure 1. Bluetooth LE uses security keys for cryptographic protection. Image from Adobe Stock (licensed)

 

A security key is essentially a piece of information—a string of numbers, characters, or both—that determines the output of a cryptographic algorithm or cipher. Think of it as the secret ingredient in a recipe that can drastically change the outcome if altered. 

Security keys are used in various cryptographic functions such as encryption, decryption, signing, and validation. They help transform plaintext data into a seemingly random collection of characters (encrypted data) and back again.

• Encryption is the process of scrambling data so that it can't be understood if intercepted. The security key defines the exact way the data is mixed up.
• Decryption is the reverse process, unscrambling the encrypted data back into its original form. This process also uses a security key, which can either be the same as the encryption key (in symmetric encryption) or a different, related key (in asymmetric encryption).
• Signing is the process of creating a unique 'signature' for a piece of data using a security key. This signature can prove the data's integrity and authenticity, showing it hasn't been tampered with since it was signed.

In this article, we’ll zero in on how Bluetooth LE technology uses security keys. With an emphasis on three types of keys—the Long Term Key (LTK), Connection Signature Resolving Key (CSRK), and Identity Resolving Key (IRK). 

 

The Pillars of Bluetooth LE Security

The security mechanics of Bluetooth Low Energy (LE) are founded on three primary pillars: encryption, data signing, and device privacy. These processes leverage distinct security keys to ensure the protection of data and the privacy of devices.

 

Encryption in Bluetooth LE

Encryption is at the heart of any secure communication, and Bluetooth LE is no exception. It employs a symmetric-key block cipher system, the Advanced Encryption Standard (AES), with a key length of 128 bits. When used correctly, it is universally recognized for its strength against all known practical attacks.

In Bluetooth LE, the encryption process involves the Long Term Key (LTK), which is a secret key shared and stored by both connected devices. This key is generated during the pairing process and used in the AES-CCM cryptography algorithm to encrypt and decrypt data. 

Specifically, during the encryption process, the plaintext data is combined with the LTK using the AES-CCM algorithm to produce ciphertext— the scrambled, unreadable data. Only devices that possess the corresponding LTK can decrypt and access the original information.

 

Data Signing in Bluetooth LE

Bluetooth LE also ensures data integrity and authenticity through data signing. This security measure guarantees that the data has not been tampered with in transit and has originated from a legitimate source.

The Connection Signature Resolving Key (CSRK) is crucial in this aspect. When a device has data to send, it generates a signature using the CSRK and attaches it to the data. The receiving device then uses the same CSRK to generate its own signature for the received data. If the generated signature matches the one attached to the data, it confirms the data's integrity and authenticity.

 

Device Privacy (Random Addressing) in Bluetooth LE

Bluetooth LE introduces measures to protect device privacy by implementing Resolvable Private Addresses (RPAs). These temporary and changeable Bluetooth Device Addresses make it difficult for malicious observers to track a device over time based on its address.

This process leverages the Identity Resolving Key (IRK), another 128-bit security key. The IRK is used to generate RPAs and resolve a device's identity given its RPA. It ensures that only trusted devices can resolve the true identity of a device from its RPA, thereby preventing unauthorized tracking.

 

The Long Term Key ( LTK)

 

Figure 2. AES-CCM is designed to provide both authentication and confidentiality during data transfer. Image used courtesy of Microchip

 

The LTK is a 128-bit key used along with the AES-CCM (Figure 2) encryption method to carry out three main tasks:

• Creating a unique key-stream: This is the first step where a special, one-time-use key-stream is made using the LTK. This key-stream, sometimes called a nonce, is a random or near-random number. When combined with the LTK, it helps make the encryption process secure and hard to break into.
• Encrypting data: After the key-stream is created, it's used with the AES-CCM encryption method to protect the data. The AES-CCM reads the unencrypted packet located in the device's RAM, encrypts the packet, and appends a four-byte-long Message Integrity Check (MIC) field to the packet. This MIC field enhances security by checking the integrity and authenticity of the messages. AES-CCM also adjusts the packet's length to account for the extra MIC field. The encrypted data packet is then stored back in the device's memory.
• Decrypting data: In the final step, the AES-CCM looks at the encrypted data packet in the device's memory, decrypts it, and verifies the packet's MIC field, producing the right MIC status. The packet's length is adjusted for the MIC field by reducing it by four bytes. The decrypted data packet is then stored back in the device's memory.

 

The Connection Signature Resolving Key (CSRK)

We know that once paired, two devices share a trusted relationship and can exchange authenticated and encrypted data.

However, not all communication between paired devices is encrypted. Whether to encrypt the data or not depends on the specific requirements of the communication scenario. For instance, some simple sensor readings or other non-sensitive data may not require encryption, while personal health data or other sensitive information would.

BLE supports encrypted and unencrypted communication between paired devices to provide flexibility in these scenarios. When encryption is not used, BLE provides an alternative method to ensure the authenticity and integrity of the data—this is where data signing and the CSRK come into play.

Data signing allows a device to verify that the received data came from a trusted source (the device with which it is paired) and that the data has not been tampered with during transmission. 

Think of signing the data like sealing a letter with a unique, personal wax seal. Anyone who receives the letter can look at the seal and know that the letter came from you, as long as they know what your seal looks like.

In Bluetooth LE, the "seal" is a signature that the sending device adds at the end of the data it sends. When the receiving device gets the data and the signature, it checks the signature. If the signature is confirmed or "verified," the receiving device knows that the data came from the trusted source.

The signature consists of two parts: a Message Authentication Code (MAC), which is generated by the signing algorithm using the CSRK and the data, and a counter. 

The counter is like a running tally of how many times the device has sent signed data. It's included in the signature to protect against "replay attacks," where a malicious device intercepts the data and tries to resend it.

 

Figure 3. Example of MAC use. Image used courtesy of Wikipedia

 

Signing the Data 

The signing algorithm in BLE uses AES-CMAC to generate a Message Authentication Code (MAC) (Figure 3). This MAC is essentially the 'signature' that verifies the data's integrity and authenticity.

There are three inputs to the signing algorithm:

1. ‘m’: The message or data to be signed. This can be of any length.
2. ‘k’: The key used for signature generation is the Connection Signature Resolving Key in this case. It is 128 bits long.
3. ‘SignCounter’: A 32-bit counter increments for every message signed with a given CSRK.

The signing algorithm combines these inputs using the AES-CMAC (Cipher-based Message Authentication Code) function:

MAC = CMAC (k, M, TLen)

Here, ‘M’ is the concatenation of the message 'm’ and the ‘SignCounter.’ The ‘TLen' is the bit length of the MAC, which is 64 bits in the case of BLE.

After the MAC is generated, it's attached to the original message, and this combined packet is sent to the receiver.

 

Verifying the Data 

On receiving this packet, the receiver separates the received MAC and the message. It then uses its own copy of the sender's CSRK and the received SignCounter to generate a new MAC for the received message. If the newly computed MAC matches the received MAC, it verifies the integrity and authenticity of the data. 

Additionally, the receiver compares the received SignCounter to the last stored SignCounter. If the received SignCounter is greater than the stored one, it confirms the message is new, thereby preventing replay attacks.

 

The Identity Resolving Key (IRK)

When a Bluetooth LE device is in a state where it needs to be discoverable, it broadcasts an address. However, consistently using a static, identifiable address could make the device susceptible to tracking. 

To circumvent this, Bluetooth LE employs the IRK to generate a random, changing RPA (resolvable private address) that it can use in place of its actual address. This makes it much harder for passive eavesdroppers to track the device based on its Bluetooth address.

Generating and resolving these private addresses involves cryptographic functions and the IRK. 

Next, we’ll take a deeper look at how it works.

 

Generating a Resolvable Private Address

To generate an RPA, a device uses its IRK and a random number called ‘prand’ in a specific cryptographic function called the ‘ah’ hash function. 

The equation for this function is:

hash = ah (IRK, prand), truncated to 24 bits

In this function, the 128-bit IRK and 24-bit prand are used as inputs to an AES-128 encryption process, and the most significant 24 bits of the output are taken as the hash .

The RPA is then formed by concatenating the 24-bit prand, and a 24-bit hash part, with the prand being the most significant bits and the hash being the least significant bits. The device then uses this RPA as its device address when broadcasting its advertising packets.

RPA= prand (24 bits) || hash (24 bits)

 

Resolvable Private Address Timeout

The host of the LE device is also responsible for setting a timeout that determines how often a new RPA should be generated. 

The host communicates this to the controller through the HCI_LE_Set_Resolvable_Private_Address_Timeout command, which allows the host to specify a timeout value. The controller's link layer then sets a timer based on this value. When the timer expires, the controller generates a new RPA for use.

The timeout value can range from 1 second to 11.5 hours, which provides significant flexibility in balancing privacy needs against the computational cost of generating new RPAs. The Bluetooth Core Specification recommends a value of 15 minutes, as this provides a reasonable trade-off between privacy and computational resources for most applications.

 

Resolution of Resolvable Private Addresses

When a device receives an advertising packet with an RPA, it uses its stored IRKs to resolve the RPA and reveal the identity or actual address of the sending device. 

This is achieved by executing the "ah" hash function with the received, prand and each stored IRK. 

The equation for this function is:

computed_hash == ah (stored_IRK, extracted_prand)

If the computed_hash matches the hash value from the received RPA, the device knows that the RPA was generated using the same IRK that it has stored. Therefore, it can confirm that the device broadcasting the RPA is the same device with which it shares the stored IRK. Thus, the result of the resolution is successful.

 

Resolving List and Privacy Modes

The Resolving List (Figure 4) is a record set in the Link Layer of a device to keep a record of pairs of IRKs: the Local IRK (the device's own IRK) and the Peer IRK (the IRK of the device it is paired with).

 

Figure 4. Logical representation of the resolving list. Image used courtesy of Bluetooth 5.4 specification

 

These IRK pairs are associated with identity addresses. An identity address is a unique, constant address that can be public (assigned during manufacturing) or static (randomly chosen but constant over device restarts). 

When a device receives an advertising packet with an RPA, it uses the IRKs in the resolving list to resolve the RPA and identify the sender.

On top of the Resolving List, Bluetooth LE also incorporates privacy modes to define how devices respond to scan and connection requests from peer devices in its resolving list. These privacy modes are:

• Network privacy mode: When enabled, a device will only accept advertising packets if they come from a device on its resolving list and the packets contain an RPA that can be resolved using the stored IRK of the peer device. This setting enhances privacy by only accepting requests from recognized devices using dynamically changing addresses.
• Device Privacy Mode: When enabled, the device will only accept advertising packets from devices on its resolving list that use either their static Identity Address or an RPA that can be resolved using the stored IRK of the peer device. This means that it allows connections from known devices using their static addresses, as well as connections using the privacy-enhanced RPAs.

The host can set both these privacy modes using the HCI_LE_Set_Privacy_Mode command to the controller. 

 

All About the Three Important Keys 

Bluetooth LE uses three important security keys to keep your data and devices safe.First, there's the Long Term Key (LTK). This is like a secret password that helps scramble and unscramble data, making sure that only the devices that know this secret password can understand the data.

Next, we have the Connection Signature Resolving Key (CSRK). This is used to 'sign' data. It's like when a letter is sealed with a unique wax seal—when a device receives the data, it checks the seal and if it matches, it knows the data is authentic and hasn't been messed with.

Lastly, there's the Identity Resolving Key (IRK). This key helps keep your device's identity private. It creates a disguise address for your device, so it can't be tracked by its public BD_ADDR.

These three keys work together to keep your Bluetooth LE communications secure.

In our next article, we'll talk about how these keys get shared between devices that trust each other.

Note: If you're interested in further exploring the LE security features, we recommend reading our comprehensive article “Securing Bluetooth LE Connections: An Overview of the Security Protocol". It offers a more comprehensive look at the security mechanisms used in Bluetooth LE.