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.
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 firstname.lastname@example.org.
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: exploring a bug in stack unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Long Term Maintainability
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Full archive