How the unlock actually works

The obvious way to build a proximity key is to have it shout a fixed identifier and let the phone listen. It is also the wrong way, and understanding why explains the whole design.

Why a static broadcast fails

A constant identifier can be recorded once and replayed forever. Free apps on any phone will happily impersonate a beacon you sniffed this morning. Against a remote attacker that might be acceptable. Against your own future self — who has physical access, unlimited patience, and a strong motive — it is no protection at all. It would let you keep the key in the drawer and unlock from the couch anyway, which defeats the point.

Challenge and response

Instead, every unlock is a fresh conversation. The phone generates a new random number — a nonce — and sends it to the key. The key signs that specific nonce with a secret only it and your phone share, and sends the signature back. The phone verifies it.

phone → key   nonce = random(16 bytes)
key   → phone sig = HMAC-SHA256(secret, nonce ‖ tid)
phone         verify(sig) → unlock

Because the nonce is different every single time, a recording of a previous exchange is useless. Replaying yesterday's signature against today's challenge fails verification. Producing a valid response requires the secret, and the secret never leaves the key.

What this does not claim

This is proximity proof, not tamper-proofing. Someone willing to open the hardware and extract the secret can clone a key. We are not defending against a laboratory — we are defending against a moment of weakness, and that is a much lower bar that a physical key clears easily.

Where an operating system makes true enforcement impossible, we say so plainly rather than pretending otherwise. Honesty about limits is part of the product.