An Introduction to Bluetooth Security

Bluetooth is an established yet growing technology that allows the exchange of data between devices in a wireless personal area network (WPAN). It started in 1996, when Intel, Ericsson, and Nokia met to standardize a short-range radio technology to support connectivity between their products. The first specification was released in 1999, and from then, Bluetooth devices have experienced a very strong growth, as shown in the following figure:

The main two Bluetooth radio versions are:

• Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), also known as Bluetooth Classic
• Bluetooth Low Energy (BLE), also known as Bluetooth Smart, which is a light-weight subset introduced as part of Bluetooth 4.0 in 2010

Bluetooth Classic and BLE use different stacks that have no compatibility. However, they can coexist in one device sharing the same antenna, because both use the same radio frequencies of the 2.4 GHz ISM band and apply frequency-hopping spread spectrum (FHSS) mechanisms to avoid interferences. In fact, in many cases, they complement each other; that’s the reason why nowadays most devices are dual mode. As shown below, Bluetooth Classic single-mode devices are projected to disappear in the future, while BLE single-mode devices grow due to the expanding IoT industry.

It is important to note that Bluetooth Classic is not an obsolete version of BLE; they are different technologies used for different applications. Bluetooth Classic is mainly used when point-to-point continuous streaming is required, e.g., wireless audio streaming (wireless speakers, headphones, in-car entertainment systems) or file transfers. On the other hand, BLE is designed for very low-power operations and supports multiple communication topologies, expanding from point-to-point to broadcast and mesh. Examples of BLE applications are monitoring sensors, beacons, and high-accuracy, indoor location services.

This post is focused on BLE, specifically version 4.2, which will be active until February 2025. It’s important to note that there is a version 5 of the Bluetooth specification that introduces some new features not outlined in this post (for example, extended advertising, mesh networking, or direction finding). However, version 5 devices are not so common in the market yet. 

What makes it “low energy”?

The main point is that BLE keeps the radio off for as much as possible. This is achieved by the following:

• There are only three advertising channels, rather than 16 to 32 for the Classic specification. This reduces the standby time.
• Very quick connection establishments (from a non-connected to connected state), takes around three milliseconds, which means less time using the radio. Bluetooth Classic connections can take up to 100 milliseconds.
• Low peak power, 15mA, which helps to save battery. Bluetooth Classic peak power is 25mA, which also is low but not enough for coin cell-based applications, for example.

BLE Stack:

Let’s define briefly how each layer works:

The application layer is typically where the most important data resides. Below this layer, the others are responsible of transporting or converting the data.

GAP defines two main aspects in BLE connections:

• Visibility: How devices discover each other, including scanning and advertising
• Interaction: How devices interact with each other, including how the connection is managed (roles, modes, security parameters, etc.)

There are two main connection modes in BLE: Advertising (sending data in one direction, without establishing a connection) and Connected (sending data in both directions).

Only after the visibility and the interaction aspects have been completely set by GAP, GATT then defines how the devices exchange information with each other. For this, GATT uses ATT as an underlying protocol to define how a server exposes its data to a client and how the data is structured. The data is structured as attributes, which can be one of several types (commands, requests, responses, notifications, indications, or confirmations), and are stored in a table using 16-bit unique IDs (also named ‘handles’) for each entry. So, the handle of an attribute can go from 0x0001 to 0xFFFF. According to the Bluetooth Specification, an attribute handle of value 0x0000 is reserved and shall not be used.

As said before, GATT defines how to interface with the attributes (data that must be sent), and for this, it uses the following concepts:

• Service: A group of one or more attributes
• Characteristic: A piece of data that the server wants to expose to the client

gatttool is a useful tool that can be used to play with these attributes.

The Security Manager in BLE is responsible for security procedures such as pairing, encryption, and signing. All connections start from a “no security” mode (no pairing), and when they want to exchange data in a secure way, they need to pair. The pairing procedure involves the exchange of a Temporary Key (TK) to generate a Short-Term Key (STK), which is used to encrypt the connection link. The security of the whole communication highly depends on how this TK is exchanged. There are four association models (for BLE 4.2) and choosing one or another depends on the input/output capabilities of the devices (information that is exchanged in clear text). We’ve sorted them from most insecure to most secure:

Association models (1-3) are known as LE Legacy Pairing and should be avoided due to their lack of security.

1. Just works: This model is for devices that do not have a display, such as headphones or speakers (therefore, this method is probably the most popular for BLE <4.2 devices). TK is set to zero, so eavesdropping and Man-in-the-Middle (MiTM) attacks are possible by easily calculating STK.
2. Passkey: This model is for devices that typically have a display (although there are some exceptions). One device displays a randomly generated 6-digit TK, and the other asks for it. If the devices have no display, the user needs to enter the same TK in both. This method provides some protection against eavesdropping and MITM attacks; however, as TK is easily brute-forceable, the overall security is very poor.
3. Out-of-Band (OOB): This model is for devices that have alternative communication technology, such as NFC, which can be used to exchange cryptographic information. This method provides decent security protection if the alternative channel is secure. In this case, TK may not be easily brute-forceable because no human interaction is needed, so the TK generated in this method can be longer (up to 128 bits) and more complex.

Association model (4) is the most secure and known as LE Secure Connections (introduced in BLE 4.2). The main difference in this model is that, instead of using TK and STK, these association models use a Long-Term Key (LTK) to encrypt the connection link and public key cryptography (specifically the Elliptic Curve Diffie Hellman algorithm) is used to exchange the LTK. This improvement protects against eavesdropping attacks, but not against MitM attacks.

