Proceedings on Privacy Enhancing Technologies ..; .. (..

):1–19

Alexander Heinrich*, Milan Stute*, Tim Kornhuber, and Matthias Hollick

Who Can Find My Devices?

Security and Privacy of Apple’s Crowd-Sourced
Bluetooth Location Tracking System
Abstract: Overnight, Apple has turned its hundreds-of- 1 Introduction
million-device ecosystem into the world’s largest crowd-
sourced location tracking network called offline finding In 2019, Apple introduced offline finding (OF), a pro-
(OF). OF leverages online finder devices to detect the prietary crowd-sourced location tracking system for off-
arXiv:2103.02282v1 [cs.CR] 3 Mar 2021

presence of missing offline devices using Bluetooth and line devices. The basic idea behind OF is that so-called
report an approximate location back to the owner via finder devices can detect the presence of other lost off-
the Internet. While OF is not the first system of its line devices using Bluetooth Low Energy (BLE) and use
kind, it is the first to commit to strong privacy goals. their Internet connection to report an approximate lo-
In particular, OF aims to ensure finder anonymity, un- cation back to the owner. Apple’s OF network consists
trackability of owner devices, and confidentiality of lo- of “hundreds of millions” of devices [4], making it the
cation reports. This paper presents the first comprehen- currently largest crowd-sourced location tracking sys-
sive security and privacy analysis of OF. To this end, we tem in existence. We expect the network to grow as OF
recover the specifications of the closed-source OF proto- will officially support the tracking of non-Apple devices
cols by means of reverse engineering. We experimentally in the future [6]. Regardless of its size, the system has
show that unauthorized access to the location reports al- sparked considerable interest and discussion within the
lows for accurate device tracking and retrieving a user’s broader tech and security communities [28, 29] as Ap-
top locations with an error in the order of 10 meters in ple makes strong security and privacy claims supported
urban areas. While we find that OF’s design achieves by new cryptographic primitives that other commercial
its privacy goals, we discover two distinct design and systems are lacking [51]. In particular, Apple claims that
implementation flaws that can lead to a location cor- it cannot access location reports, finder identities are
relation attack and unauthorized access to the location not revealed, and BLE advertisements cannot be used
history of the past seven days, which could deanonymize to track devices [35]. Apple has yet to provide ample
users. Apple has partially addressed the issues following proof for their claims as, until today, only selected com-
our responsible disclosure. Finally, we make our research ponents have been publicized [4, 6, 35].
artifacts publicly available. Contribution. This paper challenges Apple’s secu-
rity and privacy claims and examines the system de-
Keywords: Apple, Bluetooth, location privacy, reverse sign and implementation for vulnerabilities. To this end,
engineering, trackings tags, user identification we first analyze the involved OF system components on
DOI Editor to enter DOI macOS and iOS using reverse engineering and present
Received ..; revised ..; accepted ... the proprietary protocols involved during losing, search-
ing, and finding devices. In short, devices of one owner
agree on a set of so-called rolling public–private key
*Corresponding Author: Alexander Heinrich: Secure pairs. Devices without an Internet connection, i.e., with-
Mobile Networking Lab, Technical University of Darmstadt, out cellular or Wi-Fi connectivity, emit BLE adver-
Germany, E-mail: [email protected] tisements that encode one of the rolling public keys.
*Corresponding Author: Milan Stute: Secure Mobile
Finder devices overhearing the advertisements encrypt
Networking Lab, Technical University of Darmstadt, Germany,
E-mail: [email protected] their current location under the rolling public key and
Tim Kornhuber: Secure Mobile Networking Lab, Technical send the location report to a central Apple-run server.
University of Darmstadt, Germany, When searching for a lost device, another owner device
E-mail: [email protected] queries the central server for location reports with a
Matthias Hollick: Secure Mobile Networking Lab, Technical
set of known rolling public keys of the lost device. The
University of Darmstadt, Germany,
owner can decrypt the reports using the corresponding
E-mail: [email protected]
private key and retrieve the location.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 2

Based on our analysis, we assess the security and gineering methodology. § 6 describes the OF protocols
privacy of the OF system. We find that the overall de- and components in detail. § 7 evaluates the accuracy of
sign achieves Apple’s specific goals. However, we discov- OF location reports. § 8 assesses the security and pri-
ered two distinct design and implementation vulnera- vacy of Apple’s OF design and implementation. § 9 and
bilities that seem to be outside of Apple’s threat model § 10 report two discovered vulnerabilities and propose
but can have severe consequences for the users. First, our mitigations. § 11 reviews related work. Finally, § 12
the OF design allows Apple to correlate different own- concludes this work.
ers’ locations if their locations are reported by the same
finder, effectively allowing Apple to construct a social 2 Background
graph. Second, malicious macOS applications can re-
trieve and decrypt the OF location reports of the last This section gives a brief introduction to BLE and el-
seven days for all its users and for all of their devices liptic curve cryptography (ECC) as they are the basic
as cached rolling advertisement keys are stored on the building blocks for OF. We then cover relevant Apple
file system in cleartext. We demonstrate that the latter platform internals.
vulnerability is exploitable and verify that the accuracy
of the retrieved reports—in fact—allows the attacker to 2.1 Bluetooth Low Energy
locate and identify their victim with high accuracy. We Bluetooth Low Energy (BLE) [19] is designed for small
have shared our findings with Apple via responsible dis- battery-powered devices such as smartwatches and fit-
closure, who have meanwhile fixed one issue via an OS ness trackers with low data rates. Devices can broadcast
update (CVE-2020-9986, cf. Responsible Disclosure sec- BLE advertisements to inform nearby devices about
tion for details). We summarize our key contributions. their presence. The maximum BLE advertisement pay-
load size is 31 bytes [19]. Apple heavily relies on custom
– We provide a comprehensive specification of the OF BLE advertisements to announce their proprietary ser-
protocol components for losing, searching, and fin- vices such as AirDrop and bootstrap their protocols over
ding devices. Our PoC implementation allows for Wi-Fi or Apple Wireless Direct Link (AWDL) [21, 36,
tracking non-Apple devices via Apple’s OF network. 48]. OF devices also use BLE advertisements to inform
– We experimentally evaluate the accuracy of real- nearby finders about their presence [6].
world location reports for different forms of mobil-
ity (by car, train, and on foot). We show that (1) a 2.2 Elliptic Curve Cryptography
walking user’s path can be tracked with a mean er-
ror of less than 30 m in a metropolitan area and (2) OF employs elliptic curve cryptography (ECC) for en-
the top locations of a user such as home and work- crypting location reports. ECC is a public-key encryp-
place can be inferred reliably and precisely (error in tion scheme that uses operations on elliptic curve (EC)
the order of 10 m) from a one-week location trace. over finite fields. An EC is a curve over a finite field
– We discover a design flaw in OF that lets Apple that contains a known generator (or base point) G. A
correlate the location of multiple owners if the same private key in ECC is a random number in the finite
finder submits the reports. This would jeopardize field of the used curve. The public key is the result of
location privacy for all other owners if only a single the point multiplication of the generator G with the pri-
location became known. vate key. The result is an X–Y coordinate on the curve.
– We discover that a local application on macOS can The NIST P-224 curve [39], which is used by OF [6],
effectively circumvent Apple’s restrictive location provides a security level of 112 bit.
API [5] and access the user’s location history with-
out their consent, allowing for device tracking and 2.3 Apple Platform Internals
user identification. We briefly introduce the terms keychain and iCloud as
– We open-source our PoC implementation and ex- they are relevant for Apple’s OF implementation.
perimental data (cf. Availability section). Keychain. All Apple operating systems (OSs) use
a keychain as a database to store secrets such as
Outline. The remainder of this paper is structured passwords, keys, and trusted Transport Layer Security
as follows. § 2 and § 3 provide background informa- (TLS) root certificates. The keychain is used by sys-
tion about OF and the involved technology. § 4 outlines tem services such as AirDrop [48] and third-party ap-
our adversary model. § 5 summarizes our reverse en- plications to store login information, tokens, and other
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 3

