## [Comparison Table]: Trusted Execution Environment (TEE) Feature Matrix ### Overview The image displays a technical comparison table evaluating four major Trusted Execution Environment (TEE) technology families—SGX, TrustZone, SEV, and RISC-V—across a set of security and functional features. Each family is further broken down into specific implementations or variants. The table uses a symbolic legend (filled, half-filled, and empty circles) to denote the level of support for each feature. ### Components/Axes * **Main Column Headers (Top Row):** Four primary technology categories: 1. **SGX** (Software Guard Extensions) 2. **TrustZone** 3. **SEV** (Secure Encrypted Virtualization) 4. **RISC-V** * **Sub-Column Headers (Second Row):** Specific implementations under each main category: * Under **SGX**: `Client SGX`, `Scalable SGX` * Under **TrustZone**: `TrustZone-A`, `TrustZone-M` * Under **SEV**: `Vanilla`, `SEV-ES`, `SEV-SNP` * Under **RISC-V**: `Keystone`, `Sanctum`, `TIMBER-V`, `LIRA-V` * **Row Headers (Leftmost Column):** A list of 11 features evaluated: 1. Integrity 2. Freshness 3. Encryption 4. Unlimited domains 5. Open source 6. Local attestation 7. Remote attestation 8. API for attestation 9. Mutual attestation 10. User-mode support 11. Industrial TEE * **Additional Descriptive Rows (Bottom):** Two rows providing contextual information: * **Isolation and attestation granularity:** Describes the scope of protection (e.g., "Intra-address space", "Secure world", "VM"). * **System support for isolation:** Lists the underlying hardware/software mechanisms (e.g., "µcode + XuCode", "SMC + PMP", "Firmware"). * **Symbol Legend (Implied):** The table uses three symbols consistently: * **Filled Circle (●):** Full support or presence of the feature. * **Half-Filled Circle (◐):** Partial, limited, or conditional support. * **Empty Circle (○):** No support or feature absent. ### Detailed Analysis The following matrix reconstructs the table's data. "N/A" indicates the cell is not applicable or the feature is not evaluated for that specific implementation. | Feature | SGX: Client SGX | SGX: Scalable SGX | TrustZone: TrustZone-A | TrustZone: TrustZone-M | SEV: Vanilla | SEV: SEV-ES | SEV: SEV-SNP | RISC-V: Keystone | RISC-V: Sanctum | RISC-V: TIMBER-V | RISC-V: LIRA-V | | :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | | **Integrity** | ● | ● | ○ | ○ | ○ | ○ | ○ | ● | ○ | ○ | ○ | | **Freshness** | ● | ◐ | ○ | ○ | ○ | ◐ | ◐ | ● | ○ | ○ | ○ | | **Encryption** | ● | ● | ○ | ○ | ● | ● | ● | ● | ● | ● | ○ | | **Unlimited domains** | ● | ● | ○ | ● | ◐ | ● | ● | ● | ● | ● | ○ | | **Open source** | ◐ | ◐ | ○ | ○ | ○ | ○ | ○ | ● | ● | ● | ● | | **Local attestation** | ● | ◐ | ◐ | ◐ | ○ | ○ | ○ | ● | ○ | ○ | ○ | | **Remote attestation** | ● | ◐ | ◐ | ◐ | ○ | ○ | ○ | ● | ○ | ○ | ○ | | **API for attestation** | ○ | ○ | ◐ | ◐ | ○ | ○ | ○ | ● | ○ | ○ | ○ | | **Mutual attestation** | ○ | ○ | ◐ | ◐ | ○ | ○ | ○ | ● | ○ | ○ | ● | | **User-mode support** | ● | ● | ● | ● | ● | ● | ● | ● | ● | ● | ○ | | **Industrial TEE** | ● | ● | ● | ● | ● | ● | ● | ○ | ○ | ○ | ○ | | **Isolation Granularity** | Intra-address space | Intra-address space | Secure world | Secure world | VM | VM | VM | Secure world | Intra-address space | Intra-address space | Intra-address space | | **System Support** | µcode + XuCode | µcode + XuCode | SMC | MPU | Firmware | Firmware | Firmware | SMC + PMP | Tag + MPU | Tag + MPU | PMP | ### Key Observations 1. **SGX (Client & Scalable):** Shows the most comprehensive feature set, with full or partial support for nearly all listed security features (Integrity, Freshness, Encryption, Attestation). It is marked as an "Industrial TEE." Its primary limitation is the "Intra-address space" isolation granularity. 2. **TrustZone (A & M):** Focuses on a "Secure world" model. It lacks native support for core cryptographic features like Integrity, Freshness, and Encryption in this comparison, relying on the secure world boundary. It provides partial attestation APIs and mutual attestation. It is also considered an "Industrial TEE." 3. **SEV Family (Vanilla, ES, SNP):** Specializes in virtual machine (VM) isolation. Its core strength is **Encryption** (full support across all variants). Integrity and attestation features are largely absent in Vanilla but are partially introduced in SEV-ES and SEV-SNP (notably Freshness). It is an "Industrial TEE." 4. **RISC-V Implementations:** Exhibit a clear split. * **Keystone** is the most feature-rich, mirroring SGX's strong support for Integrity, Freshness, Encryption, and full attestation suite, but is **not** marked as an "Industrial TEE." * **Sanctum & TIMBER-V** focus on Encryption and Unlimited domains within an "Intra-address space" model, with open-source availability but no attestation features. * **LIRA-V** is the most minimal, supporting only Encryption and Mutual Attestation. 5. **Open Source:** A clear differentiator. All RISC-V implementations are fully open source (●), while SGX and TrustZone have partial (◐) or no (○) open-source support, and SEV is entirely closed (○). ### Interpretation This table provides a **Peircean investigative** snapshot of the TEE landscape, revealing distinct design philosophies and target use cases: * **SGX** represents a mature, general-purpose, high-assurance model for protecting code and data within applications, hence its broad feature coverage and industrial status. Its "Intra-address space" model offers fine-grained but complex isolation. * **TrustZone** embodies a system-wide, hardware-enforced separation between a "normal" and "secure" world, typical in mobile and embedded systems. Its feature set in this table is more about the foundational separation than granular, in-enclave services like attestation. * **SEV** is purpose-built for **cloud and virtualization** security. Its primary goal is to encrypt VM memory and provide integrity/freshness guarantees against a potentially malicious hypervisor, which explains its strong encryption focus and VM-level granularity. * **RISC-V** showcases an **emerging, modular ecosystem**. Keystone aims to be a full-featured, open-source alternative to SGX. The other implementations represent research or specialized solutions exploring different trade-offs between security, performance, and complexity (e.g., using MPUs or PMPs for isolation). The lack of "Industrial TEE" marking for all RISC-V options suggests they are not yet perceived as production-ready in the same commercial sense as the others. **Notable Anomaly:** The "API for attestation" and "Mutual attestation" rows are almost entirely unsupported (○) except for TrustZone (partial) and specific RISC-V implementations (Keystone, LIRA-V). This highlights that standardized, interoperable attestation remains a significant challenge and differentiator in the TEE space. The table suggests that while many TEEs can *perform* attestation internally, providing a clean, accessible API for it—and especially enabling mutual attestation between different TEEs—is rare.