The Tragedy Of Bluetooth Low Energy

Linfeng Xiao (Xiaomi), Dalin Yang (Xiaomi)

HITBSecConf2023 - Phuket · Day 2 · CommSec Track

Overview

In "The Tragedy Of Bluetooth Low Energy," Linfeng Xiao and Dalin Yang from the Xiaomi security team unveil a series of critical vulnerabilities impacting Bluetooth Low Energy (BLE) implementations, ranging from application-layer flaws in smart devices to sophisticated link-layer attacks bypassing established security mechanisms. Their presentation demonstrates that despite BLE's inherent complexity and designed-in security features like frequency hopping and link-layer encryption, real-world implementations often fall short, exposing users to significant risks. The talk highlights three distinct attack vectors: a replay attack on smart locks, a link-layer hijacking of BLE barcode scanners, and a novel controller-level relay attack against car keyless entry systems.

Watch on YouTube

Visual summary for The Tragedy Of Bluetooth Low Energy by Linfeng Xiao, Dalin Yang
Visual summary for The Tragedy Of Bluetooth Low Energy by Linfeng Xiao, Dalin Yang

Key moments

  1. 0:49 Bicycle lock replay attack (timestamp manipulation)
  2. 6:00 Barcode scanner payment theft via BLE link hijack
  3. 16:00 BLE controller relay attack for car key systems
  4. 22:00 Live demo: unlocking a car using BLE relay
  5. 27:00 Introducing custom BLE security analysis tools
  6. 32:00 BLE security defense strategies and future plans
  7. 34:00 Q&A: Confirming open-source plans for the tools

The Tragedy Of Bluetooth Low Energy

Speakers: Linfeng Xiao, Security Researcher, Xiaomi; Dalin Yang, Security Researcher, Xiaomi

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=hpzmUN1OVBU

Overview

In "The Tragedy Of Bluetooth Low Energy," Linfeng Xiao and Dalin Yang from the Xiaomi security team unveil a series of critical vulnerabilities impacting Bluetooth Low Energy (BLE) implementations, ranging from application-layer flaws in smart devices to sophisticated link-layer attacks bypassing established security mechanisms. Their presentation demonstrates that despite BLE's inherent complexity and designed-in security features like frequency hopping and link-layer encryption, real-world implementations often fall short, exposing users to significant risks. The talk highlights three distinct attack vectors: a replay attack on smart locks, a link-layer hijacking of BLE barcode scanners, and a novel controller-level relay attack against car keyless entry systems.

The speakers systematically dissect the BLE protocol stack, exposing vulnerabilities at both the application and link layers. They not only detail the theoretical underpinnings of these exploits but also provide compelling proof-of-concept demonstrations, showcasing how attackers can bypass authentication, steal credentials, and even unlock vehicles. Beyond merely identifying flaws, the Xiaomi team introduces a comprehensive, portable toolkit designed to assist security researchers and engineers in evaluating and defending against such advanced BLE threats, emphasizing the urgent need for robust security practices in an increasingly interconnected smart device ecosystem.

This article delves into the technical intricacies of these attacks, the methodologies employed by the researchers, and the critical defensive implications for manufacturers and users of BLE-enabled devices. It serves as a stark reminder that the promise of secure wireless communication hinges not just on protocol design, but on diligent and secure implementation across the entire stack.

Background

▶ Watch: Bicycle lock replay attack (timestamp manipulation) (0:49)

Bluetooth Low Energy (BLE) is a wireless personal area network technology designed for short-range communication, primarily used in applications requiring low power consumption. It underpins a vast array of smart devices, from fitness trackers and medical sensors to smart home devices and automotive systems. At its core, BLE communication is structured around the Generic Attribute Profile (GATT), which defines how two BLE devices transfer data. A GATT server hosts multiple services, each containing characteristics that represent specific data points or controls. Master devices can read and write to these characteristics, while slave devices can send data via notify or indicate mechanisms, provided the master has subscribed.

The BLE protocol is often perceived as inherently secure due to features like its complex frequency hopping mechanism, which rapidly changes communication channels, making eavesdropping difficult. Unlike conventional radios such as Wi-Fi (fixed frequency bands) or older car remote controls (fixed MHz bands), BLE employs an Adaptive Frequency Hopping (AFH) algorithm across 37 data channels. Furthermore, BLE's link layer is designed to provide security through mechanisms like authentication and encryption, handled by the Security Manager Protocol (SMP). This layered approach is intended to make attacks like simple signal amplification or replay difficult, especially when compared to simpler protocols that lack sophisticated link-layer designs or robust authentication.

