Trusted Execution Environment (TEE)

The foundational property of a TEE is the creation of a secure enclave—a private region of memory physically isolated from the host operating system, hypervisor, and other applications. This isolation is enforced by the processor itself, not by software. Even a privileged user with root or kernel access cannot read or write to the enclave's protected memory pages. The hardware blocks all external access attempts at the bus level, ensuring that code and data inside the enclave are shielded from all other software on the system, including the cloud provider's own management stack.

A TEE includes a dedicated Memory Encryption Engine (MEE) integrated into the memory controller. This engine transparently encrypts all data written to the enclave's assigned memory region (the Enclave Page Cache) and decrypts it when read back into the CPU cache. The encryption keys are generated at boot time and never leave the processor package. This protects against cold boot attacks, DRAM probing, and physical bus sniffing. An attacker with physical access to the memory DIMMs only retrieves ciphertext, ensuring data confidentiality at rest within the memory subsystem.

Remote attestation is the cryptographic mechanism that allows a remote party to verify that a specific enclave is running unmodified code on a genuine TEE platform. The process works as follows:

• The enclave generates a cryptographic measurement (a hash) of its initial code and state.
• The hardware signs this measurement with a key fused into the processor during manufacturing.
• The remote party validates the signature against the manufacturer's certificate chain. This proves to a data owner that their sensitive data will only be processed by the exact code they expect, on a genuine, uncompromised processor, before any data is sent.

Data sealing allows an enclave to encrypt data for persistent storage outside the TEE in a way that binds the ciphertext to a specific enclave identity. The encryption key is derived from the processor's unique root key and the enclave's own cryptographic measurement. This provides two critical properties:

• Sealing to Enclave Identity: Only the exact same enclave code on the same CPU can unseal the data.
• Sealing to Signing Identity: Only enclaves signed by the same developer can unseal the data. This ensures that sensitive state can survive power cycles and be securely stored on untrusted storage, such as a cloud block store, without exposure.

A TEE radically reduces the Trusted Computing Base (TCB)—the set of all hardware, firmware, and software components critical to security. In a traditional stack, the TCB includes the entire operating system, hypervisor, and millions of lines of kernel code. In a TEE model, the TCB is reduced to:

• The processor package itself.
• The enclave application code.
• A thin, audited runtime library. The OS and hypervisor are excluded from the trust boundary entirely. This drastic reduction minimizes the attack surface and makes formal verification of the security posture practically achievable.

Beyond confidentiality, a TEE guarantees the integrity of the enclave's code and data at runtime. The hardware continuously monitors the contents of the Enclave Page Cache. Any attempt by unauthorized software or hardware to modify the enclave's memory—such as a rowhammer attack or a malicious DMA write—is detected and blocked by the processor. If a modification is detected, the system triggers a security exception, halting the enclave to prevent the execution of corrupted logic. This ensures that the computation's output is trustworthy and has not been tampered with.