Open Virtualization for ARM TrustZone
- What is TrustZone?
TrustZone is a set of security extensions added to ARMv6 processors and greater, such as ARM11, CortexA8, CortexA9 and CortexA15. To improve security, these ARM processors can run a secure operating system (secure OS) and a normal operating system (normal OS) at the same time from a single core. The instruction Secure Monitor Call or SMC bridges the secure and normal modes.
TrustZone technology is programmed into the hardware, enabling the protection of memory and peripherals. Since security is designed into the hardware, TrustZone avoids security vulnerabilities caused by proprietary, non-portable solutions outside the core. Security can be maintained as an inherent feature of the device, without degrading system performance, enabling device manufacturers to build security applications, such as DRM or mobile payment as protected applications that run on the secure kernel.
With TrustZone, user space applications operate in "normal" mode. The kernel runs "system" mode. The trusted kernel operates in "monitor" mode. Because of this architecture, even a "rooted" application cannot access protected regions within the trusted kernel. Any component can be designated as part of the trusted infrastructure, from regions of the PCI-E address space to NAND memory. Overall, TrustZone offers a secure and easy-to-implement trusted computing solution for device manufacturers, without requiring additional hardware.
- What is TrustZone Software?
TrustZone software provides a minimal secure kernel which can be run in parallel with a more fully featured high-level OS-such as Linux, Android, or BSD-on the same core. It also provides drivers for the normal, rich OS ("normal world") to communicate with the secure OS ("secure world").
TrustZone software uses ARM TrustZone security extensions to completely protect the secure OS and any secure peripherals from code running in the normal world. This means that even if an attacker manages to obtain full root privileges in the normal OS, he or she cannot access the secure world.
It includes a secure monitor that switches between the secure and the normal world, and an example secure first-stage bootloader.
Systems with a separate ARM processor dedicated for security can use the TrustZone software multicore, running the secure kernel on its own CPU.
- What is the TrustZone API and the GlobalPlatform TEE API?
The ARM TrustZone API was the initial endeavor by ARM to standardize software development for the TrustZone hardware security extensions. The API was targeted for applications running in the normal OS and they masked the secure OS implementation from the normal OS.
As tasks on the secure OS became more and more complicated, the ARM TrustZone API specification needed to be expanded to encompass both application written for the normal OS and for the secure OS. By defining specifications for the secure OS, it would be possible to build applications like Digital Rights Management (DRM) for the Secure OS and port Secure OS applications easily from one system to another.
ARM has partnered with GlobalPlatform to define a new Trusted Execution Environment (TEE) API that covers all three aspects.
- TEE Client API Specification: This specification is very similar to the ARM TrustZone API. Applications running in the normal OS can be ported from the ARM TrustZone API to the TEE Client API spec with simple wrappers.
- TEE Internal API Specification: This defines the Secure OS implementation and enables easier porting of Secure Tasklets from one vendor to another. Think of it as another version of POSIX.
- TEE System Architecture: Defines the overall software architecture.
- Who are the Standards Bodies?
- Global Platform: Visa, MasterCard, NTT, ARM and others
- Trusted Computing Group & ISO/IEC (Spec 11889 for TPM): Intel, AMD, HP and others
Effectively, the ARM TrustZone API is deprecated and all the newer implementations use GlobalPlatform TEE as the reference.
- How does the Trusted Execution Environment (TEE) compare to Trusted Platform Mobile (TPM)?
There are two main components of platform security:
They work in tandem; one is not designed as a replacement of the other. As an analogy, TEE is the bulletproof safe, while TPM is the 128-digit combination lock for the safe. Both are needed to ensure the safe is protected.
- Trusted Execution Environment
- Trusted Platform Module
TEE encompasses the following elements:
- A protected or secure execution of critical applications in a virtualized environment
- Safe and secure boot ensures all system software components are in a known and "trusted" state before launching.
TPM provides the following services:
- Remote attestation: External services can verify that the system has not been altered or tampered with by using a hash of both system state. The verification is performed on both hardware and software. It is necessary to check that the system is not compromised before executing sensitive processes.
- Binding: Encryption of data using a unique RSA key that is burned into the chip when the chip is manufactured.
- Sealing: A feature that ensures that data isn't accessed or decrypted when the system is in normal operation. It ensures that applications cannot access protected data when the system is in a sealed mode. But it can also allow legitimate applications to access protected data.
Arguments were made that TPM is not necessary if the TEE is robust. Some vendors have chosen not to use external TPM and store the keys and protected data in a TEE-only addressable area. TEE can help with Binding and Sealing. ISO standards suggest using a full-fledged TPM. External TPM could be very useful in coordinating between several masters and other complex systems. On the other hand, solutions that only rely on TPM are very vulnerable for execution and boot attacks. It is easy to override the application run states and circumvent TPM.
- Do Intel or AMD offer Trusted Execution Environments?
Yes, other processor architectures support TEE. Popular CPU Architectures and their TEE implementations:
All three of these TEE implementations provide a virtualized Execution Environment for the secure OS and applications. To switch between the secure world and the normal world, Intel provides SMX Instructions, while ARM uses SMC. Programmatically, they all achieve very similar results.
- ARM TrustZone
- Intel TXT
- AMD Secure Execution Environment
Popular TPM Implementations:
- ARM Secure Core
- TPMs from Broadcom and other vendors who meet ISO standards
- Why do we need a Trusted Execution Environment?
The principle of least privilege, loved and proven to be the cornerstone of secure system design, compels the need for a TEE. System modules (drivers, applications) should not have access to a resource unless absolutely necessary. For example, there is no need for Linux to be able to access the region where the public key is stored in the SOC. Likewise, the driver for a crypto block doesn't need to know the current session key; the session key could be programmed by the key negotiation algorithm and stored in a secure location within the crypto block.
The old two-level method of protection (kernel and user) is not enough as 'root' has full privilege to access everything in the system. TEE provides a third level of privilege where some key resources like device key can be protected from the normal or "rich" OS kernel. ARM TrustZone and Intel TXT all achieve this by providing a virtualized environment to run TEE and the normal OS in parallel.
- Are peripherals aware of TrustZone? How much influence does a SOC designer have?
Yes, cores and peripherals use of the AxPROT signal to distinguish between secure and non-secure access. Two new signals-ARPROT and AWPROT-were developed for the AXI bus for TrustZone. These two signals are referred together as AxPROT. They specify whether the current transaction is secure or non-secure. ARPROT analyzes read transactions while AWPROT examines write transactions.
For example, an ARM Level 2 cache controller stores an indicator for each cache line describing whether the line was filled as a result of a secure or non-secure access. It will then return a miss if the non-secure world tries to access data that is in the cache, but tagged as secure. All of the bus masters (any that could write to memory) have to be TrustZone aware, so that a rogue driver cannot DMA to a trusted memory location. For instance, if an entire AXI is not aware of TrustZone, a 'rooted' GDMA driver could try to access protected memory even though the ARM core does not allow the code to directly access the secure region. Therefore, all bus masters must follow TrustZone directives.
Although ARM TrustZone is part of the core itself, several other things like secure boot and PCIE address mapping are specific to the individual processor. It even becomes more complicated with multi-core platforms. For example, it is possible to design a hybrid architecture with one TrustZone-enabled Cortex A15 core and multiple Cortex M3 cores without TrustZone and still provide secure services for applications running on all of the cores.
Is TrustZone only for isolating resources in Normal Operation mode?
No, TrustZone is a philosophy. It is based on the principle of least privilege. So, every other state, including entering into Power Save modes and leaving Hibernation, Power-On, and Suspend-to-DRAM,
all have to be carefully architected to avoid discontinuity in the security perimeter. Every single operational mode and transition from one mode to another has to be carefully studied and validated.
What are the real physical blocks within the chip that enforce the philosophy (for example, how can I add TrustZone to my SOC)?
The below answer is oversimplified to introduce the concept. A complete and comprehensive answer could be a few pages long by itself.
The AXI bus, adds an extra address pin. The extra signal is used to differentiate between trusted and non-trusted requests. Every I/O block connected to the AXI bus has to respect the trusted request.
- The core AXI Bus
- ARM Core itself
- TrustZone Address Space Controller
- TrustZone Protection Controller
TrustZone Address Space Controller, In short TZASC: Think of it as the equivalent of a firewall for networks. It can be used to enforce policies for both AXI and AMBA bus peripherals.
- It adds a few extra instructions for switching between secure and non-secure world.
- A new execution context. The registers are banked for speeding up the switching process. Both normal and secure world provide Guest/Kernel privileges.
It enables you to program security access permissions for each address region. It permits the transfer of data between master and slave only if the security status of the AXI transaction matches the security settings of the memory region it addresses.
One of the key features of the TrustZone address space controller is during the initial boot-up phase, when it establishes the security perimeter. It prevents write access to various registers after assertion of secure_boot_lock.
TrustZone Protection Controller: In short TZPC. It works in conjunction with the Address space controller. Some of the peripherals may not have detailed addresses or may be a simple single register bus interface.
The TZPC provides a software interface to the protection bits in a secure system in a TrustZone design. It provides system flexibility to enable you to configure different areas of memory as secure or non-secure.
It is very flexible and allows for creating multiple memory partitions. Up to 24 partitions can be created. One of the key applications of TZPC is for partitioning the internal RAM inside the SOC for secure and non-secure access.
- How important is CP15SDISABLE?
It is now left to designers of TrustZone on the SOC to decide what registers to be disabled during secure boot. In the previous cores, CP15DISABLE was used in conjunction with the
TZPC to block access to sensitive registers during secure boot.