Protecting Privacy of BLE Device Users

This paper is included in the Proceedings of the

25th USENIX Security Symposium

August 10–12, 2016 • Austin, TX

ISBN 978-1-931971-32-4

Open access to the Proceedings of the

25th USENIX Security Symposium

is sponsored by USENIX

Protecting Privacy of BLE Device Users

Kassem Fawaz, University of Michigan; Kyu-Han Kim, Hewlett Packard Labs;

Kang G. Shin, University of Michigan

https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/fawaz

USENIX Association 25th USENIX Security Symposium 1205

Protecting Privacy of BLE Device Users

Kassem Fawaz

∗

Kyu-Han Kim

†

Kang G. Shin

∗

The University of Michigan

†

Hewlett Packard Labs

Abstract

Bluetooth Low Energy (BLE) has emerged as an attrac-

tive technology to enable Internet of Things (IoTs) to

interact with others in their vicinity. Our study of the

behavior of more than 200 types of BLE-equipped de-

vices has led to a surprising discovery: the BLE proto-

col, despite its privacy provisions, fails to address the

most basic threat of all—hiding the device’s presence

from curious adversaries. Revealing the device’s exis-

tence is the stepping stone toward more serious threats

that include user proﬁling/ﬁngerprinting, behavior track-

ing, inference of sensitive information, and exploitation

of known vulnerabilities on the device. With thousands

of manufacturers and developers around the world, it is

very challenging, if not impossible, to envision the vi-

ability of any privacy or security solution that requires

changes to the devices or the BLE protocol.

In this paper, we propose a new device-agnostic sys-

tem, called BLE-Guardian, that protects the privacy of

the users/environments equipped with BLE devices/IoTs.

It enables the users and administrators to control those

who discover, scan and connect to their devices. We have

implemented BLE-Guardian using Ubertooth One, an

off-the-shelf open Bluetooth development platform, fa-

cilitating its broad deployment. Our evaluation with real

devices shows that BLE-Guardian effectively protects

the users’ privacy while incurring little overhead on the

communicating BLE-devices.

1 Introduction

Bluetooth Low Energy (BLE) [4] has emerged as the

de facto communication protocol in the new computing

paradigm of the Internet of Things (IoTs) [8, 9, 15, 23,

24, 39]. In 2013, over 1.2 billion BLE products were

shipped [9], with this number expected to hit 2.7 bil-

lion in 2020 [3]. BLE-equipped products are embedded

and used in every aspect of our lives; they sense nearby

objects, track our ﬁtness, control smart appliances and

toys provide physical security, etc. The BLE protocol

owes this proliferation to its low energy and small pro-

cessing footprint as well as its support by most end-user

devices [20], such as PCs, gateways, smartphones, and

tablets.

A BLE-equipped device advertises its presence to let

interested nearby devices initiate connections and glean

relevant information. These advertisements, however,

are a double-edged sword. An unauthorized, potentially

malicious, party can use these advertisements to learn

more about the BLE-equipped devices of a certain user

or in a speciﬁc environment [22], generally referred to in

literature as the inventory attack [42]. Revealing the de-

vice’s presence is the stepping stone toward more serious

privacy and security attacks with grave consequences in

the case of medical devices for example, especially for

high-value targets [31].

The BLE speciﬁcation contains some privacy pro-

visions to minimize the effects of inventory attacks

and ensuing threats, namely address randomization and

whitelisting. A BLE device is supposed to randomize

its address to prevent others from tracking it over time.

Moreover, only devices with a pre-existing trust rela-

tionship (whitelisted devices) are supposed to access the

BLE-equipped device.

In this paper, we ﬁrst analyze how existing BLE’s

privacy measures fare in the real-world deployments

through our own data-collection campaign. To the best

of our knowledge, this is the ﬁrst study that systemat-

ically analyzes threats to the BLE-equipped devices in

the wild. We recruited participants from our institution

and the PhoneLab testbed [27] to collect the BLE adver-

tisements in their vicinity. We have collected and an-

alyzed the advertisements from 214 different types of

BLE-equipped devices. Analyzing our dataset has led to

a surprising discovery: BLE advertisements, due to poor

design and/or implementation, leak an alarming amount

of information that allows the tracking, proﬁling, and

1206 25th USENIX Security Symposium USENIX Association

ﬁngerprinting of the users. Furthermore, some devices

allow external connections without an existing trust re-

lationship. Unauthorized entities can access unsecured

data on the BLE-equipped devices that might leak sensi-

tive information and potentially inﬂict physical harm to

the bearer.

Almost all of the existing approaches addressing some

of the above threats rely on mechanisms that necessar-

ily include changes to the protocol itself or to the way

the BLE-equipped devices function [21, 40]. Changing

the operation of such devices, post-production, requires

their patching by securely pushing a ﬁrmware update.

With thousands of manufacturers and developers around

the world, it is very challenging, sometimes impossi-

ble, to guarantee ﬁrmware patches to the millions of al-

ready deployed devices [11]. Even a security-aware user

might lack the ability to update the ﬁrmware of a BLE-

equipped device. Patch management is, therefore, the

leading security challenge in the emerging IoTs [10, 19]

(including BLE-equipped devices) for many reasons:

• Manufacturers might lack the ability to apply OTA

updates [1] for some deployed BLE-equipped de-

vices because they (such as a BLE-equipped preg-

nancy test) are neither programmable nor equipped

with an Internet connection.

• Customers might neither receive news about the up-

date nor be able to apply an update even if available.

For example, a month after the 2013 “Foscam” we-

bcams hacking incident, 40,000 of 46,000 vulnera-

ble cameras were not updated although a ﬁrmware

update was available [17].

• Companies do not have enough ﬁnancial incentives

or resources to maintain the devices post deploy-

ment [34]. For example, Samsung discontinued two

lines of smart refrigerators after 2012 so that cus-

tomers can’t receive updates for their purchased re-

frigerators [6].

There is, therefore, a need for a new class of practical ap-

proaches to mitigate the privacy threats to BLE-equipped

devices. In this paper, we seek to answer the following

related question: can we effectively fend off the threats

to BLE-equipped devices: (1) in a device-agnostic man-

ner, (2) using COTS (Commercial-Off-The-Shelf) hard-

ware only, and (3) with as little user intervention as pos-

sible?

We present BLE-Guardian as an answer to the

above question. It is a practical system that protects

the user’s BLE-equipped devices so that only user-

authorized entities can discover, scan, or connect to

them. BLE-Guardian relies on an external and off-the-

shelf Bluetooth radio as well as an accompanying appli-

cation. Therefore, a user can easily install (and control)

BLE-Guardian to any BLE gateway, be it a smartphone,

tablet, PC, Raspberry PI, Artik-10, etc. The external ra-

dio achieves the physical protection, while the applica-

tion, running on the gateway, enables the user to interact

with BLE-Guardian.

BLE-Guardian provides privacy and security protec-

tion by targeting the root of the threats, namely the ad-

vertisements. In particular, BLE-Guardian opportunis-

tically invokes reactive jamming to determine the enti-

ties that can observe the device existence through the

advertisements (device hiding module), and those that

can issue connection requests in response to advertise-

ments (access control module). In a typical BLE envi-

ronment, however, achieving BLE-Guardian’s objective

is rather challenging. Many BLE-equipped devices, in-

cluding the ones to be protected, advertise on the same

channel; while at the same time other devices, in re-

sponse to advertisements, issue scan and connection re-

quests. The timing is of an essence for BLE-Guardian;

it invokes jamming at the right time for the right dura-

tion. Therefore, BLE-Guardian does not inadvertently

harm other devices, preserves the ability of authorized

entities to connect the BLE-equipped device, and always

hides the BLE-equipped device when needed.

More than one device might be authorized to con-

nect to the BLE-equipped device. BLE-Guardian dif-

ferentiates the scan and connection requests originating

from authorized devices versus those that are fraudulent.

This is particularly challenging as the BLE advertise-

ment channel lacks any authentication mechanism for the

advertisements and connections. BLE-Guardian utilizes

Bluetooth classic as an out-of-band (OOB) channel to

authorize a device after obtaining the user’s permission.

It uses the OOB channel to instruct the connecting de-

vice to issue ordinary connection requests with (varying)

special parameters that other unauthorized devices can’t

predict. It also alerts the user when unauthorized parties

attempt connection to the user’s BLE devices.

BLE-Guardian achieves its objectives with mini-

mum requirements from the external radio. Effectively,

BLE-Guardian operates with a radio that offers only the

basic capabilities of reception and transmission on the

BLE channels. As a result, BLE-Guardian avoids em-

ploying sophisticated and customized (thus impractical)

radios and signal processing approaches.

We implement BLE-Guardian using the commer-

cially available Ubertooth One

USB dongle so that

BLE-Guardian can be easily installed on any BLE gate-

way. We also implement accompanying apps for differ-

ent BLE gateways, such as Android and Raspberry PI.

We evaluate BLE-Guardian using several BLE devices

for different real-world scenarios, where we assess its

effectiveness in combating privacy threats, its low over-

https://greatscottgadgets.com/ubertoothone/

USENIX Association 25th USENIX Security Symposium 1207

head on the channel and devices, and little disruption to

the operation of legitimate BLE devices. In particular,

BLE-Guardian is able to protect up to 10 class-2 target

BLE-equipped devices within a 5m range with less than

16% energy overhead on the gateway.

The rest paper is organized as follows. Section 2 dis-

