How the first Spark unlock worked

The obvious way to build a proximity key is to have it shout a fixed identifier and let the phone listen. When we first built Spark we called that the wrong way, and the reasoning explains the original design.

The case against a static broadcast

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 — we argued it was no protection at all: it would let you keep the key in the drawer and unlock from the couch anyway. That risk is real, and it applies to the key sold today.

The first design: challenge and response

So the first Spark made every unlock a fresh conversation. The phone generated a new random number — a nonce — and sent it to the key. The key signed that specific nonce with a secret only it and the phone shared, and sent the signature back. The phone verified it.

1. phone → key
   nonce = random(16 B)
2. key → phone
   sig = HMAC-SHA256(
     secret, nonce ‖ tid)
3. phone
   verify(sig) → unlock

Because the nonce was different every time, a recording of a previous exchange was useless: replaying yesterday's signature against today's challenge failed verification. Producing a valid response required the secret, and the secret never left the key.

What the key checks today

The Bluetooth Spark sold today does not run that exchange. It broadcasts a fixed identity, and the phone unlocks when it hears that identity at contact range, with the phone held against the key for about 15 seconds. That is the static broadcast this post argued against, and a recording of it can be replayed. What still holds is the part the design was for in the first place: the key has to be fetched and held against the phone, which is a walk your tired self has to take. What no longer holds is the claim that a copy is worthless.

9:41HOLD 15 S

What it did not claim

Even the first design was proximity proof, not tamper-proofing: someone willing to open the hardware and extract the secret could clone a key. Today's key is easier to copy than that. We are defending against a moment of weakness, not a laboratory — and not against someone who sets out to record their own key.

Where an operating system makes true enforcement impossible, we say so plainly rather than pretending otherwise. Honesty about limits is part of the product, which is why this post now opens with a correction.