offline-finding

How it is built

Architecture overview

An offline device-finding network lets an owner see roughly where a lost phone, laptop or tag was last seen, although that device has no internet connection of its own. The lost device sends a short Bluetooth Low Energy (BLE) advertisement. Any participating phone that happens to walk past hears it, encrypts its own current location so that only the owner can read it, and uploads the result to the operator's server. The owner later asks the server for the reports stored under identifiers that only the owner's devices can compute, and decrypts them locally. The one idea that makes it work: the advertisement carries a rolling public key, and the matching private key never leaves the owner's devices. So the finder can encrypt without knowing who the owner is, the server stores only ciphertext it cannot read, and a passer-by who records the advertisements cannot link them across key changes.

The privacy goals are stated in the research literature as finder anonymity, untrackability of the lost devices and confidentiality of the location reports (Heinrich et al.). A network like this is also a tool for stalking if someone hides a tag in a bag or on a car, so the safe design has a second half: the tag and the phones must cooperate to detect unwanted trackers and warn the person being followed. This page describes both halves as publicly documented for Apple's Find My and Google's Find Hub networks, and deliberately leaves out ways around either.

Parts:

• Lost device or tag — advertises a rolling public key over BLE, keeps a per-device secret and a counter — Key derivation (HKDF), Elliptic-curve Diffie-Hellman, ble-advertising (no page yet), hardware-backed-keystore (no page yet), Wearable firmware with BLE
• Finder device — scans for the advertisement, encrypts its location to the advertised key, uploads — Elliptic-curve Diffie-Hellman, AEAD (AES-GCM, ChaCha20-Poly1305), Cryptographic hashes, ECDSA signatures
• Report relay — stores opaque encrypted reports under a hash index, rate-limits uploads and downloads — LSM tree, Token bucket, Consistent hashing, Time partitioning
• Owner devices — recompute the keys for a time window, query by hash, decrypt, combine — Key derivation (HKDF), Elliptic-curve Diffie-Hellman, AEAD (AES-GCM, ChaCha20-Poly1305)
• Close-range finding — Bluetooth to get near, ultra-wideband to point at the item — uwb-ranging (no page yet)
• Unwanted-tracker protection — near-owner and separated modes, slower key change when separated, alerts and a way to find and silence the tag — Wearable firmware with BLE, ble-advertising (no page yet)

 owner devices                lost device / tag                   finder (any participating phone)
 ┌──────────────┐  setup     ┌──────────────────────┐   BLE      ┌───────────────────────────────┐
 │ d, SK0, i    │───────────►│ SK_i, P_i (rolling)  │──advert───►│ ECIES: encrypt location to P_i│
 │ (synced E2E) │  (paired)  │ rotates P_i on timer │  P_i only  │ id = SHA-256(P_i)             │
 └──────┬───────┘            └──────────────────────┘            └──────────────┬────────────────┘
        │ derive {d_i, SHA-256(P_i)} for a time window                          │ HTTPS upload
        │                                                                       ▼
        │   query by id                                          ┌──────────────────────────────┐
        └───────────────────────────────────────────────────────►│ relay: id → encrypted reports│
                    ◄────────── encrypted reports ───────────────│ (cannot decrypt)             │
        decrypt with d_i, combine reports into one map pin       └──────────────────────────────┘

 separate path: platform OS ◄─ scans for trackers seen "separated" from their owner ─► alert + find/silence

How the parts fit together

Lost device or tag: the key schedule

Apple's Platform Security guide describes the construction. When offline finding is turned on, the device generates an elliptic-curve key pair {d, P} on the NIST P-224 curve, plus a 256-bit secret SK0 and a counter i starting at zero. These are never sent to Apple and are synced only to the owner's other devices, end-to-end encrypted through iCloud Keychain. The current symmetric key is derived recursively, SK_i = KDF(SK_(i-1), "update"). From it two big integers (u_i, v_i) = KDF(SK_i, "diversify") give a short-lived key pair: the private key is d_i = u_i · d + v_i (mod the curve order) and the public key P_i = u_i · P + v_i · G. Approximately every 15 minutes the public key is replaced using the next counter value, and the derivation is designed so that different P_i cannot be linked to the same device.