cusses the related work. Section 3 provides the nec-

essary BLE background. Section 4 states the privacy

threats arising from BLE advertisements through our

data-collection campaign. Section 5 details the design

of BLE-Guardian. Section 6 presents the implemen-

tation of BLE-Guardian and evaluates its effectiveness.

Finally, the paper concludes with Section 7.

2 Related Work

There have been limited efforts related to BLE devices

that target the security and privacy threats resulting from

the devices revealing their presence. The only excep-

tion is the work by Wang [40], where a privacy enhance-

ment is proposed for BLE advertisements to ensure con-

ﬁdentiality and prevent replay attacks as well as tracking.

This enhancement is based on providing an additional 3-

way handshake between the peripheral and the gateway.

Unarguably, this enhancement changes both the protocol

and the peripheral which is highly impractical as we ar-

gued before.

Another related ﬁeld of research includes wearable

and body-area networks. The work by Leonard [21] uses

a honeypot to lure in adversaries that attempt to attack

the user’s wearable devices. The honeypot uses a set of

helper nodes to expose fake services with known weak-

nesses so that the attacker connects to them. This work,

however, doesn’t handle the privacy threat arising from

BLE advertisements. A determined attacker will be able

to distinguish fake trafﬁc from legitimate one based on

RF signatures from the devices and issue connections to

the user’s real devices.

Other relevant work includes approaches to protecting

medical devices. Mare et al. [25] propose a mechanism

that protects health sensors when communicating with a

gateway. The proposed system, albeit relevant, doesn’t

apply for the BLE ecosystem. It also mandates chang-

ing the medical devices. Gollakota et al. [12] propose an

external device, called Shield, that the user wears to con-

trol access to his/her embedded medical device. Shield

implements friendly jamming so that only an authorized

programmer can communicate with the medical device.

BLE-Guardian takes an entirely different approach

by targeting the control plane of the BLE protocol in-

stead of the data plane. BLE-Guardian does not need

to continually protect an ongoing authorized connection

and more importantly need not invoke jamming signal

cancellation that requires accurate estimation of chan-

nel condition in a dynamic mobile indoor environment

as well as a full duplex radio. BLE-Guardian consti-

tutes a reference design that can function with any radio

that has reception and transmission capabilities on the

2.4 GHz band. BLE-Guardian, also, considers far less

restrictive scenarios than Shield. It does not have to be

within centimeters of the device-to-be-protected as the

case with Shield. Moreover, BLE-Guardian’s practical

design allows scaling up protection for multiple devices

(multiple connectors and protected devices) simultane-

ously, which is not the case for Shield that considers a

two-device scenario only [36].

Finally, researchers have explored ways to reduce in-

formation leaks from sensors in a smart home environ-

ment [30, 37]. Srinivasan et al. [37], Park et al. [30], and

Schurgot et al. [35] propose a set of privacy enhance-

ments that include perturbing the timing of broadcasted

sensory data along with padding the real sensory data

with fake data to confuse the adversary. These protocols

fail to address the threats resulting from BLE advertise-

ments and have the shortcoming of requiring changes to

the sensors as well.

3 BLE Primer

The BLE (Bluetooth 4.0 and newer) protocol has been

developed by the Bluetooth SIG to support low power

devices such as sensors, ﬁtness trackers, health monitors,

etc. Currently, more than 75,000 devices in the market

support this protocol along with most of more capable

devices such as smartphones, tablet, PCs, and recently

access points [2].

3.1 BLE States

A BLE device assumes either a central or peripheral role.

A peripheral device is typically the one with lower capa-

bilities and with the information to advertise. The central

device, typically an AP, PC, or smartphone, scans for ad-

vertisements and initiates connections.

The BLE speciﬁcation places a higher burden on the

central device. It is responsible for initiating the con-

nection and thus has to keep scanning until it receives

an advertisement. Conversely, the peripheral (prior to its

connection) sleeps for most of the time and only wakes

up to advertise, which helps save its limited energy.

3.2 Advertisements

BLE advertisements are instrumental to the operation of

the protocol, and constitute the only means by which a

device can be discovered. The speciﬁcation deﬁnes 4 ad-

vertisement message types as shown in Table 1, and 3

1208 25th USENIX Security Symposium USENIX Association

Table 1: The four types of BLE advertisements.

Type Advertising Interval

ADV IND 20ms − 10.24s

ADV

DIRECT IND 3.75ms

ADV

NONCONN IND 100ms − 10.24s

ADV

SCAN IND 100ms − 10.24s

ch.1 ch. 2 ch. 3

Advertising session

Advertising interval Rando m de lay

Figure 1: The advertisement pattern in BLE.

advertisement channels: 37 (2402MHz), 38 (2426MHz),

and 39 (2480MHz).

ADV

DIRECT IND (introduced in Bluetooth 4.2) is

a special advertisement; it enables fast reconnection be-

tween the central and the peripheral devices. The periph-

eral, when turned on, will broadcast advertisements at a

fast rate (once every 3.75ms, for 1.28 seconds) that are

directed to the client (with a pre-existing trust relation-

ship) before assuming the central role. The advertise-

ment message only contains the message type, source,

and destination addresses.

The other three advertisements are similar to each

other in that they are periodic. The advertisement in-

terval determines the frequency with which each device

advertises. This interval has to be chosen, at conﬁgu-

ration time, between 20ms and 10.24 seconds (at incre-

ments of 0.625ms) for the ADV

IND advertisement and

between 300ms and 10.24 seconds for the other two ad-

vertisements. To prevent advertisements of different de-

vices from colliding with each other, each device waits

for a random amount of time between 0 and 10ms (in ad-

dition to the advertisement interval) before it advertises

(Fig. 1).

The advertisement session constitutes the period when

the device is actually advertising. During each adver-

tisement session, the device advertises on the three ad-

vertisement channels given a pre-conﬁgured channel se-

quence. Before switching to the next channel, the device

has to wait for a preset period of time (less than 10ms)

for scan and connection requests (t

in Fig. 1). We will

henceforth refer to the advertisement interval, the chan-

nel sequence, and the waiting time as the advertisement

pattern.

Each advertisement message contains the message

type, source address, along with some of the services

offered by the device and their respective values. The

speciﬁcation deﬁnes a set of services that have unique

UUIDs, such as device name. The message is limited in

length, and hence, to get more information about the de-

vice, an interested device can either issue a scan request

to which the advertising device responds with a scan re-

sponse or connect to the advertising device.

3.3 Connections

Not all BLE devices accept connections; devices that use

ADV

NONCONN IND advertisement messages run in

transmit mode only and they don’t accept any scan or

connection requests such as iBeacons.

Also, devices advertising with ADV

SCAN IND mes-

sages don’t accept connections but accept scan requests.

Particularly, when the device broadcasts an advertise-

ment message on some channel, it listens on the same

channel for some time (less than 10ms) before switching

to the next channel. It waits for scan requests from clients

wanting to learn more information to which it responds

with a scan response.

Devices that advertise using ADV

IND messages are

scannable and connectable; they respond to scan mes-

sages and connection requests. After sending an adver-

tisement message, the device listens for connection re-

quests. The connection request contains the source and

destination addresses along with other connection pa-

rameters. These parameters contain the connection in-

terval, the timeout, and the slave interval. When con-

nected, the device starts frequency hopping according to

a schedule negotiated with the central. If the device (now

peripheral) doesn’t receive any communication from the

central over the period deﬁned by the “timeout interval”,

it drops the connection.

While connected, the device must not broadcast con-

nectable advertisement messages (the ﬁrst two types of

Table 1). It can, however, still broadcast non-connectable

advertising messages to share information (the last two

types of Table 1) with other clients in its transmission

range which still leaks information about the device’s

name, type, and address.

3.4 Privacy and Security Provisions

The BLE speciﬁcation borrows some security provisions

from classical Bluetooth to establish trust relationships

between devices, a process known as pairing. When

the device boots for the ﬁrst time, it will advertise using

ADV

IND with its public Bluetooth address. The user

can then pair a smartphone (or other BLE-equipped de-

vice) so that the two devices exchange a secret key that

will enable future secure communication.

USENIX Association 25th USENIX Security Symposium 1209

Once a BLE-equipped device is paired with another

device, it can invoke more privacy and security provi-

sions. The ﬁrst provision is whitelisting, and the device

will only accept connections from devices it has been

paired with before, i.e., those that are whitelisted. Also,

the device might accept connections from any client but

might require higher security levels for some of the ser-

vices it exposes so that only authorized users access sen-

sitive content.

Finally, the BLE speciﬁcation deﬁnes a privacy pro-

vision based on address randomization to prevent device

tracking. When two devices are paired, they exchange an

additional key called the Identity Resolution Key (IRK).

The device uses this key to generate a random address ac-

cording to a timer value set by the manufacturer, which

it will use to advertise. This random address will be re-

solved by the paired device using the same key. As this

random address is supposed to change regularly, curious

parties shouldn’t be able to track a BLE-equipped device.

Devices that don’t utilize address randomization can re-

sort to direct advertising (ADV

DIRECT IND) to enable

fast and private reconnections.

These privacy provisions are akin to those proposed

earlier in the context of WiFi networks. Researchers have

long identiﬁed privacy leaks from the consistent identi-

ﬁers broadcasted by wireless devices. They proposed pri-

vacy enhancements that include randomizing or frequent

disposing of MAC addresses [14, 18] and hiding them

