Attestation

Attestation binds an enclave's unique identity to a cryptographic measurement of its initial state. This measurement—a hash of the code, data, and configuration loaded into the enclave—serves as an unforgeable fingerprint. A verifier compares this fingerprint against a known-good reference value to confirm the enclave is running the exact expected software stack, not a compromised or substituted version.

• MRENCLAVE: Identifies the exact code version
• MRSIGNER: Identifies the software vendor via signing key hash
• Hardware Root of Trust: The processor itself signs the attestation report

Attestation protocols incorporate freshness mechanisms to prevent an attacker from replaying a stale but valid attestation report from a previously healthy enclave. The verifier embeds a cryptographic nonce in the challenge. The enclave must include this nonce in its signed report, proving the attestation is generated in real-time and not a recording.

• Nonce: A random, single-use value from the verifier
• Timestamp: Hardware-generated proof of recency
• Platform TCB Status: Includes current security patch level

Attestation is the gatekeeper for secure secret delivery. A relying party only transmits encryption keys, model weights, or sensitive data to an enclave after successful attestation verification. The secrets are encrypted such that only the attested enclave—identified by its measurement—can decrypt them. This creates a cryptographically guaranteed trust boundary.

• Key Wrap: Secrets encrypted to the enclave's public key
• Conditional Release: Secrets released only on measurement match
• Data Sealing: Enclave persists secrets to untrusted storage for later retrieval

In collaborative confidential computing, multiple parties must mutually verify each other's enclaves before participating. Mutual attestation ensures all enclaves in a distributed computation are genuine and running approved code. This is foundational for Confidential Consortium Framework deployments where governance depends on every node being verifiably honest.

• Mutual TLS with Attestation: Embed attestation evidence in TLS handshakes
• Confidential Consortium: All nodes attest before joining the network
• Policy Enforcement: Verifiers check measurements against governance rules

A client sends sensitive data for inference to a model hosted in a Confidential VM. Before transmitting the payload, the client challenges the VM to produce an attestation report signed by the hardware root of trust.

• The report includes the MRENCLAVE measurement, proving the exact model and runtime are unmodified.
• The client verifies the report against a reference manifest before releasing an encryption key.
• This ensures the model owner cannot see the input and the client cannot steal the model weights.

Multiple hospitals collaborate to train a diagnostic model without sharing patient data. Each hospital's enclave performs local training and produces a gradient update.

• A central aggregator attests each hospital's enclave to verify it runs the approved training code.
• Secure aggregation combines updates only from attested enclaves.
• This prevents a malicious participant from injecting poisoned gradients or inspecting aggregated contributions.

Using the Confidential Consortium Framework (CCF), multiple enterprises run a tamper-proof ledger for supply chain tracking. Each node runs inside an attested enclave.

• Nodes attest to each other before forming the consortium, establishing a trusted computing base for governance.
• The attestation report proves the exact version of the CCF application is running.
• All transactions are endorsed within attested enclaves, providing cryptographic proof of correct execution for auditors.

Two financial institutions want to discover common money-laundering suspects without revealing their full customer lists. A neutral enclave acts as the computation broker.

• Both banks attest the broker's enclave to verify it runs the exact Private Set Intersection protocol.
• Each bank provisions its encrypted dataset to the attested enclave.
• The enclave computes the intersection and outputs only the matching records, then cryptographically proves it discarded all non-matching data.

An autonomous drone processes classified sensor data using an on-device ARM CCA Realm. Before the command center streams mission data, it attests the drone's runtime.

• The attestation verifies the drone's firmware, operating system, and ML model have not been tampered with.
• The report includes hardware-backed platform configuration registers to detect physical tampering.
• Only after successful attestation is the encryption key for the mission data released to the Realm.

An enclave needs to persist state across restarts. It uses data sealing to encrypt secrets to a key derived from its own identity and the platform's TPM.

• On restart, the enclave requests its sealed blob from untrusted storage.
• The hardware verifies the current enclave's measurement matches the sealing identity.
• If the enclave code has been updated or moved to a different machine, decryption fails, preventing secret exfiltration.