BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy

Jianliang Wu Yuhong Nan Vireshwar Kumar Dave (Jing) Tian

Purdue University Purdue University Purdue University Purdue University
wu1220@purdue.edu nan1@purdue.edu viresh@purdue.edu daveti@purdue.edu
Antonio Bianchi Mathias Payer Dongyan Xu
Purdue University EPFL Purdue University
antoniob@purdue.edu mathias.payer@nebelwelt.net dxu@cs.purdue.edu

Abstract perform a specific pairing procedure, which varies depending

on the type of the connected devices and their user-interfaces’
The Bluetooth Low Energy (BLE) protocol ubiquitously
capabilities.
enables energy-efficient wireless communication among
The major factors that have helped the rapid growth of the
resource-constrained devices. To ease its adoption, BLE re-
adoption of BLE-enabled devices are its low cost and the
quires limited or no user interaction to establish a connection
minimal setup effort required for end users. Unfortunately,
between two devices. Unfortunately, this simplicity is the root
previous research [7, 12, 22, 24, 27] has shown that these user-
cause of several security issues.
friendly features have a negative impact on the security of
In this paper, we analyze the security of the BLE link-layer,
this protocol. This concern is particularly worrisome since
focusing on the scenario in which two previously-connected
BLE communication is often used in security-sensitive de-
devices reconnect. Based on a formal analysis of the reconnec-
vices, such as physical safety devices (e.g., locks) or health
tion procedure defined by the BLE specification, we highlight
monitoring devices (e.g., medical implants) [16].
two critical security weaknesses in the specification. As a re-
sult, even a device implementing the BLE protocol correctly Researchers have pointed out and studied many implemen-
may be vulnerable to spoofing attacks. tation weaknesses in the BLE protocol by manually analyzing
its specification [2, 3, 8, 32, 35]. Additionally, some previous
To demonstrate these design weaknesses, and further study
works have also performed a formal automated analysis of the
their security implications, we develop BLE Spoofing Attacks
BLE specification [5, 29]. However, these formal approaches
(BLESA). These attacks enable an attacker to impersonate a
only focused on limited aspects of the entire protocol, such
BLE device and to provide spoofed data to another previously-
as the BLE pairing mechanism. This limitation is due to the
paired device. BLESA can be easily carried out against some
fact that it is challenging to fully formalize and automatically
implementations of the BLE protocol, such as the one used in
analyze the BLE specification. The challenges stem from the
Linux. Additionally, for the BLE stack implementations used
complexity of the BLE protocol, difficulties in modeling its
by Android and iOS, we found a logic bug enabling BLESA.
multi-layer design, and its multiple variants and optional fea-
We reported this security issue to the affected parties (Google
tures (which allow this protocol to support a wide range of
and Apple), and they acknowledged our findings.
devices with significantly different capabilities).
In this paper, we study a previously-unexplored mechanism
1 Introduction of the BLE protocol. Specifically, we focus on the mechanism
of dealing with reconnecting two previously connected de-
Bluetooth Low Energy (BLE) is the most widely utilized low- vices. This mechanism comes into play when, for instance, a
energy communication protocol, and, by 2023, the number of server device (e.g., a fitness tracker) moves out of the BLE
BLE-capable devices is expected to reach 5 billion [10]. The wireless communication range of a connected client device
BLE protocol enables wireless, short-range communication (e.g., a smartphone), and then at a later time, the two devices
which allows two devices to connect and exchange data. A get close enough to re-establish a connection.
typical usage scenario consists of a smartphone and a “gadget” To start our analysis of this scenario, we first carried out
device (such as a fitness tracker) that communicate over BLE. a formal verification of the relevant BLE link-layer specifi-
Every BLE connection involves a device acting as a client (in cation [11], by using the ProVerif protocol verifier [9]. Our
this example, the smartphone) and another device acting as formal analysis highlighted two weaknesses in the BLE of-
a server (in this example, the fitness tracker). The first time ficial specification. These weaknesses, in some BLE stack
two devices connect (allowing them to exchange data), they implementations, allow an attacker to launch a spoofing at-
tack in which the attacker pretends to be a previously-paired procedure to make it robust against BLESA.
server device, inducing a client device into accepting spoofed
data.
2 Background
In particular, we discovered that the BLE specification al-
lows implementing several aspects of this protocol in multiple The original Bluetooth (Classic) protocol was designed
ways, some of which are vulnerable. For this reason, even for short-range wireless streaming applications such as au-
BLE stack implementations correctly following the speci- dio, video, and file transfer. Different from Bluetooth Clas-
fication can potentially be susceptible to spoofing attacks. sic, Bluetooth Low Energy (BLE) is designed for energy-
For instance, we found that the BLE protocol stack (when constrained low-cost IoT applications that require an intermit-
accessed via gatttool [26]) used in Linux client devices tent transfer of smaller amounts of data at lower speeds.
(e.g., Linux laptops), while following the BLE specification The BLE protocol enables a device, acting as a server (e.g.,
correctly, is susceptible to the identified spoofing attack. a fitness tracker), to efficiently communicate relevant data
Furthermore, we discovered that even BLE protocol stacks (e.g., the number of tracked footsteps) to another connected
implemented in ways that are, in theory, not susceptible to device, acting as a client (e.g., a smartphone). In BLE, the
the identified attack are still vulnerable in practice due to a typical communication procedure between the server and the
specific logic vulnerability. Specifically, we found a similar client involves five steps:
implementation issue in the BLE stack used by Android de-
1. The server advertises its presence by broadcasting adver-
vices and in that used by iOS devices. This issue makes many
tising packets containing its identity.
Android and iOS devices vulnerable to the identified attack.
We have responsibly reported our findings to Google and Ap- 2. The client scans for advertising packets to discover the
ple, and they have confirmed these vulnerabilities. As of June server and establishes a wireless connection with it.
2020, while Apple has assigned the CVE-2020-9770 to the 3. (Optionally) The client pairs with the server to share a
vulnerability and fixed it, the Android BLE implementation long-term cryptographic key. This key is used to encrypt
in our tested device (i.e., Google Pixel XL running Android and authenticate the exchanged data.
10) is still vulnerable. 4. The client initiates the request to access the data stored by
To showcase the identified issues, we design a novel practi- the server.
cal attack, named BLESA (BLE Spoofing Attack). In BLESA, 5. The server checks if the client has the right to access the
the attacker pretends to be a previously-paired server device, specific requested data. If this condition is true, the server
rejects the authentication requests coming from the client grants read/write access to the requested data.
device, and then feeds spoofed data to it. We then show that
a Linux laptop running Ubuntu with the most updated ver- Security Levels. The data stored at a server is organized
sion of its BLE stack is vulnerable to BLESA. In addition, in attributes, and each attribute (e.g., a blood pressure mea-
we demonstrate the effectiveness of BLESA by launching surement) is identified using a unique identifier. BLE allows
it against Google Pixel XL phone recording the informa- the server to protect attributes at a fine-grained granularity. In
tion from a wearable activity-tracking device called Oura particular, the server can specify an access control policy for
Ring [25]. In particular, by using BLESA, the attacker suc- each attribute. Each such policy describes how an attribute can
cessfully impersonates the ring, injects spoofed data to the be accessed (read-only, write-only, or read-and-write), and
phone, and the companion application of the ring running on which security level is needed to access it. Specifically, there
the phone accepts and displays the spoofed data. are four possible security levels: no security (level 1), encryp-
tion only (level 2), encryption and authentication (level 3),
In summary, our work has these main contributions:
and strong encryption with authentication (level 4).
• We performed a formal analysis of the BLE link-layer au- When an access request is received from the client, the
thentication mechanism and discovered two design weak- server checks whether the current connection meets the se-
nesses in the BLE protocol specification. curity level required to access the requested attribute. If the
• We studied how these design weaknesses affect existing connection satisfies the required security level, the server
BLE stack implementations, and we discovered a related grants access to the requested attribute. Otherwise, the server
logic bug in the BLE link-layer implementations used by denies the request and sends an error message back to the
Android and iOS devices. client.
• Exploiting the identified design weaknesses and the discov- Pairing and Key Generation. The pairing between the
ered logic bug, we crafted a novel attack, named BLESA, client and the server is optional, and it depends on the security
which allows an attacker to impersonate a server device and level requested by the server. When encryption or authentica-
provide forged data to a previously-paired client device. tion is needed to access an attribute, the client and the server
• We proposed mitigation techniques to the identified security must be paired to establish a (long-term) shared secret key.
issues, which enable systemic changes in the reconnection Once the long-term key is generated between two devices, the
two devices are said to be bonded, and the long-term key is 1 free attAccessReq [private].
utilized to derive session keys to encrypt and authenticate the 2 free attAccessRsp [private].
3 free attSecAccessReq [private].
exchanged data during reconnections. 4 free attSecAccessRsp [private].
5 // Secrecy and integrity of attribute read request and
Different pairing methods require different levels of user attribute value
interaction, and a specific pairing method is selected based 6 query attacker( attAccessReq ).
7 query attacker( attAccessRsp ).
on the available user interface (e.g., keyboard and display) of 8 query attacker( attSecAccessReq ).
the pairing devices. For example, if the server device has a 9 query attacker( attSecAccessRsp ).
10 // Authenticity of attribute request and response
graphical user interface (such as in a smartwatch), user inter- 11 query event( clientRecvRsp ) == > inj-event( serverSendRsp ).
action (e.g., pressing a button or inserting a PIN) is required 12 // Consistency of request and response security levels
13 query x: SecLv ; event( clientReqSecLv (x))== > inj-event(
to approve the pairing on the server. In this case, the gener- serverRspSecLv (x)).
ated key can be used to access security level 3 or 4 attributes
(depending on the length of the key). Alternatively, if the Listing 1: ProVerif code with the verified security properties.
server device does not have input or output interfaces (e.g.,
a temperature sensor), no user interaction is possible on the
server-side. In this case, the generated key can only be used 4.1 ProVerif Model
to access attributes requiring security level 2.
Note that authentication and encryption are not always We build a formal model for the authentication process when
needed since data transmission in plaintext is allowed in the the client reconnects with the server in a new session. The
specification. In fact, the access control policy specified by authentication process is modeled as two communicating
the server fully determines if encryption and/or authentication state machines, one for the client and one for the server. We
are used. model the state machine corresponding to the transmission
For example, the Polar H7 Heart Rate Sensor [31] transmits of the attribute request of the client and the state machine
the heart rate in plaintext. Hence, no pairing is needed to read corresponding to the handling of the attribute request on the
the heart rate from this device. Conversely, the Fitbit smart- server in the BLE specification [11]. The model comprehen-
watch [20] requires link-layer encryption and authentication. sively covers the different types of messages including those
In this case, a smartphone has to pair with the smartwatch corresponding to the attribute access requests, attribute ac-
before reading its recorded data. cess responses, and the error responses. The communication
between the client and the server is modeled as the free (or
open) channel (free plain_channel: channel) where the
adversary has the abilities as described in the threat model.
3 Threat Model We also consider all the features of the attributes to cover
the different usage scenarios of server devices. Therefore,
We assume the adversary has the same capabilities as the we model the attributes on the server as both readable and
Dolev–Yao model [19], i.e., the adversary can eavesdrop, in- writable.
tercept, and modify legitimate messages communicated be- Furthermore, we model two types of attributes: (1) basic
tween a server and a client. The adversary can also inject attributes that can be accessed without pairing (i.e., at security
any message into the communication channel. However, the level 1), and (2) sensitive attributes that can be accessed after
adversary does not know the secret key shared between the pairing (at security level 2 or higher). Finally, we model the
server and the client, and the used cryptographic functionality client to send access requests to the server to read/write these
are perfectly secure. Also, the adversary cannot replace the two types of attributes in different orders. The shared secret
firmware of the server or client. Since BLE is a short-range key established during the pairing is used to encrypt/decrypt
communication protocol, we assume that the distance between the traffic when encryption is needed.
the adversary and the client, and the distance between the ad-
Security Goals. We analyze the above model in the light
versary and the server, are both within the Bluetooth range.
of traditional security goals that are presented in Listing 1.
In this scenario, the adversary aims to impersonate the server
These security goals include: (1) Confidentiality, i.e., the com-
and to mislead the client with spoofed messages.
municated messages should not leak any sensitive data to the
adversary (Line 6-9), (2) Integrity, i.e., the communicated
messages should not be tampered by the adversary without
4 Formal Analysis of BLE Reconnection being detected (Line 6-9), and (3) Authenticity, i.e., the com-
municated messages can be verified to be generated by the
We perform formal verification of the BLE link-layer au- genuine sender (Line 11). Besides, we also check one BLE
thentication mechanism when the client reconnects with a specific security goal extracted from the rules specified in the
previously connected server. We utilize ProVerif [9] to carry specification [11] when initiating requests from the client and
out this protocol verification. handling requests on the server. Only if the security level of
the connection is consistent with the requirement to access (1) Reactive Authentication. In this procedure, the client
the attribute, should the server give read/write access to the sends the attribute access request in plaintext (i.e., at security
client (Line 13). level 1) right after establishing the connection. Only if the
server responds with an error message revealing an inconsis-
tency between the current security level of the connection and
4.2 Discovered Design Weaknesses the one required for accessing the attribute, the client reacts
Through formal verification, we discover several instances of by enabling the encryption/authentication.
violations of the checked security goals when the previously- For this procedure, the formal analysis indicates that the
connected devices reconnect. These violations result in the authenticity of the access response can be violated, as shown
following two security weaknesses that can be potentially by the following ProVerif output.
exploited by an adversary to launch spoofing attacks. RESULT inj-event(clientRecvRsp) ==>
inj-event(serverSendRsp) is false.
4.2.1 Weakness-1: Optional Authentication Counterexample:
We find that the link-layer encryption/authentication is op- event clientReqSecLv(secLv1) at 3 in copy a
tional: the client and the server may choose to disable it for a out(plain_channel, ~M) with ~M = attAccessReq at 4 in
specific attribute. Therefore, in the case of the basic attribute, copy a
the confidentiality, integrity, and authenticity goals of the at- in(plain_channel, a_1) at 5 in copy a
tribute access request and response can be violated as shown event clientRecvRsp at 14 in copy a (goal)
in the following results from ProVerif. The event clientRecvRsp is executed at 14 in copy a.
RESULT not attacker(attAccessRsp[]) is false. A trace has been found.

