Trusted Execution Environment (TEE)

A TEE establishes a strict boundary between the secure world and the normal world at the silicon level. Code and data inside the enclave reside in a physically protected memory region that the host OS, hypervisor, and DMA-capable peripherals cannot access. This isolation is enforced by the memory management unit and on-chip bus fabric, not by software policy. Any attempt by an unauthorized process to read or write enclave memory triggers a hardware fault, ensuring that even a compromised kernel cannot exfiltrate secrets.

Remote attestation is the cryptographic mechanism that allows a remote party to verify the identity, integrity, and trustworthiness of a TEE before provisioning secrets. The process works in three stages:

• Measurement: The TEE hardware generates a cryptographically signed hash of the enclave's initial code, data, and configuration.
• Verification: The remote party validates this attestation report against a trusted manufacturer's certificate chain.
• Provisioning: Only after successful verification are secrets like decryption keys transmitted over a secure channel. This prevents secrets from being sent to a malicious or tampered enclave.

TEEs protect data confidentiality and integrity even against physical attackers with access to the DRAM bus. The Memory Encryption Engine (MEE) transparently encrypts all data written from the enclave cache to main memory and decrypts it on read. Simultaneously, a Message Authentication Code (MAC) tree verifies data integrity, detecting replay attacks, splicing, and bit-flip tampering. An attacker probing the memory bus with a logic analyzer sees only ciphertext, and any unauthorized modification causes a machine check exception, halting the compromised enclave.

Sealed storage allows a TEE to persist secrets to untrusted local storage, such as a hard drive, in a way that binds them to a specific enclave identity. Data is encrypted with a Sealing Key derived from the CPU's unique fuse key and the enclave's measurement hash. This creates two binding policies:

• Sealing to Enclave Identity: Only the exact same enclave binary on the same device can unseal the data.
• Sealing to Signing Authority: Any enclave signed by the same developer's key can unseal, enabling data migration across version updates. If the enclave code is modified, the derived key changes, rendering the sealed blob permanently inaccessible.

A TEE dramatically reduces the Trusted Computing Base (TCB) for a secure workload. In a traditional stack, the TCB includes the entire OS, hypervisor, firmware, and all privileged daemons—millions of lines of code with a vast attack surface. A TEE excludes all of these. The TCB shrinks to just:

• The CPU package and its microcode.
• The enclave application code itself.
• A thin, verified runtime library. This minimization means that a vulnerability in the Linux kernel or a malicious cloud administrator cannot compromise the enclave's confidentiality or integrity.

When the OS scheduler preempts an enclave thread, the TEE hardware must securely save and restore the enclave's state without leaking data. During a context switch, the CPU:

1. Flushes the Enclave Page Cache (EPC) to encrypted main memory.
2. Saves CPU register state to a protected State Save Area (SSA) frame.
3. Clears all architectural registers to prevent data leakage to the next thread. This ensures that enclave execution is transparently multiplexed on shared cores while maintaining strict temporal isolation between the secure and normal worlds.

The foundational security anchor that establishes the chain of trust for a TEE. A Hardware Root of Trust (HRoT) is an immutable, tamper-resistant component—typically fused into silicon during manufacturing—that stores cryptographic keys and performs the initial integrity measurement during secure boot.

• Provides immutable identity for the TEE through burned-in private keys
• Performs measured boot to verify firmware and hypervisor integrity before TEE initialization
• Common implementations: Intel Boot Guard, AMD Platform Security Processor (PSP), ARM TrustZone Root of Trust
• Enables remote attestation by signing attestation reports with keys derived from the HRoT

A cryptographic protocol that enables a remote party to verify that specific code is running inside an authentic TEE on a genuine hardware platform. The TEE generates a signed attestation report containing a cryptographic hash of its memory state and identity.

• Verifier challenges the TEE and receives a quote signed by the hardware root of trust
• Report includes measurements of firmware, OS, and application code loaded into the enclave
• Establishes trustworthiness before secrets are provisioned to the enclave
• Protocols: Intel EPID/ECDSA, AMD SEV-SNP Attestation, NVIDIA Hopper Attestation

The hardware-enforced encryption engine that protects TEE-resident data from external access, including the host operating system, hypervisor, and DMA attacks. The memory encryption engine sits on the memory bus and transparently encrypts/decrypts data as it moves between the CPU cache and RAM.

• Intel MKTME: Multi-Key Total Memory Encryption with per-enclave key isolation
• AMD SME/SEV: Secure Memory Encryption with AES-128 engine and per-VM key management
• ARM CCA Realm Extension: Granular memory isolation for confidential VMs
• Protects against cold boot attacks, DMA snooping, and malicious hypervisor access

The strict isolation perimeter enforced by the CPU that separates TEE execution from the untrusted host. The enclave boundary ensures that code outside the TEE cannot read or write enclave memory, even with kernel or hypervisor privileges.

• Intel SGX: Enclave Page Cache (EPC) with hardware-enforced access control
• AMD SEV-SNP: Reverse Map Table (RMP) preventing hypervisor remapping attacks
• ARM TrustZone: Physical address space partitioning between Secure and Normal worlds
• Enforces least privilege by design—the host OS is treated as potentially compromised

A deployment model extending TEE protection to entire virtual machines rather than individual application enclaves. Confidential VMs encrypt all VM memory and CPU state, protecting workloads from the cloud provider and hypervisor without requiring application modification.

• AMD SEV-SNP: Full VM encryption with integrity protection and attestation
• Intel TDX: Trust Domain Extensions providing hardware-isolated VMs
• ARM CCA: Realm Management Extension for confidential compute in cloud environments
• Enables lift-and-shift migration of legacy applications into confidential computing

Hardware and software mitigations that protect TEEs from attacks that infer secrets through physical side effects like cache timing, power consumption, or electromagnetic emissions rather than direct memory access.

• Cache partitioning: Intel CAT (Cache Allocation Technology) prevents cross-enclave cache eviction attacks
• Constant-time cryptography: Algorithms designed to execute in uniform cycles regardless of secret values
• Speculative execution barriers: LFENCE and other serializing instructions mitigate Spectre-class attacks
• Address space layout randomization (ASLR): Applied within enclaves to complicate memory layout inference