Proceedings on Privacy Enhancing Technologies ..; .. (..):1–17

Johannes K Becker*, David Li, and David Starobinski

Tracking Anonymized Bluetooth DevicesAbstract: Bluetooth Low Energy (BLE) devices usepublic (non-encrypted) advertising channels to an-nounce their presence to other devices. To prevent track-ing on these public channels, devices may use a peri-odically changing, randomized address instead of theirpermanent Media Access Control (MAC) address. Inthis work we show that many state-of-the-art deviceswhich are implementing such anonymization measuresare vulnerable to passive tracking that extends well be-yond their address randomization cycles. We show thatit is possible to extract identifying tokens from the pay-load of advertising messages for tracking purposes. Wepresent an address-carryover algorithm which exploitsthe asynchronous nature of payload and address changesto achieve tracking beyond the address randomization ofa device. We furthermore identify an identity-exposingattack via a device accessory that allows permanent,non-continuous tracking, as well as an iOS side-channelwhich allows insights into user activity. Finally, we pro-vide countermeasures against the presented algorithmand other privacy flaws in BLE advertising.

Keywords: Bluetooth, tracking, privacy, informationleakage, side-channels, correlation attacks, traffic anal-ysis.

DOI Editor to enter DOIReceived ..; revised ..; accepted ...

1 IntroductionBluetooth technology has facilitated the ubiquity ofinstant wireless connectivity, ranging from personalconnected accessories, to smart homes, and localizedand personalized, location-based shopping experiences.Since it was first adopted in mobile phones in the year2000 [1], it has undergone five major Core Specificationrevisions with numerous amendments [2].

In early versions of the Bluetooth specification, thepermanent Bluetooth MAC addresses of devices were

*Corresponding Author: Johannes K Becker: BostonUniversity, E-mail: jkbecker@bu.eduDavid Li: Boston University, E-mail: dlhi@bu.eduDavid Starobinski: Boston University, E-mail: staro@bu.edu

regularly broadcasted in the clear, leading to major pri-vacy concerns over the possibility of unwanted track-ing [3]. This was addressed in the Bluetooth Core Spec-ification 4.0 with the introduction of the Bluetooth LowEnergy (BLE) standard also known as Bluetooth Smart.BLE allows device manufacturers to use temporary ran-dom addresses in over-the-air communication instead oftheir permanent address to prevent tracking [4]. How-ever, these anonymization features are defined in a waythat leaves a certain degree of flexibility to manufactur-ers. The optionality of such privacy protecting featuresis of special relevance, as the BLE standard was de-signed specifically to support low-energy devices such assmart watches and other wearable devices, which are anattractive target for adversarial tracking of their users.

BLE devices broadcast so-called advertisements onunencrypted, public channels in order to signal theirpresence to other devices. Ideally, this public broadcastcontains all the required information to perform a de-vice function, while not leaking unnecessary private in-formation about the device or its user. In some cases,however, devices may broadcast data that exposes sen-sitive details about themselves or even other devices.

In this work, we show how even state-of-the-artdevices such as Windows 10 computers and iPhones,which do implement privacy protecting measures suchas address randomization may be vulnerable to contin-uous tracking. We first examine various types of ad-vertising messages and identify so-called identifying to-kens, which are unique to a device and remain static forlong enough to be used as secondary identifiers besidesthe address. We present an online algorithm called theaddress-carryover algorithm, which exploits the factthat identifying tokens and the random address do notchange in sync, to continuously track a device despiteimplementing anonymization measures. To our knowl-edge, this approach affects all Windows 10, iOS, andmacOS devices. The algorithm does not require mes-sage decryption or breaking Bluetooth security in anyway, as it is based entirely on public, unencrypted ad-vertising traffic.

The Bluetooth 5 Specification extends usable com-munication range to whole buildings or hundreds of me-ters in line-of-sight transmissions [5, 6]. While the track-ing attack proposed in this paper considers tracking bya single adversary in such an operating radius, previous

Tracking Anonymized Bluetooth Devices 2

work [7] suggests that local BLE tracking methods maybe significantly compounded by coordinating them ina botnet of adversaries, resulting in potentially globaltracking capabilities.

The main contributions of this paper are as follows:

1. We describe a tracking vulnerability that affectsWindows 10, iOS, and macOS devices as long asthey are continuously observed by the adversary.

2. We develop a methodology that can be applied todevices from various manufacturers, based on rawBLE advertising log files.

3. We present an algorithm that allows tracking be-yond the address randomization of a device, andmeasure the resulting maximum tracking time(MTT).

4. We identify other privacy vulnerabilities that existon certain device types, which expose device identi-fiers permanently via a peripheral, and which leakactivity information on iOS devices.

5. We provide recommendations and potential coun-termeasures to the tracking vulnerabilities uncov-ered in this work.

The rest of this paper is structured as follows: Sec-tion 2 discusses prior related work. Section 3 presentsbackground information on the Bluetooth protocol nec-essary to understand this work. In Section 4, we de-scribe our adversarial model and the methodology usedin this work, followed by the experimental setup in Sec-tion 5. We present our results in Section 6, followed byrecommendations for the avoidance of unwanted devicetracking in Section 7. We summarize our findings andgive an outlook on further research in Section 8.

2 Related WorkPrivacy and security concerns over Bluetooth date backto its very first release [8]. Anonymizing devices in pub-lic channel communication only became available withthe introduction of BLE in Bluetooth 4.0 [9]. A lot of re-search regarding the effectiveness of MAC address ran-domization is focused on Wi-Fi, where the same privacyconcern of broadcasting permanent identifiers exists,but vulnerabilities are often not easily transferable tothe Bluetooth case as they are based on different areasspecific to the Wi-Fi network stack. We will highlightsome important works relating to more general cases of

Bluetooth and Wi-Fi tracking concerns, as well as moreBLE-specific techniques and utilities.

In 2007, Spill and Bittau [3] presented several tech-niques for eavesdropping on Bluetooth 2.0 commu-nication using a GNU Radio-based Bluetooth snifferand USRP software-defined radio hardware. Their workdescribes an approach for intercepting packets, andreverse-engineering all the parameters required to eaves-drop on Bluetooth communication [3]. However, thesefindings only concern the Bluetooth Classic implemen-tation, which is of decreasing relevance in light of BLEand Bluetooth 5.

In 2015, Jameel and Dungen presented an open-source library for scanning Bluetooth Low Energy (LE)and Active RFID advertising [10]. Their work sum-marizes different available Beacon protocols, which areproximity-based broadcast protocols [11, 12] and enableall kinds of localized interactions with smartphones andother Bluetooth devices via the BLE advertising chan-nels. Furthermore, the authors published a library calledadvlib [13], which processes raw BLE advertising mes-sages and decodes them into an open, portable dataformat. This library enables software developers to eas-ily integrate BLE advertising-based functionality intotheir software, without having to manually decode low-level protocols. The library further powers the open-source “collaborative repository” Sniffypedia [14], whichpresents a large number of publicly known BLE adver-tising identifiers in a searchable and accessible format.This platform can help classify Bluetooth device classesfor reconnaissance purposes, but does not offer devicetracking capabilities.

Vanhoef et al. [15] present techniques to gain ac-cess to permanent MAC addresses by exploiting proberequests in Wi-Fi. They develop an algorithm whichrelies on timing features and sequence numbers foundin Wi-Fi probe requests to identify devices regardlessof their MAC address. They further describe a variantof the Karma Attack – exploiting the fact that manydevices will expose information to supposedly knownand trusted networks [16] by creating a catch-all accesspoint [17] – which creates large numbers of popular Wi-Fi networks in order to invite devices to connect, oftenpresenting their permanent MAC address in a suppos-edly trusted context.

Issoufaly and Tournoux [7] show that despite the ex-istence of privacy-preserving MAC address randomiza-tion in Bluetooth 4.0 LE, not all devices make use of thisfunctionality and are therefore vulnerable to tracking.Furthermore, they showed how maliciously distributingsuitable tracking software to a number of mobile de-

Tracking Anonymized Bluetooth Devices 3

