Introduction to BLE security for IoT

With a handful of protocols leading the Internet of things, Bluetooth security for IoT becomes extremely important. For the consumer to industrial-focused IoT, leveraging the mesh networks Bluetooth low energy is helping build Industry 4.0. Companies that build IoT devices for a large number of users should test security vulnerabilities during product development.

With Bluetooth 5.0, the enhanced BLE range, enhanced channels, and the network topology are really amazing. But, when you connect your safety-critical systems, your consumer products and your daily workflow using Bluetooth low energy. How secure is Bluetooth?

The short answer? Very big. But you probably already knew that. We’ll go more into the details about how Bluetooth security works in this article, but let’s start with a cautionary tale.

A recent example of this vulnerability in practice came from the most innocent of children’s toys: a teddy bear. 11-year-old Reuben Paul shocked an audience of security experts at a conference in The Netherlands.

According to SecurityWeek, he used a Raspberry Pi to connect to the WiFi network and download the numbers of many Bluetooth connected devices, including his teddy bear. He then used that information to hack into his bear and turn on lights remotely, as well as recording a message from the audience.

Chilling for a simple teddy bear, right?

Security vulnerabilities associated with remote access technologies

With the release of Bluetooth 5, there are several new features designed to expand the features and capabilities for Internet of Things (IoT) devices. Here are just a few of the new features, according to SecurityIntelligence:

• Data transmission up to 2 Mbps
• Communication up to 400 meters
• 800% in connection bandwidth

While these improvements mean that using Bluetooth for connected devices instead of WiFi becomes more feasible, it also opens up other security concerns. The increased bandwidth and connection distance means that an attacker can access Bluetooth connections from even further away than before. And with the new 2 Mbps data transfer speed, they could get the data they need and be off before you even notice.

Common Bluetooth security vulnerabilities

A publication from NIST details common Bluetooth security vulnerabilities. While many have been patched over the years as the Bluetooth protocol has matured, many vulnerabilities still exist even in the most recent version of Bluetooth. Here is a selection of current security limitations:

• No user authentication. At present, the Bluetooth specification only offers built-in device level authentication. Application and user-level security can be added by the application developer.

• No end-to-end security. Additional security layers can provide end-to-end encryption, but in the current specification, only individual links are encrypted. Even so, the messages are decrypted at intermediate points.

• Discoverable/connectable devices are prone to attack. Devices should not remain in “discoverable” mode at all times. Only turn it on when necessary.
• Link keys may be stored insecurely. Bluetooth link keys could be read or modified by an attack if they are not stored securely.

For even more Bluetooth attacks and vulnerabilities, see this paper.

List of common Bluetooth security risks for IoT

A report from Trinity College in Dublin lays out a list of security vulnerabilities inherent in wireless and Bluetooth connections. See the report for the full list, but some of the more unsettling implications are described below:

• Sensitive information transferred between two wireless devices (or data encrypted with weak cryptographic techniques) can be intercepted and decoded. This is called a “Man-In-The-Middle Attack” (MITM), and we will discuss it more below.
• Data could be corrupted during improper synchronization.
• Data can be extracted without detection on many wireless mobile devices.
• Many IoT devices are easily stolen and with it, any sensitive data residing on the device.

Bluetooth man in the middle attack (MITM)

What exactly is a Man in the Middle attack? If you’re sending data between two wireless devices (such as your fitness tracker and your phone) it could be intercepted by a third party called a “man in the middle.”

When two devices exchange keys, the attacker catches the key and replaces it with their own, “impersonating” the other user.

So how do we protect against this? There are three levels of MITM encryption you can use:

• No protection. This uses a known key equal to 0, meaning that an attacker can follow your connection if they catch your packets during pairing.

• Low protection. This involves using a user input passkey that’s less than 1,000,000. This way, an attacker only needs to try one million keys.
• High protection. In this method, the device uses an out of band key. This way, the attacker would need to know the key in order to proceed. However, there’s no key-exchange process yet in BLE.

Note of caution: Bluetooth “Just Works” pairing does not protect against MITM attacks. “Just Works” pairing is commonly used with devices that do not have a display or keypad because they are unable to use Passkey authentication.

Further reading on MITM:

Attacking bluetooth smart devices: introducing a new BLE proxy tool from Priyanka Aash

Passive eavesdropping in Bluetooth

While using a strong passkey can help protect against MITM attacks, Slawomir Jasek from the security firm SecuRing warns that it does not protect against passive eavesdropping.

Passive eavesdropping is a little different from MITM because it does not seek to change or impersonate the data. It simply sits there, watching and gathering information.

In fact, Jasek mentions that up to 80 percent of Bluetooth smart devices are vulnerable to MITM attacks because companies often do not implement bonding and encryption standards.

This can be mitigated by using AES cryptography in addition to a secure pairing/key exchange method.

Is Bluetooth encrypted?

Since Bluetooth 2.1, encryption has been mandatory after devices have been paired. Note that this does not say anything about the encryption of the pairing/authentication process.

For example, since there is no screen on your wireless keyboard or headset, it’s not easy to know you’re connecting to the right device. Of course, you should always check the MAC address, but that can be spoofed.

Bluetooth low energy encryption algorithm

Data transmission over Bluetooth LE in version 5.0 of the specification uses AES-CCM encryption. This encryption is performed in the Bluetooth Controller.

