CONCEPT Cited by 1 source
Remote attestation¶
Definition¶
Remote attestation is the cryptographic mechanism by which a client can verify — from outside — that a specific, known-good software image is running inside a genuine TEE on a specific hardware instance, without trusting the host operator. The attestation is:
- Produced by the CPU (hardware root of trust) — not by the host OS, not by the hypervisor, not by the application itself.
- Bound to the TEE instance + loaded binary measurement — a hash of the code + initial state that uniquely identifies the image.
- Signed by a vendor-rooted key (e.g. Intel / AMD / Arm) that verifiers can check against a well-known public trust chain.
- Freshness-protected — includes a nonce from the verifier so replayed attestations from a previously-good-but-since-replaced binary are rejected.
What attestation proves, and what it doesn't¶
Proves: the binary whose digest is X is running in a genuine TEE at this moment, with freshness nonce N.
Does not prove: X is a good binary to trust. That second question is what a binary transparency log answers — by publishing every digest that has been blessed for the service, so "X matches the attestation" becomes verifiable as "X is on the published list of acceptable images".
This is why Meta pairs attestation with a third-party ledger in Private Processing. The post states:
"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."
Load-bearing in session-key gating¶
Attestation's practical use is not as a stand-alone proof, but as the gate on releasing a session key. The canonical pattern: the client performs attestation as part of the handshake (RA-TLS), and the client's ephemeral session key is only derived / released if the attestation verifies against the published ledger. A compromised or swapped-in binary fails the check, and the client refuses to continue — the attack fails closed. This is the patterns/attestation-before-session-key-release pattern.
Distinguishing sibling concepts¶
- concepts/release-attestation — signed statement that a specific software release was published by a specific identity. Verifies a supply-chain claim, not a runtime one. Portable outside the platform that produced it.
- Remote attestation (this page) — runtime cryptographic proof, produced by the CPU, that a specific binary is currently running inside a TEE. Tied to a live session.
Both are necessary for a defence-in-depth posture on a confidential-computing service: release attestation answers "did the right team publish this binary?"; remote attestation answers "is this binary the one actually executing on the server I'm talking to?"; the transparency log answers "is the binary one of the ones we said we'd run?".
Seen in¶
- sources/2025-04-30-meta-building-private-processing-for-ai-tools-on-whatsapp — remote attestation is the central enforcement mechanism that makes Meta's verifiable-transparency guarantee binding at session-establishment time. Canonical wiki instance.
Related¶
- concepts/trusted-execution-environment — what's being attested.
- concepts/confidential-computing — the posture remote attestation is one pillar of.
- concepts/ra-tls — the TLS composition.
- concepts/verifiable-transparency-log — the trusted-ledger layer against which attestations are checked.
- concepts/release-attestation — the supply-chain sibling.
- systems/cvm-confidential-virtual-machine, systems/whatsapp-private-processing.
- patterns/attestation-before-session-key-release — the gating pattern.
- patterns/publish-binary-digest-ledger — the complementary transparency pattern.