Detailed Report on the Crowd-Sourced Device-Finding Workflow in arXiv:2103.02282

All section references below refer to the paper Who Can Find My Devices? Security and Privacy of Apple's Crowd-Sourced Bluetooth Location Tracking System.

1. Executive Summary

The paper reverse-engineers Apple's Offline Finding (OF) system and evaluates its security and privacy properties. Its main contribution is not a brand-new finder protocol, but a reconstruction of how Apple's crowd-sourced device-finding workflow operates in practice (see §1, §5, §6, and §8).

The paper does describe a concrete crowd-sourced device-finding workflow at the protocol level. In summary, devices enter a lost state, broadcast rolling Bluetooth Low Energy (BLE) public keys, nearby finder devices generate encrypted location reports, Apple stores those reports, and the owner later downloads and decrypts them (see §3 and §6). However, the authors explicitly state that they did not reconstruct Apple's internal algorithm for combining multiple reports into the final location displayed in Find My (see §6.4.2).

2. System Model and Roles

The system is organized around four roles (see §3):

  • Owner devices: devices associated with the same Apple ID; any of them can search for the others through Find My (see §3.0.0.1).
  • Lost devices: devices or accessories that start advertising once they lose Internet connectivity or BLE contact with the owner (see §3.0.0.2).
  • Finder devices: nearby Apple devices that scan for OF BLE advertisements, attach their current location, and upload encrypted reports (see §3.0.0.3).
  • Apple servers: storage and relay infrastructure for location reports; reports are intended to remain readable only by the owner (see §3.0.0.4).

The paper also highlights the role of iCloud and the Keychain. iCloud synchronizes key material across owner devices, while the Keychain stores secrets needed for decryption and authenticated communication (see §2.3, especially §2.3.0.1 and §2.3.0.2).

3. End-to-End Workflow of the Crowd-Sourced Finding Process

3.1 Initial Setup and Key Provisioning

The cryptographic basis of OF is introduced in §6.1. Each owner device initially generates a master beacon key, consisting of a NIST P-224 public/private key pair plus a 32-byte symmetric key (see §6.1.0.1). These master inputs are never broadcast directly.

From that master material, the system derives a sequence of rolling advertisement keys using ANSI X9.63 KDF with SHA-256 (see §6.1.0.1). This rolling-key design is central to the privacy model because consecutive BLE advertisements should be unlinkable to outside observers, while owner devices can still deterministically regenerate the same sequence (see §6.1.0.1 and §8.1.0.1).

To support report retrieval from any owner device, Apple synchronizes the master beacon keys via iCloud. The synchronized file is encrypted with AES-GCM, and the corresponding decryption key is stored in the iCloud Keychain under the label Beacon Store (see §6.1.0.2, with supporting context in §2.3.0.2).

3.2 Transition to Lost Mode and BLE Broadcasting

The operational workflow begins when a device becomes "lost." For Apple devices, this means losing Internet connectivity; for third-party accessories, it means losing BLE connectivity to the owner device (see §3.0.0.2).

Once in that state, the lost device starts broadcasting BLE advertisements that contain the public part of the current rolling advertisement key (see §3.0.0.2 and §6.2). Because BLE advertising space is limited, the paper explains in detail how Apple compresses the public key into the advertisement format and even reuses part of the BLE address field (see §6.2.0.1 and Table 2).

The same rolling key is broadcast for a 15-minute window, and advertisements are emitted every 2 seconds while the device remains offline (see §6.2.0.2). This timing affects discoverability, privacy, and energy cost.

3.3 Finder-Side Discovery and Report Generation

Finder devices form the crowd-sourcing layer of the system. They continuously scan for OF advertisements (see §3.0.0.3 and §6.3). When a finder receives an advertisement, it extracts the broadcast public key, determines its own current geolocation, and constructs a message that contains location, reported accuracy, and status information (see §6.3.0.1).

The encryption procedure is described in §6.1.0.3 and operationalized in §6.3.0.1. The finder:

  1. generates a fresh ephemeral P-224 key pair;
  2. performs ECDH with the lost device's advertised public key;
  3. derives a symmetric key and IV via ANSI X9.63 KDF with SHA-256;
  4. encrypts the location payload with AES-GCM.

The resulting location report contains the current timestamp, the finder's ephemeral public key, the ciphertext, and the AES-GCM authentication tag (see §6.3.0.1 and Fig. 2). Apple stores this report, but under the intended design it should not be able to decrypt the plaintext location because it lacks the owner's private advertisement keys (see §6.1.0.4 and §8).

3.4 Uploading Reports to Apple

After generating reports, finder devices do not necessarily upload each one immediately. The paper observes that uploads may be delayed and batched, likely to reduce power and bandwidth costs (see §6.3.0.2). It also notes that low-power mode can substantially increase the upload delay (see §6.3.0.2).

