Trust Zone

Jump to: navigation, search


AMBA AXI Firewall

The most significant feature of the extended bus design is the addition of an extra control signal for each of the read and write channels on the main system bus. These bits are known as the Non-Secure, or NS bits, and are defined in the public AMBA3 Advanced eXtensble Interface (AXI) bus protocol specification.

  • AWPROT[1]: Write transaction – low is Secure and high is Non-secure.
  • ARPROT[1]: Read transaction – low is Secure and high is Non-secure.

All bus masters set these signals when they make a new transaction, and the bus or slave decode logic must interpret them to ensure that the required security separation is not violated. All Non-secure masters must have their NS bits set high in the hardware, which makes it impossible for them to access Secure slaves. The address decode for the access will not match any Secure slave and the transaction will fail. If a Non-secure master attempts to access a Secure slave it is implementation defined whether the operation fails silently or generates an error. An error may be raised by the slave or the bus, depending on the hardware peripheral design and bus configuration, consequently a SLVERR (slave error) or a DECERR (decode error) may occur.

AMBA APB Firewall

One of the most useful features of the TrustZone architecture is the ability to secure peripherals, such as interrupt controllers, timers, and user I/O devices. This enables the security environment to be extended so that it can solve some of the wider security issues which need more than just a secure data processing environment. A secure interrupt controller and timer allows a non-interruptible secure task to monitor the system, a secure clock source enables robust DRM, and a securable keyboard peripheral enables secure entry of a user password. The AMBA3 specification includes a low gate-count low-bandwidth peripheral bus known as the Advanced Peripheral Bus (APB), which is attached to the system bus using an AXI-to-APB bridge. The APB bus does not carry an equivalent of the NS bits. This ensures that existing AMBA2 APB peripherals are compatible with systems implementing TrustZone technology. The AXI-to-APB bridge hardware is responsible for managing the security of the APB peripherals; the bridge must reject transactions of inappropriate security setting and must not forward these requests to the peripherals.

The addition of the NS bit to the bus transactions, and to any cache tags in the system, can be viewed as providing a 33rd address bit. There is a 32-bit physical address space for Secure transactions and a 32-bit physical address space for Non-secure transactions. As with any address space, including those without TrustZone technology, care must be taken to ensure that the 33-bit address space is used in such a way that data remains coherent in all of the locations that it is stored, otherwise data corruption may result.

Two worlds

Each of the physical processor provides two virtual cores, one considered Non-secure and the other Secure, and a mechanism to robustly context switch between them, known as monitor mode. The value of the NS bit sent on the main system bus is indirectly derived from the identity of the virtual core that performed the instruction or data access. This enables trivial integration of the virtual processors into the system security mechanism; the Non-secure virtual processor can only access Non-secure system resources, but the Secure virtual processor can see all resources.

Trustzone two worlds.png

The two virtual processors execute in a time-sliced fashion, context switching through a new core mode called monitor mode when changing the currently running virtual processor. The mechanisms by which the physical processor can enter monitor mode from the Normal world are tightly controlled, and are all viewed as exceptions to the monitor mode software. The entry to monitor can be triggered by software executing a dedicated instruction, the Secure Monitor Call (SMC) instruction, or by a subset of the hardware exception mechanisms. The IRQ, FIQ, external Data Abort, and external Prefetch Abort exceptions can all be configured to cause the processor to switch into monitor mode.

The software that executes within monitor mode is implementation defined, but it generally saves the state of the current world and restores the state of the world being switched to. It then performs a return-from-exception to restart processing in the restored world. The world in which the processor is executing is indicated by the NS-bit in the Secure Configuration Register (SCR) in CP15, the system control coprocessor, unless the processor is in monitor mode. When in monitor mode, the processor is always executing in the Secure world regardless of the value of the SCR NS-bit, but operations on banked CP15 registers will access Normal world copies if the SCR NS-bit is set to 1.

Normal world software is not able to access the contents of the SCR.

Secure interrupts

