Skip to content

PATTERN Cited by 1 source

Attestation before session-key release

Pattern

Gate the release of the client's session-key material on a successful remote-attestation verification of the server TEE's binary digest against a known-good policy — typically a published transparency log of acceptable binaries. A compromised, swapped, or unknown binary fails the check, the client refuses to release the key, and the session fails closed.

In the canonical realisation, this gating lives inside the TLS handshake itself — RA-TLS — so application code does not have to remember to check.

Problem

TEEs produce attestations, transparency logs publish acceptable digests — but these artefacts are only load-bearing if something actually uses them as a gate. Naive designs treat attestation as an informational artefact ("we checked, looks fine") or verify attestation after the session has been established and secrets have already been exchanged. An attacker who compromises the binary after deployment but keeps the X.509 certificate valid can still complete a normal TLS handshake; if the client's session key is released before attestation is verified, the compromise succeeds.

Solution

  1. Bind the session key derivation to attestation verification. The client derives/releases the ephemeral key only if the server's attestation verifies against the ledger.
  2. Perform the check inside the handshake. RA-TLS is the standard composition: the attestation is a field the server presents during the TLS handshake; the client's verifier rejects the handshake if the attestation doesn't pass, preventing any session from ever being established.
  3. Fail closed. On any verification failure (unknown digest, stale nonce, wrong TEE identity, expired attestation, ledger unreachable-and-strict-mode), the client refuses the session — no fallback to un-attested communication.
  4. Reuse the same pattern for server-to-server traffic. If one TEE must call another to complete a request, it attests the same way before key release.

Canonical wiki instance

The 2025-04-30 Meta Private Processing post describes the realisation verbatim:

"Private Processing establishes a Remote Attestation + Transport Layer Security (RA-TLS) session between the user's device and the TEE. The attestation verification step cross-checks the measurements against a third-party ledger to ensure that the client only connects to code which satisfies our verifiable transparency guarantee."

And for inter-CVM traffic:

"CVMs may communicate with other CVMs using the same RA-TLS connection clients use to complete processing."

Why the gate is load-bearing

Without the gate:

  • Compromised binary + valid cert → plaintext leak. An attacker with host access who swaps the binary but keeps the X.509 cert can complete TLS normally, read the session key, and silently exfiltrate.
  • Unknown binary in production → no detection. An operational mistake that pushes an unreviewed binary would simply succeed silently.

With the gate:

  • Attacker-swapped binary produces a digest not on the ledger → handshake fails → no session.
  • Un-published binary produces a digest not on the ledger → handshake fails → deployment-mistake detectable at first client connection.
  • Genuine published binary produces matching digest → normal session proceeds.

The gate turns attestation from audit evidence into an enforcement mechanism.

Failure modes

  • Ledger-unreachable / stale-ledger soft-fail. If the client falls back to un-attested mode when it can't reach the ledger, an attacker who can cause a DoS on the ledger degrades the guarantee. Strict-mode clients must refuse sessions during ledger outages.
  • Missing freshness nonce. Replay of an old-good attestation after binary downgrade. Defence: nonce bound to session.
  • Attestation verifier coupled to server operator. The verifier must be an independent trust-rooted component (vendor chain + published ledger) — if the server operator can also silently update its own verifier, the gate is compromised.
  • Mis-configured ledger policy. If the client's policy is "any digest on the ledger is fine" without an integrity check on the ledger itself, a compromised-ledger appends bad digests. Defence: signed + auditable ledger, client-side cross-checks.

Seen in

Last updated · 319 distilled / 1,201 read