The KNOB is Broken: Exploiting Low Entropy in the

Encryption Key Negotiation Of Bluetooth BR/EDR

Daniele Antonioli, SUTD; Nils Ole Tippenhauer, CISPA; Kasper B. Rasmussen,
University of Oxford
https://www.usenix.org/conference/usenixsecurity19/presentation/antonioli

This paper is included in the Proceedings of the

28th USENIX Security Symposium.
August 14–16, 2019 • Santa Clara, CA, USA
978-1-939133-06-9

Open access to the Proceedings of the

28th USENIX Security Symposium
is sponsored by USENIX.
The KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation
Of Bluetooth BR/EDR

Daniele Antonioli Nils Ole Tippenhauer Kasper Rasmussen

Singapore University of CISPA Helmholtz Center Department of Computer Science
Technology and Design for Information Security University of Oxford
daniele [email protected] [email protected] [email protected]

Abstract The security and privacy of Bluetooth has been attacked

and fixed several times, going all the way back to Blue-
We present an attack on the encryption key negotiation pro- tooth v1.0. [15, 32]. Several successful attacks on the (secure
tocol of Bluetooth BR/EDR. The attack allows a third party, simple) pairing phase [28, 13, 4] have resulted in substantial
without knowledge of any secret material (such as link and revisions of the standard. Attacks on Android, iOS, Windows
encryption keys), to make two (or more) victims agree on an and Linux implementations of Bluetooth were also discussed
encryption key with only 1 byte (8 bits) of entropy. Such low in [2]. However, little attention has been given to the security
entropy enables the attacker to easily brute force the nego- of the encryption key negotiation protocol, e.g., the Bluetooth
tiated encryption keys, decrypt the eavesdropped ciphertext, security overview in the latest Bluetooth core specification
and inject valid encrypted messages (in real-time). The attack (v5.0) does not mention it [6, p. 240].
is stealthy because the encryption key negotiation is transpar-
The encryption key negotiation protocol is used by two
ent to the Bluetooth users. The attack is standard-compliant
Bluetooth devices to agree on the entropy of the link layer
because all Bluetooth BR/EDR versions require to support en-
encryption key. Entropy negotiation was introduced in the
cryption keys with entropy between 1 and 16 bytes and do not
specification of Bluetooth to cope with international encryp-
secure the key negotiation protocol. As a result, the attacker
tion regulations and to facilitate security upgrades [6, p. 1650].
completely breaks Bluetooth BR/EDR security without being
To the best of our knowledge, all versions of the Bluetooth
detected. We call our attack Key Negotiation Of Bluetooth
standard (including the latest v5.0 [6]) require to use entropy
(KNOB) attack.
values between 1 and 16 bytes. The specification of Blue-
The attack targets the firmware of the Bluetooth chip be-
tooth states this requirement as follows: “For the encryption
cause the firmware (Bluetooth controller) implements all
algorithm, the key size may vary between 1 and 16 octets (8 -
the security features of Bluetooth BR/EDR. As a standard-
128 bits)” [6, p. 1650]. Our interpretation of this requirement
compliant attack, it is expected to be effective on any firmware
is that any device to be standard-compliant has to support
that follows the specification and on any device using a vul-
encryption keys with entropy varying from one to sixteen
nerable firmware. We describe how to perform the KNOB
bytes. The attack that we present in this work confirms our
attack, and we implement it. We evaluate our implementation
interpretation.
on more than 14 Bluetooth chips from popular manufactur-
ers such as Intel, Broadcom, Apple, and Qualcomm. Our The encryption key negotiation protocol is conducted be-
results demonstrate that all tested devices are vulnerable to tween two parties as follows: the initiator proposes an entropy
the KNOB attack. We discuss countermeasures to fix the value N that is an integer between 1 and 16, the other party
Bluetooth specification and its implementation. either accepts it or proposes a lower value or aborts the pro-
tocol. If the other party proposes a lower value, e.g., N − 1,
then the initiator either accepts it or proposes a lower value or
1 Introduction it aborts the protocol. At the end of a successful negotiation
the two parties have agreed on the entropy value of the Blue-
Bluetooth BR/EDR (referred for the rest of this paper as tooth encryption key. The entropy negotiation is performed
Bluetooth), is a short-range wireless technology widely used over the Link Manager Protocol (LMP), it is not encrypted
by many products such as mobile devices, laptops, IoT and and not authenticated, and it is transparent to the Bluetooth
industrial devices. Bluetooth provides security mechanisms users because LMP packets are managed by the firmware of
to achieve authentication, confidentiality and data integrity at the Bluetooth chips and they are not propagated to higher
the link layer [6, p. 1646]. layers [6, p. 508].

USENIX Association 28th USENIX Security Symposium 1047

 In this paper we describe, implement and evaluate an attack this problem has not somehow been fixed in practice, we
capable of making two (or more) victims using a Bluetooth test more than 14 different Bluetooth chips and find all
encryption key with 1 byte of entropy without noticing it. The of them to be vulnerable.
attacker then can easily brute force the encryption key, eaves-
drop and decrypt the ciphertext and inject valid ciphertext • We discuss what changes should be made, both to the
without affecting the status of the target Bluetooth piconet. Bluetooth standard and its implementation, in order to
In other words, the attacker completely breaks Bluetooth counter this attack.
BR/EDR security without being detected. We call this attack Our work is organized as follows: in Section 2 we intro-
the Key Negotiation Of Bluetooth (KNOB) attack. duce the Bluetooth BR/EDR stack. In Section 3 we present
The KNOB attack can be conducted remotely or by mali- the Key Negotiation Of Bluetooth (KNOB) attack. An imple-
ciously modifying few bytes in one of the victim’s Bluetooth mentation of the attack is discussed in Section 4. We evaluate
firmware. Being a standard-compliant attack it is expected the impact of our attack in Section 5 and we discuss the at-
to be effective on any firmware implementing the Bluetooth tack and our proposed countermeasures in Section 6. We
specification, regardless of the Bluetooth version. The at- present the related work in Section 7. We conclude the paper
tacker is not required to posses any (pre-shared) secret ma- in Section 8.
terial and he does not have to observe the pairing process of
the victims. The attack is effective even when the victims
use the strongest security mode of Bluetooth (Secure Connec- 2 Background
tions). The attack is stealthy because the application using
Bluetooth and even the operating systems of the victims can- 2.1 Bluetooth Basic Rate/Extended Data Rate
not access or control the encryption key negotiation protocol Bluetooth Basic Rate/Extended Data Rate (BR/EDR), also
(see Section 3.2 for the details). known as Bluetooth Classic, is a widely used wireless technol-
After explaining the attack in detail, we implement it lever- ogy for low-power short-range communications maintained
aging our development of several Bluetooth security proce- by the Bluetooth Special Interest Group(SIG) [6]. Its physical
dures to generate valid link and encryption keys, and the layer uses the same 2.4 GHz frequency spectrum of WiFi and
InternalBlue toolkit [21]. Our implementation allows a man- (adaptive) frequency hopping to mitigate RF interference. A
in-the-middle attacker to intercept, manipulate, and drop LMP Bluetooth network is called a piconet and it uses a master-
packets in real-time and to brute force low-entropy encryp- slave medium access protocol. There is always one master
tion keys, without knowing any (pre-shared) secret. We have device per piconet at a time. The devices are synchronized by
disclosed our findings about the KNOB attack with CERT maintaining a reference clock signal, defined as CLK. Each
and the Bluetooth SIG, and following that, we plan to re- device has a Bluetooth address (BTADD) consisting of a se-
lease our tools as open-source at https://github.com/ quence of six bytes. From left to right, the first two bytes are
francozappa/knob. This will enable other Bluetooth re- defined as non-significant address part (NAP), the third byte
searchers to take advantage of our work. as upper address part (UAP) and the last three bytes as lower
We summarize our main contributions as follows: address part (LAP).
To establish a secure Bluetooth connection two devices
• We develop an attack on the encryption key negotiation
first have to pair. This procedure results in the establishment
protocol of Bluetooth BR/EDR that allows to let two
of a long-term shared secret defined as link key, indicated
unaware victims negotiate a link-layer encryption key
with KL . There are four types of link key: initialization, unit,
with 1 byte of entropy. The attacker then is able to brute
combination and master. A initialization key is always gener-
force the low entropy key, decrypt all traffic and inject
ated for each new pairing procedure. A unit key is generated
arbitrary ciphertext. The attacker does not have to know
from a device and utilized to pair with every other device,
any secret material and he can target multiple nodes and
and its usage is not recommended because it is insecure. A
piconets at the same time.
combination key is generated using Elliptic Curve Diffie Hell-
• We demonstrate the practical feasibility of the attack by man (ECDH) on the P-256 elliptic curve. This procedure
implementing it. Our implementation involves a man- is defined as Secure Simple Pairing (SSP) and it provides
in-the-middle attacker capable of manipulating the en- optional authentication of the link key. Combination keys are
cryption key negotiation protocol, brute forcing the key the most secure and widely used. A master key is generated
and decrypting the traffic exchanged by two (or more) only for broadcast encryption and it has limited usage. The
unaware victims. master key is temporary, while the others are semi-permanent.
A semi-permanent key can persist until a new link key is re-
• All standard-compliant devices should be vulnerable quested (link key is bonded) or it can change within the same
to our attack, including the ones using the strongest session (link key is not bonded). In this paper we deal with
Bluetooth security mode. In order to demonstrate that combination link keys generated using authenticated SSP.

