Securing BLE Connections—An Overview of the Security Protocol

Communication protocols like Bluetooth LE need to prioritize security. And there’s a good reason for that. They're carrying precious cargo: our data! Without these protocols, our sensor data, control messages, automation commands are all at risk. They could all be swiped, peeked at, or messed up by some no-good internet rogues. The consequences of all this are many: Problems like incorrect sensor readings, messed up automation, or even total network shutdowns.

As an example, imagine a smart irrigation system where sensors send data to a central hub to decide when and where to water. If the messages from the sensors are intercepted or altered, you might end up with a flooded garden or a parched lawn. Or picture a home automation system where a rogue command could switch off your security lights at the worst possible time.

It’s true that different wireless communication protocols address different aspects of security, depending on their purpose. That said, most have a common set of goals, as follows:

• Confidentiality: This ensures that the content of the communication cannot be read by anyone other than the intended recipients. This is usually achieved through encryption, which transforms data into an unreadable format unless the appropriate decryption key is used.
• Integrity: This ensures that the data cannot be tampered with during transmission. Techniques like hashing and digital signatures are often used to verify that the data received is exactly the same as the data that was sent.
• Authentication: This is all about confirming identities – making sure that the devices involved in the communication are really who they claim to be. In real-life, we use personal identification documents like passports to prove our identity. Similarly, in wireless communications, this might involve pre-shared keys or device certificates. Authentication helps deter imposters, and in its absence, communication systems can experience Man-in-the-Middle (MITM)attacks.
• Non-repudiation: This is the "no take-backs" rule. It prevents a device from denying it sent a message. This can be a bit more challenging in the low-power world, but some protocols have clever ways to handle it.
• Availability: It involves designing the network to resist or recover from interference, jamming, or other attacks that could disrupt service.
• Authorization: It's about giving permissions: What can each device do? Which data can it access? What operations can it perform? This level of control is essential to prevent a device from accessing information or performing actions outside its jurisdiction.
• Privacy: The last thing anyone wants in a world striving to be more connected is to be tracked. Privacy is the security aspect that ensures this doesn't happen. It involves hiding or anonymizing the device's address or other identifying features to prevent unauthorized tracking of the device and, by extension, its user. 

In this article, we’ll discuss how the Bluetooth LE protocol provides some of the above security features, as well as the key considerations to take when building a secure LE device. 

 

SMP—Bluetooth LE Security Toolbox

Bluetooth Low Energy (BLE), as its name suggests, is designed for short-range communications while keeping power consumption to a minimum. But just because it's low power doesn't mean it skimps on security. On the contrary, Bluetooth LE incorporates a variety of mechanisms to ensure secure communication. 

Bluetooth LE incorporates an integral component known as the Security Manager, paired with the Security Manager Protocol (SMP). This protocol presents a toolkit (Figure 1) filled with optional security features that product designers can sift through to find what best fits their product's security needs.
 

Figure 1. Bluetooth LE’s security manager protocol (SMP) is a toolkit filled with security features for product designers to use. Image (modified) used courtesy of Adobe Stock

 

The SMP doesn't treat any of its security features as a “must-have”, but some of the Bluetooth profile specifications do require a minimum level of security. Meanwhile, when selecting security features, system designers have to play a bit of a balancing act.

They have to pick the right security tools from the SMP toolbox, keeping in mind that skimping on security features could leave their product wide open to sneaky attacks. On the flip side, piling on too many features might bump up the development and hardware costs, not to mention possibly affect the device's performance and the all-important user experience (UX).

 

BLE Security Features—Examining 7 Attributes

Now, let’s take a closer look at how Bluetooth LE manages to tick the boxes for the security attributes we talked about earlier. We’ll discuss seven important attributes one by one.

 

1. Link Encryption Addresses the need for Confidentiality

Encryption is a technique used to keep data secret. It works by converting readable data (or plaintext) into a scrambled, unreadable format (or ciphertext). This conversion requires two things: an encryption algorithm, which is like a set of rules for the scrambling process, and a key, which is a unique piece of information that ensures each transformation is one-of-a-kind.

If you're the intended recipient, you can turn the ciphertext back into readable plaintext using the appropriate secret key and the reverse of the algorithm.

Bluetooth LE uses a special kind of encryption known as AES-CCM. AES-CCM stands for Advanced Encryption Standard with Cipher Block Chaining Message Authentication Code. This method does two things: it keeps data confidential through encryption (using AES), and it verifies the data's authenticity (using the message authentication code).

To create and share these encryption keys, a process called pairing is used. There are two main types: LE Legacy Pairing and LE Secure Connections. LE Legacy Pairing, introduced in BLE v4.0, was the original method. However, it had a weakness: it was susceptible to passive eavesdropping and MITM (man in the middle) attacks. 