The ability to trap IRQ and FIQ directly to the monitor, without intervention of code in either world, allows for the creation of a flexible interrupt model for secure interrupt sources. Once the execution reaches the monitor, the trusted software can route the interrupt request accordingly. When combined with a security aware interrupt controller this allows a design to provide secure interrupt sources which cannot be manipulated by the Normal world software. The model recommended by ARM is the use of IRQ as a Normal world interrupt source, and FIQ as the Secure world source. IRQ is the most common interrupt source in use in most operating environments, so the use of FIQ as the secure interrupt should mean the fewest modifications to existing software. If the processor is running the correct virtual core when an interrupt occurs there is no switch to the monitor and the interrupt is handled locally in the current world. If the core is in the other world when an interrupt occurs the hardware traps to the monitor, the monitor software causes a context switch and jumps to the restored world, at which point the interrupt is taken.

!!!!!! Possible violation on call Secure Monitor with unmasked interrupts

Trustzone secure interrupts.png

Secure configuration

To enable independent execution of code on the virtual CPUs, the hardware strictly manages the configuration options present in CP15. The configuration options that are considered sensitive, or that apply globally to the core, can only be written by Secure world software, although most can be read by Normal world software. Settings that are not globally sensitive, and as such can be applied locally in each world, are normally banked in the hardware. This gives each world independent control over the settings that would impact their implementation.


ARM processors prior to the introduction of the Security Extensions have included a single debug control signal that globally enables or disables debugger access to the processor.

The TrustZone debug extensions separate the debug access control into independently configurable views of each of the following aspects:

  • Secure privileged invasive (JTAG) debug
  • Secure privileged non-invasive (trace) debug
  • Secure user invasive debug
  • Secure user non-invasive debug

The Secure privileged debug access is controlled by two input signals to the core, SPIDEN (invasive) and SPNIDEN (non-invasive). The Secure user mode debug access is controlled by two bits, SUIDEN (invasive) and SUNIDEN (non-invasive) in a Secure privileged access only CP15 register. These settings enable a TrustZone processor to give control over the debug visibility once the device is deployed. It is, for example, possible to give full Normal world debug visibility while also preventing all Secure world debug.

The ARM system debug solution is the ARM CoreSight on-chip debug and trace technology. It provides a debug and trace solution for the entire SoC, enabling debug of multiple processors and other system components. The CoreSight debug infrastructure can be accessed both from off-device tools and from on-device components. The parts of the CoreSight infrastructure that are accessible from on-SoC hardware and software are implemented as APB peripherals. To reduce the number of components needed the CoreSight peripherals are designed not to use the standard per-peripheral protection mechanisms provided by an AXI-to-APB bridge; CoreSight components should be accessible to Non-secure memory transactions. As an alternative to the protection provided by the AXI-to-APB bridge, the CoreSight components include a number of control signals which are used to enable or disable Secure debug. These signals are known as the CoreSight authentication interface, and include SPIDEN, SPNIDEN and DBGEN signals, which perform a similar role to the signals of the same name described for the processor core.

If external debug hardware, or on-target Normal world software, attempts to set a system breakpoint on a secure address when SPIDEN is deasserted, the CoreSight hardware will fail to create a breakpoint. For instrumentation solutions, Secure trace information will simply be discarded by the peripheral if SPNIDEN is not asserted.

A consequence of the debug security architecture is that Normal world software may be able to directly affect or monitor the Secure world execution in a system when SPIDEN or SPNIDEN are asserted. Secure debug should therefore only be enabled when the device is located in a trusted environment.

All details you can find in the full TrustZone description - File:Prd29-genc-009492c trustzone security whitepaper.pdf


Cortex A8 (OMAP3xxx) doesnt contain TCM (Tightly Couple Memory) and have integrated L2 cache controller


PrimeCell High-Performance Matrix


PrimeCell Level 2 Cache Controller


PrimeCell DMA Controller

Datasheet: File:Trustzone pl330.pdf


PrimeCell TrustZone Address Space Controller

Datasheet: File:Trustzone pl380.pdf


PrimeCell Infrastructure AMBA3 AXI TrustZone Memory Adapter

Datasheet: File:Trustzone bp141.pdf