vices – a “BLE Botnet” – extends tracking capabilitiesfar beyond the local transmission range of regular Blue-tooth communication. Combining BLE privacy with thenotion of a potentially global botnet motivates our workas it extends the privacy threat from local presence de-tection to large-scale location tracking, which would berealistic to implement for nation-state actors. While Is-soufaly and Tournoux focus on tracking devices that usestatic device addresses, our work focuses on tracking de-vices that use dynamically randomized addresses. Theseaddresses change depending on regeneration parametersset by their manufacturers.

Along the same line, Martin et al. [18] show thatMAC address randomization is often defeated by not be-ing implemented properly or consistently, partly build-ing upon previous approaches [15]. Furthermore, theyshow flaws in the address randomization of Androidphones, which allow the deduction of device types viaaddress prefixes, as well as their global MAC addressvia information found in broadcasted WPS attributes.They also identify a control frame attack that exposesthe permanent Wi-Fi MAC address of a device with100% success rate [18, p. 280]. Our approach differs inthat we do not retrieve information through reversalof hashes or other reverse-engineering methods, and weuse entirely passive sniffing to generate insights whichallow device tracking. Our tracking method, based onextracting identifying tokens in the payload of advertis-ing messages, leverages specific Bluetooth features anddiffers from this previous line of work.

3 BackgroundBluetooth is a wireless communication protocol on the2.4 GHz ISM band. Our focus lies on the Low En-ergy specification, which was introduced in 2010 withBluetooth 4.0 [9]. Bluetooth LE (BLE) is optimizedfor small, often battery-powered devices with relativelystrict energy restrictions, like connected wearables, wire-less smart sensors, or computer accessories like digitalpencils. The Bluetooth 5 Specification adds various fea-ture and performance improvements, notably a largercommunication range [5], which allows for up to 780 me-ters of line-of-sight connectivity [6].

We focus on introducing the elements that are es-sential for the experiments described in the followingSections. We refer to Heydon [19, p. 7] for a generalhigh-level introduction to the Bluetooth 5 architectureand the Bluetooth 5 Core Specification for details [20].

Scanning

StandbyAdvertising Initiating

ConnectionMaste

rSlave

Fig. 1. The Link Layer State machine [19, p. 15].

3.1 Physical Layer and Link Layer

BLE operates on 40 physical channels spaced in 2 MHzsteps from 2402 MHz to 2480 MHz [20, p. 2535f.]. Threeof these channels are so-called advertising channels at2402 MHz, 2426 MHz, and 2480 MHz – frequencies withminimal interference with other 2.4 GHz band traffic(notably Wi-Fi) [10]. These channels are used to broad-cast advertising messages, which may be simple pe-riodic, presence announcements, scanning requests to-wards other devices, beacons containing location-basedmetadata, and other public broadcast-type informa-tion. The remaining channels are used primarily fordata transmissions between paired devices and employ apseudo-random channel hopping scheme, which is nego-tiated between the two connected parties upon connec-tion to avoid interference with other ISM band traffic.

On the link layer, Bluetooth defines different states,shown in Figure 1. In the Advertising state, the linklayer creates Advertising Events which are broadcastedon all advertising channels. These events contain differ-ent types of Payload Data Units (PDU)1. In our work,the following PDU types are relevant:

– the Connectable Directed Event using theADV_DIRECT_IND PDU, which invites a specificallyaddressed device to initiate a connection.

– the Connectable and Scannable Undirected Eventusing the ADV_IND PDU, which allows any deviceto respond with scanning requests or connection re-quests.

In the Scanning state, the link layer receives adver-tising messages without responding (passive scanning)or responds with scan requests to inquire about further

1 The full list of advertising event types and corresponding PDUtypes can be found in [20, p. 2609, Table 4.1].

Tracking Anonymized Bluetooth Devices 4

a)

Pream

ble(1

byte)

0

AccessAdd

ress

(4by

te)

8

PDU

Heade

r(2

byte)

40

PDU Payload(1-255 byte)

56

CRC(3 byte)

bit address

b)PDU Type

(4 bit)

0

RFU

(1bit)

4

ChS

el(1

bit)

5

TxAdd

(1bit)

6

RxA

dd(1

bit)

7

Length(8 bit)

8 bit address

Fig. 2. The BLE advertising packet format (Fig. 2.a)) and theAdvertising Channel PDU Header (Fig. 2.b)) [20, p. 2562, 2567].

device details (active scanning) [20, p. 2633]. In the Ini-tiating state, the link layer listens for advertising mes-sages, and sends Connect Requests to advertising de-vices. If the requested device responds, the devices canenter a Connection state [20, p. 2637].

In the Connection State, devices implementing theso-called Central role can connect to up to 8 Periph-eral role devices as their Master, while Peripheral de-vices can connect to one Central role device as a Slave.Smartphones or PCs are typical Central role devicesconnecting to multiple wireless input devices, activitytrackers or other wireless sensors. However, devices mayimplement both roles and may therefore send advertis-ing messages (Peripheral role) while scanning for adver-tising messages (Central role)2. In our work, we observedevices which are in the Advertising state using an ob-server device which is in the Passive Scanning state.

3.2 Advertising Packet Format

We next provide details on the structure and contentsof advertising packets, since those will be exploited totrack and distinguish between different devices. Adver-tising packets follow a structure shown in Figure 2.a),consisting of a preamble, an Access Address (AA)3, aPayload Data Unit (PDU) and a CRC field. The ad-

2 I.e., a BLE device can be in more than one state shown inFigure 1 at the same time.3 The access address is always 0x8E89BED6 for advertising pay-loads [20, p. 2563].

AdvA(6 bytes)

0

TargetA(6 bytes)

48 bit address

Fig. 3. The PDU Payload format for the ADV_DIRECT_IND PDUType contains an Advertising Address (AdvA) and a Target Ad-dress (TargetA). [20, p. 2570.].

a)AdvA(6 byte)

0

AdvData(0-31 byte)

48 bit address

b)AD Structure 1

(≥ 3 byte)

0

AD Structure 2(≥ 3 byte)

32

. . .AD Structure n

(≥ 3 byte)

bit address

c)Le

ngth

(1by

te)

0

AD

Typ

e(n

byte)

8

AD Data(Length− n byte)

16 bit address

Fig. 4. PDU Payload format for ADV_IND and ADV_NONCONN_INDPDU Types (Fig. 4.a)), the AdvData format (Fig. 4.b)), and theAD Structure format (Fig. 4.c)) [20, p. 2086, 2569ff.] [21].

vertising channel PDU itself consists of a header anda payload depending on the PDU Type defined in theheader [20, p. 2567] (see Figure 2.b)).

The PDU Payload of a directed advertising eventcontains an Advertising Address (AdvA) and a TargetAddress (TargetA), as shown in Figure 3. Only deviceswith the matching Target Address can initiate a con-nection by sending a Connect Request.

Indirected advertising allows any device receivingthe PDU to respond with a Scan Request (requestinginformation about available features) or a Connect Re-quest. The PDU Payload for this type of advertising isformatted as shown in Figure 4, containing an Advertis-ing Address (AdvA) and Advertising Data (AdvData),which may contain one or more AD Structures (see Fig-ures 4.b). Finally, AD Types define the content of theAD Data contained in each AD Structure (Figure 4.c).

An overview of some AD Types that we will uselater in this paper is shown in Table 1, we refer to [21]for the full list.

Most AD Types define simple numbers or strings.TheManufacturer Specific Data type is worth highlight-ing, as it gives device manufacturers the flexibility to

Tracking Anonymized Bluetooth Devices 5

Length(1 byte)

0

0xFF(1 byte)

8Manufacturer

ID(2 byte)

16

Manufacturer Data(Length− 3 byte)

32 bit address

Fig. 5. The Manufacturer Specific Data AD Structure format[22, 23].

AD Type Name Description0x01 Flags BLE capability flags0x06 List of 128-bit Service

Class UUIDsglobally unique identifierfor a certain device service

0x09 Complete Local Name Device “friendly name”0x16 Service Data Service UUID as per [24]0xFF Manufacturer Specific

Datacustom data structure con-tainer (see Figure 5)