Why this and not a random key per period? Because the owner has to be able to recompute every key for any past window without having stored it, while an observer must not be able to. The derivation chain is a one-way ratchet (Key derivation (HKDF) is the general "extract, then expand" pattern; the reverse-engineering paper by Heinrich et al. reports that Apple uses the ANSI X9.63 KDF with SHA-256 rather than HKDF itself). The affine relation d_i = u_i · d + v_i means the public key can be derived from public values only if you know P (the owner's side does), but the keys look unrelated to anyone without the secret. P-224 is chosen so that the public key's x-coordinate (28 bytes) fits into a single BLE advertisement; Heinrich et al. describe how the first six bytes are squeezed into the advertising address field and the rest goes into the payload.

Contract with the finder: the lost device emits only the public key and a status byte. It does not authenticate itself, receive anything, or accept connections in this mode (the paper notes the advertisements are non-connectable, which also removes a remote-attack surface). The paper reports one advertisement roughly every two seconds while a key is in use, the same key for a 15-minute window.

On an accessory the secret and counter live in firmware (Wearable firmware with BLE). On the owner's phone a hardware-backed-keystore (no page yet) matters most, since d or SK0 reveals every past and future report of that device. Heinrich et al. found a concrete case in 2020: macOS cached the precomputed advertisement keys on disk where an unprivileged local app could read them and decrypt seven days of reports (CVE-2020-9986, fixed in a macOS update). The lesson: derive keys on demand or keep them encrypted.

Finder device: encrypt to a stranger

The finder hears P_i and knows nothing else. Apple's guide says it uses an ECIES construction: encrypt the finder's current location under P_i and upload it. The reverse-engineering paper gives the detail: the finder generates an ephemeral key pair, runs ECDH between its ephemeral private key and P_i, derives a 16-byte key and a 16-byte IV with a KDF over the shared secret, and encrypts with AES-GCM (AEAD). The ephemeral public key and the authentication tag go along in the report. The report is filed under an identifier equal to SHA-256 of P_i (Cryptographic hashes); Apple's guide calls it the server index.

Why public-key encryption and not a shared symmetric key? A symmetric scheme makes the lost device take part in each report, which costs battery and opens a resource-exhaustion path (the paper contrasts an academic design, PrivateFind). With public-key encryption the tag only broadcasts.

Two contracts matter. First, uploads are batched: the paper measured a median of 26 minutes from creating a report to uploading it, longer in low-power mode, and observed a limit of four uploaded reports per advertisement key. Second, the finder's request to the server is authenticated as a genuine device of that operator (the paper observed a device certificate and an ECDSA signature from a key held in the Secure Enclave, and assumed it works as attestation), while Apple's guide states the traffic contains no authentication information that would reveal who the finder is. The paper itself says it could not fully reconstruct the authentication scheme, so treat the anonymity of the finder-to-server channel as the part that depends on operator behaviour rather than on cryptography.

Report relay: a blind mailbox

The server stores a mailbox per hash index, holding ciphertext it cannot decrypt, because Apple's guide says it never has the decryption key. A write-heavy key-value store with retention fits an LSM tree with time partitioning (a reasoned fit, not a documented choice of either operator). Hash indexes are uniform, so consistent hashing spreads them over shards.

Abuse control sits here and on the device. A token bucket per source and per index limits uploads and downloads; Google states that its network limits how many times a nearby Android device can contribute a report for a particular tag and throttles how often an owner can request an updated location, precisely so that the network is useful for lost keys and baggage but poor for real-time tracking of a moving person (Google Security Blog, 2024). Google also says encrypted location data is minimally buffered and frequently overwritten, and that when the owner's own device can see the tag, crowdsourced reports for it are discarded.

Owner devices: derive, query, decrypt

To search, an owner device estimates the range of counter values for the search period. From d and the SK_i values it reconstructs the set {d_i, SHA-256(P_i)} for the whole period, asks the server for the encrypted reports under those indexes, and decrypts them locally with the matching d_i (Apple's guide). Reports from several finders are combined into one approximate position, and the guide notes the app shows the age of the latest detection. Heinrich et al. report that the service looked back seven days and that fetching used one request per batch of keys; 15-minute keys over seven days is 672 keys per device (arithmetic from their numbers: 7 · 24 · 4).

The paper also shows a cost. Because the owner authenticates when downloading, and the finder authenticates when uploading, the operator could in principle link owners that were near the same finder (the "Apple can correlate" analysis in the paper). That is a statement about what the server could do, not evidence that it does; the paper recommends removing owner identification from the download request.

Google's Find Hub encrypts item locations with a key that only the owner can access by entering the Android device's PIN, pattern or password, backed by the same technology as Google Password Manager (Google Android Help): the same idea, with the key tied to something the owner knows.

Close-range finding

Once the owner is within Bluetooth range, ultra-wideband ranging can give distance and direction. Apple's guide says its U1 chip lets recent iPhones precisely locate other U1-equipped devices; the ranging principle is uwb-ranging (no page yet), the radio class that real-time location systems use indoors. It is a local, owner-initiated step that does not use the crowd.

Unwanted-tracker protection

A finder network that works because the tag speaks to strangers works equally well for a hidden tag. The public mitigations, in the order they act:

1. Tag behaviour. The IETF working group on Detecting Unwanted Location Trackers (DULT) is standardising how tags must behave. In its accessory-protocol draft (expired, work continuing in the working group) a tag keeps a second internal state, near-owner or separated, depending on whether it is connected to or near the owner's devices. A separated tag must advertise its location-enabled payload; a separated tag rotates its address every 24 hours, while a near-owner tag rotates every 15 minutes. The slower rotation is deliberate: it lets a phone notice that the same tag has been following it for some time. A tag also exposes a non-owner interface (identification, a way to make it play a sound).
2. Phone behaviour. The phone scans for trackers that are separated from their owner and travelling with it, and notifies the user, with instructions to find and disable the tag. Google says the Find Hub network complies with the joint industry standard, so that both Android and iOS users get unknown-tracker alerts for compatible tags (Google Security Blog).
3. Network behaviour. Google's blog describes aggregation by default (several nearby devices must see a tag before a location is reported), no contribution of crowdsourced reports near a saved home address, and the rate limits above.
4. Open detection tools. AirGuard (Heinrich et al.) is an Android app that detects unwanted Apple-network trackers.

The contract between tag and phone is therefore a conformance contract. A tag that does not follow it (for example one built from the open research frameworks) is exactly the gap the standardisation work addresses, which is why the DULT charter lists "detection and exclusion of nonconformant accessories" among the interfaces.

Data and control flow

Setup and loss (once, then continuously):

1. Owner enables offline finding; the device creates {d, P}, SK0 and counter i = 0, and syncs them to the owner's other devices end to end encrypted.
2. When the device loses connectivity (or a tag is separated), it starts advertising P_i for a 15-minute window, then advances the counter and derives P_(i+1).
3. A finder hears P_i, reads its own location, encrypts it to P_i, labels it SHA-256(P_i) and queues it. Time goes to waiting for a batch upload: tens of minutes (paper median 26 minutes).

Search:

1. Owner opens the app on any enrolled device. It computes the counter range for the last hours or days and derives (d_i, SHA-256(P_i)) for each.
2. It requests those indexes in batches; the server returns whatever ciphertext exists. Most keys return nothing; the cost is request volume, not payload size.
3. For each returned report the app does ECDH with d_i, derives the AES-GCM key, authenticates and decrypts, then merges the reports into one pin with an age.
4. Within range, the owner switches to ultra-wideband precision finding, or plays a sound on a tag.

Unwanted-tracker check (on the phone, in the background):

1. The OS scans BLE and recognises advertisements that follow the standard format.
2. It notes which tags are separated from their owner and keep appearing near the phone over time, using the tag's 24-hour rotation to recognise a persistent companion.
3. If the pattern persists, it alerts the user, can make the tag play a sound, and shows how to disable it.

Scaling

1. Battery on the tag: advertising interval and key-change period trade finding speed against battery life. Levers: longer interval, advertising only when separated.
2. Report volume and latency: more finders means more reports, so uploads are batched, limited per key, and the relay is a key-value store with expiry. Levers: batching windows, per-key caps, sharding by hash.
3. Owner query cost: a seven-day search touches hundreds of indexes per device (672 for 15-minute keys). Levers: longer-lived keys when near, derivation on demand, batching queries, caching results on the device.
4. Density: the network is only as good as the number of finders nearby. Aggregation (Google) trades recall in empty places for safety.

Failure modes

Real implementations

None of the open-source projects found for this page is a complete crowdsourced network operator; the operator side (relay, device attestation, abuse control) is described only in the vendors' documents.

Sources

• Apple, Apple Platform Security (August 2026 edition), "Find My security": end-to-end encryption, P-224 rolling keys, 15-minute rotation, finder anonymity, owner search. guide landing page; PDF
• A. Heinrich, M. Stute, T. Kornhuber, M. Hollick, Who Can Find My Devices? Security and Privacy of Apple's Crowd-Sourced Bluetooth Location Tracking System, PETS 2021. Reverse-engineered protocol detail, advertisement format, upload delays, the correlation and key-cache findings. arXiv:2103.02282
• A. Heinrich et al., AirGuard: Protecting Android Users From Stalking Attacks By Apple Find My Devices. arXiv:2202.11813
• Google Security Blog, How we built the new Find Hub network with user security and privacy in mind, 8 April 2024. post
• Google Android Help, How Find Hub protects your data. help page
• IETF DULT working group: charter and documents; accessory protocol draft; threat model draft.
• Apple Developer, Find My network accessories: accessory specification available through the MFi Program.