1048 28th USENIX Security Symposium USENIX Association

 The specification of Bluetooth defines custom security pro-
cedures to achieve confidentiality, integrity and authentication.
In the specification their names are prefixed with the letter E.
In particular, a combination link key KL is mutually authenti-
cated by the E1 procedure. This procedure uses a public nonce
(AU RAND) and the slave’s Bluetooth address (BTADDS ) to
generate two values: the Signed Response (SRES) and the
Authenticated Ciphering Offset (ACO). SRES is used over
the air to verify that two devices actually own the same KL .
The symmetric encryption key KC is generated using the
E3 procedure. When the link key is a combination key E3
uses ACO (computed by E1 ) as its Ciphering Offset Num-
ber (COF) parameter, together with KL and a public nonce
(EN RAND). E1 and E3 use a custom hash function defined
in the specification of Bluetooth with H. The hash function is
Figure 1: High level stages of a KNOB attack.
based on SAFER+, a block cipher that was submitted as an
AES candidate in 1998 [22].
Once the encryption key KC is generated there are two pos- 3 Exploiting Low Entropy in the Encryption
sible ways to encrypt the link-layer traffic. If both devices Key Negotiation Of Bluetooth BR/EDR
support Secure Connections, then encryption is performed
using a modified version of AES CCM. AES CCM is an In this section we describe the Key Negotiation Of Bluetooth
authenticate-then encrypt cipher that combines Counter mode (KNOB) attack. The attack allows Charlie (the attacker) to
with CBC-MAC and it is defined in the IETF RFC 3610 [14]. reduce the entropy of the encryption key of any Bluetooth
As a side note, the specification of Bluetooth defines a mes- BR/EDR (referred as Bluetooth) connection to 1 byte, without
sage authentication codes (MAC) with the term message in- being detected by the victims (Alice and Bob). The attacker
tegrity check (MIC). If Secure Connections is not supported can brute force the encryption key without having to know
then the devices use the E0 stream cipher for encryption. The any (pre-shared) secret material and without having to ob-
cipher is derived from the Massey-Rueppel algorithm and it serve the Secure Simple Pairing protocol. As a result, the
is described in the specification of Bluetooth [6, p. 1662]. E0 attacker can eavesdrop and decrypt all the traffic and inject
requires synchronization between the master and the slaves arbitrary packets in the target Bluetooth network (piconet).
of the piconet, this is achieved using the Bluetooth’s clock The attack works regardless the usage of Secure Connections
value (CLK). (the strongest security mode of Bluetooth). The KNOB attack
Modern implementations of Bluetooth provides the Host high level stages are shown in Figure 1 and they are described
Controller Interface (HCI). This interface allows to separate in detail in the rest of this section.
the Bluetooth stack into two components: the host and the
controller. Each component has specific responsibilities, i.e.,
the controller manages low-level radio and baseband opera-
3.1 System and Attacker Model
tions and the host manages high-level application layer pro- We assume a system composed of two or more legitimate
files. Typically, the host is implemented in the operating devices that communicate using Bluetooth (as described in
system and the controller in the firmware of the Bluetooth Section 2). One device is the master and the others are slaves.
chip. For example BlueZ and Bluedroid implement the HCI Without loss of generality, we focus on a piconet with one
host on Linux and Android, and the firmware of a Qualcomm master and one slave (Alice and Bob). We indicate their
or Broadcom Bluetooth chip implements the HCI controller. Bluetooth addresses with BTADDM and BTADDS , and the
The host and the controller communicate using the Host Con- Bluetooth clock with CLK. The clock is used for synchro-
troller Interface (HCI) protocol. This protocol is based on nization and it does not provide any security guarantee. The
commands and events, i.e., the host sends (acknowledged) victims are capable of using Secure Simple Pairing and Secure
commands to the controller, and the controller uses events to Connections. This combination enables the highest security
notify the host. level of Bluetooth and should protect against eavesdropping
The Link Manager Protocol (LMP) is used over the air by and active man in the middle attacks. For example, if both
two controllers to perform link set-up and control for Blue- devices have a display their users have to confirm that they
tooth BR/EDR. LMP is neither encrypted nor authenticated. see the same numeric sequence to mutually authenticate.
The LMP packets do not propagate to higher protocol layers, The attacker (Charlie) wants to decrypt all messages ex-
hence, the hosts (OSes) are not aware about the LMP packets changed between Alice and Bob and inject valid encrypted
exchanged between the Bluetooth controllers. messages, without being detected. The attacker has no access

USENIX Association 28th USENIX Security Symposium 1049

 Alice (controller) Bob (controller)
A B
LMP: AU RAND
LMP: SRES
LMP encryption mode req: 1
LMP accept
′
LMP KC entropy: 16
′
LMP KC entropy: 1
Figure 2: Generation and usage of the Bluetooth link layer Negot’n
LMP accept
encryption key (KC0 ). Firstly, KC is generated from KL and LMP start encryption: EN RAND
other public parameters. KC has 16 bytes of entropy, and LMP accept
it is not directly used as the encryption key. KC0 , the actual
encryption key, is computed by reducing the entropy of KC ′
Encryption key KC has 1 byte of entropy
to N bytes. N is an integer between 1 and 16 and it is the
result of the encryption key negotiation protocol. The N byte
entropy KC0 is then used for link layer encryption by either the
E0 or the AES-CCM cipher.

Figure 3: Alice and Bob negotiate 1 byte of entropy for the

to any (pre-shared) secret material. i.e., the link key KL and encryption key (KC0 ). The protocol is run by Alice and Bob
the encryption key KC . Charlie can observe the public nonces controllers (implemented in their Bluetooth chip) over the air
(EN RAND and AU RAND), the Bluetooth clock and the using LMP.
packets exchanged between Alice and Bob.
We define two attacker models: a remote attacker and a
to facilitate security upgrades [6, p. 1650]. The specification
firmware attacker. A remote attacker controls a device that
of the Bluetooth encryption key negotiation protocol contains
is in Bluetooth range with Alice and Bob. He is able to
three significant problems:
passively capture encrypted messages, actively manipulate
unencrypted communication, and to drop packets using tech- 1. It allows to negotiate entropy values as low as 1 byte,
niques such as network man-in-the-middle and manipulation regardless the Bluetooth security level.
of physical-layer signals [31, 26]. The firmware attacker is
able to compromise the firmware of the Bluetooth chip of a 2. It is neither encrypted nor authenticated.
single victim using techniques such as backdoors [7], supply-
chain implants [12], and rogue chip manufacturers [27]. The 3. It is implemented in the Bluetooth controller (firmware)
firmware attacker requires no access to the Bluetooth host and it is transparent to the Bluetooth host (OS) and to
(OS) and applications used by the victims. the user of a Bluetooth application.

Hence, an attacker (Charlie) can convince any two victims