secrets. Every keychain item may contain a keychain Apple’s servers Owner device
access group. This group is used to identify which ap-
(4) Download and decrypt
plication can access which keychain items. Access poli-
location reports
cies are implemented via entitlement files embedded into
signed application binaries. A system process prevents (3) Upload encrypted
the execution of processes with unauthorized entitle- (1) Pair through
locations reports
ments, e.g., a third-party application trying to access a initial setup
system-owned keychain item. This security mechanism
(2) Broadcast
can be disabled on jailbroken iOS devices or by deacti-
Bluetooth advertisements
vating macOS system integrity protection (SIP), which
with public key
helps extracting keys and secrets used by Apple’s sys-
Finder devices Lost device
tem services.
iCloud. iCloud is an umbrella term for all Apple Fig. 1. Simplified offline finding (OF) workflow.
services handling online data storage and synchroniza-
tion via Apple’s servers. All owner devices signed in to
are considered to be lost when they lose Internet con-
the same Apple account can synchronize themselves via
nectivity. Third-party accessories [6] are small battery-
iCloud. OF uses the iCloud keychain to share rolling
powered devices that can be attached to a personal item
advertisement keys across all owner devices. The syn-
and are set up through an owner device. Accessories de-
chronization is required to retrieve and decrypt the lo-
termine to be lost when they lose their BLE connection
cation reports from potential finders on any of the owner
to the owner device.
devices [4, 35].
Finder devices. Finder devices form the core of the
OF network. As of 2020, only iPhones and iPads with a
3 Apple Offline Finding Overview GPS module are offering finder capabilities. Finder de-
Apple introduced OF in 2019 for iOS 13, macOS 10.15, vices can discover lost devices and accessories by scan-
and watchOS 6 [10]. OF enables locating Apple devices ning for BLE advertisements. Upon receiving an OF
without an Internet connection and promises to oper- advertisement, a finder creates an end-to-end encrypted
ate in a privacy-preserving manner. In 2020, Apple an- location report that includes its current location and
nounced to support third-party BLE-enabled devices to sends it to Apple’s servers.
be tracked by the OF network [11] and released a pro- Apple’s servers. Apple’s servers store OF location
tocol specification for their integration [6]. We found reports submitted by finder devices. Owner devices can
that this public specification is incomplete concerning fetch those reports and decrypt them locally.
the overall OF system. Within this paper, we focus on
our recovered specification that was partly validated by 4 Adversary Model
the accessory specification [6].
OF exposes several interfaces that might be targeted by
In the following, we give a brief overview of how
attackers. In this section, we identify these potentially
OF works and introduce the different roles of devices.
vulnerable interfaces and devise a comprehensive ad-
Fig. 1 depicts the interplay of the roles and protocols
versary model that will guide the rest of this paper. We
involved in OF. In particular, OF involves (1) initial
first detail the four sub-models, summarized in Tab. 1,
pairing of owner devices, (2) broadcasting BLE adver-
and we specify them by their assumptions, goals, and
tisements that contain a rolling public key, (3) upload-
capabilities following [23]. Then, we motivate the sub-
ing encrypted location reports to Apple’s servers, and
sequent analysis of OF protocols and components based
(4) retrieving the location reports on owner devices. The
on these models.
terminology of the roles below has been derived from the
First of all, we consider adversaries on either of
official documentation [6].
OF’s communication channels (cf. (2)–(4) in Fig. 1).
Owner devices. Owner devices share a common Ap-
In particular, a proximity-based adversary has access to
ple ID and can use the Find My application on macOS
BLE advertisements (A2), and a network-based adver-
and iOS to search for any devices of the same owner.
sary can modify traffic between OF devices and Apple’s
Lost devices. Devices that determine to be in a lost
servers (A3). Also, we consider a zero-permission appli-
state start sending out BLE advertisements with a pub-
cation running with user privileges on an owner/lost de-
lic key to be discovered by finder devices. Apple devices
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 4

Table 1. Adversary models considered throughout and guiding this paper. We assume that neither adversary has direct access to cryp-
tographic secrets or can break cryptographic primitives.

Model Assumptions Goals Capabilities

Local application (A1) (1) User-installed application on (1) Determine location of OF de- (1) Communicate with any server
lost/owner devices that is either re- vices without asking for permis- over the Internet. (2) Read/write
viewed or notarized. (2) Zero-per- sion. (2) Track user by accessing files that are accessible by the user
mission. (3) No privilege escalation current or historic location data. and not restricted through sand-
exploits. boxing.
Proximity-based (A2) (1) In BLE communication range (1) Access location of lost de- (1) Track devices based on adver-
of OF device. (2) Control one or vices or personally linkable data. tisement content. (2) Record and
more BLE transceivers to cover a (2) Track lost devices in larger ar- replay advertisements at different
larger area. eas (e.g., shopping center or air- locations. (3) Fabricate new adver-
port). (3) DoS against OF service. tisements.
Network-based (A3) (1) MitM position between Apple (1) Access location of reported lost (1) Redirect traffic to a different
and OF devices. (2) Cannot break devices. (2) Identify reported de- host. (2) Read, intercept, redirect,
TLS. vices. (3) Identify lost devices. or modify traffic.
Service operator (A4) (1) Apple as the service provider. (1) Locate individuals and their (1) Access to all encrypted OF re-
(2) Controls the OF server infras- lost devices. (2) Correlate locations ports and their metadata. (2) Add,
tructure. to create a social graph. remove, or modify reports.

vice that wants to infer the user’s current location. The 5 Methodology
application may be distributed inside or outside1 of Ap-
ple’s official app stores (A1). Finally, we also consider Our analysis of OF required a comprehensive under-
Apple as the service operator as an adversary that has standing of the implemented protocols by Apple. Our
access to all encrypted location reports and might try methodology follows previous works analyzing the Ap-
to infer any information based on the report metadata ple ecosystem [21, 36, 44, 45, 48], while providing new
such as submission times and finder identifiers (A4). insights into the reverse engineering process. We started
Note that Apple uses its iCloud keychain service for this research with the beta releases of macOS 10.15 and
initial device pairing and key synchronization (cf. (1) iOS 13, the first Apple OSs to support OF. During that
in Fig. 1). Apple provides detailed information about its time, no official documentation from Apple was avail-
keychain [4], which appears to withstand professional able regarding the OF design or implementation. There-
forensics analyses [1]. Therefore, we assume that the fore, we used reverse engineering tools such as system
pairing process is secure throughout this paper. log analysis, static binary analysis, and network traffic
To conduct a security and privacy analysis based analysis. In addition, we implemented an OF prototype
on these models, we need to understand OF in detail. to validate our findings. Some of our findings, such as
To this end, we reverse engineer the protocols involved the BLE advertisement format and cryptographic prim-
in loosing, finding, and searching devices (cf. (2)–(4) itives, were later confirmed by Apple’s specification for
in Fig. 1) in § 6. Based on our understanding of OF, third-party accessories [6].
we conduct a security and privacy analysis of the BLE System Logging. To get a first overview of OS in-
communication (A2), the server communication (A3), ternals, we used the system logging facility on macOS.
and storage of encrypted reports and cryptographic It aggregates applications and kernel events, and can ac-
keys (A1/A4) in § 8. cess the same events from a USB-attached iOS device.
We can filter logs by process or keyword and adjust the
log level for more verbose output. By using a special
configuration profile [27], macOS will show logs that are
normally redacted. On iOS, this option is only available
with a jailbreak [14].
1 On macOS, applications can be distributed outside of Apple’s
app store. Those applications are not reviewed [3]. However, Binary analysis. We use binary analysis to under-
Apple recommends submitting those application to their nota- stand the closed-source OF protocols. Many Apple bi-
rization service, which checks application for malicious code [8]. naries have been written in Objective-C, which uses
macOS displays a warning and asks for user consent before ex- message dispatch to resolve methods at runtime. There-
ecuting non-notarized applications.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 5

fore, Objective-C binaries include method and instance In the following, we explain the cryptography in use,
variable names as part of the dispatch table. This sim- the protocols involved in losing, searching, and finding
plifies identifying interesting code paths and segments, devices, as well as a brief description of the system’s
e.g., those responsible for parsing BLE packets. Unfor- implementation on iOS and macOS.
tunately, most OF code is written in the newer Swift
programming language. Swift methods are statically 6.1 Cryptography
called by their program address and, therefore, do not
OF employs ECC [6]. In the following, we explain the
require an entry in the symbol table, i.e., the symbol
key generation and derivation mechanisms and the cryp-
names may be stripped by the compiler. Additionally,
tographic algorithms used for encryption and decryp-
the Swift compiler adds several checks to achieve type
tion.
safety, which clutters the compiled code and makes it
Master Beacon and Advertisement Keys. Initially,
hard to follow the program logic. However, dynami-
each owner device generates a private–public key pair
cally linked frameworks and libraries must keep function
(d0 , p0 ) on the NIST P-224 curve and a 32-byte sym-
names in the symbol table, facilitating the identifica-
metric key SK0 that together form the master beacon
tion of interesting code segments. Furthermore, dynamic
key. Those keys are never sent out via BLE and are used
analysis methods aid in understanding the control flow
to derive the rolling advertisement keys included in the
and access function parameters at runtime. By hooking
BLE advertisements.
functions with a dynamic instrumentation tool such as
OF makes device tracking hard by regularly chang-
Frida [40], we can, e.g., access cryptographic keys used
ing the contents of the BLE advertisements. In partic-
by system processes as shown in [45].
ular, OF uses the concept of rolling keys that can be
Network analysis. We can identify a service’s proto-
deterministically derived if one knows the initial input
cols by monitoring network interfaces, which helps un-
keys (d0 , p0 ) and SK0 but are otherwise unlinkable. OF
derstand the information exchange with external par-
iteratively calculates the advertisement keys (di , pi ) for
ties. OF uses two protocols: BLE for advertisements and
i > 0 as follows using the ANSI X.963 key derivation
HTTPS for server communication. To understand the
function (KDF) with SHA-256 [33] and a generator G
embedded custom protocols and payloads, we rely on
of the NIST P-224 curve:
two sets of tools. For BLE, we use BTLEmap [31] to cap-
ture all BLE advertisements. As we already know the SKi = KDF(SKi−1 , “update”, 32) (1)
basic frame format of Apple’s custom advertisements
(ui , vi ) = KDF(SKi , “diversify”, 72) (2)
from related work [21, 36], we were able to identify OF
as a new subtype. HTTPS proxies such as [50] decrypt di = (d0 ∗ ui ) + vi (3)
HTTPS sessions by masquerading as both HTTP client pi = di ∗ G (4)
and server and using self-signed TLS certificates. To ac-
Equation (1) derives a new symmetric key from the last
cess OF-related traffic, we disabled certificate pinning,
used symmetric key with 32 bytes length. Equation (2)
which OF clients use for all server communication.
derives the so-called “anti-tracking” keys ui and vi from

6 Apple Offline Finding in Detail

