Bluetooth LE: Security Modes and Procedures Explained

There’s no doubt that Bluetooth Low Energy (BLE) technology's surge in popularity has made our lives more convenient. That said, along this rise, security concerns for Bluetooth LE devices have escalated. 

Contrary to common belief, this isn't necessarily due to any inherent Bluetooth LE protocol flaw. Rather, the issue often lies in the constraints manufacturers and developers face—namely, rigid market deadlines and the daunting intricacies of a 3000-page Bluetooth specification. Under these pressures, security measures are occasionally overlooked.

Nevertheless, as Bluetooth LE becomes an increasingly integral part of our daily lives, such compromises on security become less acceptable and more perilous. With that in mind, it’s more critical than ever to comprehend the nuances of Bluetooth LE security measures and to make this information accessible and digestible to all stakeholders. After all, an informed perspective is our most potent defense.

This article aims to make Bluetooth LE security easy to understand. We'll focus on its three main security modes: LE Security Mode 1, Mode 2, and Mode 3. We'll also review the five security procedures: Encryption, Authentication, Data Signing, Encrypted Advertising, and Authorization.

 

Definitions 

If you want to handle Bluetooth LE security well, it's imperative to know two basic things: what "security modes" are and what "security procedures" are.

 

Security Modes

The term "mode" in English means a specific way of doing something or how one behaves. For example, how we travel—by car, bike, train, or foot—is a mode of transport. Similarly, in the case of Bluetooth LE security, 'modes' are the different methods a device uses to stay secure. Different modes give different levels of safety. The choice of mode depends on the specific security needs of a device and its resistance to security threats.

 

Security Procedures

On the other hand, "security procedures" refer to the actual actions or processes used to ensure the security of the Bluetooth LE device.

In essence, while security modes set the overarching strategy for a device's security (in other words, security requirements), the security procedures are the tactical implementations that bring this strategy to life. 

In this article, we'll be switching back and forth between security modes and procedures.

 

Security Mode 1 

This mode primarily grapples with the decision of device pairing and, more specifically, the type of pairing—be it authenticated or unauthenticated.

 

Figure 1. High-level pairing flow. Image used courtesy of Bluetooth SIG

 

To delve deeper into the pairing mechanisms and association models, I'd recommend our previous article Understanding Bluetooth LE Pairing—Step by Step.

Now, let's dissect the different security levels encapsulated within Security Mode 1.

 

Security Level 1: No Security (No Authentication, No Encryption)

In Level 1, devices connect without pairing. This level offers maximum user convenience and is typically seen in devices where security is a low priority. However, without any protective measures in place, this level is vulnerable to all types of security breaches.

 

Security Level 2: Unauthenticated Pairing with Encryption

Stepping up to Level 2, devices require pairing, but the pairing process doesn't involve user interaction. This level leverages the Just Works association model, making it a common choice for situations where one or both of the devices involved in pairing lack the ability to input or output (IO capabilities).

 

Security Level 3: Authenticated Pairing with Encryption

At Level 3, we encounter authenticated pairing. The key element here is the protection against Man-in-the-Middle (MITM) attacks, which is achieved by necessitating user interaction during the pairing process. Devices operating at this level use either the Out-of-Band (OOB) association model or the passkey entry method for pairing.

 

Security Level 4: Authenticated LE Secure Connections Pairing with Encryption Using a 128-Bit Strength Encryption Key

Devices at this level implement pairing via the LE Secure Connections pairing method, superseding the legacy method. This pairing process incorporates the Numeric Comparison association model and requires a robust 128-bit strength encryption key.

It's important to note that a device's I/O capabilities often determine the association model and, consequently, the security level it can achieve. In some cases, devices are produced without any I/O capabilities to keep costs low, limiting them to Level 1 or the Just Works association model—both of which provide the least protection.

Furthermore, user convenience plays a significant role in the choice of security level. High-security levels requiring user interaction during pairing may be viewed as inconvenient, pushing developers and manufacturers towards lower security levels. This trade-off between convenience and robust security is a critical factor to consider in the design and use of Bluetooth LE devices.

Security Levels in Mode 1 are hierarchical. Higher security levels inherently fulfill the requirements of the lower ones. For example, a connection at Level 4 meets the requirements for all preceding levels, ensuring comprehensive security.
 

Authentication Procedure

In digital communication, 'authentication' is the process that verifies the identity of a user, device, or system. It's a critical checkpoint that ensures the parties involved in the communication are genuinely who they say they are.

This validation process helps keep MITM attacks at bay. In a MITM attack, a hacker places their device in the middle of two devices that are trying to connect. They trick each device into thinking that the hacker's device is the one they're supposed to pair with. So, the devices unintentionally end up connected to the attacker's device instead.

To thwart MITM, Bluetooth LE implements an authentication procedure during device pairing. This procedure, involving user interaction, ensures the devices confirm their communication partner's identity, making the pairing process more secure.

The way this authentication is done can vary based on the pairing model in use:

• Passkey entry: This method involves the use of a six-digit passkey. One device displays this passkey during the pairing process, and the user confirms and enters it on the other device to authenticate the pairing.
• Numeric key comparison: In this method, a six-digit numeric key is displayed on both devices. The user is then asked to confirm if the numbers match on both devices to authenticate the pairing.

