HomeTechnical ArchitecturePhilosophyContactRequest access
All articles

Relay

Algorithm: The Attested Push Seal

5 min read

Two mechanisms make the push path safe: a sealed box that hides a wake token at rest and makes two tokens for the same device look unrelated, and an attestation the client checks before it will hand a sealed token to anyone. This is the concrete construction of both — and an honest accounting of which half is hardware and which is, for now, software.

This is the algorithm behind Waking a Sleeping Phone. Read that first for why; this is the how.

1. What has to be protected

To wake Bob, someone eventually presents Bob's Apple device token to APNs. That device token is the crown jewel — it links to a physical phone and a person — so it must be:

  1. Unreadable by the registry (push-svc) that stores it,
  2. Unlinkable at rest — two stored wake tokens for the same device must not look like they belong together, or the registry becomes a device-clustering map even without reading anything,
  3. Openable only by the attested sender (push-sender), and only after the client has checked that the sender is the real, expected code.

The first two are the sealed box; the third is the attestation.

2. The sealed box: a per-row hybrid KEM seal

The wake token is sealed with a hybrid key-encapsulation mechanism (KEM) called X-Wing, which combines the lattice KEM ML-KEM-768 with classical X25519. A KEM is the modern shape of public-key encryption: instead of "encrypt this message under a public key," you encapsulate — run the public key to jointly produce a fresh random shared secret and a ciphertext that lets the holder of the private key recover that secret. You then use the shared secret with a symmetric cipher to seal the actual payload.

The sealing, per stored row, is:

  1. Encapsulate to the sender's public seal key: (shared_secret, kem_ct) ← X-Wing.Encap(pk_seal). Because encapsulation draws fresh randomness every time, kem_ct and the resulting key are different for every row — even sealing the same device token twice yields two unrelated-looking blobs. This is what buys unlinkability at rest.
  2. Derive a key: aead_key ← HKDF-SHA256(shared_secret).
  3. Seal the token: an AEAD (authenticated encryption) under aead_key with a fresh nonce produces the ciphertext ct.

The stored blob is the concatenation kem_ct ‖ nonce ‖ ct — roughly 1120 ‖ 12 ‖ … bytes, the 1120 being X-Wing's ciphertext. push-svc holds a pile of these and can open none of them (it has no private seal key); push-sender, holding the private key, does the reverse — X-Wing.Decap to recover the secret, HKDF, AEAD-open — for exactly one row, in memory, then forgets.

A note for the careful reader: this is not HPKE. HPKE (RFC 9180) is the standard "seal a message to a public key" construction and would be the natural thing to reach for, but it has no standardized post-quantum hybrid mode we wanted to depend on, so the push seal is a purpose-built X-Wing sealed box with the same shape as HPKE (encap → HKDF → AEAD) but its own PQ-hybrid KEM. If you read the code expecting RFC 9180, you will not find it; the analogy is conceptual, the bytes are ours.

3. The attestation: proving you may hold the key

The sealed box protects the token from the registry. It does nothing against a malicious operator who simply publishes their own seal key and collects readable wake tokens sealed to it. Stopping that is the attestation's job: the client must be able to verify, before it seals anything, that a seal public key really lives inside the expected, measured software and not in an attacker's pocket.

So a seal key is never presented bare — it comes with a signed attestation over a canonical preimage:

preimage =  tag  ‖  alg  ‖  measurement  ‖  pk_seal  ‖  timestamp  ‖  nonce
  • tag — domain separation (this is a push-seal attestation, not some other signed blob),
  • alg — which attestation algorithm/root produced it,
  • measurement — the identity of the code holding the key: a hash/measurement of the exact software image, so "who vouches for this key" is really "this specific, inspectable build,"
  • pk_seal — the seal public key being attested,
  • timestamp + nonce — freshness, so an old attestation can't be replayed forever.

The client verifies this fail-closed: it checks the signature against a pinned root, checks the measurement matches the expected image, checks freshness — and if anything is off, or the attestation is simply absent, it refuses to seal and the wake is not set up. There is no "unverified fallback." A relay that cannot prove its sender is the real sender gets no wake tokens.

The picture is a bonded courier. The sealed tube protects the note from everyone; the courier's bonded badge — which you inspect against a registry you trust, before you hand over the tube — protects you from handing your note to an impostor courier.

4. The honest seam: software today, hardware next

Here is where we refuse to overclaim, exactly as article 07 warned.

Shipped and tested: the sealed box, the per-row unlinkability, the attestation format, the client's fail-closed verification, and a software attester — the measurement is signed with an Ed25519 key, and the whole path has end-to-end tests. Today's guarantee is therefore "the client will only seal to a key vouched for by the expected, measured software image."

A marked, unshipped seam: the hardware root. The design's destination is an attestation rooted in a real trusted execution environment — an AWS Nitro Enclave, whose attestation is an ECDSA-P384 document signed by the CPU platform, not by our own software — so that the seal key is non-exportable even by the operator running the machine. That provider is present in the code as an explicit seam and it fails loud: ask the verifier to accept a hardware-rooted (Nitro) attestation today and it throws "provider unavailable"; ask push-sender to boot in Nitro mode and it refuses. Nothing silently degrades — the hardware path is wired for, and visibly not yet on.

So the precise statement is: the software attestation (measured image) is real and enforced; the hardware enclave that would make the key non-exfiltratable is the remaining work, cleanly seamed. And, as always, even a perfect enclave leaves Apple as the disclosed floor for the wake event itself.

References & further reading