However, the talk illustrates that despite these design considerations, vulnerabilities can emerge from several sources:

  1. Application Layer Flaws: Incorrect implementation of security logic at the application level, failing to properly utilize or extend the underlying BLE security features.
  2. Link Layer Exploitation: Identifying and leveraging weaknesses in the complex frequency hopping or connection management processes to hijack active communication.
  3. Bypassing Defensive Mechanisms: Developing novel attack vectors that circumvent existing security measures, such as traditional relay attack countermeasures, by operating at a deeper protocol layer (e.g., controller layer).

The speakers' research highlights that the "tragedy" of BLE lies in the gap between its robust theoretical design and the practical realities of diverse and often flawed implementations, creating an expansive attack surface for determined adversaries.

Key Findings

▶ Watch: BLE controller relay attack for car key systems (16:00)

The Xiaomi security team presented three distinct yet interconnected key findings, each demonstrating a critical vulnerability within different layers of the BLE ecosystem:

  1. Application Layer Replay Attack on Smart Locks: This finding exposed a fundamental flaw in how certain smart locks handle command timestamps and synchronization. Despite using HMAC-SHA1 for signature verification and checking command timestamps, an attacker could force a lock to resynchronize its internal clock. By hijacking and replaying a specific "refresh timestamp" command (0840) followed by a captured "unlock" command (0150), attackers could bypass the intended security measures and unlock devices at will, effectively rendering the timestamp and signature checks useless against a sophisticated replay.
  1. BLE Link Layer Hijacking for Payment Credential Theft: The researchers demonstrated a highly technical attack against BLE barcode scanners, where the vulnerability lay not in the application layer, but directly within the BLE link layer itself. By meticulously sniffing and calculating all the complex connection parameters (including Access Address, CRC Init Value, Channel Map, Connection Interval, and Hop Parameter), attackers could accurately predict BLE's frequency hopping sequence. Once tracked, they could induce a supervision timeout by interfering with the slave device's responses, causing the master device to disconnect. This allowed the attacker to seize control of the link and intercept sensitive information, such as payment credentials, directly from the device's communication stream.
  1. BLE Controller Relay Attack Bypassing Traditional Defenses: This was perhaps the most sophisticated finding, demonstrating a novel relay attack against car keyless entry systems. Traditional BLE relay defenses often focus on the GAP layer or rely on tight timing windows that physical signal amplification struggles to meet due to latency. The Xiaomi team's breakthrough was performing a link layer relay, where instead of simply amplifying signals, they established two separate, full BLE link-layer connections (one with the legitimate device, one with the target). They then selectively relayed only the essential Link Layer PDU (LL_PDU) data, discarding physical layer parameters like the Access Address. This method effectively bypassed TCP/IP latency issues and supervision timeouts, allowing them to relay commands over extended distances and unlock vehicles, proving that even with encryption, the fundamental relay problem persists if not addressed at the controller level.

These findings collectively illustrate the pervasive "tragedy" of BLE: even with robust protocol designs, implementation oversights, or the failure to anticipate advanced attack vectors, can leave a wide range of smart devices vulnerable to exploitation.

Technical Deep Dive

▶ Watch: Live demo: unlocking a car using BLE relay (22:00)

The technical deep dive into the "Tragedy of Bluetooth Low Energy" unravels the sophisticated methodologies employed by the Xiaomi security team to exploit vulnerabilities across different layers of the BLE stack.

Application Layer Replay: The Smart Lock Conundrum

The smart lock attack highlights a critical flaw in application-layer logic, specifically concerning time synchronization and command validation. When an app sends an unlock command, it's typically a 0150 command, bundled with a timestamp and signed with an HMAC-SHA1 calculation. The lock is designed to verify this signature and check if the timestamp is within an acceptable range of its internal clock. If the time difference is too large, the command should be discarded.

However, the researchers discovered a critical interaction: if the lock's internal time significantly deviates from the app's time, the app initiates a synchronization process by sending an 0840 command to refresh the lock's timestamp. This mechanism, intended for usability, becomes an attack vector. The attack sequence is as follows:

  1. An attacker first hijacks the unlock command, making the app believe its time is not synchronized with the lock.
  2. The app then sends the 0840 refresh command, which the attacker captures.
  3. The attacker then resends the captured 0840 command to the lock, forcing the lock to synchronize its time with a time dictated by the attacker (or simply to accept a new reference point).
  4. Immediately after, the attacker resends a previously captured 0150 unlock command. Because the lock's time has just been "refreshed" (or reset in a way that aligns with the captured command's timestamp), the signature and timestamp checks now pass, successfully unlocking the device.