through encrypting the entire WiFi packets [13]. These

enhancements require introducing changes for the client

devices.

4 Threats from BLE Devices

While, in theory, BLE’s privacy provisions might be ef-

fective to thwart threats to the user’s privacy, whether or

not various manufacturers and developers properly im-

plement them is an entirely different story. In what fol-

lows, we investigate how the BLE privacy provisions fare

in the wild using a dataset collected in our institution and

using the PhoneLab testbed [27] of SUNY Buffalo.

We developed an Android app that collects the content

of the advertisement messages. We recruited users from

our institution and from the PhoneLab testbed. We didn’t

collect any personal information about the users and thus

obtained non-regulated status from the IRB of our insti-

tution. One could view this study as crowdsourcing the

analysis of BLE devices; instead of purchasing a limited

set of devices and analyzing them, we monitored the be-

havior of a broad range of devices in the wild. Analyzing

the advertisements we collected from 214 different types

of devices (sample of these devices shown in Tables 2

and 3), we observed:

Table 2: A sample of devices with revealing names.

Name Type

LG LAS751M(27:5D) music streaming

JS00002074 digital pen

ihere key ﬁnder

spacestation battery/storage extension

Jabra PULSE Smart smartbulb

DEXCOMRX Glucose monitor

Clover Printer 0467 printer

Frances’s Band ea:9d LE smartband

Gear Fit (60ED) activity tracker

Lyve Home-00228 photo storage

Matthias-FUSE headset

Richelle’s Band b2:6a LE smartband

vivosmart #3891203273 activity tracker

KFDNX key fob

OTbeat heart rate monitor

Thermos-4653 Smart Thermos

POWERDRIVER-L10C3 smart power inverter

Table 3: A sample of devices with consistent addresses

for more than a day.

Name Type Days observed

One activity tracker 37

Flex activity tracker 37

Zip activity tracker 37

Surge activity tracker 36

Charge activity tracker 36

Forerunner 920 smartwatch 36

Basis Peak sleep tracker 25

MB Chronowing smartwatch 15

dotti pixel light 7

UP MOVE ﬁtness tracker 2

GKChain laptop security 2

Gear S2 (0412) smartwatch 2

Crazyﬂie quadropter 1

Dropcam camera 1

1. Two advertisement types (ADV NONCONN IND

and ADV

SCAN IND) require a ﬁxed address

which would enable tracking of a mobile target.

2. Devices that are bonded to the users advertise us-

ing ADV

IND messages instead of the more private

ADV

DIRECT IND.

3. Some devices, albeit not expected to do so, use their

public Bluetooth addresses in advertisements. This

also enables tracking as well as identifying of the

device manufacturer.

4. Other devices implement poor address randomiza-

tion by ﬂipping some bits of the address render-

ing them ineffective against tracking. This has also

been identiﬁed in other studies of BLE devices [22].

5. A large number of devices advertise their names

(Table 2), revealing sensitive information about

them, the user, and the environment. Also, some

of the device names contain personal information

1210 25th USENIX Security Symposium USENIX Association

or unique identiﬁers that may enable user tracking.

6. Some devices use a consistent Bluetooth address

for long periods of time which renders address ran-

domization ineffective (Table 3). Examples include

various types of wristbands (Fitbit Flex, Forerunner

920, etc.), headsets, smartwatches (Apple Watch or

Samsung Gear), etc. This has also been identiﬁed

by Das et al. [7], where they analyzed the adver-

tisements of BLE-equipped ﬁtness trackers. Das et

al. found the ﬁtness trackers constantly advertising

with consistent (non-private) BLE addresses. In our

experiments, we observed that Flex and One kept

the same address for 37 days, so did One and Charge

for 30 days.

7. Some devices accept connections from non-bonded

devices. This allows access to the services on the

device including the unique manufacturer ID, for in-

stance, which allows for user tracking regardless of

the device’s address. For example, we were able

to connect to various devices and access data from

them without any existing trust relationship, such

as various Fitbit devices (One, Zip Flex, Charge),

Garmin Vivosmart, digital pens, etc. It is worth not-

ing that we connected to these devices under con-

trolled experimental settings, not in the wild. As a

result, an external access control mechanism is nec-

essary to protect such devices.

The above observations indicate that the address ran-

domization, part of the BLE speciﬁcations, fails to pro-

vide the promised privacy protection. Various develop-

ers and manufacturers do not implement it properly; they

rely on public Bluetooth addresses, apply weak random-

ization, or keep a consistent address for a long time. On

the other hand, even if address randomization is properly

implemented, other information in the advertisement or

in the device might contain unique information (device

name or id) that allows for its tracking.

Moreover, data accessed from an advertisement or the

device (once connected) might reveal sensitive informa-

tion about the user or the environment. Through our data

collection campaign, we were able to detect different

types of glucose monitors, wristbands, smart watches,

ﬁtness trackers, sleep monitors, laptops, smartphones,

laptop security locks, security cameras, key trackers,

headsets, etc. Knowing which type of glucose moni-

tor the user is carrying or the type of physical security

system s/he has installed could lead to serious harm to

the user. Finally, an adversary might use such advertise-

ment data as side information to infer more about the

user’s behavior. For example, a temperature sensor con-

stantly reading 60

◦

F in winter would indicate a vacant

property [41] which may invite in a thief.

attacker

BLE device

Authorized client

BLE-Guardian

(a) Mobile

attacker

BLE device

Authorized client

BLE-Guardian

(b) Vehicle

Figure 2: Example deployments of BLE-Guardian.

5 BLE-Guardian

BLE-Guardian addresses the aforementioned privacy

threats by allowing only authorized clients to dis-

cover, scan, and connect to the user’s BLE-equipped

device. Before delving into the inner workings of

BLE-Guardian, we ﬁrst describe the system and threat

models.

5.1 System and Threat Models

5.1.1 System Model

A typical BLE scenario involves two interacting entities:

the client and the BLE-equipped device. The BLE device

broadcasts advertisements to make other nearby clients

aware of its presence along with the services/information

it is offering. A client can then connect to the device

to access more services/information and control some of

its attributes, in which case it will be the BLE-device’s

gateway to the outside world.

The user’s mobile device (e.g., smartphone or tablet)

acts a gateway where BLE devices are wearable (e.g.,

ﬁtness trackers), or mHealth devices (e.g., Glucose mon-

itor) (Fig. 2a). In a home environment, the user’s ac-

cess point, PC, or even mobile device, serves as a gate-

way for BLE devices that include smart appliances, we-

bcams, physical security systems, etc. Last but not least,

a smart vehicle or the driver’s mobile device operate as

gateways (Fig. 2b) for the different BLE-equipped sen-

sors in the vehicle, such as tire pressure.

An interested

reader could consult the work of Rouf et al. [32] for a

discussion on the security and privacy risks of a wireless

tire pressure sensor.

BLE-Guardian leverages the existence of gateways

near the BLE-equipped devices to fend off unauthorized

clients scanning and connecting to them. It comprises

both hardware and software components. The hardware

https://my-fobo.com/Product/FOBOTIRE

USENIX Association 25th USENIX Security Symposium 1211

component is an external Bluetooth radio that connects

physically to the gateway, while the software component

is an accompanying application that runs on the gate-

way. BLE-Guardian requires another software compo-

nent to run on the clients willing to discover and con-

nect to the user’s BLE devices. The user, be it an owner

of the BLE-equipped device or a client, interacts with

BLE-Guardian through its software components.

5.1.2 Threat Model

BLE-Guardian only trusts the gateway on which

it is running. Otherwise, the entire operation of

BLE-Guardian will be compromised and will fail to pro-

vide the promised privacy provisions. BLE-Guardian

achieves privacy protection at the device level, so that if it

authorizes a client to access the BLE device, all applica-

tions running on that device will have same access priv-

ileges. This security/privacy dimension is orthogonal to

BLE-Guardian and has been addressed elsewhere [28].

It also requires the user’s BLE device — the one to be

protected — to comply with the BLE speciﬁcations.

BLE-Guardian protects a target BLE-equipped de-

vice against an adversary or an unauthorized/unwanted

device that sniffs the device’s advertisements, issues scan

requests and attempts to connect to the device. The ad-

versary aims to achieve three objectives based on the

BLE devices that the user is deploying:

1. Proﬁling: The adversary aims to obtain an inven-

tory of the user’s devices. Based on this inventory,

the adversary might learn the user’s health condi-

tion, preferences, habits, etc.

2. Tracking: The adversary aims to monitor the user’s

devices to track him/her over time, especially by

exploiting the consistent identiﬁers that the devices

leak as we observed in Section 4.

3. Harming: The adversary aims to access the user’s

BLE device to learn more sensitive information or

even to control it. Both will have severe conse-

quences for the user, especially if a certain device

is known to have some vulnerabilities that allow re-

mote unauthorized access [26].

This adversary can have varying passive and active ca-

pabilities, from curious individuals scanning nearby de-

vices (e.g., using a mobile app), to those with moder-

ate technical knowledge employing commercial sniffers,

all the way to sophisticated adversaries with software-

deﬁned radios.

A passive attacker is capable of snifﬁng all the com-

munications over advertisement channels including those

that fail the CRC check. This includes all commercial

Bluetooth devices and existing Bluetooth sniffers in the

market, such as the Texas Instruments CC2540 chip. The

adversary might possess further capabilities by employ-

ing MIMO receiver that could recover the original signal