3.2 Negotiate a Low Entropy Encryption Key (Alice and Bob) to negotiate N equal to 1, the lowest possible,
yet standard-compliant, entropy value. As a result the victims
Every time a Bluetooth connection requires link-layer encryp- compute and use a Bluetooth encryption key (KC0 ) with one
tion, Alice and Bob compute an encryption key KC based on byte of entropy. The victims (and their OSes) are not aware
KL , BTADDS , AU RAND, and EN RAND (see top part of about the entropy reduction of KC0 because the negotiation
Figure 2). KL is the link key established during secure simple happens between the victims’ Bluetooth controller (firmware)
pairing and the others parameters are public. Assuming ideal and the packets do not propagate to the victims’ Bluetooth
random number generation, the entropy of KC is always 16 host (OS).
bytes. To understand how an attacker can set N equal to 1 (or
KC is not directly used as the encryption key for the cur- to any other standard-compliant value), we have to look at
rent session. The actual encryption key, indicated with KC0 , is the details of the encryption key negotiation protocol. The
computed by reducing the entropy of KC to N bytes. N is the protocol is run between the Bluetooth chip of Alice and Bob.
outcome of the Bluetooth encryption key negotiation protocol In the following, we provide an example where Alice (the
(Entropy Negotiation in Figure 2). The protocol is part of the master) proposes 16 bytes of entropy, and Bob (the slave) is
Bluetooth specification since version v1.0, and it was intro- only able to support 1 byte of entropy (see Figure 3). The
duced to cope with international encryption regulations and standard enables to set the minimum and maximum entropy

1050 28th USENIX Security Symposium USENIX Association

 Alice (host) Alice (controller) Charlie (attacker) Bob (controller) Bob (host)
Ahost Actrl C Bctrl Bhost
HCI set encryption
HCI accept
′
LMP KC entropy: 16
′
LMP KC entropy: 1
LMP accept
′
LMP KC entropy: 1
LMP accept
HCI encryption on HCI encryption on

′
Alice and Bob use an encryption key KC with 1 byte of entropy

Figure 4: The KNOB attack sets the entropy of the encryption key (KC0 ) to 1 byte. Alice requests Bob to activate encryption and
starts the encryption key negotiation protocol. The attacker (Charlie) changes the entropy suggested by Alice from 16 to 1 byte.
Bob accepts Alice’s proposal and Charlie changes Bob’s acceptance to a proposal of 1 byte. Alice, who originally proposed 16
bytes of entropy and she is asked to use 1 byte accepts the (standard-compliant) proposal. Charlie drops Alice’s acceptance
message because Bob already accepted Alice’s proposal (modified by Charlie). Charlie does not know any pre-shared secret and
does not observe SSP.

values by setting two parameters defined as Lmin and Lmax . requests to activate (set) encryption. Alice’s Bluetooth con-
These values can be set and read only by the Bluetooth chip troller accepts the local requests and starts the encryption key
(firmware). Indeed, our scenario describes a situation where negotiation procedure with Bob’s Bluetooth controller over
Alice’s Bluetooth firmware declares Lmax = 16 and Lmin = 1, the air. The attacker intercepts Alice’s proposed key entropy
and Bob’s Bluetooth firmware declares Lmax = Lmin = 1. and substitutes 16 with 1. This simple substitution works
The encryption key negotiation protocol is carried over because LMP is neither encrypted nor integrity protected.
the Link Manager Protocol (LMP). The first two messages Bob’s controller accepts 1 byte. The attacker intercepts Bob’s
in Figure 3 allow Alice to authenticate that Bob possesses acceptance message and change it to an entropy proposal of
the correct KL . Then, with the next two messages, Alice 1 byte. Alice thinks that Bob does not support 16 bytes of
requests to initiate Bluetooth link layer encryption and Bob entropy and accepts 1 byte. The attacker intercepts Alice’
accepts. Now, the negotiation of N takes place (Negot’n in acceptance message and drops it. Finally, the controllers of
Figure 3). Alice proposes 16 bytes of entropy. Bob can Alice and Bob compute the same KC0 with one byte of entropy
either propose a smaller value or accept the proposed one or and notify their respective hosts that link-layer encryption
abort the negotiation. In our example, Bob proposes 1 byte is on.
of entropy because it is the only value that he supports and
It is reasonable to think that the victim could prevent or
Alice accepts it. Then, Alice requests to activate link-layer
detect this attack using a proper value for Lmin . However, the
encryption and Bob accepts. Finally, Alice and Bob compute
standard does not state how to explicitly take advantage of
the same encryption key (KC0 ) that has 1 byte of entropy. Note
it, e.g., deprecate Lmin values that are too low. The standard
that, the Bluetooth hosts of Alice and Bob do not have access
states the following: “The possibility of a failure in setting
to KC and KC0 , they are only informed about the outcome of
up a secure link is an unavoidable consequence of letting the
the negotiation. The key negotiation procedure can also be
application decide whether to accept or reject a suggested
initiated by the Bob (the slave), resulting in the same outcome.
key size.” [6, p. 1663]. This statement is ambiguous because
Figure 4 describes how the attacker (Charlie) manages to it is not clear what the definition of “application” is in that
let Alice and Bob agree on a KC0 with 1 byte of entropy when sentence. As we show in Section 5, this ambiguity results in
both Alice and Bob declare Lmax = 16 and Lmin = 1. In this no-one being responsible for terminating connections with
Figure we also show the local interactions between hosts and low entropy keys in practice. In particular, the entity who
controllers to emphasize that at the end of the negotiation the decides whether to accept or reject the entropy proposal is
hosts are not informed about N and KC0 . the firmware of the Bluetooth chip by setting Lmin and Lmax
The attack is performed as follows: Alice’s Bluetooth host and participating in the entropy negotiation protocol. The

USENIX Association 28th USENIX Security Symposium 1051

“application” (intended as the Bluetooth application running In case of AES-CCM the entropy reduction procedure
on the OS using the firmware as a service) cannot check and is simpler than the one of E0 . In particular, the 16 − N
set Lmin and Lmax , and it is not directly involved in the en- least significant bytes of KC are set to zero. For example,
tropy acceptance/rejection choice (that is performed by the when N = 1 the 256 KC0 candidates for AES-CCM are the set
firmware). The application can interact with the firmware 0x00. . . 0xff.
using the HCI protocol. In particular, it can use the HCI Read In the implementation of our KNOB attack brute force
Encryption Key Size request, to check the amount of nego- logic, we pre-compute the 512 keys with 1 byte of entropy
tiated entropy after the Bluetooth connection is established and we store them in a look-up table to speed-up comparisons.
and theoretically abort the connection. This check is neither Table 4 in Appendix A shows the first twenty KC0 with 1 byte
required nor recommended by the standard as part of the key of entropy for E0 and AES-CCM. More details about the brute
negotiation protocol. force implementation are discussed in Section 4.
The low entropy negotiation presented in Figure 4 can be
performed by both attacker models presented in Section 3.1.
The remote attacker has the capabilities of dropping and inject- 3.4 KNOB Attack Implications
ing valid plaintext (the encryption key negotiation protocol is
neither encrypted nor authenticated). The firmware attacker The Key Negotiation Of Bluetooth (KNOB) attack exploits
can modify few bytes in the Bluetooth firmware of a victim a vulnerability at the architectural level of Bluetooth. The
to always negotiate 1 byte of entropy. Furthermore, the nego- vulnerable encryption key negotiation protocol endangers po-
tiation is effective regardless of who initiates the protocol and tentially all standard compliant Bluetooth devices, regardless
the roles (master or slave) of the victims in the piconet. their Bluetooth version number and implementation details.
We believe that the encryption key negotiation protocol has to
be fixed as soon as possible.
3.3 Brute forcing the Encryption Key In particular the KNOB attack has serious implications
Bluetooth has two link layer encryption schemes one is based related to its effectiveness, stealthiness, and cost. The attack
on the E0 cipher (legacy) and the other on the AES-CCM ci- is effective because it exploits a weakness in the specification
pher (Secure Connections). Our KNOB attack works in both of Bluetooth. The Bluetooth security mode does not matter,
cases. If the negotiated entropy for the encryption key (KC0 ) is i.e., the attack works even with Secure Connections. The
1 byte, then the attacker can trivially brute force it trying (in implementation details do not matter, e.g., whether Bluetooth
parallel) the 256 KC0 ’s candidates against one or more cipher is implemented in hardware or in software. The time con-
texts. The attacker does not have to know what type of ap- straints imposed by the Bluetooth protocols do not matter
plication layer traffic is exchanged, because a valid plaintext because the attacker can eavesdrop the traffic and brute force
contains well known Bluetooth fields, such as L2CAP and the low-entropy key offline. The type of connection does
RFCOMM headers, that the attacker can use as oracles. not matter, e.g., the attack works with long-lived and short-
We now describe how to compute all 1 byte entropy keys lived connections. In a long-lived connection, e.g.,victims
when E0 and AES-CCM are in use. Each encryption mode are a laptop and a Bluetooth keyboard, the attacker has to
involves a specific entropy reduction procedure that takes N negotiate and brute force a single low-entropy KC0 . In a short-
and KC as inputs and produces KC0 as output (Entropy Reduc- lived connection, e.g.,victims are two devices transferring
tion in Figure 2). The specification of Bluetooth calls this files over Bluetooth, the attacker has to negotiate and brute
procedure Encryption Key Size Reduction [6]. force multiple low-entropy KC0 over time re-using the same
attack technique without incurring in significant runtime and
computational overheads.
 