the new symmetric key with a length of 36 bytes each.
Finally, Eqs. (3) and (4) create the advertisement key
This section describes and discusses the technical details pair via EC point multiplication using the anti-tracking
of Apple’s OF system. In reference to Fig. 1, we (1) ex- keys and the master beacon key d0 .
plain the involved cryptography and the key exchange Key Synchronization. All owner devices need to
during initial device pairing, and then explain the pro- access the advertisement keys to download and decrypt
tocols implementing (2) losing, (3) finding, (4) searching location reports. Therefore, OF synchronizes the mas-
for devices. ter beacon keys via iCloud in a property list file en-
In short, devices and accessories in lost mode send crypted under Advanced Encryption Standard in Ga-
out BLE advertisements containing a public key. Finder lois/Counter Mode (AES-GCM). The decryption key for
devices receive them, encrypt their location by using the file is stored in the iCloud keychain under the label
the public key, and upload a report to Apple’s servers. “Beacon Store.”
This results in an end-to-end encrypted location report Encryption. The BLE advertisements sent out by
that cannot be read by Apple or any other third-party a lost device contain an EC public key pi . A finder
that does not have access to the owner’s private keys. device that receives such an advertisement determines
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 6

its current location and encrypts the location with Table 2. OF advertisement format (with zero-indexed bytes).
pi . OF employs Elliptic Curve Integrated Encryption
Scheme (ECIES) that performs an ephemeral Elliptic Bytes Content (details cf. [6, § 5.1])
Curve Diffie-Hellmann (ECDH) key exchange to derive 0–5 BLE address ((pi [0] | (0b11  6)) || pi [1..5])
a shared secret and encrypt the report [37]. In particu- 6 Payload length in bytes (30)
lar, the finder’s encryption algorithm works as follows: 7 Advertisement type (0xFF for manufacturer-specific data)
8–9 Company ID (0x004C)
(1) Generate a new ephemeral key (d0 , p0 ) on the NIST 10 OF type (0x12)
P-224 curve for a received OF advertisement. 11 OF data length in bytes (25)
(2) Perform ECDH using the ephemeral private key d0 12 Status (e.g., battery level)
13–34 Public key bytes pi [6..27]
and the advertised public key pi to generate a shared
35 Public key bits pi [0]  6
secret. 36 Hint (0x00 on iOS reports)
(3) Derive a symmetric key with ANSI X.963 KDF on
the shared secret with the advertised public key as
entropy and SHA-256 as the hash function. for the payload. For standard compliance, the custom
(4) Use the first 16 bytes as the encryption key e0 . OF advertisements needs to add a 4-byte header for
(5) Use the last 16 bytes as an initialization vector (IV). specifying manufacturer-specific data, which leaves 27
(6) Encrypt the location report under e0 and the IV bytes. Within this space, Apple uses a custom encod-
with AES-GCM. ing for subtypes used by other wireless services such as
AirDrop [21]), which leaves 25 bytes for OF data. To fit
The ephemeral public key p0 and the authentication
the 28-byte advertisement key in one packet, Apple re-
tag of AES-GCM are part of the uploaded message, as
purposes the random address field to encode the key’s
shown in Fig. 2. All location reports are identified by
first 6 bytes. However, there is one caveat: the BLE stan-
an id, which is a SHA-256 hash of pi .
dard requires that the first two bits of a random address
Decryption. An owner device that retrieves en-
be set to 0b11. OF stores the first two bits of the ad-
crypted location reports follows the inverse of the en-
vertisement key together with the 24 remaining bytes in
cryption procedure. First, the owner device selects the
the payload to solve the problem. We depict the com-
proper advertisement keys (di , pi ) based on the hashed
plete BLE advertisement packet format in Tab. 2. Apple
pi of the location report. Second, it performs the ECDH
confirmed the reverse-engineered specification later [6].
key exchange with the finder’s ephemeral public key p0
Advertising Interval. The same key is emitted dur-
and the lost device’s private key di to compute the sym-
ing a window of 15 minutes, after which the next key
metric key e0 and the IV. Finally, the owner can use e0
pi+1 is used. During a window, OF-enabled iOS and
and IV to decrypt the location report.
macOS devices emit one BLE advertisement every two
seconds when they lose Internet connectivity.
6.2 Losing
An OF device that loses its Internet connection starts 6.3 Finding
emitting BLE advertisements. This advertisement con-
All finder devices regularly scan for OF advertisements.
sists of the 224 bit (28 bytes) public part2 of the adver-
When the finder receives a packet in the OF advertise-
tisement key (pi ), but required some engineering effort
ment format, it generates and uploads an encrypted lo-
to fit in a single BLE packet.
cation report to Apple’s servers.
Advertisement Packet Format. Apple had to en-
Generating Reports. The finder parses the pub-
gineer its way around the fact that one BLE advertise-
lic key from the advertisement. Then, it determines its
ment packet may contain at most 37 bytes [19, Vol. 6,
current geolocation and creates a message that includes
Part B, § 2.3.1.3], of which 6 bytes are reserved for the
location, accuracy,3 and status information (cf. green
advertising MAC address, and up to 31 can be used
fields in Fig. 2). The message is then encrypted us-

2 More precisely, OF only advertises the X coordinate of the

public key, which has a length of 28 bytes. The Y coordinate is 3 We assume that the accuracy value is encoded in metric me-
irrelevant for calculating a shared secret via ECDH, so the sign ters as it matches the experimentally determined positioning er-
bit for the compressed format [20] can be omitted. ror of the coordinates in the location reports, as we show in § 7.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 7

4 bytes 1 byte 57 byte Table 3. HTTP request headers for uploading location reports.

Timestamp Confidence Ephermal public key

Request Header Value
10 bytes 16 bytes
Encrypted location AES-GCM authentication tag X-Apple-Sign1 Device identity certificate (base64)
X-Apple-Sign2 SHA-256 hash of the signing CA (base64)
X-Apple-Sign3 Device ECDSA signature (ASN.1)
Latitude Longitude Horizontal accuracy Status X-Apple-I-TimeZone Client’s time zone (e.g., GMT+9)
X-Apple-I-ClientTime Client’s time (Unix)
4 bytes 4 bytes 1 byte 1 byte
User-Agent “searchpartyd/1
Fig. 2. Binary format of a location report. <iPhoneModel>/<OSVersion>”

ing the algorithm described in § 6.1. Finally, the finder 6.4 Searching
creates a complete location report, including the cur-
rent timestamp (in seconds since January 1, 2001), the An owner requests reported location from Apple’s
ephemeral public key d0 , the encrypted message, and the servers when searching for a lost device. As the adver-
AES-GCM authentication tag as shown in Fig. 2. tisement keys are synchronized across all of the owner’s
Uploading Reports. Finder devices accumulate re- devices, the owner can use any of their other devices
ports over time and upload them in batches regularly, with Apple’s Find My app to download and decrypt
possibly reducing energy and bandwidth consumption. the location reports. In short, the owner device fetches
During the evaluation with our test devices, we dis- location reports from Apple’s servers by sending a list
covered that the median time from generating to up- of the most recent public advertisement keys of the lost
loading a location report is 26 min. We include the de- device.
lay distribution in Appendix B. The delay can increase Downloading Reports. Similar to upload-
to several hours if the finder device is in a low power ing (cf. § 6.4), downloading is implemented as an
mode [7]. A finder limits the number of uploaded re- HTTPS POST request to https://gateway.icloud.com/
ports for the same advertisement key to four, most acsnservice/fetch. We show the headers in Tab. 4 and
likely to prevent excess traffic on Apple’s servers. The a truncated example body in Appendix A. The user
upload is implemented as an HTTPS POST request authenticates with Apple’s servers using their Apple
to https://gateway.icloud.com/acsnservice/submit. Ev- account in two steps. First, HTTP basic authenti-
ery request is authenticated to ensure that only gen- cation [41] is performed with a unique identifier of
uine Apple devices can upload requests. Table 3 shows the user’s Apple ID4 and a search-party-token that is
the request header containing a device identity certifi- device-specific and changes at irregular intervals (in
cate, the signing CA’s certificate, and an Elliptic Curve the order of weeks). Second, several headers with so-
Digital Signature Algorithm (ECDSA) signature over called “anisette data” are included. Anisette data are
the request body. The certificates are stored in the de- short-lived tokens valid for 30 s and allow omitting two-
vice’s keychain. However, the private key used for sign- factor authentication from a previously authenticated
ing is stored in the Secure Enclave Processor (SEP), system [2].
Apple’s implementation of a trusted execution environ- Decrypting Reports. The response to the down-
ment (TEE) [4]. The SEP prohibits the extraction of load request contains a list of finder location reports
the signing key but provides an interface for signing re- (cf. Fig. 2) and metadata such as the hashed public ad-
quests. We assume that the finder authentication serves vertisement key and the time when the report was up-
as a form of remote attestation. However, we were un- loaded. We show a truncated example of the response
able to verify this assumption due to the obfuscated body in Appendix A. Using the respective private ad-
code. The HTTPS request body is prefixed with a fixed vertisement keys di , the owner device can then decrypt
header (0x0F8AE0) and one byte specifying the number the received location reports. Apple’s Find My applica-
of included reports. This limits the number of reports tion combines a subset of the reports to display the most
in a single request to 255. Each report consists the ID
(SHA-256(pi )) followed by the 88-byte location report
shown in Fig. 2.
4 This numerical identifier is unique to each Apple account and
does not change even if the user changes their primary email
address.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 8

Table 4. HTTP request headers for downloading location reports.

Find My SPFinder CoreBluetooth

Request Header Value

Bluetooth
Authorization Base64 encoded basic authentication searchpartyd locationd bluetoothd
X-Apple-I-MD Anisette data
X-Apple-I-MD-RINFO Anisette data
X-Apple-I-MD-M Anisette data IOBluetooth
X-Apple-I-TimeZone Client’s time zone iCloud SPOwner
Family
X-Apple-I-ClientTime Client’s time (ISO 8601)
X-BA-CLIENT-TIMESTAMP Client’s time (Unix)
Fig. 3. Simplified view of components and their interactions such
User-Agent “searchpartyd/1
as apps ( ), daemons ( ), frameworks ( ), and drivers ( ) that
<iPhoneModel>/<OSVersion>”
are used by OF on iOS. We highlight the two involved external
communication interfaces in blue.