Table 1. An overview of some relevant AD Types [21] [20, Vol. 3,Part C, Sections 8.1, 11.1, and 18] [22, Part A, Section 1].

define further data structures within the AD Data field.Figure 5 shows a Manufacturer Specific Data AD Struc-ture. This AD Type allows manufacturers to developtheir own advertising-based protocols that live withinthis data4, which may contain data that our proposedalgorithm exploits.

3.3 Advertising Addresses

The Bluetooth architecture generally refers to devicesthat transmit advertising packets as advertisers. Deviceslistening to advertising packets are referred to as scan-ners if they listen without intention of connecting, andas initiators if they intend to make Connect Requestsin response to suitable advertising events [20, p. 170].

The Advertising Address shown in Figures 3 and 4 isthe 48-bit MAC address of the advertiser transmittingthe advertising packet. This address may be a publicor random address depending on the TxAdd flag in thePDU Header (see Fig. 2).

A public address (TxAdd = 0) is the standard IEEE-assigned 48-bit MAC address obtained from the IEEERegistration Authority, in which the 24 least significantbits are manufacturer-assigned, while the 24 most signif-icant bits represent the IEEE-assigned company ID [26].These addresses are permanently attached to the de-

4 Widely adopted manufacturer-specific data protocols are theApple iBeacon protocol [11] or other open protocols like Google’sEddystone [12] and Radius Networks’ AltBeacon [25].

vice hardware, making them a vulnerability to long termtracking if used in public communication.

Random addresses (TxAdd = 1) may be static, inwhich case they are randomly generated whenever thedevice reboots or remain with the device permanently,which makes them vulnerable to long-term tracking.Random private addresses prevent address-based track-ing by regenerating periodically, essentially anonymiz-ing the device identity [4]. Such random private ad-dresses may either be an unresolvable address made ofa random number, or they may be resolvable to a per-manent address by trusted devices holding an IdentityResolving Key (IRK). This can be used to send directedadvertising to a specific device without broadcasting itspermanent address in the clear and is further discussedin Section 7 containing our Recommendations. Resolv-able and unresolvable random addresses can be distin-guished by their two most significant bits being set to0b01 and 0b00, respectively [20, p. 2558].

4 Methodology

4.1 Adversarial Model

This paper aims to uncover potential security and pri-vacy flaws in BLE devices, as they appear “in the wild”.We consider a local adversary5 in the scanning linklayer state (see Section 3.1). As such, it is a passive,external adversary which reads continuously, but neveradds, removes, or modifies ongoing BLE adversary traf-fic. Specifically, the adversary never sends scan requestsor connect requests, and remains entirely passive dur-ing the attack, i.e., there is no bi-directional interactionwith the target device. We assume that the adversaryis capable of monitoring the ongoing advertising trafficin order to be aware of changes in advertising messagesas they occur over time.

We do not make any assumptions about the victimdevices, other than Bluetooth being turned on. Notethat devices may implement the Peripheral and Centralroles at the same time, and thus remain in advertis-ing state for the Peripheral role despite ongoing connec-tions as a Master device. Thus, the ability of trackingsmartphones or computers via passive tracking mainlydepends on whether they implement the Peripheral role.

5 Emphasized terms in this Section in line with the definitionsof privacy metrics given in [27, Section 4].

Tracking Anonymized Bluetooth Devices 6

The adversary only needs to observe Bluetooth ad-vertising messages (which are sent in plain text), i.e.,the adversary does not require the capability to read en-crypted data transmissions or follow channel hopping.The adversary implements a sniffing device (in our case,a Software-Defined Radio (SDR)) which listens to oneof the Bluetooth advertising channels (i.e., channels 37,38, or 396). The packets are then broken down into theirelements as defined in the Bluetooth specification (seealso Figure 2) and further analyzed for any observabledata which could be used to compromise user privacy.

As advertising messages are sent in the clear and arenot authenticated, proving authenticity and integrity ofan advertising message is not easy in most cases. Assuch, the methodology used in this paper considers be-nign communication by devices which are oblivious topotential privacy issues in their advertising patterns,i.e., they neither forge the contents of their messagesnor change the traffic patterns for their messages in or-der to obfuscate their identity.

This work assumes that an adversary will at somepoint make a connection between an arbitrary identifierin an advertising event and its real-world associated de-vice, and will then continuously observe ongoing BLEadvertising traffic in order to track it without the user’sconsent for the longest time period possible. Adversarysuccess is defined as the adversary being able to hold onto a device identity beyond its address randomizationusing local, passive, continuous observation.

In this paper, we use the terms user and device syn-onymously. We assume that devices are being trackedwith the intent of tracking their users, and the abilityto track a device implies the ability to track its user.We therefore do not consider devices that are sharedbetween multiple users and would require such a logicaldistinction.

4.2 Privacy Metrics

The applied metrics focus on the adversary’s ability totrack a device over time due to some observable signa-ture. Specifically, let the anonymity set size ASu rep-resent the set of users that an adversary cannot distin-

6 It is assumed that any of the available advertising channelscan be considered equivalent as advertising events are usuallybroadcast to all three channels in a round-robin fashion.

guish from a targeted user u [27, p. 57:9] [28, p. 5], i.e.:

|ASu| = number of users indistinguishablefrom user u. (1)

The primary metric of interest in this paper is theMaximum Tracking Time (MTT ), which is defined asthe cumulative time that a user u can be uniquely iden-tified [27, p. 57:30] [28, p. 5], that is:

MTTu = time during which |ASu| = 1for a user u. (2)

We show that several types of devices have un-bounded MTT .

4.3 Device Tracking Algorithm

We propose a two-phase algorithm which allows track-ing of devices beyond their address randomization. Thealgorithm consists of an offline pre-processing phase andan online tracking phase.

4.3.1 Phase 1: Pre-Processing

The pre-processing phase uses recorded log files con-taining decoded BLE advertising packets (see Figure 2)and their PDU Payloads in raw format. All collected logfiles are processed offline in order to identify potentialidentifying tokens occurring in advertising messages. Anidentifying token can be any sequence of bits containedin an advertising message which allows distinguishingone device from another – be it by design (such as theadvertising address) or by a side effect. As a generalrule, an identifying token for a given device should re-main fixed over a certain period of time, while beingunique to one device (i.e., its values should not collidewith values produced by other devices within range overtime).

The set of useful identifying tokens for a class of de-vices depends on its operating system and other device-specific hardware or software features, as all of thesefactors determine the structure and content of advertis-ing messages.

In this sense, a universal MAC address [26, p. 22f.]is a perfect identifying token as it is guaranteed to beunique to a device, and is permanently linked to a de-vice. In a local context, these requirements can be re-laxed as long as the distinction between the devices inrange is still possible with high confidence.

Tracking Anonymized Bluetooth Devices 7

Identifying tokens may be found either by look-ing at the raw PDU Payload and isolating a byte se-quence which fulfills the requirements laid out above,or by breaking down the PDU Payload according to theBluetooth protocol specification and identifying suitablemetadata elements.

In order to avoid collisions between identifying to-kens, it is important that the bit length n of the identi-fying token be large enough. Formally, suppose an ad-versary aims to track a Bluetooth device over a certainperiod, say a week, in an area containing at most m

other Bluetooth devices with the same types of identify-ing tokens (devices with different identifying tokens aretrivial to distinguish). Furthermore, suppose that eachdevice changes its identifying token at a rate no fasterthan once every 15 minutes (based on our experimentaldata, 15 minutes appears to be an upper bound on thefrequency of changes of identifying tokens). This meansthat the targeted device will generate at most k = 672tokens in a week.

Assume that each identifying token is generateduniformly at random (a reasonable assumption basedon our experimental data). The probability that an-other Bluetooth device produces tokens that do not con-flict with one of these k tokens is at least (1 − k/2n)k.Hence, the probability that all the other m devices pro-duce different tokens than the targeted device is atleast (1 − k/2n)mk ≥ 1 − mk2/2n, where the latterinequality is obtained by applying Bernoulli’s inequal-ity [29]. Therefore, by choosing 1 −mk2/2n ≥ 1 − p orn ≥ dlog2(mk2/p)e, we can ensure a collision probabil-ity smaller than p. As an example, for m = 1000 devicesand p = 10−3, we obtain n ≥ 39 bits. Consequently,identifying tokens that have a length of at least 40 bits(i.e., 5 bytes), satisfy this inequality.

