BLUFFS Attack: How Bluetooth’s Legacy Security Enables Forward Future Exploits

This article analyzes the BLUFFS vulnerability disclosed at ACM CCS 2023, detailing how the legacy Bluetooth security mechanism (LSC) allows attackers to manipulate authentication and key‑generation parameters, leading to forward‑secrecy and future‑secrecy breaches, and evaluates the impact across devices supporting Bluetooth 4.2‑5.4.

OPPO Amber Lab
OPPO Amber Lab
OPPO Amber Lab
BLUFFS Attack: How Bluetooth’s Legacy Security Enables Forward Future Exploits

1. Introduction

On November 28, 2023, at the ACM CCS 2023 conference, Daniele Antonioli from EURECOM presented the paper BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses , which describes a Bluetooth protocol‑level vulnerability (CVE‑2023‑24023) affecting devices using Bluetooth 4.2 to 5.4. This article analyzes the cause, impact range, and severity of the vulnerability.

2. Technical Background

2.1 Bluetooth Security Features

The Bluetooth security model includes five features: Pairing, Bonding, Device Authentication, Encryption, and Message Integrity.

Pairing : creates one or more shared keys.

Bonding : stores the keys generated during pairing for future connections.

Device Authentication : verifies that both devices share the same key.

Encryption : protects confidentiality of messages.

Message Integrity : prevents tampering and forgery.

Pairing generates a Link Key (LK), which may be temporary or semi‑permanent. In this article, LK is treated as a semi‑permanent key.

Bluetooth specifications (v5.3) are used as a reference for the analysis.

2.1.1 Legacy Secure Connections (LSC)

LSC devices follow five stages before transmitting data: initialization key generation, Link Key generation, LK exchange, device authentication, and Session Key (SK) generation. The initialization key K init is derived from a PIN and a shared random number using the E2 algorithm (based on SAFER+). The Link Key K link is then derived from K init and used for authentication.

Device authentication involves a Claimant and a Verifier exchanging a 128‑bit random number (AU_RAND) and computing a 128‑bit response; the most significant 32 bits (SRES) are used for verification.

After successful authentication, both sides generate a random EN_RAND, combine it with the Link Key, COF (derived from the authentication step), and use algorithm E3 to derive the encryption key K c (the Session Key). The key length can be negotiated from 1 to 16 bytes, but after the KNOB vulnerability was mitigated, the minimum length is 7 bytes. The final encryption/decryption uses algorithm E0.

2.1.2 Secure Connections (SC)

SC follows the same three phases (Link Key generation, device authentication, Session Key generation) as SSP, but uses different algorithms (e.g., ECDH for key exchange). SC supports four association models: Numeric Comparison, Passkey Entry, Just Works, and Out‑of‑Band. In this article, we focus on the model that requires Link Key verification.

3. BLUFFS Overview

BLUFFS targets the LSC authentication and encryption phases. The vulnerability lies in the Session Key generation: the SK can be reused across sessions, allowing an attacker who obtains the SK to decrypt past and future communications.

3.1 Vulnerability Description

An attacker (Charlie) can impersonate a previously paired device (Alice) by using Alice’s MAC address. By assuming the Central role, Charlie controls the parameters AC A , SE A , and SD A used to derive the SK, even without knowing the stored Pair Key (PK). Charlie can force the SK length to the minimum (7 bytes), making offline brute‑force attacks feasible.

Once the SK is cracked, Charlie can:

Impersonate Alice to communicate with Bob (cases A1‑A2).

Perform a man‑in‑the‑middle attack, decrypting and re‑encrypting traffic between Alice and Bob (cases A3‑A6).

3.1.1 Device Impersonation

Charlie uses Alice’s MAC to connect to Bob, drives the authentication and SK generation, and then cracks the SK (often 7 bytes). After cracking, Charlie can repeatedly generate the same SK, allowing persistent impersonation.

3.1.2 Man‑in‑the‑Middle Attack

Charlie uses two devices, each impersonating one side of the communication, to obtain two distinct SKs (SK A and SK B ). After cracking both, Charlie decrypts traffic from Alice, re‑encrypts it with Bob’s SK, and forwards it, achieving full interception and modification.

3.2 Impact

If both devices support SC, the attack fails because SC requires mutual verification. Experiments show that devices supporting only LSC are vulnerable, while those supporting SC resist the attack, except for a few chipsets with implementation flaws.

4. Root Causes

LSC’s authentication and SK generation are centrally controlled, allowing a malicious Central to dictate parameters.

Parameters used for SK generation are not truly random and can be reused, enabling forward and future secrecy breaches.

SK‑generation parameters are not integrity‑protected, permitting tampering.

Downgrading from SC to LSC occurs without authentication, facilitating attacks.

5. Conclusion

The BLUFFS vulnerability exploits weaknesses in the legacy LSC security mechanism implemented in Bluetooth controllers. While the impact is high when one device only supports LSC, most modern devices support both LSC and SC, limiting practical exploitation. Mitigations include enforcing longer encryption keys and preferring SC where possible.

securityBluetoothVulnerabilityProtocolcryptographyLSCSC
OPPO Amber Lab
Written by

OPPO Amber Lab

Centered on user data security and privacy, we conduct research and open our tech capabilities to developers, building an information‑security fortress for partners and users and safeguarding OPPO device security.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.