recent location of the lost device on a map. According to

Apple, multiple reports are combined to get a more ac- vide empirical evidence on the quality of OF location
curate location [4, p. 104]. While we did not reconstruct reports when retrieving lost devices.
Apple’s algorithm, we show in § 7 that the downloaded Apple’s Find My application combines multiple lo-
location reports are sufficient to not only determine the cation reports to improve accuracy when displaying a lo-
most recent location but to even precisely reconstruct cation on a map [4]. It does not show the seven-day his-
and trace the movement of a lost device. tory of location reports that can be available on Apple’s
servers. In this section, we assess the location report ac-
6.5 System Implementation curacy by using this historical location data. To this
end, we use the same PoC implementation presented
Apple’s OF system is implemented across several dae-
in § 10 to access the raw location reports for our own
mons and frameworks which communicate via XPC,
devices. We conduct two sets of experiments in this sec-
Apple’s implementation of interprocess communica-
tion. First, we evaluate the accuracy of OF reports for
tion [12]. We depict the dependencies of the iOS imple-
mobility tracking. Second, we use the seven-day loca-
mentation in Fig. 3. The main daemon that handles OF
tion data history to profile a user’s most visited or “top”
is searchpartyd, which runs with root privileges. It gen-
locations—which can be abused for user identification.
erates the necessary keys and performs all cryptographic
We open-source all data and evaluation tools forming
operations. The daemon is also responsible for commu-
this section to make our results reproducible (cf. Avail-
nicating with Apple’s servers to synchronize keys, sub-
ability section).
mit location reports as a finder device, and fetch loca-
A Note on Geographic Coordinates. Throughout
tion reports as an owner device. The bluetoothd daemon
this section, we deal with geographic coordinates, their
is responsible for sending and receiving OF advertise-
distances, and their projections. In order to produce
ments and passes received advertisements to locationd.
meaningful results, we need to use coordinates in the
The locationd daemon adds the device’s current location
same reference system. All locations in this paper are
and forwards this information to searchpartyd, which
latitude and longitude coordinates in the World Geode-
generates the finder reports. On macOS, some function-
tic System 1984 (WGS 84) [24], which is also used by
ality of searchpartyd such as the server communication
GPS. We apply the EPSG:3857 projection [25] to visu-
is externalized to the searchpartyuseragent daemon to
alize coordinates on a map (e.g., Fig. 4). When we cal-
support the multi-user architecture that is not available
culate the distance between two locations, we use the
on iOS.
length of a geodesic, i.e., the shortest path between two
points on the surface of the ellipsoidal earth [34].
7 Location Report Accuracy
We experimentally assess the accuracy of OF location 7.1 Path Tracking
reports submitted by finder devices. This serves two We compare reported OF locations with GPS traces
purposes. (1) From an attacker’s perspective, we can that we record with the tracked device. We conduct ex-
determine the severity of the discovered vulnerability al- periments with different means of transportations in and
lowing unauthorized access to location history described around a metropolitan area. We measure the error of the
in § 10. (2) From an end-user’s perspective, we can pro-
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 9

Table 5. Evaluation scenarios including distance traveled and

duration of recorded GPS traces, and the number of downloaded
OF location reports.

Scenario Distance (m) Duration (h:m:s) No. OF reports

Walking 3375 0:55:11 489

Restaurant 160 0:42:29 185
Train 23237 0:35:30 166
Car 94569 1:04:22 25
GPS trace
Estimated OF path
raw OF reports to the GPS trace and show that we can Raw OF reports

significantly improve accuracy by applying a scatterplot

smoothing algorithm to the raw reports. Fig. 4. Map of the walking scenario showing the GPS trace, the
raw OF location reports, and the estimated path calculated from
the reports.
7.1.1 Experimental Setup
We conduct experiments in different scenarios that at- Table 6. Accuracy of OF location reports.
tempt to emulate common mobility patterns: walking,
driving a car, riding a train, and visiting a restaurant. Mean distance to GPS trace (m) Improvement
All experiments were conducted in and around the city Scenario Reported Raw Est. Path Raw→Est. Path
of Frankfurt am Main, Germany. For each scenario, we
Walking 121.9 81.4 25.9 3.1×
record a GPS trace that serves as the ground truth for Restaurant 117.2 60.2 27.4 2.2×
our evaluation.5 Train 171.0 440.7 299.6 1.5×
Table 5 summarizes the evaluated scenarios with Car 145.2 580.7 — —
the time and distance traveled according to the GPS
trace and the number of uploaded OF reports during
these times. Our test devices are an iPhone 8 running 7.1.2 Raw Location Report Accuracy
iOS 13.5 and a MacBook Pro running macOS 10.15.4 We calculate the distance of the OF reports to the GPS
that are logged into the same iCloud account. During trace. As GPS trace and OF reports do not have a com-
each experiment, we carry the iPhone in flight mode to mon time index, we interpolate the GPS trace to the
emit OF advertisements and record the GPS trace us- time indices of the OF reports. Then, we calculate the
ing the SensorLog [49] application set to a 2 s sampling distance of each OF report to the corresponding point
interval. The MacBook acts as the owner device that on the interpolated GPS trace. Table 6 shows the mean
we use to download location reports after each experi- error of the raw reports. We can see that raw reports
ment. We did not carry any other Apple devices during have a mean error in the order of 100 m for the walking
an experiment, so we would not get additional reports. and restaurant scenarios. However, results become less
Consequently, all downloaded reports were submitted accurate when using faster modes of transportations,
by the devices of pedestrians. To access the private ad- e.g., 500 m when riding a train. Table 6 also shows the
vertising keys for downloading and decrypting location reported accuracy value, which is part of the OF reports
reports, we use our PoC implementation (cf. § 10). We (cf. § 6.3), and the improved results of the estimated
use the OF reports’ generation timestamps to filter the path that we will discuss next.
reports that lie between the start and end date of each
GPS trace. 7.1.3 Estimated Path Accuracy
The raw location reports provide a decent accuracy suf-
ficient to pinpoint an individual’s location to a city dis-
5 The experiments were conducted during the COVID-19 pan- trict or even a street. However, when plotting the lo-
demic. Consequently, the authors implemented anti-infection
cations on a map (cf. Fig. 4), we see that simply “con-
measures, i.e., they wore face masks, used hand sanitizer while
traveling with public transport and exercised minimum phys- necting the dots” does not yield a smooth path that we
ical distancing. At the time of the experiments, the local inci- would expect from a human mobility trace. We won-
dence rate was low (five cases per 100 000 inhabitants over seven dered if we could improve accuracy by harnessing and
days) [32].
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 10

combining all finders’ reports. Essentially, we want to top locations and even achieve an accuracy of up to
provide a better estimate of the actual path by fitting a 5 m.
curve through the reported OF locations.
To this end, we apply a popular curve fitting 7.2.1 Experimental Setup
method called locally weighted scatterplot smoothing To determine the top locations, we want to use the same
(LOWESS) [22] independently to the longitude and lat- seven-day historic data available as an attacker getting
itude coordinates of the location reports. LOWESS per- access to the OF report decryption keys (cf. § 10). Col-
forms a weighted local (or moving) regression over a lecting this data from various test subjects for an eval-
window of nearby data points. A Gaussian distribution uation would be extremely intrusive to their privacy.
assigns a higher weight to the data points in the cen- Running our evaluation algorithm on the subjects’ Macs
ter of the window. The size of the window heavily in- would also not be feasible, because the subjects would
fluences the performance of LOWESS. Empirically, we have to disable macOS’s SIP to download raw OF loca-
found that a value of 30 reports provides the most ac- tion reports, effectively weakening their system security.
curate results for our traces. Sensibly, our ethical review board (ERB) would not ap-
Fig. 4 shows such an estimated path calculated from prove such a study. Consequently, we abstain from con-
the walking scenario. The figure shows that our path ducting a user study and, instead, use our (the authors’)
estimation algorithm approximates the real path rather data for the evaluation. To preserve the authors’ privacy,
well. We quantify the accuracy of the estimated path we will not show or discuss the raw data. Instead, we
by calculating the mean distance to the GPS track and apply our algorithm for identifying top locations on the
show the results in Tab. 6. Most OF locations were raw data and then discuss the output.
reported in busy places in a metropolitan city (walk-
ing and restaurant visit). Here, our fitting algorithm 7.2.2 Resampling and Clustering OF Reports
approximated the real path with a mean error below
Previous works [38, 52] have used identifiers of cell sites
30 m—a 3.1× improvement over the raw data. Our fit-
to rank top locations. For a particular user, they sim-
ting algorithm is unable to produce meaningful results
ply count the number of registrations per cell and base
for the car experiment as the sample set is too sparse.
the location rank on this number. E.g., the cell with the
For completeness, we include maps of the restaurant,
highest registration count is regarded as the top 1 loca-
train, and car scenario in Appendix C.
tion. We cannot apply the same concept for identifying
Overall, using a fitting algorithm helps to recon-
top locations based on OF reports for two reasons.
struct the user’s path from noisy OF reports if the
Problem 1: Non-Uniform Distribution Over Time.
dataset is dense enough. In the best case, we improved
We observed that the density of OF reports over time is
the accuracy compared to the raw location reports by a
non-uniform. In busy places such as malls or restau-
factor of 3.1×.
rants, more finder devices are available and, conse-
7.2 Identifying Top Locations quently, more reports are generated. If we simply count
the number of OF reports to determine the top loca-
Apple’s servers store OF reports for seven days, which tions, these busy places are likely to be overrepresented.
can be accessed by an unauthorized third-party appli- Instead, we want to rank top locations based on the
cation (cf. § 10). Previous work has shown that the top overall visit duration of the user.
(most visited) locations can be used for user fingerprint- Problem 2: Continuous Coordinate Range. Cell
ing. Montjoye et al. [38] demonstrated that four spatio- identifiers are elements of a discrete set. In contrast,
temporal points are sufficient to identify 95 % of all in- the location coordinates in OF reports are drawn from
dividuals in an anonymized location dataset. Also, Zang a continuous range, which makes simple counting of vis-
and Bolot [52] found that the three top locations on a its per location hard. To address both issues, we use a
mobile cell-level are accurate enough to identify 50 % of two-step approach.
all individuals in a large data set. Even though most Solution 1: Resampling. We resample the location
devices try to keep a permanent connection to the In- reports on the time axis to solve Problem 1 and “flat-
ternet, our analysis has shown that hundreds of reports ten” the distribution over time. Within each resampling
have been generated throughout a week. This section interval R, we calculate the center coordinates as the
shows that OF reports can also be used to determine mean of all reports within that interval. Setting a rea-
sonable value R is essential. If R is too small, the desired
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 11