(N) (N)
KC0 = g2 ⊗ KC mod g1 (Es )
The attack is stealthy because only the Bluetooth con-
trollers (implemented in the victims’ Bluetooth chip) are
In case of E0 , KC0 is computed using Equation (Es ), where
aware of N and KC0 . By design, the controllers are not notify-
N is an integer between 1 and 16 resulted from the encryption
(N) ing the Bluetooth hosts (implemented in the OSes) about N,
key negotiation protocol (see Section 3.2). g1 is a polyno- but only about the outcome of the entropy negotiation. The
mial of degree 8N used to reduce the entropy of KC to N users and the Bluetooth application developers are unaware of
bytes. The result of the reduction is encoded with a block this problem because they use Bluetooth link-layer encryption
(N)
code g2 , a polynomial of degree less or equal to 128 − 8N. as a trusted service.
The values of these polynomials depend on N and they are The attack is cheap because it does not require a strong
tabulated in [6, p. 1668]. If N = 1, then we can compute attacker model and expensive resources to be conducted. We
the 256 candidate KC0 by multiplying all the possible 1 byte expect that a remote attacker with commercial-off-the-shelf
(1) (1)
reductions KC mod g1 (the set 0x00. . . 0xff) with g2 (that devices such as a software defined radio, GNU Radio and a
equals to 0x00e275a0abd218d4cf928b9bbf6cb08f). laptop can conduct the attack.

1052 28th USENIX Security Symposium USENIX Association

3.5 KNOB Attack Root Causes
The root causes of the KNOB attack are shared between the
specification and the implementation of Bluetooth BR/EDR
confidentially mechanisms. On one side the specification
is defining a vulnerable encryption key negotiation protocol
that allows devices to negotiate low entropy values. On the
implementation side (see Section 5), the Bluetooth applica-
Figure 5: Transmission and reception of an E0 encrypted
tions that we tested are failing to check the negotiated entropy
payload. The concatenation of the payload and its CRC (PT x )
in practice. This is understandable because they are imple-
is encrypted, whitened, encoded and then transmitted. On the
menting a specification that is not mandating or explicitly
receiver side the steps are applied in the opposite order. RF is
recommending an entropy check.
the radio frequency wireless channel.
We do not see any reason to include the encryption key ne-
gotiation protocol in the specification of Bluetooth. From our
experiments (presented in Section 5) we observe that if two
know about. To brute force KC0 and decrypt the ciphertext we
devices are not attacked they always use it in the same way (a
use a ThinkPad X1 laptop running a Linux based OS.
device proposes 16 bytes of entropy and the other accepts).
The victims use the following security procedures: Secure
Furthermore, the entropy reduction does not improve runtime
Simple Pairing to generate KL (the link key) and authenticate
performances because the size of the encryption key is fixed
the users, the entropy reduction function from Equation (Es ),
to 16 bytes even when its entropy is reduced.
and E0 legacy encryption. The victims use legacy encryption
because the Nexus 5 does not support Secure Connections.
4 Implementation Nevertheless, the KNOB attack works also with Secure Con-
nections.
We now discuss how we implemented the KNOB attack using Every E0 -encrypted packet that contains data is transmitted
a reference attack scenario. In particular, we explain how and received as in Figure 5. A cyclic redundancy checksum
we manipulate the key negotiation protocol, brute force the (CRC) is computed and appended to the payload (PayT x ).
encryption key (KC0 ) using eavesdropped traffic, and validate The resulting bytes (PT x ) are encrypted with E0 using KC0 .
KC0 by computing it from KL as a legitimate device (as in The ciphertext is whitened, encoded, and transmitted over
Figure 2). In our attack scenario, the attacker is able to decrypt the air. On the receiver side the following steps are applied
the content of a link-layer encrypted file sent from a Nexus 5 in sequence: decoding, de-whitening, decryption, and CRC
to a Motorola G3 using the Bluetooth OBject EXchange check. The encryption and decryption procedures are the
(OBEX) profile. A Bluetooth profile is the equivalent of an same because E0 is a stream cipher, i.e., the same keystream is
application layer protocol in the TCP/IP stack. XORed with the plaintext and the ciphertext. Whitening and
Our implementation required significant efforts mainly due encoding procedures do not add any security guarantee and
to the lack of low-cost Bluetooth protocol analyzers and soft- the Ubertooth One is capable of performing both procedures.
ware libraries implementing the custom Bluetooth security
primitives (such as the modified SAFER+ block cipher). Us-
4.2 Manipulation of the Entropy Negotiation
ing our implementation we conducted successful KNOB at-
tacks on more than 14 different Bluetooth chips, the attacks We implement the manipulation of the encryption key nego-
are evaluated in Section 5. tiation protocol (presented in Section 3.2) by extending the
functionalities of InternalBlue [21] and using it to patch the
Bluetooth chip firmware of the Nexus 5. Our InternalBlue
4.1 Attack Scenario
modifications allow to manipulate all incoming LMP mes-
To describe our implementation we use an attack scenario sages before they are processed by the entropy negotiation
with two victims a Nexus 5 and a Motorola G3, Table 1 logic, and all outgoing LMP messages after they’ve been
lists their relevant specifications. The Nexus 5 is used also processed by the entropy negotiation logic. The entropy ne-
as a man-in-the-middle attacker by adding extra code to its gotiation logic is the code in the Nexus 5 Bluetooth firmware
Bluetooth firmware. This setup allows us to simulate a remote that manages the encryption key negotiation protocol, and
man-in-the-middle attacker (more details in Section 4.2). To we do not modify it. As a result, we can use a Nexus 5 (or
perform eavesdropping, we use an Ubertooth One [24] with any other device supported by InternalBlue) as a victim and
firmware version 2017-03-R2 (API:1.02). To the best of our a remote KNOB attacker without having to deal with the
knowledge, Ubertooth One does not capture all Bluetooth practical issues related with wireless attacks over-the-air.
BR/EDR packets, but it is the only open-source, low-cost, InternalBlue is an open-source toolkit capable of interfac-
and practical eavesdropping solution for Bluetooth that we ing with the firmware of the BCM4339 Bluetooth chip in

USENIX Association 28th USENIX Security Symposium 1053

 Bluetooth
Phone OS Version MAC SC Chip
Nexus 5 Android 6.0.1 4.1 48:59:29:01:AD:6F No Broadcom BCM4339
Motorola G3 Android 6.0.1 4.1 24:DA:9B:66:9F:83 Yes Qualcomm Snapdragon 410

Table 1: Relevant technical specifications of Nexus 5 and Motorola G3 devices used to describe our attack implementation. The
SC column indicates if a device supports Secure Connections.

Nexus 5 phones. To use it, one has to root the target Nexus 5 whenever an LMP packet is received. The hooks are intended
and compile and install the Android Bluetooth stack with for LMP monitoring, and we upgraded them to be used also
debugging features enabled. InternalBlue allows to patch the for LMP manipulation.
firmware in real-time (e.g., start LMP monitoring) and read Listing 1 shows three ARM assembly code blocks that we
the ROM and the RAM of firmware at runtime. Internal- added to fw 5.py to let the Nexus 5 and the Motorola G3
Blue provides a way to hook and execute arbitrary code in negotiate 1 byte of entropy. In this case the Nexus 5 is the
the Bluetooth firmware. At the time of writing, InternalBlue master and it initiates the encryption key negotiation protocol.
is not capable of hooking directly the key negotiation logic. The first block translates to: if the Nexus 5 is sending an
However, we managed to extend it to enable two victims (one LMP KC0 entropy proposal then change it to 1 byte. This
is always the Nexus 5) to negotiate one (or more) byte of block is executed when the Nexus 5 starts an encryption key
entropy. negotiation protocol. The code allows to propose any entropy
Our manipulation of the entropy negotiation works regard- value by moving a different constant into r2 in line 5.
less the role of the Nexus 5 in the piconet and it does not The second block from Listing 1 translates to: if the
require to capture any information about the Secure Simple Nexus 5 is receiving an LMP accept (entropy proposal), then
Pairing process. Assuming that the victims are already paired, change it to an LMP KC0 entropy proposal of 1 byte. This
we test if two victims are vulnerable to the KNOB attack as code is used to let the Nexus 5 firmware believe that the other
follows: victim proposed 1 byte, while she already accepted 1 byte (as-
suming that she is vulnerable). The third blocks translates to:
1. We connect over USB the Nexus 5 with the X1 laptop, if the Nexus 5 is sending an LMP accept (entropy proposal),
we run our version of InternalBlue, and we activate LMP then change it to an LMP preferred rate. This allows to obtain
and HCI monitoring. the same result of dropping an LMP accept packet because
the LMP preferred rate packet does not affect the state of the
2. We connect and start the Ubertooth One capture over the
encryption key negotiation protocols. We developed and used
air focusing only on the Nexus 5 piconet (using UAP
similar patches to cover the other attack cases: Nexus 5 is the
and LAP flags).
master and does not initiate the connection, Nexus 5 is the
3. We request a connection from the Nexus 5 to the victim slave and initiates the connection and Nexus 5 is the slave
(or vice versa) to trigger the encryption key negotiation and does not initiate the connection.
protocol over LMP.

