Understanding ARM TrustZone for Embedded Security

ARM TrustZone is a hardware-based security technology that creates two isolated execution environments—Secure World and Non-Secure World—within a single processor, enforced by hardware that cannot be bypassed by software. On Cortex-A processors (ARMv8-A), TrustZone enables a Trusted Execution Environment (TEE) running alongside a Rich Execution Environment (REE), with the Secure Monitor (EL3) managing transitions. On Cortex-M processors (ARMv8-M, found in STM32L5, nRF5340, LPC55S69), TrustZone-M provides memory-mapped security attribution where each memory region, peripheral, and interrupt is assigned as Secure or Non-Secure via the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU). This hardware isolation protects cryptographic keys, secure boot chains, and sensitive operations from compromised or buggy application code. Unlike software-only isolation, TrustZone prevents even a fully compromised Non-Secure OS from accessing Secure World resources, making it essential for IoT devices handling credentials, firmware verification, and secure communication.

How Does TrustZone Work on Cortex-M Processors?

TrustZone-M (ARMv8-M Security Extension) divides the 4 GB address space into Secure, Non-Secure, and Non-Secure Callable (NSC) regions. The SAU (Security Attribution Unit) defines up to 8 regions with configurable security attributes, while the IDAU (hardwired by the chip vendor) provides the default security map. When the processor is in Non-Secure state and attempts to access Secure memory, the hardware generates a SecureFault exception—no software check is needed. The NSC region contains Secure Gateway (SG) veneers: special entry points that allow Non-Secure code to call specific Secure functions through a well-defined API. The SG instruction at the start of each veneer validates the transition. Upon entry into Secure World, the processor automatically pushes Non-Secure registers onto the Non-Secure stack to prevent information leakage. This mechanism lets you keep cryptographic keys, private certificates, and secure boot logic in the Secure World while running the main application in Non-Secure World.

/* TrustZone-M: Secure function callable from Non-Secure World */
/* Placed in Non-Secure Callable (NSC) region */
#include "arm_cmse.h"

/* Secure API entry point - must be in NSC region */
__attribute__((cmse_nonsecure_entry))
int secure_encrypt_data(uint8_t *data, size_t len, uint8_t *key_id) {
  /* Validate Non-Secure pointer before dereferencing */
  if (cmse_check_address_range(data, len, CMSE_NONSECURE | CMSE_MPU_READ) == NULL) {
    return -1; /* Invalid pointer - access denied */
  }

  /* Access Secure-only AES hardware peripheral */
  AES->KEY[0] = secure_keystore[*key_id].word[0];
  AES->KEY[1] = secure_keystore[*key_id].word[1];
  AES->KEY[2] = secure_keystore[*key_id].word[2];
  AES->KEY[3] = secure_keystore[*key_id].word[3];

  /* Perform encryption - key never exposed to Non-Secure */
  AES->DINR = *(uint32_t *)data;
  while (!(AES->SR & AES_SR_CCF));
  *(uint32_t *)data = AES->DOUTR;

  return 0;
}

How Does TrustZone Differ Between Cortex-M and Cortex-A?

On Cortex-A processors, TrustZone creates a full parallel execution environment with its own OS, memory, and peripherals. The Secure World typically runs a Trusted OS like OP-TEE, Trusty, or a proprietary TEE, while the Normal World runs Linux or Android. Transitions occur through the Secure Monitor Call (SMC) instruction, handled by a Secure Monitor at EL3 (the highest privilege level). This architecture supports Trusted Applications (TAs) with their own isolated memory spaces. On Cortex-M, TrustZone-M is lighter weight—there is no separate OS in the Secure World (though TF-M, Trusted Firmware-M, provides a standardized Secure Processing Environment). Transitions between worlds happen through branch instructions to NSC veneers, taking only a few clock cycles compared to hundreds of cycles for an SMC-based context switch on Cortex-A.

What Security Services Should Run in the Secure World?

What Is TF-M and How Does It Standardize TrustZone-M?

