## System Architecture Diagram: Trusted Execution Environment (TEE) Implementations ### Overview The image presents a comparative technical diagram illustrating three distinct hardware-based trusted execution environment (TEE) architectures. Each panel depicts a layered system stack, showing the separation between "Untrusted" and "Trusted" execution worlds or components. The diagrams use a consistent color scheme: red for firmware/microcode, orange for hypervisor, light orange for OS, and beige for application-level components. ### Components/Axes The image is divided into three labeled panels: * **(a) Intel SGX** (Software Guard Extensions) * **(b) Arm TrustZone** * **(c) AMD SEV** (Secure Encrypted Virtualization) Each panel is a vertical stack diagram with the following common layers (from bottom to top): 1. **Firmware / Microcode** (Red block) 2. **Hypervisor** (Orange block) 3. **OS** (Light orange block) 4. **Application-level components** (Beige blocks) A key visual element in each panel is the boundary line (solid or dashed) separating the **Untrusted** and **Trusted** domains. ### Detailed Analysis #### **Panel (a): Intel SGX** * **Trust Boundary:** A vertical dashed line splits the diagram. The left side is labeled **Untrusted**, and the right side is labeled **Trusted**. * **Layer Breakdown:** * **Firmware / Microcode:** A single red block spans the entire width at the bottom. * **Hypervisor:** An orange block sits above the firmware, spanning the full width. * **OS:** A light orange block is positioned above the hypervisor, also spanning the full width. * **Application Layer:** This layer is split by the trust boundary. * **Untrusted Side (Left):** Contains two beige blocks labeled **App** and **Call gate**. * **Trusted Side (Right):** Contains one beige block labeled **Enclave†**. The dagger (†) symbol is part of the label. * **Spatial Grounding:** The trust boundary runs vertically through the center of the application layer, leaving the lower three system layers (Firmware, Hypervisor, OS) entirely in the untrusted domain. #### **Panel (b): Arm TrustZone** * **Trust Boundary:** A vertical dashed line splits the diagram into two distinct worlds: **Normal World** (left) and **Secure World** (right). * **Layer Breakdown:** * **Firmware / Microcode:** A red block spans the bottom of the **Normal World** only. * **Secure Monitor:** A separate red block is located at the bottom of the **Secure World**. An arrow points from the **Hypervisor** in the Normal World to this **Secure Monitor**. * **Hypervisor:** An orange block is present only in the **Normal World**, above the firmware. * **OS:** A light orange block is present in the **Normal World**. * **Trusted OS:** A light orange block is present in the **Secure World**. * **Library:** Beige blocks labeled **Library** are present in both the Normal World and the Secure World. * **Application Layer:** * **Normal World:** Contains two beige blocks labeled **App**. * **Secure World:** Contains two beige blocks labeled **TA** (Trusted Application). * **Spatial Grounding:** The architecture creates two parallel, isolated stacks. The Normal World contains a standard OS and hypervisor. The Secure World contains a dedicated Trusted OS and Trusted Applications (TAs). The Secure Monitor acts as a gateway between the two worlds' firmware layers. #### **Panel (c): AMD SEV** * **Trust Boundary:** A vertical solid line splits the diagram. The left side is labeled **Untrusted**, and the right side is labeled **Trusted**. * **Layer Breakdown:** * **Firmware / Microcode:** A single red block spans the entire width at the bottom. * **Hypervisor:** An orange block spans the entire width. It is labeled **Hypervisor***, with an asterisk. * **OS:** * **Untrusted Side (Left):** A light orange block labeled **OS**. * **Trusted Side (Right):** A light orange block labeled **OS†**. * **Application Layer:** * **Untrusted Side (Left):** Contains two beige blocks labeled **App**. * **Trusted Side (Right):** Contains two beige blocks labeled **App†**. * **Spatial Grounding:** The trust boundary runs vertically through the OS and Application layers. Notably, the **Hypervisor** layer is not split; it spans both domains but is marked with an asterisk (*), indicating a special role or state. The components on the trusted side (OS†, App†) are marked with daggers (†). ### Key Observations 1. **Differing Trust Granularity:** The three models protect different layers. * **Intel SGX:** Protects only specific application-level enclaves. The entire OS and hypervisor are untrusted. * **Arm TrustZone:** Creates two full, isolated worlds, each with its own OS. The Secure World runs a separate Trusted OS. * **AMD SEV:** Protects entire virtual machines (the OS and Apps on the right). The hypervisor remains in control but is marked as untrusted relative to the protected VM. 2. **Symbolism:** The dagger (†) consistently marks components that are part of the trusted compute base (Enclave, OS†, App†). The asterisk (*) on the AMD SEV hypervisor suggests it has a privileged but potentially untrusted role in managing the secure VMs. 3. **Isolation Mechanism:** SGX uses memory encryption for enclaves. TrustZone uses a hardware-enforced world switch via the Secure Monitor. SEV uses memory encryption for entire VMs, managed by a hypervisor that cannot access the VM's encrypted memory. ### Interpretation This diagram is a high-level conceptual comparison of hardware security architectures. It demonstrates three philosophies for establishing a **Trusted Computing Base (TCB)**: * **Intel SGX** adopts a "zero-trust" approach towards the system software (OS, Hypervisor), placing trust only in the CPU and the specific, verifiable enclave code. This minimizes the TCB but requires applications to be explicitly rewritten into an enclave model. * **Arm TrustZone** creates a bifurcated system, allowing a full, legacy "Normal World" to coexist with a separate "Secure World" that runs its own trusted OS and applications. This is suitable for devices that need to run both rich operating systems (like Android) and critical security functions (like biometric processing) on the same chip. * **AMD SEV** focuses on virtualization security. It protects entire virtual machines from a potentially malicious or compromised hypervisor. The hypervisor retains control over resource scheduling but cannot inspect or tamper with the VM's memory contents. This is crucial for cloud computing, where the cloud provider (who controls the hypervisor) should not be able to access a tenant's data within a VM. The core trade-off illustrated is between the **size of the trusted computing base** and the **ease of deployment**. A smaller TCB (SGX) offers stronger theoretical security but requires significant software changes. A larger, world-based TCB (TrustZone) or VM-based TCB (SEV) is easier to deploy for existing software but expands the amount of code that must be trusted and verified.