Confidential Container

A hardware-enforced secure area within a main processor that guarantees the confidentiality and integrity of code and data loaded inside it. The TEE isolates sensitive computation from the host operating system, hypervisor, and other privileged processes.

• Key properties: Data isolation, memory encryption, and integrity protection
• Examples: Intel SGX enclaves, AMD SEV-SNP, ARM TrustZone
• Role in confidential containers: Provides the foundational isolation layer that protects containerized workloads from the underlying infrastructure

A cryptographic mechanism that enables a remote client to verify the identity and integrity of a software stack running inside a TEE on an untrusted host. The TEE generates a signed report containing measurements of the code and platform state.

• Process: The TEE produces an attestation quote signed by a hardware-rooted key, which is verified against the manufacturer's reference values
• Critical for confidential containers: Ensures the container image hasn't been tampered with and is running on genuine hardware before any secrets are provisioned
• Protocols: Intel DCAP, AMD SEV-SNP Attestation, Azure Attestation

A hardware mechanism that transparently encrypts and decrypts data as it moves between the processor and main memory (DRAM). This prevents physical attackers from reading sensitive data through DRAM probing, cold boot attacks, or bus snooping.

• Implementation: AES-XTS encryption engines integrated into the memory controller, operating at line speed with minimal latency
• AMD SEV: Encrypts entire VM memory with a unique key per VM
• Intel MKTME: Multi-Key Total Memory Encryption supports multiple encryption keys for different memory pages
• Impact: Eliminates the hypervisor and cloud provider from the trust boundary for data-in-use

The process by which a TEE generates a cryptographically signed report to prove its identity, integrity, and that it is running specific code on genuine hardware. This establishes a hardware-rooted chain of trust between the workload and a remote relying party.

• Local attestation: Two enclaves on the same platform verify each other's identity
• Remote attestation: A remote server verifies the enclave's authenticity before trusting it
• Attestation report contents: Enclave identity (MRENCLAVE), signer identity (MRSIGNER), product ID, security version number, and platform TCB status
• Verification: The report signature is validated against the manufacturer's certificate chain

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.

• Seal to enclave identity: Data bound to the enclave's measurement (MRENCLAVE), ensuring only identical code can decrypt it
• Seal to signer identity: Data bound to the enclave author's identity (MRSIGNER), allowing versioned enclaves from the same author to access the data
• Use case: Securely persisting sensitive state across enclave restarts without exposing it to the untrusted host OS

A physically immutable, inherently trusted source within a computing platform that serves as the foundation for all subsequent security operations. It is the anchor point from which the entire chain of trust extends.

• Components: Fused cryptographic keys burned into silicon during manufacturing, immutable boot ROM, and on-die random number generators
• Functions: Secure boot verification, cryptographic key generation, and platform identity attestation
• In confidential containers: The hardware root of trust ensures that attestation reports originate from genuine silicon, not emulated environments
• Examples: Intel's fuse-derived Root Key, AMD's Platform Secure Processor (PSP)