BLESA: Spoofing Attacks against Reconnections in Bluetooth Low

BLESA: Spooﬁng Attacks against Reconnections in Bluetooth Low Energy

Jianliang Wu

Purdue University

wu1220@purdue.edu

Yuhong Nan

Purdue University

nan1@purdue.edu

Vireshwar Kumar

Purdue University

viresh@purdue.edu

Dave (Jing) Tian

Purdue University

daveti@purdue.edu

Antonio Bianchi

Purdue University

antoniob@purdue.edu

Mathias Payer

EPFL

[email protected]

Dongyan Xu

Purdue University

[email protected]due.edu

Abstract

The Bluetooth Low Energy (BLE) protocol ubiquitously

enables energy-efﬁcient wireless communication among

resource-constrained devices. To ease its adoption, BLE re-

quires limited or no user interaction to establish a connection

between two devices. Unfortunately, this simplicity is the root

cause of several security issues.

In this paper, we analyze the security of the BLE link-layer,

focusing on the scenario in which two previously-connected

devices reconnect. Based on a formal analysis of the reconnec-

tion procedure deﬁned by the BLE speciﬁcation, we highlight

two critical security weaknesses in the speciﬁcation. As a re-

sult, even a device implementing the BLE protocol correctly

may be vulnerable to spooﬁng attacks.

To demonstrate these design weaknesses, and further study

their security implications, we develop BLE Spooﬁng Attacks

(

BLESA

). These attacks enable an attacker to impersonate a

BLE device and to provide spoofed data to another previously-

paired device.

BLESA

can be easily carried out against some

implementations of the BLE protocol, such as the one used in

Linux. Additionally, for the BLE stack implementations used

by Android and iOS, we found a logic bug enabling

BLESA

We reported this security issue to the affected parties (Google

and Apple), and they acknowledged our ﬁndings.

1 Introduction

Bluetooth Low Energy (BLE) is the most widely utilized low-

energy communication protocol, and, by 2023, the number of

BLE-capable devices is expected to reach 5 billion [10]. The

BLE protocol enables wireless, short-range communication

which allows two devices to connect and exchange data. A

typical usage scenario consists of a smartphone and a “gadget”

device (such as a ﬁtness tracker) that communicate over BLE.

Every BLE connection involves a device acting as a

client

(in

this example, the smartphone) and another device acting as

server

(in this example, the ﬁtness tracker). The ﬁrst time

two devices connect (allowing them to exchange data), they

perform a speciﬁc pairing procedure, which varies depending

on the type of the connected devices and their user-interfaces’

capabilities.

The major factors that have helped the rapid growth of the

adoption of BLE-enabled devices are its low cost and the

minimal setup effort required for end users. Unfortunately,

previous research [7, 12, 22, 24, 27] has shown that these user-

friendly features have a negative impact on the security of

this protocol. This concern is particularly worrisome since

BLE communication is often used in security-sensitive de-

vices, such as physical safety devices (e.g., locks) or health

monitoring devices (e.g., medical implants) [16].

Researchers have pointed out and studied many implemen-

tation weaknesses in the BLE protocol by manually analyzing

its speciﬁcation [2, 3, 8, 32, 35]. Additionally, some previous

works have also performed a formal automated analysis of the

BLE speciﬁcation [5, 29]. However, these formal approaches

only focused on limited aspects of the entire protocol, such

as the BLE pairing mechanism. This limitation is due to the

fact that it is challenging to fully formalize and automatically

analyze the BLE speciﬁcation. The challenges stem from the

complexity of the BLE protocol, difﬁculties in modeling its

multi-layer design, and its multiple variants and optional fea-

tures (which allow this protocol to support a wide range of

devices with signiﬁcantly different capabilities).

In this paper, we study a previously-unexplored mechanism

of the BLE protocol. Speciﬁcally, we focus on the mechanism

of dealing with reconnecting two previously connected de-

vices. This mechanism comes into play when, for instance, a

server device (e.g., a ﬁtness tracker) moves out of the BLE

wireless communication range of a connected client device

(e.g., a smartphone), and then at a later time, the two devices

get close enough to re-establish a connection.

To start our analysis of this scenario, we ﬁrst carried out

a formal veriﬁcation of the relevant BLE link-layer speciﬁ-

cation [11], by using the ProVerif protocol veriﬁer [9]. Our

formal analysis highlighted two weaknesses in the BLE of-

ﬁcial speciﬁcation. These weaknesses, in some BLE stack

implementations, allow an attacker to launch a spooﬁng at-

tack in which the attacker pretends to be a previously-paired

server

device, inducing a

client

device into accepting spoofed

data.

In particular, we discovered that the BLE speciﬁcation al-

lows implementing several aspects of this protocol in multiple

ways, some of which are vulnerable. For this reason, even

BLE stack implementations correctly following the speci-

ﬁcation can potentially be susceptible to spooﬁng attacks.

For instance, we found that the BLE protocol stack (when

accessed via

gatttool

[26]) used in Linux

client

devices

(e.g., Linux laptops), while following the BLE speciﬁcation

correctly, is susceptible to the identiﬁed spooﬁng attack.

Furthermore, we discovered that even BLE protocol stacks

implemented in ways that are, in theory, not susceptible to

the identiﬁed attack are still vulnerable in practice due to a

speciﬁc logic vulnerability. Speciﬁcally, we found a similar

implementation issue in the BLE stack used by Android de-

vices and in that used by iOS devices. This issue makes many

Android and iOS devices vulnerable to the identiﬁed attack.

We have responsibly reported our ﬁndings to Google and Ap-

ple, and they have conﬁrmed these vulnerabilities. As of June

2020, while Apple has assigned the CVE-2020-9770 to the

vulnerability and ﬁxed it, the Android BLE implementation

in our tested device (i.e., Google Pixel XL running Android

10) is still vulnerable.

To showcase the identiﬁed issues, we design a novel practi-

cal attack, named

BLESA

(BLE Spooﬁng Attack). In

BLESA

the attacker pretends to be a previously-paired server device,

rejects the authentication requests coming from the

client

device, and then feeds spoofed data to it. We then show that

a Linux laptop running Ubuntu with the most updated ver-

sion of its BLE stack is vulnerable to BLESA. In addition,

we demonstrate the effectiveness of BLESA by launching

it against Google Pixel XL phone recording the informa-

tion from a wearable activity-tracking device called Oura

Ring [25]. In particular, by using

BLESA

, the attacker suc-

cessfully impersonates the ring, injects spoofed data to the

