Skip to content

04 — Trusted Execution Environments

Technical Overview

A Trusted Execution Environment (TEE) is a hardware-isolated environment with the following properties: 1. Confidentiality: code and data inside are encrypted and inaccessible to the main OS, hypervisor, and other tenants. 2. Integrity: execution cannot be tampered with by a privileged adversary. 3. Remote attestation: a remote party can cryptographically verify that specific software is running in a genuine TEE.

TEEs solve a problem that software-alone security cannot: they protect against a malicious or compromised privileged layer. If you run a database in a cloud VM, the cloud provider's hypervisor can, in principle, read your VM's memory. TEEs—specifically Intel SGX and AMD SEV—close this gap. The threat model shifts from "trust the cloud provider" to "trust the CPU manufacturer."

Prerequisites

  • x86-64 memory management (page tables, virtual to physical translation).
  • Symmetric and asymmetric cryptography basics (AES-GCM, RSA, ECDSA).
  • TLS/PKI fundamentals.
  • Virtualization fundamentals (hypervisor, VMM, VMCS).

Core Content

Intel SGX (Software Guard Extensions)

SGX (Intel Skylake, 2015) introduces enclaves: user-space code regions with hardware-encrypted memory, isolated from the OS, hypervisor, and all other processes.

SGX Memory Model

Physical Memory
┌─────────────────────────────────────────────────────────────────┐
│                    Regular DRAM (unencrypted)                   │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │               PRM (Processor Reserved Memory)             │ │
│  │  ┌──────────────────────────────────────────────────────┐ │ │
│  │  │              EPC (Enclave Page Cache)                │ │ │
│  │  │  Pages encrypted with MEE (Memory Encryption Engine) │ │ │
│  │  │                                                      │ │ │
│  │  │  Enclave A pages  |  Enclave B pages  |  EPCM       │ │ │
│  │  │  (only A's CPU    |  (only B's CPU    |  (metadata)  │ │ │
│  │  │   can decrypt)    |   can decrypt)    |              │ │ │
│  │  └──────────────────────────────────────────────────────┘ │ │
│  └────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

MEE: Memory Encryption Engine (on-die hardware, AES-CTR)
EPC: Limited to ~128MB on most SGX v1 platforms (SGX v2: up to several GB)
EPCM: Enclave Page Cache Map — records which enclave owns each EPC page

The OS/hypervisor manages EPC page mappings but cannot read their content—the CPU decrypts pages only when they're in the L1 cache, and only for the enclave's code.

SGX Instructions

Key SGX instructions (ring 0 for management, ring 3 for enclave operation):

