On Making Emerging Trusted Execution Environments Accessible to Developers

New types of Trusted Execution Environment (TEE) architectures like TrustLite and Intel Software Guard Extensions (SGX) are emerging. They bring new features that can lead to innovative security and privacy solutions. But each new TEE environment comes with its own set of interfaces and programming paradigms, thus raising the barrier for entry for developers who want to make use of these TEEs. In this paper, we motivate the need for realizing standard TEE interfaces on such emerging TEE architectures and show that this exercise is not straightforward. We report on our on-going work in mapping GlobalPlatform standard interfaces to TrustLite and SGX.

💡 Research Summary

The paper addresses the growing diversity of Trusted Execution Environment (TEE) architectures, focusing on two emerging platforms: TrustLite, designed for highly constrained embedded devices, and Intel Software Guard Extensions (SGX), aimed at servers and desktops. Both platforms offer novel hardware‑based isolation mechanisms, yet each defines its own programming model and API, creating a steep learning curve for developers accustomed to existing standards. The authors argue that adopting a common, industry‑wide interface—specifically the GlobalPlatform (GP) specifications—could dramatically lower this barrier, enabling developers to write applications once and deploy them across heterogeneous TEEs.

The authors begin by reviewing the dominant split‑world model embodied by ARM TrustZone, where a single processor alternates between a “normal world” (REE) and a “secure world” (TEE) using banked CPU state, a secure monitor, and hardware signals such as the NS bit. This model underpins many existing GP implementations, which assume the presence of a TEE operating system that manages sessions, trusted storage, and inter‑process communication (IPC).

TrustLite departs from this paradigm. It lacks an MMU and instead relies on a Memory Protection Unit (MPU) enhanced with an Execution‑Aware MPU (EA‑MPU) that can enforce access control based on the current program counter. A dedicated secure exception engine preserves isolation even during interrupts. Because TrustLite typically runs without a full‑featured OS, the GP Core API’s expectations of a TEE OS must be re‑implemented as a lightweight runtime that translates GP session semantics into EA‑MPU rules and uses the secure exception engine for protected IPC. The paper highlights the difficulty of mapping GP’s dynamic memory allocation, session lifecycle, and trusted storage concepts onto a hardware‑only protection model.

SGX presents a different set of challenges. Enclaves are created with ECREATE/EINIT and entered with EENTER; they exist as encrypted pages within the host process’s address space. While this simplifies context switches compared to split‑world, SGX forbids system calls inside an enclave, mandates explicit exits for any OS interaction, and handles asynchronous exits (AEX) by scrubbing registers and clearing caches. Consequently, the GP Client API, which expects seamless RPC calls from a REE client to a TEE service, cannot be used directly. The authors propose a bridge layer that marshals GP commands outside the enclave, forwards them via shared memory (subject to SGX’s page‑level encryption), and re‑enters the enclave to execute the requested operation. They also discuss the need to emulate GP Trusted Storage, perhaps by integrating an encrypted file system or remote key‑management service, because SGX provides no native persistent secure storage.

The paper enumerates four primary obstacles in realizing GP on these platforms: (1) mismatched memory protection models (MPU vs. page encryption), (2) absence of a native TEE OS to manage sessions and IPC, (3) divergent attestation and credential mechanisms, and (4) performance overheads associated with enclave entry/exit or EA‑MPU reconfiguration. Early prototype work is described: for TrustLite, a minimal runtime maps GP Core API calls to EA‑MPU rule updates and leverages the TyTAN secure IPC mechanism; for SGX, the authors build on the Open‑Enclave SDK to wrap GP Client API calls, and implement a virtual trusted storage using an encrypted container mounted inside the enclave. Both prototypes have been exercised against portions of the GP Compliance Test Suite, showing functional compatibility but revealing latency spikes on frequent session creation and storage operations.

In conclusion, the authors demonstrate that while it is technically feasible to expose GP‑compliant interfaces on both TrustLite and SGX, substantial engineering effort is required to reconcile architectural differences. A carefully designed abstraction layer can preserve the benefits of the emerging hardware features while providing developers with a familiar, standardized programming model. Future work will focus on automating compliance testing, supporting concurrent Trusted Applications, and evaluating real‑world performance in latency‑sensitive embedded scenarios.