phone, and the companion application of the ring running on

the phone accepts and displays the spoofed data.

In summary, our work has these main contributions:

•

We performed a formal analysis of the BLE link-layer au-

thentication mechanism and discovered two design weak-

nesses in the BLE protocol speciﬁcation.

•

We studied how these design weaknesses affect existing

BLE stack implementations, and we discovered a related

logic bug in the BLE link-layer implementations used by

Android and iOS devices.

•

Exploiting the identiﬁed design weaknesses and the discov-

ered logic bug, we crafted a novel attack, named BLESA,

which allows an attacker to impersonate a

server

device and

provide forged data to a previously-paired client device.

•

We proposed mitigation techniques to the identiﬁed security

issues, which enable systemic changes in the reconnection

procedure to make it robust against BLESA.

2 Background

The original Bluetooth (Classic) protocol was designed

for short-range wireless streaming applications such as au-

dio, video, and ﬁle transfer. Different from Bluetooth Clas-

sic, Bluetooth Low Energy (BLE) is designed for energy-

constrained low-cost IoT applications that require an intermit-

tent transfer of smaller amounts of data at lower speeds.

The BLE protocol enables a device, acting as a

server

(e.g.,

a ﬁtness tracker), to efﬁciently communicate relevant data

(e.g., the number of tracked footsteps) to another connected

device, acting as a

client

(e.g., a smartphone). In BLE, the

typical communication procedure between the

server

and the

client involves ﬁve steps:

The

server

advertises its presence by broadcasting adver-

tising packets containing its identity.

The

client

scans for advertising packets to discover the

server and establishes a wireless connection with it.

(Optionally) The

client

pairs with the

server

to share a

long-term cryptographic key. This key is used to encrypt

and authenticate the exchanged data.

The

client

initiates the request to access the data stored by

the server.

The

server

checks if the

client

has the right to access the

speciﬁc requested data. If this condition is true, the

server

grants read/write access to the requested data.

Security Levels.

The data stored at a

server

is organized

in attributes, and each attribute (e.g., a blood pressure mea-

surement) is identiﬁed using a unique identiﬁer. BLE allows

the

server

to protect attributes at a ﬁne-grained granularity. In

particular, the

server

can specify an access control policy for

each attribute. Each such policy describes how an attribute can

be accessed (read-only, write-only, or read-and-write), and

which security level is needed to access it. Speciﬁcally, there

are four possible security levels: no security (level 1), encryp-

tion only (level 2), encryption and authentication (level 3),

and strong encryption with authentication (level 4).

When an access request is received from the

client

, the

server

checks whether the current connection meets the se-

curity level required to access the requested attribute. If the

connection satisﬁes the required security level, the

server

grants access to the requested attribute. Otherwise, the

server

denies the request and sends an error message back to the

client.

Pairing and Key Generation.

The pairing between the

client

and the

server

is optional, and it depends on the security

level requested by the

server

. When encryption or authentica-

tion is needed to access an attribute, the

client

and the

server

must be paired to establish a (long-term) shared secret key.

Once the long-term key is generated between two devices, the

two devices are said to be bonded, and the long-term key is

utilized to derive session keys to encrypt and authenticate the

exchanged data during reconnections.

Different pairing methods require different levels of user

interaction, and a speciﬁc pairing method is selected based

on the available user interface (e.g., keyboard and display) of

the pairing devices. For example, if the

server

device has a

graphical user interface (such as in a smartwatch), user inter-

action (e.g., pressing a button or inserting a PIN) is required

to approve the pairing on the

server

. In this case, the gener-

ated key can be used to access security level 3 or 4 attributes

(depending on the length of the key). Alternatively, if the

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

to access attributes requiring security level 2.

Note that authentication and encryption are not always

needed since data transmission in plaintext is allowed in the

speciﬁcation. In fact, the access control policy speciﬁed by

the

server

fully determines if encryption and/or authentication

are used.

For example, the Polar H7 Heart Rate Sensor [31] transmits

the heart rate in plaintext. Hence, no pairing is needed to read

the heart rate from this device. Conversely, the Fitbit smart-

watch [20] requires link-layer encryption and authentication.

In this case, a smartphone has to pair with the smartwatch

before reading its recorded data.

3 Threat Model

We assume the adversary has the same capabilities as the

Dolev–Yao model [19], i.e., the adversary can eavesdrop, in-

tercept, and modify legitimate messages communicated be-

tween a

server

and a

client

. The adversary can also inject

any message into the communication channel. However, the

adversary does not know the secret key shared between the

server

and the

client

, and the used cryptographic functionality

are perfectly secure. Also, the adversary cannot replace the

ﬁrmware of the

server

client

. Since BLE is a short-range

communication protocol, we assume that the distance between

the adversary and the

client

, and the distance between the ad-

versary and the

server

, are both within the Bluetooth range.

In this scenario, the adversary aims to impersonate the

server

and to mislead the client with spoofed messages.

4 Formal Analysis of BLE Reconnection

We perform formal veriﬁcation of the BLE link-layer au-

thentication mechanism when the

client

reconnects with a

previously connected

server

. We utilize ProVerif [9] to carry

out this protocol veriﬁcation.

1 free a ttAc ce ss Re q [private].

2 free a tt Ac ce ss Rs p [private].

3 free a tt Se c Ac ce ss Re q [private].

4 free a tt Se c Ac ce ss Rs p [private].

5 // Secrecy and integrity of attribute read request and

attribute value

6 query attacker( a tt Ac ce ss Re q ) .

7 query attacker( a tt Ac ce ss Rs p ) .

8 query attacker( a tt Se cA cc es sR e q ).

9 query attacker( a tt Se cA cc es sR s p ).

10 // Authenticity of attribute request and response

11 query event( c li en tR ec vR sp ) == > inj-event( s er ve rS en dR sp ).

12 // Consistency of request and response security levels

13 query x: S ec Lv ; event( c l i en tR eq Se cL v ( x) ) == > inj-event(

se rv er Rs p Se cL v ( x) ).

Listing 1: ProVerif code with the veriﬁed security properties.

4.1 ProVerif Model

We build a formal model for the authentication process when

the

client

reconnects with the

server

in a new session. The

authentication process is modeled as two communicating

state machines, one for the

client

and one for the

server

. We

model the state machine corresponding to the transmission

of the attribute request of the

client

and the state machine

corresponding to the handling of the attribute request on the

server

in the BLE speciﬁcation [11]. The model comprehen-

sively covers the different types of messages including those