1. Numeric Comparison: This model provides the best security without affecting the user experience too much. So, it’s the recommended one when designing a BLE device or application. When using this model, both devices exchange their public ECDH key, and generate independently one random 128-bit nonce for each peer to provide protection against replay attacks. Then, these nonces are exchanged (using the ECDH keys, to avoid eavesdropping attacks) and checked using a Confirm Value Generation function. Finally, both devices independently calculate a six-digit number using the exchanged public keys and nonces and show it using the display. At this point, the user is expected to check them and confirm (with a “yes” or “no”) that both numbers match. Matching numbers means that no MitM attack was performed, so the connection link can be securely encrypted. If the numbers do not match and the user selects “no”, the pairing process fails, thus protecting the user.

In conclusion, the main and difficult goal of all association models listed above is to securely exchange a key between two devices which don’t have an established connection. The big advantage is that usually both devices have a human between them.

Next is the Logical Link Control & Adaptation Protocol (L2CAP) layer, which is responsible for multiplexing, segmentation and reassembly, logical connection establishment, and flow control. It is equivalent to IP in the TCP/IP stack.

Finally, we have the link layer, which is responsible for scanning, advertising, and creating connections, and interacts directly with the physical layer that converts the bits to RF. These two layers are implemented by hardware in the Bluetooth chip. All the others are implemented by software in the device.

Pen Testing BLE Connections

What about its security? BLE is just a technology; so, the responsibility of BLE security between two devices relies on the implementation applied by the manufacturer.

When you have full control of at least one device:

The easiest way to pen test BLE devices is using the Host-Controller Interface (HCI). As said before, the Host layers are implemented by software, and the Controller layers are implemented by hardware. The Bluetooth HCI specifies all interactions between them, and these interactions can be logged. No additional hardware is needed.

Logging HCI events and commands is very easy, especially on Android, Linux, and OS X systems:

• Android: Does not require root nor additional applications. There is already an option under the “Developer Options” called “Enable Bluetooth HCI snoop log”. Once enabled this option, the smartphone will start logging to a file all traffic going through HCI.
• Linux: The “btmon” tool is used for logging HCI events and commands to a file.
• OS X: The additional tool for XCode, called “PacketLogger”, is used for logging this traffic.

The logging applications generate BTsnoop-formatted files, which are not plain text. However, they can easily be loaded into Wireshark. The following Wireshark filters are useful for analyzing BLE traffic:

• btatt: Shows ATT packets, which content the data sent and received by the application.
• bthci_cmd.le_long_term_key: Shows the long term key for BLE encryption. Not finding these bytes in the captured traffic means that the connection is not BLE encrypted (but could be encrypted at the application layer).

For Bluetooth Classic:

• bthci_cmd.link_key: Shows the link key used to encrypt the Bluetooth connection. Not finding these bytes in the captured traffic means that the connection is not BLE encrypted (but it could be encrypted at the application layer).

Logging is always easier than sniffing and should be used whenever possible.

When you do not have full control of any device:

For example, when you want to analyze BLE traffic between a wireless game controller and its game console. Typically, we have three options in this scenario:

• Pair the game controller to another device that you can fully control and log the traffic (not always possible).
• Get full control in the game console and log the traffic (not always possible).
• Sniff communications without having full control of any device.

The last option usually requires additional hardware, such as the BBC MicroBit, the BlueFruit, or the Ubertooth. However, these devices are not reliable, and they lose packets, even when a connection was already caught.

Additionally, each of these devices can listen only on one BLE channel. Because the BLE spectrum has three advertisement channels, the probability of catching a connection by using one device would be 33.33%. Using two devices, the  would be 66.66%. And using three devices (one per advertisement channel), the probability would be 100%.

The software usually used for sniffing is BTLE Jack, which automatically all the difficulties caused by the frequency hopping mechanism applied in BLE.

For more professional tasks, the company Ellisys sells very good and reliable devices used for Bluetooth sniffing, such as the Bluetooth Explorer or the Bluetooth Vanguard. However, prices are much higher than the MicroBit or the BlueFruit.

In conclusion, for most pen testing projects, it is enough to log the traffic using the Host-Controller Interface. In case the consultant does not have full control over any device, one BBC MicroBit (or similar sniffing tool) should be enough. However, they will need to repeat the process if the device loses packets.

MitM

When logging or sniffing is not enough and modifying the traffic is required, we typically use two attack vectors:

• Hook functions on a fully controlled device (using Frida, for example).
• Perform a Man-in-the-Middle (MitM) attack at network level.

Nowadays, some vendors apply heavy obfuscation to their application’s code, making it very difficult for a reverse-engineer to understand. Additionally, pen tests are almost always time-boxed, so the first option usually becomes infeasible when the code is obfuscated.

However, using just a laptop and two BLE dongles, MitM attacks can be performed without needing any kind of analysis of the firmware or the mobile application. So, code obfuscation does not protect against the second attack vector.

Tools like gattacker and BTLE Juice already take care of all the BLE protocol phases and features to allow MitM and relay attacks. These tools are very flexible and are great for discovering new flaws in applications or in the BLE protocol itself.

For example, an attacker could use the tool gattacker to MitM a connection between two devices during the pairing phase and modify the traffic to trick the devices into a more insecure association model.

Conclusion

I highly encourage you to start looking into BLE and IoT devices. A lot of IoT vendors are still applying very weak security (if any) to their devices, which is equivalent to the same security as computers in the 90’s. And as shown above, you may already have the hardware (if not, you just need less than $100).