BlueTrust, goodbye to Bluetooth privacy

BlueTrust is the name of a new technique developed by Tarlogic that makes it possible to discover trust relationships between Bluetooth devices to obtain data of interest about their users.

We continue with the series of research articles on Bluetooth technology and the existing attacks on this protocol. Previously, the BIAS and BLESA attacks (introduction to BIAS and BLESA attacks); and KNOB and BLURtooth (KNOB and BLURtooth attacks) were analysed theoretically.

This article presents how to reproduce and implement BIAS and KNOB attacks. As one might expect, the leap from the academic (and theoretical) world to the real (and practical) world is neither immediate nor straightforward. The main problems and obstacles encountered and how they have been overcome will be presented throughout the article.

Following the study of Bluetooth attacks and the detailed analysis of how the standard works, a privacy problem has been discovered in the standard, which has been given the name BlueTrust.

Bluetooth is a communication standard for short-range connections, typically between mobile devices and low-power devices, which is commonly used as a low-power alternative for personal area networks (PAN).

BlueTrust and protocol security flaws

While efforts have been made to ensure the security of the protocol as much as possible, over the years new attacks have emerged that have exposed security flaws at the standard and protocol implementation level.

The impact of these last attacks is uneven, since an implementation problem is associated with a particular manufacturer or device and, in many cases, can be remedied with some kind of update. In contrast, vulnerabilities that affect the standard impact all devices that work with that version of Bluetooth, so their impact is more relevant and critical.

Among the most recent attacks affecting the definition of the standard, BIAS and KNOB stand out. Both have been published by Daniele Antonioli‘s team at the Federal Polytechnic School of Lausanne. While it is true that the media coverage of these attacks has been very pronounced, it is quite difficult to find news or records of actual implementations of these attacks. The reason is the difficulty and effort required to properly implement the attacks in the real world.

This article presents BlueTrust, the work of implementing and developing the theoretical attacks to bring them to a practical scenario and the conclusions that can be drawn from both the attacks implemented and the path followed to put them into action.

Before getting into the description and implementation of the attacks, it is necessary to highlight some characteristics of the Bluetooth protocols that make it a particular technology, and to talk about the protocols that are necessary to understand the BIAS and KNOB approach.

Bluetooth

Bluetooth has several physical channel selection approaches to perform communications between two devices. Two of the existing techniques are: Adaptive Frequency Hopping (frequency hopping) and the division into Time Slots (time blocks). With the first technique, the information is segmented in a special way (changing channel/frequency in the spectrum). With the second technique, the information is segmented temporally.

With these techniques, the bandwidth of your connections is extended and interference is avoided. While it is true that intrinsically these techniques offer an extra layer of protection by making it very difficult for a third party to listen in on the transferred messages and protect against the injection of false messages into communications, they make it very difficult to carry out investigations and attacks on Bluetooth.

Although it’s possible to monitor all Bluetooth channels simultaneously, this is too costly for viable and replicable attacks, and requires reconstructing the message sequences exchanged between endpoints.

In general, Bluetooth is a complex technology, with multiple interacting protocols documented in a standard (Bluetooth Core Specification), which is thousands of pages long and difficult to understand – a major barrier to entry when assessing the security of the technology.

The first division in the standard is the differentiation between Bluetooth BR/EDR (Basic Rate / Extended Data Rate) and BLE (Bluetooth Low Energy). The first variant, known commercially as Bluetooth Classic, occupies a higher bandwidth and consumes more energy, which is why BLE was developed, which is adapted to smaller devices with lower power consumption. BIAS and KNOB affect the Bluetooth BR/EDR or classic protocols.

The Bluetooth architecture splits the protocol stack between the host and the controller.

• The host consists of the device that requires Bluetooth functionality, i.e. the PC, mobile phone or headset, and manages the higher layers of the Bluetooth stack, usually implemented as a driver in the device’s operating system. The driver is the hardware directly connected to the Bluetooth antenna, which controls the lower layers of the stack.
• The controller can be integrated in the host electronics or implemented as a separate module, and contains in its firmware the implementation of Bluetooth BR/EDR, BLE or both.

Host and controller communicate through the Host-Controller Interface (HCI) protocol, which allows the host, programmed by its user, to tell the controller which procedures to execute. The HCI messages limit the actions that can be carried out from the host and the degree of control that a Bluetooth programmer has.

On the other hand, among the different protocols of the Bluetooth BR/EDR stack, LMP is the control protocol, which establishes connections between devices, negotiates security keys and executes authentication procedures, as well as changes in the encryption of a connection. LMP is part of Bluetooth BR/EDR (BLE uses other protocols) and is implemented in the driver, so in general the host user has no control over it.

These two protocols control the processes targeted by the BIAS and KNOB attacks, so where each is located affects the implementation of the attacks.

BIAS and KNOB

From the study of the state of the art of Bluetooth security, BIAS and KNOB stand out. These are vulnerabilities focused on the Bluetooth standard and do not look for flaws in manufacturer-dependent implementations. This approach gives them a remarkable impact, making them interesting objects of study.

The BIAS vulnerability proposes a method to bypass the authentication process of a Bluetooth connection. In combination with this vulnerability, KNOB proposes a method to reduce the security of the encryption of a connection and break the encryption key at runtime.

Both techniques used together present a complicated scenario for the technology because they initially promise the possibility of breaking all Bluetooth communications. However, as might be expected, the reality is more complex…