4. Our InternalBlue patch changes the LMP packets as 4.3 Brute Forcing the Encryption Key
Charlie does in Figure 4.
Once the attacker is able to reduce the entropy of the en-
5. If the victims successfully complete the protocol, then cryption key (KC0 ) to 1 byte, he has to brute force the key
they are vulnerable to the KNOB attack and we can value (key space is 256). In this section we explain how we
decrypt the ciphertext captured with the Ubertooth One. brute forced and validated a E0 encryption key with 1 byte
of entropy. The key was used in one of our KNOB attacks
We now describe how we extended InternalBlue to perform to decrypt the content of a file transferred over a link layer
the fourth step of the list. In this context, the most important encrypted Bluetooth connection.
file of InternalBlue is internalblue/fw 5.py. This file The details about the E0 encryption scheme are presented
contains all the information about the BCM4339 firmware, in Figure 6, we describe them backwards starting from the E0
and it provides two hooks into the firmware, defined by Mantz cipher. E0 takes three inputs: BTADDM , CLK26-1 and KC0 .
(the main author of InternalBlue) as LMP send packet and CLK26-1 are the 26 bits of CLK in the interval CLK[25:1]
LMP dispatcher. The former hook allows to execute code (assuming that CLK stores its least significant bit at CLK[0]).
every time an LMP packet is about to be sent and the latter The BTADDM is the Bluetooth address of the master and it

1054 28th USENIX Security Symposium USENIX Association