ECREATE: Create an enclave (assign MRENCLAVE measurement)
EADD:    Add a page to an enclave
EEXTEND: Extend enclave measurement (SHA-256 hash of content)
EINIT:   Finalize enclave, verify measurement against SIGSTRUCT
EENTER:  Transition into enclave (ring 3, enclave's code)
EEXIT:   Return from enclave to untrusted code
ERESUME: Resume after AEX (Asynchronous Enclave Exit)
EGETKEY: Get sealing/reporting key from hardware
EREPORT: Generate attestation report

SGX Threat Model

SGX protects enclave code and data from: - Malicious or compromised OS kernel - Malicious or compromised hypervisor / VMM - Physical DRAM attacks (bus probing, cold boot) — MEE prevents - Other enclaves and processes

SGX does not protect against: - The CPU die itself (Intel's manufacturing) - Cache side-channel attacks (no MMU-level isolation of cache sets) - Power analysis (not relevant for most threat models)

This is the "trusted CPU, untrusted everything else" model—ideal for cloud workloads where you don't trust the provider.

Remote Attestation

Remote attestation allows a verifier (client) to confirm that: 1. An enclave is running on genuine Intel SGX hardware. 2. The enclave contains specific, unmodified code (by MRENCLAVE measurement).

Enclave                     Intel Attestation Service (IAS)
    │                                   │
    │  EREPORT → local report           │
    │  (signed with key derived from    │
    │   CPU's EPID/DCAP keys)           │
    │                                   │
    ▼                                   │
 Quote (via QE — Quoting Enclave)       │
    │                                   │
    └──── Submit quote ────────────────►│
                                        │
                                        │  Verify quote signature
                                        │  against Intel's root CA
                                        │
          ◄── Attestation Verification Report ──
               (signed by IAS: enclave is genuine)
    │
    ▼
Client can now establish TLS with the enclave
(only after attestation confirms code is correct)

Modern SGX uses DCAP (Data Center Attestation Primitives)—local attestation without contacting Intel's IAS service, for datacenter deployments.

SGX v2 and EDMM

SGX v2 (Ice Lake Xeon, 2021) adds: - EDMM (Enclave Dynamic Memory Management): enclaves can dynamically add/remove EPC pages without re-creation. Solves SGX v1's constraint that the enclave size is fixed at creation. - Increased EPC capacity (up to several GB per socket). - Support for up to 1 TB of enclave virtual address space.

SGX Limitations: Cache Side-Channels

SGX enclaves share the LLC with other processes. Cache side-channel attacks exploit this:

SGAxe (CVE-2020-0549, 2020): extracts secrets from SGX enclaves using a variant of RDRAND microarchitecture vulnerabilities. Allows an attacker with OS/hypervisor privileges to extract enclave secrets.

LVI (Load Value Injection, CVE-2020-0551): an inversion of Meltdown. Instead of reading data from the victim, the attacker injects values into the victim's speculative execution. Can cause enclave to encrypt attacker-controlled data, revealing the key.

Plundervolt (CVE-2019-11157): undervolts the CPU via the MSR interface (privileged, but the OS has this privilege). Voltage glitches cause computation errors inside the enclave, leaking key material.

Mitigations: LLVM -enclave-hardening, memory access obliviousness (ORAM—Oblivious RAM), and constant-time implementations of cryptographic code.

AMD SEV (Secure Encrypted Virtualization)

AMD SEV (EPYC Naples, 2017) encrypts entire VM memory with a per-VM key managed by the AMD Secure Processor (an ARM TrustZone core integrated into the EPYC SoC).

EPYC CPU Die
┌─────────────────────────────────────────────────────────┐
│                                                         │
│  x86 Cores  │  IOMMU  │  AMD Secure Processor (SP)     │
│             │         │  ┌────────────────────────────┐ │
│             │         │  │ AES-128 per-VM encryption  │ │
│             │         │  │ VM Key Table               │ │
│             │         │  │ (hypervisor cannot access) │ │
│             │         │  └────────────────────────────┘ │
│             │         │                                 │
│  ┌──────────────────────────────────────────────────┐   │
│  │                    DRAM Controller               │   │
│  │  VM A pages: encrypted with key A                │   │
│  │  VM B pages: encrypted with key B                │   │
│  │  Hypervisor pages: encrypted with hypervisor key │   │
│  └──────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────┘

The hypervisor manages page table mappings but sees only ciphertext when reading guest memory.

SEV-ES (Encrypted State): extends SEV to also encrypt CPU register state on VM exit/entry—preventing the hypervisor from reading register contents during VM exits.

SEV-SNP (Secure Nested Paging): adds: - Memory integrity: pages have a Reverse Map Table (RMP) entry that records which VM owns them. The CPU verifies ownership on access, preventing replay attacks, page aliasing, and remapping attacks where the hypervisor redirects page table entries to spy on another VM's data. - VM integrity: VM state is attested; modifications are detected.

SEV-SNP (EPYC Milan, 2021) is the production-grade confidential VM technology.

# Check SEV support
dmesg | grep -i sev
cat /sys/module/kvm_amd/parameters/sev
cat /sys/module/kvm_amd/parameters/sev_es
cat /sys/module/kvm_amd/parameters/sev_snp

# Launch an SEV-SNP VM with QEMU
qemu-system-x86_64 \
  -machine q35,confidential-guest-support=sev0 \
  -object sev-snp-guest,id=sev0,policy=0x30000 \
  ...

ARM TrustZone

TrustZone (ARM Cortex-A, 2003; standard on all modern ARM SoCs) partitions the CPU into two worlds:

  • Secure World (SW): runs the Trusted Execution Environment OS (e.g., OP-TEE, Qualcomm QSEE, Samsung TEEgris).
  • Normal World (NW): runs the main OS (Linux, Android, iOS).
ARM Core
┌──────────────────────────────────────────┐
│           Normal World                   │
│  Android OS, apps, kernel                │
│  No access to Secure World memory/devices│
├──────────────────────────────────────────┤
│  SMC instruction (Secure Monitor Call)   │
│  ← only crossing point between worlds   │
├──────────────────────────────────────────┤
│           Secure World                   │
│  Trusted OS (OP-TEE, vendor-specific)    │
│  Trusted Applications (TAs):             │
│    - DRM key storage (Widevine L1)       │
│    - Biometric verification (fingerprint)│
│    - Secure payment processing           │
│    - Hardware-backed Keystore (Android)  │
└──────────────────────────────────────────┘

TrustZone uses a NS (Non-Secure) bit in every memory transaction. Hardware enforces that NS=1 transactions (from Normal World) cannot access Secure World memory pages.

Use cases: - Android Keystore: cryptographic keys are stored in Secure World; signing/decryption operations happen there; the key material never leaves TrustZone. - DRM (Widevine L1): video decryption happens in Secure World; decrypted frames are transferred directly to the display controller without touching Normal World memory. - FIDO2 / biometric authentication: fingerprint matching in Secure World prevents a malicious Android app from accessing the fingerprint template.

TPM (Trusted Platform Module)

TPM (ISO/IEC 11889) is a dedicated security microcontroller or firmware implementation providing: - Measured boot: each boot stage hashes the next stage and extends a PCR (Platform Configuration Register). The final PCR state cryptographically summarizes the entire boot sequence. - Remote attestation: TPM signs a quote of PCR values with its attestation key. A verifier with the TPM's public key can confirm exactly what software was booted. - Sealed storage: encrypt a key bound to specific PCR values. The key can only be recovered if the system booted exactly the same software. - Key generation: hardware-based RSA/ECC key generation with the private key never leaving the TPM.

# Check TPM availability
ls /dev/tpm0  # physical TPM
ls /dev/tpmrm0  # TPM resource manager

# Read PCR values
tpm2_pcrread sha256:0,1,2,3,4,5,6,7

# Create an attestation quote
tpm2_quote --key-context key.ctx --pcr-list sha256:0,1,2,3 \
           --message nonce.bin --signature sig.bin --qualification qual.bin

# Seal a secret to current PCR state
echo -n "mysecret" | tpm2_create -C 0x81000000 \
  -g sha256 -G aes128 -i /dev/stdin -u sealed.pub -r sealed.priv \
  -L "sha256:0,1,2,3,4,5,6,7"

TPM + LUKS disk encryption: systemd-cryptenroll binds LUKS disk decryption to TPM PCR values, enabling auto-unlock only when the system boots exactly the same firmware/bootloader (measured boot verification).

Confidential Computing Use Cases

Medical data processing in untrusted cloud: A hospital outsources computation on patient data to a cloud provider. Using SGX or SEV-SNP: 1. Patient data is encrypted before upload. 2. The TEE decrypts and processes inside the enclave/confidential VM. 3. Only encrypted results leave the TEE. 4. Remote attestation proves the processing code hasn't been tampered with. 5. The cloud provider cannot read any patient data.

Blockchain key custody: Cryptocurrency exchanges using HSMs (Hardware Security Modules) traditionally required dedicated hardware. TEEs (especially SGX enclaves) enable "cloud HSMs"—cryptographic keys generated and used inside enclaves with hardware-attested security guarantees.

Multi-party computation (MPC): Multiple companies share data for analysis (e.g., fraud detection across banks) without revealing raw data to each other. TEE attestation ensures each party's code runs unmodified and the shared computation is private.

Historical Context

TrustZone was the first widely-deployed TEE technology (2003), driven by DRM requirements for content protection on mobile devices. It remains the dominant TEE on mobile hardware.

Intel SGX was announced in 2013 and shipped in Skylake (2015). It attracted significant research attention as the first widely-available TEE that protected against a malicious OS/hypervisor. However, the volume of side-channel vulnerabilities discovered (2018–2022) significantly undermined confidence in SGX's security guarantees.

AMD SEV was announced at 2016 Hot Chips and shipped in Naples (2017). SEV-SNP (2021) added the integrity guarantees needed for production confidential computing.

The Confidential Computing Consortium (Linux Foundation, 2019) standardizes APIs and attestation protocols across TEE implementations (SGX, TDX, SEV-SNP, TrustZone).

Intel TDX (Trust Domain Extensions, 2023) provides VM-level confidential computing analogous to AMD SEV-SNP but from Intel, replacing SGX for VM workloads.

Production Examples

Case: Azure Confidential Computing with SGX. Azure's DC-series instances expose SGX enclaves to tenant VMs. Fortanix (encrypted databases), Signal (private contact intersection), and various blockchain applications use Azure's SGX-enabled instances for key custody and private computation. Attestation goes through Azure Attestation Service (local DCAP, no dependency on Intel IAS).

Case: AWS Nitro Enclaves. AWS Nitro Enclaves (2020) use the Nitro hypervisor and a dedicated attestation mechanism rather than Intel SGX directly. They isolate a partition of the EC2 instance's memory as an "enclave" with no persistent storage, no interactive access, and cryptographic attestation. Used for processing payment card data (PCI DSS scope reduction) and secrets management.

Debugging Notes

# SGX: check enclave MRENCLAVE measurement
sgx_sign measure -enclave enclave.so -out measurement.txt

# Check SGX EPC usage
cat /sys/kernel/debug/x86/sgx_epc_pages  # EPC pages used

# AMD SEV: verify VM is running under SEV-SNP
# Inside the guest:
dmesg | grep -i sev
cat /sys/kernel/security/sev

# TrustZone: interact with Trusted Applications (Android)
# Use Keystore API — direct TA access is not available to apps

# TPM tools
tpm2_getcap handles-persistent  # list persisted keys
tpm2_nvread 0x01c00002          # read NV index

Security Implications

Attestation chain of trust: TEE security ultimately depends on trusting the CPU manufacturer's root key. Intel's SGX attestation root of trust is Intel's manufacturing key. A compromise of Intel's key hierarchy (or a vulnerability in the TEE implementation) breaks the entire attestation model.

Side-channel attacks on TEEs: SGX in particular has suffered from a series of cache and microarchitectural side-channel attacks (see SGAxe, LVI, Plundervolt above). Each required mitigations that imposed performance penalties. AMD SEV-SNP was designed with stronger memory integrity but still shares the same CPU microarchitecture vulnerabilities as non-TEE code.

Supply chain: TEEs attest that specific code is running. They do not attest that the code is correct, unvulnerable, or aligned with the user's interests. A TEE can run backdoored code with the same attestation guarantees as clean code—the user must still trust the software vendor.

Performance Implications

SGX EPC eviction (when enclave size exceeds EPC capacity): the kernel must swap EPC pages to regular DRAM (encrypted), which involves: - Encrypting the page with a new version counter. - Updating the EPCM entry. - Page fault on re-access.

This can be 100x slower than a normal page fault. SGX v1 workloads must fit within the EPC (historically 64–128 MB). SGX v2's EDMM and larger EPC (up to several GB) addresses this.

AMD SEV-SNP performance: encryption is done by the memory controller; effective throughput reduction is ~3–5% vs. plaintext VMs. Attestation adds startup latency (~100 ms) but does not affect steady-state performance.

Failure Modes and Real Incidents

SGX side-channels (2018–2022): A series of attacks demonstrated that the LLC shared between the enclave and the rest of the system could be used to extract secrets from enclaves: - Foreshadow / L1TF (CVE-2018-3615, 2018): L1 terminal fault attack could read enclave memory from another hyperthread. Intel disabled SGX on machines without microcode patches. - SGAxe (CVE-2020-0549): persistently extract EPID attestation keys, allowing impersonation of genuine SGX hardware. Intel released microcode fixes and revoked compromised platform keys. - LVI (CVE-2020-0551): inject values into speculative execution paths inside the enclave. Mitigation required serializing loads (LFENCE), with ~2–19x performance overhead for enclave code.

These incidents fundamentally changed the SGX threat model—it cannot protect against an adversary with access to the same physical CPU or neighboring VMs (hyperthreading).

Modern Usage

Confidential VMs are the dominant TEE deployment model in 2024–2026: - Azure: CVM (Confidential VM) with AMD SEV-SNP. - Google: Confidential GKE with AMD SEV-SNP. - AWS: Nitro Enclaves (proprietary) and bare-metal SGX instances.

Intel TDX (Trust Domain Extensions) is the Intel equivalent of AMD SEV-SNP: VM-level confidentiality with hardware attestation. Intel TDX shipped in Sapphire Rapids (2023).

All major TEEs are now part of the Confidential Computing Consortium (CCC) under the Linux Foundation, which standardizes attestation APIs (RATS, Remote Attestation Procedures) and porting toolkits.

Future Directions

  • TEE-enabled databases: CipherStash, Edgeless Systems (EDB) run entire PostgreSQL inside SGX enclaves.
  • Confidential containers (OCI): Kata Containers + SEV-SNP or TDX provides pod-level TEE isolation in Kubernetes.
  • RISC-V Keystone: an open-source TEE framework for RISC-V processors, enabling academic research and embedded TEE implementations without proprietary hardware.
  • Post-quantum attestation: current SGX/TPM attestation uses RSA/ECDSA; migration to CRYSTALS-Dilithium or similar post-quantum signatures is underway.

Exercises

  1. Examine Intel's SGX memory encryption diagram. Explain why the MEE can encrypt DRAM without the OS or hypervisor knowing the key, and what prevents the OS from changing the encryption key.

  2. Research the Foreshadow attack (CVE-2018-3615). Write a two-paragraph technical description of the exploit mechanism, why SGX's L1 cache isolation was insufficient, and what the microcode mitigation does.

  3. Compare AMD SEV vs. SEV-ES vs. SEV-SNP. Create a table showing what each variant protects (memory contents, register state, memory integrity) and against which threat actors (curious hypervisor, actively malicious hypervisor).

  4. Using the tpm2-tools package, perform a measured boot simulation: (a) read the current PCR values, (b) seal a secret to those PCR values, (c) unseal the secret. Explain why the unseal would fail if any PCR value changed.

  5. Design a threat model for a medical data processing application using SGX. List: what secrets the enclave protects, what the attestation verifies, what side-channel attacks remain possible, and what mitigations you would apply.

References

  • McKeen, F. et al. "Innovative Instructions and Software Model for Isolated Execution." HASP 2013. (SGX original paper.)
  • Costan, V., Devadas, S. "Intel SGX Explained." IACR ePrint, 2016. https://eprint.iacr.org/2016/086.pdf
  • Wilke, L. et al. "SGAxe: How SGX Fails in Practice." USENIX Security 2020.
  • Murdock, K. et al. "Plundervolt: Software-based Fault Injection Attacks against Intel SGX." IEEE S&P 2020.
  • AMD SEV-SNP whitepaper: https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
  • ARM TrustZone: https://developer.arm.com/ip-products/security-ip/trustzone
  • Confidential Computing Consortium: https://confidentialcomputing.io/
  • Intel TDX: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html
  • RATS (Remote Attestation Procedures): RFC 9334.