Backdrop: What are TEEs and adjacent technologies?
What is a TEE?
A Trusted Execution Environment (TEE) is an isolated computing context that provides:
- Confidentiality and integrity of code and data inside the TEE, even if the host OS, hypervisor, or firmware is compromised.
- A measurable identity, meaning a cryptographic measurement of the code and configuration.
- Attestation, i.e., a cryptographic proof (signed by silicon-rooted keys) that communicates:
- what code is running,
- on which hardware,
- and in what security state.
- Sealed storage, enabling encryption of data at rest using keys derived from TEE identity.
- Controlled I/O and IPC bridges to communicate with the untrusted world.
TEE design families:
-
Process-/Enclave-style TEEs
Examples: Intel SGX, RISC-V Keystone- Isolation below the OS, using a process-like abstraction.
-
VM-style / Confidential VM TEEs
Examples: AMD SEV-SNP, Intel TDX, IBM PEF, IBM s390x Secure Execution- Isolation below the hypervisor, protecting whole virtual machines.
Additionally, secure-world TEEs (e.g., Arm TrustZone / Arm CCA) partition the CPU into secure and normal worlds.
Threat model
Adversary capabilities:
- Malicious kernel, hypervisor, co-tenant, or cloud administrator
- Physical attackers (to a limited, realistic extent)
TEE protects:
- Memory and state inside an enclave/realm/TD/secure world
- Confidentiality and integrity of code and secrets
Not fully protected without additional controls:
- Side-channels (cache/branch/speculative execution)
- Denial of service
- Traffic analysis
- Plaintext I/O outside the TEE boundary
- Developer bugs and logic flaws
Core building blocks
Key architectural components:
- Isolation primitives: memory encryption engines, integrity/Merkle trees, page-table tagging, secure execution levels.
- Boot / roots of trust: immutable ROM, firmware/microcode, device-unique keys, certificate chains.
- Attestation pipeline: measurement → report → endorsement (chip/vendor certs) → remote attestation.
- Sealing keys: derive per-enclave/per-CPU encryption keys for data at rest.
- Bridging mechanisms (untrusted ↔ trusted world):
- SGX: ECALL / OCALL
- TrustZone / CCA: SMC calls
- SEV-SNP: GHCB
- TDX: TDVMCALL
- Lifecycle phases: load → measure → initialize → attest → run → update/rotate → teardown
Key terminology
Generic
- Measurement: cryptographic hash of code and configuration used as identity.
- Local vs remote attestation: local (same machine peers) vs remote (external verifier).
- Sealing: encrypting data using a key derived from TEE identity.
- Provisioning: injecting secrets after attestation verification.
Intel SGX
- Enclave: isolated region for code + data.
- MRENCLAVE / MRSIGNER: measurement of code / signer identity.
- QE / PCE / LE: Quoting / Provisioning / Launch enclaves.
- DCAP / EPID: attestation schemes.
- MEE / MECT: memory encryption + integrity tree.
Intel TDX (VM TEE)
- TD: Trusted Domain (guest VM).
- TDX Module: isolation logic below hypervisor.
- TDVMCALL: interface for TD ↔ VMM.
- Quote: attestation artifact.
AMD SEV family (VM TEE)
- SEV / SEV-ES / SEV-SNP: baseline / encrypted state / secure nested paging (adds integrity).
- PSP: Platform Security Processor.
- ASK/ARK / CEK/VCEK: AMD attestation key hierarchy.
- GHCB: Guest-Hypervisor Communication Block.
Arm TrustZone (secure world)
- Normal vs Secure world: CPU partition.
- EL3 / Monitor / SMC: world switching.
- Secure OS / TEE: OP-TEE, QSEE, Kinibi.
- TA / CA: Trusted Application vs Client Application.
- GlobalPlatform TEE: common API/spec ecosystem.
Arm CCA (Realm-based)
- Realm: new isolated world (beyond Secure/Normal).
- RMM: Realm Management Monitor.
- REC: Realm Execution Context.
- CCA Attestation: vendor-signed attestation for realms.
IBM platforms
- PEF: Protected Execution Facility.
- Ultravisor: firmware enforcing TEE policy.
- s390x Secure Execution: protected virtualization on IBM Z.
RISC-V
- Keystone: enclave framework.
- SM: Security Monitor.
Apple / Mobile SoCs
- Secure Enclave (SEP): co-processor TEE.
- Keybags / UID key: device-bound keying material.
- Android TEEs: TrustZone (with Vendor TEE OS) + Android StrongBox (sometimes with a separate secure element).
Attestation in practice
- TEE creates a report (measurements + security version numbers).
- A device-local trusted service signs the report using endorsement keys anchored in silicon and a vendor cert chain.
- A relying party verifies:
- signature and cert chain,
- measurements/configuration (hashes, config, PCR/SVN levels),
- policies (version, signer identity, etc.).
- If valid, the verifying party securely provisions secrets.
Developer surface
- GlobalPlatform TEE APIs (client/core) on TrustZone TEEs (OP-TEE, commercial TEEs).
- Intel SGX SDK, Open Enclave SDK, Gramine/Graphene, SCONE, Occlum, Enarx: higher-level runtimes for enclaves/TEE portability.
- TDX/SEV-SNP Confidential VM tooling: use normal OS images; add attestation agent (e.g., AK/SNP/TDX agents) and paravisor interfaces.
- Keystone SDK on RISC-V.
Non-comprehensive platform map (by abstraction)
Process-/enclave-style TEEs
- Intel SGX (client & server generations; strong process isolation, memory integrity trees, DCAP attestation).
- RISC-V Keystone (open-source, research-to-productization).
- Academic lineage: Sanctum, MI6 (conceptual predecessors).
VM-style TEEs (Confidential VMs)
- AMD SEV → SEV-ES → SEV-SNP (widely used in clouds; memory encryption + integrity; attestation via PSP).
- Intel TDX (similar goal; TDs protected from VMM with TDX Module; remote attestation).
- IBM POWER PEF (Ultravisor-secured VMs).
- IBM Z (s390x) Secure Execution / Protected Virtualization.
- Arm CCA Realms (armv9-era: Realm world + RMM, designed for cloud-scale CVMs).
Secure-world / split-world TEEs (services & TAs)
- Arm TrustZone implementations:
- OP-TEE (open-source TEE OS; common in embedded/edge).
- Qualcomm QSEE, Trustonic Kinibi, Huawei iTrustee, Samsung TEEgris (commercial TEEs on phones/SoCs).
- Apple Secure Enclave (SEP) (coprocessor TEE for key/biometric policy).
Device/accelerator TEEs
- NVIDIA Hopper (H100) Confidential Computing (GPU-side isolated execution + attestation for kernels).
- AMD GPU enclaves (emerging, often coordinated with CPU-side CVMs).
- SmartNIC/DPUs (e.g., BlueField) with RoT and attestation to run network/security functions in a TEE-like domain.
How TEEs isolate memory/state
- Encrypt-only (SME/SEV) vs encrypt+integrity (SGX MEE, SEV-SNP RMP, TDX).
- Page table ownership: second-stage/NPT/EPT with protected metadata (e.g., RMP for SEV-SNP, EPT attributes for SGX/TDX).
- World partitioning (TrustZone S/NS memory tagging; CCA introduces a new Realm world).
- Microcode/firmware arbitration (PSP, TDX module, ultravisor, monitor).
Security caveats
- Side channels: timing/cache/branch/spectre, page-fault, controlled-channel. Use constant-time crypto, oblivious access, page-level padding, partitioned caches where possible.
- I/O exposure: data must be encrypted/authenticated end-to-end before leaving the TEE.
- Updatability: track SVNs/TCBs, require minimum versions in attestation policy.
- Supply chain: pin vendor certs, check revocation (CRLs/OCSP/equivalents).
- Denial of Service: the host can starve/suspend your TEE.
Standards & ecosystems
- GlobalPlatform defines TEE Internal Core and Client APIs as well as management and compliance standards for TrustZone-class TEEs.
- Confidential Computing Consortium (CNCF/LF) defines standards for attestation formats and confidential computing runtimes which rely on underlying TEE / SE for security guarantees. For example projects like Enarx, Open Enclave etc.
- IETF RATS: Defines the syntax and semantics for attestation, specifically EAT (Entity Attestation Token) & Attestation Results patterns (with CBOR/COSE/JWT encodings increasingly used). It standardizes how to convey claims about a TEE's state (e.g., "this TEE is running certified firmware X, version Y, with measurements Z").
- Common Criteria EAL (Evaluation Assurance Level): Provides independent evaluation/proof that a specific implementation of a TEE or SE (also known as Target of Evaluation or TOE), adhering to any of the standards mentioned above, has been built and evaluated to a rigorous level of assurance as per target specifications, with no exploitable vulnerabilities at that level. EAL levels are defined from EAL1 to EAL7 with each increasing level having stricter requirements to prove security assurances (in addition to meting the requirement of previous levels). Below is a table for quick reference.
| EAL Level | Focus | Evaluation | Use-Case |
|---|---|---|---|
| EAL1 | Functionally Tested | Provides analysis of the security functions, using a functional and interface specification of the TOE, to understand the security behaviour | Low-risk, need a basic check. (e.g., consumer OS) |
| EAL2 | Structurally Tested | Independent testing of the security functions, evidence of developer "black box" testing, and evidence of a developer search for obvious vulnerabilities. | Legacy systems; requires developer cooperation |
| EAL3 | Methodically tested and checked | The analysis is supported by "grey box" testing, selective independent confirmation of the developer test results, and evidence of a developer search for obvious vulnerabilities. Development environment controls and TOE configuration management are also required. | Good balance of rigor vs. cost. (e.g., network gear) |
| EAL4 | Methodically designed, tested and reviewed | Analysis is supported by the low-level design the TOE, and a subset of the implementation. Testing is supported by an independent search for obvious vulnerabilities. Development controls are supported by a life-cycle model, identification of tools, and automated configuration management. | The most common level for commercial security products. (e.g., TEEs, Smart Cards) |
| EAL5 | Semi-formally designed and tested | Analysis includes all of the implementation. Assurance is supplemented by a formal model and a semiformal presentation of the functional specification and high level design, and a semiformal demonstration of correspondence. The search for vulnerabilities must ensure relative resistance to penetration attack. Covert channel analysis and modular design are also required. | High-assurance for high-risk environments. (e.g., Banking, Military) |
| EAL6 | Semi-formally verified designed and tested | Analysis is supported by a modular and layered approach to design, and a structured presentation of the implementation. The independent search for vulnerabilities must ensure high resistance to penetration attack. The search for covert channels must be systematic. | Extremely high-assurance for significant risks |
| EAL7 | Formally verified design and tested | The formal model is supplemented by a formal presentation of the functional specification and high level design showing correspondence. Evidence of developer "white box" testing and complete independent confirmation of developer test results are required. | For the most critical, small-scale applications |
Similar / adjacent tech
- TPM (dTPM/fTPM): not a TEE for general code, but a measurement/keys co-processor; often supplies PCR-based boot trust and can help bind secrets to a platform state.
- Secure Elements / Smartcards (UICC/eSIM, embedded SE, Google StrongBox): isolated chips for keys/identity; narrower execution models than general-purpose TEEs.
- HSMs: external appliances/cards that provide isolated crypto + key custody (enterprise/server side).
- AWS Nitro Enclaves: software & hypervisor isolation splitting a VM into an enclave VM with no persistent storage/network; not silicon-enclave, but a practical alternative in cloud.
- Apple SEP (again): co-processor TEE archetype; not general-purpose for arbitrary apps but sets the reference for UX-grade key protection.
- OpenTitan: open silicon root of trust; pairs with TEEs to anchor attestation.
Picking the right model
| Goal | Recommended TEE Model |
|---|---|
| Whole OS isolation; reuse existing stacks | Confidential VMs (SEV-SNP, TDX, PEF, s390x, Arm CCA) |
| Minimal TCB, process-level isolation | SGX / Keystone |
| Mobile / embedded | TrustZone + GlobalPlatform |
| Device-grade key custody | SEP / Secure Element / TPM / HSM |
| ML secrecy | GPU TEEs paired with CVM + attestation |
Minimal developer toolbox (by target)
- SGX: Intel SGX SDK, Open Enclave, Gramine/Graphene, SCONE, Occlum.
- SEV-SNP/TDX/PEF/s390x: Standard guest OS + attestation agent (e.g., SNP/TDX agents), KMS plugins for secret injection, distroless base images for smaller TCB.
- TrustZone/CCA: OP-TEE + GlobalPlatform Client/Core APIs; vendor TEEs similar shape.
- Keystone: Keystone SDK; host SM + runtime in enclave.
Attestation Artifacts (by vendor)
| Platform | Artifact |
|---|---|
SGX | Quote (EPID/DCAP), Certificate Chain to Intel Root CA, MRENCLAVE/MRSIGNER/ISVSVN |
TDX | TD Quote with TCB components (TDX-SEAM microcode) |
SEV-SNP | Attestation report (signed by PSP), VCEK Certificate per CPU, RMP based integrity claims |
Arm CCA | Realm attestation token (EAT/CBOR), Realm Measurement + RMM and firmware versions |
IBM | Vendor-signed reports via ultravisor |
TrustZone | Platform-specific implementations, usually through GlobalPlatform APIs or vendor attestation flows. |
NVIDIA Confidential Compute | HSI (H100-Style) Attestation Report, signed by GPU Root of Trust, includes GPU TCB (FW, BL, Config) and user-defined measurement (Nonces, VM ID) |
Architectural Spectrum of TEE Implementations
| Type | Representative Examples | Isolation Mechanism | Key Trust Anchor | Security Profile |
|---|---|---|---|---|
| Software-defined TEE | AWS Nitro Enclaves, gVisor-like isolation, Enarx (on CVMs), library OS TEEs | Software isolation (hypervisor/VM or namespace boundaries) | Cloud firmware + VM configuration | Flexible, low hardware trust; relies on hypervisor/firmware correctness |
| CPU-assisted (on-die) | Intel SGX, AMD SEV-SNP, Intel TDX, Arm CCA | Hardware memory encryption + access control | CPU microarchitecture / microcode | Strong isolation from host OS/VMM; hardware-backed attestation |
| SoC secure-world partition | Arm TrustZone, OP-TEE, Qualcomm QSEE | Secure/Normal world split, hardware arbitration | Secure boot ROM, fuses | Medium–high: secure boot verified; isolation enforced by EL3 monitor |
| Dedicated co-processor TEE | Apple Secure Enclave (SEP), Google Titan M, TPM 2.0, Android StrongBox | Physically separate core + dedicated memory | Separate firmware & RoT | Very high for key management; narrow compute model |
| Standalone secure device / SE / HSM | Smartcard, SIM, YubiKey, Hardware Security Modules | Separate chip w/ tamper resistance | Embedded secure element & crypto coprocessor | Highest physical & logical assurance (Common Criteria EAL5–EAL7) |
TEE vs SE: Conceptual and Security Comparison
| Property | TEE (Trusted Execution Environment) | SE (Secure Element / HSM / TPM) |
|---|---|---|
| Execution model | General-purpose code execution within isolated context | Limited-purpose (crypto ops, key mgmt) |
| Integration | On-SoC / CPU-based (shared die or logical partition) | Separate chip or coprocessor |
| Trust base | Depends on CPU vendor RoT, firmware, and boot chain | Dedicated silicon with minimal firmware, physically separate |
| Tamper resistance | Typically not tamper-resistant (focus on logical isolation) | Physical anti-tamper and side-channel protections |
| Physical attack surface | Higher (shared die, shared power/caches) | Lower (hardened packaging, fault detection) |
| Attestation | Software + vendor key infrastructure (DCAP, PSP, Realm tokens) | Static identity via hardware certificates (endorsement keys) |
| Performance | Near-native execution; scalable | Limited compute, I/O bottleneck |
| Certification level (typical) | EAL2–EAL4+ (logical separation) | EAL5+ to EAL7 (physical + logical separation) |
| Use cases | Confidential computing, trusted apps, enclaves, ML inference | Key storage, payment, identity, DRM, FIDO |
| Example systems | Intel SGX, AMD SEV, Arm TrustZone/CCA, IBM PEF | TPM 2.0, Titan M, Apple SEP, YubiKey, Smartcard |
Security Assurance / Certification Landscape
| Standard / Evaluation | Scope | Typical Targets | Level Description |
|---|---|---|---|
| Common Criteria (ISO/IEC 15408) | Evaluates security functionality and assurance (EAL1–EAL7) | SEs, HSMs, TPMs, some TEEs | EAL1–4: software assurance; EAL5–7: high physical tamper resistance |
| FIPS 140-2/3 | Cryptographic module validation | SEs, HSMs, TPMs | Levels 1–4; Level 3–4 require tamper response |
| GlobalPlatform TEE Protection Profile (GP TEE PP v1.3) | Logical security of TEEs | Arm TrustZone/OP-TEE, Kinibi, QSEE | Common Criteria EAL2+ baseline for TEEs |
| EMVCo | Smartcards, payment SEs | SEs / SIMs | Security & functional compliance (no EAL number) |
| PSA Certified (Arm ecosystem) | Embedded/IoT TEEs & RoTs | TrustZone-based designs | Level 1–3 map to EAL2–EAL4 equivalence |
Summary Axes for Classification
Dimension | Category | Example
-
Integration:
- Software-only isolation → Nitro Enclaves, gVisor
- CPU hardware isolation → SGX, SEV, TDX, CCA
- SoC partition → TrustZone
- Dedicated co-processor → SEP, TPM
- External secure device → HSM, SE, Smartcard
-
Trust Boundary:
- Logical (CPU microcode boundary)
- Physical (dedicated chip or tamper mesh)
-
Certification Potential:
- Logical-only (EAL2–EAL4) → typical TEEs
- Logical + physical (EAL5–EAL7) → SEs/HSMs
-
Security Guarantees Tradeoff:
- TEE: stronger flexibility, weaker physical protection
- SE: stronger hardware assurance, limited programmability
TEE & Secure Element Landscape
Interpretation Matrix
| Dimension | Lower End | Middle Tier | Higher End |
|---|---|---|---|
| Integration | Software-defined (Nitro, gVisor) | SoC-integrated (SGX, TrustZone) | Separate chip (TPM, SE, HSM) |
| Isolation Type | Software process/VM boundary | Hardware-enforced memory partition | Physical silicon barrier |
| Attestation Root | Firmware / platform key | CPU vendor RoT / Boot ROM | Device-specific key, cert chain |
| Certification (EAL/FIPS) | EAL1–EAL2 | EAL2–EAL4+ | EAL5–EAL7 / FIPS 140-3 L3+ |
| Target Use Case | Cloud & container TEEs | General compute / mobile security | Key custody, payments, identity |