Note that performing pre-processing is only re-quired once per device class. Once a suitable set of iden-tifying tokens has been found for a class of devices, itcan be applied to track any individual device in thisclass.

4.3.2 Phase 2: Tracking

The address-carryover algorithm (Algorithm 1) isan online algorithm that continuously observes changesin the address as well as any other relevant identifyingtokens found in the pre-processing phase.

The algorithm listens to incoming advertising mes-sages mi as they are broadcast on one of the BLE adver-tising channels with the goal of tracking a target device

D beyond the point where it randomizes its advertisingaddress.

If the incoming message contains the right identify-ing tokens for the class of devices that D belongs to, thetokens are extracted (line 4). Then, if the incoming ad-vertising address is identical to the existing advertisingaddress (addr), we still know the device identity andwe update the stored values of the identifying tokensif any changes are detected (line 7). Otherwise, if theadvertising address has changed, a match is attemptedusing any of the available identifying tokens as a pseudo-identity – in case of a successful match, the address ofdevice D can be updated with the incoming address andaddress-carryover was successful (line 11). In either ofthese cases, the timeout counter is reset to indicate thatthe device D is being tracked successfully. If neither ad-dress nor identifying token matches succeed for a certainperiod of time Tmax, it is assumed that device trackinghas failed and the algorithm terminates.

The algorithm requires an amount of memory andcomputation that are linear in the size of the set ofidentifying tokens. Since there is only a handful of iden-tifying tokens, the algorithm can be run in real-timewithout limitation.

5 Experimental SetupThe experimental setup used in this work consists ofmonitoring one of the BLE advertising channels for acertain amount of time and analyzing the content ofadvertising events that are broadcast by devices withintypical Bluetooth proximity.

We use a modified version of Xianjun Jiao’s SDR-based BLE sniffer [30] for all experiments. The col-lected log files contain advertising messages accordingto Figure 2, with all metadata decoded and the PDUpayload in raw hexadecimal ASCII characters. In thepre-processing phase, we decode them according to thestructure shown in Figures 2, 4, and 5, where applica-ble. The system used for all experiments is based on aUbuntu Xenial-based PC and the HackRF One SDR.

We chose to use an SDR-based Bluetooth snifferover a sniffer based on the regular Bluetooth stack toremain independent of variations in Bluetooth imple-mentations on different hardware and OSes, to be ableto observe raw data which is typically discarded by thelow-level network stack, and in order to facilitate futureconsideration of physical layer metrics in our research.

Tracking Anonymized Bluetooth Devices 8

Algorithm 1: Address-carryover algorithmInput : stream of advertising messages m1, m2, . . .

Variable : addr is an advertising address for device D

Variable : A is a list of identifying tokens [a1, a2, ...] for device D

Variable : Tmax is the maximum time tracking will be attemptedVariable : timeout is a time counterInitialize: addr to the current random address of the target device D, A to the currently broadcast values

of A for device D. Set timeout to zero and begin counting.1 while timeout < Tmax do2 receive message mi;3 if message mi contains at least one identifying token then4 extract incoming addr all contained identifying tokens from message mi;5 if incoming addr = existing addr then6 if any incoming token values differ from existing token values in A then7 update A to reflect new values of tokens;8 reset timeout ; // D is known (address unchanged)9 else unknown address:

10 if the value of any identifying token in mi matches the corresponding value in A then11 addr := incoming address;12 update A to reflect new values of tokens;13 reset timeout; // D is known (address carried over)

Result: Successfully tracked device D, new address is <addr>.14 end

/* timeout exceeds T_max: D is lost */

However, advanced knowledge of SDR is not requiredfor this paper.

Once we ensure that Bluetooth is enabled, the de-vice is allowed to go to lock screen or be casually used,i.e., we do not require the Bluetooth settings to remainopen during the attack. The sniffer passively listens toBluetooth advertisements and does not actively engagein communication. We perform four weeks worth of 1-2 hour long daily recordings and additional 15 longerrecordings ranging from 5 hours to multiple days.

We consider two types of advertising messages:

OS Advertising, i.e., regular BLE advertising activ-ity for each considered OS (Section 5.1).

Accessory Activation, i.e., traffic originating fromtypical BLE-based accessories (Section 5.2).

Note that the sniffer also records advertising mes-sages of other (non-tracked) devices in proximity, whichare ignored.

5.1 OS Advertising

This scenario describes BLE advertising events whichare periodically transmitted by an operating systemwhen a device is in a Bluetooth-enabled state, with-out being triggered by a particular user action. In thisscenario, the observer passively listens to a Bluetooth-enabled device while it is active for a certain amount oftime. During our daily recordings over the period of fourweeks, we identify whether advertising messages containlong-term static components.

We examine the following types of devices – all ofwhich are owned and operated by the authors:

Windows 10 devices. We passively record advertis-ing events, while the Bluetooth in Windows 10 is en-abled. We measure data generated by one MicrosoftSurface Pro 5, two laptops and one desktop PC fromother OEMs, all running an up-to-date Windows 10.

macOS and iOS devices. We passively record ad-vertising events, while Bluetooth in macOS / iOSis enabled. Additionally, the Airdrop sharing fea-ture is launched on the respective devices, and theresulting advertising events are recorded. We mea-sure data generated by various up-to-date iPhones

Tracking Anonymized Bluetooth Devices 9

(iPhone 5s, iPhone 8, iPhone X, running iOS 11),two iPads (iPad, iPad Pro running iOS 12), andtwo Macs (iMac A1419 and Macbook Pro A1502running macOS 10.13).

Android devices. We passively record advertisingevents, while Bluetooth in Android is enabled. Wemeasure data generated by two different Androiddevices (Samsung Galaxy S5, Google Nexus 4).

Smartwatches. We connect each smartwatch to itsrespective app on a smartphone and then deacti-vate Bluetooth on the smartphone. This triggersthe smartwatch to advertise its presence. We sampledata from two Fitbit Charge 2 smartwatches inter-mittently over the course of multiple months. Ad-ditionally, one of the smartwatches is subjected toboth a restart and a factory reset to find out if theseactions affect its behavior.

5.2 Accessory Activation

This scenario describes advertising events triggered bythe use of BLE-based accessories. Our work considerstwo types of touch-sensitive BLE-enabled pencils.

Microsoft Surface Pen. The Microsoft Surface Protablet can be used with a Microsoft Surface Pen.This digital pen is connected to the device via BLEin order to transmit pressure sensitivity data andfurthermore transmit signals from its two buttons.Our experiment consists of disconnecting and re-connecting the pen in order to clarify whether theSurface Pro, or the pen use a static address or oth-erwise leaks privacy-relevant information. Further-more, we examine the effect of button actuation forthe same goal.

iPad Pro Pen. The iPad Pro can be used with theApple Pencil pen. This pen is connected to the iPadvia BLE in order to transmit pressure sensitivitydata. Our experiment consists of disconnecting andreconnecting the pen in order to find out whetherthe iPad Pro, or the pen leak any privacy-relevantinformation.

OS Prevalent Type Prevalent ContentWindows 10 ADV_NONCONN_IND Company Identifier 0x0006macOS, iOS ADV_IND Company Identifier 0x004cAndroid SCAN_REQ Target AddressFitbit ADV_IND Fitbit Service Class UUID

Surface Pen ADV_DIRECT_IND Target Address

Table 2. Typical advertising features per operating system.

6 Results

6.1 Pre-Processing

In the pre-processing phase, we seek to identify suitableidentifying tokens which may be used to track devicesbeyond their address randomization.

Operating system vendors implement widely differ-ing strategies when it comes to implementing Bluetoothadvertisements, driven by overall system architectureand ecosystem considerations. Therefore, different op-erating systems behave in different ways in order to an-nounce their presence to nearby devices, and the OSorigin is typically easily distinguishable by some high-level features in the broadcasted advertising messages.