Counterexample: As the counterexample shows, the attacker can first inter-

cept the request sent from the client. After that, the attacker
out(plain_channel, ~M) with ~M = attAccessReq at 2 in can respond to the client with any message other than an error
copy a message, so that the client will receive and accept the message
in(plain_channel, ~M) with ~M = attAccessReq at 11 in from the attacker.
copy a_1 Although the sensitive attribute stored at the server is not
out(plain_channel, ~M_1) with ~M_1 = errCode at 13 in leaked to the adversary, the adversary can eavesdrop on the
copy a_1 request sent by the client, impersonate the server, and trick the
in(plain_channel, a_2) at 14 in copy a_1 client with a spoofed response corresponding to the sensitive
out(plain_channel, ~M_2) with ~M_2 = attAccessRsp at 16 attribute. We will demonstrate in Section 5.1 that the existing
in copy a_1 BLE stack implementation (when accessed via gatttool) on
The attacker has the message ~M_2 = attAccessRsp. Linux follows this reactive authentication making the corre-
A trace has been found. sponding clients vulnerable to spoofing attacks.
We note that the server determines the security level of its
(2) Proactive Authentication. In this procedure, the client
connection with the client based on the requested attribute’s
device proactively enables the encryption/authentication be-
access control policy. As the counterexample shows, when
fore sending any request to the server. In particular, the client
the access control policy allows the lowest security level (i.e.,
enables the encryption using the pre-shared secret key previ-
security level 1) of the connection, the attribute access request
ously established, and then it proceeds with the authentication.
and the response can be transmitted in plaintext. In this case,
In this case, if the server fails to enable the encryption (which
no link-layer authentication is deployed. Therefore, the at-
also means that it fails to enable the authentication), the client
tacker can launch spoofing attacks against the server and the
aborts the connection. Our formal verification shows that all
client devices.
the checked security goals hold during proactive authentica-
We highlight that because the security level of the con-
tion, as shown by the following results.
nection is guided by the server, the client cannot enforce a
connection with higher security levels if the server only al- RESULT not attacker(attSecAccessReq[]) is true.
lows connections with security level 1. This aspect makes RESULT not attacker(attSecAccessReq[]) is true.
both the server and the client vulnerable to spoofing attacks. RESULT inj-event(clientRecvRsp) ==>
inj-event(serverSendRsp) is true.
RESULT inj-event(clientReqSecLv(x)) ==>
4.2.2 Weakness-2: Circumventing Authentication inj-event(serverRspSecLv(x)) is true.
The BLE specification provides two possible authentication Unfortunately, as we will further elaborate in Section 5.2,
procedures when the client reconnects with the server after the existing BLE stack implementations used by Andriod
pairing. and iOS fail to correctly follow this procedure making the
 Client Server

