ARM TrustZone and Trusted Firmware: A Practical Guide for Embedded Linux

The European Union’s Cyber Resilience Act (CRA) enters full enforcement in 2027, and from that point “security by design” stops being a differentiator and becomes a legal requirement. For any team building connected hardware, that changes the roadmap: secure boot, data isolation and vulnerability management move from best practice to mandatory, with non-compliant products facing removal from the EU market.

Meeting these requirements is an architectural decision at the system, software and hardware design stages, and not a late-stage patch. Get it wrong, and you are potentially looking at hardware revisions or a compliance failure once the product is already deployed in the market.

As embedded devices become more connected and complex, integrating multi-core processors, Wi-Fi, Bluetooth, and multiple operating systems, their attack surfaces multiply exponentially.

Every new feature is a potential entry point for a malicious actor seeking to steal intellectual property, encryption keys/credentials, operational/user data, or to compromise the system to enable denial-of-service and ransomware attacks.

Cybersecurity and resilience can be met through a hybrid approach that combines hardware-level isolation with secure software architecture; in this article, we will specifically cover ARM TrustZone and Trusted Firmware.

Beyond Theory: Critical Applications of Trusted Firmware

Before diving into the bits and bytes of the architecture, it is essential to understand why solutions rely so heavily on Trusted Execution Environments (TEEs) and Trusted Firmware. Here are three critical domains where Trusted Firmware is heavily used:

Digital Rights Management (DRM) in Media Devices

If you have ever used a set-top box, a smart TV, or a streaming dongle to watch premium 4K content on Netflix, Disney+, or Prime Video, you have interacted with a TEE. High-value media content requires strict cryptographic protection to prevent illegal piracy and copying of content.

With Trusted Firmware, a large part of the DRM pipeline, from negotiating decryption keys with external servers to decoding the actual video frames, is isolated in the Secure execution environment. Untrusted Applications (UA) running in the Rich Execution Environment (REE)) never see the unencrypted keys or video buffers, often enforcing what the industry calls a Secure Video Path.

Biometric Authentication and Mobile Payments

When you authorise a financial transaction using a fingerprint or facial scan on a smartphone or a modern point-of-sale (POS) terminal, Trusted Firmware is protecting your identity.

The raw data from a fingerprint sensor or camera is routed straight to the Trusted Execution Environment (TEE). The Trusted Application (TA) compares the scan against a securely stored cryptographic hash, signs the transaction token with isolated private keys, and simply returns a “Success” or “Failure” status to the Untrusted Application. Your actual biometric data never leaves the TEE or enters the main operating system memory.

Secure Over-the-Air (OTA) Updates and Boot Flow Validation

In the internet era, a device that cannot be updated remotely is a liability. However, the update mechanism and the update package itself are a primary target for hackers. If an attacker can intercept the update process and modify the update artefacts, they could potentially gain full control of your hardware.

Trusted Firmware secures this process by acting as the gatekeeper for Firmware Lifecycle Management. When a new OTA update package arrives, the operating system cannot simply flash it and reboot. Instead, the update payload is verified by the trusted application running in the secure TEE. The TEE cryptographically validates the digital signature of the incoming image against public keys permanently programmed into the SoC’s hardware (e-fuses).

Furthermore, the Secure Monitor verifies anti-rollback counters, ensuring an attacker cannot force the device to boot an older, official firmware version that contains known, unpatched vulnerabilities.

Two Worlds – Core of the Architecture

When designing a secure system, software containers and user-space cryptography are not enough. True security requires a hardware root of trust.

ARM TrustZone achieves this by splitting the processor’s architecture, memory, and execution states into two completely isolated environments:

• Non-Secure REE (Normal World): Where your standard operating system (like Embedded Linux), user interfaces, and standard applications (e.g., a GUI, web browsers) run.
• Secure TEE (Secure World): An isolated execution environment where a lightweight, highly secure operating system (a Trusted OS, like OP-TEE) runs. This environment handles sensitive operations such as cryptographic key management, authentication, and secure storage.

When switching from Normal to Secure World, the device’s CPU enters secure state. Because of this, the CPU can now execute instructions in a secure context, ensuring secure assets remain inaccessible to arbitrary software.

In this architecture, untrusted applications cannot read or write to memory regions assigned to the secure environment. Even if a hacker gains root system access privileges to your operating system, the hardware prevents them from accessing the secure environment to steal your master keys.

ARM Exception Levels