This attack demonstrates that even with cryptographic signatures (HMAC-SHA1) and timestamp verification in place, a poorly designed synchronization mechanism at the application layer can undermine the entire security model, allowing for simple replay attacks.

Link Layer Hijacking: Barcode Scanner Credential Theft

This attack targets the core of BLE's communication—the link layer—by exploiting the complexity of its Adaptive Frequency Hopping (AFH). Unlike simpler radio protocols, BLE's frequency hopping is highly dynamic, making it challenging to track and intercept. To hijack an established BLE link, an attacker needs to precisely predict the hopping sequence. This requires obtaining several critical parameters from the initial connection packets:

  1. Access Address: A 32-bit value unique to each BLE connection, acting as a primary identifier. It can be obtained by sniffing over-the-air packets.
  2. CRC Init Value: Used for subsequent Cyclic Redundancy Check (CRC) calculations. This can be derived by acquiring empty packets and performing inverse operations.
  3. Channel Map: A 37-bit mask indicating which of the 37 data channels are used for communication. Obtaining this is time-consuming: an attacker must listen on each possible frequency band for approximately 4 seconds. If the Access Address characteristic is detected, that channel is marked as active. This process takes a total of 48 seconds to acquire the complete channel map.
  4. Connection Interval: Defines the interval between frequency hops. To calculate this, the attacker needs to understand the Channel Selection Algorithm (e.g., Algorithm 1: FN+1 = (FN + Hop Parameter) mod 37). By finding a suitable channel, listening for the interval between two data packets, and dividing it by 37 (the number of channels), the Connection Interval can be deduced.
  5. Hop Parameter: This parameter determines how many channels to jump for the next hop. Its range is small (typically 5 to 16), allowing for brute-force discovery once other parameters are known.

Once all these parameters are obtained, the attacker can accurately track the BLE frequency hopping. The hijacking mechanism then leverages a Supervision Timeout. By repeatedly interfering with the data returned by the slave device, the master device eventually perceives the slave as having disappeared. The master then actively sends a termination command to disconnect the link. At this point, the attacker can take advantage of the disconnection to establish their own malicious link or intercept further communications, as demonstrated by stealing payment credentials from a barcode scanner.

Controller Relay Attack: Car Keyless Entry Bypass

The most advanced attack presented targets car keyless entry systems, overcoming the limitations of traditional relay attacks. Previous GAP layer relay tools often failed against modern BLE implementations due to the protocol's tight timing windows and the latency introduced by relaying signals over distances (e.g., via TCP/IP). A simple physical layer relay that amplifies signals across TCP/IP fails because the central device, upon sending a request on Channel 8, quickly hops to Channel 25 for the next communication. Due to TCP/IP latency, the peripheral's response might return after the central device has already hopped, causing a supervision timeout and connection failure.

The Xiaomi team's innovation is a BLE Link Layer Relay. The key insight is that the entire data structure transmitted on the physical channel contains both physical layer parameters (like Access Address, CRC Init) and the actual host layer communication data within the Link Layer PDU (LL_PDU). The physical layer parameters are for maintaining the link, while the LL_PDU carries the actual application data.