corresponding to the attribute access requests, attribute ac-

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.

We also consider all the features of the attributes to cover

the different usage scenarios of

server

devices. Therefore,

we model the attributes on the

server

as both readable and

writable.

Furthermore, we model two types of attributes: (1) basic

attributes that can be accessed without pairing (i.e., at security

level 1), and (2) sensitive attributes that can be accessed after

pairing (at security level 2 or higher). Finally, we model the

client

to send access requests to the

server

to read/write these

two types of attributes in different orders. The shared secret

key established during the pairing is used to encrypt/decrypt

the trafﬁc when encryption is needed.

Security Goals.

We analyze the above model in the light

of traditional security goals that are presented in Listing 1.

These security goals include: (1) Conﬁdentiality, i.e., the com-

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

being detected (Line 6-9), and (3) Authenticity, i.e., the com-

municated messages can be veriﬁed to be generated by the

genuine sender (Line 11). Besides, we also check one BLE

speciﬁc security goal extracted from the rules speciﬁed in the

speciﬁcation [11] when initiating requests from the

client

and

handling requests on the

server

. Only if the security level of

the connection is consistent with the requirement to access

the attribute, should the

server

give read/write access to the

client (Line 13).

4.2 Discovered Design Weaknesses

Through formal veriﬁcation, we discover several instances of

violations of the checked security goals when the previously-

connected devices reconnect. These violations result in the

following two security weaknesses that can be potentially

exploited by an adversary to launch spooﬁng attacks.

4.2.1 Weakness-1: Optional Authentication

We ﬁnd that the link-layer encryption/authentication is op-

tional: the

client

and the

server

may choose to disable it for a

speciﬁc attribute. Therefore, in the case of the basic attribute,

the conﬁdentiality, integrity, and authenticity goals of the at-

tribute access request and response can be violated as shown

in the following results from ProVerif.

RESULT not attacker(attAccessRsp[]) is false.

Counterexample:

out(plain_channel, ~M) with ~M = attAccessReq at 2 in

copy a

in(plain_channel, ~M) with ~M = attAccessReq at 11 in

copy a_1

out(plain_channel, ~M_1) with ~M_1 = errCode at 13 in

copy a_1

in(plain_channel, a_2) at 14 in copy a_1

out(plain_channel, ~M_2) with ~M_2 = attAccessRsp at 16

in copy a_1

The attacker has the message ~M_2 = attAccessRsp.

A trace has been found.

We note that the

server

determines the security level of its

connection with the

client

based on the requested attribute’s

access control policy. As the counterexample shows, when

the access control policy allows the lowest security level (i.e.,

security level 1) of the connection, the attribute access request

and the response can be transmitted in plaintext. In this case,

no link-layer authentication is deployed. Therefore, the at-

tacker can launch spooﬁng attacks against the server and the

client devices.

We highlight that because the security level of the con-

nection is guided by the

server

, the

client

cannot enforce a

connection with higher security levels if the

server

only al-

lows connections with security level 1. This aspect makes

both the server and the client vulnerable to spooﬁng attacks.

4.2.2 Weakness-2: Circumventing Authentication

The BLE speciﬁcation provides two possible authentication

procedures when the

client

reconnects with the

server

after

pairing.

(1) Reactive Authentication.

In this procedure, the

client

