Developed by ARM technologies in 2004, TrustZone is a secure hardware extension that keeps digital keys and sensitive resources in a secure zone. Its primary objective is to create a hardware-enforced barrier that creates a separate secure and non-secure zone within device processors.
Navigating through the security ecosystem of connected devices, you might have often heard of Trusted Execution Environment (TEE). Known for providing a safe environment to execute and process sensitive codes it protects the integrity and confidentiality of data.
While aware of how the TEE works in simple devices, we often fail to understand what powers it in complex computer systems like modern vehicles. On most automotive processors, which are ARM-based platforms the TEE is powered by TrustZone.
What it does? Let’s understand with an example.
Imagine one fine day you somehow connect an infected USB drive to your car’s infotainment system that introduces a bug in your device’s media player or allows a malicious app to access your personal credentials.
The consequences? You can imagine better!
As technology advances, external threats continue to put your devices and sensitive data at risk.
TrustZone adds an extra layer of security that creates an isolated environment within the same processor or SoC, accessible only to trusted entities.
Overview of TrustZone Architecture in TEE
At its core, TrustZone is a hardware-based security extension that creates an isolation space within the automotive TEE, enabling the creation of differentiated trusted and untrusted code execution environments.
Rather than relying only on isolation powered by software or a solution that adds separate security hardware, TrustZone builds security into the processor itself. This mechanism helps it to control parts of the system that can access sensitive operations and data.
So basically, TrustZone creates a space that divides the system into two distinct worlds:
- A secure world that enables trusted code and sensitive data (such as encryption keys, root-of-trust logic, or bootloaders) to be stored and accessed by trusted individuals.
- Another, a normal world where general-purpose applications, drivers, and potentially vulnerable third-party code execute
The processor of TrustZone dynamically keeps switching between these two different states using a mechanism known as the Secure Monitor Call (SMC) instruction. This allows the system to maintain operational performance alongside making sure that critical resources remain inaccessible from non-secure execution layers.
Moreover, the architecture of TrustZone is further strengthened by its ability to propagate across the entire SoC. This ensures that only trusted entities can access secure memory regions or configure specific hardware blocks.
Application of TrustZone in Embedded Systems
Initially launched to protect the Touch IDs in mobile devices, the potential of the technology further came into application in embedded systems.
The tech working behind automotive applications often relies on varying trust levels and runs on the same processor as others to perform different functions. This makes it vulnerable to non-critical services acting as an entry point for malicious actors that have the potential to compromise secure operations.
TrustZone acts as a barrier to prevent the entry of such miscreants. It creates isolated execution environments within a single processor, ensuring that even if the main OS is compromised, the attacker can’t access secure resources.
Why TrustZone Is Critical in Modern Automobiles
As we rapidly advance, the future of vehicles transitions into more of a software-defined platform with infotainment units, V2X communication, and safety-critical ECUs all interconnected, which exposes it to the risk of cross-domain attacks.
For Automotive OEMs and suppliers involved in the development of E/E architectures, the role of TrustZone is imperative for various reasons. It provides:
- Scalable, silicon-level security mechanism to enforce functional isolation,
- Enables secure boot,
- Protects cryptographic material, and
- Meets evolving security standards (i.e., ISO/SAE 21434 and UNECE WP.29)
Well, if you are wondering where this is all put into application, basically, it’s all around.
Authenticating over-the-air updates to verify digital signatures in a secure environment and preventing malicious or tampered firmware from being installed.
Enabling software-defined features, consider an example of the system that provides the feature to enable seat comfort, (i.e., heated seats). In some cases, such features are offered by manufacturers post-purchase via a software update. TrustZone keeps a check on the activation of keys and verification logic for such a feature and securely stores and executes it only in the secure world, preventing unauthorized access, cloning, or activation.
Furthermore, as In-vehicle payment systems develop, they allow users to pay for EV charging, tolls, or parking directly through the vehicle’s infotainment system. TrustZone secures the personal details, such as credit card or digital wallet credentials, storing and processing them in the secure world.
Moreover, to enable safety separation, TrustZone helps in creating an isolation space between safety-critical ECUs and less-trusted domains. For instance, consider a connected car with a compromised infotainment system through an infected USB drive.
Functioning of TrustZone in Automotive Systems?
Well, it’s probably clear by now that primarily, TrustZone builds hardware-enforced barriers that help automotive systems reduce the attack surface and retain the integrity, confidentiality, and availability of automotive systems.
But the question is, how does TrustZone work during automotive boot and runtime?
The overall functioning of TrustZone in automotives follows a step-by-step procedure. So basically, when a system boots:
- The TrustZone-enabled SoCs initiate the process in the secure world, which enables the trusted firmware and bootloaders to execute before other components.
- Next, the secure boot process verifies the integrity and authenticity of each software layer, preventing any tampered or unauthorized code from launching.
- Once the secure boot phase completes, control is passed to the normal world, where the general-purpose OS and standard applications operate.
However, it is important to note that the secure world remains inactive but accessible, and the processor switches to it only when specific instructions such as Secure Monitor Calls (SMCs) are executed to transition between the two worlds.
These transitions between the Secure and Normal Worlds are orchestrated by the underlying hardware, primarily ARM Cortex processors which enables TrustZone functionality across different system domains.
Hardware Support for TrustZone: A/R/M Cortex Processors and Their Role
Often referred to as the backbone behind the operation of the TrustZone processors, the ARM Cortex steers the functioning of different systems in vehicles.
In automotive applications, it supports TrustZone with two major Cortex families:
- The Cortex A series, which is typically used in systems like digital cockpits, infotainment units, and central vehicle gateways, is mainly built for handling complex, resource-heavy tasks.
- On the other hand, the Cortex M series is a lightweight microcontroller used in real-time and safety-critical systems like airbag controllers, braking systems, or steering ECUs.
Cortex-A and Its Role in TrustZone
Developed for performing high-performance tasks, Cortex-A is primarily known for its ability to separate the processor into two environments, a Secure World and a Normal World. It allows trusted functions like secure boot, key management, and access control to happen separately from regular OS activities.
For modern automotive architectures, this separation is imperative, as these high-performance units handle multiple domains, including infotainment, telematics, and diagnostics.
Cortex-M and Its Role in TrustZone
Designed for perform tasks that require quick response and low power, TrustZone was brought to the Cortex-M family. This addition was a significant step forward for embedded systems that require strong isolation but run on more resource-constrained hardware.
It offers lightweight security suitable for applications that don’t require full system isolation but benefit from separating safety or secure logic from non-secure control code.
Example: A body control module using a Cortex-M may separate secure update logic from regular operations to ensure firmware integrity even during maintenance.
Cortex-A | Cortex-M | |
---|---|---|
Use Case | High-performance systems (infotainment, digital cockpit, gateways) | Low-power embedded systems (e.g., body control, window motors) |
Performance | High computing power | Optimized for low power and fast response |
Operating System | Runs rich OSes like Linux or Android | Typically runs RTOS or bare-metal firmware |
TrustZone Support | Full TrustZone (Secure & Normal World) | TrustZone-M (Secure & Non-secure states) |
Security Focus | Protects complex systems from untrusted apps | Secures lightweight control systems from interference |
Relevance of Cortex R in the TrustZone
Alongside the Cortex A and M series, there exists another critical processor Cortex R that does not directly support the TrustZone but operates on its isolation principles in advanced SoCs.
Their architecture supports real-time, deterministic execution, crucial for ECUs controlling powertrain, ABS, or braking systems.
For example, a vehicle’s central computer system may use a Cortex-A for infotainment and diagnostics, while a Cortex-R core executes real-time critical safety tasks, ensuring that even if the infotainment system is compromised, the vehicle’s safety remains unaffected.
Moreover, it is purposely built for applications demanding high reliability, deterministic performance, and fault tolerance.
TrustZone vs. Other Hardware Security Solutions in Automotive Security
Reading through the guide, you might have come across a thought about why is TrustZone preferred over other hardware security solutions in automobiles. Well, the primary reason lies in its powerful core which other HSMs do not provide.
Moreover, unlike Secure Elements (SEs) and Trusted Platform Modules (TPMs), which are separate chips dedicated to secure key storage and hardware root of trust, TrustZone operates directly on the main CPU. This allows it to isolate secure and non-secure environments within a single SoC, reducing latency and cost.
Compared to Intel TXT or SGX, which are designed for x86 systems and require more complex setup, TrustZone is optimized for ARM-based architectures offering efficient power consumption solution making it a natural fit for embedded platforms. Additionally, unlike hypervisor-based virtualization that emulates full systems, TrustZone offers lightweight isolation with minimal overhead.
Frequently Asked Questions
TrustZone is used to create a secure execution environment within the processor, enabling isolation between trusted and untrusted code. It protects sensitive data like encryption keys and ensures secure boot, access control, and functional safety in embedded systems.
ARM Cortex refers to a family of processors in embedded systems that handle various computing needs. Cortex-A supports high-performance applications, Cortex-M handles tasks that require quick response and low power tasks, and Cortex-R is designed for safety-critical real-time operations with reliability and fault tolerance.
ARM processors power embedded systems by offering scalable computing for both performance-heavy and real-time applications. They support secure operations through TrustZone, enabling functional separation, secure boot, and protection of critical data in automotive and IoT environments.
ARM processors offer low power consumption, high performance, scalability across applications, and built-in security features like TrustZone. They support diverse workloads, making them ideal for embedded and automotive platforms.
Wrapping Up
In the aspect of today’s developing ecosystem, in parallel to technology, the risk around cybersecurity is rapidly advancing. TrustZone lowers the risk of cyberattacks caused by attempts on OS and device processors.
As detailed in the article, its role is growing to be imperative with the evolving threats to vehicle security highlighted under the regulation of ISO/SAE 21434 and UNECE WP.29.