Types of TEEs
An overview of the different types of TEEs available today:
| Type | Examples | Mechanism | Advantages | Disadvantages | Notes |
|---|---|---|---|---|---|
| Process-Based Isolation | Intel SGX | Isolated memory region within a single process (enclave); system call boundaries enforce separation | Small TCB; simple attestation; clear separation of trusted/untrusted logic | Hard to develop; needs code rewrites; poor support for legacy apps | First widely-used commercial TEE; foundational model for enclave-based security |
| VM-Based Isolation | Intel TDX, AMD SEV, ARM CCA | Entire VM runs in a hardware-isolated environment with memory encryption and extended TCB | Full OS access; high compatibility with existing apps; easy for developers | Large TCB; complex attestation; potential need for runtime monitoring | Emerging as the preferred model for cloud-native TEEs; trades security for dev ease |
| Hypervisor-Based Isolation | AWS Nitro Enclave | Uses a hypervisor and HSM to partition a VM into trusted/untrusted regions with limited hardware backing | Fast deployment on general-purpose machines; moderate development effort | Relies on EC2 host instance encryption; limited device support; weaker isolation assumptions | A transitional model between legacy and full VM-based TEEs; good for cloud services |
| Design Your Own TEE | ARM TrustZone, BYOTEE (Software + Hardware Co-design) | Developers build TEEs using hardware toolkits, implementing their own OS, attestation, and trust logic | Full control over TEE architecture; supports trusted I/O paths (e.g., camera, keyboard) | Extremely complex to implement; requires custom OS, provisioning, and attestation design | Best suited for embedded/mobile systems or privacy-critical interfaces |
| Software + Physical Isolation | SpaceTEE / SpaceComputer, Microsoft Project Natick (Hypothetical) | No hardware isolation; physical inaccessibility enforced, combined with software-only control and trust | Works on any hardware; physically tamper-resistant by isolation; zero cryptographic hardware requirements | Relies entirely on no physical access; unverifiable; not suited for hostile environments | Conceptual TEE model; good for compliance-driven or closed-system deployment |
Reference: Old TEE Tales A not so in depth exploration of TEE platforms and its designs — by Zheng Leong Chua