Listing 1 We add three ARM assembly code blocks to
internalblue/fw 5.py to negotiate KC0 with 1 byte of en-
tropy. In this case the Nexus 5 is the master and it initiates
the encryption key negotiation protocol.
1 # Send LMP Kc' entropy 1 rather than 16
2 ldrb r2, [r1]
3 cmp r2, #0x20
4 bne skip_sent_ksr
5 mov r2, #0x01
6 strb r2, [r1, #1]
7 skip_sent_ksr:
8
9 # Recv LMP Kc' entropy 1 rather than LMP accept
10 ldrb r2, [r1]
11 cmp r2, #0x06
12 bne skip_recv_aksr Figure 6: Implementation of the KNOB attack on the E0
13 ldrb r2, [r1, #1] cipher. The attacker makes the victims agree on a KC0 with
14 cmp r2, #0x10 one byte of entropy (N = 1) and then brute force KC0 , without
15 bne skip_recv_aksr knowing KL and KC .
16 mov r2, #0x20
17 strb r2, [r1]
18 mov r2, #0x01
19 strb r2, [r1, #1] is used to compute the Ciphering Offset Number (COF), the
20 skip_recv_aksr: latter to compute KC (see Figure 6). Both procedures use a
21
22 # Send LMP_preferred rate rather than LMP accept
custom hash function defined in the specification of Bluetooth
23 # Simulate an attacker dropping LMP accept with H. We write E1 and E3 equations and label them with
24 ldrb r2, [r1] their respective names as follows:
25 cmp r2, #0x06
26 bne skip_send_aksr SRESkACO = H(KL , AU RAND, BTADDS , 6) (E1 )
27 ldrb r2, [r1, #1]
28 cmp r2, #0x10 KC = H(KL , EN RAND, COF, 12) (E3 )
29 bne skip_send_aksr
30 mov r2, #0x48 Figure 7 shows how E3 uses the H hash function, H inter-
31 strb r2, [r1]
32 mov r2, #0x70 nally uses SAFER+, a block cipher that was submitted as an
33 strb r2, [r1, #1] AES candidate in 1998 [22]. SAFER+ is used with 128 bit
34 skip_send_aksr: block size (8 rounds), in ECB mode, and only for encryption.
SAFER+’ (SAFER+ prime) is a modified version of SAFER+
such that the input of the first round is added to the input
of the third round. This modification was introduced in the
is a public parameter. We did not have to implement the E0 specification of Bluetooth to avoid SAFER+’ being used for
cipher because we found an open-source implementation [8] encryption [6, p. 1677].
which we verified against the specification of Bluetooth. To We implemented in Python both SAFER+ and SAFER+’
provide valid KC0 candidates to E0 we had to implement the Es including the round computations and the key scheduling
entropy reduction procedure. This procedure takes an input algorithm. We tested the two against the specification of Blue-
with 16 bytes of entropy (KC ) and computes an output with N tooth (where they are indicated with Ar and Ar ’ [6, p. 1676]).
bytes of entropy (KC0 ). Es involves modular arithmetic over We also implemented the E and O blocks from Figure 7. The
polynomials in Galois fields and we use the BitVector [16] E block is an extension block that transforms the 12 byte COF
Python module to perform such computations. into a 16 byte sequence using modular arithmetic. The same
Our Python brute force script takes a ciphertext (captured block is applied to the 6 byte BTADDS in E1 . The O block
over the air using Ubertooth One) and tries to decrypt it is offsetting KL using algebraic (modular) operations and the
by using the E0 cipher with all possible values of KC0 . We largest primes below 257 for which 10 is a primitive root. We
validate our script by decrypting the content of a file sent from implement the E and O blocks in Python and we tested them
the Nexus 5 to the Motorola G3 using the OBEX Bluetooth against the specification of Bluetooth. Then, we were able to
profile after the negotiation of 1 byte of entropy. The content implement H and to use it to implement and test E3 and E1 .
of the file (in ASCII) is aaaabbbbccccdddd. We discuss We validate the brute forced KC0 by using the necessary pa-
several brute forcing practical issues in Section 6.3. rameters from Figure 6 to compute KC0 from KL . We captured
Once we found the matching plaintext we wanted to verify the parameters using the Bluetooth logging capabilities of-
that the brute forced key was effectively the one in use by the fered by Android. Table 2 shows an example of actual public
victims. To do that we had to implement E1 and E3 , the former and private values used during one of our KNOB attacks. We

USENIX Association 28th USENIX Security Symposium 1055

 5 Evaluation
Our implementation of the KNOB attack (presented in Sec-
tion 4) allows to test if any device accepts an encryption key
with 1 byte of entropy (N = Lmin = 1). We focus our discus-
sion on the attack best case (1 byte of entropy) while arguably
any entropy value lower than 14 bytes could be considered
not secure for symmetric encryption [3].
After successfully conducting the KNOB attack on a
Nexus 5 and a Motorola G3 we conducted other KNOB at-
tacks on more than 14 unique Bluetooth chips (by attacking
Figure 7: Bluetooth defines H a custom hash function based
21 different devices). Each attack is easy to reproduce and
on SAFER+. H is used to compute KC from KL , EN RAND,
testing if a device is vulnerable is a matter of seconds.
and COF (see Equation E3 ).
Based on our experiments, we concluded that there are
no differences between the specification and the implemen-
Name Value tation of both the Bluetooth controller (implemented in the
firmware) and the Bluetooth host (implemented in the OS
Public and usable as an interface by a Bluetooth application). In the
BTADDM 0xccfa0070dcb6 former case the specification is not enforcing any minimum
BTADDS 0x829f669bda24 Lmin and it is not protecting the entropy negotiation protocol.
AU RAND 0x722e6ecd32ed43b7f3cdbdc2100ff6e0 The firmware’s implementers (to provide standard-compliant
EN RAND 0xd72fb4217dcdc3145056ba488bea9076 products) are allowing the negotiation of 1 byte of entropy
SRES 0xb0a3f41f with an insecure protocol. The only exception is the Apple
N 0x1 W1 chip where an attacker can only reduce the entropy to 7
Secret bytes. In the latter case, the Bluetooth specification is provid-
KL 0xd5f20744c05d08601d28fa1dd79cdc27 ing an HCI Read Encryption size API but it is not mandating
COF=ACO 0x1ce4f9426dc2bc110472d68e or recommending its usage, e.g., a mandatory check at the
KC 0xa3fccef22ad2232c7acb01e9b9ed6727 end of the LMP entropy negotiation. The host’s implementers
KC0 0x7fffffffffffffffffffffffffffffff are providing this API and the applications that we tested are
not using it.
Table 2: Public and secret values (in hexadecimal representa-
tion) collected during a KNOB attack involving authenticated
SSP and E0 encryption. The encryption key (KC0 ) has 1 byte
5.1 Evaluation Setup
of entropy. To perform our evaluation we collected as many devices as
possible containing different Bluetooth chips. At the time
of writing, we were able to test chips from Broadcom, Qual-
plan to release our code implementing Es , E1 and E3 as open- comm, Apple, Intel, and Chicony manufacturers. For each
source to help researchers interested in Bluetooth’s security, chip we conducted the KNOB attack following the same
after we complete the responsible disclosure of our findings1 . five steps presented in Section 4.2. As explained earlier, the
Nexus 5 is used as a (remote) attacker and a victim. For each
test we recorded the manipulated encryption key negotiation
protocol over LMP in a pcapng file and we manually verified
4.4 Implementation for Secure Connections the protocol’s outcome with Wireshark.
Our evaluation setup is not hard to reproduce and easy
The specification of Bluetooth allows to perform the KNOB to extend because it does not require expensive hardware
attack even when the victims are using Secure Connections. and uses open-source software. We would like to see other
We already implemented the entropy reduction function of the researchers evaluating more Bluetooth chips and devices that
brute force script over AES–CCM. However, at the time of currently we do not posses, e.g., Apple Watches.
writing, InternalBlue is not capable of patching the firmware
of a Bluetooth chip that supports Secure Connections, indeed
we are not able to implement the low entropy negotiation part 5.2 Evaluation Results
of the attack using InternalBlue.
Table 3 shows our evaluation results. Overall, we tested more
than 14 Bluetooth chips and 21 devices. The first column
1 See https://github.com/francozappa/knob contains the Bluetooth chip names. We fill the entries of this

1056 28th USENIX Security Symposium USENIX Association

 Bluetooth chip Device(s) Vuln? across different Bluetooth versions including the latest ones
such as 5.0 and 4.2. This fact confirms that the KNOB attack
Bluetooth Version 5.0
is a significant threat for all Bluetooth users and we believe
Snapdragon 845 Galaxy S9 X
that the specification of Bluetooth has to be fixed as soon as
Snapdragon 835 Pixel 2, OnePlus 5 X
possible.
Apple/USI 339S00428 MacBookPro 2018 X
Apple A1865 iPhone X X
Bluetooth Version 4.2 6 Discussion
Intel 8265 ThinkPad X1 6th X
Intel 7265 ThinkPad X1 3rd X 6.1 Attacking Other Bluetooth Profiles
Unknown Sennheiser PXC 550 X Cable replacement wireless technologies such as Bluetooth
Apple/USI 339S00045 iPad Pro 2 X are widely used for all sorts of applications including desktop,
BCM43438 RPi 3B, RPi 3B+ X mobile, IoT, industrial and medical devices. Bluetooth defines
BCM43602 iMac MMQA2LL/A X its set of application layer services as profiles. In Section 4
Bluetooth Version 4.1 we describe an attack on the OBject EXchange (OBEX) Blue-
BCM4339 (CYW4339) Nexus 5, iPhone 6 X tooth profile, where the attacker breaks Bluetooth security by
Snapdragon 410 Motorola G3 X decrypting the content of an encrypted file without having
access to any (pre-shared) secret. Here we describe three
Bluetooth Version ≤ 4.0
KNOB attacks targeting other popular Bluetooth profiles. As
Snapdragon 800 LG G2 X
in the OBEX case, the attacks have serious implications in
Intel Centrino 6205 ThinkPad X230 X
terms of security and privacy of the victims. To the best of
Chicony Unknown ThinkPad KT-1255 X
our knowledge, all the profiles that we discuss in this section
Broadcom Unknown ThinkPad 41U5008 X
rely only on the link-layer for their security guarantees and
Broadcom Unknown Anker A7721 X
they are widely used across different vendors. Our list of
Apple W1 AirPods *
attacks is not exhaustive and an attacker might exploit the
vulnerable encryption key negotiation protocol of Bluetooth
Table 3: List of Bluetooth chips and devices tested against
in other creative ways.
the KNOB attack. Xindicates that a chip accepts one byte of
entropy. * indicates that a chip accepts at least seven bytes
of entropy. We note that, all chips and devices implementing HID profile The attacker could perform a remote keylog-
any specification of Bluetooth are expected to be vulnerable ging attack on any device that uses the Human Interface
to the KNOB attack because the entropy reduction feature is Device (HID) profile. This profile is used by input-output de-
standard-compliant. vices such as keyboards, mice and joysticks. As a result, the
attacker can sniff sensitive information including passwords,
credit card numbers, and emails regardless if these informa-
column with Unknown when we are not able to find informa- tion are then encrypted on the (wired or wireless) Ethernet
tion about the chip manufacturer and/or model number. The link.
second column lists the devices that we tested grouped by
chip, e.g., the Snapdragon 835 is used both by the Pixel 2 Bluetooth tethering The attacker could mount a remote
and the OnePlus 5. The third column contains a X if the man-in-the-middle attack when the victim uses Bluetooth
Bluetooth chip accepts 1 byte of entropy and a * if it accepts for tethering. Tethering is used by a device, acting as an
at least 7 bytes. The table’s rows are grouped by Bluetooth hotspot, to share Internet connectivity with other devices
version in four blocks: version 5.0, version 4.2, version 4,1 in range. Bluetooth transports Ethernet over the Bluetooth
and version lower or equal than 4.0. Network Encapsulation Protocol (BNEP) [5]. This protocol
From the third column of Table 3 we see that all the chips encapsulates Ethernet frames and transports them over (link-
accept 1 byte of entropy (X) except the Apple W1 chip (*) layer encrypted) L2CAP. As a result, the attacker can sniff all
that requires at least 7 bytes of entropy. Apple W1 and its Internet traffic of the victims using a Bluetooth hotspot.
successors are used in devices such as AirPods, and Apple
Watches. Seven bytes of entropy are better than one, but A2DP profile The attacker could record and inject audio
not enough to prevent brute force attacks. For example, the signals when the victim uses the Advanced Audio Distribution
Data Encryption Standard (DES) uses the same amount of Profile (A2DP) profile. As a result, the attacker is able to
entropy and DES keys were brute forced multiple times with record phone and Voice over IP (VoIP) calls even if the call
increasing efficacy [19]. is encrypted (e.g., 4G and Skype). The attacker can also
Table 3 also demonstrates that the vulnerability spans tamper with voice commands sent to a personal assistant, e.g.,

USENIX Association 28th USENIX Security Symposium 1057

Siri and Google Assistant. Recent mobile devices, such as 6.4 Countermeasures
smartphone and tablets, are particularly vulnerable to this
threat because Bluetooth is a convenient solution to the lack In this section we propose several countermeasures to the
of an analog audio connector (audio jack). KNOB attack. We divide them into two classes: legacy com-
pliant and non legacy compliant. The former type of coun-
termeasure does not require a change to the specification of
Bluetooth while the latter does. We already proposed these
6.2 Attacking Multiple Nodes and Piconets countermeasures to the Bluetooth SIG and CERT during our
responsible disclosure.
In our paper we describe the implementation of KNOB at-
tacks targeting two victims. If a Bluetooth piconet contains
more than two devices, then (in the worst case for the attacker) Legacy compliant. Our first proposed legacy compliant
each master-slave pair uses a dedicated set of keys. In this countermeasure is to require a minimum and maximum
scenario the KNOB attack still works because it can be par- amount of negotiable entropy that cannot be easily brute
allelized with minimal effort. For example, the attacker may forced, e.g., require 16 bytes of entropy. This means fixing
run the same attack script on different computing units, such Lmin and Lmax in the Bluetooth controller (firmware) and re-
as processes or machines, and let each computing unit target sults in the negotiation of proper encryption keys. Another
a master-slave pair. Each parallel instance of the attack nego- possible countermeasure is to automatically have the Blue-
tiates an encryption key with one byte of entropy, captures tooth host (OS) check the amount of negotiated entropy each
the exchanged ciphertext, and brute forces the encryption key. time link layer encryption is activated and abort the connec-
For example, an attacker is able to decrypt all the traffic from tion if the entropy does not meet a minimum requirement.
a victim using multiple Bluetooth I/O devices to interact with The entropy value can be obtained by the host using the HCI
his device e.g., a laptop connected with a keyboard, a mouse Read Encryption Key Size Command. This solution requires
and an headset. to modify the Bluetooth host and it might be suboptimal be-
cause it acts on a connection that is already established (and
The KNOB attack is effective even if the attacker wants
possibly in use), not as part of the entropy negotiation proto-
to target multiple piconets (Bluetooth networks) at the same
col. A third solution is to distrust the link layer and provide
time. In this case the attacker has to follow and use a different
the security guarantees at the application layer. Some vendors
Bluetooth clock (CLK) value for each piconet to compute
have done so by adding a custom application layer security
the correct encryption key. This is not a problem because the
mechanism on top of Bluetooth (which, in case of Google
attacker can use parallel KNOB attack instances, where each
Nearby Connections, was also found to be vulnerable [1]).
instance follows a pair of devices in a target piconet.

Non legacy compliant. A non legacy compliant counter-

measure is to modify the encryption key negotiation protocol
6.3 Practical Implementation Issues by securing it using the link key. The link key is a shared (and
possibly authenticated) secret that should be always available
We spent considerable time to fine tune our brute force script.
before starting the entropy negotiation protocol. The new pro-
One main reason is that Ubertooth One, used to sniff Blue-
tocol should provide message integrity and might also provide
tooth BR/EDR packets over the air, does not reliably capture
confidentiality. Preferably, the specification should get rid of
all packets and clock values (CLK). This is true even if we
the entropy negotiation protocol and always use encryption
limit our capture to a specific piconet by setting the UAP and
keys with a fixed amount of entropy, e.g., 16 bytes. The im-
LAP parameters. As a result, we had to include extra logic in
plementation of these solutions only requires the modification
our brute force script to iterate over different CLK values and
of the Bluetooth controller (firmware).
E0 keystream offsets. Our basic brute force logic only iterates
over the encryption key space (256 iterations). The extra
logic can be removed if we get access to a commercial-grade 7 Related Work
Bluetooth protocol analyzer such as Ellisys [10] or similar.
Unfortunately, these devices are very expensive. The security and privacy guarantees of Bluetooth were studied
We implemented our attack by simulating a remote attacker since Bluetooth v1.0 [15, 32]. Particular attention was given
using InternalBlue. Alternatively, we could have conducted to Secure Simple Pairing (SSP), a mechanisms that Bluetooth
the attacks over the air using signal manipulation [26] and uses to generate and share a long term secret (defined as the
(reactive) jamming [31]. However, the InternalBlue setup is link key). Several attacks on the SSP protocol were proposed
simpler, more reliable, cheaper, and easier to reproduce than [28, 13, 4]. The Key Negotiation Of Bluetooth (KNOB)
the over-the-air setup and it affects the victims in the same attack works regardless of security guarantees provided by
way as a remote attacker. SSP (such as mutual user authentication).

1058 28th USENIX Security Symposium USENIX Association

 The most up to date survey about Bluetooth security was Bluetooth host (OS) and the Bluetooth application used by
provided by NIST in 2017 [25]. This survey recommends to the victims. We expect that the attack could be run in parallel
use 128 bit keys (16 bytes of entropy). It also describes the to target multiple devices and piconets at the same time.
key negotiation protocol, and considers it as a security issue We demonstrate that the KNOB attack can be performed
when one of the connected devices is malicious (and not a in practice by implementing it to attack a Nexus 5 and a Mo-
third party). Prior surveys do not consider the problem of torola G3. In our attack we decrypt a file transmitted over
encryption key negotiation at all [9] or superficially discuss an authenticated and link-layer encrypted Bluetooth connec-
it [29]. tion. Brute-forcing a key with 1 byte of entropy introduces
The various implementation of Bluetooth were also ana- a negligible overhead enabling an attacker to decrypt all the
lyzed and several attacks were presented on Android, iOS, ciphertext and to introduce valid ciphertext even in real-time.
Windows and Linux implementations [2]. Our attack works We evaluate the KNOB attack on more than 14 Bluetooth
regardless of the implementation details of the target platform, chips from different vendors such as Broadcom, Qualcomm
because if any implementation is standard-compliant then it and Intel. All the chips accept 1 byte of entropy except the Ap-
is vulnerable to the KNOB attack. ple W1 chip that accepts (at least) 7 bytes of entropy. Frankly,
The security of the ciphers used by Bluetooth has been we were expecting to find more non standard-compliant chips
extensively discussed by cryptographers. The SAFER+ ci- like the Apple W1. Before submitting the paper, we reported
pher used by Bluetooth for authentication purposes was ana- our findings to the Computer Emergency Response Team
lyzed [17]. The E0 cipher used by Bluetooth for encryption (CERT) and the Bluetooth Special Interest Group (SIG). Both
was also analyzed [11]. Our attack works even with per- organizations acknowledged the problem and we are collabo-
fectly secure ciphers. For our implementation of the custom rating with them to solve it. After our responsible disclosure,
Bluetooth security procedures (presented in Section 4) we we plan to release the tools that we developed to implement
used as main references the specification of Bluetooth [6] and the attacks as open-source.
third-party hardware [18] and software [20] implementations. The KNOB attack is a serious threat to the security and
Third-party manipulations of key negotiation protocols privacy of all Bluetooth users. We were surprised to discover
were also discussed in the context of WiFi, for example key such fundamental issues in a widely used and 20 years old
reuse in [30]. Compared to those attacks, our attack exploits standard. We attribute the identified issues in part to am-
not only implementation issues, but a standard-compliant biguous phrasing in the standard, as it is not clear who is
vulnerability of the specification of Bluetooth. responsible for enforcing the entropy of the encryption keys,
Protocol downgrade attacks were discussed in the context and as a result no-one seems to be responsible in practice.
of TLS[23], where the two parties are negotiating the cipher We urge the Bluetooth SIG to update the specification of
suite to use. We note that in contrast to our scenario, for TLS Bluetooth according to our findings. Until the specification
the application developers have commonly direct control over is not fixed, we do not recommend to trust any link-layer en-
the cipher suites that will be offered by their applications. crypted Bluetooth BR/EDR link. In Section 6.4 we propose
Therefore, avoiding a fallback to legacy encryption standards legacy and non legacy compliant countermeasures that would
can be prevented by the developers. To the best of our knowl- make the KNOB attack impractical. We also recommend
edge, this is not the case for Bluetooth, as the protocols does the Bluetooth SIG to create a dedicated procedure enabling
not enforce any mandatory checks on the encryption key’s researchers to securely submit new potential vulnerabilities,
entropy. similarly to what other companies, such as Google, Microsoft
and Facebook, are offering.
8 Conclusion
References
In this paper we present the Key Negotiation Of Bluetooth
(KNOB) attack. Our attack is capable of reducing the entropy [1] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper
of the encryption key of any Bluetooth BR/EDR connection Rasmussen. Nearby Threats: Reversing, Analyzing, and
to 1 byte (8 bits). The attack is standard-compliant because Attacking Google’s “Nearby Connections” on Android.
the specification of Bluetooth includes an insecure encryption In Network and Distributed System Security Symposium
key negotiation protocol that supports entropy values between (NDSS), February 2019.
1 and 16 bytes. As a main consequence, an attacker can easily
negotiate an encryption key with low entropy and then brute [2] Armis Inc. The Attack Vector BlueBorne Exposes Al-
force it. The attacker is effectively breaking the security most Every Connected Device. https://armis.com/
guarantees of Bluetooth without having to posses any (pre- blueborne/, Accessed: 2018-01-26.
shared) secret material. The attack is stealthy because the
vulnerable entropy negotiation protocol is run by the victims’ [3] Elaine Barker, William Barker, William Burr, William
Bluetooth controller and this protocol is transparent to the Polk, and Miles Smid. Recommendation for key man-

USENIX Association 28th USENIX Security Symposium 1059

 agement part 1: General (revision 3). NIST special [17] John Kelsey, Bruce Schneier, and David Wagner. Key
publication, 800(57):1–147, 2012. schedule weaknesses in SAFER+. In The Second Ad-
vanced Encryption Standard Candidate Conference,
[4] Eli Biham and Lior Neumann. Breaking the blue- pages 155–167, 1999.
tooth pairing–fixed coordinate invalid curve attack.
http://www.cs.technion.ac.il/~biham/BT/bt- [18] Paraskevas Kitsos, Nicolas Sklavos, Kyriakos Papado-
fixed-coordinate-invalid-curve-attack.pdf, manolakis, and Odysseas Koufopavlou. Hardware im-
Accessed: 2018-10-30. plementation of Bluetooth security. IEEE Pervasive
Computing, (1):21–29, 2003.
[5] Bluetooth SIG. Bluetooth Network Encapsulation Proto-
col. http://grouper.ieee.org/groups/802/15/ [19] Sandeep Kumar, Christof Paar, Jan Pelzl, Gerd Pfeif-
Bluetooth/BNEP.pdf, Accessed: 2018-10-28, 2001. fer, and Manfred Schimmler. Breaking ciphers with
copacobana–a cost-optimized parallel code breaker. In
[6] Bluetooth SIG. Bluetooth Core Specification International Workshop on Cryptographic Hardware
v5.0. https://www.bluetooth.org/DocMan/ and Embedded Systems, pages 101–118. Springer, 2006.
handlers/DownloadDoc.ashx?doc_id=421043,
Accessed: 2018-10-28, 2016. [20] Musaria K Mahmood, Lujain S Abdulla, Ahmed H
Mohsin, and Hamza A Abdullah. MATLAB Imple-
[7] Bob Cromwell. The Problem With Government- mentation of 128-key length SAFER+ Cipher System.
Imposed Backdoors. https://cromwell-intl.com/
cybersecurity/backdoors.html, Accessed: 2019- [21] Dennis Mantz. Internalblue. https://github.com/
2-4. seemoo-lab/internalblue, Accessed: 2018-10-30.
[8] Arnaud Delmas. A C implementation of the Bluetooth [22] James L Massey, Gurgen H Khachatrian, and Melsik K
stream cipher E0. https://github.com/adelmas/ Kuregian. Nomination of SAFER+ as candidate algo-
e0, Accessed: 2018-10-28. rithm for the Advanced Encryption Standard (AES).
NIST AES Proposal, 1998.
[9] John Dunning. Taming the blue beast: A survey of blue-
tooth based threats. IEEE Security & Privacy, 8(2):20– [23] Bodo Möller, Thai Duong, and Krzysztof Kotow-
27, 2010. icz. This POODLE bites: exploiting the SSL 3.0
fallback. https://www.openssl.org/~bodo/ssl-
[10] Ellisys. Ellisys protocol test solutions. https://www.
poodle.pdf, Accessed: 2019-02-04, 2014.
ellisys.com/, Accessed: 2018-10-28.
[24] Michael Ossmann. Project Ubertooth. https://
[11] Scott Fluhrer and Stefan Lucks. Analysis of the E0 en-
github.com/greatscottgadgets/ubertooth, Ac-
cryption system. In International Workshop on Selected
cessed: 2018-11-01.
Areas in Cryptography, pages 38–48. Springer, 2001.

[12] Glenn Greenwald. No place to hide: Edward Snowden, [25] John Padgette. Guide to bluetooth security. NIST Special
the NSA, and the US surveillance state. Metropolitan Publication, 800:121, 2017.
Books, 2014. [26] Christina Pöpper, Nils Ole Tippenhauer, Boris Danev,
[13] Keijo Haataja and Pekka Toivanen. Two practical man- and Srdjan Čapkun. Investigation of signal and message
in-the-middle attacks on bluetooth secure simple pairing manipulations on the wireless channel. In Proceedings
and countermeasures. IEEE Transactions on Wireless of the European Symposium on Research in Computer
Communications, 9(1), 2010. Security (ESORICS), December 2011.

[14] IETF. Counter with CBC-MAC (CCM). https:// [27] Jordan Robertson and Michael Riley. The Big
www.ietf.org/rfc/rfc3610.txt, Accessed: 2018- Hack: How China Used a Tiny Chip to Infiltrate
10-28. U.S. Companies. https://www.bloomberg.com/
news/features/2018-10-04/the-big-hack-
[15] Markus Jakobsson and Susanne Wetzel. Security weak- how-china-used-a-tiny-chip-to-infiltrate-
nesses in Bluetooth. In Cryptographers’ Track at the america-s-top-companies, Accessed: 2018-10-30.
RSA Conference, pages 176–191. Springer, 2001.
[28] Yaniv Shaked and Avishai Wool. Cracking the Blue-
[16] Avinash Kak. BitVector.py. https://engineering. tooth PIN. In Proceedings of the conference on Mobile
purdue.edu/kak/dist/BitVector-3.4.8.html, systems, applications, and services (MobiSys), pages
Accessed: 2018-10-28. 39–50. ACM, 2005.

1060 28th USENIX Security Symposium USENIX Association

[29] Juha T Vainio. Bluetooth security. In Proceedings of
Helsinki University of Technology, Telecommunications
Software and Multimedia Laboratory, Seminar on In-
ternetworking: Ad Hoc Networking, Spring, volume 5,
2000.

[30] Mathy Vanhoef and Frank Piessens. Key reinstallation

attacks: Forcing nonce reuse in WPA2. In Proceedings
of the ACM SIGSAC Conference on Computer and Com-
munications Security (CCS), pages 1313–1328. ACM,
2017.

[31] Matthias Wilhelm, Ivan Martinovic, Jens B Schmitt,

and Vincent Lenders. Short paper: reactive jamming
in wireless networks: how realistic is the threat? In
Proceedings of the fourth ACM conference on Wireless
network security, pages 47–52. ACM, 2011.
[32] Ford-Long Wong and Frank Stajano. Location privacy
in Bluetooth. In European Workshop on Security in
Ad-hoc and Sensor Networks, pages 176–188. Springer,
2005.

A Appendix
The Key Negotiation Of Bluetooth (KNOB) attack reduces
the entropy of the encryption key (KC0 ) to 1 byte (key space
has 256 elements). Table 4 shows twenty encryption keys
with one byte of entropy both for E0 and AES-CCM.

E0 KC0 in hex, MSB on the left AES-CCM KC0 in hex, MSB on the left
0x00000000000000000000000000000000 0x00000000000000000000000000000000
0x00e275a0abd218d4cf928b9bbf6cb08f 0x01000000000000000000000000000000
0x01c4eb4157a431a99f2517377ed9611e 0x02000000000000000000000000000000
0x01269ee1fc76297d50b79cacc1b5d191 0x03000000000000000000000000000000
0x0389d682af4863533e4a2e6efdb2c23c 0x04000000000000000000000000000000
0x036ba322049a7b87f1d8a5f542de72b3 0x05000000000000000000000000000000
0x024d3dc3f8ec52faa16f3959836ba322 0x06000000000000000000000000000000
0x02af4863533e4a2e6efdb2c23c0713ad 0x07000000000000000000000000000000
0x0713ad055e90c6a67c945cddfb658478 0x08000000000000000000000000000000
0x07f1d8a5f542de72b306d746440934f7 0x09000000000000000000000000000000
0x06d746440934f70fe3b14bea85bce566 0x0a000000000000000000000000000000
0x063533e4a2e6efdb2c23c0713ad055e9 0x0b000000000000000000000000000000
0x049a7b87f1d8a5f542de72b306d74644 0x0c000000000000000000000000000000
0x04780e275a0abd218d4cf928b9bbf6cb 0x0d000000000000000000000000000000
0x055e90c6a67c945cddfb6584780e275a 0x0e000000000000000000000000000000
0x05bce5660dae8c881269ee1fc76297d5 0x0f000000000000000000000000000000
0x0e275a0abd218d4cf928b9bbf6cb08f0 0x10000000000000000000000000000000
0x0ec52faa16f3959836ba322049a7b87f 0x11000000000000000000000000000000
0x0fe3b14bea85bce5660dae8c881269ee 0x12000000000000000000000000000000
0x0f01c4eb4157a431a99f2517377ed961 0x13000000000000000000000000000000

Table 4: List of twenty KC0 used by E0 (left column) and

AES-CCM (right column) when N = 1 (key space is 256).

USENIX Association 28th USENIX Security Symposium 1061