Identifying the major OS vendors and device typesis fairly straightforward, as Apple and Microsoft de-vices advertise using manufacturer-specific data, whichis always prepended by an officially assigned Com-pany ID [23]. In other cases where this approach isnot used, the vendor can typically be found out by in-specting other specific characteristics like Service ClassUUIDs [22, pp. 10, 12f., 18] or Service UUIDs [24].

The advertising message features shown in Table 2allow for such a high-level classification of messagesbased on the considered devices.

6.1.1 Windows 10 devices

Windows 10 devices typically advertise a PDU Payloadwith only a single AD Structure of type ManufacturerSpecific Data, as shown in Figure 6.

After recording for an extended period of time, wefind the advertising address to regenerate approximatelyevery 960 seconds, i.e., giving an adversary an averagetracking time of approximately 16 minutes based on theaddress until the device is lost. This shows that Win-dows 10 implements random private addresses (see Sec-tion 3.3).

The Manufacturer Specific Data contained in thepayload starts with the Company Identifier for Mi-

Tracking Anonymized Bluetooth Devices 10

AdvA: <48bit random address>AdvData: 1 AD Structure:

0xFF → Manufacturer Specific Data:Company Identifier: 0x0006 → “Microsoft”Data: <27 bytes of data>

Fig. 6. A a typical Windows 10 advertisement PDU Payload,containing a single "Manufacturer Specific Data" AD Structure(see Figure 5).

crosoft [23] 0x0006 and 27 bytes of proprietary data(see Figure 6), comprised of four fixed bytes followedby 23 variable bytes7. The first fixed bytes do not dif-fer between computers, i.e., they are not suitable to beused as identifying tokens. The 23 variable bytes, how-ever, appear uniformly random and, in fact, seem to beunique per device.

Furthermore, the payload is observed to remainstatic for approximately one hour. We observed nodifferences in advertising behavior between the ob-served devices that would indicate manufacturer-specific, rather than OS-specific behavior. We thereforeretain the following identifying token for Windows 10devices:

AW in10 = [Manufacturer Specific Data[-23:]]. (3)

6.1.2 Apple (macOS and iOS) Computers andSmartphones

MacOS and iOS devices regularly advertise their pres-ence as well. The advertising rates in macOS and iOSare much higher than in Windows 10, at up to two ad-vertising events per second. Address lifetimes are highlyvariable, ranging from seconds up to around two hoursin rare edge cases, with an average of around 20 minutes.

The typical message format contains, similar tothe Windows 10 payload, a manufacturer-specific datafield. However, Apple devices can be further distin-guished by advertising an additional flags data struc-ture which Windows 10 does not use (see Figure 7). Themanufacturer-specific data may contain one or more ofApple-specific data types, which are used for specificfunctionality in iOS and macOS which is facilitated byBLE. Table 3 shows an overview of the encountered data

7 Example payload:01092002︸ ︷︷ ︸fixed bytes

d70d650aac181b8397b8588f3a62de55810d23db56f176︸ ︷︷ ︸variable bytes

.

AdvA: <48bit random address>AdvData: 2 AD Structures:

0x01 → Flags: 0x1a0xFF → Manufacturer Specific Data:

Company Identifier: 0x004c → “Apple”Data: (nearby or handoff or both)

nearby (0x10) <5 bytes of data>handoff (0x0c) <14 bytes of data>

Fig. 7. A a typical Apple device advertisement PDU Payload,containing a single "Manufacturer Specific Data" AD Structure(see Figure 5).

Description iBeacon AirDrop Airpods Airplay Handoff NearbySource

Type 0x02 0x05 0x07 0x0a 0x0c 0x10Occurrence 4,762 4,649 2,151 13,846 79,001 87,598

Table 3. Occurrences of the most common data types observed iniOS/macOS advertising messages.

types. Of the data types observed, the nearby and hand-off types are by far the most frequent.

The handoff data structure consists of 14 bytes ofdata, in which the first bytes seems to be always zeroand the remaining bytes may take arbitrary values. Thisdata structure changes its value based on multiple fac-tors, some of which we identify in Section 6.3.2. Noneof the observed values showed collisions between devicesand the data has a sufficient length, making this a goodcandidate for an identifying token.

The nearby data structure consists of 5 bytes ofdata. Within these 5 bytes, the first two bytes do notseem to be fully random, reducing our useful length be-low the threshold set in Section 4.3.1, i.e., the number ofbits is smaller than what we would want to avoid iden-tity collisions. In practice, we have not observed valuescolliding, and have successfully been using nearby datain our experiments as a second token to the handoffdata. We conclude that while it is of practical useful-ness to our algorithm, it should not be relied on as asingle identifying token.

Clearly, types of data which rarely appear in adver-tising messages are not suitable identifying tokens. Wetherefore consider the nearby and handoff data struc-tures as the best candidates, since they appear an orderof magnitude more often than any other data type (seeTable 3).

An additional data type worth mentioning is theAirdrop data type. Airdrop allows users to share fileswith a nearby friend using an Apple-specific combina-

Tracking Anonymized Bluetooth Devices 11

AdvA: <48bit random address>AdvData: 3 AD Structures:

0x01 → Flags: 0x060x06 → Incompl.List of 128-bit Service Class UUIDs:

adabfb006e7d4601bda2bffaa68956ba0x16 → Service Data:

uuid: 0x180a → “Device Information”data: <5 bytes of data>

Fig. 8. A typical Fitbit PDU Payload (relevant AD Types aredefined in [22, p. 10,p. 12f.,p. 18]).

tion of Wi-Fi and Bluetooth for peer-to-peer file trans-fer. Airdrop produces a significant amount of advertis-ing events, which are triggered whenever a user taps orclicks a native share button in the respective OS. Inter-estingly, Airdrop uses a separate randomized advertis-ing address for this purpose, which cannot be associatedwith the regular address used for other advertising –making it unsuitable as an identifying token.

Overall, we observed no differences in advertisingbehavior between the observed iOS or macOS devicesthat would indicate noteworthy behavioral differencesbetween iOS 11, 12, or macOS 10.13. We therefore retainthe identifying tokens

AApple = AiOS = AmacOS = [nearby, handoff].(4)

6.1.3 Android smartphones

We observed Android advertising addresses to change inintervals of about 15-45 minutes. However, the observedAndroid smartphones use a completely different adver-tising approach than Windows or iOS/macOS, makingthem immune to the address-carryover algorithm. Thetested Android phones never send out manufacturer-specific data or other potentially device-identifying datain regular intervals. Instead the OS scans for advertise-ments of other devices when the Bluetooth settings areopened by the user. Due to the lack of active, contin-uous advertising, identifying tokens cannot be assem-bled, making the observed Android devices immune tothe carry-over algorithm.

6.1.4 Smartwatches

We analyze Fitbit smartwatches which use random ad-dresses (according to their TxAdd flag) for advertisingand provide a constant 128-bit Service Class UUID as

well as some Device Information data (see Figure 8).The smartwatch advertises approximately once every 7seconds using this format.

While the TxAdd flag indicates that the devices userandom addresses, the addresses actually never change(which has previously been analyzed in depth by Cyr etal. [31] and Das et al. [32]). In the tracking section, weprovide some additional insights on this behavior, sincesuch permanent trackability raises considerable privacyconcerns.

The advertised 128-bit Service Class UUIDadabfb006e7d4601bda2bffaa68956ba is specific to thewatch model [14, 33], and is identical for the tworecorded watches. Service Class UUIDs are therefore notsuitable identifying tokens, as their value does not iden-tify individual devices.

The Device Information data seems to be differ-ent for different smartwatches8, and changes over timein the scale of weeks or months. We observed changeswithin one device which only concerned a single bit inthe Device Information data, whereas differences be-tween the observed devices differed in 7 different bits.More measurements on different devices would have tobe conducted to conclude its fitness as an identifying to-ken – given the above-mentioned trivial case of a never-changing address, we did not explore this further.

6.2 Device Tracking

Applying phase 2 of the algorithm reveal that multi-ple classes of devices are vulnerable to tracking beyondaddress randomization.