To counter these security issues, BLE v4.2 introduced a more secure method called LE Secure Connections. This new pairing process uses a cryptographic protocol called Elliptic Curve Diffie-Hellman (ECDH) for key exchange. This protocol allows two devices to create a shared secret key, even over an unsecure channel, enhancing security significantly.

And, to make its encryption even stronger, Bluetooth LE uses something called a Session Key Diversifier (SKD). This is a value that both devices share when pairing, and it's used to generate the session key. The key changes with every session, which means every encryption session is unique. This ensures that even if you encrypt the same plaintext during different sessions, the resulting ciphertext won't be the same.

 

2. Message Authentication Codes (MACs) Verify the Authenticity and Integrity of Data

Message Authentication Codes, or MACs, also known as Message Identification Codes (MICs), are cryptographic mechanisms that help ensure a message's authenticity and integrity during communication. They confirm that a message hasn't been tampered with in transit and that it came from a legitimate source.

Here's how MICs work:

1. Device A, the sender, creates a MIC for her message using a secret key that was previously established with Device B, the receiver.
2. Device A, sends the message along with the computed MIC to Device B.
3. When Device B, the receiver, gets the message, he generates his own MAC for the message using the same secret key.
4. Device B then compares the MIC he calculated with the one the Device A sent. If they match, the receiver knows the message hasn't been changed while it was being sent and it's likely from Device A. If they don't match, it means the message might have been tampered with or wasn't actually from Device A. 

One thing to note is that MICs aren't able to pinpoint exactly what changed in a message. They can only signal if a message might not be trustworthy. 

 

3. Digital Signature Verify the Authenticity and Integrity of Data

Digital signatures use a method known as asymmetric cryptography, where two different keys are used: a private key to sign, and a public key to verify the signature. This mechanism assures that the message came from a specific source and that it hasn't been altered during transmission.

Within Bluetooth LE, digital signatures are used in data signing for individual GATT write procedures through the Attribute Protocol (ATT) Signed Write command. 

The Generic Attribute Profile (GATT) is used for sending and receiving short pieces of data known as "attributes" over a BLE connection. GATT is built on top of the Attribute Protocol (ATT), which defines the basic structure and operation of these data transfers.

When data is being written to an attribute on a Bluetooth LE device (which is known as a GATT write operation), it's often important to verify the authenticity of that data. To accomplish this, the ATT Signed Write command can be used. This command works by attaching a digital signature to the attribute value that's being written. 

Here's how this works:

1. Device A, the sender, uses her private key to create a digital signature for her message, and sends her message, digital signature and public key to Device B, the receiver.
2. When Device B receives the message and the signature, he uses Device A's public key, which is known to him, to verify the digital signature. If the signature verifies correctly, Device B can be sure of two things : the message indeed came from Device A (authentication), and the message wasn't tampered with during transmission (integrity).
3. However, if the va/lidation fails, it means either the message didn't come from Device A or the message was modified during transit. In such cases, the message is deemed untrustworthy.

While digital signatures and MICs both ensure data integrity and authenticity, they do so differently. MICs use symmetric cryptography, which involves a shared secret key known to both sender and receiver. Meanwhile, digital signatures use asymmetric cryptography—where a private key is used to sign, and a public key is used to verify the signature. 

 

4. Encrypted Advertising Data (EAD) & Broadcast Codes 

While Link encryption, (MICs), and digital signatures are powerful security features for Bluetooth LE devices, they primarily cater to connected communication. That is, they're most useful when devices have established a connection and are communicating in that context.

However, BLE also supports connectionless communication, where devices broadcast information openly. This is where mechanisms like Encrypted Advertising Data (EAD) and broadcast codes become relevant.

The EAD feature—introduced in version 5.4 of the Bluetooth Core Specification—allows the data payload that's transmitted in advertising packets to be encrypted. 

And for Broadcast Isochronous Groups (BIG) or Streams, broadcast codes are used for encryption. The broadcast code is a 16-octet value that is shared among devices in the BIG. This code is used to generate an encryption key, which is then used to encrypt the data broadcasted to devices in the group.

 

5. Private Addresses Protect Against Device Tracking

Bluetooth LE devices have a public address known as a Bluetooth Device Address (BD_ADDR). This address is globally unique and is hard-coded into the device during manufacturing. Essentially, it is the identity address of the device, and it facilitates device discovery, connection establishment, and data exchange.

However, the BD_ADDR poses a potential privacy risk. Since the address remains static, by capturing the BD_ADDR, an attacker can track the device's movements and infer user behavior.

To address these privacy concerns, Bluetooth LE introduced the concept of “private addresses” (Figure 2). These addresses are not identity addresses; instead, they hide the identity of the device by substituting the actual address with a randomly generated one that changes periodically. This helps to maintain user privacy and protect the device against tracking.
 

Figure 2. Format of a resolvable private address. Image courtesy of Bluetooth Security Study Guide

 

There are three types of private addresses, each offering a different level of security:

• Random static addresses: This type of private address changes each time the device is power-cycled. This is the least protective form of private addresses because it remains constant between power cycles, making it possible for tracking to occur if the device remains on for long periods.

