\n ## Trusted Execution Environment (TEE) Architectures: Comparative Diagram ### Overview The image presents a comparative technical diagram illustrating four different hardware-based Trusted Execution Environment (TEE) architectures. It is divided into four quadrants, each depicting a distinct model's memory isolation and privilege separation strategy. The diagrams use a consistent layered visual language to represent software and hardware components, with color-coding to denote different privilege levels or worlds. ### Components/Axes The image is a composite of four separate architectural diagrams, labeled (a) through (d). Each diagram is structured as a vertical stack of layers, divided into two primary columns representing different security domains. **Common Visual Elements:** * **Columns:** Each diagram is split into two vertical columns representing security domains (e.g., "Untrusted" vs. "Trusted", "Normal World" vs. "Secure World"). * **Layers:** Horizontal layers represent different levels of the software/hardware stack. From top to bottom, these typically include Application, Operating System (OS), Hypervisor, and Firmware/Hardware. * **Color Coding:** * Light Beige: Application layer. * Light Orange: Operating System (OS) layer. * Darker Orange: Hypervisor layer. * Red: Firmware, Microcode, or Hardware layer. * **Symbols:** A dagger (†) and an asterisk (*) are used as annotations on specific components, likely indicating modified or security-enhanced versions. ### Detailed Analysis #### (a) Intel SGX * **Columns:** "Untrusted" (left) and "Trusted" (right). * **Components & Flow:** * **App Layer:** In the Untrusted column, a standard "App" component exists. A "Call gate" bridges to the Trusted column, which contains an "Enclave†". The dagger suggests this is a special, protected application container. * **OS Layer:** Only present in the Untrusted column ("OS"). The Trusted column's OS layer is empty, indicating the OS is not part of the trusted computing base (TCB) for the enclave. * **Hypervisor Layer:** Only present in the Untrusted column ("Hypervisor"). * **Firmware/Microcode Layer:** Spans both columns, forming the foundational hardware trust anchor. * **Spatial Grounding:** The "Call gate" is positioned at the boundary between the Untrusted App and the Trusted Enclave. The Trusted column's OS and Hypervisor layers are visually empty. #### (b) AMD SEV * **Columns:** "Untrusted" (left) and "Trusted" (right). * **Components & Flow:** * **App Layer:** Both columns contain an "App". The Trusted column's app is labeled "App†", indicating it is a protected virtual machine (VM). * **OS Layer:** Both columns contain an "OS". The Trusted column's OS is labeled "OS†", indicating it is the OS for the protected VM. * **Hypervisor Layer:** Both columns contain a "Hypervisor". The Trusted column's hypervisor is labeled "Hypervisor*", with an asterisk. This suggests a modified hypervisor component (likely the AMD SEV firmware) that manages encrypted VMs. * **Firmware/Microcode Layer:** Spans both columns. * **Spatial Grounding:** The vertical dividing line between Untrusted and Trusted is solid, indicating a full memory encryption boundary that encapsulates the entire VM stack (App, OS, and a hypervisor component). #### (c) Arm TrustZone-A * **Columns:** "Normal World" (left) and "Secure World" (right). * **Components & Flow:** * **App Layer:** "App" in Normal World. "TA" (Trusted Application) in Secure World. * **OS Layer:** "OS" in Normal World. "Trusted OS" in Secure World. * **Hypervisor Layer:** Present only in the Normal World ("Hypervisor"). * **Secure Monitor Layer:** A dedicated "Secure Monitor" layer sits at the bottom of the Secure World column. A double-headed arrow connects it to the Normal World's Hypervisor, indicating context switching between worlds. * **Spatial Grounding:** The "Secure Monitor" is positioned as a gateway between the two worlds, below the hypervisor level. The arrow explicitly shows the control flow path for world switching. #### (d) Arm TrustZone-M * **Columns:** "Normal World" (left) and "Secure World" (right). * **Components & Flow:** * **App Layer:** "App" in Normal World. The Secure World's app layer is split: "NSC" (Non-Secure Callable) on the boundary and "Service" inside the Secure World. * **OS Layer:** "OS" only in the Normal World. The Secure World's OS layer is empty. * **Hypervisor Layer:** Not present in either column. * **Firmware Layer:** Present only in the Secure World ("Firmware"). * **Hardware Layer:** A "Hardware" layer spans both columns at the very bottom, replacing the Firmware/Microcode layer seen in other diagrams. * **Spatial Grounding:** The "NSC" component is placed directly on the dividing line, acting as a defined entry point into the Secure World's "Service". The Secure World lacks a traditional OS layer, with services running closer to the firmware. ### Key Observations 1. **Isolation Granularity:** The architectures isolate different components. Intel SGX isolates specific application enclaves. AMD SEV isolates entire virtual machines. Arm TrustZone isolates entire worlds (Normal vs. Secure), which can contain full OSes or lightweight services. 2. **Trusted Computing Base (TCB) Size:** The TCB (components in the Trusted/Secure column) varies significantly. SGX has a minimal TCB (just the Enclave). SEV's TCB includes the guest OS and a hypervisor component. TrustZone-A's TCB includes a Trusted OS and Secure Monitor. TrustZone-M's TCB is firmware-centric. 3. **Role of the Hypervisor:** The hypervisor is untrusted in SGX and TrustZone-A. It is partially trusted (with a modified component) in SEV. It is absent in the TrustZone-M model, which is designed for microcontrollers without virtualization. 4. **Entry Points:** Each architecture defines a specific, controlled entry point into the trusted domain: a "Call gate" (SGX), the entire VM boundary (SEV), the "Secure Monitor" (TrustZone-A), or an "NSC" (TrustZone-M). ### Interpretation This diagram is a pedagogical tool for comparing hardware security extensions. It visually answers the question: "Where does the security boundary lie, and what is protected inside it?" * **Intel SGX** prioritizes **application-level** confidentiality, protecting code and data even from a compromised OS or hypervisor. Its model is "protect this specific piece of code." * **AMD SEV** prioritizes **virtual machine-level** confidentiality, protecting an entire guest VM from the hypervisor and host system. Its model is "protect this entire virtual machine." * **Arm TrustZone-A** implements a **system-level** dual-world architecture, suitable for running a rich OS (Normal World) alongside a separate, secure operating system for critical services (Secure World). Its model is "partition the entire system into two distinct operating environments." * **Arm TrustZone-M** is a **resource-constrained** variant for microcontrollers, eliminating the hypervisor and OS layers in the secure world for a leaner, firmware-driven trusted service model. The progression from (a) to (d) shows a spectrum from fine-grained, application-centric isolation to coarse-grained, system-level partitioning, with variations tailored to different threat models (cloud VMs vs. mobile devices vs. IoT sensors). The consistent use of layered diagrams allows for direct comparison of what each architecture considers part of its trusted foundation.