To understand how secure and non-secure applications interact, we must look at Exception Levels (EL) in the ARM architecture. In this framework, execution levels dictate privilege: the higher the number, the greater the architectural control.

On ARM architecture, exception levels are following:

• EL0 (User Space): Highly restricted. Applications running here have no direct access to hardware, the Memory Management Unit (MMU), or interrupts. They must ask for permission to do anything meaningful.
• EL1 (Kernel Space): This is where the standard Linux kernel (and the Secure OS on the isolated side) lives. It manages hardware resources and MMU configurations on behalf of the user-space applications.
• EL2 (Hypervisor): Heavily used in sectors such as automotive, this level manages multiple guest operating systems via virtualisation.
• EL3 (Secure Monitor): This is the highest privilege level on the chip. It controls everything beneath it and acts as the gatekeeper, physically switching the CPU context between the Non-Secure (Normal) and Secure worlds.

How the Worlds Communicate

When a normal (untrusted) application needs a secure operation performed, such as verifying a signature, it triggers a chain of events across these levels using explicit assembly instructions:

• EL0 (Normal Application): Calls a function in a rich user-space library, which issues an SVC (Service Call) instruction to talk to the kernel.
• EL1 (Linux Kernel): Captures the request and passes it to the TrustZone driver. The driver executes an SMC (Secure Monitor Call) instruction.
• EL3 (Secure Monitor): The SMC drops the system into EL3. The Secure Monitor checks permissions, saves the Normal World state, switches the CPU to the Secure state, and drops into the Secure World’s kernel.
• EL1/EL0 (Secure World): The Trusted OS (OP-TEE) routes the request to a Trusted Application (TA), which performs the cryptographic work and passes the result back through the same chain in reverse.

During a secure boot sequence, each component verifies the cryptographic signature of the next component before executing it. If the bootloader or Linux kernel image has been corrupted or tampered with, the chain breaks, and the system refuses to boot, neutralising potential exploits before they can execute.

Developing for the Secure World: The Host-TA Architecture

If you want to build custom security features, you will likely leverage OP-TEE (Open Portable Trusted Execution Environment), the open-source, industry-standard framework backed by Linaro and Trusted Firmware.

Developing an OP-TEE application requires a shift in mindset. You are not writing a standalone binary; you are creating a split client-server system:

1. The Host Application: Runs in standard Linux user space (Normal World, EL0). It acts as the client.
2. The Trusted Application (TA): Runs inside the Secure OS environment (Secure World, EL0). It acts as the server.

Every Trusted Application must implement a strict, standard lifecycle API to communicate with the host:

• TA_OpenSessionEntryPoint: Called when the host initialises a connection to the TA.
• TA_InvokeCommandEntryPoint: The core execution engine. The host sends a command ID (e.g., CMD_ENCRYPT_DATA) and a pointer to a shared memory buffer. The TA processes this command via a standard switch-case architecture.
• TA_CloseSessionEntryPoint & TA_DestroyEntryPoint: Handles cleanup and tears down secure contexts.

The Reality of Secure Development: What They Don’t Tell You in the Manual

Developing trusted applications comes with a steep learning curve and several stark constraints that catch traditional software engineers off guard:

• No C++ Allowed: TAs must be written in pure, tightly optimised C.
• Stripped-down Standard Libraries: You cannot use standard glibc. The available C library in the secure world is heavily minimised to keep the footprint small and reduce the attack surface. Many common convenience functions simply do not exist.
• No Traditional Debugging: Forget about running traditional debugging tools inside the secure world. Debugging involves using a mixture of SoC-specific tools and instructions, raw kernel memory dumps, and secure print statements.

Secure Your Next Project with Consult Red

This article covers how to navigate the complexities of ARM TrustZone, configure TF-A bootloaders, and write secure OP-TEE applications. Other TEE-based solutions exist and vary by chipset and SoC vendors; at Consult Red, we have broad experience with SoC vendor solutions across multiple domains, including Media, Broadband, and Industrial/IoT.

Designing, developing and maintaining a secure device is a significant engineering undertaking, and many teams don’t have the required skills in-house. With the EU Cyber Resilience Act enforcement date looming, mistakes made during the architectural phase can result in costly hardware revisions or regulatory compliance failures down the road.

At Consult Red, we specialise in embedded software and hardware development, with over 20 years of experience in hardware root-of-trust and embedded security. We help companies design resilient, secure-by-design products that protect intellectual property and comply with global regulatory standards.