Ref: Bluetooth Specification Version 5.0

Bluetooth LE security modes

According to the Bluetooth Specification Version 5.0, There are two Bluetooth LE Security modes:

• LE Security Mode 1
• LE Security Mode 2

Each of these modes comes with differing levels of security within those modes.

LE Security Mode 1

There are four security levels within LE Security Mode 1.

1. No security (No authentication, no encryption)
2. Unauthenticated pairing with encryption
3. Authenticated pairing with encryption
4. Authenticated LE Secure Connections pairing with encryption using a 128-bit strength encryption key.

Each security level satisfies the requirements for the levels below it (e.g. LE Security Mode 1 Level 4 satisfies the requirements for levels 1, 2, and 3.) In addition, LE Security Mode 1 Level 4 and LE Security Mode 1 Level 3 also satisfy the requirements for LE Security Mode 2.

LE Security Mode 2

There are two security levels within LE Security Mode 2.

1. Unauthenticated pairing with data signing
2. Authenticated pairing with data signing

LE Security Mode 2 is only used for connection-based data signing (transferring data between two devices on an unencrypted connection).

BLE pairing vs bonding

To an outsider, Bluetooth LE pairing and Bluetooth LE bonding may sound like the same thing. Not so. Here’s a breakdown of the differences:

Bluetooth LE pairing

Pairing is the process of finding and exchanging temporary keys with a Bluetooth device. This temporary key is used to encrypt the connection. According to the blog Pirate Comm, the Client side initiates an exchange of security features where it asks the server what it can do (e.g. does it have input? Output?)

This exchange of features will determine what pairing method to use. For example, if the server only supports no input and no output (let’s say, for a Bluetooth light bulb), then Just Works pairing will be used.

Once this exchange is complete, the devices share temporary encryption keys. These keys are not stored for posterity. During this encrypted connection, long-term keys may be stored for later use. This is called “bonding” which you can learn more about below.

This is called “bonding” which you can learn more about below.

Bluetooth LE bonding

Just like in real life, Bluetooth LE bonding refers to a longer-term connection with another device. Think of it as a “known party”. At this point, the devices have shared long-term encryption keys with one another, so when pairing initiates again, the devices use that key instead of generating a new one.

Because of this process, the devices do not need to re-negotiate new encryption keys. The client can simply say “hey, turn encryption on”, and the server will use the pre-stored keys to do so. In this manner, the devices can initiate an encrypted connection without another key exchange.

This means that eavesdroppers cannot see the key exchange and snoop on the connection.

Elliptic Curve Diffie-Helman cryptography is used for key exchange in Bluetooth LE Secure Connections, according to the Bluetooth Specification Version 5.0. This helps protect against passive eavesdropping but may be susceptible to Man in the Middle (MITM) attacks.

To mitigate this risk, ensure that you are not using the same passkey multiple times. The Bluetooth spec recommends random passkey generation each time pairing is initiated.

Bluetooth Passkey Entry

When one or more of the devices has an output and an input device, they can use Bluetooth Passkey Entry to pair. According to Kai Ren on the Bluetooth blog, the initiating device will show a six-digit number between 000000 and 999999. Then the user must enter the same number into the responding device, provided it has input functionality.

This value is called the Temporary Key (TK). In addition, the “master” and “slave” device each create a 128-bit random number which we’ll call Mrand and Srand.

Then each device generates a 128-bit confirm value using the algorithm presented in the Bluetooth Specification. Once those values have been exchanged and confirmed, then an encrypted channel exists between the two devices and we can say they have been “paired”.

Bluetooth Numeric Comparison

As of Bluetooth 4.2, a new pairing process exists called LE Secure Connections which mitigates some of the risk associated with passkey pairing. In addition to Passkey, Just Works, and Out of Band Authentication, there is a new method called Numeric Comparison.

Numeric Comparison requires that a display is available on both devices. An example of this is pairing between a mobile phone and a laptop. In Numeric Comparison, a six-digit key appears on both devices and the user must verify that they are the same number.

As long as both devices can accept a yes/no input, devices can use this method to pair and it may protect against MITM attacks (provided the key is confirmed on both devices and the comparison is done correctly).

Note: Numeric Comparison is not available for Bluetooth LE Legacy pairing, only LE Secure Connections (Bluetooth 4.2 and above).

Bluetooth Out Of Band Legacy pairing

When done correctly, Out of Band pairing techniques can be used to protect against some of the risks inherent in techniques like Passkey Entry. However, since it’s up to the developer to create a pairing method, the security depends largely on the technology used.

A common use case for Out of Band pairing is NFC (near field communication). This occurs when you tap two devices together to connect them. The idea is that since the devices are so close together, you do in fact mean to pair them.

Under the hood, both devices must have their OOB data flag set if they wish to use OOB for pairing. Then the exchange process works similar to Passkey Entry with both sides exchanging a random and confirm value.

At this point, you should know a lot more about Bluetooth security than you did at the beginning of this article. You have learned about common vulnerabilities, encryption techniques, and pairing processes. As Bluetooth-connected devices become ever more ubiquitous, we must remain vigilant and press for more comprehensive security controls. Do you have a story about a Bluetooth device went awry? Share it with us in the comments.