Trusted Firmware-M (TF-M) is an open-source reference implementation of the Platform Security Architecture (PSA) for Cortex-M devices. It provides a standardized Secure Processing Environment with four core services: Crypto (wrapping Mbed TLS for Secure-side operations), Internal Trusted Storage (ITS) for small secrets, Protected Storage for larger encrypted data, and Attestation for device identity verification. TF-M runs in the Secure World and exposes a PSA Functional API to Non-Secure applications. Zephyr RTOS and Mbed OS both support TF-M integration, where the RTOS runs in Non-Secure World and calls TF-M services through PSA API functions. This standardization allows application code to be portable across different TrustZone-M-equipped MCUs (STM32L5, nRF5340, LPC55S69) without rewriting security services for each platform.

Key takeaway: ARM TrustZone creates hardware-enforced Secure and Non-Secure execution environments that cannot be bypassed by software. On Cortex-M (ARMv8-M), TrustZone-M provides memory-mapped security attribution with SAU/IDAU, while on Cortex-A (ARMv8-A), it enables a full Trusted Execution Environment via Secure Monitor at EL3. TF-M standardizes Secure World services for portable IoT security.

How Did We Implement TrustZone Security for a Connected Medical Device?

At EmbedCrest, we implemented TrustZone-M security on an STM32U5 (Cortex-M33) for a connected insulin pump controller that required HIPAA-compliant handling of patient health data and FDA cybersecurity compliance. The Secure World ran TF-M with four services: Crypto (AES-256-GCM encryption of patient data using hardware-accelerated AES), Internal Trusted Storage (storing the device's X.509 client certificate and ECDSA private key), Protected Storage (encrypted patient dosing history), and Attestation (device identity verification for cloud authentication). The Non-Secure World ran the pump control application on FreeRTOS, accessing Secure services exclusively through the PSA Functional API. We configured the SAU with 6 regions: Secure flash (256 KB for TF-M + MCUboot), Non-Secure flash (512 KB for application + OTA staging), NSC region (4 KB for Secure Gateway veneers), Secure SRAM (64 KB for TF-M stack and crypto operations), Non-Secure SRAM (192 KB for application), and Secure peripherals (AES, PKA, RNG, HASH mapped as Secure-only). The key security property was that even a fully compromised Non-Secure application (via a buffer overflow or malicious OTA update) could not extract the device's private key or read unencrypted patient data, because TrustZone hardware blocks prevented Non-Secure access to Secure memory regions.

What Are Common TrustZone Implementation Mistakes?

The most critical TrustZone-M mistake is failing to validate Non-Secure pointers passed to Secure functions. When Non-Secure code calls a Secure API with a pointer argument, the Secure function must verify that the pointer actually points to Non-Secure memory using cmse_check_address_range() before dereferencing it. Without this check, a malicious Non-Secure application could pass a pointer to Secure memory, tricking the Secure function into reading or writing Secure data on its behalf (a TOCTOU or confused deputy attack). Second, placing too much functionality in the Secure World increases the Trusted Computing Base (TCB) and the attack surface. Keep Secure World code minimal: only cryptographic operations, key management, boot verification, and attestation. Application logic, networking, and sensor processing should run in Non-Secure World. Third, not protecting the Non-Secure Callable region allows Non-Secure code to jump into arbitrary Secure code addresses, bypassing the SG veneer entry points. Ensure all Secure code outside the NSC region is truly non-reachable from Non-Secure state. Fourth, neglecting to clear sensitive data from registers before returning to Non-Secure World can leak information. TF-M handles this automatically, but custom Secure functions must explicitly clear registers containing key material.

How Does TrustZone Compare to External Secure Elements?

TrustZone and external secure elements (ATECC608B, OPTIGA Trust M, SE050) serve complementary security roles. TrustZone provides software isolation at near-zero additional hardware cost and zero additional BOM components, with the Secure World handling key storage, crypto operations, and secure boot on the main MCU. External secure elements provide tamper-resistant hardware with physical attack resistance (glitching, side-channel, probing), certified to Common Criteria EAL5+ or EAL6+, with keys stored in dedicated hardened silicon. For consumer IoT devices with moderate threat models (remote software attacks), TrustZone alone provides adequate security. For devices handling financial transactions, medical data subject to FDA requirements, or infrastructure control (smart grid meters), combine TrustZone with an external secure element: use the secure element for long-term key storage and certificate management, and TrustZone for runtime cryptographic operations and secure boot. This layered approach means that even physical extraction of the MCU does not compromise the master keys stored in the tamper-resistant secure element.