BLUFFS: Bluetooth Forward and Future Secrecy Attacks andDefensesDaniele Antonioli
EURECOM
Sophia Antipolis, France
daniele.antonioli@eurecom.fr

ABSTRACTKEYWORDS

Bluetooth is a pervasive technology for wireless communication.
Billions of devices use it in sensitive applications and to exchange
private data. The security of Bluetooth depends on the Bluetoothstandard and its two security mechanisms: pairing and session establishment. No prior work, including the standard itself, analyzed
the future and forward secrecy guarantees of these mechanisms,
e.g., if Bluetooth pairing and session establishment defend pastand future sessions when the adversary compromises the current.
To address this gap, we present six novel attacks, defined as the
BLUFFS attacks, breaking Bluetooth sessions’ forward and future
secrecy. Our attacks enable device impersonation and machine-inthe-middle across sessions by only compromising one session key.
The attacks exploit two novel vulnerabilities that we uncover in theBluetooth standard related to unilateral and repeatable session key
derivation. As the attacks affect Bluetooth at the architectural level,
they are effective regardless of the victim’s hardware and software
details (e.g., chip, stack, version, and security mode).
We also release BLUFFS, a low-cost toolkit to perform and automatically check the effectiveness of our attacks. The toolkit employs
seven original patches to manipulate and monitor Bluetooth session
key derivation by dynamically patching a closed-source Bluetooth
firmware that we reverse-engineered. We show that our attacks
have a critical and large-scale impact on the Bluetooth ecosystem,by evaluating them on seventeen diverse Bluetooth chips (eighteen
devices) from popular hardware and software vendors and supporting the most popular Bluetooth versions. Motivated by ourempirical findings, we develop and successfully test an enhanced
key derivation function for Bluetooth that stops by-design our six
attacks and their four root causes. We show how to effectively
integrate our fix into the Bluetooth standard and discuss alternative implementation-level mitigations. We responsibly disclosed ourcontributions to the Bluetooth SIG.

Bluetooth, forward secrecy, future secrecy, attacks, defenses
ACM Reference Format:
Daniele Antonioli. 2023. BLUFFS: Bluetooth Forward and Future Secrecy
Attacks and Defenses. In Proceedings of the 2023 ACM SIGSAC Conference
on Computer and Communications Security (CCS ’23), November 26–30, 2023,
Copenhagen, Denmark. ACM, New York, NY, USA, 15 pages. https://doi.org/
10.1145/3576915.3623066

1

INTRODUCTION

Bluetooth is a pervasive technology for low-power wireless communication [10, 12, 13]. It provides two transports: Bluetooth Classic
for high throughput and connection-oriented use cases and Bluetooth Low Energy (BLE) for connectionless and low throughput
scenarios. This paper focuses on Bluetooth Classic, from now indicated as Bluetooth. As billions of devices, such as smartphones,
laptops, speakers, headsets, and tablets, daily employ Bluetooth toexchange sensitive data and commands, Bluetooth must provide
strong security and privacy guarantees, including confidentiality,
integrity and authenticity.
Bluetooth’s security and privacy depend on pairing and session
establishment, two mechanisms specified in the Bluetooth standard(v5.3) [11]. Devices use pairing to agree upon a long-term secretcalled the pairing key. Pairing involves user interaction, such aspressing a button or confirming a numeric value on the screen.
Paired devices use session establishment to create encrypted andintegrity-protected connections, each protected by a fresh session
key derived from the (static) pairing key and runtime parameters(key diversifiers). Session establishment, unlike pairing, does not
require user interaction. These two mechanisms have two security modes: (i) Legacy Secure Connections (LSC) using legacy cryptographic primitives and procedures, (ii) Secure Connections (SC)employing FIPS-compliant ones, such as ECDH, AES-CCM. Pairing and session establishment are critical attack surfaces as if they
are vulnerable, an adversary can exploit such vulnerability on any(standard-compliant) Bluetooth device. This critical risk motivatedextensive research on pairing [4, 9, 25, 29, 37, 53, 56] and session
establishment [3, 5] (see Section 8 for more works).
But, no prior work has investigated Bluetooth’s forward andfuture secrecy guarantees and their relation with pairing and session establishment. Forward and future secrecy, which enable todefend past and future messages from key compromise attacks,
are not even discussed by the Bluetooth standard. We extrapolated
these properties via a careful analysis of the standard. We inferredthat Bluetooth should provide forward and future secrecy among
sessions if the pairing key stays secret. Hence, an attacker compromising the current session key should not be able to decrypt