PrimeCell Generic Interrupt Controller

Datasheet: File:Trustzone pl390.pdf


PrimeCell Infrastructure AMBA3 TrustZone Protection Controller

Datasheet: File:Trustzone bp147.pdf

Secure Boot

A secure boot scheme adds cryptographic checks to each stage of the Secure world boot process. This process aims to assert the integrity of all of the Secure world software images that are executed, preventing any unauthorized or maliciously modified software from running.

The most logical cryptographic protocol to apply is one based on a public-key signature algorithm, such as RSA-PSS (Rivest, Shamir and Adleman - Probabilistic Signature Scheme). In these protocols a trusted vendor uses their Private Key (PrK) to generate a signature of the code that they want to deploy, and pushes this to the device alongside the software binary. The device contains the Public Key (PuK) of the vendor, which can be used to verify that the binary has not been modified and that it was provided by the trusted vendor in question. The PuK does not need to be kept confidential, but it does need to be stored within the device in a manner which means it cannot be replaced by a PuK that belongs to an attacker.

The secure boot process implements a chain of trust. Starting with an implicitly trusted component, every other component can be authenticated before being executed. The ownership of the chain can change at each stage - a PuK belonging to the device OEM might be used to authenticate the first bootloader, but the Secure world OS binary might include a secondary PuK that is used to authenticate the applications that it loads. Unless a design can discount hardware shack attacks the foundations of the secure boot process, known as the root of trust, must be located in the on-SoC ROM. The SoC ROM is the only component in the system that cannot be trivially modified or replaced by simple reprogramming attacks. Storage of the PuK for the root of trust can be problematic; embedding it in the on-SoC ROM implies that all devices use the same PuK. This makes them vulnerable to class-break attacks if the PrK is stolen or successfully reverse-engineered. On-SoC One-Time-Programmable (OTP) hardware, such as poly-silicon fuses, can be used to store unique values in each SoC during device manufacture. This enables a number of different PuK values to be stored in a single class of devices, reducing risk of class break attacks.

OTP memory can consume considerable silicon area, so the number of bits are that available is typically limited. A RSA PuK is over 1024-bits long, which is typically too large to fit in the available OTP storage. However, as the PuK is not confidential it can be stored in off-SoC storage, provided that a cryptographic hash of the PuK is stored on-SoC in the OTP. The hash is much smaller than the PuK itself (256-bits for a SHA256 hash), and can be used to authenticate the value of the PuK at run-time.

See also: security_boot_lock signal in TZASC ( PL380 )


In our target device, the native handset boot starts exe- cuting from an on-chip ROM, which in turns loads a signed bootloader and executes it on successful verification. The M-Shield architecture additionally includes on-chip RAM to be used by so-called protected applications. These can either persistently be present on an on-chip ROM, or be uploaded to on-chip RAM as signed binaries. The system implements a firewall/monitor entry point for executing these applica- tions, and this firewall takes care of disabling or clearing all security-critical processor features (interrupts, DMA, VM) for the duration of the TrEE invocation. In this manner the system provides hardware-enforced isolation for the pro- tected applications. The on-chip protected applications have access to a limited amount of persistent secret data (like a device-specific symmetric key) and to cryptographic accelerator primitives.


Sheme.gif 2007 06-nokia-figure-2.gif Arch 1.jpg

  1. ROM to store the program code or a mechanism by which the integrity of code uploaded to the secure environment can be validated (code signing).
  2. a shielded location (secure RAM) for the loaded state, as well as for run-time data.
  3. an isolated execution environment (TrEE) for the program code with access to the shielded data location.
  4. a device-specific, persistent secret to seed the RTS. The confidentiality (access control) of the secret can e.g. be bound to the secure environment itself.
  5. a simple (I/O) library for use in the isolated environment, including cryptographic primitives and random number generation necessary for a MTM.1