Windows 10 devices are vulnerable to theaddress-carryover algorithm because the advertising ad-dress and the identifying token AW in10’s value changesoccur at different intervals and out of sync. This allowsthe algorithm to either update the payload while theaddress is known, or vice versa. Figure 9 shows how weare able to track the device with the initial advertisingaddress 1da6aa6d7b4e and associate it with the device2662e1021647 almost four hours later, and after 12 ad-dress randomizations. The longest observed MTTW in10is 11.2 hours of continous tracking. However, assum-ing an always-on target device there is no clear upperbound, i.e., MTTW in10 ∈ [11.2 hours,∞).

8 We did not have access to a sufficient amount of watches ofthis type to make a strong claim about its uniqueness

Tracking Anonymized Bluetooth Devices 12

address:

payload:

09:4

8:41

09:5

6:00

10:1

2:00

10:2

7:58

10:3

1:21

10:4

3:58

10:5

9:57

11:1

5:56

11:3

1:20

11:3

1:57

11:4

7:55

12:0

3:55

12:1

9:55

12:3

1:22

12:3

5:54

12:5

1:53

13:0

7:52

13:2

3:55

13:3

1:20

13:3

9:51

3b53acb2...feffa92adfdceea9...514feee1bd0810ce...f54dedfcd2f263ca...4b9cdc9a 4883de9d...cdc5fce7

1da6aa6d7b4e0265aa31d96c09940c1c007e3980a7d6747914ad7b1271620029374df4011ac7364f46cf2f507edc63d8049728a906d70b43fca5358239e2218858c120891f7e96c73b567a4cade43e02757912e70dfc4c7aab342662e1021647

time

Fig. 9. An experiment illustrating the carry-over effect on Windows 10 devices. Asynchronous value changes allow updating the deviceidentity whenever it changes.

address:

handoff:

nearby:

12:2

6:24

12:2

7:08

12:2

7:32

12:3

0:57

12:3

2:03

12:3

4:02

12:3

4:57

12:3

6:21

12:4

1:30

12:4

4:16

12:4

6:46

12:4

7:11

12:4

9:16

12:5

0:16

12:5

1:30

12:5

3:49

12:5

6:19

12:5

8:07

12:5

8:53

12:5

9:27

13:0

1:53

13:0

4:22

13:0

5:10

13:0

7:06

13:0

8:04

13:1

5:32

13:1

8:07

13:1

9:07

13:2

0:19

003...10c 003...953 004...647

0b1...e20

488d4dbaa162 5f4cb95c9be6 50889aae1b43 40514e890446 7fb552cfec20

time

Fig. 10. This timeline shows address-carryover across 5 random addresses on iOS. The first three hops occur via the handoff identify-ing token, the last one occurs via the nearby token. Different colors denote different values.

iOS or macOS devices have two identifying tokens(nearby, handoff) which change in different intervals. Inmany cases, the values of the identifying tokens changein sync with the address. However, in some cases the to-ken change does not happen in the same moment, whichallows the carry-over algorithm to identify the next ran-dom address. Figure 10 shows such a carry-over chain, inwhich a device is trackable across five address random-izations. In contrast to the Windows 10 implementation,synchronized value changes appear to be more preva-lent than asynchronous changes, the latter representingcarry-over opportunities. MTTApple = 53 minutes is thelongest time we were able to track during our experi-ments; additional tests may yield a longer time.

Prior findings by other groups [31, 32] indicate thatFitbit smartwatches advertising addresses do not peri-odically randomize. However, since the address carriesthe flag indicating a random address, we seek to furtherinvestigate its nature by subjecting the smartwatch todifferent conditions which may trigger a new randomaddress. Our tests include:

– Draining the battery;– Performing a hard reset;– Performing a factory reset.

None of these measures resulted in a change of the ob-served advertising address, leading to permanent non-continuous trackability despite active attempts to re-generate the address. Hence, by confirming that there

is no user-accessible way to anonymize the device iden-tity periodicity, we conclude that there is no upper limitfor the trackability of a Fitbit smartwatch of the typediscussed, i.e., MTTF itbit =∞.

Android devices do not appear to be vulnerable toour passive sniffing algorithm, as they typically do notsend advertising messages containing suitable identify-ing tokens.

6.3 Other Vulnerabilities

This Section summarizes additional findings which donot directly result from the application of our algorithm,but were discovered in the process.

6.3.1 Accessory Activation

We look into the effect of BLE-connected accessories,specifically pencils of touch-enabled laptops and tablets.

The Microsoft Surface Pen has a button whichcan be configured to launch the note-taking (or anyother) application to facilitate activities which make useof handwritten input. Whenever that button is pressed,the pen sends an ADV_DIRECT_IND request to its con-nected Surface device. These types of messages containthe device’s own advertising address as well as the tar-get address. In the case of the Surface Pen, this targetaddress uses the public static address of the device it is

Tracking Anonymized Bluetooth Devices 13

AdvA: <48bit random address>AdvData: 2 AD Structures:

0x01 → Flags: 0x060x09 → Complete Local Name:

“Apple Pencil<13 Unicode Nullbytes>”

Fig. 11. Apple Pencil advertising during connection procedure..

associated to. The Surface Pen also features a magneticconnector which allows it to be attached to the Surface.When the Surface Pen is detached from the Surface, itsends the same kind of address-leaking directed adver-tising as well.

This means that even if the Surface computer itselfnever discloses its public static address, the pen will ex-pose it. The fact that it is a permanent identifier leadsto the Surface computer being trackable permanentlyvia active probing. Once the public address becomesknown, an adversary could periodically probe the Sur-face device directly using its permanent address. Theresponse to such a directed advertising message (or ab-sence thereof) results in indefinite presence tracking ofthe Surface device, i.e., MTTSurface,leaked =∞.

We tested whether the Apple Pencil has similarissues, but it uses an entirely different approach. Whenit first connects to an iOS device, it emits a short burstof ADV_IND messages containing a random address, ca-pability flags and a Complete Local Name field of valueApple Pencil (see Figure 11). After this initial advertis-ing, the pen does not emit any advertising messages aslong as it is paired with the iOS device. Every time thepen is set up again, the random address changes.

6.3.2 Activity Side-Channel on iOS

The handoff data structure only appears in certain pat-terns. Closer inspection reveals the following two char-acteristics:

– The handoff payload is triggered when a device getsactivated;

– The handoff payload changes depending on contextor content of the active application.

Both of these characteristics present a side channelwhich allows a passive observer to deduct activity pat-terns of the user using the target device. Figure 12illustrates the presence of a burst of advertising mes-

unlock phone lock phone unlock phone lock phone

nearby: 031c6b0e3b 0b1c6b0e3b 031c6b0e3b 0b1c6b0e3b

handoff: 004b16627c02. . . 004c169f562d. . .

time

Fig. 12. The handoff data structure appears whenever an iOSdevice is unlocked.

open link #1 link #2 link #3 close

nearby: 0b1c6b0e3bhandoff: H1 H2 H3 H4 H5

time

Fig. 13. The handoff payload changes correlate closely with cer-tain user activity on iOS.

sages containing the handoff data structure every timean iPhone is unlocked.

The handoff feature on macOS and iOS devices al-lows a user to continue one activity on another device.For example, it allows browsing a website on an iPhoneand then continuing to browse it on a computer runningmacOS, when the two devices are in proximity. As such,this feature is inherently dependent on content and con-text of the user activity. It can be shown that handoffdata changes highly correlate with user navigation usingthe Safari browser in iOS (see Figure 13).

7 RecommendationsDevice implementations should follow a few simple rulesin order to protect themselves against address-carryovertracking.

Synchronize payload changes with address ran-domizations. If the advertising message payloadcontains any type of data that could be used as anidentifying token (see Section 4.3.1), the payloadshould change in sync with the address to preventextended tracking. While there may be technicalreasons for keeping certain payloads around longerthan the default address randomization frequencyof a given operating system, it should be ensuredprogrammatically that there is no continuous car-ryover, as shown to be the case in Windows 10 andto a certain degree in iOS and macOS.