from the jammed signal [38], especially in stationary sce-

narios. We refer to this adversary as the strong passive

attacker.

Furthermore, the adversary is capable of injecting traf-

ﬁc into any Bluetooth channel at any given point of time,

but will “play” within the bounds of the BLE speciﬁ-

cations when attempting communication with the BLE

device. This is a reasonable assumption, as the device

won’t otherwise respond to any communication. We

refer to such an adversary as the active attacker. On

the other hand, the attacker might be able to transmit

with higher power than allowed by regulatory bodies, in

which case we refer to as the strong active attacker.

Thus, we have four classes of attackers referring to the

combinations of their passive and active capabilities as

shown in the ﬁrst column of Table 4.

Attacks, including jamming the channel completely,

masquerading as fake devices to trick the users to con-

nect to them, or attacking the bonding process are orthog-

onal to our work. Such attacks have been addressed by

O’Connor and Reeves [29] and Ryan [33]. Finally, once

BLE-Guardian enables the authorized client to connect

to the BLE device, it won’t have any control over what

follows later.

5.2 High-Level Overview

BLE-Guardian is a system the user can use out of the

box; it only requires installing a hardware component

(an external Bluetooth radio) to the gateway and running

an app on the gateway to control and interface with the

Bluetooth radio. Conceptually, BLE-Guardian consists

of device hiding and access control modules. The device

hiding module ensures that the BLE device is invisible to

scanners in the area, while the access control module en-

sures that only authorized clients are allowed to discover,

scan, and connect to the BLE device.

Fig. 3 shows the high-level operation of

BLE-Guardian from the moment a user designates

a BLE device to be protected all the way to enabling

authorized client connection to the protected device.

The high-level operation of BLE-Guardian takes the

following sequence:

1. The user installs the hardware component along

with the accompanying app on the gateway.

2. The user runs the app, which scans for BLE devices

nearby. The user can then choose a device to hide.

3. The device hiding module of BLE-Guardian starts

by learning the advertisement pattern of the target

BLE device along with that of the other devices in

1212 25th USENIX Security Symposium USENIX Association

Owner chooses

BLE device

to be hidden

Devi ce

Hiding

Module

Cl ient

Authe nticati on

New client

appears

Whitelist

Cl ient

Acc es s

granted

Acc es s

denied

Connection

Enabl ing

Authenticated

client appears

Attacker

detected

User A lert

BLE-Guardian

running

Acces s Control Module

Figure 3: The modules of BLE-Guardian and their un-

derlying interactions.

the area. The device hiding module then applies re-

active jamming to hide the device.

4. When a new client enters the area and wants to dis-

cover the user’s devices, it communicates with the

access control module so that the user can either

grant or reject authorization.

5. If the user authorizes the client, the access control

module advertises privately on behalf of the BLE

device to let the authorized client scan and connect

to it.

6. BLE-Guardian monitors if other unauthorized en-

tities are attempting to connect to the BLE device;

in such a case, it blocks the connection and alerts

the user.

5.3 Device Hiding

The hiding module is responsible for rendering the

BLE device invisible to other scanning devices. The

hiding module jams the device’s advertisement ses-

sion to achieve this invisibility. In particular, it

targets three types of advertisements, ADV

IND,

ADV

NONCONN IND, and ADV SCAN IND of Ta-

ble 1, which are periodic and leak more information

about the user as we indicated earlier.

Hiding the BLE device is, however, challenging for

two reasons. The hiding module must jam the BLE de-

vice precisely at the moment it is advertising. Also, it

must not disrupt the operation of other devices advertis-

ing in the same area.

5.3.1 Learning

The hiding module ﬁrst learns the target BLE device’s

advertising pattern before jamming to hide its presence.

The device’s advertisement pattern comprises the adver-

tising interval, advertising channel sequence, and the

time to listen on the individual channels. Fortunately, the

37 long

38 short

39 short

37,38,39

39 long

37 short

39,37,38

37,39,38

37,38

38 long

39 short

37 short

38,39,37

38,37,39

39 long

39,38,37

38,37

39 long

37 short

39,37

38 long

39 short

38,39

39 long

39,38

3839

Eliminate all

sequences

with 37

Eliminate all

sequences with 38

Keep all

sequences

with 37

Keep all

sequences with 37

followed by 38

Figure 4: The learning algorithm followed by

BLE-Guardian. The blue boxes refer to monitoring each

channel either for a short period of time (less than 10ms)

or for a longer period of 10.24 seconds. Depending

on whether an advertisement is detected on the channel

some sequences are eliminated till a sequence is decided

on (gray boxes).

latter two parameters are deterministic and can be ob-

served directly, which is not the case for the advertising

interval. The BLE speciﬁcation leaves it to the device

to determine the advertising pattern, so that there are 15

possible permutations of the channel sequence.

As shown in Fig. 4, BLE-Guardian follows a pro-

cess of elimination to identify the advertising sequence

of the BLE device using a single antenna. In the worst

case, it will take three advertising intervals to learn the

entire advertising sequence of a BLE-equipped device.

This corresponds to the longest path of Fig. 4, where

BLE-Guardian monitors each channel for the maximum

advertising interval of 10.24 seconds. At the same time,

it would have identiﬁed the time the BLE device spends

listening on each channel before switching to the next

channel.

While observing the advertising sequence of the BLE

device, the hiding module keeps track of the interval

separating the consecutive advertisements sessions. The

hiding module observes a set of inter-advertisement in-

tervals, t

= adv + p, where adv is the actual adver-

tisement interval as set by the device and p is a ran-

dom variable representing the random delay such that

p ∈ uni f (0,10 ms). Also, BLE-Guardian will perform

the same process for all advertising devices in the same

area at the same time to learn their advertising parame-

ters as well. Learning other devices’ advertising at the

same time will be useful as evident below.

USENIX Association 25th USENIX Security Symposium 1213

5.3.2 Actuation

After identifying the advertising pattern, the hiding mod-

ule needs to just detect the start of the advertisement ses-

sion. Then, it jams the advertising channels according to

their advertisement sequence. There is a caveat, though;

the hiding module needs to detect the advertisement be-

fore it can be decoded. Otherwise, the rest of the jam-

ming will not be effective.

From monitoring earlier advertisements, the hiding

module obtains a set of t

’s of different devices’ adver-

tisements, including the BLE device to be hidden. The

advertisement interval will be adv = t

− p for each ob-

served inter-advertisement interval. Each observed ad-

vertisement will be used to improve the estimation of

the advertisement interval. For N observed intervals, we

have:

adv =

∑

i=1

− p)=

∑

i=1

−

∑

i=1

p. (1)

Let P =

∑

i=1

p, the random variable P is drawn from

the distribution

p ∗

p...

p. Since the single

random delays p are i.i.d., the mean of P will be equal

to 5 (mean of the original distribution of p) and the stan-

dard deviation of



∑

i=1

√

(3)

. The hiding module

estimates adv as:

adv



= E(adv)=

∑

i=1

−5. (2)

The standard deviation of P will get lower as N in-

creases; it deﬁnes the error in the estimate of adv as

deﬁned by Eq. (1). Given previous N observed adver-

tisements from the BLE device, the hiding module can

predict the next advertisement to happen at adv

∈

[adv

low

, adv

high

] such that:

adv

low

= T

+ adv



−e (3)

adv

high

= T

+ adv



+ e + 10, (4)

where T

is the time of the last advertisement and e

is the 90

percentile value of P (symmetric around

the mean) which approaches 0 as N increases (so that

adv

high

−adv

low

approaches 10ms).

Starting from the last observed T

of the target

BLE device, the advertisement hiding module computes

adv

low

and adv

high

. Also, it enumerates the list of

other devices expected to advertise within the interval

