Remote Attestation

Attestation creates an unforgeable binding between an enclave's measurement (a cryptographic hash of its initial code and data) and the hardware root of trust embedded in the processor. The CPU signs a report containing the enclave's measurement using a key fused into the silicon during manufacturing. This chain of trust extends from the hardware to the application, ensuring that a remote verifier can distinguish a genuine enclave running specific code from an imposter or modified version. The binding is anchored in physically immutable hardware, making software-based spoofing computationally infeasible.

To prevent replay attacks—where an attacker captures a valid attestation report and replays it later—remote attestation protocols incorporate freshness nonces. The verifier generates a cryptographically random nonce and sends it to the attester, which includes it in the signed report. This proves the report was generated in real-time for that specific challenge. Without freshness guarantees, a compromised system could present an old, valid report while running malicious code. The nonce mechanism ensures liveness, confirming the enclave is currently operational and responsive.

Attestation is not a binary pass/fail check; it enables fine-grained policy evaluation by the verifier. The verifier receives the enclave's measurement and can apply custom logic to decide whether to trust it. Policies can be based on:

• MRENCLAVE: Trusting only a specific, version-pinned build of the enclave code.
• MRSIGNER: Trusting any enclave signed by a specific vendor's key, enabling version flexibility.
• Security Version Numbers (SVNs): Rejecting enclaves running outdated firmware or software with known vulnerabilities.
• Platform TCB Status: Verifying that the underlying hardware and firmware are up-to-date against the latest security advisories.

The primary purpose of remote attestation is to establish a secure channel for provisioning secrets. Once the verifier validates the enclave's identity, it can encrypt sensitive data—such as model weights, API keys, or decryption keys—such that only that specific enclave can decrypt it. This is achieved by embedding a transient public key generated by the enclave within the signed attestation report. The verifier wraps the secrets with this key, ensuring that even the host operating system or hypervisor cannot access them. This mechanism is the foundation for Confidential AI and private inference.

Production deployments require attestation to scale beyond one-to-one verification. Data Center Attestation Primitives (DCAP) and similar frameworks provide a flexible infrastructure where enterprises can run their own attestation services. This decouples verification from the hardware manufacturer's cloud services, enabling:

• Caching of verification collateral to reduce latency.
• Integration with existing PKI and certificate management systems.
• Privacy-preserving attestation where the verifier learns only that the enclave meets a policy, without receiving the full measurement, using techniques like zero-knowledge proofs. This infrastructure is critical for orchestrating thousands of enclaves in a confidential computing cluster.

In collaborative AI scenarios like Secure Multi-Party Computation or Federated Learning, multiple distrusting parties may need to verify an enclave before contributing data. Remote attestation enables mutual verification, where each party independently challenges the enclave and receives a signed report. Only after all parties are satisfied with the attestation results do they provision their respective secrets. This establishes a collective trust anchor for multi-stakeholder confidential workloads, ensuring no single party can coerce the enclave into misbehavior without detection by the others.

Two distinct attestation trust models serve different operational needs:

• MRENCLAVE (Exact Match): Verifies the precise cryptographic hash of the enclave binary. Any code change—even a single byte—produces a different measurement. This provides immutable identity but requires re-attestation on every update.
• MRSIGNER (Vendor Trust): Verifies only the hash of the signing authority's public key. This allows trust in any enclave signed by a specific vendor, enabling seamless updates without re-provisioning secrets.
• Hybrid Models: Production systems often combine both, using MRSIGNER for broad trust and MRENCLAVE for critical security-sensitive operations.

Attestation results are encoded as standardized tokens for interoperability:

• JSON Web Token (JWT): A widely adopted, human-readable format encoding attestation claims as JSON objects with cryptographic signatures. Used by Intel DCAP and many cloud providers.
• CBOR Web Token (CWT): A compact binary format based on Concise Binary Object Representation, optimized for constrained environments like IoT devices and embedded TEEs.
• Entity Attestation Token (EAT): An IETF standard extending CWT/JWT with attestation-specific claims, including hardware version, security lifecycle state, and measured boot logs.
• Verification: Both formats support chained signatures, allowing a verifier to trace trust from the token back to the hardware root of trust.