Table 7. Identified top locations sorted by their rank. Error in-

Home
dicates the geodesic distance between the ground truth and the

Top Location
Office
estimated cluster center. Days indicate on how many days of the
Partner
week the location was visted. Dwell time is the estimated overall
Friends
time that the location was visited.
Sport
Family
Kind Rank Error Resampled Days Dwell time
reports (hour:min) 0 5 10 15 20
Hour of day
Home 1 14.1 m 129 6 43:00
Work 2 4.9 m 25 2 08:20 Fig. 5. Visiting times distribution of top locations averaged over
Partner 3 15.5 m 19 2 06:20 seven days. Darker colors indicate a higher number of location
Friends 4 11.1 m 15 1 05:00 reports during these hours.
Sport 5 9.5 m 9 3 03:00
Family 6 6.6 m 9 2 03:00
the characteristics of the location reports. To this end,
we provide a detailed view of the visiting times across
flattening effect will not occur. If R is too large, we lose the hours of a day in Fig. 5. The figure shows the hours
accuracy. Empirically, we found that R = 20 min pro- of a day in which location reports were submitted for
duces good results for our dataset. the respective top location. We can visually identify the
Solution 2: Clustering. We use a clustering algo- type of some locations from this distribution. In partic-
rithm to identify places for which we received multiple ular, the workplace distribution matches typical office
location reports over time to solve Problem 2. In partic- hours (8 am to 5 pm). The all-day distribution of the
ular, we select the popular Density-Based Spatial Clus- home location reflects the fact that the measurements
tering of Applications with Noise (DBSCAN) [26, 43] were taken over the course of a week and the author
algorithm. DBSCAN can detect an arbitrary number of stayed at home on some days for remote work.
clusters, which is important for us as we do not know Previous work showed that four spatio-temporal
the number of top locations a priori. Also, DBSCAN points could be sufficient to uniquely identify an in-
adequately deals with noise, which is common in OF dividual with a chance of 95 % [38]. While we were
reports. In short, DBSCAN forms clusters by finding unable to conduct a similar large-scale user study as
“core samples” that have at least N neighbors within in [38] based on OF, our small-scale experiment already
a radius of D. All samples that are not part of a clus- demonstrates that OF reports contain highly sensitive
ter are considered as noise. Empirically, we determined information that can be used to deanonymize users.
that D = 50 m and N = 6 produces good results for our
dataset. 8 Security and Privacy Analysis
7.2.3 Results In this section, we perform a security and privacy anal-
ysis of Apple’s OF system implemented on iOS and
We run our resampling and clustering algorithms on an
macOS based on the adversary models described in
author dataset. Together, the algorithms determine a
§ 4. We first examine the cryptography-related compo-
list of six clusters that we interpret as top locations. Af-
nents that are relevant for the local application (A1)
terwards, we let the author label each entry and assign
and service operator (A4) models that have access to
the actual location of the home or office by picking co-
keys and encrypted reports, respectively. Then, we as-
ordinates from an online map service, which we use as
sess the BLE interface relevant to the proximity-based
ground truth. Finally, we compute the distance of the
adversary (A2) and the HTTPS-based server commu-
clusters’ centers to the ground truth locations and show
nication relevant for the network-based adversary (A3).
the complete results in Tab. 7. The results demonstrate
We summarize our findings in Tab. 8 and discuss in the
that we successfully identified typical locations such as
following.
home and workplace [52] with an error below 20 m. Im-
pressively, the location reports were precise enough to
8.1 Cryptography
pinpoint not only the workplace but with a 5 m error
even identify the exact office. Key Diversification. OF employs key diversification
We wondered if it would have been possible to dis- to derive the rolling advertisement keys from the mas-
cern the type of location (e.g., home or work) just from ter beacon key (cf. § 6.1). Apple’s design follows the
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 12

Table 8. Summary of our security and privacy analysis of OF. We list potential issues and provide a short assessment about whether or
not they are exploitable in practice (3or 7) and if 3, by which adversary model (cf. § 4).

Component Potential issue Exploit. Assessment

Cryptography Key diversification 7 The custom key diversification process follows the NIST recommendation for key
derivation through extraction-then-expansion [16].
Choice of P-224 curve 7 Use of NIST P-224 is discouraged by some cryptographers [18]. However, we are
unaware of any practical attacks against P-224 when used exclusively for ECDH.
Insecure key storage 3 (A1) Keychains and SEP are used to securely store keys for server communication and
the master beacon key. However, macOS caches the derived advertisement keys on
disk, which can be read by local applications. Attackers can exploit this to access
(historical) geolocation data as we describe in § 10.

Bluetooth Device tracking via 7 BLE payload and address are determined by the advertisement key, which is changed
BLE advertisements at 15 min intervals, making long-term tracking hard.
Remote code execu- 7 As OF uses non-connectable mode to emit advertisements, devices remain secure
tion (RCE) against RCE attacks on the Bluetooth firmware [42].
Denial-of-service 3 (A2) An attacker could emit/relay legitimate advertisements at other physical locations
(DoS) to pollute the set of location reports.
Server comm. Spoofing (finder) 7 Impact similar to Bluetooth relaying. However, we have been unable to inject fabri-
cated location reports into the server communication.
Spoofing (owner) 7 Spoofing an owner device is not critical as location reports are end-to-end encrypted.
Device identification 3 (A4) Apple’s servers can identify both finder and owner devices. This enables a location
correlation attack that we discuss in § 9.

NIST recommendation of performing extraction-then- 8.2 Bluetooth

expansion [16] to securely derive keys. The two-step pro-
Device Tracking. One of the key design goals of OF
cess first extracts a derivation key from a secure input
is to prevent tracking of lost devices via their BLE ad-
and then expands this key to the desired output length.
vertisements. According to our analysis, OF fulfills this
Specifically, OF first extracts a new 32-byte key SKi
promise by randomizing both BLE advertisement ad-
from the previous derivation key using the KDF and
dress and payload in 15 min intervals (cf. § 6.2).
then expands SKi using the same KDF to 72 bytes.
Remote Code Execution. In addition, OF uses the
Choice of NIST P-224 Curve. We believe that Ap-
so-called “non-connectable mode” [19, Vol. 3, Part C,
ple’s choice for the NIST P-224 curve is the consequence
§ 9.3.2], which means that other devices cannot connect
of the constrained capacity of BLE advertisements while
to it and exploit potential remote code execution (RCE)
maximizing the security level of the encryption keys.
vulnerabilities in the Bluetooth firmware [42].
Apple’s implementation of P-224 in corecrypto has been
Denial-of-Service Through Relaying. BLE adver-
submitted to validate compliance with U.S. Federal In-
tisements only contain the public part of an advertise-
formation Processing Standards (FIPS) [9]. Within the
ment key and are not authenticated. Anyone recording
cryptography community, some researchers discourage
an advertisement can replay it at a different physical
the use of P-224 because its generation process is un-
location. Any finder at that location would generate a
clear [17, 18]. More modern curves with the same secu-
location report and submit it to Apple. Through this
rity margin are available, e.g., M-221 [13], but are not
type of relaying, an attacker could make a lost device ap-
used by Apple.
pear at a different location, effectively mounting a DoS
Insecure Key Storage. We analyzed how OF keys
attack as owners would receive different contradicting
and secrets are stored on the system. While most in-
location reports.
volved keys are synchronized and stored in the iCloud

8.3 Server Communication

keychain, we discovered that the advertisement keys de-
rived from the master beacon key (cf. § 6.1) are cached
on disk to avoid unnecessary re-computations. We found Spoofing. The communication with Apple’s servers uses
that the cached key directory is accessible by a local ap- TLS, including certificate pinning to ensure that no
plication with user privileges and can be used to bypass MitM attack can be deployed. Based on our analysis,
the system’s location API, as we describe in § 10. the protocol seems to implement a secure authentication
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 13

scheme. However, we have been unable to reconstruct