Reconnect to a paired server device

Client Adversary
Connection request

Advertise as
Connected Connected benign server
Read attribute request
Reconnect to a paired server device
(Plaintext)
Encryption needed Connection request

Insufficient Encryption Connected Connected

Enable encryption (Plaintext) Enable encryption Read attribute request

and authentication and authentication
(Plaintext)
Read attribute request
No authentication
or encryption
(Encrypted and authenticated)

Attribute value Spoofed attribute value

(Encrypted and authenticated) (Plaintext)

Accept attribute Accept spoofed
value attribute value

(a) Reconnection with the paired benign server. (b) Instantiation of BLESA against the client.

Figure 1: BLE communication workflow when the client (following the reactive authentication procedure) reconnects with
(a) the benign server and (b) the adversary which exploits the security weaknesses to circumvent the authentication procedure.

corresponding clients vulnerable to spoofing attacks. with the adversary.

At this point, the adversary is ready to launch BLESA
against the client. We present the workflows of BLESA
5 BLE Spoofing Attack (BLESA) against the client following the reactive authentication proce-
dure and that following the proactive authentication procedure
We exploit the design weaknesses identified through the for- in the following sections.
mal verification to craft the BLE Spoofing Attack (BLESA).
In this attack, an adversary provides spoofed data to a client
device pretending to be a previously-paired server device. 5.1 BLESA against Reactive Authentication
Attack Setup. We examine the scenario where the server Figure 1a shows an illustration where the client and the server
and the client were securely paired in a previous session. reconnect, and the reactive authentication procedure (dis-
Currently, they are disconnected, but they intend to start a cussed in Section 4.2.2) plays out in a benign environment.
new session. This scenario happens when, for instance, the The client first sends an attribute read request to the server
client moves out of the communication range of the server at the lowest security level (i.e., level 1) without any encryp-
and then it gets back. tion/authentication. If the attribute is sensitive and can be read
In this scenario, the adversary first discovers the server and only at a higher security level (e.g., security level 3 with en-
connects with it to obtain information (e.g., the identifier) cryption and authentication), the server responds to the client
about a server’s attributes. The adversary can easily obtain with an error message (e.g., insufficient encryption). After
this information because the BLE protocol is designed to receiving the error message, the client elevates the security
allow any device to connect with another BLE device and level by enabling encryption and authentication using the pre-
obtain information about provided attributes. Further, since shared secret key and sends the request again. At this time,
the BLE advertising packets are always transmitted in plain- the server readily accepts the read request and returns the
text, the adversary can easily impersonate the benign server attribute value.
by advertising the same packets and cloning its MAC address. Now we present the workflow of BLESA, as shown in
Then, the adversary starts broadcasting spoofed advertising Figure 1b. Here, the adversary intercepts the attribute read
packets to ensure that whenever the client attempts to start a request from the client and responds with a spoofed attribute
new session with the previously-paired server, it can discover value. Since the client does not encounter any error message,
the spoofed advertising packets and establish a connection it mistakenly assumes that the attribute can be accessed at the
 Client Adversary

