Arm Trustzone has been popularised as a way to isolate security related features from the rest of any system.
During this blog series we investigate the challenge of continuously maintaining security in complex systems.
Therefore given the introductory background we have from the first entry, we now expand on top of this and look into viable alternatives to Arm TrustZone also used in modern systems.
How do the alternatives compare with Arm TrustZone (like the TPM, Intel's SGX, AMD's SEV, or Sanctum for RISC-V)?
The following information is based on the comprehensive survey from Pinto and Santos published in 2019 we also introduced in our previous blog post.
TrustZone is only available on Arm devices, hence the next question is what is the landscape like on alternatives? For a brief introduction, TrustZone, TPM, and SGX are among the most commonly used options, while other solutions tend to be more niche or academic. However, they all introduce hardware security at different levels in a system (corresponding to levels visible in the figure below):
- User-level memory enclaves (e.g., SGX)
- OS kernel-level partitions (e.g., AEGIS)
- Hypervisor-level hosting of TEE-like guest OS-s (e.g., SEV)
- Hardware-backed TEE (e.g., TrustZone)
- Coprocessor-level functionality offloading (e.g., TPM)
SGX provides hardware encrypted memory regions called enclaves to processes running in user space and Sanctum is doing the same but without encryption. However, similar to TrustZone, old Intel x86 systems used an approach called SMM that used hardware-level isolation.
AEGIS is an hardware-agnostic approach that partitions the OS kernel to maintain Tamper-Evident Environments (TEs) to detect malicious activity. Then there are approaches to provide isolation at the hypervisor level like AMD's SEV which is supporting TEE-like environments on a guest OS.
The last option is to have a separate trusted processor on the board which is called a TPM. TPM is not used to execute any resource-hungry processes like the TEE can but to only bootstrap the trust of the platform that can be used in tandem with all of the aforementioned technologies during the secure-boot process. An alternative to TPM is Intel's recent ME engine that can host some small amounts of code as well.
In the automotive industry there are additional options being more widely used: namely the Secure Hardware Extension (SHE) and the automotive specific EVITA HSM. Plappert et al., in 2022 evaluated different Hardware Trust Anchors (HTAs) in the automotive domain which resulted in informative comparisons between the various options in terms of security but also flexibility and usability. For example, their analysis claims that TPMs provide the best solution in terms of creating a small isolated security oriented root system and the software ecosystem around using these is fairly mature (demonstrated by the existing integration in Linux and Windows systems). But they are lacking in raw performance, due to which the use of some certain implementations of TrustZone that include crypto accelerators could be justified. However TrustZone provides a larger attack surface and the ecosystem around TrustZone is less mature which is why many hardware solutions in all 5 levels previously introduced, are viable in different scenarios.
Next, we will explore the feasibility and reasonableness of avoiding the use of hardware modules altogether.
How do software equivalent security libraries compare (e.g., OpenSSL, WolfSSL, SoftHSM)?
The main idea behind isolating security related processes and services to hardware components is to avoid bloating the existing trusted computing bases (TCBs) that typically consist of the OS kernel and privileged services and libraries where adding to the already large complexity of these systems increases the likelihood of undetected security vulnerabilities.
Identifying the TCB is crucial as it is then referred to as a minimal set of hardware and software components that must be trusted as uncompromised in order to fulfil the system security guarantees.
Instead of continually adding additional permission levels, another approach is to better organise the two layers of user-land and kernel-level privileges. However, even if all components in the kernel are verified trustworthy on their own, the sheer number of them working concurrently make it difficult to formally prove that they never affect the state of the system in unpredictable ways (e.g., anecdotally, large legacy device drivers made for old printers and protocols are discouraging for making strong safety or security claims). This is also part of the reasoning behind using alternatives to Linux based systems like QNX that are used for safety-critical applications.
Nevertheless there is a strong claim to make with software equivalent crypto libraries - they're more maintainable than the proprietary services inside the hardware modules. In practice either way systems that are designed to use HSMs often need to provide a software equivalent library (e.g., SoftHSM, Mozilla's NSS, Microsoft's CNG, WolfSSl, and OpenSSL) in case the hardware isn't available. In some aspects, the software equivalents can provide more security due to their transparency because if there are additional higher privilege statuses with obfuscated implementation there could be easily exploitable security vulnerabilities that sidestep all of the high-quality security libraries inside the user-land and kernel-land.
All in all, the automotive industry and others adhere to widely respected standards like FIPS from NIST and ISO, meeting them using both HSMs and software libraries. Next, in the last entry of this blog series, we will examine how hardware vendors provide access to these features and provide evidence for establishing trust.
If you'd like to learn more about this topic, or discuss how we can support your business, please reach out to us via email@example.com.
- 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 one 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