Advertise: p1
some of the involved components. We understand that a F ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− L1
device-specific certificate (cf. § 6.3) and a private signing Advertise: p2
F ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− L2
key, protected by the SEP, are involved in submitting
Upload: SHA(p1 ), Report , SHA(p2 ), Report
reports. We assume that this private key is used for F −−−−−−−−−−−−−−−−−−1−−−−−−−−−−−−−→
2
Apple
remote attestation to prevent non-Apple devices from Download: Apple ID , SHA(p1 )
1
submitting potentially fabricated reports. The genera- O1 −−−−−−−−−−−−−−−−−−−− −−−−−−−−−−−→ Apple
tion and registration process of these keys with Apple’s Download: Apple ID , SHA(p2 )
2
O2 −−−−−−−−−−−−−−−−−−−− −−−−−−−−−−−→ Apple
server remains unknown to us. Also, the “anisette data”
used for authenticating owner devices (cf. § 6.4) is not
Fig. 6. Apple could infer which users have been in close proximity
publicly documented, and the code that generates the
to each other.
tokens is highly obfuscated.
Device Identification. While we did not recover
the exact details of the authentication mechanism, we the same finder. Similarly, during the download process,
have observed that both finder and owner devices pro- the owner device has to reveal its Apple ID. In partic-
vide identifiable tokens to Apple’s servers. In particular, ular, the owner includes its Apple ID in the HTTPS
owner devices provide their Apple ID to access location request headers (cf. Tab. 4), which allows Apple to link
reports. In § 9, we show that by requesting IDs, Apple’s reports uploaded by a particular finder to the Apple ID
servers are—in principle—able to correlate the locations of the downloading owners. Since we do not have access
of different owners. to Apple’s servers, we cannot make assumptions about
whether or not Apple actually stores such metadata.
9 Apple Can Correlate User However, the fact that Apple could store this informa-
tion indefinitely opens the possibility of abuse.
Locations
Apple as the service provider (A4) could infer that two 9.2 Attack
or more owners have been in close proximity to each It is possible for Apple to find out which owners have
other as OF uses identifiable information in both up- been in physical proximity to each other if the owners
load and download requests. Law enforcement agencies request the location of their devices via the Find My ap-
could exploit this issue to deanonymize participants of plication. We sketch the attack for two owners in Fig. 6.
(political) demonstrations even when participants put A finder F receives advertisements from the lost devices
their phones in flight mode. Exploiting this design vul- L1 and L2 that belong to the owners O1 and O2 , respec-
nerability requires that the victims request the location tively, and publishes encrypted location reports to Ap-
of their devices via the Find My application.6 Next, we ple’s servers. Due to the limited communication range
describe the vulnerability, a possible attack, and our of BLE, we can reasonably assume that L1 and L2 have
proposed mitigation. been in close proximity if the respective location reports
were generated at a similar time and submitted by the
9.1 Vulnerability same finder. Later, O1 and O2 both download location
When uploading and downloading location reports, reports, by opening the Find My app, for L1 and L2 ,
finder and owner devices reveal their identity to Ap- respectively. At this point, Apple can infer that these
ple. During the upload process, the finder reveals a two owners identified by their Apple IDs were close to
device-specific identifier in the HTTPS request header each other.
(cf. Tab. 3) that can be used to link multiple reports to
9.3 Impact
The presented attack could be harmful to protesters
6 This requirement currently limits the exploitability of who put their phones into flight mode to stay anony-
the described vulnerability. However, exploitability could in- mous and prevent their devices from showing up during
crease when changing the usage pattern of the downloading a cell site analysis—which is precisely when the devices
API (cf. § 6.4). For example, a future Apple application could
would start emitting OF advertisements. Law enforce-
notify users about lost devices automatically by regularly re-
questing reports for the devices’ last known locations, thereby,
ment agencies could record all the advertised public keys
removing the need for user interaction. at the demonstration site and ask Apple to provide the
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 14

Apple IDs of the users that later requested location re- (1) Victim installs and runs malicious app
ports to deanonymize the participants. Such a collusion
(0) Victim has at least
would be a combination of the proximity-based (A2)
one other device linked
and service provider (A4) adversary models (cf. § 4). Private
to their iCloud account
iOS Read keys
9.4 Proposed Mitigation key app (3) App
extracts keys
There are two straightforward options to mitigate this
attack: remove identifying information from either (1) (3) Exfiltrate keys
Victim device (macOS)
finder devices or (2) owner devices. We assume that the to attacker device
authentication of the finder provides a form a remote (4) App queries
attestation proving that the device is—in fact—a gen- encrypted
Offline
uine Apple device allowed to upload location reports to location reports
finding
Apple’s servers. In that case, option (1) is not feasible as (5) Decrypt using Apple’s
app
the finder has to provide some verifiable information by location reports private offline
design. However, we currently see no reason why owner finding API
devices have to authenticate to Apple’s servers and pro- Attacker device Apple
vide personally identifiable information, i.e., the Apple (macOS, SIP disabled) server
ID. We found that any Apple device can request ar-
bitrary location reports, so the authentication appears Fig. 7. Attack flow for gaining access to the victim’s location
to be a security-by-obscurity measure and only prevents history. Attacker-controlled components are marked in red.

everyone without access to an Apple device from access-

ing location reports. Therefore, we recommend option disk in the directory /private/var/folders/<Random>
(2) as mitigation and disable authentication for down- /com.apple.icloud.searchpartyd/Keys/<DeviceId>
load requests. /Primary/<IdRange>.keys. The directory is readable
by the local user and—in extension—by any application
10 Unauthorized Access of that runs with user privileges. On iOS, those cache files

Location History
exist as well, but they are inaccessible for third-party
applications due to iOS’s sandboxing mechanism.
We discovered a vulnerability of the OF implementa-
tion on macOS that allows a malicious application (A1) 10.2 Attack
to effectively circumvent Apple’s restricted location
We describe the attack flow and explain our PoC imple-
API [5] and access the geolocation of all owner devices
mentation, which leads to the attacker gaining access
without user consent. Moreover, historical location re-
to the location history of the victim’s devices. In the
ports can be abused to generate a unique mobility pro-
following, we detail the operation of our two-part PoC
file and identify the user, as we demonstrate in § 7.
attack. The steps are referring to Fig. 7.
Reading Private Keys (Steps 1–3). The victim
10.1 Vulnerability
installs a non-sandboxed malicious application.7 When
§ 6 describes that the location privacy of lost devices started, the malicious application runs with user priv-
is based on the assumption that the private part of ileges and, therefore, has access to the key cache di-
the advertisement keys is only known to the owner de- rectory. It can read the advertisement keys from disk
vices. The advertisement keys change every 15 minutes (2) and then exfiltrate them to the attacker’s server
and OF supports retrieving location reports from the (3). Apart from starting the application, this process
last seven days, so there is a total of 672 advertise- requires no user interaction, i.e., no dialogs requesting
ment keys per device, for which there exist potential disk access are displayed to the user.
location reports on Apple’s servers. In principle, all of
these keys could be generated from the master beacon
key (cf. § 6.1) whenever needed. However, Apple de-
7 Sandboxing is only required for applications distributed via
cided to cache the advertisement keys, most likely for Apple’s app store. Many popular macOS applications such as
performance reasons. During our reverse engineering ef- Firefox or Zoom are not distributed via the app store and, thus,
forts, we found that macOS stores these cached keys on could have exploited the discovered vulnerability.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 15

Downloading Location Reports (Step 4). The at- tion (2), which moved the keys to a new directory that
tacker’s machine essentially acts as an owner device is protected via the system’s sandboxing mechanism.
(cf. § 6.4) but uses the victim’s keys as input for the
HTTPS download request. To download the victim’s lo- 11 Related Work
cation reports, our PoC needs to access the attacker’s
anisette data for authenticating the request to Apple’s We review other crowd-sourced location tracking sys-
servers. As we need to link private frameworks and ac- tems and previous security and privacy analyses of Ap-
cess the anisette data in our implementation, the at- ple’s ecosystem.
tacker’s macOS system needs to disable SIP and Ap- Crowd-Sourced Location Tracking. Weller et al.
ple mobile file integrity (AMFI). Since this device is [51] have studied the security and privacy of commer-
attacker-owned, this requirement does not limit the ap- cial Bluetooth tags (similar to Apple’s definition of ac-
plicability of the presented attack. SIP and AMFI are cessories) sold by multiple vendors. Many of the studied
disabled by booting in the macOS recovery mode and systems provide crowd-sourced location tracking similar
running the following terminal commands. to Apple’s OF, allowing users to discover lost devices by
leveraging the finder capabilities of other devices. The
csrutil disable
study discovered several design and implementation is-
nvram boot - args =" a m f i _ g e t _ o u t _ o f _ m y _ w a y =1"
sues, including but not limited to the use of plaintext lo-
Decrypting Location Reports (Step 5). In the fi- cation reports, unauthorized access to location reports,
nal step, the adversary uses the victim’s private keys to broken TLS implementations, and leaking user data.
decrypt the location reports. Based on their findings, Weller et al. [51] propose a novel
privacy-preserving crowd-sourced location tracking sys-
10.3 Impact tem called PrivateFind. PrivateFind does not need user
The attack essentially allows any third-party applica- accounts and uses end-to-end encrypted location reports
tion to bypass Apple’s Core Location API [5] that en- with a symmetric encryption key stored on the Blue-
forces user consent before an application can access the tooth finder during the initial setup. In their solution,
device’s location. Moreover, the attacker can access the a finder that discovers a lost Bluetooth tag sends its
location history of the past seven days of all the owner’s geolocation to the finder over Bluetooth. The lost de-
devices. The victim is only required to download and vice encrypts the location with its symmetric key and
run the application but remains otherwise clueless about returns the encrypted report. The finder then uploads
the breach. Our analysis has shown that the advertise- the encrypted location report on behalf of the tag. An
ment keys are precomputed for up to nine weeks into the owner device that knows the symmetric key can then
future, which allows an adversary to continue download- download and decrypt the location report.
ing new reports even after the victim has uninstalled the To the best of our knowledge, PrivateFind is the
malicious application. only other privacy-friendly offline device finding system
Even though the location reports are not continu- next to OF. Both designs achieve similar privacy goals,
ous, our evaluation in § 7 shows that it is easy to identify such as preventing a third party from learning the loca-
the user’s most visited places such as home and work- tion. The main difference is the way encrypted location
place. Furthermore, we show that the decrypted location reports are generated. OF employs public-key cryptog-
reports can accurately track the victim’s movement of raphy, which allows finder devices to generate a loca-
the last seven days. tion report upon receiving a single Bluetooth advertise-
ment. In PrivateFind, lost devices are actively involved
10.4 Mitigation in the generation, which leads to the following prac-
tical issues: (1) Lost devices or tags drain their bat-
As a short-term mitigation, users can disable participat- teries quicker as they have to establish Bluetooth con-
ing in the OF network to prevent the attack. In addi- nections with other devices and perform cryptographic
tion, we propose three long-term solutions to mitigate operations. This opens up the door for resource-exhaus-
the attack: (1) encrypting all cached files on disk store tion attacks where a powerful adversary issues an exces-
the decryption key in the keychain, (2) restricting access sive number of encryption requests to the lost devices.
to the cache directory via access control lists, (3) not (2) The lack of finder attestation would allow an at-
caching the keys and computing them on-demand. In tacker to upload fabricated reports as the lost device
fact, macOS 10.15.7 includes a mitigation based on op- cannot verify the correctness of the provided location.
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 16