[adv

low

, adv

high

The device hiding module always listens on the ﬁrst

channel of the advertising sequence of the BLE device

to be hidden. During the interval [adv

low

, adv

high

0 5 10

Time (sec)

-100

-80

-60

-40

-20

RSSI (dBm)

Device Advertisement

(a) Over 10 seconds.

1.16 1.18 1.2

Time (sec)

-100

-80

-60

-40

-20

RSSI (dBm)

Device Advertisement

Monitoring Interval

(b) Single adv. interval.

Figure 5: RSSI at channel 37 when a device is advertis-

ing at a distance of 1m at the interval of 960ms.

the device hiding module will sample the RSSI of the

channel very frequently (every 25µs). When the re-

ceived RSSI is −90dBm or higher (the peaks of Fig. 5a),

BLE-Guardian determines that there is a transmission

currently starting to take place. The device hiding mod-

ule moves immediately to jam the channel on which it is

listening. Since the transmission of a typical advertise-

ment message takes 380µs to ﬁnish [16], jamming the

channel will prevent the message from being decoded by

other receivers.

At this point, two situations might arise; (1) the target

BLE device is the only device expected to be advertising

at this time instant, or (2) some other device is expected

to be advertising in the same interval. In the ﬁrst situ-

ation, the target BLE device is most probably responsi-

ble for this transmission as part of its advertisement ses-

sion. The device hiding module repeats the same process

(sample RSSI and jam) over the rest of the channels to

conﬁrm that transmissions follow the device’s advertis-

ing pattern. Fig. 5b shows an example interval where

there is only one device advertising.

In the second situation, the device hiding module can’t

readily ascertain whether the transmission belongs to the

target BLE device or not. This will take place when the

observed transmission sequence matches the advertising

sequence of the target BLE device and some other de-

vice that is expected to advertise at the same interval. To

resolve this uncertainty, immediately after jamming the

advertising message (400 µs after commencing jamming

on the channel), the device hiding module lifts jamming

and sends scan requests for devices other than the tar-

get device. The device hiding module then listens on the

channel to observe if a scan response is received. De-

spite its advertisement being jammed, any device will

still be listening on and will respond to scan requests.

Depending on whether a scan response is received or not,

BLE-Guardian can associate the transmission with the

correct device, be it the target BLE device or some other

1214 25th USENIX Security Symposium USENIX Association

device.

The device hiding module then adjusts the next mon-

itoring interval according to the observed transmissions

in the current intervals as follows:

adv

low

= min(T

)+adv



−e (5)

adv

high

= max(t

)+adv



+ e + 10, (6)

where T

represents the instants of the transmissions

possibly matching the advertisement of the target BLE

device in the current monitoring interval.

Note that we don’t utilize the power level per se, or any

physical-layer indicator, to indicate whether the same de-

vice is transmitting or not, as it is sensitive to the envi-

ronment and the distance between BLE-Guardian and

the target BLE device. To actually perform the jamming,

the device hiding module continuously transmits at the

maximum power for the speciﬁed interval.

BLE-Guardian may jam the advertisements of non-

target devices which might disrupt their operation, which

we referred to as the second situation above. Neverthe-

less, because of the random delay introduced by the de-

vice before each advertisement, the aforementioned “col-

lision” events become unlikely. In Appendix A, we use

renewal theory to show that the expected number of an-

other device’s advertisements within the expected adver-

tising interval of the target BLE-equipped device will al-

ways be less than 1. This applies when BLE-Guardian

protects a single BLE-equipped device. Our evaluation

in Section 6 conﬁrms this observation.

5.4 Access control

So far, BLE-Guardian has hidden the target BLE device,

so neither authorized nor unauthorized entities have ac-

cess to the device. It is the access control module that

authorizes client devices and enables their access to the

target BLE device.

5.4.1 Device Authorization

BLE-Guardian utilizes Bluetooth classic (BR/EDR) as

an out-of-band (OOB) channel to authorize end-user de-

vices intending to scan and access the target BLE de-

vice. BLE-Guardian runs in server mode on the gate-

way waiting for incoming connections, while the “au-

thenticating” device will have BLE-Guardian running in

client mode to initiate connections and ask for authoriza-

tion. The choice of Bluetooth Classic as an OOB channel

is natural; most end-user devices (such as smartphones)

are dual-mode, supporting both BLE and Bluetooth clas-

sic. Moreover, Bluetooth classic already contains pairing

and authentication procedures, eliminating the need for a

dedicated authentication protocol. Last but not least, a

BLE-

Guardian

Client

Target BLE

Device

Attacker

bt_addr, U UID

attempt connection

send pairing request

Client authorized by user

users complete pairing

connection parameters

reduced-info Ad

connection request

Legitimate connection established

data

connection request

Connection dropped

connection request

Unauthorized

connection established

missed advertisements --> alert user

AuthorizationConnection Enabling

Attac k

Detection

Figure 6: The sequence diagram of the access con-

trol module. Thin green lines from the target device

designate the advertisements. Thick green lines from

BLE-Guardian designate the jamming signal.

Bluetooth-equipped end-user device will be able to com-

municate simultaneously over Bluetooth classic and BLE

so that it can communicate with both BLE-Guardian and

the target BLE device.

Fig. 6 depicts the interactions between BLE-Guardian

and a client device when they connect for the ﬁrst time.

BLE-Guardian will be listening on the gateway over

a secure RFCOMM channel with a speciﬁed UUID.

The gateway, however, won’t be running in discoverable

mode so as to prevent others from tracking the user. It is

up to the party interested in authenticating itself to obtain

the Bluetooth address of the user’s gateway as well as the

UUID of the authentication service.

Once the client end-user device obtains the Blue-

tooth address and UUID, it can initiate a secure con-

nection to the gateway. This will trigger a pairing pro-

cess to take place if both devices are not already paired.

BLE-Guardian relies on Bluetooth pairing process to se-

cure the connections between the gateway and the client

device. For future sessions, an already paired client de-

vice can connect to BLE-Guardian without the need for

any user involvement. The owner can also revoke the

privileges of any client device by simply un-pairing it.

5.4.2 Connection Enabling

The device hiding module of BLE-Guardian jams the

entire advertising sequence of the target BLE device, in-

cluding the period it listens for incoming scan or connec-

tion requests so that it cannot decode them. Therefore,

both unauthorized and authorized clients cannot access

the target BLE device (the case of an adversary using

USENIX Association 25th USENIX Security Symposium 1215

high transmission power will be discussed later). Fig. 6

shows the procedure that BLE-Guardian follows to en-

able only the authorized clients access to the target BLE

device.

Immediately after the last advertisement of a single ad-

vertisement session, when the target device is the only

one expected to be advertising, the access control mod-

ule lifts the jamming. This ensures that the BLE device

will not be advertising until the next adverting session,

and it is currently listening for scan and connection re-

quests. Then, BLE-Guardian advertises on behalf of the

target BLE device on the same channel. The advertise-

ment message contains only the headers and the address

of the previously hidden device. It is stripped of explicit

identiﬁers, hence leaking only limited information about

the BLE device for a brief period.

At the same time, BLE-Guardian will communicate

to the authenticated client app the address of the BLE

device and a secret set of connection parameters over

the OOB channel. BLE-Guardian’s app running on the

client device will use the address and the parameters to

initiate a connection to the BLE device. The connection

initiation procedure is handled by the Bluetooth radio of

the client device, which scans for the advertisement with

the provided address. After receiving such an advertise-

ment, it sends a connection request after which both de-

vices will be connected.

The above procedure will not break the way BLE

scans and connections take place. It doesn’t matter from

which radio the actual advertisement was coming. From

the perspective of the BLE device, it will receive a scan

or connection request while waiting for one. On the

other hand, the client device will receive an advertise-

ment message while also expecting one.

5.5 Security and Privacy Features

BLE-Guardian addresses the tracking and proﬁling

threats discussed in Section 5.1.2. It hides the adver-

tisements, which are used as the main means to track

users. It only exposes the advertisement for a very short

period when enabling others to connect. Furthermore,

BLE-Guardian greatly reduces the proﬁling threat by

hiding the contents of the advertisement which leak the

device name, type, and other attributes.

A strong passive attacker [38] can still detect the “hid-

den” peripheral by recovering the real advertisement, so

that it can connect to the BLE-equipped device. Dis-

tinguishing legitimate connection requests based on the

Bluetooth address of the initiator is not effective; an at-

tacker could easily spoof its Bluetooth address to imper-

sonate the authorized client. Therefore, BLE-Guardian

uses the connection parameters of the connection request

to distinguish fraudulent connection requests from legit-

Table 4: The protections offered by BLE-Guardian.

Adversary

Proﬁling

Protect.

Tracking

Protect.

Access

Control

User

Alert

Passive & Active   

Strong Passive &

Active

–  

Passive & Strong

Active

– 

Strong Passive &

Strong Active

–  – 

imate ones. Legitimate connection requests contain the

set of “secret” connection parameters communicated ear-

lier to the client.

The probability of the attacker matching a particular

set of connection parameters is very low. According to

the speciﬁcation, there are more than 3 million possi-

ble combinations of values for the connection, slave, and

timeout intervals. If the connection is established based

on a fraudulent connection request, then BLE-Guardian

prevents the connection from taking place. The connec-

tion request already contains the hopping sequence ini-

tiation. BLE-Guardian hops to the next channel and

jams it so as to prevent the BLE device from receiving

any message from the connected unauthorized device.

The BLE device drops the connection since it receives

no message on the channel.

An attacker might abuse this connection process by

constantly attempting to connect to the BLE device, thus

depriving the authorized client of access. This will al-

ways be possible, even when BLE-Guardian is not de-

ployed. BLE-Guardian observes such a situation from

a high frequency of fraudulent connection requests and

alerts the user of this threat. As it will be evident

in Section 6, an active attacker injecting messages to

the advertising channel can’t affect the operations of

BLE-Guardian.

A strong active adversary, however, can override

BLE-Guardian’s jamming and issue connection requests

that the BLE-equipped device will decode. While jam-

ming, BLE-Guardian runs in transmit mode and can

not monitor the channel for incoming requests. Nev-

ertheless, it detects that the BLE device is missing its

advertising intervals, signifying that it was connected

without BLE-Guardian’s approval. In such a case,

BLE-Guardian alerts the user of the existence of a

strong adversary nearby.

Finally, Table 4 summarizes BLE-Guardian’s capa-

bilities when faced with the various adversaries de-

scribed in Section 5.1.2.

1216 25th USENIX Security Symposium USENIX Association

Figure 7: The deployment scenario for BLE-Guardian

for a mobile user (left) and the main UI (right).

6 Implementation and Evaluation

We now present a prototype of BLE-Guardian along

with its evaluation.

6.1 Implementation

We implement BLE-Guardian using Ubertooth One ra-

dio which is an open platform for Bluetooth research

and development. It can connect to any host that sup-

ports USB such as Raspberry Pi, Samsung’s Artik-10,

PC, smartphone (Fig. 7 (left)), etc. Since communica-

tion over USB incurs latency in the order of a few mil-

liseconds, we implement most of BLE-Guardian’s func-

tionalities inside Ubertooth One’s ﬁrmware to maintain

real-time operation.

We also implement the software component of

BLE-Guardian on Linux and Android. Fig. 7 (right)

shows a screenshot of the BLE-Guardian app while run-

ning on Android in server mode where the user can

choose the device to protect and control its authorized

client list. The app communicates the Bluetooth address

of the chosen device to the Ubertooth One radio.

BLE-Guardian requires running in privileged mode

on the client device in order to be able to connect with

modiﬁed connection parameters. This is easily achiev-

able on Linux-based clients, but might not be the case for

mobile devices. In other words, BLE-Guardian, while

running in client mode on Android, requires root access

to be able to issue connection requests with a set of spec-

iﬁed connection requests. Also, BLE-Guardian (if run-

ning in privileged mode on the client device) can mod-

ify content of the advertisement message from the BLE

scanner to the user-level application to reconstruct the

original hidden advertisement. As such, user-level ap-

plications (on the trusted client) will receive the original

advertisement, which does not break their functionality.

0 0.5 1 1.5 2 2.5 3

Distance (m)

0.5

1.5

cutoff (m)

TI CC2540

clear

covered

0 0.5 1 1.5 2 2.5 3

Distance (m)

0.5

1.5

Galaxy S5

clear

covered

Figure 8: The cutoff distance as a function of the distance

between BLE-Guardian and the target device.

Maintaining BLE-Guardian is easy; it only requires

updating the application running on the gateway which

usually takes place without the user’s intervention (e.g.,

mobile app updates). This application interacts with the

hardware component and applies updates, if necessary,

through pushing ﬁrmware updates, a process which is

also transparent to the users.

6.2 Evaluation

To evaluate BLE-Guardian, we utilize Broadcom

BCM20702A0 and Nordic nRF51822 chips as the tar-

get BLE devices (both transmitting at 4dBm) and the TI

CC2540 dongle as the sniffer node. CC2540 is able to

decode the messages on the three advertisement chan-

nels, even on those that fail the CRC check. We evalu-

ate using Nordic and Broadcom chips instead of actual

BLE products, because these products (such as Fitbits)

are mostly powered by the same (Nordic and Broadcom)

BLE chips.

6.2.1 Impact of Distance

Due to transmission power limitations (battery or regula-

tory bodies’ constraints), there would always be a small

area around the target BLE device where BLE-Guardian

won’t be able to enact the privacy protection. The trans-

mission from the target BLE device covers the jamming

signal of BLE-Guardian. Nevertheless, as the sniffer

moves farther away from the target BLE device (in any

direction), the jamming signal will cover the advertise-

ments, provided that the BLE device and BLE-Guardian

are not very far apart. So, there is a cutoff distance be-

yond which the adversary can’t scan, and connect to the

target BLE device.

We study the cutoff distance of a target BLE device

(advertising at 20ms) at different distances separating it

from BLE-Guardian (between 0 and 3m). At each po-

sition, we move the sniffer node (either a CC2540 don-

gle or Samsung Galaxy S5) around the BLE device, and

USENIX Association 25th USENIX Security Symposium 1217

record the farthest distance at which it received any ad-

vertisement from the BLE device as to study the hidden

terminal effect. Furthermore, we repeat each experiment

twice, the ﬁrst with BLE-Guardian clear of any obsta-

cles and the second with it inside a backpack.

It is evident from Fig. 8 that the cutoff distance in-

creases as BLE-Guardian and the BLE device become

farther apart. In all of the cases, however, the cutoff dis-

tance is less than 1m, even when BLE-Guardian and

the BLE device are 3m apart. This also applies when

BLE-Guardian is inside the backpack which should re-

duce the effectiveness of its jamming. Snifﬁng with

a smartphone has a shorter cutoff distance because the

smartphone’s BLE chip ﬁlters out advertisements failing

the CRC check so that they are not reported to the OS.

The cutoff distance is enough to thwart tracking and

proﬁling in several scenarios, especially when the user

is moving (walking, jogging, biking or driving). In these

scenarios, BLE-Guardian is not farther than 1m from the

target BLE device. An adversary has to get very close to

the user, even if BLE-Guardian is covered in a coat or

bag, to be able to scan or connect to the BLE device.

In other cases, the user has to keep his BLE devices

(to be protected) close to BLE-Guardian in order to

get the best privacy protection possible. Our experi-

ments showed that BLE-Guardian and the target BLE

device must be separated by a maximum distance of 5m

so that an attacker beyond the cutoff distance won’t be

able to decode the advertisements. If BLE-Guardian

and target BLE device are farther apart than this, then

BLE-Guardian’s jamming won’t be able to cover the en-

tire transmission area of the BLE device. In all circum-

stances, however, BLE-Guardian detects unauthorized

connections and alerts the user accordingly.

6.2.2 Evaluation Setup

Beyond the cutoff distance, BLE-Guardian is capable of

hiding the advertisements and controlling access to any

target BLE device regardless of its advertising frequency.

This protection, however, comes at a cost. In what fol-

lows, we evaluate BLE-Guardian’s impact on other in-

nocuous devices, the advertising channel, and the gate-

way. In the evaluation scenarios, we deploy the target

BLE devices at distance of 1.5m from BLE-Guardian,

and the sniffer between BLE-Guardian and the BLE de-

vices (at a distance of 0.5m from BLE-Guardian). We

evaluate BLE-Guardian when protecting up to 10 target

devices with the following advertising intervals: 10.24

sec (highest possible), 5 sec, 2.5 sec, 1.25 sec, 960ms,

625ms, 312.5ms, 100ms, 40ms, and 20ms (lowest possi-

ble). Note that evaluating with 10 target devices con-

stitutes an extreme scenario; according to our dataset,

the average user is bonded to less than 4 devices, which

12345678910

# Advertisers

0.5

Jammed Ads

Adv=20ms

12345678910

# Advertisers

0.5

Adv=960ms

12345678910

# Advertisers

0.5

Jammed Ads

Adv=5000ms

12345678910

# Advertisers

0.5

Adv=10240ms

Figure 9: Portion of jammed advertisements of an in-

nocuous BLE device when BLE-Guardian is running

and protecting up to 10 advertisers.

would indicate the number of target devices (i.e. those to

be protected).

6.2.3 Advertisement Hiding

Impact on Other Devices: We ﬁrst evaluate the num-

ber of advertisements, not belonging to the target BLE

device(s), BLE-Guardian will jam (Fig. 9). While ac-

cidentally jamming other devices doesn’t affect the pri-

vacy properties of BLE-Guardian, it hinders the services

they offer to other users. In particular, we study four

scenarios with an innocuous (not the target) BLE device

advertising at 20ms, 960ms, 5s, and 10.24s, and a vary-

ing number (between 1 and 10) of target devices, which

BLE-Guardian protects. Each subset of target devices

of size N (≤ 10) contains the top N advertising intervals

from the list of Section 6.2.2.

There are two takeaways from Fig. 9. First,

BLE-Guardian has little effect on other devices when it

protects a relatively low number of devices, or when the

advertising interval of the target BLE device(s) is larger

than 500ms; in these cases, BLE-Guardian will be less

active (bars corresponding to less than 6 target devices

in the four plots of Fig. 9). Second, BLE-Guardian has

a higher effect on the innocuous device with higher ad-

vertising frequencies as observed from top-left plot of

Fig. 9, especially when protecting a large number of de-

vices (including those with 20 ms advertising interval).

In the latter case, BLE-Guardian is active for at least

half of the time, representing the worst-case scenario of

BLE-Guardian’s overhead where up to 50% of other de-

vices’ advertisements are jammed. However, since the

advertisement frequency is high, even with a relatively

high rate of jammed advertisements, the user’s experi-

ence won’t be drastically affected. On the other hand,

1218 25th USENIX Security Symposium USENIX Association

12345678910

# advertisers

100

200

delay (ms)

Adv=20ms

12345678910

# advertisers

delay (sec)

Adv=960ms

12345678910

# advertisers

100

150

delay (sec)

Adv=5000ms

12345678910

# advertisers

100

200

delay (sec)

Adv=10240ms

Figure 10: The delay of an authorized client in

successfully connecting to the target device when

BLE-Guardian is running.

when the target BLE device advertises at lower frequen-

cies, the effect on the advertising channels and conse-

quently other devices will be limited as evident from the

rest of the plots of Fig. 9.

Impact on Authorized Access: To enable autho-

rized connections, BLE-Guardian advertises on the be-

half of the target BLE device only when it is conﬁ-

dent that the target device is listening for connections.

BLE-Guardian skips some advertising sessions which

will introduce delays to authorized clients attempting

connections as reported in Fig. 10. In this scenario, an

authorized client is attempting connection to a target de-

vice advertising at 20ms, 960 ms, 5s, and 10.24 s, with an

additional number of protected devices varying from 1 to

10. In the majority of the cases, the client has to wait for

less than a second before successfully receiving an adver-

tisement and issuing a connection. The only exception is

the worst case consisting of BLE-Guardian protecting

all of the 10 target devices (including devices advertis-

ing at intervals less than 100ms). The client might have

to wait for up to multiple advertisement intervals before

being able to connect. This is evident from the rightmost

bar in each of the four plots of Fig. 10.

Impact on Advertising Channels Last but not least,

we evaluate BLE-Guardian’s impact on the advertising

channel, which, if high, might leak information about

the existence of sensitive device(s). In this experiment,

BLE-Guardian protects a single target device advertis-

ing at 20ms (the lowest possible), 960ms, and 10240ms

(the highest possible). At the same time, two innocuous

devices advertise at 20ms, in addition to other 15 devices

not under our control advertising at different frequen-

cies (minimum advertisement interval 30ms). In this sce-

37 38 39

Channel

# unneccessary jams

Adv=20ms

37 38 39

Channel

Adv=960ms

37 38 39

Channel

Adv=10240ms

Figure 11: Unnecessary jamming instances with two ad-

vertisers at 20ms.

nario, BLE-Guardian will be active all the time since the

two innocuous advertisers will force it to enlarge its mon-

itoring interval between 20–30ms (while the advertising

interval of the target device is only 20ms).

Fig. 11 shows the distribution of the number of unnec-

essary jammed instances in each interval when the target

BLE device is expected to advertise. It is evident that

in more than 50% of the intervals when BLE-Guardian

is active, the number of unnecessary jamming instances

events is 0, indicating a low overhead on the channel.

When the target BLE device advertises at a lower fre-

quency, BLE-Guardian is less active (middle and left

plots of Fig. 11). These plots match the real-world

scenarios observed from our data-collection campaign.

Most commercial BLE devices advertise at relatively low

frequencies (at intervals between 1 and 10s).

Finally, we evaluate the accuracy of predicting the next

advertisement event of the target BLE devices. In all the

experiments (including all scenarios), BLE-Guardian

can predict the device’s advertisements, i.e., the target

BLE device advertised in the interval it is expected to.

BLE-Guardian is also able to jam all the advertisements

of the BLE device over the three advertising channels.

This indicates that an attacker can’t modify the behavior

of BLE-Guardian by injecting trafﬁc into the advertising

channels.

6.2.4 Energy Overhead

BLE-Guardian incurs no energy overhead for both the

target BLE devices and the authorized clients. Neverthe-

less, energy overhead is a concern when BLE-Guardian

is attached to a smartphone. We measured the en-

ergy overhead of BLE-Guardian using a Monsoon

power monitor while running on a Samsung Galaxy S4

with Android 4.4.2. In the idle case, BLE-Guardian

consumes 1370mW on average. The average power

consumption rises to 1860mW while transmitting and

1654mW while receiving as shown in Fig. 12a. Fortu-

nately, BLE-Guardian doesn’t sense the channel or per-

USENIX Association 25th USENIX Security Symposium 1219

024

Time (sec)

1.5

2.5

Power (W)

Start Tx

12345

Time (sec)

1.5

2.5

Power (W)

Start Rx

(a) Overhead of basic opera-

tions.

12345678910

# Advertisers

Energy Overhead

(b) Average overhead in differ-

ent scenarios.

Figure 12: The energy overhead of BLE-Guardian run-

ning on Samsung Galaxy S4.

form jamming frequently. Fig. 12b shows the average

energy overhead when BLE-Guardian is protecting the

set of ten devices (we described earlier) at different ad-

vertising intervals. In the worst case of 10 target BLE

devices, including a couple advertising at the highest fre-

quency possible, the energy overhead is limited to 16%

regardless of whether there are other advertisers in the

area. In other cases, when there are less target devices

and/or target devices are advertising at a lower frequency,

the energy overhead is negligible.

7 Conclusion

BLE is emerging as the most prominent and promis-

ing communication protocol between different IoT de-

vices. It, however, accompanies a set of privacy risks.

An adversary can track, proﬁle, and even harm the user

through BLE-equipped devices that constantly adver-

tise their presence. Existing solutions are impractical

as they require modiﬁcations to the BLE-equipped de-

vices, thereby making their deployment difﬁcult. In

this paper, we presented a device-agnostic system, called

BLE-Guardian, which addresses the users’ privacy risks

brought by BLE-equipped devices. BLE-Guardian

doesn’t require any modiﬁcation to the protocol and can

be implemented with off-the-shelf Bluetooth hardware.

We implemented BLE-Guardian using Ubertooth One

radio and Android, and evaluated its effectiveness in pro-

tecting the users’ privacy. In future, we plan to explore

the data plane by analyzing and reducing the data leaks

from BLE devices to unauthorized clients.

8 Acknowledgments

We would like to thank the anonymous reviewers for

constructive comments. We would also like to thank Kr-

ishna C. Garikipati for useful discussions on this paper.

The work reported in this paper was supported in part by

the NSF under grants CNS-1114837 and CNS-1505785,

and the ARO under grant W911NF-15-1-0511.

References

[1] ARTICLE 29 DATA PROTECTION WORKING PARTY.

Opinion 8/2014 on the on recent developments on

the internet of things. http://ec.europa.eu/justice/data-

protection/article-29/documentation/opinion-

recommendation/ﬁles/2014/wp223

en.pdf, Sep. 2014. Accessed:

18-01-2016.

[2] A

RUBA NETWORKS. Data Sheet: Aruba 320 series access points.

http://www.arubanetworks.com/assets/ds/DS

AP320Series.pdf.

[3] B

LUETOOTH SIG. Bluetooth SIG Analyst Digest 2H 2014.

https://www.bluetooth.org/en-us/Documents/Analyst2014. Ac-

cessed: 10-02-2016.

[4] B

LUETOOTH SIG. Speciﬁcation of the Bluetooth Sys-

tem. Version 4.2, Dec. 2014. https://www.bluetooth.org/en-

us/speciﬁcation/adopted-speciﬁcations.

[5] C

OX , D. Renewal theory. Methuen’s monographs on applied

probability and statistics. Methuen, 1962.

[6] C

RIST, R. Samsung swings for the fences with a new smart

fridge at ces. http://www.cnet.com/products/samsung-family-

hub-refrigerator, Jan. 2016. Accessed: 18-01-2016.

[7] D

AS, A. K., PATHAK, P. H., CHUAH, C.-N., AND MOHAP-

ATRA, P. Uncovering privacy leakage in ble network trafﬁc of

wearable ﬁtness trackers. In Proceedings of the 17th Interna-

tional Workshop on Mobile Computing Systems and Applications

(New York, NY, USA, 2016), HotMobile ’16, ACM, pp. 99–104.

[8] D

EGELER, A. Bluetooth low energy: Security issues and

how to overcome them. https://stanfy.com/blog/bluetooth-low-

energy-security-issues-and-how-to-overcome-them/, Jun. 2015.

Accessed: 02-02-2016.

[9] D

IGI-KEY TECHNICAL CONTENT. Cy-

press PSoC 4 BLE (Bluetooth Low Energy).

http://www.digikey.com/en/articles/techzone/2015/dec/cypress-

psoc-4-ble-bluetooth-low-energy, Dec. 2015. Accessed:

12-01-2016.

[10] F

EDERAL BUREAU OF INVESTIGATION. Inter-

net of Things Poses Oppotunities for Cyber Crime.

https://www.ic3.gov/media/2015/150910.aspx, Sep. 2015.

Accessed: 18-01-2016.

[11] F

EDERAL TRADE COMMISSION. Internet of

Things, Privacy & Security in a Connected World.

https://www.ftc.gov/system/ﬁles/documents/reports/federal-

trade-commission-staff-report-november-2013-workshop-

entitled-internet-things-privacy/150127iotrpt.pdf, Jan. 2015.

[12] G

OLLAKOTA, S., HASSANIEH, H., RANSFORD, B., KATABI,

D.,

AND FU, K. They can hear your heartbeats: Non-invasive

security for implantable medical devices. In Proceedings of the

ACM SIGCOMM 2011 Conference (New York, NY, USA, 2011),

SIGCOMM ’11, ACM, pp. 2–13.

[13] G

REENSTEIN, B., MCCOY, D., PANG, J., KOHNO, T., SE-

SHAN, S., AND WETHERALL, D. Improving wireless privacy

with an identiﬁer-free link layer protocol. In Proceedings of the

6th International Conference on Mobile Systems, Applications,

and Services (New York, NY, USA, 2008), MobiSys ’08, ACM,

pp. 40–53.

1220 25th USENIX Security Symposium USENIX Association

[14] GRUTESER, M., AND GRUNWALD, D. Enhancing location pri-

vacy in wireless lan through disposable interface identiﬁers: A

quantitative analysis. Mobile Networks and Applications 10,3

(2005), 315–325.

[15] H

ART, L. Telit Acquires Wireless Communications Assets to

Boost Capabilities in Low-Power Internet of Things Market).

http://www.businesswire.com/news/home/20160113005310/en/,

Jan. 2016. Accessed: 01-02-2016.

[16] H

EYDON, R. Bluetooth low energy: the developer’s handbook.

Prentice Hall, 2012.

[17] H

ILL, K. ’Baby Monitor Hack’ Could

Happen To 40,000 Other Foscam Users.

http://www.forbes.com/sites/kashmirhill/2013/08/27/baby-

monitor-hack-could-happen-to-40000-other-foscam-users, Aug.

2013. Accessed: 18-01-2016.

[18] J

IANG,T.,WANG, H. J., AND HU, Y.-C. Preserving location

privacy in wireless lans. In Proceedings of the 5th International

Conference on Mobile Systems, Applications and Services (New

York, NY, USA, 2007), MobiSys ’07, ACM, pp. 246–257.

[19] J

OHN PESCATORE. A SANS Analyst Survey: Securing the

“Internet of Things” Survey. https://www.sans.org/reading-

room/whitepapers/analyst/securing-internet-things-survey-

34785, Jan. 2014. Accessed: 18-01-2016.

[20] K

UCHINSKAS, S. Bluetooth’s smart future in telemat-

ics. http://analysis.tu-auto.com/infotainment/bluetooths-smart-

future-telematics, March 2013.

[21] L

EONARD, A. Wearable Honeypot. PhD thesis, Worcester Poly-

technic Institute, 2015.

[22] L

ESTER, S. The Emergence of Bluetooth Low Energy.

http://www.contextis.com/resources/blog/emergence-bluetooth-

low-energy/, May 2015.

[23] L

UTHRA, G. Embedded controllers for the Internet of Things.

http://www.edn.com/design/sensors/4440576/Embedded-

controllers-for-the-Internet-of-Things/, Oct 2015.

[24] M

ADAAN, P. IoT for the smarter home.

http://www.ecnmag.com/article/2015/05/iot-smarter-home,

May. 2015. Accessed: 11-01-2016.

[25] M

ARE, S., SORBER, J., SHIN, M., CORNELIUS, C., AND

KOTZ , D. Hide-n-sense: Preserving privacy efﬁciently in wire-

less mhealth. Mobile Networks and Applications 19, 3 (2014),

331–344.

[26] M

ARGARITELLI, S. Nike+ FuelBand SE BLE Protocol Re-

versed. http://www.evilsocket.net/2015/01/29/nike-fuelband-se-

ble-protocol-reversed/, Jan 2015.

[27] N

ANDUGUDI, A., MAITI, A., KI,T.,BULUT,F.,DEMIR-

BAS, M., KOSAR, T., QIAO, C., KO, S. Y., AND CHALLEN,

G. PhoneLab: A large programmable smartphone testbed. In

Proceedings of SENSEMINE ’13 (New York, NY, USA, 2013),

ACM, pp. 4:1–4:6.

[28] N

AVEED, M., ZHOU, X., DEMETRIOU, S., WANG, X., AND

GUNTER, C. A. Inside job: Understanding and mitigating the

threat of external device mis-bonding on android. In Proceed-

ings of the 21st Annual Network and Distributed System Security

Symposium (NDSS) (2014), pp. 23–26.

[29] OC

ONNOR, T., AND REEVES, D. Bluetooth network-based mis-

use detection. In Computer Security Applications Conference,

2008. ACSAC 2008. Annual (Dec 2008), pp. 377–391.

[30] P

ARK, H., BASARAN, C., PARK, T., AND SON, S. H. Energy-

efﬁcient privacy protection for smart home environments using

behavioral semantics. Sensors 14, 9 (2014), 16235.

[31] P

ETERSON, A. Yes, terrorists could have hacked Dick

Cheneys heart. https://www.washingtonpost.com/news/the-

switch/wp/2013/10/21/yes-terrorists-could-have-hacked-dick-

cheneys-heart/, Oct. 2013.

[32] R

OUF, I., MILLER, R., MUSTAFA, H., TAYLOR,T.,OH, S.,

U,W.,GRUTESER, M., TRAPPE, W. , AND SESKAR, I. Se-

curity and privacy vulnerabilities of in-car wireless networks: A

tire pressure monitoring system case study. In Proceedings of

the 19th USENIX Conference on Security (Berkeley, CA, USA,

2010), USENIX Security’10, USENIX Association, pp. 21–21.

[33] R

YA N , M. Bluetooth: With low energy comes low security. In

Proceedings of the 7th USENIX Conference on Offensive Tech-

nologies (Berkeley, CA, USA, 2013), WOOT’13, USENIX As-

sociation, pp. 4–4.

[34] S

CHNEIER, B. The internet of things is wildly insecure –

and often unpatchable. http://www.wired.com/2014/01/theres-

no-good-way-to-patch-the-internet-of-things-and-thats-a-huge-

problem, Jan. 2014. Accessed: 18-01-2016.

[35] S

CHURGOT, M., SHINBERG, D., AND GREENWALD, L. Ex-

periments with security and privacy in IoT networks. In World

of Wireless, Mobile and Multimedia Networks (WoWMoM), 2015

IEEE 16th International Symposium on a (June 2015), pp. 1–6.

[36] S

HEN,W.,NING,P.,HE, X., AND DAI, H. Ally friendly jam-

ming: How to jam your enemy and maintain your own wireless

connectivity at the same time. In Security and Privacy (SP), 2013

IEEE Symposium on (May 2013), pp. 174–188.

[37] S

RINIVASAN, V. , S TANKOVIC, J., AND WHITEHOUSE, K. Pro-

tecting your daily in-home activity information from a wireless

snooping attack. In Proceedings of the 10th International Con-

ference on Ubiquitous Computing (New York, NY, USA, 2008),

UbiComp ’08, ACM, pp. 202–211.

[38] T

IPPENHAUER, N., MALISA, L., RANGANATHAN, A., AND

CAPKUN, S. On limitations of friendly jamming for conﬁden-

tiality. In Security and Privacy (SP), 2013 IEEE Symposium on

(May 2013), pp. 160–173.

[39] TURK, V. The internet of things has a language prob-

lem. http://motherboard.vice.com/read/the-internet-of-things-

has-a-language-problem, Jul. 2014. Accessed: 03-02-2016.

[40] W

ANG, P. Bluetooth low energy-privacy enhancement for adver-

tisement.

[41] W

ANT, R., SCHILIT, B., AND JENSON, S. Enabling the internet

of things. Computer 48, 1 (Jan 2015), 28–35.

[42] Z

IEGELDORF, J. H., MORCHON, O. G., A ND WEHRLE, K. Pri-

vacy in the internet of things: threats andchallenges. Security and

Communication Networks 7, 12 (2014), 2728–2742.

A Analysis of Device Hiding

BLE-Guardian may jam the advertisements of non-

target devices which might disrupt their operation, which

we refer to as the second situation in Section 5.3.2. Nev-

ertheless, because of the random delay introduced by the

device before each advertisement, the aforementioned

“collision” events become unlikely. In what follows, we

show that the expected number of another device’s ad-

vertisements within the expected advertising interval of

the target BLE-equipped device will always be less than

1, when BLE-Guardian protects a single BLE-equipped

device.

USENIX Association 25th USENIX Security Symposium 1221

One could view the advertising process of a sin-

gle BLE-equipped device as a renewal process [5],

where each event corresponds to an advertising session.

The inter-arrival times, X

, are nothing but the inter-

advertising intervals deﬁned as i.i.d. random variables

such that X

∼ uni f (adv,adv + 10). The n

advertise-

ment time T

∑

i=1

has the distribution deﬁned by

the n-fold convolution of distribution of X

. As n in-

creases, the probability distribution of the n-th adver-

tisement spreads over a larger time interval deﬁned as

A =[n.adv, n.(adv + 10)].

The device hiding module attempts jamming at an in-

terval of width 10ms, as speciﬁed before. If this jam-

ming interval falls within the expected advertising in-

terval of some other device, A, then the second situa-

tion of Section 5.3.2 might occur. Nevertheless, as n in-

creases the length of interval A increases and thus the

expected number of advertisements, from a single de-

vice within 10ms should be less than 1. We show be-

low how the expected number of advertisements in a

10ms interval drops between n = 1 and n = 2. We con-

sider m(t), the expected number of events up to time

t, deﬁned as F

(t)+



m(t − x) f

(x)dx, where f

(s)

is the probability distribution of X

which is equal to

uni f (adv,adv + 10) and F

(t) is the cumulative distri-

bution function given as:

(t)=











0 t < adv

t−adv

adv ≤t ≤ adv + 10

1 t > adv.

(7)

During the ﬁrst advertising interval, t ∈ [adv,adv +

10], the expected number of advertisements is

t−adv



adv

m(t −x)dx after substituting F

(t) and f

(x) with

their corresponding expressions. After performing a sub-

stitution of variable of y = t −x, and since m(t)=0 for

t < adv, then m(t)=

t−adv

. So, if the expected advertis-

ing interval of the device hiding module overlaps with the

ﬁrst advertising interval of another advertising device,

the expected number of events, m(adv + 10) −m(adv),

will be 1, which is intuitive.

The second advertisement will take place at the in-

terval B =[2.adv, 2.(adv + 10)], and we use a simi-

lar procedure to derive the expressions for m(t) for t ∈

[2.adv, 2.adv + 10] and t ∈ [2.adv, 2.(adv + 10)]. If the

expected advertising interval of the device hiding mod-

ule overlaps with interval, B, then the expected number

of advertisements m(t + 10) −m(t) will drop to

. The

same trend will follow for the subsequent advertising in-

tervals; the expected number of another device’s adver-

tisements within the expected advertising of the target

BLE device will always be less than 1. Our evaluation in

Section 6. conﬁrms this observation.

Finally, even if another device, with the same adver-

tising parameters, starts advertising with the target BLE

device at the same time, their advertising events will

eventually diverge. After N advertisements from both

devices, the distribution of Ta

N+1

−Tb

N+1

, the differ-

ence in time between the N + 1 advertising instants of

both devices will be a random variable with mean 0 but

with σ = 2.N.

√

. As N increases, the standard devi-

ation increases, which in turn decreases the probability

of both advertising events taking place within 10ms. The

10ms-advertising interval is the length of interval that the

device hiding module expects the target BLE device to

advertise.