Implement address randomization for low-powered devices. For some devices, especiallywearables and other battery-powered sensor de-vices, frequently randomizing the address may be

Tracking Anonymized Bluetooth Devices 14

at conflict with energy constraints. In these situ-ations, device states which are not concerned bythese constraints should be leveraged to change theaddress, e.g., when charging the battery or when apower cycle or other maintenance activity is per-formed. For example, wearables typically have to berecharged weekly or even every few days, which –even though far from perfect – will at least preventtrivial address-based tracking for the lifetime of thedevice.

Implement reconnection addresses. BLE allowsdevices to exchange Identity Resolving Keys (IRK)which enable them to use resolvable random pri-vate addresses of each other (see Section 3.3). Thisallows for secure directed advertisement and con-nection initiation that does not leak permanentidentifiers to the public [20, pp. 1251f., 2738]. De-vices which currently use an advertising approachinvolving static addresses (such as the MicrosoftSurface Pen) should consider integrating this pro-tocol feature into their software architecture.

7.1 Workaround for Windows 10 devices

Our investigation showed that simply turning the Blue-tooth setting in the Windows 10 Settings Panel off andon did not regenerate the payload and address used forBluetooth advertising, instead merely paused advertis-ing activity.

As Windows 10 is closed-source, a real fix has tobe implemented by the manufacturer. However, it isstill possible to break address-carryover tracking on theuser side by completely disabling the Bluetooth devicethrough the Windows Device Manager and re-enablingit again. Contrary to the Windows 10 Settings page,disabling the Bluetooth device in this manner will resetboth the advertising address and the payload, therebybreaking the chain. Figure 14 shows an approach whichpractically achieves protection from our algorithm bycyclically performing this reset every x seconds when-ever the device is not in the Connection state (in orderto not break ongoing communication).

7.2 Workaround for iOS / macOS

For iOS and macOS, the same approach shown in Fig-ure 14 applies. Switching Bluetooth off and on in theSystem Settings (or in the Menu Bar on macOS) willrandomize the address and change the payload.

start Bluetoothactive?

stop

State 6=Connec-tion?

DisableBluetoothDevice

EnableBluetoothDevice

Timeoutx seconds

no

yes yes

no

Fig. 14. A proposed workaround which breaks tracking via theaddress-carryover algorithm on Windows 10 and iOS/macOSdevices.

8 ConclusionDevice manufacturers have flexibility in how to imple-ment address randomization supported by BLE, andmay be compelled to take shortcuts for various reasons– be it energy or memory constraints on the device level,software complexity or just for the sake of cutting de-velopment cost.

We showed that most computer and smartphone op-erating systems do implement address randomizationsby default as a means to prevent long-term passivetracking, as permanent identifiers are not broadcasted.

However, we identified that devices running Win-dows 10, iOS or macOS regularly transmit advertis-ing events containing custom data structures which areused to enable certain platform-specific interaction withother devices within BLE range. By observing typi-cal advertising behaviors of these operating systems,we identified that parts of these data structures allowan adversary to abuse them as a temporary, secondarypseudo-identity. These identifying tokens can be inte-grated into an algorithm which allows device trackingbeyond address randomization.

The address-carryover algorithm exploits theasynchronous nature of address and payload change,and uses unchanged identifying tokens in the payloadto trace a new incoming random address back to aknown device. In doing so, the address-carryover algo-rithm neutralizes the goal of anonymity in broadcastingchannels intended by frequent address randomization.

The main findings of this work are summarized inTable 4. The algorithm succeeds consistently on Win-dows 10 and sometimes on Apple operating systems. Inboth cases, the respective identifying tokens change outof sync with the advertising address. In the Windows 10case, there is no evidence of any synchronization by de-sign. In the Apple case, it seems that there exist mecha-

Tracking Anonymized Bluetooth Devices 15

Type ∅ Address life MT T∗ Adversary MechanismWindows 10 16 min unbounded continuous carry-over algorithmmacOS, iOS 20 min 53 min9 continuous carry-over algorithmAndroid 15-45 min no vuln. identified continuous carry-over algorithmFitbit Charge static unbounded non-continuous vendor implementationMicrosoft Surface 16 min unbounded non-continuous identifier leak via Pen

Table 4. Trackability summary of the observed devices.

nisms to synchronize updates of identifying tokens withaddress randomization, but they occasionally fail.

The Android devices that we tested are not affectedby the address-carryover algorithm, as they do not con-tinuously send advertising messages. This is consistentwith the BLE Central role (see Section 3.1), which scansfor advertising from nearby Peripheral devices instead ofadvertising itself. Note that the Android SDK containsfunctionality for implementing BLE advertising [34],but it does not seem to be used by the OS by default inthe devices we tested.

Fitbit has not fixed the trackability issue, despiteit being known for years [31, 32]. This is concerningsince such activity trackers are by design worn and car-ried around in daily life, and there is no way to preventsniffing their permanent addresses.

Any device which regularly advertises data contain-ing suitable advertising tokens will be vulnerable to thecarry-over algorithm if it does not change all of its iden-tifying tokens in sync with the advertising address. AsBluetooth adoption is projected to grow from 4.2 to5.2 billion devices between 2019 and 2022 [5, p. 11],with over half a billion amongst them wearables andother data-focused connected devices [5, p. 15], estab-lishing tracking-resistant methods, especially on unen-crypted communication channels, is of paramount im-portance. This privacy concern is compounded by therealistic feasibility of BLE-based botnets [7] and comple-mentary threats such as large-scale tracking of users viacompromised Wi-Fi routers [35], which amplify tracka-bility to a global scale. It can further be imagined thatadditional metadata such as electronic purchase trans-actions, facial recognition and other digital traces couldbe combined with Bluetooth tracking to generate a fine-grained location profile of a victim.

9 Longer tracking may be possible, but did not occur in ourexperiments.

8.1 Further Research

In this work, we entirely focused on the existence of datafields which could be re-purposed as pseudo-identifiers.The discoveries presented in this work do not requirean SDR-based setup and should be reproducible usingcommon Bluetooth communication hardware.

Future work may focus on additional factors such asthe consideration of advertising message timing, whichmay make the address-carryover algorithm even morepowerful. Another interesting factor would be physicallayer device fingerprinting using SDR, similar to previ-ous work done on other wireless technologies [36–39],which may allow tracking despite immunity from theaddress-carryover algorithm to certain extents.

Furthermore, our current approach may be comple-mented by active attacks previously considered for Wi-Fi [7, 15, 18], and adapted to Bluetooth where applica-ble. This includes Connection-based attacks which arebased on the data channels rather than just the BLEadvertising channels.

Responsible Disclosure

Vulnerability to the address-carryover algorithm discov-ered in Microsoft and Apple software was disclosed withthe companies in November 2018. Additional findingsregarding the Microsoft Surface Pen and iOS activityside channel were subsequently disclosed to the respec-tive companies during the ongoing correspondence.

Acknowledgment

This research was supported in part by NSF under grantCCF-1563753 and by the Boston University UROP pro-gram. The authors also thank Jed Crandall for shep-herding the paper and the anonymous reviewers for theirconstructive suggestions.

Tracking Anonymized Bluetooth Devices 16

References[1] Bluetooth Special Interest Group (SIG), “Our History,” 2018.

[Online]. Available: https://www.bluetooth.com/about-us/our-history

[2] ——, “Core Specifications,” 2018. [Online]. Available:https://www.bluetooth.com/specifications/bluetooth-core-specification

[3] D. Spill and A. Bittau, “BlueSniff: Eve meets Alice andBluetooth,” WOOT ’07 Proceedings of the first USENIXworkshop on Offensive Technologies, p. 10, 2007. [Online].Available: http://dl.acm.org/citation.cfm?id=1323276.1323281

[4] M. Woolley, “Bluetooth Technology Protecting YourPrivacy,” 2015. [Online]. Available: https://blog.bluetooth.com/bluetooth-technology-protecting-your-privacy

[5] Bluetooth Special Interest Group (SIG), “BluetoothMarket Update 2018,” Bluetooth Special InterestGroup (SIG), Tech. Rep., 2018. [Online]. Available:https://www.bluetooth.com/markets/market-report