Apple’s Wireless Ecosystem Security and Privacy. leveraging the historical reports, an attacker is able to
Previous work analyzed parts of Apple’s wireless ser- identify the user’s most visited location with sub-20 m
vices. Bai et al. [15] investigated the risks of using inse- accuracy. Secondly, we believe that Apple has yet to
cure multicast DNS (mDNS) service advertisements and provide a good reason why owner devices need to au-
showed that they have been able to spoof an AirDrop thenticate when retrieving encrypted location reports
receiver identity to get unauthorized access to personal as it allows Apple to correlate the locations of different
files. Stute, Kreitschmann, and Hollick [46] and Stute Apple users.
et al. [48] reverse engineered the complete AWDL and We were only able to publish our findings by inten-
AirDrop protocols and demonstrated several attacks, sively studying the OF system using reverse engineering,
including user tracking via AWDL, a DoS attack on which is a very time-consuming process (we started ana-
AWDL, and a MitM attack on AirDrop. Martin et al. lyzing OF mid-2019). To protect user privacy, we believe
[36] extensively analyzed the content of the BLE adver- that systems handling highly sensitive information such
tisements for several Apple services. They found sev- as OF need to be openly and fully specified to facilitate
eral privacy-compromising issues, including device fin- timely independent analyses. To this end, we urge man-
gerprinting and long-term device and activity tracking. ufacturers to provide not only partial [6] but complete
Celosia and Cunche [21] extended this work and discov- documentation of their systems and release components
ered new ways of tracking BLE devices such as Apple as open-source software whenever possible, which is al-
AirPods and demonstrated how to recover user email ready a best practice for cryptographic libraries [9].
addresses and phone numbers from BLE advertisements
sent by Apple’s Wi-Fi Password Sharing (PWS). Hein- Responsible Disclosure
rich et al. [30] found that AirDrop also leaks user phone
numbers and email addresses and proposes a new pro- We disclosed the vulnerability in § 10 on July 2,
tocol based on private set intersection. Stute et al. [45] 2020. On October 5, 2020, Apple informed us that
investigated the protocols involved in PWS and Apple’s macOS 10.15.7 provides a mitigation for the issue, which
Handoff and found vulnerabilities allowing device track- was assigned CVE-2020-9986. In addition, we informed
ing via Handoff advertisements, a MitM attack on PWS, Apple about the vulnerability in § 9 on October 16,
and DoS attacks on both services. While the above 2020, and are currently waiting for feedback.
works have analyzed other services, we leveraged their
methodology for approaching our analysis and reverse Availability
engineering work of OF.
We release the following open-source software artifacts

12 Conclusion
as part of the Open Wireless Link project [47]: (1) The
PoC implementation that can download and decrypt
Apple has turned its mobile ecosystem into a massive location reports, which we used for the exploit de-
crowd-sourced location tracking system called OF. In scribed in § 10 (github.com/seemoo-lab/openhaystack).
this system, all iPhones act as so-called finder devices (2) The experimental raw data and evalua-
that report the location of lost devices to their respec- tion scripts to reproduce the results in § 7
tive owners. Apple claims to implement OF in a privacy- (github.com/seemoo-lab/offline-finding-evaluation).
preserving manner. In particular, location reports are
inaccessible to Apple, finder identities are concealed, Acknowledgments
and BLE advertisements cannot be used to track the
We thank our anonymous reviewers and our shepherd
owner [35]. We have been the first to challenge these
Santiago Torres-Arias for their invaluable feedback. We
claims and provide a comprehensive security and pri-
thank Fontawesome for the vector graphics and Stamen
vacy analysis of OF.
for the map tiles used in our figures. This work has been
The good news is that we were unable to falsify
funded by the LOEWE initiative (Hesse, Germany)
Apple’s specific claims. However, we have found that
within the emergenCITY center and by the German
OF provides a critical attack surface that seems to have
Federal Ministry of Education and Research and the
been outside of Apple’s threat model. Firstly, the OF
Hessen State Ministry for Higher Education, Research
implementation on macOS allows a malicious appli-
and the Arts within their joint support of the National
cation to effectively bypass Apple’s location API and
Research Center for Applied Cybersecurity ATHENE.
retrieve the user’s location without their consent. By
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 17

References [19] Bluetooth SIG. Bluetooth Core Specification Version 5.2.

Tech. rep. 2019.
[1] Oleg Afonin. Extracting and Decrypting iOS Keychain: Phys- [20] Daniel R. L. Brown. Standards for Efficient Cryptography 1
ical, Logical and Cloud Options Explored. Elcomsoft Co. (SEC 1). 2009.
Ltd. 2020. url: https : / / blog . elcomsoft . com / 2020 / 08 / [21] Guillaume Celosia and Mathieu Cunche. “Discontinued Pri-
extracting - and - decrypting - ios - keychain - physical - logical - vacy: Personal Data Leaks in Apple Bluetooth-Low-Energy
and-cloud-options-explored/ (visited on 02/08/2021). Continuity Protocols.” In: Privacy Enhancing Technologies
[2] Oleg Afonin. iCloud Authentication Tokens Inside Out. El- (2020). doi: 10.2478/popets-2020-0003.
comsoft Co. Ltd. 2017. url: https://blog.elcomsoft.com/ [22] William S. Cleveland and Susan J. Devlin. “Locally Weighted
2017/11/icloud- authentication- tokens- inside- out (visited Regression: An Approach to Regression Analysis by Local
on 09/03/2020). Fitting.” In: Journal of the American Statistical Association
[3] Apple Inc. App Review. url: https://developer.apple.com/ 83.403 (1988). doi: 10.1080/01621459.1988.10478639.
app-store/review/ (visited on 02/09/2021). [23] Quang Do, Ben Martini, and Kim-Kwang Raymond Choo.
[4] Apple Inc. Apple Platform Security. 2020. url: https : / / “The Role of the Adversary Model in Applied Security Re-
support.apple.com/guide/security/ (visited on 10/10/2020). search.” In: Computers & Security 81 (2019). doi: 10.1016/
[5] Apple Inc. Core Location. url: https : / / developer . apple . j.cose.2018.12.002.
com/documentation/corelocation/ (visited on 10/10/2020). [24] EPSG Geodetic Parameter Dataset. WGS 84 (EPSG:4326).
[6] Apple Inc. Find My Network Accessory Specification. Ver- url: https://epsg.org/crs_4326/WGS-84.html (visited on
sion Release R1. 2020. url: https://developer.apple.com/ 10/13/2020).
find-my/. [25] EPSG Geodetic Parameter Dataset. WGS 84 / Pseudo-
[7] Apple Inc. Maximizing Battery Life and Lifespan. 2020. Mercator (EPSG:3857). url: https://epsg.org/crs_3857/
url: https : / / www . apple . com / batteries / maximizing - WGS-84-Pseudo-Mercator.html (visited on 10/13/2020).
performance/ (visited on 10/07/2020). [26] Martin Ester, Hans-Peter Kriegel, Jörg Sander, and Xiaowei
[8] Apple Inc. Notarizing macOS Software Before Distribution. Xu. “A Density-Based Algorithm for Discovering Clusters in
url: https://developer.apple.com/documentation/xcode/ Large Spatial Databases with Noise.” In: International Con-
notarizing_macos_software_before_distribution (visited on ference on Knowledge Discovery and Data Mining. KDD-96.
11/24/2020). AAAI Press, 1996. url: http : / / www . aaai . org / Library /
[9] Apple Inc. Security. url: https : / / developer . apple . com / KDD/1996/kdd96-037.php.
security/ (visited on 09/16/2020). [27] George Garside. Show Private Log Messages in Catalina’s
[10] Apple Inc. WWDC 2019 Keynote. 2019. url: https : / / Console.app. 2020. url: https://georgegarside.com/blog/
developer.apple.com/videos/play/wwdc2019/101/ (visited macos/sierra-console-private/ (visited on 09/15/2020).
on 08/17/2020). [28] Matthew Green. How does Apple (privately) find your offline
[11] Apple Inc. WWDC 2020 Keynote. 2020. url: https : / / devices? 2019. url: https://blog.cryptographyengineering.
developer.apple.com/videos/play/wwdc2020/101/ (visited com / 2019 / 06 / 05 / how - does - apple - privately - find - your -
on 08/17/2020). offline-devices/ (visited on 09/17/2020).
[12] Apple Inc. XPC. url: https : / / developer . apple . com / [29] Andy Greenberg. The Clever Cryptography Behind Apple’s
documentation/xpc (visited on 09/03/2020). ’Find My’ Feature. 2019. url: https : / / www . wired . com /
[13] Diego F. Aranha, Paulo S. L. M. Barreto, Geovandro C. C. F. story / apple - find - my - cryptography - bluetooth/ (visited on
Pereira, and Jefferson E. Ricardini. “A Note on High- 09/17/2020).
Security General-Purpose Elliptic Curves.” In: Cryptology [30] Alexander Heinrich, Matthias Hollick, Thomas Schneider,
ePrint Archive (2013). url: https://eprint.iacr.org/2013/ Milan Stute, and Christian Weinert. “PrivateDrop: Practi-
647. cal Privacy-Preserving Authentication for Apple AirDrop.”
[14] Ethan Arbuckle. Unredacting Private os_log Messages on In: USENIX Security Symposium. To appear. USENIX Asso-
iOS. 2018. url: https : / / github . com / EthanArbuckle / ciation, 2021.
unredact-private-os_logs (visited on 02/10/2021). [31] Alexander Heinrich, Milan Stute, and Matthias Hollick.
[15] Xiaolong Bai, Luyi Xing, Nan Zhang, Xiaofeng Wang, Xi- “BTLEmap: Nmap for Bluetooth Low Energy.” In: Confer-
aojing Liao, Tongxin Li, and Shi-Min Hu. “Staying Secure ence on Security and Privacy in Wireless and Mobile Net-
and Unprepared: Understanding and Mitigating the Security works. ACM, 2020. doi: 10.1145/3395351.3401796.
Risks of Apple ZeroConf.” In: IEEE Symposium on Security [32] Hessisches Landesprüfungs- und Untersuchungsamt im
and Privacy (S&P). 2016. doi: 10.1109/SP.2016.45. Gesundheitswesen. Bulletin Stand 29.07.2020, 14 Uhr. 2020.
[16] Elaine Barker, Lily Chen, and Richard Davis. Recommen- url: https : / / soziales . hessen . de / sites / default / files /
dation for Key-Derivation Methods in Key-Establishment media/2020_ 07_ 29_ bulletin_ coronavirus.pdf (visited on
Schemes. Special Publication 800-56C Rev. 1. 2018. doi: 11/24/2020).
10.6028/nist.sp.800-56cr1. [33] American National Standards Institute. ANSI X.963 Public-
[17] Daniel J. Bernstein. “Curve25519: New Diffie-Hellman Speed Key Cryptography for the Financial Services Industry: Key
Records.” In: Public Key Cryptography - PKC 2006. Springer Agreement and Key Transport Using Elliptic Curve Cryptog-
Berlin Heidelberg, 2006. doi: 10.1007/11745853_14. raphy. Tech. rep. 2001.
[18] Daniel J. Bernstein and Tanja Lange. SafeCurves: Choos- [34] Charles F. F. Karney. “Algorithms for Geodesics.” In: Journal
ing Safe Curves for Elliptic-Curve Cryptography. 2020. url: of Geodesy 87 (2013). doi: 10.1007/s00190-012-0578-z.
https://safecurves.cr.yp.to (visited on 10/07/2020).
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 18

