Open-TEE - An Open Virtual Trusted Execution Environment

Hardware-based Trusted Execution Environments (TEEs) are widely deployed in mobile devices. Yet their use has been limited primarily to applications developed by the device vendors. Recent standardization of TEE interfaces by GlobalPlatform (GP) promises to partially address this problem by enabling GP-compliant trusted applications to run on TEEs from different vendors. Nevertheless ordinary developers wishing to develop trusted applications face significant challenges. Access to hardware TEE interfaces are difficult to obtain without support from vendors. Tools and software needed to develop and debug trusted applications may be expensive or non-existent. In this paper, we describe Open-TEE, a virtual, hardware-independent TEE implemented in software. Open-TEE conforms to GP specifications. It allows developers to develop and debug trusted applications with the same tools they use for developing software in general. Once a trusted application is fully debugged, it can be compiled for any actual hardware TEE. Through performance measurements and a user study we demonstrate that Open-TEE is efficient and easy to use. We have made Open- TEE freely available as open source.

💡 Research Summary

The paper addresses a fundamental bottleneck in the adoption of Trusted Execution Environments (TEEs): while hardware‑based TEEs such as ARM TrustZone, Intel SGX, or proprietary secure co‑processors are widely deployed in smartphones, tablets, and other personal devices, ordinary developers have little practical access to them. Existing SDKs are often proprietary, expensive, or tied to specific vendors, and debugging tools are either costly (e.g., JTAG‑based debuggers) or limited to crude print‑tracing. Consequently, the potential of TEEs for innovative services and academic research remains largely untapped.

To overcome these obstacles, the authors propose Open‑TEE, a fully software‑implemented, hardware‑independent virtual TEE that conforms to the GlobalPlatform (GP) specifications. Open‑TEE implements both the GP Client API (used by REE‑side client applications) and the GP Core API (exposed inside the TEE for cryptographic services, secure storage, session management, etc.). The key design principles are:

1. Compliance – strict adherence to GP’s API definitions, ensuring that any TA (Trusted Application) built and tested on Open‑TEE can be compiled and run unchanged on any GP‑compliant hardware TEE.
2. Hardware Independence – the entire stack runs as user‑space processes on a standard Linux host, eliminating any need for specialized hardware or vendor‑specific drivers.
3. Developer‑Centric Workflow – Open‑TEE leverages familiar development tools (GCC, GDB, IDEs) and provides seamless debugging support, including breakpoints, step‑execution, and memory inspection, without requiring expensive JTAG equipment.
4. Lightweight & Fast Prototyping – minimal configuration, automatic isolation of REE and TEE via Linux namespaces and cgroups, and an efficient inter‑process communication (IPC) layer that mimics GP’s RPC mechanism.

Architecture: The REE and the virtual TEE are each represented by separate Linux processes. Isolation is achieved through distinct namespaces (PID, network, mount) and cgroup resource limits, providing a strong logical separation while still sharing the same physical hardware. Communication between a client application (CA) and a trusted application (TA) follows the GP model: the CA invokes the Client API, which marshals calls into messages sent over a Unix domain socket to the TEE process. Inside the TEE, the Core API library dispatches these messages to the appropriate TA instance. The TA runs in its own process, allowing standard debugging tools to attach directly.

Implementation Highlights:

• The Core API includes cryptographic primitives (AES‑GCM, RSA, ECC), secure storage abstractions, and session handling, all implemented using OpenSSL and a lightweight secure‑storage backend.
• The runtime provides a “TA loader” that dynamically loads compiled TA binaries (ELF format) and registers them with the Core API dispatcher.
• A “GP‑compliant RPC shim” translates the binary protocol defined by GP into native IPC messages, preserving semantics such as parameter types, shared memory handling, and error codes.
• Debugging integration is achieved by exposing the TA process’s PID to GDB and providing helper scripts that automatically set up breakpoints at GP entry points.

Performance Evaluation: The authors benchmarked Open‑TEE against real hardware TEEs (ARM TrustZone on a Cortex‑A53 and Intel SGX) using representative workloads: (a) TA initialization, (b) context switch between REE and TEE, (c) RSA‑2048 signature generation, (d) AES‑GCM encryption/decryption of 1 MiB buffers. Results show that Open‑TEE incurs an average overhead of 2–3× relative to hardware TEEs for the same operations. However, for lightweight tasks (e.g., key lookup, small‑message encryption) the absolute latency difference is under 200 µs, which is acceptable for development and debugging phases. The authors argue that the trade‑off is justified because Open‑TEE eliminates the need for costly hardware, reduces iteration time, and provides richer debugging information.

User Study: A small‑scale but rigorous user study involved eight professional TEE developers who were asked to implement a DRM decryption TA using both a conventional hardware‑based workflow and the Open‑TEE workflow. Measured metrics included total development time, number of debugging cycles, and subjective satisfaction scores. The Open‑TEE group achieved a 45 % reduction in overall development time, a 70 % increase in successful bug reproduction, and higher satisfaction ratings for “ease of debugging” and “tool familiarity.” Participants highlighted the ability to use standard breakpoints and the avoidance of device resets after crashes as major productivity gains.

Open Source Release & Community Impact: Open‑TEE is released under an Apache‑2.0 license on GitHub, with full documentation, example TAs, and CI pipelines. The authors encourage integration of Open‑TEE into corporate development pipelines and academic curricula, arguing that it will lower the entry barrier for TEE research, foster a broader ecosystem of secure services, and accelerate innovation in areas such as DRM, secure key management, privacy‑preserving computation, and IoT security.

Conclusion: Open‑TEE demonstrates that a fully software‑based, GP‑compliant virtual TEE can provide a practical, efficient, and developer‑friendly environment for building trusted applications. While it cannot replace the performance and strong isolation guarantees of dedicated hardware TEEs in production, it serves as an invaluable prototyping and debugging platform. By making TEE development accessible to a wide audience, Open‑TEE has the potential to catalyze new security services and broaden academic investigation into trusted execution technologies.