[6] H. Karvonen, C. Pomalaza-Ráez, K. Mikhaylov,M. Hämäläinen, and J. Iinatti, “Experimental PerformanceEvaluation of BLE 4 Versus BLE 5 in Indoorsand Outdoors Scenarios,” in Advances in Body AreaNetworks I, G. Fortino and Z. Wang, Eds. Cham:Springer, 2019, pp. 235–251. [Online]. Available:http://link.springer.com/10.1007/978-3-030-02819-0_18

[7] T. Issoufaly and P. U. Tournoux, “BLEB: Bluetooth LowEnergy Botnet for large scale individual tracking,” 20171st International Conference on Next Generation ComputingApplications, NextComp 2017, pp. 115–120, 2017.

[8] M. Jakobsson and S. Wetzel, “Security Weaknessesin Bluetooth,” in Topics in Cryptology — CT-RSA 2001,D. Naccache, Ed. Berlin, Heidelberg: Springer, 2001, pp. 176–191. [Online]. Available: http://link.springer.com/10.1007/3-540-45353-9_14

[9] Bluetooth Special Interest Group (SIG), Bluetooth CoreSpecification. v4.0. Bluetooth Special Interest Group (SIG),2010.

[10] M. I. Jameel and J. Dungen, “Low-Power WirelessAdvertising Software Library for Distributed M2M andContextual IoT,” in 2015 IEEE 2nd World Forum on Internetof Things (WF-IoT). IEEE, 12 2015, pp. 597–602. [Online].Available: http://ieeexplore.ieee.org/document/7389121/

[11] Apple Inc., “iBeacon,” 2014. [Online]. Available:https://developer.apple.com/ibeacon/

[12] Google, “Eddystone.” [Online]. Available: https://github.com/google/eddystone

[13] reelyActive, “reelyActive-git.” [Online]. Available: https://github.com/reelyactive/advlib

[14] ——, “Sniffypedia,” 2018. [Online]. Available: https://sniffypedia.org/

[15] M. Vanhoef, C. Matte, M. Cunche, L. S. Cardoso,and F. Piessens, “Why MAC Address Randomizationis not Enough,” in Proceedings of the 11th ACM onAsia Conference on Computer and Communications Security- ASIA CCS ’16. New York, New York, USA: ACMPress, 2016, pp. 413–424. [Online]. Available: https://dl.acm.org/citation.cfm?id=2897883

[16] D. Dai Zovi and S. Macaulay, “Attacking AutomaticWireless Network Selection,” in Proceedings from theSixth Annual IEEE Systems, Man and Cybernetics (SMC)Information Assurance Workshop, 2005., vol. 2005. IEEE,2005, pp. 365–372. [Online]. Available: http://ieeexplore.ieee.org/document/1495975/

[17] D. A. Dai Zovi, “KARMA Attacks Radioed MachinesAutomatically,” 2005. [Online]. Available: http://theta44.org/karma/

[18] J. Martin, T. Mayberry, C. Donahue, L. Foppe, L. Brown,C. Riggins, E. C. Rye, and D. Brown, “A Study of MACAddress Randomization in Mobile Devices and When itFails,” Proceedings on Privacy Enhancing Technologies, vol.2017, no. 4, pp. 365–383, 10 2017. [Online]. Available:http://content.sciendo.com/view/journals/popets/2017/4/article-p365.xml

[19] R. Heydon, “An Introduction to Bluetooth Low Energy,” pp.1–15, 2013.

[20] Bluetooth Special Interest Group (SIG), Bluetooth CoreSpecification. v5.0. Bluetooth Special Interest Group (SIG),2016. [Online]. Available: https://www.bluetooth.com/bluetooth-technology/bluetooth5/bluetooth5-paper

[21] ——, “Generic Access Profile.” [Online]. Available: https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile

[22] ——, Supplement to the Bluetooth Core Specification.Bluetooth Special Interest Group (SIG), 2015.

[23] ——, “Company Identifiers.” [Online]. Available: https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers

[24] ——, “Service Discovery.” [Online]. Available: https://www.bluetooth.com/specifications/assigned-numbers/service-discovery

[25] Radius Networks, “AltBeacon,” 2015. [Online]. Available:https://altbeacon.org/

[26] IEEE Computer Society, IEEE Standard for Local andMetropolitan Area Networks - Link Aggregation. IEEEStandards Association, 2008. [Online]. Available: http://standards.ieee.org/findstds/standard/802.1AX-2008.html

[27] I. Wagner and D. Eckhoff, “Technical Privacy Metrics,”ACM Computing Surveys, vol. 51, no. 3, pp. 1–38, 2018.[Online]. Available: http://dl.acm.org/citation.cfm?doid=3212709.3168389

[28] K. Sampigethaya, L. Huang, M. Li, R. Poovendran, K. Mat-suura, and K. Sezaki, “CARAVAN: Providing Location Privacyfor VANET,” Washington Univ Seattle Dept of ElectricalEngineering, Tech. Rep., 2005.

[29] B. C. Drachman and M. J. Cloud, Inequalities: With Applica-tions to Engineering. Springer-Verlag, 1998.

[30] X. Jiao, “BTLE,” 2014. [Online]. Available: https://github.com/JiaoXianjun/BTLE

[31] B. Cyr, W. Horn, D. Miao, and M. Specter, “SecurityAnalysis of Wearable Fitness Devices (Fitbit),” MassachusettsInstitute of Technology, pp. 1–14, 2014. [Online]. Available:http://courses.csail.mit.edu/6.857/2014/files/17-cyrbritt-webbhorn-specter-dmiao-hacking-fitbit.pdf

[32] A. K. Das, P. H. Pathak, C.-N. Chuah, and P. Mohapatra,“Uncovering Privacy Leakage in BLE Network Trafficof Wearable Fitness Trackers,” in Proceedings of the17th International Workshop on Mobile Computing Systems

Tracking Anonymized Bluetooth Devices 17

and Applications - HotMobile ’16. New York, New York,USA: ACM Press, 2016, pp. 99–104. [Online]. Available:http://dl.acm.org/citation.cfm?doid=2873587.2873594

[33] virtualabs, “probeZero,” 2016. [Online]. Available:https://github.com/virtualabs/probeZero

[34] Google Developers, “BluetoothLeAdvertiser.” [Online].Available: https://developer.android.com/reference/android/bluetooth/le/BluetoothLeAdvertiser

[35] P. Rouveyrol, P. Raveneau, and M. Cunche, “Large Scale Wi-Fi Tracking Using a Botnet of Wireless Routers,” Workshopon Surveillance & Technology, 2015.

[36] B. Danev, D. Zanetti, and S. Capkun, “On Physical-LayerIdentification of Wireless Devices,” ACM Computing Surveys,vol. 45, no. 1, pp. 1–29, 2012. [Online]. Available:http://dl.acm.org/citation.cfm?doid=2379776.2379782

[37] Q. Xu, R. Zheng, W. Saad, and Z. Han, “DeviceFingerprinting in Wireless Networks: Challenges andOpportunities,” IEEE Communications Surveys & Tutorials,vol. 18, no. 1, pp. 94–104, 2016. [Online]. Available:http://ieeexplore.ieee.org/document/7239531/

[38] T. D. Vo-Huu, T. D. Vo-Huu, and G. Noubir,“Fingerprinting Wi-Fi Devices Using Software DefinedRadios,” in Proceedings of the 9th ACM Conferenceon Security & Privacy in Wireless and Mobile Networks -WiSec ’16. New York, New York, USA: ACMPress, 2016, pp. 3–14. [Online]. Available: http://dl.acm.org/citation.cfm?doid=2939918.2939936

[39] G. Baldini, R. Giuliani, G. Steri, and R. Neisse,“Physical Layer Authentication of Internet of ThingsWireless Devices Through Permutation and DispersionEntropy,” in 2017 Global Internet of Things Summit(GIoTS). IEEE, 6 2017, pp. 1–6. [Online]. Available:http://ieeexplore.ieee.org/document/8016272/