Cryptography protects sensitive and mission-critical data, which entails designing systems and protocols that securely exchange and store keys to access such data.

In order to establish a secure communication channel, all involved parties must agree on a common trust anchor. For example, updating sensitive safety-critical software - the package must come from a trusted source that can be verified using the anchor in conjunction with formally proven cryptographic protocols, such as those provided by libraries like OpenSSL.

Rather than assuming that the underlying software is trustworthy, the industry is increasingly building systems that derive software trust (with methods such as measured and secure boot that can enable creating a trustworthy chain of certificates vouching for the underlying component). Nowadays, the tamper-proof Root of Trust is built into hardware designed by reputable parties.

While this article refrains from delving into the security discussions about the verification of these tamper-proof techniques, we will shed light on the prevalent hardware security modules that facilitate trust anchors.

This article is part 1 of a 3 part series. In this part, we will give a brief historical overview before giving a technical overview of Arm TrustZone.

Modern history of hardware security modules

Recently, there has been an increasing amount of interest around Hardware Security Modules (HSMs). Trusted Platform Module, or TPM has been supported since the release of Windows 8 in 2012 for various security and access verification related functionality. TPM, first widely deployed in 2003, is a separated hardware module that establishes a more trustworthy and smaller root of trust than only using a CPU as its functionality is deliberately limited and designed only for the purpose of providing security guarantees. Linux distributions also allow installing modules that use TPM for disk encryption, measured boot and establishing trust (and there are a plethora of libraries that can use TPMs, e.g., GnuPG, the golang library sks, or even custom providers for OpenSSL that enable TPM use).

Modern Apple products also contain a hardware security module branded Secure Enclave. The initial versions of Apple's Secure Enclave were done with Arm TrustZone before they started using their own separate chips. Arm TrustZone, first released in 2004, can provide additional features (depending on implementation details) missing from TPM, like secure peripheral access, and has been used in the Android world with Android Keystore since the release of v4.3 in 2013. Due to the OP-TEE and GlobalPlatform standardisation efforts, TrustZone has become more adaptable recently and is also accessible through custom hardware on AMD FPGAs (formerly Xilinx).

Thanks to the increasing accessibility of TrustZone and increased adoption of TPMs, this trend is now becoming a discussion topic among Linux distributions which also are considering the more widespread use of HSMs. Likewise, the mobile, automotive and aerospace industries are expanding the use of HSMs.

What is Arm TrustZone and why should anyone use it?

We begin by exploring TrustZone, which offers more flexibility than TPM because, instead of being a separate hardware module per se, it represents a method for segregating hardware functions from untrusted environments using an additional security flag. However, keep in mind that it is not necessarily a better solution than its alternatives, as they all have various tradeoffs. To better understand TrustZone, we recommend consulting either the comprehensive survey from Pinto and Santos published in 2019 or the shorter introductory blog post from Trustonic, a company that sells software solutions to use TrustZone features. Our explanation below is based on these sources.

Rather than relying on either a) applications to behave nicely by isolating data between processes or b) Memory Management Units (MMUs) to police memory access requests, that could be bypassed in multi-core heterogeneous systems, the TrustZone approach proposes that the hardware should have an isolation layer between the user-facing application and the memory/peripherals providing the data. With this isolation, in order to access the walled off data, an additional magic bit has to be set in hardware interfaces that can only be done by a trusted component living in the secure environment - another OS-like system called the Trusted Execution Environment (TEE) running Trusted Applications (TAs). This TEE can then transfer the data to all user-facing applications in the untrusted world which can be either a single OS or a system of OS's managed by various hypervisor layouts - where for simplicity the untrusted world is called a Rich Execution Environment (REE).

Apps in the REE can use TEE processing through a new privileged instruction call (SMC), which involves a context switch into the secure world (or alternatively using new specialised branching instructions to switch state on low-power microcontrollers), similar to existing system calls for accessing OS resources in the REE.

An important side note is that the TrustZone specification includes optional memory control units that isolate access with an additional bit. This ensures that anything in the REE cannot access memory (including cache lines) allocated in the TEE. However, not all System-on-a-Chip (SoC) or microcontroller implementations include this isolation feature. In general, this means that TrustZone allows for the partitioning of system resources in such a way that some resources can be isolated and made accessible only with higher privileges than those available in traditional operating systems.

As a result, if sufficient attestation (verification) protocols are in place, any remote party can establish trust with the underlying TEE, even if the REE has been compromised. Through secure communication channels (created with libraries like Mbed TLS) secret keys can be exchanged and stored in the TEE (where safe storage is enforced by privileged firmware) without exposing them.

An example

The most appealing example here is having a secure connection to cloud services where the TEEs of end-user devices are used to manage the secret keys to decrypt data stored (in encrypted form) on any cloud services. Then the devices can make any sensitive operations in the trusted world before safely discarding the unencrypted data. Or vice-versa, sensitive user data can be processed in a server TrustZone (there are now a surprising amount of server-grade Arm processors) without exposing it to the cloud provider even if the server administrator privileges are compromised.

For example, Samsung Pay ensures the safety of payment information by storing access keys in the Samsung Knox Vault, which is implemented with TrustZone. When a payment is issued, the phone interacts with the secure hardware modules; the actual payment information is decrypted and utilized securely, ensuring that sensitive data remains isolated from potentially compromised components of the device's OS or other apps, as this memory is segregated from the rest of the system and accessed only after successful attestation protocols.

In general, the higher privilege mode built into the hardware is an appealing solution for isolating all security related functionality from the rest of the system. We examine other alternatives to Arm Trustzone in the next blog in this series.

If you'd like to learn more about this topic, or discuss how we can support your business, please reach out to us via sales@codethink.co.uk.