[35] Ivan Krstić. “Behind the Scenes of iOS and Mac Secu- [50] Nghia Tran and Hang Nguyen. Proxyman. url: https : / /
rity.” In: Black Hat USA 2019. 2019. url: https : / / www . proxyman.io (visited on 09/15/2020).
youtube.com/watch?v=3byNNUReyvE&t=2398s (visited [51] Mira Weller, Jiska Classen, Fabian Ullrich, Denis Waßmann,
on 09/09/2020). and Erik Tews. “Lost and Found: Stopping Bluetooth Find-
[36] Jeremy Martin, Douglas Alpuche, Kristina Bodeman, Lam- ers from Leaking Private Information.” In: Conference on Se-
ont Brown, Ellis Fenske, Lucas Foppe, Travis Mayberry, Erik curity and Privacy in Wireless and Mobile Networks. ACM,
Rye, Brandon Sipes, and Sam Teplov. “Handoff All Your 2020. doi: 10.1145/3395351.3399422.
Privacy: A Review of Apple’s Bluetooth Low Energy Imple- [52] Hui Zang and Jean Bolot. “Anonymization of Location Data
mentation.” In: (2019). doi: 10.2478/popets-2019-0057. Does Not Work: A Large-Scale Measurement Study.” In: In-
[37] David A. McGrew, Kevin M. Igoe, and Margaret Salter. ternational Conference on Mobile Computing and Network-
Fundamental Elliptic Curve Cryptography Algorithms. RFC ing. ACM, 2011. doi: 10.1145/2030613.2030630.
6090. IETF, 2011. doi: 10.17487/RFC6090.
[38] Yves-Alexandre de Montjoye, César A. Hidalgo, Michel Ver-
leysen, and Vincent D. Blondel. “Unique in the Crowd: The A HTTP Body Content
Privacy Bounds of Human Mobility.” In: Scientific Reports
Listings 1 and 2 show the HTTP request and response
3.1 (2013). doi: 10.1038/srep01376.
[39] National Institute for Standards and Technology. Digital Sig- body for downloading location reports, respectively.
nature Standard. 186-2. 2000. url: http://csrc.nist.gov/
publications/fips/archive/fips186-2/fips186-2.pdf. Listing 1. Request body for downloading location reports.
[40] Ole André V. Ravnås. Frida: A World-Class Dynamic Instru- {
mentation Framework. 2020. url: https://frida.re (visited " search ": [
on 09/23/2020). {
[41] Julian F. Reschke. The ’Basic’ HTTP Authentication " endDate ": 1599052814928 ,
Scheme. RFC 7617. IETF, 2015. doi: 10.17487/RFC7617. " startDate ": 1598965514928 ,
[42] Jan Ruge, Jiska Classen, Francesco Gringoli, and Matthias " ids ": [
Hollick. “Frankenstein: Advanced Wireless Fuzzing to Exploit " tEJGn1j59g + mgj7cKhDMYN3UMNb8 ..." ,
New Bluetooth Escalation Targets.” In: USENIX Security " s r 7 4 j R o V k h X d s h f 0 Y 6 8 j 6 q G y W 6 8 v ..." ,
Symposium. USENIX Association, 2020. url: https://www. " p z c y P 8 d X f d S y V T H k 8 i o 7 A U g A x 8 5 J ..." ,
usenix.org/conference/usenixsecurity20/presentation/ruge. ... ]
[43] Erich Schubert, Jörg Sander, Martin Ester, Hans Peter } , ... ]
Kriegel, and Xiaowei Xu. “DBSCAN Revisited, Revisited: }
Why and How You Should (Still) Use DBSCAN.” In: ACM
Transactions on Database Systems 42.3 (2017). doi: 10 .
1145/3068335. Listing 2. Response body for downloading location reports.
[44] Milan Stute. “Availability by Design: Practical Denial-of- {
Service-Resilient Distributed Wireless Networks.” PhD thesis. " results ": [
2020. doi: 10.25534/tuprints-00011457. {
[45] Milan Stute, Alexander Heinrich, Jannik Lorenz, and " datePublished ": 1586804587284 ,
Matthias Hollick. “Disrupting Continuity of Apple’s Wireless " payload ": " JETtmwIEzRBG ...." ,
Ecosystem Security: New Tracking, DoS, and MitM Attacks " description ": " found " ,
on iOS and macOS Through Bluetooth Low Energy, AWDL, " id ": " B6E5tpUPbuudAc ..."
and Wi-Fi.” In: USENIX Security Symposium. To appear. " statusCode ": 0
USENIX Association, 2021. } , ... ] ,
[46] Milan Stute, David Kreitschmann, and Matthias Hollick. " statusCode ": "200"
“One Billion Apples’ Secret Sauce: Recipe for the Apple }
Wireless Direct Link Ad hoc Protocol.” In: International Con-
ference on Mobile Computing and Networking. ACM, 2018.

[47]
doi: 10.1145/3241539.3241566.
Milan Stute, David Kreitschmann, and Matthias Hollick. The
B Reporting Delay
Open Wireless Link Project. 2018. url: https://owlink.org. Fig. 8 shows the distribution of the reporting delays
[48] Milan Stute, Sashank Narain, Alex Mariotto, Alexander Hein- (time between uploading and generating a report) over
rich, David Kreitschmann, Guevara Noubir, and Matthias
all traces recorded for the experiments in § 7.1.
Hollick. “A Billion Open Interfaces for Eve and Mallory:
MitM, DoS, and Tracking Attacks on iOS and macOS
Through Apple Wireless Direct Link.” In: USENIX Security C Additional Experimental Traces
Symposium. USENIX Association, 2019. url: https://www.
usenix.org/conference/usenixsecurity19/presentation/stute. We show the reports of our restaurant, train, and car
[49] Bernd Thomas. SensorLog. 2020. url: https : / / apps . evaluation scenarios in Figs. 9 to 11, respectively.
apple . com / us / app / sensorlog / id388014573 (visited on
09/04/2020).
 Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System 19

1.0

0.5
CDF
Median: 26.3 min GPS trace
0.0
Estimated OF path
0 25 50 75 100 125 150 175
Raw OF reports
Publication delay (min)

Fig. 8. Reporting delays for all reports considered in § 7.1 as a Fig. 9. Map showing the GPS trace, the raw OF location reports,
cumulative distribution function. and the estimated paths for the restaurant scenario (cf. § 7.1).

Estimated OF path
Raw OF reports
GPS trace
Fig. 10. Map showing the GPS trace, the raw OF location reports, and the estimated paths for the train scenario (cf. § 7.1).

Raw OF reports
GPS trace

Fig. 11. Map showing the GPS trace and the raw OF location reports for the car scenario (cf. § 7.1).