Advertise as
benign device
Reconnect to a paired server device

Client Server Connection request

Reconnect to a paired server device

Connected Enable encryption Connected
Connection request
No long-
Connected Connected Encryption fails term key
Enable encryption

Bypass authentication
Encryption and Encryption and
and connection not abort
authentication enabled authentication enabled
Read attribute request Attribute read request
(Encrypted and authenticated) (Plaintext)
No authentication
Attribute value Spoofed attribute value or encryption

(Encrypted and authenticated) (Plaintext)

Accept attribute Accept spoofed
value attribute value

(a) Reconnection with the paired benign server. (b) Instantiation of BLESA against the client.

Figure 2: BLE communication workflow when the client (following the proactive authentication procedure) reconnects with
(a) the benign server and (b) an adversary exploiting BLESA.

lowest security level (i.e., in plaintext). Therefore, the client ... If encryption fails either the bond no longer exists on the re-
does not enable the encryption/authentication, and it accepts mote device, or the wrong device has been connected. The local
the spoofed attribute value. device must, after user interaction to confirm the remote de-
We highlight that in this instantiation of BLESA, the fun- vice, re-bond, perform service discovery and re-configure
the remote device...
damental reason making the attack possible is the fact that
the client device relies on the server’s error message to adapt
Figure 3: Description of the BLE protocol (page 1381 in [11])
the used security level.
indicating the steps to deal with the failure in enabling the
encryption during the proactive authentication procedure.
5.2 BLESA against Proactive Authentication
Figure 2a shows the workflow of the proactive authentication Android and iOS-based devices) fail to follow the specifi-
procedure triggered when a client device reconnects with a cation correctly. Specifically, we discover that even if the
benign server. Right after the connection, the client requests enabling encryption process fails, the client may not abort
to enable the encryption (and authentication) using the pre- the connection and continue the communication in plaintext
shared key, and the server complies with the request. Then without re-pairing with the server. This flaw can be exploited
the client securely sends an attribute read request, and the by an adversary to launch BLESA.
server securely responds with the (encrypted and authenti-
cated) attribute value. If the BLE stack correctly implement- ... if the Host indicates that a key is not available, the slave
ing the proactive authentication follows the specification (as shall either send an LL_REJECT_IND ... or Key Missing ...
presented in Figure 10.2 on page 1382 in [11]), BLESA will The Link Layer can now send LL Data PDUs and LL Control
fail against the client. However, our further analysis reveals PDUs; these packets will not be encrypted.
that both Android and iOS-based client devices suffer from a
logic bug that makes BLESA possible against these devices. Figure 4: Description of the BLE protocol (page 3031 in [11])
Implementation Vulnerability. According to the BLE indicating the procedure to deal with the non-availability of
specification, when the client reconnects with the previously- the long-term key at the client device.
paired server, if the encryption enabling process fails during
the proactive authentication procedure, the client should ei- We suspect that this implementation vulnerability is likely
ther re-pair with the server (as mentioned in Figure 3) or abort caused by the way in which this part of the BLE protocol is
the connection. However, the BLE stacks in some clients (i.e., explained in the official documentation.
 Specifically, since encryption is not mandatory in BLE Table 1: List of BLE server devices examined to evaluate the
for accessing basic attributes and some server devices do impact of the design weakness-1.
not support link-layer encryption (i.e., the design weakness-
1 discussed in Section 4.2.1), the BLE specification makes Support for link-layer
Device Name
provisions to maintain the compatibility and enhance usabil- authentication
ity with these resource-constrained server devices. For this Nest Protect Smoke Detector ×
reason, when the encryption/authentication fails, the BLE Nest Cam Indoor Camera ×
data and control messages can still be transmitted in plaintext SensorPush Temperature Sensor ×
as described in the specification (Figure 4). We believe that Tahmo Tempi Temperature Sensor ×
August Smart Lock ×
the contradiction originating from the details in the speci-
Eve Door&Window Sensor ×
fication shown in Figures 3 and 4 may have confused the
Eve Button Remote Control ×
BLE stack developers. As such, they made the logical mis-
Eve Energy Socket ×
take of not aborting the connection in the event of failure of Ilumi Smart Light Bulb ×
the encryption process, which is mandatory for accessing the Polar H7 Heart Rate Sensor ×
security-sensitive attributes on a previously-paired server. √
Fitbit Versa Smartwatch
Figure 2b presents the details of how the BLESA succeeds √
Oura Smart Ring
against client devices using the proactive authentication pro-
cedure, but affected by the explained implementation vulnera-
bility. Specifically, after the connection to the adversary, if the (e.g., the number of footsteps). Since the pairing procedure
client attempts to enable the encryption, the adversary sends (to establish a secret key) is one of the prerequisites for en-
an error message to the client specifying the non-availability abling the link-layer authentication, we can readily confirm
of the long-term key so that the encryption fails. At this point, that the BLE device does not support the link-layer authen-
the client does not follow correctly the BLE specification tication if there is no pairing API invoked in its companion
(which, in this case, recommends aborting the connection), application. To this end, we utilize the static analysis frame-
but continues the connection with the adversary. work, FlowDroid [6], to inspect the Android BLE applications.
Due to the first design weakness described in Section 4.2.1, More specifically, for each companion application, we use the
the client then proceeds to send the read request for the target Class Hierarchical Analysis (CHA) option in FlowDroid to
attribute in plaintext. Unlike the server, the adversary read- build the call graph and find whether the application indeed
ily grants the access to the attribute, making it available at invokes the pairing API from any of its entry points (e.g.,
the lowest security level (i.e., security level 1), and it feeds an Activity). Since CHA is a relatively conservative way for
spoofed attribute data to the client. Consequently, the client call-graph construction, it may miss part of the method invo-
accepts the spoofed data from the adversary. cations. However, the analysis result is much more precise,
with minimal false positives compared to other options (e.g.,
SPARK) [23]. Hence, it provides us a lower-bound of BLE
6 Implementation and Impact apps using pairing.
Our static analysis starts with 33,785 popular applications,
In this section, we first examine the impact of the two iden- which are automatically crawled from AndroZoo website [1]
tified design weaknesses in the real-world BLE stack imple- in January and February 2020. Based on the constructed call-
mentations (Section 6.1 and Section 6.2). We then elaborate graph and corresponding APIs of these applications, we find
on the impact of BLESA on the Linux platforms (Section 6.3) that only 127 applications contain the BLE data read/write op-
and the Android/iOS mobile platforms (Section 6.4). erations. We then check if the pairing API (createBond()) is
invoked in these applications. Unfortunately, we find that only
6.1 Examination of Design Weakness-1 41 (32.3%) out of the 127 inspected applications contain the
pairing procedure, implying that a majority of the investigated
To find out if there are indeed certain BLE server devices that BLE companion applications (67.7%) do not implement the
do not employ the link-layer authentication, we follow two link-layer authentication.
approaches: (1) We inspect the behavior of a set of BLE de- Runtime Analysis of Transmitted Packets. We examine
vices’ companion applications through static analysis. (2) We 12 BLE devices (as listed in Table 1) which are selected to rep-
sample a set of real-world BLE devices and inspect their com- resent a variety of application from mainstream BLE device
munication packets with runtime analysis. manufacturers. We connect each of these server devices with
Static Analysis of Mobile Applications. A typical BLE a Google Pixel XL phone and read their attributes. During
device (e.g., Fitbit fitness tracker) relies on its companion these experiments, we intercept the runtime communicated
mobile application (e.g., the Fitbit application) which enables packets using an Ubertooth One radio [33]. By analyzing the
the end-user to access and manage the recorded attribute data intercepted packets, we find that 10 out of the 12 inspected
Table 2: List of BLE client platforms examined to evaluate the Table 3: BLE server devices utilized to evaluate BLESA.
impact of the design weakness-2 and utilized as the victims
to evaluate BLESA. Platform OS BLE Stack
Linux Laptop Ubuntu 18.04 BlueZ 5.48
Platform OS BLE Stack Oura Ring [25] Vendor OS Vendor Firmware
Google Pixel XL Android 8.1, 9, 10 Fluoride [17]
iPhone 8 iOS 12.1, 12.4, 13.3.1 iOS BLE stack
Table 4: Adversary’s platform for launching BLESA.
BlueZ 5.48 [14]
Linux Laptop Ubuntu 18.04
(accessed via gatttool)
Thinkpad X1 Yoga Windows 10 V. 1809 Windows stack Platform OS BLE Stack
Linux PC & BT Dongle Ubuntu 18.04 BlueZ 5.48

BLE devices do not support any link-layer encryption/authen-

tication. To this end, we conclude that most real-world BLE 2020) Android BLE implementation in our test device (i.e.,
devices do not employ link-layer authentication. Google Pixel XL with Android 10) is still vulnerable.