A finder uploads reports through an HTTPS POST request to Apple's submit endpoint (see §6.3.0.2). The request is authenticated with a device identity certificate, a CA hash, and an ECDSA signature. The signing key is protected by the Secure Enclave Processor, which suggests a remote-attestation-like mechanism intended to ensure that only genuine Apple devices can submit reports (see §6.3.0.2, Table 3, and §8.3.0.1).

The paper further reports that a finder uploads at most four reports for the same advertisement key, likely to limit duplicate traffic (see §6.3.0.2).

3.5 Owner-Side Search, Fetch, and Decryption

The owner-side retrieval path is described in §6.4. When searching for a lost device, an owner device sends Apple's fetch endpoint a list of the most recent public advertisement keys associated with the lost device (see §6.4.0.1). Authentication uses the owner's Apple account together with a device-specific search-party-token, plus anisette data, which acts as a short-lived trust artifact for previously authenticated systems (see §6.4.0.1 and Table 4).

Apple's response contains matching encrypted location reports and metadata, including the hashed public advertisement key that helps the owner select the correct private key for decryption (see §6.4.0.2). The owner device then performs the inverse of the finder's encryption process: it selects the correct private advertisement key, performs ECDH with the finder's ephemeral public key, derives the same symmetric key and IV, and decrypts the report locally (see §6.1.0.4 and §6.4.0.2).

This is the core crowd-sourced finding workflow reconstructed in the paper: crowd devices sense and encrypt, Apple stores and relays, and the owner reconstructs the location by local decryption.

An important limitation is stated explicitly in §6.4.2: Apple's Find My app combines multiple reports to display a more accurate location, but the authors did not reconstruct that internal fusion algorithm. Therefore, the paper gives the acquisition and decryption pipeline in detail, but not the exact final map-rendering logic.

3.6 System Implementation Inside Apple Operating Systems

The paper maps the workflow to Apple system components in §6.5. On iOS, searchpartyd is the main daemon responsible for key generation, cryptographic operations, and communication with Apple's servers. bluetoothd handles OF advertisements, while locationd contributes the finder's current geolocation before forwarding data to searchpartyd (see §6.5). On macOS, some networking functionality is delegated to searchpartyuseragent (see §6.5).

This implementation mapping matters because later vulnerabilities arise not only from the abstract protocol, but also from how keys and reports are stored and processed in the actual operating system (see §8.1.0.3 and §10).

4. What Is Algorithmic in the Paper, and What Is Not

The paper contains two distinct kinds of algorithmic material.

First, it reconstructs Apple's protocol-level workflow for crowd-sourced device finding (see §3 and §6). This is the operational algorithm of the OF system.

Second, the authors introduce their own analysis algorithms on top of downloaded reports (see §7). These are not Apple's production algorithms. In §7.1.3, they apply LOWESS to reconstruct mobility paths from noisy report points. In §7.2.2, they use resampling plus DBSCAN to infer top locations such as home and workplace from seven days of reports. These methods belong to the authors' evaluation and attack analysis, not to the standard OF protocol.

This distinction is essential. The paper fully describes the crowd-sourced reporting pipeline, but only partially reveals the logic by which Apple may convert multiple reports into a final displayed location.

5. Security and Privacy Interpretation of the Workflow

The paper's analysis in §8 argues that several design goals are substantially achieved:

  • end-to-end encryption prevents Apple from directly reading the plaintext contents of reports (see §6.1 and §8.1);
  • rolling BLE advertisements make long-term tracking by advertisement content difficult (see §6.2 and §8.2.0.1);
  • non-connectable BLE mode reduces exposure to Bluetooth remote code execution risks (see §8.2.0.2);
  • TLS and certificate pinning strengthen the server communication path (see §8.3.0.1).

At the same time, the reconstructed workflow still exposes serious weaknesses:

  • Apple can correlate users through metadata because finder uploads and owner downloads reveal identifying information; this enables proximity correlation across different owners (see §9.1 to §9.3).
  • macOS cached advertisement keys on disk in a readable location, allowing a malicious local application to extract them and download seven days of location history without permission (see §8.1.0.3 and §10.1 to §10.3).
  • BLE advertisements are unauthenticated, so relaying them elsewhere can create false location evidence and denial-of-service effects (see §8.2.0.3).

6. Final Conclusion

Yes, the paper does describe a crowd-sourced device-finding algorithm in a meaningful and technically detailed sense. It reconstructs the complete operational flow from key setup, BLE broadcasting, finder-side encryption, server upload, owner-side retrieval, and local decryption (see §3 and §6).

However, the paper does not fully recover Apple's proprietary multi-report fusion algorithm used inside Find My to compute the final displayed location (see §6.4.2). The most accurate summary is therefore:

  • Yes for the crowd-sourced discovery and reporting workflow.
  • No for the exact final-location fusion logic used by Apple's application.

Sources