CCS CONCEPTS• Security and privacy → Systems security; Network security;
Mobile and wireless security; Security protocols.

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for components of this work owned by others than theauthor(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from permissions@acm.org.
CCS ’23, November 26–30, 2023, Copenhagen, Denmark© 2023 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 979-8-4007-0050-7/23/11. . . $15.00
https://doi.org/10.1145/3576915.3623066

636

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

data from past (i.e., forward secrecy) and future sessions (i.e., future secrecy). Then we questioned this assumption and uncovered
that, instead, sessions’ forward and future secrecy can be broken
by stealthily attacking session key derivation at the protocol level,
without knowing the pairing key or triggering a new (suspicious)
pairing event.
Specifically, we present the BLUFFS attacks, six novel attacks
breaking Bluetooth’s forward and future secrecy by targeting session establishment. The attacks exploit an attack strategy forcing
LSC session establishment and manipulating in novel ways its key
derivation to reuse a key known to the attacker across sessions. The
attacker first installs a weak session key, then spends some timebrute-forcing it, and reuses it to impersonate or machine-in-themiddle (MitM) a victim in subsequent sessions (breaking future
secrecy) and decrypt data from past sessions (breaking forward secrecy). We decline the attack strategy in six attack scenarios related
to the victim’s connection role (i.e., initiator or responder) and Bluetooth security mode (i.e., LSC or SC). Moreover, we detail the fourattacks’ root causes, two of which uncover that the standard allows
to unilaterally derive session keys without relying on nonces.
We develop the BLUFFS toolkit to perform and detect the BLUFFS
attacks automatically and with low effort. The toolkit provides
an attack device module requiring open-source software, a Linux
laptop, and a Cypress/Infineon CYW20819 board [30]. We provide
seven new patches for the board’s closed-source firmware enabling
monitoring and tampering with Bluetooth session key derivation.
Moreover, our attack checker module cleverly parses and analyzes
session establishment messages, aka Link Manager Protocol (LMP)
packets from a pcap file to automatically compute session keys anddetect our attacks.
We demonstrate that the BLUFFS attacks are effective on a large
scale by evaluating eighteen devices embedding seventeen uniqueBluetooth chips. We successfully exploited a broad set of devices(e.g., laptops, smartphones, headsets, and speakers), operating systems (e.g., iOS, Android, Linux, Windows, and proprietary OSes),
Bluetooth stacks (e.g., BlueZ, Gabeldorsche, Bluedroid, and proprietary ones), vendors (e.g., Intel, Broadcom, Cypress, Cambridge
Silicon Radio, Infineon, Bestechnic, Apple, Murata, Universal Scientific Industrial, Samsung, Dell, Google, Bose, Logitech, Xiaomi,
Lenovo, Jaybird, and Qualcomm), and Bluetooth versions (e.g., 5.2,
5.1, 5.0, 4.2, and 4.1).
Motivated by our evaluation results, we propose an enhanced
Bluetooth session key derivation function that stops by-design our
attacks and their root causes. Our countermeasure is backward compatible with the Bluetooth standard and adds minimal overheads.
Specifically, it reuses standard-compliant crypto primitives (i.e., 𝑒 1
and 𝑒 3 ) and link-layer functions (i.e., LMP commands). It requires
forty-eight (48) extra bytes over the air and three extra function
calls. We successfully test the fix against the BLUFFS attacks at
the protocol level and release the fix in our toolkit. We also discuss implementation-specific mitigations that vendors can use to
mitigate some BLUFFS attacks.
We summarize our contributions as follows:

attacks, named BLUFFS attacks, breaking these properties
by exploiting Bluetooth’s session key derivation. The threats
enable device impersonation and MitM across sessions byonly compromising one session key. They do not require userinteraction or compromise Bluetooth pairing (keys). The attacks are specification-compliant as they target protocol-level
weaknesses in the Bluetooth standard. We discuss the fourattacks’ root causes, two of which are novel for Bluetoothand affect session key derivation. We also explain how theattacks extend the state-of-the-art, including the KNOB and
BIAS attacks [3, 5].
• We release BLUFFS, a low-cost and reproducible toolkit toperform and automatically check our attacks. The toolkit’s
attack device enables manipulation and monitoring of Bluetooth session key derivation. The toolkit’s attack checker
uses a novel LMP parsing and analysis strategy to detect our
attacks from a pcap file automatically. Our toolkit complements and extends the state of the art of Bluetooth security
testing, such as [17, 18, 47].
• We tested the six BLUFFS attacks on eighteen devices embedding seventeen different Bluetooth chips from popular
hardware and software vendors. The attacks are successful
against all six LSC chips with one exception and against all
eleven SC chips when the impersonated victim is an LSC
device. If both victims support SC, the attacks are effective
on two out of eleven victims. From our empirical result weconclude that the BLUFFS attacks are practical and a criticalrisk for the Bluetooth ecosystem, and should be fixed withhigh priority.
• We design a backward-compliant Bluetooth session key derivation function based on fresh, authenticated, and mutual key
derivation. Our function stops the six BLUFFS attacks and addresses their four root causes at the protocol level. We show
how to integrate our countermeasure into the Bluetoothstandard with minimal overhead (e.g., three LMP packets
and three function calls). We also present our successful evaluation of the fix against our attacks at the protocol level andrelease it as part of our BLUFFS toolkit.

Responsible disclosure. We responsibly disclosed our findings andtoolkit to the Bluetooth Special Interest Group (SIG) [14] in October
2022. The Bluetooth SIG acknowledged our findings, coordinatedthe disclosure with the affected vendors, and reserved CVE-202324023 for our report. We also reached out to Google, Intel, Apple,
Qualcomm, and Logitech. Google scored our report with high severity, awarded us a bounty, and is working on a fix. Intel did the samebut scored the report with medium severity. Apple and Logitech
acknowledged the report and are working on fixes. Qualcomm has
not replied yet. We anonymously release in a private repository
our toolkit’s attack checker, countermeasure, and part of the attack
device at https://anonymous.4open.science/r/sec23-anon-654A.
We will open-source the toolkit according to responsible disclosure,and will submit it for artifact evaluation.

• We study Bluetooth’s forward and future secrecy guarantees, two essential properties currently not discussed byprior work and the Bluetooth standard. We show six novel

637

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

2

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Alice
A

PRELIMINARIESWe present the required Bluetooth preliminaries and our extrapolation of Bluetooth’s forward and future secrecy guarantees from theBluetooth standard.

2.1

A and B share long-term P K
BAA , LSC
BAB , LSC or SC
ACA
CRB

BluetoothBluetooth is the de-facto standard technology for low-power andreliable wireless communication and has an open specification (v5.3) [11]. It was born as a cable-replacement wireless protocol forthe unlicensed 2.4 GHz ISM (Industrial, Scientific and Medical)
band, and evolved to address various use cases requiring highthroughput and persistent connections. For example, it supports
wireless audio streaming, file transfer, hands-free services, peer-topeer connections, and Internet bridging. Bluetooth packets should
be protected against relevant attacks, such as device spoofing and
MitM, as it transports sensitive data and commands.
The Bluetooth stack loosely follows the Open Systems Interconnection (OSI) model. At the physical layer, it employs synchronizedfrequency hopping and time division multiple access. The link layer
uses a star topology managed by the link manager protocol (LMP).
The link layer connection initiator is known as Central, while theresponder is called Peripheral. These two roles can be switched dynamically during connection establishment or while a connection
is ongoing. Bluetooth uses a six-byte, unique, and static address
to identify a device at the link layer. A Bluetooth address does notcontain secret information and is obtained with an inquiry procedure. At the application layer, Bluetooth provides several profiles,
such as the advanced audio distribution (A2DP) profile. The Bluetooth Controller manages the physical and link layers, while theBluetooth Host takes care of the upper layers. The Host and theController communicate via the Host Controller Interface (HCI), a
protocol based on commands and events.
The Bluetooth standard specifies link-layer security mechanisms,
providing confidentiality, integrity, and authenticity to upper layers,
including all Bluetooth profiles. Pairing allows devices to establish along-term pairing key (𝑃𝐾). The standard defines such a procedure
as Secure Simple Pairing (SSP) [11, p. 268]. Session establishment
enables paired devices to establish a secure session using a freshsession key (𝑆𝐾). 𝑆𝐾 is derived from 𝑃𝐾 and constant and variable inputs. The standard includes two security modes affecting
pairing and session establishment: LSC, which employs legacy security mechanisms for backward-compliance reasons (e.g., E0 and
SAFER+), and SC that uses FIPS-compliant ones (e.g., ECDH, AESCCM, and HMAC).

2.2

Bob
B

Check CRB
SEA
Accept SK Entropy
SDA
Accept SK Diversifer
SK = KDFLSC (P K, BAB , ACA , SEA , SDA )ct1 = E0 (m1, SK)
ct2 = E0 (m2, SK)

Figure 1: Bluetooth LSC session establishment. The values inblue are used to compute a fresh 𝑆𝐾. 𝑃𝐾 and 𝐵𝐴𝐵 are constant,while 𝐴𝐶𝐴 , 𝑆𝐸𝐴 , and 𝑆𝐷𝐴 are variable. In this example, Alice(i.e., the Central) controls 𝑆𝐾 derivation as she provides all
the variable 𝑆𝐾 derivation inputs.

Bluetooth should provide forward and future secrecy across sessions until 𝑃𝐾 or the 𝑆𝐾 key derivation function (KDF) are notcompromised. Specifically, an attacker compromising the current
𝑆𝐾 cannot target past and future sessions because each session employs a fresh (i.e., different) 𝑆𝐾 derived from 𝑃𝐾 and variable key
diversifiers. So it is crucial that 𝑃𝐾 stays secret and that 𝑆𝐾 is properly derived. Nevertheless, no prior work evaluated the strength of
𝑆𝐾 derivation and the existence of related (practical and impactful)attack scenarios.
Now we describe LSC session establishment, including its key
derivation phase, as is the target of our work. We assume that Alice(Central with address 𝐵𝐴𝐴 ) and Bob (Peripheral with address 𝐵𝐴𝐵 )are paired and share 𝑃𝐾. As shown in Figure 1, LSC session establishment starts with two messages where Alice and Bob identify
themselves and negotiate LSC. Then, Alice asks Bob to authenticate
𝑃𝐾 by sending a challenge 𝐴𝐶𝐴 . Bob sends back 𝐶𝑅𝐵 , a responsecomputed from 𝑃𝐾 and 𝐴𝐶𝐴 , and Alice checks that 𝐶𝑅𝐵 equals the
response she computed locally. Then, Alice sends 𝑆𝐸𝐴 , an 𝑆𝐾 entropy proposal between 16 and 7 bytes, and Bob can accept it (as in
Figure 1) or propose a lower value to be accepted by Alice. Once 𝑆𝐾
entropy negotiation is completed, Alice sends to Bob 𝑆𝐷𝐴 , a session
key diversifier, and Bob acknowledges it. Finally, the devices use
𝐾𝐷𝐹𝐿𝑆𝐶 to derive 𝑆𝐾 from variable (𝐴𝐶𝐴 , 𝑆𝐸𝐴 , 𝑆𝐷𝐴 ) and constant
inputs (𝑃𝐾, 𝐵𝐴𝐵 ).
𝐾𝐷𝐹𝐿𝑆𝐶 is the LSC key derivation function specified in the standard and is defined as a system of three equations [11, p. 267]:

Bluetooth Forward and Future Secrecy

Despite their critical associated risks, Bluetooth’s forward and future (i.e., backward) secrecy guarantees are unexplored. By compromising forward (future) secrecy, the attacker could break theconfidentiality of past (future) sessions. However, we do not know
if these attacks and vulnerabilities exist as the Bluetooth standard
neither covers nor define forward and future secrecy, and no priorresearch investigated them. In this work, we address this crucialgap.
We examined pairing and session establishment from the standard and extracted their forward and future secrecy guarantees.

638

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

𝐶𝑂𝐹 = 𝑒 1 (𝑃𝐾, 𝐴𝐶𝐴 , 𝐵𝐴𝐵 )(1a)

𝐼𝑆𝐾 = 𝑒 3 (𝑃𝐾, 𝑆𝐷𝐴 , 𝐶𝑂𝐹 )(1b)

𝑆𝐾 = 𝑒𝑠 (𝐼𝑆𝐾, 𝑆𝐸𝐴 )(1c)messages (i.e., breaking forward secrecy) and decrypt or inject future ones (i.e., compromising future secrecy). These goals are novel
as the state-of-the-art assumes an adversary targeting the current
session (e.g., KNOB [5] and BIAS [3]). Moreover, the attacker would
like to exploit any Bluetooth device, regardless of its Bluetoothcapabilities (e.g., chip, version, software stack, security mode, andsupported profiles).

Using Equation 1a, the devices compute a ciphering offset number(𝐶𝑂𝐹 ) from the pairing key, Alice’s authentication challenge andBob’s Bluetooth address. The computation uses the 𝑒 1 authentication function [11, p. 975], which is based on the SAFER+ blockcipher [40]. Then, an intermediate session key (𝐼𝑆𝐾) is computed
via Equation 1b, using the pairing key, Alice’s session key diversifier,and COF. The second computation employs the 𝑒 3 key generation
function [11, p. 981]. Finally, Alice and Bob derive 𝑆𝐾 by reducing the entropy of 𝐼𝑆𝐾 according to 𝑆𝐸𝐴 with the 𝑒𝑠 function asshown in Equation 1c. The reduction function relies on on modular
arithmetic over polynomials in the finite Galois field [8].

3

3.3

THREAT MODEL

Here we present the paper’s system and attacker models and ournotation.

3.1

4

BLUFFS ATTACKSIn this section, we describe the BLUFFS attacks, six new threats
breaking Bluetooth’s forward and future secrecy and enabling impersonation and MitM attacks across sessions. We also present thefour attacks’ root causes related to 𝑆𝐾 derivation during session
establishment and explain why our attacks extend the state of theart (e.g., KNOB [5] and BIAS [3]). Please refer to Section 2 for theattacks’ preliminary and Section 3 for their threat model.

System Model

Our system model considers a scenario where Alice and Bob (i.e.,the victims) want to communicate securely using Bluetooth. Aliceand Bob represent arbitrary devices (e.g., laptops, headsets, andsmartphones) and can employ any Bluetooth profile (e.g., audio,
hands-free, and Internet bridge). We assume the victims have already paired using their strongest security capabilities (e.g., SSP
and SC).
The paired victims establish secure connections using Bluetooth’s session establishment. Alice is the Central (initiator) andBob the Peripheral (responder), unless stated otherwise. As discussed in Section 2.2, if an attacker compromises the current 𝑆𝐾,
she should be unable to compromise past and future sessions (i.e.,
break forward and future session secrecy), as each session employs
a fresh (i.e., different) 𝑆𝐾.

3.2

NotationIn the paper, we use the following notation. We indicate a Bluetooth
address as 𝐵𝐴, an authentication challenge as 𝐴𝐶 (AU_RAND in
the standard), a challenge-response as 𝐶𝑅 (SRES in the standard), a
session key as 𝑆𝐾 (Kc’ in the standard), a pairing key as 𝑃𝐾 (LK inthe standard), a session key entropy proposal as 𝑆𝐸 and a session
key diversifier as 𝑆𝐷 (EN_RAND in the standard). We abbreviate akey derivation function with 𝐾𝐷𝐹 . We use A, B, and C subscripts
to indicate Alice, Bob, (the victims) and Charlie (the attacker).

4.1

Attack Description

Strategy. The BLUFFS attacks take advantage of a novel attack
strategy, enabling Charlie to reuse a weak session key (𝑆𝐾𝐶 ) acrosssessions to spoof or MitM arbitrary victims (e.g., LSC and SC Centrals and Peripherals). We now describe such a strategy in an impersonation attack setup with the help of Figure 2. Charlie presents
to Bob using Alice’s Bluetooth address (𝐵𝐴𝐴 ) obtained using Bluetooth inquiry procedures or de-anonymization attacks such as [16].
She negotiates LSC mode (LSC) to force LSC session establishment(and key derivation), whether Bob supports LSC or SC. If Charlie
is a Peripheral, she switches to the Central role to lead session
establishment, including 𝑆𝐾 derivation. As a consequence, Charlie
can target Bob as a Central (initiator) or a Peripheral (responder).
Next, Charlie forces a fixed and weak session key (𝑆𝐾𝐶 ) by cleverly negotiating her session key derivation parameters. Specifically,
she sends a constant authentication challenge (𝐴𝐶𝐶 ) and ignores
Bob’s response (𝐶𝑅𝐶 ). She proposes the lowest session key entropy
value (𝑆𝐸𝐶 ) to (re)establish a weak key and a constant session key
diversifier 𝑆𝐷𝐶 . As a result, Bob (re)derives 𝑆𝐾𝐶 by using 𝐾𝐷𝐹𝐿𝑆𝐶
with constant inputs, i.e., 𝑃𝐾, 𝐵𝐴𝐵 , 𝐴𝐶𝐶 , 𝑆𝐸𝐶 , and 𝑆𝐷𝐶 . For example, Charlie can set 𝐴𝐶𝐶 and 𝑆𝐷𝐶 equal to zero, and 𝑆𝐸𝐶 equal toone (𝑆𝐾𝐶 has one byte of entropy).
We employ our attack strategy in six attacks covering all combinations of impersonation and MitM attacks across sessions (i.e.,targeting SC and LSC Centrals and Peripherals). As shown in thefollowing enumeration, the attacker can spoof a LSC Central or
Peripheral to a LSC or SC victim (i.e., A1, A2), impersonate a SC
Central or Peripheral to a LSC or SC victim (i.e., A4, A5), or MitM

Attacker Model

Our attacker model considers Charlie, a proximity-based attacker
in Bluetooth range with the victim(s). The attacker can capture
Bluetooth packets in plaintext (e.g., authentication challenges, key
diversifiers, and negotiated entropy values) and ciphertext (e.g.,encrypted audio, files, or internet traffic). Charlie knows the victim’s Bluetooth address, can craft (standard-compliant) Bluetooth
packets, and negotiate arbitrary capabilities. Charlie cannot compromise 𝑃𝐾, does not observe the victims while they are pairing,and does not trigger new pairing events. She cannot tamper withthe victims’ devices, including their hardware and software components. The attacker can downgrade the entropy of 𝑆𝐾 to the lowest
value supported by a victim (e.g., 1 byte for devices not patchedagainst the KNOB attack or 7 bytes) and brute force 𝑆𝐾. We do notassume a specific brute-force effort to cover attackers with different
capabilities and resources (e.g., motivated and average attackers).
Charlie wants to break the forward and future secrecy of Aliceand Bob’ sessions. For example, she would like to impersonate Aliceto Bob, Bob to Alice, or MitM them across sessions to decrypt past639

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

Charlie as AliceC

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Bob
B

Charlie knows SKC , Bob knows P K
BAA , LSC
BAB , LSC or SC
Switch To Central Role
Role Switch Accepted
ACC
CRC
SEC
Accept SK Entropy
SDC
Accept SK Diversifer

Force SKC
via a MitM
(A3 or A6),
sniff

Compromise SKC ,break past sessions
since t₁, broken
forward secrecy

Reuse SKC after t2,
broken future
secrecy (A1, A2, A3,
A4, A5, and A6)

t₁

t₂

t₃

time

Figure 3: BLUFFS attacks timeline. The attacker forces 𝑆𝐾𝐶 attime 𝑡 1 via a MitM attack (A3 or A6) and sniffs the messages
exchanged by the victims. She compromises (brute forces)
𝑆𝐾𝐶 at time 𝑡 2 and breaks forward secrecy by decrypting pasttraffic since 𝑡 1 . She reuses 𝑆𝐾𝐶 at time 𝑡 3 to impersonate or
MitM a victim (A1, A2, A3, A4, A5, or A6) and compromises
future secrecy.

SKC = KDFLSC (P K, BAB , ACC , SEC , SDC )ct1 = E0 (m1, SKC )ct2 = E0 (m2, SKC )effort is proportional to 𝑆𝐸𝐶 (i.e., 𝑆𝐾’s entropy). However, it does
not depend on the number of targeted sessions as it should withproper forward and future secrecy mechanisms. If 𝑆𝐸𝐶 is one, thebrute force effort is negligible, i.e., 128 trials on average within a key
space of 256 elements. Otherwise, if it is seven, the attacker requires
25 5 trials on average within a key space of 25 6 elements. Based onprior work breaking symmetric cryptosystems with seven bytes ofentropy, such as the data encryption standard (DES) [22, 35], we
estimate a moderate effort for a low-cost attacker using commercial
equipment (e.g., one to several weeks) and a low effort for a decently
funded attacker using distributed computing or optimized hardware(e.g., one to several days).

Figure 2: BLUFFS attacks strategy. Charlie approaches Alice as Bob negotiates LSC regardless of the security mode
supported by Bob, and, if she is a Peripheral, switches to
the Central role. Then, during LSC key derivation, she proposes constant values (𝐴𝐶𝐶 , 𝑆𝐸𝐶 , 𝑆𝐷𝐶 ) to force the derivationof a fixed session key (𝑆𝐾𝐶 ). Charlie employs this strategy
while impersonating (or MitMing) Alice and Bob to reuse 𝑆𝐾𝐶
across sessions.

Impact. The BLUFFS attacks have a severe impact on Bluetooth’s
security and privacy. They allow decrypting (sensitive) traffic andinjecting authorized messages across sessions by re-using a single
session key. Prior attacks require leaking 𝑃𝐾 or brute-forcing one
𝑆𝐾 per target session to achieve a similar impact. Our attacks cantarget any Bluetooth device, regardless of its role, security mode,and supported Bluetooth profiles, as they rely on flaws in the standard (detailed next in Section 4.2). Moreover, the attacks are stealthy
since they exploit the Bluetooth firmware (Controller) without requiring user interaction and triggering notifications to the user.
Finally, the attacks do not require specialized and expensive equipment, as demonstrated by our implementation in Section 5, and havea widespread impact, as empirically shown in Section 6. Motivatedby the impact of the attacks, in Section 7, we present a practicaldesign-level fix that we recommend integrating into the Bluetoothstandard and discuss other implementation-level mitigations.

a session where one victim supports LSC or both victims support
SC (i.e., A3, A6).
A1: Spoofing a LSC Central to a victim Peripheral
A2: Spoofing a LSC Peripheral to a victim Central
A3: MitM session where one victim supports LSC
A4: Spoofing a SC Central to a victim Peripheral
A5: Spoofing a SC Peripheral to a victim Central
A6: MitM session where the victims support SC
The BLUFFS attacks break Bluetooth’s session forward and future without compromising prior (strong) 𝑆𝐾s negotiated by thevictims. We consider forward (future) secrecy broken if Charlie
compromises past (future) sessions once 𝑆𝐾𝐶 is brute-forced (i.e.,compromised). As shown by the timeline in Figure 3, the attacker
at time 𝑡 1 mounts a MitM attack forcing 𝑆𝐾𝐶 (A3 or A6), captures
the traffic on the current and subsequent sessions, and starts brute
forcing 𝑆𝐾𝐶 . At 𝑡 2 > 𝑡 1 she brute forces (compromises) 𝑆𝐾𝐶 anddecrypts all past messages exchanged since 𝑡 1 violating forward secrecy. At 𝑡 3 > 𝑡 2 she reuses 𝑆𝐾𝐶 to impersonate or MitM Alice andBob across the next sessions (A1, A2, A3, A4, A5, and A6). Hence,
she breaks future secrecy by violating the sessions’ confidentiality,
integrity, and authenticity from 𝑡 2 onwards.

4.2

Attacks Root Causes

The BLUFFS attacks’ root causes are four architectural vulnerabilities in the specification of Bluetooth session establishment (i.e.,
RC1, RC2, RC3, and RC4) [11]. RC1 and RC2 are novel as they are
the first targeting 𝑆𝐾 derivation and allowing to derive the same 𝑆𝐾
across sessions (breaking their forward and future secrecy). While
RC3 and RC4 have been exploited to attack other session establishment phases. For instance, the BIAS attacks [3] employ RC3 andRC4 to bypass 𝑃𝐾 authentication, while the KNOB attacks [5] takeadvantage of them to downgrade the entropy of 𝑆𝐾.

Brute force setup and effort. Charlie brute forces 𝑆𝐾𝐶 employing
an offline and parallelizable setup similar to [5]. She tests offline
multiple session keys against one or more sniffed ciphertexts using
known Bluetooth packet fields as oracles (e.g., L2CAP and RFCOMM
headers decrypting to known constants). The attacker’s brute force

640

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

Table 1: Mapping the six BLUFFS attacks to their four root
causes. CI and PI stands for Central Impersonation and Peripheral Impersonation.
BLUFFS attack

RC1

RC2

RC3

RC4

A1: Spoofing a LSC Central
A2: Spoofing a LSC Peripheral
A3: MitM LSC victims
A4: Spoofing a SC Central
A5: Spoofing a SC Peripheral
A6: MitM SC victims

✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓

×
×
×
✓
✓
✓

4.3

Comparison with KNOB and BIAS

The KNOB+BIAS attack chain is considered the most effective way
to impersonate Bluetooth devices during session establishment. The
attacker employs BIAS to bypass 𝑃𝐾’s authentication, then KNOB
to downgrade the entropy of 𝑆𝐾. The BLUFFS attacks share thesame goals but employ different steps (e.g., attacking 𝑆𝐾 derivation)that are chainable with the BIAS and KNOB ones.
However, unlike the BLUFFS attacks, the KNOB+BIAS chain does
not compromise forward and future secrecy as it is effective within
the current session. More generally, no prior research investigatedthe existence of vulnerabilities and attacks on session establishment
persisting across sessions (i.e., no research on Bluetooth sessions’forward and future secrecy). Our work fills this research gap bypresenting the first key-reuse attacks for Bluetooth.
The BLUFFS attacks are successful even if we fix the role-switching
and SC session downgrade vulnerabilities discussed in the BIAS
paper. The attacker can reuse 𝑆𝐾𝐶 against any LSC device while
impersonating an LSC Central (A1). In particular, the attacker legitimately negotiates LSC, 𝐴𝐶𝐶 , 𝑆𝐸𝐶 , 𝑆𝐷𝐶 and is not required toauthenticate 𝑃𝐾. Moreover, devices patched against the KNOB attacks are still vulnerable to the BLUFFS attacks, as they accept 𝑆𝐸𝐶
equal to seven.
We enable attack scenarios, which are too costly for KNOB+BIAS.
For instance, if we target 𝑁𝑠 sessions, our attacks’ cost does notincrease with 𝑁𝑠 as we brute force one session key. While the
KNOB+BIAS cost is significantly higher as it linearly increases
with 𝑁𝑠 . The cost difference is even more compelling if a victim
supports entropy values (𝑆𝐸) higher than seven bytes. To give an
intuition about the cost difference, if we assume that brute forcing
a 𝑆𝐾 with seven bytes of entropy takes one week (keyspace is 256 ),and a 𝑆𝐾 with sixteen bytes of entropy takes one thousand years(keyspace is 2128 ); then our attacks cost one week against sevenbytes of entropy and one thousand years against sixteen bytes ofentropy, while KNOB+BIAS costs 𝑁𝑠 weeks and 𝑁𝑠 thousand years.
As a result of our investigation, we formulate and empirically answer new and valuable research questions not addressed by KNOB
and BIAS (and any other prior work). For example, we reveal theforward and future secrecy guarantees provided by the Bluetoothstandard, their architectural vulnerabilities, how to exploit thesevulnerabilities with practical and low-cost attacks, the attacks’ effectiveness on actual devices from different hardware and software
providers, and how to fix or mitigate the attacks (and their root
causes).

RC1: LSC 𝑆𝐾 diversification is unilateral (new). The LSC SKDF
introduced in Section 2 and depicted in Figure 1 derives a 𝑆𝐾 using
static inputs (i.e., 𝑃𝐾, 𝐵𝐴) and variable ones (i.e., 𝐴𝐶, 𝑆𝐸, 𝑆𝐷). The
variable inputs diversify 𝑆𝐾s across sessions. One would expect thatboth the Central and the Peripheral would contribute to 𝑆𝐾 diversification. However, the standard allows the Central to set all the 𝑆𝐾
diversification values. Hence, an attacker impersonating a Central(or role switching to a Central when impersonating a Peripheral)can unilaterally drive 𝑆𝐾 diversification (across sessions). We notethat the Peripheral’s Bluetooth address is unusable as a variable
input because Bluetooth (Classic) does not support randomized
link-layer addresses.
RC2: LSC 𝑆𝐾 diversification does not use nonces (new). 𝑆𝐾 is diversified using random numbers (𝐴𝐶 [11, p. 625] and 𝑆𝐷 [11, p. 637])
and a positive integer (𝑆𝐸 in [11, p. 962]). As none of them is anonce, they can be reused in past, present, and future sessions without violating the standard. Hence, an attacker who knows a triplet(𝐴𝐶𝐶 , 𝑆𝐸𝐶 , 𝑆𝐷𝐶 ) and the corresponding 𝑆𝐾𝐶 , can force the victims
to derive the same attacker-controlled session key across sessions.
RC3: LSC 𝑆𝐾 diversifiers are not integrity protected. The variable
inputs exchanged during 𝑆𝐾 derivation are sent without integrity
protection. As a result, an attacker who is spoofing a device or
performing MitM on a session can manipulate 𝐴𝐶, 𝑆𝐸, and 𝑆𝐷,
without being detected.
RC4: Downgrading SC to LSC does not require authentication.
The negotiation of SC or LSC is not integrity protected. Hence,an attacker can always downgrade a session to LSC, regardless of
SC support from the victim, and trigger LSC key negotiation and
𝐾𝐷𝐹𝐿𝑆𝐶 (presented in Figure 1).

5IMPLEMENTATION

We now describe the implementation of our BLUFFS toolkit to perform and check the BLUFFS attacks presented in Section 4. The
toolkit has two modules: an attack device and an attack checker andextends state-of-the-art tools for Bluetooth security research, suchas internalblue [47] and the BIAS and KNOB toolkits [17, 18], withnovel and useful features. For example, we unlock the possibility todynamically manipulate Bluetooth’s key derivation parameters andmonitor 𝑆𝐾 across sessions, and automatically detect our attacks
from a pcap file.
Our toolkit is low-cost as it uses open-source software (e.g.,
Python and Wireshark) and cheap hardware (e.g., a Linux laptop andRoot causes and attacks. Table 1 shows how the six BLUFFS attackpresented in Section 4.1 map to RC1, RC2, RC3, and RC4. All attacks
take advantage of RC1, RC2, and RC3 as they unilaterally derivea constant session key without using a nonce and manipulating
the integrity of the session key diversifiers. RC4 is exploited by thethree BLUFFS attacks targeting SC to downgrade a session to LSC.
We also note that no prior research (and attack) discovered RC1
and RC2.

641

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Table 2: Seven novel patches for the CYW20819 Bluetooth
firmware to perform the BLUFFS attacks. The third andfourth columns indicate the patched firmware function andits address in ROM.

a Cypress CYW20819 development board). Its technical details are
relevant for reproducing, checking, and extending our experimental
setup and results (shown in Section 6). We are anonymously releasing the attack checker module and selected parts of the attack device
module at https://anonymous.4open.science/r/sec23-anon-654A.

5.1

Attack device module

Architecture. Our attack device consists of a Linux laptop connected via USB to a CYW20819 board from Cypress/Infineon. Its
initialization setup is the same as the one described in the BIAS
repository [18]. In summary, to access link-layer traffic from thelaptop’s HCI interface, we activate LMP redirection from the board
with a vendor-specific command and patch the laptop’s Linux kernel to parse the LMP packets. Moreover, we patch the board’s
firmware using a proprietary binary instrumentation feature from
Cypress. Patching the firmware (Bluetooth Controller) is essential
to manipulate Bluetooth key derivation. The board’s patching isfacilitated by Internalblue [39], which provides high-level Python
APIs to patch the board (i.e., patchRom) and read and write its RAM(i.e., readMem and writeMem).
The CYW20819’s vendor-specific patching mechanism is quite
complex but clever. First, the unpatched firmware, stored in readonly memory (ROM), receives the Download_Minidriver command from our laptop (Bluetooth Host) and stops its execution.
Then, the laptop sends a Write_RAM command to write in RAM
the addresses to be modified in ROM. Finally, the laptop runs theLaunch_RAM command to register the patches in RAM and resume
execution. Hence, anytime the firmware CPU fetches an address in
ROM that should be patched, the control flow is redirected to thepatch in RAM. For more information about this mechanism, refer
to [33].

Name

Description

Patched function

Addr

man_acman_crman_sdrea_skrea_skec
rea_skep
rs_nop

Manip. 𝐴𝐶
Manip. LSC 𝐶𝑅
Manip. 𝑆𝐷
Read 𝑆𝐾 value
Read Central 𝑆𝐸
Read Perip. 𝑆𝐸
No Perip. role sw.

txAuRandtxSrestxStartEncryptReq
txStartEncryptReq
txStartEncryptReq
procStartEncryptReq
handleLmpSwitchReq

AEB8C
AEDC8
AE4B4
AE5B4
AE5B4
AE70C
A643C

instructions aligned to 4-byte boundaries, and the code branches to
odd addresses [6]. Currently, to comply with responsible disclosure,
we are releasing man_cr.s, rea_sk.s, and rs_nop.s.
Listing 1 shows our rs_nop patch to refuse Peripheral’s roleswitch requests. Whenever the firmware program counter hits
0xA643C inside handleLmpSwitchReq in ROM, the firmware code
jumps to our patch in RAM. The patch passes a zero as isMssInstantPassed’s second parameter by zeroing r1. Then, it calls (i.e.,
branch and link) isMssInstantPassed and overwrites the routine’s return value to True by setting r0 to one. As a side effect, theattack device firmware thinks that the MSS (Minimum Subevent
Space) interval has passed and rejects the correspondent role switch
request. Notably, such rejection is compliant with the standard. Finally, the patch unconditionally jumps back to the next valid ROM
instruction in Thumb-2 mode (i.e., branch to an odd address). This
patch enables exploitation of a new class of devices, such as victims
trying to (defensively) role switch to the Central role during session
establishment. For example, we can exploit iPhone 12 and 13 by
rejecting their role switch requests during session establishment.

Firmware patches. We developed seven new patches for the attack
device Bluetooth firmware. The patches, summarized in Table 2,
allow performing the six BLUFFS attacks presented in Section 4.
The table’s first and second columns indicate the patch name anddescription, while the last two show the patched firmware function
and its ROM address.
Our patches unlock useful security testing capabilities for Bluetooth. The three man_* patches manipulate 𝐴𝐶, 𝐶𝑅, and 𝑆𝐷, andenable negotiating constant 𝑆𝐾 diversifiers as in Figure 2, and failing session establishment when the attacker has to authenticate
a 𝑃𝐾. The three rea_* patches monitor 𝑆𝐾’s value which is otherwise hidden to the HCI and LMP layers. The rs_nop patch allows to
successfully attack devices asking to role switch to Central regardless of the attacker’s role switch strategy. This patch is valuable
as it extends the effectiveness of our attacks (and the BIAS+KNOB
chain) to a new class of devices. We reuse the patches from the
BIAS toolkit [18] to negotiate 𝑆𝐸 = 7 for the KNOB attack and avoid
𝑃𝐾 authentication. We also coded a high-level patching function
to ease the development of new patches (see device/patch.py in
our anonymized repository).
We developed the patches in Table 2 by reverse-engineering (RE)unknown portions of the CYW20819 Bluetooth firmware. In particular, we used Ghidra [55] loaded with the firmware symbols
leaked from a Cypress SDK as described in [39]. As we wrote thepatches in ARM Thumb-2 assembly, they contain 2-byte and 4-byte

5.2

Attack checker module

Our attack checker enables new capabilities for Bluetooth static
analysis. In particular, given a pcap file containing LMP packets, it automatically isolates Bluetooth sessions, computes session
keys, and detects the BLUFFS attacks. We release it as part of our
BLUFFS toolkit in the checker folder. The checker is written in
Python 3 and leverages capable and available tools, such as wireshark/tshark [59] and pyshark [20]. It requires H4 and LMP dissectors for Wireshark v3.6+ [48] or older versions [19]. We now
describe the checker’s parser, kdf, and analyzer components.
Parser. The parser uses pyshark to extract relevant LMP packets from a pcap file. It supports nine LMP packet types as shownin Table 3. Specifically, it parses LMP_host_connection_req and
LMP_detach packets, which indicate when a session starts andends. It processes entropy negotiation values (𝑆𝐸) from LMP_encryption_key_size_req and related LMP_accepted packets. The
parser also manages authentication challenges (𝐴𝐶) and responses(𝐶𝑅) from LMP_au_rand and LMP_sres packets and detects when
𝐴𝐶 is not accepted by monitoring the relevant LMP_not_accepted642

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

Table 3: Nine LMP packets supported by our parser.
LMP packet
LMP_host_connection_req
LMP_detach
LMP_encryption_key_size_req
LMP_accepted (𝑆𝐸)LMP_au_rand
LMP_sres
LMP_start_encryption_req
LMP_accepted (𝑆𝐷)
LMP_not_accepted (𝐴𝐶)Opcode51
716
3 (16)11
12
17
3 (17)
4 (11)and CI attacks while spoofing an LSC device. Also, we provide
a sc- prefixed file for the CI and PI attacks while impersonatinga SC device. analyzer.py contains two test functions with theneeded 𝑃𝐾, 𝐵𝐴, and target 𝑆𝐾𝐶 . By running the script, we observethat the attacker reuses 𝑆𝐾𝐶 across sessions, regardless of her role(i.e., Central or Peripheral). In particular, in the LSC cases 𝑆𝐾𝐶
is c61da2f42fefab75bb15b7927af0a631, while in the SC scenarios is 3581f68eecc5d1f295894c6bc9262812 and both 𝑆𝐾𝐶 have 7
byte of entropy. Under the hood, the script verifies 𝑆𝐾𝐶 (EXP_SK)
with an assert statement at line 175. The first session in each test
contains an 𝑆𝐾 different from 𝑆𝐾𝐶 , as that session is not underattack, but it is the first legitimate session after pairing completion.

Description
Start a session
Abort a session
Propose 𝑆𝐸
Confirm 𝑆𝐸
Send 𝐴𝐶
Send 𝐶𝑅
Send 𝑆𝐷
Accept 𝑆𝐷
Reject 𝐴𝐶

6

EVALUATION

We now present our evaluation setup and results.
packet. Moreover, it deals with session key diversifies (𝑆𝐷) by parsing LMP_start_encryption_req and consequent LMP_accepted
packets.
The parser’s implementation is at device/parser.py and follows an object-oriented design. An LmpBase parent class, shown in
Listing 2, parses relevant fields shared by all LMP packets. For example, it stores the LMP packet number (number), transaction initiator(tinit), and opcodes (op, op_ext). Specialized classes, extending
LmpBase, manage specific LMP opcodes. For instance, LmpAuRand,
presented in Listing 3, deals with LMP_au_rand packets and extracts
𝐴𝐶 as an hexstring and a bytearray (aurand and aurand_ba). We
developed other eight specialized LMP classes, see parser.py formore details.

6.1

Setup

Our evaluation setup tests the six BLUFFS attacks presented in
Section 4 (i.e., A1, A2, A3, A4, A5, and A6) on a target LSC or SC
device. Testing a device requires less than 15 minutes. Our setup
relies on the attack device and checker modules introduced in
Section 5 to automate its repetitive parts (e.g., compute and checkthe session keys from a pcap file). The setup has six steps:(1) First, we test A4, A5, and A6 which involve spoofing and
MitM of SC victims. We pair the attack device (also acting asa spoofed victim) with the target victim, and we disconnect
them. While pairing, the attack device declares SC support.
(2) We patch the attack device’s firmware (using the patches
presented in Table 2) to implement the strategy discussed in
Section 4.1. The patched attack device declares LSC support,monitors 𝑆𝐾s across sessions, and sets 𝐴𝐶𝐶 = 𝑆𝐷𝐶 = 0, and
𝑆𝐸𝐶 = 7 to renegotiate a constant and weak session key (i.e.,
𝑆𝐾𝐶 ). Also, the attack device tries to role switch to Central
before session key derivation when it is a Peripheral andrefuses role switch requests when acting as a Central. We
also force the attack device to send a wrong 𝐶𝑅𝐶 to detecta failure in (rare) attack scenarios where the victim asks
the Central to authenticate 𝑃𝐾 (e.g., PI against the BOOM 3
Bluetooth speaker).
(3) We test A4 by establishing multiple sessions from the attack
device (Central) and capturing the HCI and LMP packets ina pcap file. We also monitor 𝑆𝐾 from RAM in each session,
but this manual step is optional. Then, we employ our attack
checker to automatically recompute and compare the 𝑆𝐾sfrom the pcap file. If the computed keys are the same, theattack is successful, as the adversary is impersonating a SC
device while reusing 𝑆𝐾𝐶 across sessions.
(4) We test A5 by establishing multiple connections from thevictim to the attack device (Peripheral). We employ the same
strategy described in the previous steps, and the attack iseffective if we reuse 𝑆𝐾𝐶 across sessions.
(5) If either the CI or the PI attack is successful, then the victim
is also vulnerable to A6, as the adversary can combine CI
and PI in a MitM attack against SC victims.
(6) We unpair the attack device and the victim and pair themagain, but this time the attack device declares LSC support.

Kdf. The kdf module implements the LSC key derivation function
presented in Section 2 as shown in Listing 4. This functionality isneeded to compute and check 𝑆𝐾s across sessions automatically. In
particular, kdf.py computes 𝑆𝐾 (as in Equation 1) by using e1.py,
e3.py and es.py and their related cryptographic primitives (suchas h.py). We provide the kdf code in the toolkit’s device folder,
and we note that it extends [17, 18] by providing the full LSC key
derivation chain. Our code is sound as is tested against the vectors
in the Bluetooth standard [11, p. 921] and actual values extracted
during our experiments. The kdf test suite can be run with maketests.
Analyzer. The analyzer module is implemented in checker/analyzer.py and automatically detects the BLUFFS attacks presented
in Section 4. It builds on top of the parser and kdf modules presented
earlier. The analyzer employs the gen_analysis function, shownin Listing 5, that takes as inputs a pcap file, a 𝑃𝐾, and the Bluetooth
address of the victim (Peripheral). Then it calls gen_sessions to
extract from the pcap a list of LMP sessions (sessions). Then, foreach session, it calls the gen_report function that computes 𝑆𝐾
from 𝑆𝐸, 𝑆𝐷, and 𝐴𝐶 and stores the reports in a list (reports). Finally, for each report gen_analysis checks if 𝑆𝐾𝐶 is reused acrosssessions (assert report["sk"] == EXP_SK). This automation
speeded up our large-scale evaluation reported in Section 6.
To demonstrate that our module is practical, we provide thematerial to reproduce our analysis of the Pixel Buds A-Series earbuds. In the toolkit’s pcap folder, there is a file prefixed with
lsc- with the LMP traffic generated while we performed the PI

643

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Then, we repeat steps two, three, four, and five to test A1,
A2, and A3.
Our setup uses, without loss of generality, the attack device bothas a victim and the attacker to speed up the experiments. However,as stated in Section 3, we stress that the attacker does require neither
to pair with the victim devices nor observe them while they are
pairing nor trigger a new pairing session. To prove such a claim, we
tested scenarios where before attacking the victim, we unpaired theattack device from the victim by overwriting its 𝑃𝐾 with a wrong
value (via a firmware patch), and we were still able to force 𝑆𝐾𝐶
across sessions.

6.2

vendors (e.g., Intel, Broadcom, Cypress, Cambridge Silicon Radio,
Infineon, Bestechnic, Apple, Murata, Universal Scientific Industrial,
Samsung, Dell, Google, Bose, Logitech, Xiaomi, Lenovo, Jaybird,
and Qualcomm), and Bluetooth versions (e.g., 5.2, 5.1, 5.0, 4.2, and
4.1).
Moreover, Table 4’s list of vulnerable chips and devices represents a lower bound. We cannot test all Bluetooth devices in themarket. However, we are confident that most of them are flawed, as
the BLUFFS attacks exploit architectural issues of Bluetooth session
key derivation. We can confidently infer that all untested devices
employing an exploitable chip from Table 4 are vulnerable. For instance, since the Apple H1 chip is in our list; we can predict that theother devices embedding H1 are also affected, e.g., AirPods gen. 2
and 3, AirPods Max, Beats Solo Pro, Powerbeats (2000), Powerbeats
Pro, and Beats Fit Pro [58]. Hence, there is a need for a usable countermeasure to fix the BLUFFS attacks by-design, and we address
this challenge in Section 7.

Results

Table 4 presents our evaluation results obtained by testing the six
BLUFFS attacks on eighteen heterogeneous and popular devices(second column) embedding seventeen unique Bluetooth chips (firstcolumn) and employing the most popular Bluetooth versions (thirdcolumn). We compiled the table following the six steps in Section 6.1.
The last six columns contain a ✓ if a device is vulnerable to an
attack; otherwise, a ×. The fourth, fifth, and sixth columns show CI,
PI, and MitM attacks when the spoofed victim supports LSC (i.e.,
A1, A2, and A3). While the last three columns report CI, PI, andMitM attacks while impersonating a SC device (i.e., A4, A5, and
A6).

7

ENHANCED LSC KDF

Motivated by the impact of our attacks (e.g., results from Section 6.2),
we present an enhanced LSC KDF addressing the six BLUFFS attacks
and their four root causes at the architectural level. Our KDF uses
authenticated and mutual key derivation and is backward compliant with 𝐾𝐷𝐹𝐿𝑆𝐶 (Section 7.1). We show how to integrate ourcountermeasure in the Bluetooth standard while entailing minimal
computation, throughput, and latency overheads (Section 7.2). The
fix also aligns with best practices for symmetric key derivation,such as NIST SP 800–56C–rev2 [7]. We report how we successfully tested our fix at the protocol level. Based on our results, werecommend its introduction in the Bluetooth specification (e.g.,
via an amendment). We also discuss low-cost implementation-level
mitigations that vendors can employ until the standard is updated(Section 7.4).

LSC Victims. As shown by the first six rows in Table 4, all tested
LSC chips and devices are vulnerable to the six attacks, with one
exception. The Logitech BOOM 3 speaker is not vulnerable to the
PI attacks (A2, A5), as it requires the Central to authenticate 𝑃𝐾,
thus preventing the attacker from completing session establishment(despite eventually being able to reuse 𝑆𝐾𝐶 ). The Bose SoundLink
speaker also asks the Central to authenticate but is still vulnerable
to A2 and A5 as it does not check the challenge response. The
Google Pixel Buds A-Series (2021) are still vulnerable to the KNOB
downgrade resulting in 𝑆𝐾𝐶 with 1 byte of entropy; we reported
this worrisome finding to Google and got a “will not fix” response.

7.1

DesignFigure 4 shows the message sequence chart of our enhanced KDF
which extends 𝐾𝐷𝐹𝐿𝑆𝐶 , described in Figure 1, in four ways:

SC Victims. The last eleven rows in Table 4 shows our findings
about chips and devices supporting SC. If the spoofed victim supports LSC, all chips/devices are vulnerable to the CI, PI, and MitM attacks (A1, A2, A3). Hence, an attacker can impersonate any chip/device from the LSC block of rows to any chip/device in the SC set. If
we impersonate a SC device, the CYW20819 and CYW40707 chips
are vulnerable to A4, A5, and A6, demonstrating that the attacks
are effective against SC. Instead, the other eight chips/devices wetested are not vulnerable to A4, A5, and A6, as the chips enforce SC
between pairing and session establishment, preventing the attacker
from downgrading the session to LSC. But, they are still vulnerable
to A1, A2, and A3 because of the vulnerabilities we uncover withLSC.

(1) Adds 𝐸𝐾𝐷, a feature flag to negotiate our KDF, as shown by
the first two messages in Figure 4. This flag provides backward compatibility as it accommodates devices supportingand not supporting our protocol. It can also enforce the usageof our protocol across sessions, avoiding (malicious) KDF
downgrades. The Bluetooth standard employed the same
approach when it introduced SC.
(2) Defines 𝑆𝐷 not as a random number but as a nonce, (i,e., number usable once). This definition is valuable as it mandates
by design to deny 𝑆𝐷’s re-usage, regardless of the attacker’s
strategy.
(3) Employs the mutually authenticated key diversification scheme
presented in Figure 4, rather than the unilateral and unauthenticated one from the standard. In particular, Alice sends
Bob 𝑆𝐷𝐴 (i.e., Central 𝑆𝐷 nonce) and Bob answers with𝑀𝑎𝑐 (𝑆𝐷𝐴 , 𝑃𝐾), a message authentication code (MAC) computed from the diversifier and 𝑃𝐾 to acknowledge and authenticate it. Alice aborts the session if the MAC check fails
while Charlie cannot produce such MAC since she does not

Evaluation impact. Driven by our empirical results shown in
Table 4, we are convinced that the BLUFFS attacks are practical andhave a large-scale impact on the Bluetooth ecosystem. In particular,
they can target SC and LSC devices (e.g., laptops, smartphones, headsets, and speakers) supporting a wide range of operating systems(e.g., iOS, Android, Linux, Windows, and proprietary OS), Bluetooth
stacks (e.g., BlueZ, Gabeldorsche, Bluedroid, and proprietary ones),

644

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

Table 4: BLUFFS attacks evaluation results. We run the six BLUFFS attacks against eighteen devices with seventeen uniqueBluetooth chips. All the six tested LSC victims are vulnerable to all the attacks, with one exception. When we impersonate
an LSC device to an SC device, all tested eleven SC targets are vulnerable. Comparatively, when we spoof an SC device toanother SC device, the attacks are only effective on two out of eleven tested chips (i.e., CYW20819 and CYW40707). Our results
empirically demonstrate that the attacks are practical and have a widespread impact on the Bluetooth ecosystem.
Notes: 1 ask to authenticate as a Central, 2 does not check authentication response (𝐶𝑅), 3 vulnerable
𝑆𝐾 downgrade with 1 byte of entropy, 4 does not allow LSC session establishment if paired with SC.
Acronyms: USI stands for Universal Scientific Industrial, CYW for Cypress, BCM for Broadcom, and CSR for Cambridge Silicon Radio. A n/a in the Chip column indicates that the chip SoC model is unavailable from public sources.
Chip

Device(s)

BTv

A1

A2

A3

A4

A5

A6

LSC Victims
Bestechnic BES2300
Apple H1
Cypress CYW20721
CSR/Qualcomm BC57H687C-GITM-E4
Intel Wireless 7265 (rev 59)
CSR n/aPixel Buds A-Series3
AirPods Pro
Jaybird Vista
Bose SoundLink1,2
Thinkpad X1 3rd gen
Logitech BOOM 31

5.2
5.0
5.0
4.2
4.2
4.2

✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
×

✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
×

✓
✓
✓
✓
✓
✓

SC Victims
Infineon CYW20819
Cypress CYW40707
Qualcomm Snapdragon 865
Apple/USI 339S00761
Intel AX201
Broadcom BCM4389
Intel 9460/9560
Qualcomm Snapdragon 835
Murata 339S00199
Qualcomm Snapdragon 821
Qualcomm Snapdragon 410

CYW920819EVB-02
Logitech MEGABLAST
Mi 10T4
iPhones 124 , 134
Portege X30-C4
Pixel 64
Latitude 54004
Pixel 24
iPhone 74
Pixel XL4
Galaxy J54

5.0
4.2
5.2
5.2
5.2
5.2
5.0
5.0
4.2
4.2
4.1

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓

✓
✓
×
×
×
×
×
×
×
×
×

✓
✓
×
×
×
×
×
×
×
×
×

✓
✓
×
×
×
×
×
×
×
×
×

know 𝑃𝐾. Then, the protocol enforces a similar exchangeof messages from Bob to Alice involving 𝑆𝐷 𝐵 (i.e., Peripheral 𝑆𝐷 nonce) and 𝑀𝑎𝑐 (𝑆𝐷 𝐵 , 𝑃𝐾). After exchanging thesemessages, Alice and Bob mutually set and authenticate thesession key diversifiers.
(4) Uses the 𝑀𝐾𝐷𝐹𝐿𝑆𝐶 mutual key derivation function to compute mutually diversified 𝑆𝐾, unlike 𝐾𝐷𝐹𝐿𝑆𝐶 that allows asingle (malicious) party to diversify 𝑆𝐾. In particular, 𝑀𝐾𝐷𝐹𝐿𝑆𝐶
binds 𝑆𝐾 to 𝑆𝐷𝐴 and 𝑆𝐷 𝐵 , the authenticated nonces sent by
Alice and Bob.
Our enhanced KDF fixes the four attack root causes presented
in Section 4.2. RC1: The key diversification is mutual as 𝑆𝐾 depends on contributions from the Central and the Peripheral (i.e.,
𝑆𝐷𝐴 and 𝑆𝐷 𝐵 ). RC2: The diversifiers are defined as nonces rather
than random numbers. RC3: The negotiation of the diversifiers
is integrity protected using message authentication codes keyedwith 𝑃𝐾. RC4: We tolerate (malicious) LSC to SC downgrades by
providing a stronger LSC key derivation protocol.
Our scheme stops the six BLUFFS attacks regardless of the attacker’s role (CI, PI, or MitM) and target security mode (LSC or
SC). In particular, the attack strategy presented in Figure 2 becomesineffective, as the victim asks the other party to authenticate 𝑆𝐷with 𝑃𝐾 and aborts session establishment if authentication fails.

Furthermore, the fix prevents the attacks even if the attacker successfully authenticates (e.g., by stealing 𝑃𝐾), as the attacker cannot
control the victim’s 𝑆𝐷 to force a known 𝑆𝐾.
Despite being designed to address the BLUFFS vulnerabilities,
our KDF mitigates the KNOB attacks and stops the BIAS attacks.
The KDF increases the 𝑆𝐾 brute force effort exponentially with thenegotiated entropy and linearly with the number of target sessions
as the attacker must brute force a new 𝑆𝐾 for each session, otherthan a single 𝑆𝐾 regardless of the number of target sessions. Hence,
our KDF is effective even if the attacker can brute force 𝑆𝐾𝐶 as her
effort to target 𝑛 sessions increases from 256 to 𝑛 × 256 . Moreover,it blocks the BIAS attacks as an adversary who managed to skip
𝑃𝐾 authentication (e.g., by attacking a victim not patched against
BIAS) cannot bypass our mutually authenticated key derivation
protocol without knowing 𝑃𝐾.

7.2

Integration in the Bluetooth Specification

Our fix requires backward-compliant modifications to the Bluetoothstandard (e.g., LSC session establishment) and produces minimal
overhead (e.g., one extra negotiation bit, three extra LMP packets
carrying in total 48 bytes of extra data to authenticate the diversifiers, three extra function calls to compute the MACs and 𝑆𝐾). We
now describe these modifications in detail.

645

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

Alice
A

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Bob
B

𝑀𝐾𝐷𝐹𝐿𝑆𝐶 is a backward compatible extension of 𝐾𝐷𝐹𝐿𝑆𝐶 presented in Equation 1. 𝐶𝑂𝐹 and 𝐼𝑆𝐾 are computed as in 𝐾𝐷𝐹𝐿𝑆𝐶(i.e., Equations 3a and 3b). Then, we add Equation 3c to bind thesession key to 𝑆𝐷 𝐵 by computing a second intermediate session key
𝐼𝑆𝐾 ′ , reusing the 𝑒 3 key generation function [11, p. 981]. In Equation 3d, we reuse 𝑒𝑠 to reduce the session key entropy as usual andproduce 𝑆𝐾. In summary, 𝑀𝐾𝐷𝐹𝐿𝑆𝐶 is described by the following
four equations:

A and B share long-term P K
BAA , LSC, EKD
BAB , LSC, EKD
ACACRB
Check CRB
SEA
Accept SK Entropy
SDA
M ac(SDA , P K)

𝐶𝑂𝐹 = 𝑒 1 (𝑃𝐾, 𝐴𝐶𝐴 , 𝐵𝐴𝐵 )(3a)

𝐼𝑆𝐾 = 𝑒 3 (𝑃𝐾, 𝑆𝐷𝐴 , 𝐶𝑂𝐹 )

(3b)

′

𝐼𝑆𝐾 = 𝑒 3 (𝐼𝑆𝐾, 𝑆𝐷 𝐵 , 𝐶𝑂𝐹 )(3c)

𝑆𝐾 = 𝑒𝑠 (𝐼𝑆𝐾 ′, 𝑆𝐸𝐴 )(3d)

Lastly, we propose two extensions of the LMP protocol to mutually generate and authenticate 𝑆𝐷. First, the LMP_start_encryption_req command (opcode 17) which now is used to send 𝑆𝐷
from the Central [11, p. 638], should be usable also by the Peripheral to send its diversifier nonce. Second, we require a new LMP
command, defined as LMP_start_encryption_res, to send a 16
Byte MAC authenticating an 𝑆𝐷. Indeed, if Alice is the Central andBob the Peripheral, we expect the following four LMP messages:

Check SDA
SDB
M ac(SDB , P K)
Check SDB
SK = M KDFLSC (P K, BAB , ACA , SEA , SDA , SDB )(1) Alice: LMP_start_encryption_req(𝑆𝐷𝐴 )(2) Bob: LMP_start_encryption_res(𝑀𝑎𝑐 (𝑆𝐷𝐴 , 𝑃𝐾))
(3) Bob: LMP_start_encryption_req(𝑆𝐷 𝐵 )(4) Alice: LMP_start_encryption_res(𝑀𝑎𝑐 (𝑆𝐷 𝐵 , 𝑃𝐾))

ct1 = E0 (m1, SK)
ct2 = E0 (m2, SK)

Figure 4: Enhanced LSC session key derivation. Alice and
Bob negotiate the enhanced KDF via 𝐸𝐾𝐷 to maintain backward compatibility with 𝐾𝐷𝐹𝐿𝑆𝐶 . They mutually exchange,authenticate, and check session key diversification nonces(i.e., 𝑆𝐷𝐴 , 𝑆𝐷 𝐵 , 𝑀𝑎𝑐 (𝑆𝐷𝐴 , 𝑃𝐾), 𝑀𝑎𝑐 (𝑆𝐷 𝐵 , 𝑃𝐾)). Then, use the diversifiers in a mutual key derivation function (i.e., 𝑀𝐾𝐷𝐹𝐿𝑆𝐶 )to compute fresh and non-reusable keys across sessions. Our
enhanced KDF fixes the BLUFFS attacks and their four root
causes by design.

7.3

The BLUFFS toolkit includes a Python implementation of our enhanced LSC session key derivation (see checker/mkdf.py). We
used our implementation to empirically confirm at the protocollevel that the BLUFFS attacks are not effective by testing the sameattack scenarios exploited in Section 4 using the attack strategy in
Figure 2. Hence, the presented KDF stops the attacks and their root
causes (i.e., exploited vulnerabilities) by design.
As shown in checker/mkdf_tests.py, the attacker controls
𝐴𝐶𝐶 (AU_RAND_C), 𝑆𝐷𝐶 (EN_NONCE_C), 𝑆𝐸𝐶 (ENTROPY_C). However,she cannot authenticate the victim’s session key diversifier (MAC_V)
as she does not know 𝑃𝐾 (LK). Even if the adversary manages to
bypass 𝑆𝐷 mutual authentication, she cannot force a known 𝑆𝐾𝐶
as she does not control 𝑆𝐷𝑉 (EN_NONCE_V). As a result, the attacker
cannot conduct the BLUFFS attacks, regardless of her role (Central
or Peripheral) and the type of spoofed victim (LSC or SC).

𝐸𝐾𝐷 requires adding a new LMP feature that should be stored
in the firmware and optionally in the OS. For instance, the standard
could introduce an EKD flag usable to negotiate our enhanced KDF
during LMP feature exchange (as in Figure 4). Moreover, a device
can enforce EKD usage among sessions and refuse to connect witha device not supporting it.
Mandating nonces rather than random looking 𝑆𝐷s requires
straightforward textual modification to the standard. For example,
instead of defining 𝑆𝐷 as 𝐸𝑁 _𝑅𝐴𝑁 𝐷 [11, p. 637], the standard
should define it as 𝐸𝑁 _𝑁𝑂𝑁𝐶𝐸. Or when talking about 𝑆𝐷s, thedocument should classify them as “nonces” other than “random
numbers”.
Authenticating 𝑆𝐷 is also easy to implement as during session
establishment Alice and Bob already share 𝑃𝐾. In particular, werecommend computing the MACs reusing the 𝑒 1 authentication
function from the standard [11, p. 975] as follows:
𝑀𝑎𝑐 (𝑆𝐷𝐴 , 𝑃𝐾) = 𝑒 1 (𝑃𝐾, 𝑆𝐷𝐴 , 𝐵𝐴𝐵 )(2a)

𝑀𝑎𝑐 (𝑆𝐷 𝐵 , 𝑃𝐾) = 𝑒 1 (𝑃𝐾, 𝑆𝐷 𝐵 , 𝐵𝐴𝐴 )(2b)

Protocol Level Evaluation

7.4

Implementation Level Mitigations

SC-to-SC enforcement. Enforcing SC mode between pairing andsession establishment stops the attacks when both victims support
SC. One can implement this enforcement in the OS (i.e., BluetoothHost) by storing a SC flag for each paired device and checking
that flag during session establishment. As a result, if the attacker
impersonates a SC device, the victim can check whether or not theimpersonated device supports SC and abort the session when theattacker negotiates LSC. From Table 4 – Note 4, we see that ten
SC devices already implement this fix. Unfortunately, this mitigation only covers SC-to-SC attack scenarios that currently are lessprevalent than LSC-to-SC and LSC-to-LSC ones.

646

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli

LSC 𝑆𝐷 cache. A device can stop the presented attacks by maintaining a cache of seen 𝑆𝐷 (i.e., LSC session key diversifiers) and refusing a connection with a (malicious) device proposing a 𝑆𝐷 in thecache. One can implement this cache in the Bluetooth firmware (i.e.,
Bluetooth Controller), as 𝑆𝐷 is not visible by the OS. Unfortunately,
this mitigation could be brittle as the cache is unauthenticated. For
instance, an adversary can poison the cache with dumb 𝑆𝐷s andthen negotiate the target 𝑆𝐷, which is no more in the cache.

automated extraction of security-related parameters [52], detectionof link-layer vulnerabilities [57] and weaknesses in random number
generation [54].
Bluetooth fuzzing and implementation bugs. We discovered theprotocol-level BLUFFS attacks and their root causes by inference
from the Bluetooth specification. Then, we automated the repetitive
tasks by developing a toolkit. Other research work used directedfuzzing to find crashes, denial of service (DoS), and remote code
execution (RCE) implementation-level bugs in popular Bluetooth
stacks [24, 44, 46]. Other recent work employs differential testing tocatch protocol compliance implementation bugs [34] automatically.
There are works uncovering implementation-level vulnerabilities
resulting in RCE using semi-automated techniques. Notable examples are: BlueBorne [49] impacting Amazon Echo and Google Home,
BlueFrag [23] against Android 9, Bleedingbit [50] on Texas Instrument BLE chips, and BleedingTooth [42] targeting BlueZ and theLinux kernel. Unlike the exploits described in this paragraph, the
BLUFFS attacks can target a device regardless of its implementation
details (and bugs).

LSC Central authentication. A device can stop the PI attacks byrequiring an attacker in the Central role to authenticate 𝑃𝐾. One
can implement this check in the Bluetooth firmware by updating
the session establishment code in a backward compliant way. As
a result, the attacker cannot complete LSC session establishment,
as she cannot authenticate 𝑃𝐾. This mitigation is implemented by
the Logitech BOOM 3 speaker, as shown in Table 4 and detailed in
Note 1. Notably, Central authentication only protects against thetwo PI attacks.

8

RELATED WORK

Attacks on Bluetooth session establishment. Our work is the firstpresenting attacks breaking Bluetooth’s forward and future secrecy
and persisting across sessions. Other attacks on session establishment showed that session entropy negotiation is vulnerable todowngrade attacks reducing the strength of 𝑆𝐾 to 1 byte [5]. The
standard now mandates a minimum entropy value of 7 bytes, but
recent work showed that some devices classes still accept 1 byte ofentropy [2]. Other work uncovered how to bypass session authentication [3, 36]. Recent work analyzed how to employ KNOB+BIAS
to exploit different Bluetooth profiles within the same session [1]and the vehicular ecosystem [2].

Forward/future secrecy. Forward and future secrecy were extensively studied for Transport Layer Security (TLS) and Instant Messengers (IM). TLS’s forward secrecy was evaluated in the wild [28]and TLS 1.3 mandates it using non-static cipher suites, such as
ephemeral Diffie-Hellman (DH) key exchange [31]. The double
ratchet algorithm [45], used by the most popular IMs (e.g., Signal,and WhatsApp), provides future secrecy with the DH ratchet andforward secrecy with the symmetric ratchets and was analyzed
by security researchers [15]. No prior work evaluated Bluetooth’s
forward and future secrecy properties (not even the Bluetooth standard).

Attacks on Bluetooth pairing. Several works targeted Bluetooth
pairing (i.e., the SSP protocol), while in this work, we assume that
it is not under attack. In particular, there are SSP’s probabilistic
invalid curve attacks [9], MitM attacks [25, 53], and cross-transport
key derivation attacks [4]. Moreover, related work targeted SSP
association [29, 56] and the legacy pairing protocol [32, 37, 51].
We note that attacks on pairing are more challenging to perform
and less stealthy than ones on session establishment as pairing is a
one-time procedure involving user interaction.

Survey on Bluetooth security. There are not so recent survey papers about Bluetooth security [21, 38, 41, 43]. They are an excellent
way to get introduced to Bluetooth’s security architecture and related threats. However, none of them discusses Bluetooth’s forward
and future secrecy guarantees.

9

CONCLUSION

This paper presents the first security evaluation of Bluetooth forward and future secrecy guarantees. It uncovers two new vulnerabilities in Bluetooth’s session establishment, enabling to reuse of a weaksession key across sessions. We show how to exploit these flaws
in six attack scenarios to impersonate and MitM arbitrary devices
across sessions. Our attacks break Bluetooth’s forward and future
secrecy as they compromise past and future encrypted messages
with novel key reuse attacks. Our findings result from experimentswith Bluetooth session establishment on actual devices and inference from the standard. We focused on 𝑆𝐾 as, unlike 𝑃𝐾, it can betargeted without user interaction, and its entropy can be lowered
without violating the standard.
We provide BLUFFS, a low-cost and reproducible toolkit to implement, detect, and fix the attacks. The toolkit includes seven
original patches to manipulate session key derivation and monitor
𝑆𝐾s by patching the attack device’s Bluetooth firmware. It also
ships parsing and analysis scripts to detect the attacks from a pcap
file. We use our toolkit to evaluate the BLUFFS attacks on a large

Bluetooth tracking attacks. The fact that Bluetooth addresses are
not randomizable not only helps to perform the BLUFFS attacks but
also enables device tracking threat where an adversary violates thevictim’s privacy by tracking his movements using the Bluetooth
address as a permanent identifier [16, 26, 27, 60]. Researchers proposed similar attacks for BLE, despite its usage of allowlists andaddress randomization [61].
Bluetooth firmware research. Bluetooth firmware are essential for
security research as they implement pairing and session establishment. However, they are proprietary and closed-source, requiring
significant reverse-engineering effort to be analyzed and patched.
Luckily, researchers have developed tools to inspect and patch
popular Bluetooth firmware. For example, Internalblue [39] provides a Python API to interact and patch popular Broadcom andCypress firmware. Other work focused on Bluetooth firmware’s647

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

scale. We exploit eighteen devices embedding seventeen Bluetooth
chips from leading hardware and software vendors and estimate
the attacks’ impact. For example, our threats are effective in all
scenarios where at least one of the victims supports LSC and evenin scenarios where the victims support SC. These results translate
into millions of exploitable devices.
To address the attacks’ critical impact, we develop and test a
protocol-level countermeasure preventing by-design the BLUFFS
attacks and their root causes. We design an enhanced KDF for LSC
employing fresh, mutual, and authenticated session key derivation.
We show how to update the LMP protocol and 𝐾𝐷𝐹𝐿𝑆𝐶 to integrate
our fix in a backward compliant way and with minimal overheads.
Specifically, we require one extra LMP command, 48 extra bytes sent
over the air, 3 specification-compliant function calls, and minimal
textual modifications to the standard. We successfully tested ourKDF at the protocol level and released it as part of our BLUFFS
toolkit. We hope our fix will soon be added to the standard andimplemented by the vendors. Moreover, we recommend to vendors
implementation-level mitigations that can be adopted while waiting
for an update to the standard.
From this work, we learned three key lessons that we want
to share: (i) we should pay more attention to session establishment vulnerabilities, attacks, and fixes effective across sessions,(ii) we should agree on the definitions of Bluetooth’s forward andfuture secrecy and update the standard to discuss these definitions
and related risks, (iii) we need open-source Bluetooth firmware(Controllers) and better tooling around them to improve the effectiveness, coverage, and speed of our offensive and defensive
evaluations.

[9] Eli Biham and Lior Neumann. 2018. Breaking the Bluetooth Pairing–Fixed
Coordinate Invalid Curve Attack. http://www.cs.technion.ac.il/~biham/BT/btfixed-coordinate-invalid-curve-attack.pdf.
[10] Bluetooth SIG. 2020. Bluetooth Market Update 2020. https://www.bluetooth.com/bluetooth-resources/2020-bmu/.
[11] Bluetooth SIG. 2021. Bluetooth Core Specification v5.3. https://www.bluetooth.
org/DocMan/handlers/DownloadDoc.ashx?doc_id=521059.
[12] Bluetooth SIG. 2021. Bluetooth Market Update 2021. https://www.bluetooth.com/bluetooth-resources/2021-bmu/.
[13] Bluetooth SIG. 2022. Bluetooth Market Update 2022. https://www.bluetooth.com/2022-market-update/.
[14] Bluetooth SIG. 2022. Reporting Security Vulnerabilities. https://www.blueto
oth.com/learn-about-bluetooth/key-attributes/bluetooth-security/reportingsecurity/.
[15] Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt, and Douglas Stebila. 2020. A formal security analysis of the signal messaging protocol.
Journal of Cryptology 33 (2020), 1914–1983.
[16] Marco Cominelli, Francesco Gringoli, Paul Patras, Margus Lind, and Guevara
Noubir. 2020. Even black cats cannot stay hidden in the dark: Full-band deanonymization of Bluetooth Classic devices. In 2020 IEEE Symposium on Security
and Privacy (SP). IEEE, 534–548.
[17] Daniele Antonioli (francozappa). 2020. KNOB attack repository on Github. https://github.com/francozappa/knob.
[18] Daniele Antonioli (francozappa). 2021. BIAS attack repository on Github. https://github.com/francozappa/bias.
[19] Dennis Mantz (demantz). 2022. BTBB Wireshark plugin from the Ubertooth
libbtbb project. https://github.com/demantz/lmp_wireshark_dissector.
[20] Dor Green. 2022. Pyshark Python packet parser using wireshark’s tshark. https://kiminewt.github.io/pyshark/.
[21] John Dunning. 2010. Taming the blue beast: A survey of Bluetooth based threats.
IEEE Security & Privacy 8, 2 (2010), 20–27.
[22] Electronic Frontier Foundation (EFF). 1998. Cracking DES. https://archive.org/
details/crackingdes00elec.
[23] ERNW. 2020. CVE-2020-0022 an Android 8.0-9.0 Bluetooth Zero-Click RCE –BlueFrag. https://insinuator.net/2020/04/cve-2020-0022-an-android-8-0-9-0bluetooth-zero-click-rce-bluefrag/.
[24] Matheus E Garbelini, Vaibhav Bedi, Sudipta Chattopadhyay, Sumei Sun, andErnest Kurniawan. 2022. BrakTooth: Causing Havoc on Bluetooth Link Manager
via Directed Fuzzing. In 31st USENIX Security Symposium (USENIX Security 22).
1025–1042.
[25] Keijo Haataja and Pekka Toivanen. 2010. Two practical man-in-the-middle
attacks on Bluetooth Secure Simple Pairing and countermeasures. Transactions
on Wireless Communications 9, 1 (2010), 384–392.
[26] Simon Hay and Robert Harle. 2009. Bluetooth tracking without discoverability. In
International Symposium on Location-and Context-Awareness. Springer, 120–137.
[27] Jun Huang, Wahhab Albazrqaoe, and Guoliang Xing. 2014. BlueID: A practical system for Bluetooth device identification. In IEEE INFOCOM 2014-IEEE
Conference on Computer Communications. IEEE, 2849–2857.
[28] Lin-Shung Huang, Shrikant Adhikarla, Dan Boneh, and Collin Jackson. 2014. An
experimental study of TLS forward secrecy deployments. IEEE Internet Computing
18, 6 (2014), 43–51.
[29] Konstantin Hypponen and Keijo MJ Haataja. 2007. Nino man-in-the-middle
attack on Bluetooth Secure Simple Pairing. In Proceedings of the International
Conference in Central Asia on Internet. IEEE, 1–5.
[30] Infineon. 2022. CYW20819. https://www.infineon.com/cms/en/product/wirelessconnectivity/airoc-bluetooth-le-bluetooth-multiprotocol/airoc-bluetooth-lebluetooth/cyw20819/.
[31] Internet Engineering Task Force (IETF). 2018. The Transport Layer Security (TLS)
Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446.
[32] Markus Jakobsson and Susanne Wetzel. 2001. Security weaknesses in Bluetooth.
In Proceedings of the Cryptographers’ Track at the RSA Conference. Springer, 176–
191.
[33] Jiska YouTube Channel. 2021. InternalBlue Tutorial - 2021 Edition. https://www.youtube.com/watch?v=UANnKx91vyg.
[34] Imtiaz Karim, Abdullah Al Ishtiaq, Syed Rafiul Hussain, and Elisa Bertino. 2023.
BLEDiff: Scalable and Property-Agnostic Noncompliance Checking for BLE Implementations. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE Computer
Society, 1082–1100.
[35] Sandeep Kumar, Christof Paar, Jan Pelzl, Gerd Pfeiffer, and Manfred Schimmler.
2006. Breaking ciphers with COPACOBANA–a cost-optimized parallel code
breaker. In Cryptographic Hardware and Embedded Systems-CHES 2006: 8th International Workshop, Yokohama, Japan, October 10-13, 2006. Proceedings 8. Springer,
101–118.
[36] Albert Levi, Erhan Çetintaş, Murat Aydos, Çetin Kaya Koç, and M Ufuk Çağlayan.
2004. Relay attacks on Bluetooth authentication and solutions. In ProceedingsInternational Symposium on Computer and Information Sciences. Springer, 278–
288.
[37] Andrew Y Lindell. 2008. Attacks on the pairing protocol of Bluetooth v2.1. Black
Hat USA, Las Vegas, Nevada (2008).

ACKNOWLEDGMENTS
Work funded by the European Union under grant agreement no.
101070008 (ORSHIN project). Views and opinions expressed are
however those of the author(s) only and do not necessarily reflect
those of the European Union. Neither the European Union nor the
granting authority can be held responsible for them.

REFERENCES[1] Mingrui Ai, Kaiping Xue, Bo Luo, Lutong Chen, Nenghai Yu, Qibin Sun, and Feng
Wu. 2022. Blacktooth: Breaking through the Defense of Bluetooth in Silence. In
Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications
Security. 55–68.
[2] Daniele Antonioli and Mathias Payer. 2022. On the Insecurity of Vehicles Against
Protocol-Level Bluetooth Threats. In 2022 IEEE Security and Privacy Workshops(SPW). IEEE, 353–362.
[3] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper Rasmussen. 2020. BIAS:
Bluetooth impersonation attacks. In 2020 IEEE Symposium on Security and Privacy(SP). IEEE, 549–562.
[4] Daniele Antonioli, Nils Ole Tippenhauer, Kasper Rasmussen, and Mathias Payer.
2022. BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic
and Bluetooth Low Energy. In Proceedings of the Asia conference on computer andcommunications security (ASIACCS).
[5] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper B Rasmussen. 2019. The
KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of
Bluetooth BR/EDR. In 28th USENIX Security Symposium (USENIX Security 19).
1047–1061.
[6] ARM Developers. 2022. ARM Thumb-2 instruction set. https://developer.arm.com/documentation/ddi0344/k/programmers-model/thumb-2-instruction-set.
[7] Elaine Barker, Lily Chen, Richard Davis, et al. 2018. Recommendation for keyderivation methods in key-establishment schemes. NIST Special Publication 800(2018), 56C.
[8] Christoforus Juan Benvenuto. 2012. Galois field in cryptography. University ofWashington 1, 1 (2012), 1–11.

648

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

Daniele Antonioli[38] Angela M Lonzetta, Peter Cope, Joseph Campbell, Bassam J Mohd, and Thaier
Hayajneh. 2018. Security vulnerabilities in Bluetooth technology as used in IoT.
Journal of Sensor and Actuator Networks 7, 3 (2018), 28.
[39] Dennis Mantz, Jiska Classen, Matthias Schulz, and Matthias Hollick. 2019. InternalBlue Bluetooth binary patching and experimentation framework. In Proceedings of the 17th Annual International Conference on Mobile Systems, Applications,and Services. 79–90.
[40] James L Massey, Gurgen H Khachatrian, and Melsik K Kuregian. 1998. Nominationof SAFER+ as candidate algorithm for the Advanced Encryption Standard (AES).
NIST AES Proposal (1998).
[41] Nateq Be-Nazir Ibn Minar and Mohammed Tarique. 2012. Bluetooth security
threats and solutions: a survey. International Journal of Distributed and Parallel
Systems 3, 1 (2012), 127.
[42] Andy Nguyen. 2020. BleedingTooth: Linux Bluetooth Zero-Click Remote Code
Execution. https://google.github.io/security-research/pocs/linux/bleedingtooth/writeup.
[43] John Padgette. 2017. Guide to Bluetooth security. NIST Special Publication 800(2017), 121.
[44] Haram Park, Carlos Kayembe Nkuba, Seunghoon Woo, and Heejo Lee. 2022.
L2Fuzz: Discovering Bluetooth L2CAP Vulnerabilities Using Stateful Fuzz Testing.
In 2022 52nd Annual IEEE/IFIP International Conference on Dependable Systems
and Networks (DSN). IEEE, 343–354.
[45] Trevor Perrin and Moxie Marlinspike. 2016. The double ratchet algorithm. GitHub
wiki (2016).
[46] Jan Ruge, Jiska Classen, Francesco Gringoli, and Matthias Hollick. 2020. Frankenstein: Advanced wireless fuzzing to exploit new Bluetooth escalation targets. In
29th USENIX Security Symposium (USENIX Security 20). 19–36.
[47] seemoo-lab. 2021. InternalBlue repository on Github. https://github.com/seemoolab/internalblue.
[48] Seemoo-lab. 2022. BTBB plugin for Wireshark 3.6. https://github.com/seemoolab/h4bcm_wireshark_dissector.
[49] Ben Seri and Gregory Vishnepolsky. 2017. The Attack Vector BlueBorne Exposes
Almost Every Connected Device. https://armis.com/blueborne/.

[50] Ben Seri, Gregory Vishnepolsky, and Dor Zusman. 2019. BLEEDINGBIT: The
hidden Attack Surface within BLE chips. https://armis.com/bleedingbit/.
[51] Yaniv Shaked and Avishai Wool. 2005. Cracking the Bluetooth PIN. In Proceedingsof the conference on Mobile systems, applications, and services (MobiSys). ACM,
39–50.
[52] Pallavi Sivakumaran and Jorge Blasco. 2021. argXtract: Deriving IoT Security Configurations via Automated Static Analysis of Stripped ARM Cortex-M Binaries.
In Annual Computer Security Applications Conference. 861–876.
[53] Da-Zhi Sun, Yi Mu, and Willy Susilo. 2018. Man-in-the-middle attacks on Secure
Simple Pairing in Bluetooth standard V5. 0 and its countermeasure. Personal andUbiquitous Computing 22, 1 (2018), 55–67.
[54] Jörn Tillmanns, Jiska Classen, Felix Rohrbach, and Matthias Hollick. 2020.
Firmware insider: Bluetooth randomness is mostly random. arXiv preprint
arXiv:2006.16921 (2020).
[55] US NSA Research Directorate. 2022. ghidra: a software reverse engineering (sre)suite of tools. https://ghidra-sre.org/.
[56] Maximilian von Tschirschnitz, Ludwig Peuckert, Fabian Franzen, and Jens
Grossklags. 2021. Method confusion attack on Bluetooth pairing. In 2021 IEEE
Symposium on Security and Privacy (SP). IEEE, 1332–1347.
[57] Haohuang Wen, Zhiqiang Lin, and Yinqian Zhang. 2020. Firmxray: Detecting
Bluetooth link layer vulnerabilities from bare-metal firmware. In Proceedingsof the 2020 ACM SIGSAC Conference on Computer and Communications Security.
167–180.
[58] Wikipedia Community. 2022. Apple silicon. https://en.wikipedia.org/wiki/Apple_silicon.
[59] Wireshark developers. 2022. Wireshark homepage. https://www.wireshark.org/.
[60] Ford-Long Wong and Frank Stajano. 2005. Location privacy in Bluetooth. In
Proceedings of the European Workshop on Security in Ad-hoc and Sensor Networks.
Springer, 176–188.
[61] Yue Zhang and Zhiqiang Lin. 2022. When Good Becomes Evil: Tracking Bluetooth
Low Energy Devices via Allowlist-based Side Channel and Its Countermeasure. In
Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications
Security. 3181–3194.

649

BLUFFS: Bluetooth Forward and Future Secrecy Attacks and Defenses

CCS ’23, November 26–30, 2023, Copenhagen, Denmark

APPENDIX

Listing 4: Excerpt of Kdf’s kdf function
def kdf ( LK , AU_RAND , EN_RAND , BTADDR , ENTROPY ):""" Generate KcPrime """BTADDR . reverse ()_ , COF = e1 ( LK , AU_RAND , BTADDR )log . debug ( " COF : {} " . format ( repr ( COF )))# NOTE : redo reverse as it is passed by reference
BTADDR . reverse ()Kc = e3 ( LK , EN_RAND , COF )log . debug ( " Kc : {} " . format ( repr ( Kc )))Kc . reverse ()KcPrime = Kc_to_Kc_prime ( Kc , ENTROPY )KcPrime . reverse ()return KcPrime

Here we present the Listings referenced in the paper.
Listing 1: Patch to refuse Peripheral’s role switch requests.
@ Jumped from 0 xA643C ( handleLmpSwitchReq )@ Load second parameter for isMssInstantPassed
ldr r1 , [r6 , #0 x0 ]@ Call isMssInstantPassed
bl #0 XA63FE@ Set return value to True
mov r0 , #0 x1@ Jump to ROM at 0 xA643C +7 in Thumb -2 modeb #0 xA6443

Listing 2: Parser’s LmpBase Class
Listing 5: Analyzer’s gen_analysis function

class LmpBase ( object ):""" Base Class for LMP Parsing """def __init__ ( self , pkt ):self . number = int ( pkt . number )_tinit = int ( pkt . h4bcm . btbrlmp_tid )self . tinit = LMP_TRANS_INIT [ _tinit ]self . op = int ( pkt . h4bcm . btbrlmp_op )if self . op == 127:
_op_ext = int ( pkt . h4bcm . btbrlmp_eop )self . op_ext = _op_ext
self . op_str = LMP_OP_EXT [ self . op_ext ]else :
self . op_str = LMP_OP [ self . op ]def gen_analysis ( PCAP , LK , EXP_SK , BTADD_P ):""" Generate list of sessions and reports """sessions = gen_sessions ( PCAP )reports = []for session in sessions :report = gen_report ( session , LK , BTADD_P )reports . append ( report )i = 1
for report in reports :print ( f " ## Begin session : { i } " )if " keysize " in report :print ( f " keys : { report [' keysize ']} " )if " enrand " in report :print ( f " enr : { report [' enrand ']. hex ()} " )if " aurand " in report :print ( f " aur : { report [' aurand ']. hex ()} " )if " sk " in report :print ( f " sk ses : { report [' sk ']. hex ()} " )# NOTE : check constant SK
if report [ " aurand " ] == BA_16_ZEROS
and report [ " enrand " ] == BA_16_ZEROS :print ( f " sk exp : { EXP_SK . hex ()} " )assert report [ " sk " ] == EXP_SK
print ( f " ## End session : { i }\ n " )i += 1

Listing 3: Parser’s LmpAuRand Class
class LmpAuRand ( LmpBase ):""" Parse LMP_au_rand """def __init__ ( self , packet ):super (). __init__ ( packet )self . aurand = packet . h4bcm . btbrlmp_rand
self . aurand_ba = bytearray . fromhex (self . aurand . replace (":" , "" ))650