• Resolvable private addresses (RPAs): These addresses offer a higher level of protection because they change more frequently (recommended to change every 15 minutes) and can only be resolved by devices with which they've shared a secret key called the Identity Resolving Key (IRK) during the pairing process. Therefore, even if an attacker manages to capture the RPA, without the IRK, they cannot determine the actual identity address of the device.

• Non-resolvable private addresses (NRPs): These (Figure 3) are the most secure type of private addresses. NRPs cannot be resolved by any other device, not even those the device has paired with. As a result, they completely shield the identity address of the device. 

 

Figure 3. Format of a non-resolvable private address. Image courtesy of Bluetooth Security Study Guide

 

6. Attribute Permissions Address Authorization 

In the world of Bluetooth LE, the communication between connected devices is centered around a client-server model. The server contains a set of data, known as attributes. These attributes can be anything from data used by a particular service to metadata about the service or the server itself.

To ensure secure communication and protect these attributes, Bluetooth LE incorporates an authorization mechanism through a feature known as Attribute Permissions. Attribute Permissions are a set of rules or guidelines that govern which clients are allowed to access or modify these attributes, and under what conditions.

Each attribute has its own set of permissions, which dictate how a connected device can interact with that attribute. 

These permissions fall into three main categories: 

• Access Permissions: These permissions determine the type of access a client has to a server's attribute. The access permissions can be set to "read," "write," or "read/write." 

• Encryption Permissions: Encryption permissions refer to the level of encryption required before a client can access a particular attribute. There are generally two levels: unencrypted and encrypted. Some attributes may allow access without any encryption, but for more sensitive data, the server may require the client connection to be encrypted before any access or data exchange can take place.

• Authentication Permissions: Authentication permissions require a client to prove its identity before it can access a particular attribute. This can be achieved through using pairing with an association model that allows for authentication. After successful authentication, the client device will be granted access to the attribute.

 

7. Accept List to Address Unavailability

A Generic Access Profile (GAP) peripheral device, that is a device that advertises itself and accepts connections, can only be connected to one device at a time. This limitation could potentially be exploited by an attacker, who can connect to the peripheral device, making it unavailable for legitimate use when needed.

To counter this, Bluetooth LE incorporates a feature known as the Accept List. The Accept List is a whitelist of trusted devices that the peripheral device allows to connect. It contains the addresses of devices that the peripheral device trusts and wants to allow connections from.

When another device tries to connect, the peripheral device checks the Accept List. If the incoming device's address is on the list, the peripheral device accepts the connection request. If not, the request is ignored. This ensures that only trusted devices can connect, providing a significant layer of security.

By using the Accept List, Bluetooth LE devices can effectively protect themselves from unwanted connections and potential denial of service attacks. 

 

Key Considerations for Building a Secure BLE Device

When building a Bluetooth LE device, your implementation decisions can make a significant difference in the overall security of the system.

These security tips will help ensure that security is at the heart of your design:

1. Keep up with the latest Bluetooth Core Specification: Always make sure your product or application is based on the most recent Bluetooth Core Specification. At the bare minimum, it should meet the security requirements defined in the relevant profiles.

2. Employ robust pairing: Use a pairing association model that offers protection from Man-in-the-Middle (MITM) attacks. This means designing your device with the necessary input/output capabilities.

3. Do not use an encryption key size less than 16: This is the maximum key size and using anything less may compromise your device's security. If your application needs heightened security, set up your device to disallow pairing and immediately terminate any connection with devices attempting to use an encryption key smaller than 16 octets.

4. Use secure authentication: If you must use LE Legacy Pairing, it's advised to employ a secure out-of-band (OOB) mechanism for authentication.

5. Use address randomization: Opt for randomized private addresses instead of the static trackable identity addresses. To further enhance privacy, refresh these addresses regularly, following the recommended frequency in the specification (15 minutes, ref: Bluetooth Core Specification 5.2 Vol 6, Part B section 6.1).

6. Implement application-layer security: Especially for BLE devices that pair with mobile apps, consider implementing your own application layer security protocol to complement BLE security.

7. Set attribute permissions: Pay attention to configuring attribute permissions for finer control over who can access what data.

8. Allow for updates: Ensure your device can receive software updates. This feature is critical, as it allows for the rectification of known security weaknesses in devices already in circulation.

 

Leverage the Rich Toolbox

The LE Security Manager protocol is a rich toolbox, filled with tools that provide confidentiality, data integrity, authorization, and protection against device tracking. These are the ingredients you need to bake a secure Bluetooth LE device.

If you're a product designer, embedding security into your product's DNA is a must. The LE security features we've highlighted in this article are aimed at streamlining this task. But this isn't the end of the road. Stay tuned for a follow-up article that dives into common attacks on Bluetooth LE features. It will provide a more comprehensive understanding, helping you further tighten your device's security.