Although the vulnerabilities attack the Bluetooth specification, because they both modify the data flow of the LMP protocol, it is necessary to adjust the Bluetooth driver firmware to execute the proof-of-concept. Specifically, both publications make use of an undocumented and proprietary mechanism of an adapter manufacturer to download modifications to the original firmware, making proof-of-concepts dependent on a particular manufacturer.

Overcoming the entry barriers of studying the standard to understand the vulnerabilities in-depth and acquiring the appropriate hardware during electronic component shortages that have been affecting the industry for at least two years now, the tests performed reflect other, deeper complexities…

Although the proofs of concept show that these are feasible attacks, they are only feasible in controlled situations designed to be vulnerable. The attacks described appear to have no application in real-world scenarios where carrying out an attack is hugely more complex.

An example of this is discussed in the KNOB proof-of-concept, which talks about intercepting traffic, modifying a value in a plaintext packet to reduce the entropy of encryption keys and injecting it into the communication.

This scenario presents a major problem due to the design of Bluetooth, where each packet is transmitted on a different channel, making it difficult to listen in. To this problem we must add the difficulty of performing a selective jamming attack on that packet so that the receiver does not receive it correctly, not to mention the possibility of injecting a new packet on a different channel, with the new modified value.

To overcome these difficulties, the KNOB proof-of-concept modifies the firmware of one of the victims, making it also an attacker. This proves that the attack would be theoretically possible, but highlights the need to have control over the victim before performing the attack.

How we got to BlueTrust

BIAS and KNOB present difficulties in their implementation that make them impractical attacks for use in realistic auditing contexts. However, along the way at Tarlogic Security, modifications to the Bluetooth BR/EDR authentication processes have been identified that can be used in another context: intelligence gathering via Bluetooth. And it’s on this path that the BlueTrust technique has emerged.

In a normal connection process, executed in the driver firmware, the authentication process is not initiated unless there is a shared link key between the devices, and the most secure possible authentication procedure, with mutual authentication, is typically used.

Thanks to the proof of concept developed for BIAS, the authentication phase can be brought forward and executed despite the lack of a binding key. Daniele’s PoC also modifies the controller firmware to always use the classical authentication procedure as the master device, not requiring authentication to the slave device.

Using this procedure, along with others specific to Bluetooth operation, it is proposed to discover pairing information from nearby Bluetooth devices by sending an authentication request and observing the response. BIAS and KNOB present difficulties in their implementation that make them impractical attacks for use in realistic auditing contexts. However, along the way at Tarlogic, modifications to the Bluetooth BR/EDR authentication processes have been identified that can be used in another context: intelligence gathering via Bluetooth.

In a normal connection process, executed in the driver firmware, the authentication process is not initiated unless there is a shared link key between the devices, and the most secure possible authentication procedure, with mutual authentication, is typically used.

Thanks to the proof of concept developed for BIAS, the authentication phase can be brought forward and executed despite the lack of a binding key. Daniele’s PoC also modifies the controller firmware to always use the classical authentication procedure as the master device, not requiring authentication to the slave device.

Using this procedure, along with others inherent to Bluetooth operation, it’s proposed to discover pairing information from nearby Bluetooth devices by sending an authentication request and observing the response.

A device with a link key for the spoofed device will respond normally to an authentication request, while a device that does not have a key associated with the spoofed device will respond negatively or send no response message at all.

The approach can be extended to trace the pairing relationships of devices in range and infer useful information about their users, such as their Bluetooth device usage patterns.

Using the described methodology, a proof of concept called BluetTrust has been developed. This proof of concept has allowed the acquisition of a deep understanding of the operation of many Bluetooth tools, as well as the development of libraries that will allow future research to be carried out at a lower development cost.

The BlueTrust proof of concept incorporates scanning of nearby devices, automatic profiling and impersonation of profiled devices, as well as pairing discovery between devices.

Conclusions on BlueTrust

Bluetooth is a complex technology. This, in conjunction with extensive documentation, makes this technology a candidate for security by obscurantism. The barriers to entry into the study of Bluetooth security make it an unaffordable target and make it unattractive as it is too broad to be studied.

These factors, in addition to making it difficult to study, result in a lack of tools with a sufficient level of consolidation and maturity to provide clarity to potential researchers and those interested in Bluetooth security. Proof of this can be seen in the proofs of concept used to demonstrate the different vulnerabilities of the technology, where undocumented mechanisms specific to Bluetooth hardware manufacturers are commonly used.

Once these barriers to entry have been overcome, there is still a large part of the standard to be explored for security improvements. There are niches even within the explored areas where synergies between attacks and new approaches to existing vulnerabilities are not yet apparent.

BlueTrust is an example of a continuation of existing vulnerabilities. It involves work to improve existing tools and documentation of previous work. This effort leads to new possibilities not previously considered and facilitates future research.

This new proof of concept allows us to discover which Bluetooth devices are interconnected, which has very diverse applications from monitoring secure spaces to detecting intrusions in networks, detecting and locating devices associated to a person, collecting data on consumption habits…

In addition to these utilities and applications, BlueTrust paves a line of research and provides tools to continue the analysis of Bluetooth security, where there is still much room for exploration. At Tarlogic Security, we also intend that this research will result in functionality that we will integrate into our Acrylic Bluetooth LE Analyzer product.

Editor’s note

The logo and name of this vulnerability have been generated by an AI.