A standard BLE Tag is a coin-sized beacon you clip to keys, a laptop, a pallet, or a patient wristband so you can find it later. That same convenience is also the danger: drop one into someone’s bag without their knowledge and it becomes a tracking device. After a string of abuse cases, Apple and Google published a joint specification (2023-2024) for “unwanted tracking detection” that any tag — not just first-party ones — must honor to be tolerated by phones. This article is the engineering side: how a tag figures out it has been separated from its owner, how it warns a stranger instead of the owner, and the cryptography that lets a finder phone report a location without ever learning who owns the tag.
The threat model in two actors
There are exactly two relevant parties:
- Owner — the bonded phone that legitimately pairs with the tag and is supposed to stay near it.
- Non-owner — a person who now carries the tag unknowingly (the victim), or a passer-by whose phone can simply hear it (the finder).
A well-behaved tag assumes the owner is nearby most of the time. The dangerous state is *separated*: the tag is moving through the world but its owner’s phone is not with it. Detecting that state, and alerting the non-owner instead of the owner, is the entire job of anti-tracking protection.
Separation detection: “is my owner here?”
The tag cannot ask the owner over the Internet — it is BLE-only and may be outside any gateway. So it infers owner presence locally:
1. The owner’s phone, while bonded, periodically emits an authenticated presence token — a signed, rotating BLE packet the tag recognizes.
2. The tag listens during its advertising gaps. Each interval it either hears the token (owner present) or does not (a miss).
3. It keeps a miss counter. When misses exceed a threshold *and* the tag’s accelerometer reports motion, it transitions to the separated state.
The motion gate matters. A tag left on a shelf at home while the owner goes on holiday should *not* sound an alarm — there is no victim. A tag moving with a stranger for hours *should*. Typical thresholds: 8-24 h of accumulated absence while in motion before the first alert.
A minimal detection loop:
def tick(tag, owner_token_seen, accel_motion):
if owner_token_seen:
tag.miss_counter = 0
tag.separated = False
return
tag.miss_counter += 1
if tag.miss_counter > ABSENCE_LIMIT and accel_motion:
tag.separated = TrueTwo ways the tag warns the stranger
Once separated, the tag must alert the *non-owner*, not the owner:
1. On-device speaker. A small piezo or magnetic transducer plays a tone. The cross-platform spec effectively requires a sound of roughly >= 60 dB at 0.3 m emitted within a bounded window (commonly 8-24 h after separation). This is why every consumer tag ships with a transducer you cannot silently remove.
2. Non-owner phone alert. Any phone OS can flag an *unknown* tag that has been travelling with it. The phone shows a notification, offers “Play Sound”, “Show Last Seen Location”, and instructions to disable the tag. For this to work cross-vendor, the tag must advertise a separated-state flag in its normal BLE payload that any OS can parse.
| Capability | Owner phone | Stranger’s phone (non-owner) |
|---|---|---|
| Sees tag location | Yes (live + history) | Only “last seen near you” |
| Can play sound | Yes (any time) | Yes (after separation window) |
| Gets alert | No (it is the owner) | Yes (unknown-tracker alert) |
| Can disable tag | Yes (unpair) | Limited (physical / OS flow) |
Offline finding: crypto that hides the owner
The clever part is *how a stranger’s phone reports the tag’s location back to the owner without either side learning the other’s identity*. This is the “Find My” / offline-finding model:
- The tag holds a master private key. For each time interval *i* (often one hour) it derives a fresh public key `PK_i = Derive(master_priv, i)` and broadcasts it — or a short hash of it — in the advertising packet.
- A finder phone that hears `PK_i` reads its own GNSS/Wi-Fi location, encrypts `(location, timestamp)` with `PK_i`, and uploads the ciphertext to a relay server. No account, no identity.
- The owner, knowing `master_priv` and the current interval *i*, recomputes the matching private key, fetches the uploaded ciphertext, and decrypts the location.
The privacy property: the relay server sees only opaque ciphertexts. It cannot link two finds of the same tag (keys rotate), and cannot learn the owner. Only the owner’s master key ties reports together.
Engineering constraints on a tiny tag
This is where it gets hard for a coin-cell device:
- Crypto cost. An ECC scalar multiplication on a Cortex-M0+/M4 takes hundreds of milliseconds to seconds and draws mA-scale current. Rotating and re-deriving keys every hour on a CR2032 is impractical, so tags cache the current `PK_i` and only recompute at the interval boundary — often offloading the heavy derive to the owner’s phone, which pre-computes a small batch of future keys and pushes them down over the bonded connection.
- Clock drift. Key rotation is indexed by time. If the tag loses power (battery pull) its interval index resets, and the owner cannot decrypt reports until the phone re-syncs the index. Firmware must persist the index in non-volatile memory and tolerate drift.
- False-positive control. If the owner’s phone is briefly out of BLE range, the tag must not trip. The miss counter + motion gate + a long absence limit keep false alarms rare.
- Anti-tamper. The speaker and the separated flag must be hard to disable in firmware; a compliant tag exposes no “silent mode” that survives separation.
A rough power sketch for a tag doing anti-tracking:
| Activity | Current | Duty |
|---|---|---|
| Accelerometer poll (motion) | 5-50 uA | 1 Hz |
| Owner-token listen (RX) | 3-6 mA | few ms / advert gap |
| Key cache serve (BLE) | 1-3 mA | sporadic |
| Speaker alert | 20-80 mA | bursts, rare |
| Base advertising | 5-50 uA | continuous |
The dominant always-on cost is the accelerometer and the periodic RX listen; everything else is rare. A CR2032 still lasts months because the separated state and the speaker are exceptional, not daily.
What an OEM must implement to ship a compliant tag
If you build a BLE Tag that will be carried by people, the minimum firmware surface is:
1. Authenticated owner-presence detection (signed, rotating token from the bonded phone).
2. Separation timer + motion gate with the spec’d absence window.
3. Audible alert meeting the dB / latency requirement, non-removable.
4. Separated-state flag in the BLE advert so any phone OS can raise an unknown-tracker alert.
5. Offline-finding key rotation (if you join a find network) with index persistence across reboots.
If instead your tag is an *industrial asset tag* under constant gateway supervision, the same abuse is possible if a worker slips it into a coat. Many fleets solve this by treating the fleet server as the “owner”: the server confirms presence over the gateway link, and a tag that loses server contact for the limit enters the same separated behavior — just with the alert routed to security rather than a phone.
Bottom line
Anti-tracking protection is not a checkbox. It is a state machine (owner-present -> absent -> separated), a speaker you cannot silence, a cross-vendor flag, and optional cryptography that keeps the owner anonymous. Build it in from day one, because phone OSes now treat non-compliant tags as hostile and warn users against them on sight.