Abbreviation Meaning
AKI Attestation Identity Key
EK Endorcement Key
DAA Direct Anonymous Attestation
DRTM Dynamic Root of Trust Management
MTM Mobile Trusted Module
RIM Reference Integrity Metric
RTE Root of Trust for Enforcement
RTR Root of Trust for Reporting
RTS Root of Trust for Storage
RTV Root of Trust for Verification
RVAI Root Verification Authority Information
SRK Storage Root Key, is used to protect local data (keys e.g)

Listing 1: Structure for symmetric SRK

  1. // 128 bits key length                        
  2. #define SRK KEYLENGTH 16  
  4. typedef struct tdTPM KEY SRK {
  5.   TPM STRUCT VER ver;
  6.   TPM KEY USAGE keyUsage;
  7.   TPM KEY FLAGS keyFlags;
  8.   TPM AUTH DATA USAGE authDataUsage;
  9.   TPM KEY PARMS algorithmParms;
  10.   TPM SECRET usageAuth;
  11.   UINT32 PCRInfoSize;
  12.   TPM PCR INFO pcrInfo;
  13.   BYTE symKey[SRK KEYLENGTH];
  14. } TPM KEY SRK;
  15. // Size of TPM KEY SRK in bytes: 123

Listing 2: Structure for loaded asymmetric key

  1. typedef struct tdTPM KEY LOADED {
  2. TPM STRUCT VER ver;
  3. TPM KEY USAGE keyUsage;
  4. TPM KEY FLAGS keyFlags;
  5. TPM AUTH DATA USAGE authDataUsage;
  6. TPM KEY PARMS algorithmParms;
  7. TPM KEY PARMS algorithmParms;
  8. UINT32 PCRInfoSize;
  9. UINT32 PCRInfoSize;
  10. TPM PCR INFO pcrInfo;
  11. TPM STORE ASYMKEY keyData;
  13. // Size of TPM KEY LOADED in bytes: 551


  1. typedef struct tdTPM PCR ATTRIBUTES {
  2.   BOOL pcrReset;
  5. // Size of TPM PCR ATTRIBUTES in bytes: 1
  6. typedef struct tdTPM PERMANENT FLAGS {
  8.   BOOL disable;
  9.   BOOL FIPS;
  11.   BOOL readSRKPub;
  14. // Size of TPM PERMANENT FLAGS in bytes: 5
  15. typedef struct tdTPM STCLEAR FLAGS {
  16.   TPM STRUCTURE TAG tag;
  17.   BOOL deactivated;
  20. // Size of TPM STCLEAR FLAGS in bytes: 3
  21. typedef struct tdTPM STANY FLAGS {
  22.   TPM STRUCTURE TAG tag;
  23.   BOOL postInitialise;
  26. // Size of TPM STANY FLAGS in bytes: 3
  27. #define TPM SESSIONS 2
  28. typedef struct tdTPM STANY DATA {
  29.   TPM STRUCTURE TAG tag;
  33. // Size of TPM STANY DATA in bytes: 98
  34. #define TPM NUM COUNTER 1
  35. #define TPM NUM PCR 16
  37. typedef struct tdTPM PERMANENT DATA {
  38.   TPM STRUCTURE TAG tag;
  39.   BYTE revMajor;
  40.   BYTE revMinor;
  41.   TPM NONCE tpmProof;
  42.   TPM KEY srk;
  43.   TPM COUNTER VALUE monotonicCounter[TPM NUM COUNTER];
  47. // Size of TPM PERMANENT DATA in bytes: 173
  48. typedef struct tdTPM STCLEAR DATA {
  49.   TPM STRUCTURE TAG tag;
  50.   TPM COUNT ID countID;
  53. // Size of TPM STCLEAR DATA in bytes: 326

Software Emulators:

  1. MTM Emulator -
  2. TroUserS (

Useful literature

  1. Patent description with nice graphics [2]
  1. M-Shield description File:NRCTR2007015.pdf
  1. MCM Specification File:87852F33-1D09-3519-AD0C0F141CC6B10D.pdf
  1. Trusted Mobile Reference Architecture File:644597BE-1D09-3519-AD5ADDAFA0B539D2.pdf
  1. MTM Use cases File:6443B207-1D09-3519-AD3180491A6DF1F5.pdf