Arm TrustZone explained

Arm TrustZone is a system-wide approach to embedded security option for the ARM Cortex-based processor systems. Cortex-based cores are used in everything from microcontrollers (MCUs) to high-performance processors. Arm TrustZone is an embedded security technology that starts at the hardware level by creating two environments that can run simultaneously on a single core: a secure world and a not-as-secure world (non-secure world). Increasingly, developers need to secure systems beginning at the lowest levels, at the physical layer, which includes the boot up process, as hacking can target the boot up process.

Security is a big concern for embedded hardware, especially for connected devices. Connection to the internet provides a venue for hacking, which can range from Distributed Denial of Service (DDoS) attacks to unauthorized access to internal networks.  The vulnerability of the Internet of Things (IoT) is especially concerning since DDoS attacks have used millions of unsecured internet-connected devices like Closed Circuit Televisions (CCTVs) to launch massive attacks. The internet has been used to avoid wiring costs, without thought to security, but that must change.

To deal with the security issues for embedded devices, Arm created the Arm TrustZone technology.  Arm Cortex processors with TrustZone run a secure operating system (OS) and a normal OS simultaneously from a single core. TrustZone can secure a software library or an entire OS to run in the secure area. Non-secure software is blocked from access to the secure side and resources that reside there. TrustZone is based on the principle of least privilege, which means that system modules like drivers and applications do not have access to a resource unless necessary. Software runs in the secure or the non-secure environment. Work that must transpire between the secure and non-secure environments takes place via software called the “core logic” (Cortex-M processors) or the “secure monitor” (Cortex-A processors). According to Arm, “This concept of secure (trusted) and non-secure (non-trusted) worlds extends beyond the processor to encompass memory, software, bus transactions, interrupts and peripherals within an SoC… By creating a security subsystem, assets can be protected from software attacks and common hardware attacks.”[i]

Providing a secure system environment is called a Trusted Execution Environment (TEE). The TrustZone TEE can dedicate specific areas of memory for security purposes, which allows the storage of sensitive information for such things as Point-of-Sale (POS) devices and Digital Rights Management (DRM).  The non-secure OS can’t access TrustZone’s secure areas, regardless of privilege level.

Cryptographic operations execute in the secure world. In this example, not even Linux kernel operations have access to security features or keys that are isolated in the secure world. Awareness of the TEE is not obvious for end users with kernel access and rights.

TrustZone includes a Secure Boot Sequence verifies secure boot images. Images can be cryptographically authenticated using public and private keys. Once the system has finished booting up, the two OSes can communicate via a monitor kernel mode, which behaves much like a context switch. Software in the non-secure world can communicate resource requirements from the secure world using a TrustZone software instruction called the Secure Monitor Call (SMC). Hardware interrupts and external abort signals will institute a full context switch. (A context switch is when the kernel suspends execution of one of the CPU’s processes to resume execution of another, previously suspended process.)

Although no device can be made entirely hack-proof, TrustZone makes it much more difficult.  The downside is increased complexity in the development process if you run an entire OS in the secure world since there would be two OSes, each with a separate kernel. All processes must be carefully engineered so that security maintains continuity all around. Operational modes and transitions between modes require validation. TrustZone is not bulletproof; there is still an obligation for coders to create code intelligently and take common-sense security measures. To learn more about Arm TrustZone, see Security on Arm TrustZone or for a very detailed explanation, read “TrustZone Explained: Architectural Features and Use Cases” by Bernard Ngabonziza, Daniel Martin, Anna Bailey, Haehyun Cho and Sarah Martin.

[i] https://www.arm.com/products/security-on-arm/trustzone