Attestation

The attestation process begins with a Hardware Root of Trust physically embedded in the CPU die. This immutable foundation generates a unique, un-extractable endorsement key during manufacturing. The chain of trust extends from this silicon root through measured boot of firmware and software, with each stage cryptographically hashed into Platform Configuration Registers (PCRs). This guarantees that the attestation report reflects the genuine hardware state, not a simulated environment.

An attestation report is a structured, signed document generated by the TEE's firmware. It bundles critical claims:

• Enclave Identity (MRENCLAVE): A cryptographic hash of the enclave's initial code and data, proving what is running.
• Signer Identity (MRSIGNER): Identifies the authority that signed the enclave, proving who authored it.
• Platform TCB Info: Version information for hardware microcode and firmware, allowing the verifier to assess vulnerability status.
• User Data: An arbitrary 64-byte field for binding the report to a specific request or nonce, preventing replay attacks.

A relying party rarely parses raw attestation evidence directly. Instead, it delegates to a Verification Service that performs critical checks:

• Signature Validation: Confirms the report was signed by a genuine, provisioned hardware key.
• Revocation Status: Queries the hardware vendor's Provisioning Certification Service to ensure the platform's keys haven't been revoked due to vulnerabilities.
• Policy Evaluation: Compares the reported MRENCLAVE and MRSIGNER values against a known-good allowlist defined by the workload owner.
• TCB Freshness: Verifies that the reported firmware and microcode versions are above a minimum acceptable security baseline.

Attestation is only useful if the verified identity is bound to a subsequent secure communication channel. This is achieved through Enclave TLS or similar protocols. During the TLS handshake, the enclave embeds its attestation report into the certificate extension fields. The client verifies the report before completing the handshake, ensuring the private key for the TLS session is held exclusively within the attested enclave. This creates a cryptographically guaranteed, end-to-end encrypted channel terminating inside the protected memory region.

To prevent an attacker from capturing a valid attestation report from a legitimate TEE and replaying it later, attestation protocols mandate freshness mechanisms:

• Nonce Challenge: The relying party sends a cryptographically random nonce. The TEE must include this nonce in the report's user data field, proving the report was generated for that specific session.
• Timestamp Verification: Reports include a timestamp from the TEE's trusted clock, allowing the verifier to reject stale evidence.
• Ephemeral Key Binding: The report includes a hash of an ephemeral public key generated inside the enclave, binding the attestation to a fresh key exchange.

In complex confidential AI workflows, trust is not bilateral. Multi-party attestation allows multiple independent relying parties to verify the same enclave before contributing assets:

• A model owner verifies the enclave before releasing encrypted model weights.
• A data owner verifies the same enclave before releasing encrypted inference data.
• An auditor verifies the enclave's code transparency log to ensure compliance. All parties receive the same attestation evidence and independently evaluate it against their own security policies, establishing a collective trust fabric without a central broker.

Attestation proves what code is running, not just where. This requires deterministic builds:

• MRENCLAVE: A 256-bit hash of the enclave's initial code and data. Any change to the source code or compilation flags produces a different hash.
• Reproducible Builds: Organizations must ensure that a given source commit always produces the identical binary hash, allowing a relying party to map a known MRENCLAVE to a specific, audited codebase.
• Open Source Verification: Publishing the source code and build instructions allows any third party to independently verify that the attested hash corresponds to the expected, non-malicious logic.

How attestation secures a model serving pipeline:

1. Model Owner encrypts proprietary model weights with a key known only to a key management service (KMS).
2. Inference Server boots inside a TEE and generates an attestation report.
3. KMS validates the report against the expected MRENCLAVE and TCB version.
4. KMS releases the decryption key exclusively to the attested enclave.
5. Client sends encrypted query to the enclave, which decrypts it, runs inference, and returns the encrypted result.

This ensures the model provider's IP and the client's query data are protected from the cloud infrastructure.

The Trusted Computing Base (TCB) includes the CPU microcode, firmware, and TEE software stack. Attestation reports include TCB version numbers:

• Up-to-Date Enforcement: A relying party can refuse to release secrets to an enclave running outdated, vulnerable firmware.
• Revocation Lists: Hardware manufacturers publish signed lists of compromised hardware keys or firmware versions. The verification service checks the report against these lists.
• Key Rotation: If a vulnerability is discovered in a specific TCB version, all data sealed to that version must be migrated and re-encrypted for a patched TCB.

A secure area within a main processor that guarantees confidentiality and integrity of code and data loaded inside it. The TEE isolates sensitive computations from the host OS, hypervisor, and other privileged processes. Key implementations include:

• Intel SGX: Application-level enclaves with memory encryption
• AMD SEV: VM-level memory encryption with unique keys
• AWS Nitro Enclaves: Isolated compute with no persistent storage A compromised OS cannot read enclave memory, making TEEs foundational for data-in-use protection.

A TEE-specific cryptographic operation that encrypts data and binds it to the specific enclave identity and platform that generated it. Sealed data can only be decrypted by the exact same enclave on the exact same hardware. This provides:

• Secure local storage for enclave state across restarts
• Protection against data exfiltration to unauthorized environments
• A foundation for secure provisioning workflows where secrets are delivered only after attestation succeeds

A physically immutable, inherently trusted source within a computing platform that serves as the foundation for all subsequent security operations. In attestation workflows, the CPU manufacturer embeds a unique, unextractable private key during fabrication. This key signs the attestation report, proving the hardware is genuine. From this root, a chain of trust extends through firmware, bootloader, OS, and application layers, with each component cryptographically verified by the preceding one.

The application of confidential computing principles to artificial intelligence workloads, ensuring that model weights, training data, and inference queries remain encrypted and isolated during computation. Key protections include:

• Model providers can deploy proprietary weights without exposing them to cloud operators
• Data owners can submit sensitive queries knowing the host cannot inspect them
• Attestation verifies the inference environment before any data is released This addresses the data-in-use gap for regulated industries deploying AI.