We also have the Out of Band (OOB) method. This method provides MITM protection without depending on the IO capabilities of the devices involved. Instead, it relies on an external form of communication that is itself resistant to MITM attacks.

 

Encryption Procedure

The encryption procedure occurs during the second phase of the pairing process. In this stage, devices collaborate to generate a secret key which they use to encrypt the communication link. By doing so, they shield the to-be-shared security keys from eavesdropping. 

 

Security Mode 2

Bluetooth LE's Security Mode 2 is exclusively dedicated to a feature known as 'connection-based data signing.

 

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

 

Now, you might ask, "What is data signing?" At its core, 'data signing' is a procedure that guarantees the data sent between devices remains intact and trustworthy.  It involves generating and appending a unique signature to the data packet. This signature, born from a secret key (CSRK key) shared between the devices in the pairing process, tags along with the data as it travels from one device to another.

Why is this important? It provides:

• Integrity: By checking the signature, the recipient device can verify that the data hasn't been altered in transit. If an attacker tries to change the data, they would also need to alter the signature correspondingly, which would require knowledge of the secret key.
• Authenticity: The signature also confirms that the data genuinely originates from the expected device. Only the device in possession of the secret key could have generated the correct signature.

So, when we say Security Mode 2 is for 'connection-based data signing,' we mean that this mode equips Bluetooth LE connections with a feature to confirm that the data they're sharing is authentic and has not been altered.

There are two security levels in LE Security Mode 2:

 

Security Level 1: Unauthenticated Pairing with Data Signing

In this level, pairing happens without user interaction, typically through the 'Just Works' method. As there's no MITM protection, pairing devices in a secure environment is crucial, certainly not in public places. 

To implement data signing, devices must share the CSRK key during the transport key distribution phase in pairing. This level is used for services requiring fast connection setup and data transfer. 

 

Security Level 2: Authenticated Pairing with Data Signing

This level involves user interaction during pairing, which provides MITM protection. The pairing methods used here include Out-of-Band (OOB), Passkey Entry, or Numeric Comparison. This level necessitates using encryption, authentication, and data signing procedures for bolstered security.

 

Connection Data Signing Procedure

The connection data signing procedure is a security guard for the integrity and authenticity of data transmitted between devices, even when encryption isn't used. The procedure can be summarized in the following steps:

1. Key Generation: During pairing, devices share a Connection Signature Resolving Key (CSRK). 
2. Signature Creation: Device A makes a data packet to send to Device B. At the same time, Device A uses the CSRK and the packet's details to create a signature. The signature comprises a Message Authentication Code (MAC), made by a special Signing Algorithm and a counter value. The counter value increases every time a new data packet is sent. This makes sure that every signature is unique, even for data packets that are the same.
3. Data Transmission: The signature is appended to the data packet, forming a convoy that travels together over the communication link from Device A to Device B.
4. Signature Verification: Upon receipt, Device B uses its copy of the CSRK to recreate the signature. It does this based on the received data packet and the counter value. If the newly recreated signature aligns with the one that came with the data packet, Device B can trust the data's authenticity and that no tampering occurred during its journey.
5. Counter Synchronization: The counter value also helps Device B keep track of the data packets' sequence. If there's a mismatch in the counter value, Device B can identify that a replay attack is happening.

Figure 3. Data appended with a signature. Image used courtesy of Bluetooth SIG

 

Security Mode 3 

Security Mode 3 comes about when dealing with devices broadcasting isochronous data. The pivotal question here is: should this broadcasted data be encrypted? If the answer is yes, how should we share the encryption's broadcast code?

To accommodate varying requirements, Security Mode 3 has three levels.

 

Security Level 1: No Encryption Required

With this level, devices simply say "no thank you" to encryption. The isochronous data is broadcast in plaintext providing utmost ease and convenience at the expense of security.

 

Security Level 2: Encryption with Unauthenticated Broadcast_Code

This is where things get a bit more secure. Devices at this level insist that isochronous data gets a protective layer of encryption before it hits the airwaves. But, the key to that protective layer, the Broadcast_Code, doesn't need to be authenticated. 

 

Security Level 3: Encryption with Authenticated Broadcast_Code

Here, isochronous data must be encrypted with an authenticated Broadcast_Code. If the device doesn't receive this authenticated code when necessary, it prompts an error message, such as "Insufficient Security for Broadcast_Code."

 

Encrypted Advertising Data Procedure

Before the Bluetooth Core Specification version 5.4 was put into place, there was no set way to keep advertisement data confidential. But with the new Encrypted Advertising Data procedure, this issue was addressed, creating a new benchmark for securing broadcasted data from connected devices.

The encrypted advertising data procedure enables advertising packets to be secured through encryption and authentication processes.

This procedure uses the CCM encryption algorithm to encrypt and authenticate the Advertisement Data (AD data). The encryption key, referred to as the Key Material, is stored in the peripheral LE, which is usually the server in the Generic Attribute Profile (or GATT), and this key is shared with the GATT client.

 

Authorization Procedure 

Authorization serves as a second layer of defense after authentication. While authentication ensures devices are who they claim to be, authorization verifies whether a device has the required permissions to access certain resources or perform certain actions.