How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion

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):

1. User-level memory enclaves (e.g., SGX)
2. OS kernel-level partitions (e.g., AEGIS)
3. Hypervisor-level hosting of TEE-like guest OS-s (e.g., SEV)
4. Hardware-backed TEE (e.g., TrustZone)
5. 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 sales@codethink.co.uk.