6.2 Examination of Design Weakness-2 6.3 BLESA against Linux Clients

For the examination of the second weakness, we test four For attacking the Linux client (listed in the third row in Ta-
different client devices that cover all major platforms with ble 2), we utilize another Linux laptop (listed in the first row
different BLE stack implementations. We present detailed in Table 3) as the server device. The emulated server runs
information about these devices in Table 2. We run experi- a python script to provide a service corresponding to a sen-
ments on each of these platforms to explore the answers for sitive attribute that can be read at security level 3 (i.e., with
the following two questions: (1) Which of the two authen- an encrypted and authenticated connection). To emulate the
tication procedures (i.e., reactive or proactive, as discussed adversary, we use a Linux desktop with a CSR 4.0 [15] Blue-
in Section 4.2.2) does the client device utilize when it recon- tooth dongle (shown in Table 4). The adversary also runs a
nects with a server device? (2) If the client device follows the python script that handles the messages received from the
proactive authentication procedure, does its BLE stack imple- client and launches BLESA against it. Besides, we use the
mentation have any logic flaw making it vulnerable against gatttool on the client device to send the attribute read re-
a spoofing attack? To answer these two questions, we first quests and receive the responses.
pair each tested client with a server (which is emulated using To launch BLESA, the adversary carries out the follow-
a Linux laptop, as shown in Table 3) and then disconnect ing steps which are akin to the procedure described in
them. Thereafter, we reconnect the tested client with the same Section 5.1: ¶ scan (bluetoothctl) for the advertising
server, and we ask the client to read one of the server’s at- packets transmitted by the server to record its MAC ad-
tributes, while capturing all the generated BLE traffic using dress; · change the adversary’s Bluetooth MAC address
Wireshark [18]. (bdaddr tool in BlueZ) to the server’s MAC address so
By analyzing the traffic data corresponding to the Linux that the client can reconnect with the adversary; ¸ broad-
laptop used as the client, we find that the Linux BLE stack cast the same (impersonated) advertising packets as the
(i.e., BlueZ accessed via gatttool) implements the reactive server by issuing Host Controller Interface (HCI) com-
authentication procedure. As a result, the Linux BLE stack mands, HCI_LE_Set_Advertising_Parameters, HCI_LE_
suffers from the weakness described in Section 4.2.2. Set_Advertising_Data, and HCI_LE_Set_Advertising_
Conversely, we find that the Android, iOS, and Windows Enable, to the dongle; and ¹ inject the spoofed data via ATT_
BLE stacks implement the proactive authentication procedure. READ_RSP message after receiving ATT_READ_REQ message
Among them, the Windows BLE stack strictly follows the from the client.
BLE specification. However, both Android and iOS devices By performing these steps, the adversary successfully by-
continue the reconnection even when the encryption/authenti- passes the reactive authentication procedure of the Linux
cation fails (as elaborated in Section 5.2). client and tricks the client into accepting the spoofed data.
Responsible Disclosure. We have reported the vulner-
ability to Apple and Google on April 8, 2019. Apple has
acknowledged our findings, assigned the CVE-2020-9770
6.4 BLESA against Android/iOS Clients
to the vulnerability, and fixed it. Although Google has also Since BLESA bypasses the link-layer authentication by down-
confirmed the vulnerability, we have been told that our vul- grading the connection to plaintext, all Android and iOS-
nerability report is similar to another report submitted three based client devices communicating with the BLE server
days earlier than us1 . We note that a more recent (as of May
Team believes that this is a duplicate of a report previously submitted by
1 We received the following reply from Google: "The Android Security another external researcher on Apr 5, 2019".
 (a) Benign battery level (43%). (b) Spoofed battery level (0%). (c) Spoofed notification for charging.

Figure 5: Demonstration of the impact of BLESA on the data displayed by the Oura Ring application on the Google Pixel phone.

devices that do not employ any application-layer security At the same time, we also inject another spoofed message
mechanism (e.g., encryption or authentication) are vulnerable which triggers a notification in the application mentioning
to BLESA. We note that according to prior research [32], 46% that the charging is complete, as shown in Figure 5c.
of the Android applications (2,379 million cumulative instal- We note that although the first spoofed message tricks
lations) do not utilize application-layer security while reading the application into believing that the battery level is at 0%,
data from BLE server devices. This implies that at least 46% the application interestingly accepts another spoofed mes-
of the Andriod applications are vulnerable against BLESA. sage (corresponding to charging completion) and displays the
The Apple app store is likely to have a similar proportion of false notification to the user. A demo of this attack can be
vulnerable applications. accessed at https://pursec.cs.purdue.edu/projects/
blesa.html.
Here, we present how an adversary (shown in Table 4)
launches BLESA against a Google Pixel phone (the client
device, shown in Table 2) by impersonating an Oura Ring 7 Mitigation of BLESA
(the server device, shown in Table 3). The adversary carries
out the first three steps similar to those utilized for attack- To prevent BLESA, we need to secure the reconnection pro-
ing Linux clients as discussed in Section 6.3, i.e., ¶ scan cedure between clients and their previously-paired server de-
for the advertising packets of the ring; · clone the advertis- vices. We can achieve this by improving the BLE stack im-
ing packets and the MAC address of the ring; ¸ advertise plementations and/or updating the BLE specification.
as the ring. Thereafter, the adversary performs the follow-
Updating Implementation. As far as the Linux BLE
ing: ¹ send an HCI command HCI_LE_Long_Term_Key_
stack (BlueZ accessed via gatttool) is concerned, the
Request_Negative_Reply indicating the unavailability of
client devices can be updated to only employ the proactive
the key to bypasse the encryption and authentication when the
authentication. We clarify that, another Linux client tool,
HCI event HCI_LE_Long_Term_Key_Request is received;
bluetoothctl, used by typical applications and built on the
º inject the spoofed data via ATT_READ_RSP messages after D-Bus APIs in BlueZ, strictly follows the proactive authen-
receiving ATT_READ_REQ message from the phone. We note
tication specification, and therefore, is immune to BLESA.
that the adversary can follow the same steps to launch BLESA
According to BlueZ developers, they have marked gatttool
against an iOS client device (the second row in Table 2).
as deprecated and will remove gatttool and its source code
By performing these steps, the adversary successfully in- from BlueZ completely and only keep bluetoothctl. Also,
jects spoofed data into the smartphone, and the companion the discovered implementation vulnerability of the proac-
application of the ring running on the smartphone displays tive authentication used by Android and iOS clients can be
the spoofed data to the user. Figure 5a shows that, in our mitigated by correctly following the BLE specification. The
experiment, the real battery level of the Oura Ring device updated implementation must ensure that when the authenti-
is 43%. Through BLESA, we successfully inject a spoofed cation with a previously-paired server fails, the client aborts
battery level (0%) to the application, as shown in Figure 5b. the connection and restarts the pairing process.
 A more fundamental problem is that even for the proactive al. [30] have also formally verified and found vulnerabilities
authentication, BLESA can bypass the link-layer authentica- in the secure simple pairing. Arai et al. [5] have specifically
tion in the presence of other potential bugs in the implemen- analyzed the numeric comparison protocol used in the secure
tation. This is a typical scenario in which authentication at simple pairing and identified potential attacks. Nguyen et
multiple layers is suggested by the security researchers [21]. al. [29] have discovered vulnerabilities in the protocols that
In fact, the link-layer problem would not be an exploitable use out-of-band channels to establish shared keys. In contrast,
issue if we had authenticaiton/encryption at application-layer. in this paper, we focus on the formal modeling and analysis
Unfortunately, such an improvement might not be widely de- of the reconnection procedure in the BLE protocol, which
ployed because a large proportion of resource-constrained leads to two design weaknesses in the authentication process.
devices cannot be remotely updated. Attacks against Bluetooth. A majority of the recent stud-
Updating Specification. We argue that while it is important ies focus on the design weaknesses and implementation flaws
to fix the implementation bugs to promptly make the BLE in the Bluetooth stacks. Naveed et al. [28] have discussed
devices secure against BLESA, it is equally critical to chart the mis-binding between applications and external Bluetooth
out a roadmap to prevent more advanced spoofing attacks. Classic devices. Sivakumaran et al. [32] have revealed sim-
To this end, we should prevent the client from sending the ilar mis-binding issues for BLE devices and analyzed the
attribute access request first and adjust the security level of application-layer security issues in BLE applications on An-
the connection later based on the error message returned by droid. Antonioli et al. [3] have discovered a logic flaw in the
the server. In other words, the client should first obtain the key negotiation protocol during pairing and exploited it to
authentic information about the access requirements of the decrypt the encrypted traffic. BadBluetooth [35] has revealed
attributes stored at the server, and then adjust the security level how a malicious Bluetooth device can launch severe attacks
of the connection to meet those requirements, before sending against mobile platforms. Biham et al. [8] have focused on the
the access request. However, this approach requires the client Elliptic Curve Diffie-Hellman protocol and found weaknesses
to record the security requirements for each attribute on the in the Bluetooth pairing procedure against invalid curve at-
server during the pairing process. Therefore, pairing process tacks. The study closest to our work is presented by Antonioli
in the specification needs to be updated so that the server can et al. [4] where they have presented impersonation attacks
send the security requirements of each of its attributes to the against Bluetooth Classic by exploiting the existing support
client. for legacy pairing methods and role-switching feature. In this
Challenges and Future Directions. Patching different vul- paper, we focus on the design weaknesses and implemen-
nerabilities at different layers in a timely fashion is a naive and tation vulnerabilities in the BLE stack and how they can be
straight forward approach to prevent spoofing attacks in BLE. exploited to launch the spoofing attack, BLESA. We highlight
However, this approach is unlikely to work well in practice that since BLESA can be launched by an adversary without
because such ad-hoc, case-by-case fixes might not be feasibly any additional assistance from a malicious application pre-
adopted by the extremely fragmented BLE ecosystem at a installed on the client device, it is more powerful and practical
large-scale. BLE device vendors tend to sacrifice security for than the attacks in the prior art [3, 4, 28, 32, 35].
utility, especially for low-end BLE devices. It is especially
challenging to secure those low-end BLE devices that do not
support any firmware update. Also, it is difficult to modify the 9 Conclusion
pairing process while maintaining the backward compatibil-
ity with the legacy BLE devices. In addition, fundamentally In this paper, we carried out a formal verification of the re-
addressing the BLE protocol vulnerabilities will require up- connection procedure defined in the BLE specification, and
dating the BLE specification, which requires a lot of time and we discovered two design weaknesses in the BLE link-layer
coordination. Therefore, such challenges bring the need for a authentication mechanism. By exploiting these design weak-
device-agnostic, legacy-friendly, and comprehensive solution nesses, we proposed BLESA, a novel BLE spoofing attack
to mitigate the threat of spoofing attacks, as partially explored through which an attacker can impersonate a BLE server de-
by a recent study [34]. vice and provide spoofed data to a previously-paired BLE
client device. BLESA can easily be launched against a BLE
device running Linux (accessed via gatttool).
8 Related Work In addition, further examination of the identified weak-
nesses in real-world BLE implementations revealed a related
Formal analysis of the Bluetooth Protocol. Existing lit- implementation vulnerability in the Android and iOS BLE
erature focuses on the formal analysis of Bluetooth pairing stacks. Due to this vulnerability, these two stacks are vulnera-
protocols. Chang et al. [13] have formally analyzed the au- ble against BLESA.
thentication process in the Bluetooth legacy pairing and the To showcase BLESA, we provided an in detail description
secure simple pairing, and revealed their weaknesses. Phan et of how to use this attack to spoof data coming from a fitness
tracker to an Android smartphone. Moreover, we estimated [7] Vaibhav Bedi. Exploiting BLE smart
the number of existing Android apps potentially affected by bulb security using BtleJuice: A step-by-
this attack. Finally, we discussed possible improvements in step guide. https://blog.attify.com/
the reconnection procedure, to fundamentally mitigate the btlejuice-mitm-attack-smart-bulb/, 2018.
threat of spoofing attacks like BLESA. Accessed: August 1, 2019.

[8] Eli Biham and Lior Neumann. Breaking the Bluetooth

Acknowledgments Pairing–The Fixed Coordinate Invalid Curve Attack. In
International Conference on Selected Areas in Cryptog-
We thank the anonymous reviewers for their valuable com-
raphy. Springer, 2019.
ments and suggestions. This work was supported in part by
ONR under Grant N00014-18-1-2674. Any opinions, findings, [9] Bruno Blanchet. An Efficient Cryptographic Protocol
and conclusions in this paper are those of the authors and do Verifier Based on Prolog Rules. In 14th IEEE Computer
not necessarily reflect the views of the ONR. Security Foundations Workshop (CSFW-14), June 2001.

[10] Bluetooth Special Interest Group. 2019

References
Bluetooth Market Update. https://www.
[1] Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein, bluetooth.com/bluetooth-resources/
and Yves Le Traon. Androzoo: Collecting millions of 2019-bluetooth-market-update/, 2019. Ac-
android apps for the research community. In Proceed- cessed: August 1, 2019.
ings of the 13th International Conference on Mining
[11] Bluetooth Special Interest Group. Core specifica-
Software Repositories, MSR ’16, 2016.
tions 5.2. https://www.bluetooth.org/docman/
[2] Daniele Antonioli, Nils Tippenhauer, and Kasper Bonne handlers/downloaddoc.ashx?doc_id=478726,
Rasmussen. Key negotiation downgrade attacks on blue- 2019. Accessed: April 1, 2020.
tooth and bluetooth low energy. ACM Trans. Inf. Syst.
Secur., 0(ja). [12] Victor Casares. Mimo baby hack.
https://medium.com/@victor_14768/
[3] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper mimo-baby-hack-ac7fa0ae3bfb, 2018. Accessed:
Rasmussen. The KNOB is Broken: Exploiting Low August 1, 2019.
Entropy in the Encryption Key Negotiation Of Blue-
tooth BR/EDR. In Proceedings of the USENIX Security [13] Richard Chang and Vitaly Shmatikov. Formal analy-
Symposium (USENIX Security), August 2019. sis of authentication in bluetooth device pairing. FCS-
ARSPA07, 2007.
[4] Daniele Antonioli, Nils Ole Tippenhauer, and Kasper
Rasmussen. BIAS: Bluetooth Impersonation AttackS. [14] BlueZ contributers. Bluez. http://www.bluez.org/,
In Proceedings of the IEEE Symposium on Security and 2019. Accessed: August 1, 2019.
Privacy (S&P), 2020.
[15] CSR. CSR 4.0 Bluetooth USB
[5] Kenichi Arai and Toshinobu Kaneko. Formal Verifi- adapter. https://www.amazon.com/
cation of Improved Numeric Comparison Protocol for Bluetooth-Adapter-Songway-Computer-Keyboard/
Secure Simple Paring in Bluetooth Using ProVerif. In dp/B07KWVXBKZ/ref=sr_1_46?keywords=
Proceedings of the International Conference on Security bluetooth+adapter+car+4.0&qid=1563227361&s=
and Management (SAM). The Steering Committee of electronics&sr=1-46. Accessed: August 1, 2019.
The World Congress in Computer Science, Computer
Engineering and Applied Computing (WorldComp), [16] Aveek K. Das, Parth H. Pathak, Chen-Nee Chuah, and
2014. Prasant Mohapatra. Uncovering privacy leakage in BLE
network traffic of wearable fitness trackers. In Proceed-
[6] Steven Arzt, Siegfried Rasthofer, Christian Fritz, ings of the 17th International Workshop on Mobile Com-
Eric Bodden, Alexandre Bartel, Jacques Klein, Yves puting Systems and Applications (HotMobile), 2016.
Le Traon, Damien Octeau, and Patrick McDaniel. Flow-
Droid: Precise Context, Flow, Field, Object-Sensitive [17] Android Developers. Fluoride Blue-
and Lifecycle-Aware Taint Analysis for Android Apps. tooth stack. https://android.
In Proceedings of the 35th ACM SIGPLAN Conference googlesource.com/platform/system/bt/+/
on Programming Language Design and Implementation, 181144a50114c824cfe3cdfd695c11a074673a5e/
PLDI ’14, 2014. README.md, 2019. Accessed: August 1, 2019.
[18] Wireshark developers. Wireshark Go Deep. https: [28] Muhammad Naveed, Xiao-yong Zhou, Soteris
//www.wireshark.org. Accessed: May 15, 2020. Demetriou, XiaoFeng Wang, and Carl A Gunter. Inside
job: Understanding and mitigating the threat of external
[19] Danny Dolev and Andrew Yao. On the security of public device mis-binding on android. In Proceedings of the
key protocols. IEEE Transactions on information theory, Network and Distributed System Security Symposium
29(2), 1983. (NDSS), 2014.
[20] Fitbit. Fitbit versa 2. https://www.fitbit.com/us/
[29] Trung Nguyen and Jean Leneutre. Formal analysis of
products/smartwatches/versa, 2019. Accessed:
secure device pairing protocols. In 2014 IEEE 13th
Aug 1, 2019.
International Symposium on Network Computing and
[21] Mario Frustaci, Pasquale Pace, Gianluca Aloi, and Gian- Applications. IEEE, 2014.
carlo Fortino. Evaluating critical security issues of the
IoT world: Present and future challenges. IEEE Internet [30] Raphael C-W Phan and Patrick Mingard. Analyzing
of things journal, 5(4), 2017. the secure simple pairing in Bluetooth v4.0. Wireless
Personal Communications, 64(4), 2012.
[22] Constantinos Kolias, Lucas Copi, Fengwei Zhang, and [31] Polar. Polar h7 heartrate sensor. https:
Angelos Stavrou. Breaking BLE beacons for fun but //support.polar.com/us-en/support/H7_heart_
mostly profit. In Proceedings of the 10th European rate_sensor, 2019. Accessed: Aug 1, 2019.
Workshop on Systems Security (EuroSec), 2017.
[32] Pallavi Sivakumaran and Jorge Blasco. A study of the
[23] Patrick Lam. Soot phase options (call graph con- feasibility of co-located app attacks against BLE and a
struction). https://www.sable.mcgill.ca/soot/ large-scale analysis of the current application-layer secu-
tutorial/phase/phase.html, 2019. Accessed: Aug rity landscape. In Proceedings of the USENIX Security
1, 2019. Symposium (USENIX Security), August 2019.
[24] Angela Lonzetta, Peter Cope, Joseph Campbell, Bassam [33] Ubertooth Developers. Ubertooth One.
Mohd, and Thaier Hayajneh. Security vulnerabilities in https://github.com/greatscottgadgets/
Bluetooth technology as used in IoT. Journal of Sensor ubertooth/wiki, 2019. Accessed: August 1,
and Actuator Networks, 7(3), 2018. 2019.
[25] Oura Health Ltd. OURA SMART RING. https://
[34] Jianliang Wu, Yuhong Nan, Vireshwar Kumar, Mathias
ouraring.com/products/, 2019. Accessed: August
Payer, and Dongyan Xu. BlueShield: Detecting Spoof-
1, 2019.
ing Attacks in Bluetooth Low Energy (BLE) Networks.
[26] Ubuntu Manpage. gatttool - tool for Bluetooth In 23nd International Symposium on Research in At-
Low Energy device. http://manpages.ubuntu.com/ tacks, Intrusions and Defenses (RAID 2020), 2020.
manpages/cosmic/man1/gatttool.1.html. Ac-
cessed: May 15, 2020. [35] Fenghao Xu, Wenrui Diao, Zhou Li, Jiongyi Chen, and
Kehuan Zhang. BadBluetooth: Breaking Android Secu-
[27] Tal Melamed. An active man-in-the-middle attack on rity Mechanisms via Malicious Bluetooth Peripherals.
Bluetooth smart devices. International Journal of Safety In Proceedings of the 26th Annual Network and Dis-
and Security Engineering, 8(2), 2018. tributed System Security Symposium (NDSS), 2019.