The refined relay technique works as follows:

  1. Separate Connections: The relay device establishes two independent, complete BLE link layer connections: one with the legitimate central device (e.g., the car owner's key) and another with the target peripheral device (e.g., the car itself).
  2. Selective PDU Relay: Instead of relaying the entire physical layer packet, the relay only forwards the LL_PDUs (which can be Link Layer Control PDUs or Link Layer Data PDUs). Physical layer specific parameters like Access Address and CRC Init are discarded.
  3. Empty Package Filling: To maintain the separate connections and avoid supervision timeouts, the relay uses empty packages to fill each connection interval on both sides when there's no actual interaction data to relay. This ensures both devices remain connected and do not time out due to the relay's latency.
  4. Encryption Handling: A specific challenge arises when a link becomes encrypted, as Link Layer Data Packages are then encrypted, making it impossible to pass their content or track channel changes if the hopping also changes. To counter this, the attackers proactively switch to a fixed 52 channel before link encryption occurs. This strategy ensures the channel remains fixed, avoiding the impact of hopping on tracking once encryption is established.

This method effectively decouples the physical layer timing constraints from the logical link layer communication, allowing the LL_PDUs to be relayed over potentially long distances without triggering supervision timeouts, thus enabling the bypass of keyless entry systems.

Demo / Proof of Concept

▶ Watch: BLE security defense strategies and future plans (32:00)

The talk included compelling demonstrations for each of the identified vulnerabilities, providing concrete proof of concept for the theoretical attacks.

For the Smart Lock Application Layer Replay Attack, the speakers showed a three-step process:

  1. A normal, legitimate unlock of a smart lock using an app.
  2. An attempt to simply replay a captured unlock command, which failed due to the timestamp and signature checks.
  3. The successful execution of the replay attack: capturing the 0840 refresh command, replaying it to synchronize the lock's time, and then replaying the 0150 unlock command, leading to the successful unlocking of the device.

The BLE Link Layer Hijacking for Barcode Scanners was demonstrated by showing the process of first hijacking the BLE frequency hopping information. This involved capturing the necessary connection parameters. Once the hopping sequence was predictable, the attackers successfully hijacked the barcode scanner's communication link, ultimately revealing that they had obtained the desired payment credentials.

The most visually impactful demonstration was for the BLE Controller Relay Attack against Car Keyless Entry systems. The demo scenario involved:

  1. The car owner locking their vehicle and walking a significant distance away, rendering their key out of range.
  2. A first attacker positioning themselves near the owner (and their key fob).
  3. A second attacker positioning themselves near the car.
  4. Through the relay setup, the second attacker was able to successfully open the car, demonstrating the complete bypass of the physical distance limitation and the car's security system. The implication was that the car could then be driven away.

Beyond these specific attack demonstrations, the Xiaomi team also showcased their comprehensive BLE security testing tool. This tool integrates multiple functionalities, including:

  • Link Layer Relay
  • Controller Hijack
  • Sniffer
  • Fake Package generation
  • Identification of non-standard UUID services of GATT.

The tool is designed as a mobile terminal device, battery-powered, with a touchscreen interface, making it highly portable for field assessments. Its hardware architecture is modular, combining a Raspberry Pi, an NFRF51822 dongle, a TI CC2652 module, and an RT USB dongle for network connectivity. The software environment utilizes Python with QT for the user interface, alongside modified BLE protocol stacks (BL models). The demonstration video of the tool highlighted its BLE relay capabilities, showing data transmission between a master and slave device being relayed over a TCP socket. The speakers confirmed their intention to open-source both the software and hardware designs of this tool on GitHub, further contributing to the BLE security research community.

Defensive Implications

▶ Watch: Q&A: Confirming open-source plans for the tools (34:00)

The research presented by Linfeng Xiao and Dalin Yang carries significant defensive implications for manufacturers and users of BLE-enabled devices. It underscores that relying solely on built-in BLE protocol security features or superficial application-layer checks is insufficient.

A critical finding in the defensive analysis was the ineffectiveness of certain proposed anti-relay mechanisms against their advanced link layer relay attack. For example, some manufacturers, like NXP, have implemented methods to reduce the transmission time of interactive data over the air to as little as 3.6 microseconds. While this might deter traditional relay attacks that rely on simple signal amplification, the Xiaomi team demonstrated that it is ineffective against their link layer relay. This is because their method establishes a complete link layer connection on each side, meaning each data transfer is not affected by microsecond-level over-the-air transmission times. Instead, the critical factor becomes the network delay (e.g., TCP/IP latency) between the two relay points, which is overcome by selectively relaying only the LL_PDUs and filling connection intervals with empty packages. This highlights that defenses must address the controller layer, not just the physical transmission timing.

General defensive measures that should be adopted or strengthened:

  1. Robust Link Layer Encryption: While the relay attack demonstrated bypasses, proper BLE link layer encryption (managed by SMP) remains fundamental. It prevents passive sniffing of data and is the first line of defense against many attacks. Manufacturers should ensure it is correctly implemented and enforced.
  2. Dynamic Link Layer Transmission Parameters: Updating link layer transmission parameters frequently can make it harder for attackers to sniff and track the connection, though this is not a foolproof solution against determined link-layer hijackers.
  3. "More Data" (Fragmentation): Configuring the "More Data" function for packet transmission can make sniffing more difficult by fragmenting data across multiple packets, similar to TCP fragmentation.
  4. Multi-Model BLE Implementations: In complex systems like cars, using multiple Bluetooth models to assist in making connections might reduce certain security risks, but as the relay attack showed, it doesn't eliminate the possibility of sophisticated link-layer attacks if the underlying protocol stack is still vulnerable.
  5. Strengthened GATT Layer Defenses (SMP): The Security Manager Protocol (SMP) is crucial for handling authentication, encryption, and key management between BLE devices. Manufacturers must:
  • Implement strong authentication mechanisms to prevent unauthorized connections.
  • Ensure robust key management practices for encryption keys.
  • Encrypt all important service data before transmission, even if the link layer is encrypted, as an additional layer of defense against potential decryption or side-channel attacks.
  • Strictly control read and write permissions for UUIDs to prevent unauthorized access or manipulation of sensitive characteristics.
  1. Application-Layer Logic Review: For issues like the smart lock vulnerability, developers must critically review their application-layer security logic. This includes:
  • Implementing stronger timestamp validation that cannot be easily reset or influenced by an attacker.
  • Using non-replayable nonces or challenge-response mechanisms for critical commands, instead of relying solely on timestamps and static signatures, to prevent replay attacks.
  • Ensuring that synchronization mechanisms are themselves secured and authenticated.
  1. Continuous Security Assessment: The development of tools like the one presented by Xiaomi underscores the need for continuous, in-depth security evaluations of BLE products. Manufacturers should use such tools to identify and remediate vulnerabilities proactively, including fuzzing, GATT service fuzzing, and historical CVE inspection.

Ultimately, defending against the "Tragedy of Bluetooth Low Energy" requires a holistic approach, addressing vulnerabilities from the application layer down to the controller, and acknowledging that sophisticated attackers will always seek to exploit the weakest link.

Key Takeaways

  • Application-Layer Logic Flaws Undermine Core Security: Even with cryptographic signatures (HMAC-SHA1) and timestamp checks, design flaws in application-layer synchronization mechanisms (e.g., the 0840 refresh command) can enable simple replay attacks, rendering intended security measures ineffective.
  • BLE Link Layer is a Complex Attack Surface: Despite its sophisticated frequency hopping, an attacker can precisely predict and hijack a BLE link by meticulously sniffing and calculating connection parameters like Access Address, CRC Init Value, Channel Map, Connection Interval, and Hop Parameter, leading to data interception and credential theft.
  • Novel Controller-Layer Relay Bypasses Traditional Defenses: The demonstrated Link Layer PDU (LL_PDU) relay attack circumvents existing anti-relay measures (like NXP's microsecond-level timing windows) by establishing separate, complete link-layer connections and selectively relaying only the essential data, proving that physical distance limitations can be overcome for devices like keyless entry systems.
  • Comprehensive Tooling is Essential for BLE Security Assessment: The Xiaomi team's open-source security tool, integrating functions like link layer relay, controller hijack, sniffing, and fuzzing, is vital for researchers and engineers to proactively identify and mitigate complex BLE vulnerabilities across the entire stack.
  • Multi-Layered Defense is Imperative: Effective BLE security requires a multi-faceted approach, combining robust Link Layer Encryption with strong GATT Layer (SMP) authentication, secure key management, vigilant application-layer design, and continuous security assessments to counter evolving threats.

About the Speaker(s)

Linfeng Xiao and Dalin Yang are key members of the Xiaomi security team. Their work is dedicated to researching advanced security technologies, developing automated security platforms, and conducting security assessments and protection for smart devices. The team has a strong track record, having participated in and won multiple awards at prestigious security events such as GeekPwn, TM Cup, and Baidu Cup, demonstrating their expertise in identifying and exploiting complex vulnerabilities in modern technologies.

Reviews

Dr. Zero (Offensive Security Researcher) — STRONG ACCEPT

Solid offensive BLE research with three distinct attack classes demonstrated end-to-end. The link-layer hijacking and controller relay work show real depth—this isn't repackaged 2019 content. Loses a star because the app-layer replay is table stakes and the defense section is thin, but the core research is legit.

Heather Calloway (CISO) — SOLID

Solid offensive BLE research demonstrating three distinct attack classes across the protocol stack. Worth knowing about if you have smart locks, barcode scanners, or BLE-enabled vehicle fleets in your environment, but the strategic implications are narrow and the defenses are mostly things your team should already be doing.

→ Top-rated talks at HITBSecConf2023 - Phuket

All talks from HITBSecConf2023 - Phuket