sends the attribute access request in plaintext (i.e., at security

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

the one required for accessing the attribute, the

client

reacts

by enabling the encryption/authentication.

For this procedure, the formal analysis indicates that the

authenticity of the access response can be violated, as shown

by the following ProVerif output.

RESULT inj-event(clientRecvRsp) ==>

inj-event(serverSendRsp) is false.

Counterexample:

event clientReqSecLv(secLv1) at 3 in copy a

out(plain_channel, ~M) with ~M = attAccessReq at 4 in

copy a

in(plain_channel, a_1) at 5 in copy a

event clientRecvRsp at 14 in copy a (goal)

The event clientRecvRsp is executed at 14 in copy a.

A trace has been found.

As the counterexample shows, the attacker can ﬁrst inter-

cept the request sent from the

client

. After that, the attacker

can respond to the

client

with any message other than an error

message, so that the

client

will receive and accept the message

from the attacker.

Although the sensitive attribute stored at the

server

is not

leaked to the adversary, the adversary can eavesdrop on the

request sent by the

client

, impersonate the

server

, and trick the

client

with a spoofed response corresponding to the sensitive

attribute. We will demonstrate in Section 5.1 that the existing

BLE stack implementation (when accessed via

gatttool

) on

Linux follows this reactive authentication making the corre-

sponding clients vulnerable to spooﬁng attacks.

(2) Proactive Authentication.

In this procedure, the

client

device proactively enables the encryption/authentication be-

fore sending any request to the

server

. In particular, the

client

enables the encryption using the pre-shared secret key previ-

ously established, and then it proceeds with the authentication.

In this case, if the

server

fails to enable the encryption (which

also means that it fails to enable the authentication), the

client

aborts the connection. Our formal veriﬁcation shows that all

the checked security goals hold during proactive authentica-

tion, as shown by the following results.

RESULT not attacker(attSecAccessReq[]) is true.

RESULT inj-event(clientRecvRsp) ==>

inj-event(serverSendRsp) is true.

RESULT inj-event(clientReqSecLv(x)) ==>

inj-event(serverRspSecLv(x)) is true.

Unfortunately, as we will further elaborate in Section 5.2,

the existing BLE stack implementations used by Andriod

and iOS fail to correctly follow this procedure making the

Server

Read attribute request

(Plaintext)

Encryption needed

Insufficient Encryption

(Plaintext)

Enable encryption

and authentication

Enable encryption

and authentication

(Encrypted and authenticated)

Attribute value

(Encrypted and authenticated)

Read attribute request

Connected

Connection request

Reconnect to a paired server device

Accept attribute

value

Client

(a) Reconnection with the paired benign server.

(Plaintext)

No authentication

or encryption

Spoofed attribute value

(Plaintext)

Read attribute request

Adversary

ConnectedConnected

Connection request

Reconnect to a paired server device

Accept spoofed

attribute value

Client

Advertise as

benign server

(b) Instantiation of BLESA against the client.

Figure 1: BLE communication workﬂow 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 spooﬁng attacks.

5 BLE Spooﬁng Attack (BLESA)

We exploit the design weaknesses identiﬁed through the for-

mal veriﬁcation to craft the BLE Spooﬁng Attack (

BLESA

In this attack, an adversary provides spoofed data to a client

device pretending to be a previously-paired server device.

Attack Setup.

We examine the scenario where the

server

and the

client

were securely paired in a previous session.

Currently, they are disconnected, but they intend to start a

new session. This scenario happens when, for instance, the

client

moves out of the communication range of the

server

and then it gets back.

In this scenario, the adversary ﬁrst discovers the

server

and

connects with it to obtain information (e.g., the identiﬁer)

about a

server

’s attributes. The adversary can easily obtain

this information because the BLE protocol is designed to

allow any device to connect with another BLE device and

obtain information about provided attributes. Further, since

the BLE advertising packets are always transmitted in plain-

text, the adversary can easily impersonate the benign

server

by advertising the same packets and cloning its MAC address.

Then, the adversary starts broadcasting spoofed advertising

packets to ensure that whenever the

client

attempts to start a

new session with the previously-paired

server

, it can discover

the spoofed advertising packets and establish a connection

with the adversary.

At this point, the adversary is ready to launch

BLESA

against the

client

. We present the workﬂows of

BLESA

against the

client

following the reactive authentication proce-

dure and that following the proactive authentication procedure

in the following sections.

5.1 BLESA against Reactive Authentication

Figure 1a shows an illustration where the

client

and the

server

reconnect, and the reactive authentication procedure (dis-

cussed in Section 4.2.2) plays out in a benign environment.

The

client

ﬁrst sends an attribute read request to the

server

at the lowest security level (i.e., level 1) without any encryp-

tion/authentication. If the attribute is sensitive and can be read

only at a higher security level (e.g., security level 3 with en-

cryption and authentication), the

server

responds to the

client

with an error message (e.g., insufﬁcient encryption). After

receiving the error message, the

client

elevates the security

level by enabling encryption and authentication using the pre-

shared secret key and sends the request again. At this time,

the

server

readily accepts the read request and returns the

attribute value.

Now we present the workﬂow of

BLESA

, as shown in

Figure 1b. Here, the adversary intercepts the attribute read

request from the

client

and responds with a spoofed attribute

value. Since the

client

does not encounter any error message,

it mistakenly assumes that the attribute can be accessed at the

Server

Client

(Encrypted and authenticated)

Attribute value

(Encrypted and authenticated)

Read attribute request

Reconnect to a paired server device

ConnectedConnected

Connection request

Enable encryption

Encryption and

authentication enabled

Encryption and

authentication enabled

Accept attribute

value

(a) Reconnection with the paired benign server.

Reconnect to a paired server device

No long-

term key

Advertise as

benign device

No authentication

or encryption

Connected

Bypass authentication

and connection not abort

Client

Connection request

Enable encryption

Encryption fails

Attribute read request

Spoofed attribute value

Adversary

(Plaintext)

Accept spoofed

attribute value

(b) Instantiation of BLESA against the client.

Figure 2: BLE communication workﬂow 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

does not enable the encryption/authentication, and it accepts

the spoofed attribute value.

We highlight that in this instantiation of

BLESA

, the fun-

damental reason making the attack possible is the fact that

the

client

device relies on the

server

’s error message to adapt

the used security level.

5.2 BLESA against Proactive Authentication

Figure 2a shows the workﬂow of the proactive authentication

procedure triggered when a

client

device reconnects with a

benign

server

. Right after the connection, the

client

requests

to enable the encryption (and authentication) using the pre-

shared key, and the

server

complies with the request. Then

the

client

securely sends an attribute read request, and the

server

securely responds with the (encrypted and authenti-

cated) attribute value. If the BLE stack correctly implement-

ing the proactive authentication follows the speciﬁcation (as

presented in Figure 10.2 on page 1382 in [11]), BLESA will

fail against the

client

. However, our further analysis reveals

that both Android and iOS-based

client

devices suffer from a

logic bug that makes BLESA possible against these devices.

Implementation Vulnerability.

According to the BLE

speciﬁcation, when the

client

reconnects with the previously-

paired

server

, if the encryption enabling process fails during

the proactive authentication procedure, the

client

should ei-

ther re-pair with the

server

(as mentioned in Figure 3) or abort

the connection. However, the BLE stacks in some

client

s (i.e.,

... If encryption fails either the bond no longer exists on the re-

mote device, or the wrong device has been connected. The local

device

must, after user interaction to conﬁrm the remote de-

vice, re-bond, perform service discovery and re-conﬁgure

the remote device...

Figure 3: Description of the BLE protocol (page 1381 in [11])

indicating the steps to deal with the failure in enabling the

encryption during the proactive authentication procedure.

Android and iOS-based devices) fail to follow the speciﬁ-

cation correctly. Speciﬁcally, we discover that even if the

enabling encryption process fails, the

client

may not abort

the connection and continue the communication in plaintext

without re-pairing with the

server

. This ﬂaw can be exploited

by an adversary to launch BLESA.

... if the Host indicates that

a key is not available

, the slave

shall either send an LL_REJECT_IND ... or

Key Missing

...

The Link Layer can now send LL Data PDUs and LL Control

PDUs; these packets will not be encrypted.

Figure 4: Description of the BLE protocol (page 3031 in [11])

indicating the procedure to deal with the non-availability of

the long-term key at the client device.

We suspect that this implementation vulnerability is likely

caused by the way in which this part of the BLE protocol is

explained in the ofﬁcial documentation.

Speciﬁcally, since encryption is not mandatory in BLE

for accessing basic attributes and some

server

devices do

not support link-layer encryption (i.e., the design weakness-

1 discussed in Section 4.2.1), the BLE speciﬁcation makes

provisions to maintain the compatibility and enhance usabil-

ity with these resource-constrained

server

devices. For this

reason, when the encryption/authentication fails, the BLE

data and control messages can still be transmitted in plaintext

as described in the speciﬁcation (Figure 4). We believe that

the contradiction originating from the details in the speci-

ﬁcation shown in Figures 3 and 4 may have confused the

BLE stack developers. As such, they made the logical mis-

take of not aborting the connection in the event of failure of

the encryption process, which is mandatory for accessing the

security-sensitive attributes on a previously-paired server.

Figure 2b presents the details of how the

BLESA

succeeds

against

client

devices using the proactive authentication pro-

cedure, but affected by the explained implementation vulnera-

bility. Speciﬁcally, after the connection to the adversary, if the

client

attempts to enable the encryption, the adversary sends

an error message to the

client

specifying the non-availability

of the long-term key so that the encryption fails. At this point,

the

client

does not follow correctly the BLE speciﬁcation

(which, in this case, recommends aborting the connection),

but continues the connection with the adversary.

Due to the ﬁrst design weakness described in Section 4.2.1,

the

client

then proceeds to send the read request for the target

attribute in plaintext. Unlike the

server

, the adversary read-

ily grants the access to the attribute, making it available at

the lowest security level (i.e., security level 1), and it feeds

spoofed attribute data to the

client

. Consequently, the

client

accepts the spoofed data from the adversary.

6 Implementation and Impact

In this section, we ﬁrst examine the impact of the two iden-

tiﬁed design weaknesses in the real-world BLE stack imple-

mentations (Section 6.1 and Section 6.2). We then elaborate

on the impact of

BLESA

on the Linux platforms (Section 6.3)

and the Android/iOS mobile platforms (Section 6.4).

6.1 Examination of Design Weakness-1

To ﬁnd out if there are indeed certain BLE server devices that

do not employ the link-layer authentication, we follow two

approaches: (1) We inspect the behavior of a set of BLE de-

vices’ companion applications through static analysis. (2) We

sample a set of real-world BLE devices and inspect their com-

munication packets with runtime analysis.

Static Analysis of Mobile Applications.

A typical BLE

device (e.g., Fitbit ﬁtness tracker) relies on its companion

mobile application (e.g., the Fitbit application) which enables

the end-user to access and manage the recorded attribute data

Table 1: List of BLE

server

devices examined to evaluate the

impact of the design weakness-1.

Device Name

Support for link-layer

authentication

Nest Protect Smoke Detector ×

Nest Cam Indoor Camera ×

SensorPush Temperature Sensor ×

Tahmo Tempi Temperature Sensor ×

August Smart Lock ×

Eve Door&Window Sensor ×

Eve Button Remote Control ×

Eve Energy Socket ×

Ilumi Smart Light Bulb ×

Polar H7 Heart Rate Sensor ×

Fitbit Versa Smartwatch

√

Oura Smart Ring

√

(e.g., the number of footsteps). Since the pairing procedure

(to establish a secret key) is one of the prerequisites for en-

abling the link-layer authentication, we can readily conﬁrm

that the BLE device does not support the link-layer authen-

tication if there is no pairing API invoked in its companion

application. To this end, we utilize the static analysis frame-

work, FlowDroid [6], to inspect the Android BLE applications.

More speciﬁcally, for each companion application, we use the

Class Hierarchical Analysis (CHA) option in FlowDroid to

build the call graph and ﬁnd whether the application indeed

invokes the pairing API from any of its entry points (e.g.,

an Activity). Since CHA is a relatively conservative way for

call-graph construction, it may miss part of the method invo-

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

apps using pairing.

Our static analysis starts with 33,785 popular applications,

which are automatically crawled from AndroZoo website [1]

in January and February 2020. Based on the constructed call-

graph and corresponding APIs of these applications, we ﬁnd

that only 127 applications contain the BLE data read/write op-

erations. We then check if the pairing API (

createBond()

) is

invoked in these applications. Unfortunately, we ﬁnd that only

41 (32.3%) out of the 127 inspected applications contain the

pairing procedure, implying that a majority of the investigated

BLE companion applications (67.7%) do not implement the

link-layer authentication.

Runtime Analysis of Transmitted Packets.

We examine

12 BLE devices (as listed in Table 1) which are selected to rep-

resent a variety of application from mainstream BLE device

manufacturers. We connect each of these

server

devices with

a Google Pixel XL phone and read their attributes. During

these experiments, we intercept the runtime communicated

packets using an Ubertooth One radio [33]. By analyzing the

intercepted packets, we ﬁnd that 10 out of the 12 inspected

Table 2: List of BLE

client

platforms examined to evaluate the

impact of the design weakness-2 and utilized as the victims

to evaluate BLESA.

Platform OS BLE Stack

Google Pixel XL Android 8.1, 9, 10 Fluoride [17]

iPhone 8 iOS 12.1, 12.4, 13.3.1 iOS BLE stack

Linux Laptop Ubuntu 18.04

BlueZ 5.48 [14]

(accessed via gatttool)

Thinkpad X1 Yoga Windows 10 V. 1809 Windows stack

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

tication. To this end, we conclude that most real-world BLE

devices do not employ link-layer authentication.

6.2 Examination of Design Weakness-2

For the examination of the second weakness, we test four

different

client

devices that cover all major platforms with

different BLE stack implementations. We present detailed

information about these devices in Table 2. We run experi-

ments on each of these platforms to explore the answers for

the following two questions: (1) Which of the two authen-

tication procedures (i.e., reactive or proactive, as discussed

in Section 4.2.2) does the

client

device utilize when it recon-

nects with a

server

device? (2) If the

client

device follows the

proactive authentication procedure, does its BLE stack imple-

mentation have any logic ﬂaw making it vulnerable against

a spooﬁng attack? To answer these two questions, we ﬁrst

pair each tested

client

with a

server

(which is emulated using

a Linux laptop, as shown in Table 3) and then disconnect

them. Thereafter, we reconnect the tested

client

with the same

server

, and we ask the

client

to read one of the

server

’s at-

tributes, while capturing all the generated BLE trafﬁc using

Wireshark [18].

By analyzing the trafﬁc data corresponding to the Linux

laptop used as the client, we ﬁnd that the Linux BLE stack

(i.e., BlueZ accessed via

gatttool

) implements the reactive

authentication procedure. As a result, the Linux BLE stack

suffers from the weakness described in Section 4.2.2.

Conversely, we ﬁnd that the Android, iOS, and Windows

BLE stacks implement the proactive authentication procedure.

Among them, the Windows BLE stack strictly follows the

BLE speciﬁcation. However, both Android and iOS devices

continue the reconnection even when the encryption/authenti-

cation fails (as elaborated in Section 5.2).

Responsible Disclosure.

We have reported the vulner-

ability to Apple and Google on April 8, 2019. Apple has

acknowledged our ﬁndings, assigned the CVE-2020-9770

to the vulnerability, and ﬁxed it. Although Google has also

conﬁrmed the vulnerability, we have been told that our vul-

nerability report is similar to another report submitted three

days earlier than us

. We note that a more recent (as of May

We received the following reply from Google: "The Android Security

Table 3: BLE server devices utilized to evaluate BLESA.

Platform OS BLE Stack

Linux Laptop Ubuntu 18.04 BlueZ 5.48

Oura Ring [25] Vendor OS

Vendor Firmware

Table 4: Adversary’s platform for launching BLESA.

Platform OS BLE Stack

Linux PC & BT Dongle Ubuntu 18.04 BlueZ 5.48

2020) Android BLE implementation in our test device (i.e.,

Google Pixel XL with Android 10) is still vulnerable.

6.3 BLESA against Linux Clients

For attacking the Linux

client

(listed in the third row in Ta-

ble 2), we utilize another Linux laptop (listed in the ﬁrst row

in Table 3) as the

server

device. The emulated

server

runs

a python script to provide a service corresponding to a sen-

sitive attribute that can be read at security level 3 (i.e., with

an encrypted and authenticated connection). To emulate the

adversary, we use a Linux desktop with a CSR 4.0 [15] Blue-

tooth dongle (shown in Table 4). The adversary also runs a

python script that handles the messages received from the

client

and launches

BLESA

against it. Besides, we use the

gatttool

on the client device to send the attribute read re-

quests and receive the responses.

To launch

BLESA

, the adversary carries out the follow-

ing steps which are akin to the procedure described in

Section 5.1:

scan (

bluetoothctl

) for the advertising

packets transmitted by the

server

to record its MAC ad-

dress;

change the adversary’s Bluetooth MAC address

(

bdaddr

tool in BlueZ) to the

server

’s MAC address so

that the

client

can reconnect with the adversary;

broad-

cast the same (impersonated) advertising packets as the

server

by issuing Host Controller Interface (HCI) com-

mands,

HCI_LE_Set_Advertising_Parameters

HCI_LE_

Set_Advertising_Data

, and

HCI_LE_Set_Advertising_

Enable

, to the dongle; and

inject the spoofed data via

ATT_

READ_RSP

message after receiving

ATT_READ_REQ

message

from the client.

By performing these steps, the adversary successfully by-

passes the reactive authentication procedure of the Linux

client and tricks the client into accepting the spoofed data.

6.4 BLESA against Android/iOS Clients

Since

BLESA

bypasses the link-layer authentication by down-

grading the connection to plaintext, all Android and iOS-

based

client

devices communicating with the BLE

server

Team believes that this is a duplicate of a report previously submitted by

another external researcher on Apr 5, 2019".

(a) Benign battery level (43%).

(b) Spoofed battery level (0%).

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

mechanism (e.g., encryption or authentication) are vulnerable

BLESA

. We note that according to prior research [32], 46%

of the Android applications (2,379 million cumulative instal-

lations) do not utilize application-layer security while reading

data from BLE

server

devices. This implies that at least 46%

of the Andriod applications are vulnerable against

BLESA

The Apple app store is likely to have a similar proportion of

vulnerable applications.

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

(the

server

device, shown in Table 3). The adversary carries

out the ﬁrst three steps similar to those utilized for attack-

ing Linux clients as discussed in Section 6.3, i.e.,

scan

for the advertising packets of the ring;

clone the advertis-

ing packets and the MAC address of the ring;

advertise

as the ring. Thereafter, the adversary performs the follow-

ing:

send an HCI command

HCI_LE_Long_Term_Key_

Request_Negative_Reply

indicating the unavailability of

the key to bypasse the encryption and authentication when the

HCI event

HCI_LE_Long_Term_Key_Request

is received;

inject the spoofed data via

ATT_READ_RSP

messages after

receiving

ATT_READ_REQ

message from the phone. We note

that the adversary can follow the same steps to launch

BLESA

against an iOS client device (the second row in Table 2).

By performing these steps, the adversary successfully in-

jects spoofed data into the smartphone, and the companion

application of the ring running on the smartphone displays

the spoofed data to the user. Figure 5a shows that, in our

experiment, the real battery level of the Oura Ring device

is 43%. Through

BLESA

, we successfully inject a spoofed

battery level (0%) to the application, as shown in Figure 5b.

At the same time, we also inject another spoofed message

which triggers a notiﬁcation in the application mentioning

that the charging is complete, as shown in Figure 5c.

We note that although the ﬁrst spoofed message tricks

the application into believing that the battery level is at 0%,

the application interestingly accepts another spoofed mes-

sage (corresponding to charging completion) and displays the

false notiﬁcation to the user. A demo of this attack can be

accessed at

https://pursec.cs.purdue.edu/projects/

blesa.html.

7 Mitigation of BLESA

To prevent

BLESA

, we need to secure the reconnection pro-

cedure between

client

s and their previously-paired

server

de-

vices. We can achieve this by improving the BLE stack im-

plementations and/or updating the BLE speciﬁcation.

Updating Implementation.

As far as the Linux BLE

stack (BlueZ accessed via

gatttool

) is concerned, the

client

devices can be updated to only employ the proactive

authentication. We clarify that, another Linux client tool,

bluetoothctl

, used by typical applications and built on the

D-Bus APIs in BlueZ, strictly follows the proactive authen-

tication speciﬁcation, and therefore, is immune to

BLESA

According to BlueZ developers, they have marked

gatttool

as deprecated and will remove

gatttool

and its source code

from BlueZ completely and only keep

bluetoothctl

. Also,

the discovered implementation vulnerability of the proac-

tive authentication used by Android and iOS

client

s can be

mitigated by correctly following the BLE speciﬁcation. The

updated implementation must ensure that when the authenti-

cation with a previously-paired

server

fails, the

client

aborts

the connection and restarts the pairing process.

A more fundamental problem is that even for the proactive

authentication,

BLESA

can bypass the link-layer authentica-

tion in the presence of other potential bugs in the implemen-

tation. This is a typical scenario in which authentication at

multiple layers is suggested by the security researchers [21].

In fact, the link-layer problem would not be an exploitable

issue if we had authenticaiton/encryption at application-layer.

Unfortunately, such an improvement might not be widely de-

ployed because a large proportion of resource-constrained

devices cannot be remotely updated.

Updating Speciﬁcation.

We argue that while it is important

to ﬁx the implementation bugs to promptly make the BLE

devices secure against

BLESA

, it is equally critical to chart

out a roadmap to prevent more advanced spooﬁng attacks.

To this end, we should prevent the

client

from sending the

attribute access request ﬁrst and adjust the security level of

the connection later based on the error message returned by

the

server

. In other words, the

client

should ﬁrst obtain the

authentic information about the access requirements of the

attributes stored at the

server

, and then adjust the security level

of the connection to meet those requirements, before sending

the access request. However, this approach requires the

client

to record the security requirements for each attribute on the

server

during the pairing process. Therefore, pairing process

in the speciﬁcation needs to be updated so that the

server

can

send the security requirements of each of its attributes to the

client.

Challenges and Future Directions.

Patching different vul-

nerabilities at different layers in a timely fashion is a naive and

straight forward approach to prevent spooﬁng attacks in BLE.

However, this approach is unlikely to work well in practice

because such ad-hoc, case-by-case ﬁxes might not be feasibly

adopted by the extremely fragmented BLE ecosystem at a

large-scale. BLE device vendors tend to sacriﬁce security for

utility, especially for low-end BLE devices. It is especially

challenging to secure those low-end BLE devices that do not

support any ﬁrmware update. Also, it is difﬁcult to modify the

pairing process while maintaining the backward compatibil-

ity with the legacy BLE devices. In addition, fundamentally

addressing the BLE protocol vulnerabilities will require up-

dating the BLE speciﬁcation, which requires a lot of time and

coordination. Therefore, such challenges bring the need for a

device-agnostic, legacy-friendly, and comprehensive solution

to mitigate the threat of spooﬁng attacks, as partially explored

by a recent study [34].

8 Related Work

Formal analysis of the Bluetooth Protocol.

Existing lit-

erature focuses on the formal analysis of Bluetooth pairing

protocols. Chang et al. [13] have formally analyzed the au-

thentication process in the Bluetooth legacy pairing and the

secure simple pairing, and revealed their weaknesses. Phan et

al. [30] have also formally veriﬁed and found vulnerabilities

in the secure simple pairing. Arai et al. [5] have speciﬁcally

analyzed the numeric comparison protocol used in the secure

simple pairing and identiﬁed potential attacks. Nguyen et

al. [29] have discovered vulnerabilities in the protocols that

use out-of-band channels to establish shared keys. In contrast,

in this paper, we focus on the formal modeling and analysis

of the reconnection procedure in the BLE protocol, which

leads to two design weaknesses in the authentication process.

Attacks against Bluetooth.

A majority of the recent stud-

ies focus on the design weaknesses and implementation ﬂaws

in the Bluetooth stacks. Naveed et al. [28] have discussed

the mis-binding between applications and external Bluetooth

Classic devices. Sivakumaran et al. [32] have revealed sim-

ilar mis-binding issues for BLE devices and analyzed the

application-layer security issues in BLE applications on An-

droid. Antonioli et al. [3] have discovered a logic ﬂaw in the

key negotiation protocol during pairing and exploited it to

decrypt the encrypted trafﬁc. BadBluetooth [35] has revealed

how a malicious Bluetooth device can launch severe attacks

against mobile platforms. Biham et al. [8] have focused on the

Elliptic Curve Difﬁe-Hellman protocol and found weaknesses

in the Bluetooth pairing procedure against invalid curve at-

tacks. The study closest to our work is presented by Antonioli

et al. [4] where they have presented impersonation attacks

against Bluetooth Classic by exploiting the existing support

for legacy pairing methods and role-switching feature. In this

paper, we focus on the design weaknesses and implemen-

tation vulnerabilities in the BLE stack and how they can be

exploited to launch the spooﬁng attack,

BLESA

. We highlight

that since

BLESA

can be launched by an adversary without

any additional assistance from a malicious application pre-

installed on the

client

device, it is more powerful and practical

than the attacks in the prior art [3, 4, 28, 32, 35].

9 Conclusion

In this paper, we carried out a formal veriﬁcation of the re-

connection procedure deﬁned in the BLE speciﬁcation, and

we discovered two design weaknesses in the BLE link-layer

authentication mechanism. By exploiting these design weak-

nesses, we proposed

BLESA

, a novel BLE spooﬁng attack

through which an attacker can impersonate a BLE

server

de-

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).

In addition, further examination of the identiﬁed weak-

nesses in real-world BLE implementations revealed a related

implementation vulnerability in the Android and iOS BLE

stacks. Due to this vulnerability, these two stacks are vulnera-

ble against BLESA.

To showcase

BLESA

, we provided an in detail description

of how to use this attack to spoof data coming from a ﬁtness

tracker to an Android smartphone. Moreover, we estimated

the number of existing Android apps potentially affected by

this attack. Finally, we discussed possible improvements in

the reconnection procedure, to fundamentally mitigate the

threat of spooﬁng attacks like BLESA.

Acknowledgments

We thank the anonymous reviewers for their valuable com-

ments and suggestions. This work was supported in part by

ONR under Grant N00014-18-1-2674. Any opinions, ﬁndings,

and conclusions in this paper are those of the authors and do

not necessarily reﬂect the views of the ONR.

References

[1]

Kevin Allix, Tegawendé F. Bissyandé, Jacques Klein,

and Yves Le Traon. Androzoo: Collecting millions of

android apps for the research community. In Proceed-

ings of the 13th International Conference on Mining

Software Repositories, MSR ’16, 2016.

[2]

Daniele Antonioli, Nils Tippenhauer, and Kasper Bonne

Rasmussen. Key negotiation downgrade attacks on blue-

tooth and bluetooth low energy. ACM Trans. Inf. Syst.

Secur., 0(ja).

[3]

Daniele Antonioli, Nils Ole Tippenhauer, and Kasper

Rasmussen. The KNOB is Broken: Exploiting Low

Entropy in the Encryption Key Negotiation Of Blue-

tooth BR/EDR. In Proceedings of the USENIX Security

Symposium (USENIX Security), August 2019.

[4]

Daniele Antonioli, Nils Ole Tippenhauer, and Kasper

Rasmussen. BIAS: Bluetooth Impersonation AttackS.

In Proceedings of the IEEE Symposium on Security and

Privacy (S&P), 2020.

[5]

Kenichi Arai and Toshinobu Kaneko. Formal Veriﬁ-

cation of Improved Numeric Comparison Protocol for

Secure Simple Paring in Bluetooth Using ProVerif. In

Proceedings of the International Conference on Security

and Management (SAM). The Steering Committee of

The World Congress in Computer Science, Computer

Engineering and Applied Computing (WorldComp),

2014.

[6]

Steven Arzt, Siegfried Rasthofer, Christian Fritz,

Eric Bodden, Alexandre Bartel, Jacques Klein, Yves

Le Traon, Damien Octeau, and Patrick McDaniel. Flow-

Droid: Precise Context, Flow, Field, Object-Sensitive

and Lifecycle-Aware Taint Analysis for Android Apps.

In Proceedings of the 35th ACM SIGPLAN Conference

on Programming Language Design and Implementation,

PLDI ’14, 2014.

[7]

Vaibhav Bedi. Exploiting BLE smart

bulb security using BtleJuice: A step-by-

step guide.

https://blog.attify.com/

btlejuice-mitm-attack-smart-bulb/

, 2018.

Accessed: August 1, 2019.

[8]

Eli Biham and Lior Neumann. Breaking the Bluetooth

Pairing–The Fixed Coordinate Invalid Curve Attack. In

International Conference on Selected Areas in Cryptog-

raphy. Springer, 2019.

[9]

Bruno Blanchet. An Efﬁcient Cryptographic Protocol

Veriﬁer Based on Prolog Rules. In 14th IEEE Computer

Security Foundations Workshop (CSFW-14), June 2001.

[10]

Bluetooth Special Interest Group. 2019

Bluetooth Market Update.

https://www.

bluetooth.com/bluetooth-resources/

2019-bluetooth-market-update/

, 2019. Ac-

cessed: August 1, 2019.

[11]

Bluetooth Special Interest Group. Core speciﬁca-

tions 5.2.

https://www.bluetooth.org/docman/

handlers/downloaddoc.ashx?doc_id=478726

2019. Accessed: April 1, 2020.

[12]

Victor Casares. Mimo baby hack.

https://medium.com/@victor_14768/

mimo-baby-hack-ac7fa0ae3bfb

, 2018. Accessed:

August 1, 2019.

[13]

Richard Chang and Vitaly Shmatikov. Formal analy-

sis of authentication in bluetooth device pairing. FCS-

ARSPA07, 2007.

[14]

BlueZ contributers. Bluez.

http://www.bluez.org/

2019. Accessed: August 1, 2019.

[15]

CSR. CSR 4.0 Bluetooth USB

adapter.

https://www.amazon.com/

Bluetooth-Adapter-Songway-Computer-Keyboard/

dp/B07KWVXBKZ/ref=sr_1_46?keywords=

bluetooth+adapter+car+4.0&qid=1563227361&s=

electronics&sr=1-46. Accessed: August 1, 2019.

[16]

Aveek K. Das, Parth H. Pathak, Chen-Nee Chuah, and

Prasant Mohapatra. Uncovering privacy leakage in BLE

network trafﬁc of wearable ﬁtness trackers. In Proceed-

ings of the 17th International Workshop on Mobile Com-

puting Systems and Applications (HotMobile), 2016.

[17]

Android Developers. Fluoride Blue-

tooth stack.

https://android.

googlesource.com/platform/system/bt/+/

181144a50114c824cfe3cdfd695c11a074673a5e/

README.md, 2019. Accessed: August 1, 2019.

[18]

Wireshark developers. Wireshark Go Deep.

https:

//www.wireshark.org. Accessed: May 15, 2020.

[19]

Danny Dolev and Andrew Yao. On the security of public

key protocols. IEEE Transactions on information theory,

29(2), 1983.

[20]

Fitbit. Fitbit versa 2.

https://www.fitbit.com/us/

products/smartwatches/versa

, 2019. Accessed:

Aug 1, 2019.

[21]

Mario Frustaci, Pasquale Pace, Gianluca Aloi, and Gian-

carlo Fortino. Evaluating critical security issues of the

IoT world: Present and future challenges. IEEE Internet

of things journal, 5(4), 2017.

[22]

Constantinos Kolias, Lucas Copi, Fengwei Zhang, and

Angelos Stavrou. Breaking BLE beacons for fun but

mostly proﬁt. In Proceedings of the 10th European

Workshop on Systems Security (EuroSec), 2017.

[23]

Patrick Lam. Soot phase options (call graph con-

struction).

https://www.sable.mcgill.ca/soot/

tutorial/phase/phase.html

, 2019. Accessed: Aug

1, 2019.

[24]

Angela Lonzetta, Peter Cope, Joseph Campbell, Bassam

Mohd, and Thaier Hayajneh. Security vulnerabilities in

Bluetooth technology as used in IoT. Journal of Sensor

and Actuator Networks, 7(3), 2018.

[25]

Oura Health Ltd. OURA SMART RING.

https://

ouraring.com/products/

, 2019. Accessed: August

1, 2019.

[26]

Ubuntu Manpage. gatttool - tool for Bluetooth

Low Energy device.

http://manpages.ubuntu.com/

manpages/cosmic/man1/gatttool.1.html

. Ac-

cessed: May 15, 2020.

[27]

Tal Melamed. An active man-in-the-middle attack on

Bluetooth smart devices. International Journal of Safety

and Security Engineering, 8(2), 2018.

[28]

Muhammad Naveed, Xiao-yong Zhou, Soteris

Demetriou, XiaoFeng Wang, and Carl A Gunter. Inside

job: Understanding and mitigating the threat of external

device mis-binding on android. In Proceedings of the

Network and Distributed System Security Symposium

(NDSS), 2014.

[29]

Trung Nguyen and Jean Leneutre. Formal analysis of

secure device pairing protocols. In 2014 IEEE 13th

International Symposium on Network Computing and

Applications. IEEE, 2014.

[30]

Raphael C-W Phan and Patrick Mingard. Analyzing

the secure simple pairing in Bluetooth v4.0. Wireless

Personal Communications, 64(4), 2012.

[31]

Polar. Polar h7 heartrate sensor.

https:

//support.polar.com/us-en/support/H7_heart_

rate_sensor, 2019. Accessed: Aug 1, 2019.

[32]

Pallavi Sivakumaran and Jorge Blasco. A study of the

feasibility of co-located app attacks against BLE and a

large-scale analysis of the current application-layer secu-

rity landscape. In Proceedings of the USENIX Security

Symposium (USENIX Security), August 2019.

[33]

Ubertooth Developers. Ubertooth One.

https://github.com/greatscottgadgets/

ubertooth/wiki

, 2019. Accessed: August 1,

2019.

[34]

Jianliang Wu, Yuhong Nan, Vireshwar Kumar, Mathias

Payer, and Dongyan Xu. BlueShield: Detecting Spoof-

ing Attacks in Bluetooth Low Energy (BLE) Networks.

In 23nd International Symposium on Research in At-

tacks, Intrusions and Defenses (RAID 2020), 2020.

[35]

Fenghao Xu, Wenrui Diao, Zhou Li, Jiongyi Chen, and

Kehuan Zhang. BadBluetooth: Breaking Android Secu-

rity Mechanisms via Malicious Bluetooth Peripherals.

In Proceedings of the 26th Annual Network and Dis-

tributed System Security Symposium (NDSS), 2019.