How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion

So far in this blog series we have introduced a wide range of security modules and libraries available:

1. Part one - introduction
2. Part two - comparison

To summarise our findings, we will now discuss how to practically implement these security features.

How do hardware vendors provide access to hardware security features?

Let's examine the TrustZone as there is more flexibility on how hardware security modules could be integrated. Each SoC manufacturer implements a different set of TrustZone features (e.g., different levels of integration with memory isolation and/or crypto accelerators) and hence also exposes these through different interfaces and APIs (often proprietary) accessible in the untrusted world. Then there are the vendor-specific drivers in the TEE that listen to requests from the untrusted world to initiate the context switch into the trusted world. Some of these interfaces are application/vendor specific (e.g., Android Keymaster's reference implementation can be modified further by vendors), however there is increasing demand for standardised APIs to make any TEE (Trusted Execution Environment) work with any TA (Trusted Application) and any REE (Rich Execution Environment). For example, PKCS#11 and GlobalPlatform Client API are used to interface TEE to the REE and other GlobalPlatform APIs are for developing interchangeable TEE kernels and TAs.

Another approach is to provide a specific service in the trusted world that is paired with a custom-made TA, rather than accessing an OS-like managed system in the trusted world through a generic system call. This is demonstrated by how Android uses TrustZone widely available in the mobile market. For example, DroidVault provides trusted storage and similar examples are available for generating one-time passwords, providing authentication or access control services. Here end-user applications wouldn't access the TEE but the front-end of the service in the untrusted world as the interface between the TEE and REE is again proprietary. The TrustZone is then exposed through a collection of untrusted-world applications communicating with their counterparts in the trusted world - however, this collection is not particularly rich at the moment given the effort needed to support this on all platforms.

An interesting note here is that to avoid duplicating untrusted world functionality, optionally various TAs can be used as front-ends to processes in the untrusted world OSs that behave as back-ends (e.g., device drivers for input, display and network). However, using kernel-level processes inside TAs has to be done with care to avoid introducing new vulnerabilities and should be avoided if the REE is compromised.

In order to stimulate the development of a richer choice of platforms and user-land libraries with hardware-backed security features, there is an open-source reference firmware stack: TF-A and TF-M. These target the TrustZone on Arm’s Cortex A and M-series products, respectively for high-performance and low-power requirements, and with an LTS version released this year, the community can build upon it and start using standardised APIs. These open-source firmware stacks are then used by both proprietary and open-source TEEs (e.g., in OP-TEE, TF-A is used to boot securely).

Pros and cons of HSMs

Adding more security layers always increases the overhead of developing and using the provided service and hence it is a question of risk-management. How does the benefit for a malicious attacker compromising your system scale against the effort the attacker has to put in to gain significant enough access? If the service you are providing is safety-critical or contains highly-confidential and sensitive data then adding as many security layers as the runtime responsiveness requirements allow should be the chosen strategy.

Briefly, the pro here is evident: Hardware security modules offer an additional layer of security, ensuring that critical functionality, when implemented correctly, can be executed with a higher degree of certainty in its integrity and safety.

The cons of using HSMs (especially when talking about hardware-isolated TEEs like those present in TrustZone), can be summarised with the following:

1. APIs are not well standardised, so interfacing between different systems is more complex
2. Low flexibility of the functionality provided

If we take the TrustZone as a reference, the first highlighted con can be explained by the large pressure to make TEE processes as trustworthy and bug-proof as possible which requires a lot of work that is then gated behind proprietary licences and obfuscation to hide any potential exploits. The second point can be explained by the design reasoning to keep the TEE as light-weight and small as possible to have higher confidence that the whole TEE component is secure. Due to these 2 main cons, the adoption of TEE-like systems has been low as there isn't enough information available to confidently prove the safety of these systems (with numerous security vulnerability exploit examples justifying the lack of trust).

As a side note, the use of HSMs has mixed feelings from the wider consumer community as it also allows putting potentially undesired features (e.g., DRM-enabling checks that are supported by Arm's Dynamic TrustZone approach) into non-bypassable proprietary enclaves of end-user devices.

Finally, we will discuss how hardware-backed security features could be implemented in practice.

How to make hardware security modules more practical

The main question is at which level do we want to introduce hardware-backed security features, given that we have decided we want them in the first place? As discussed in our second article in this series, where we compared TrustZone to its alternatives, hardware security features can be introduced at different levels.

Each option deserves careful consideration as they all provide different pros and cons, however given the significant market share of Arm and the number of devices that have TrustZone available, especially in the mobile space, we consider this an appealing option given the effective use of Android systems that successfully utilise TrustZone.

The easiest way to start using TEE-enabled services is to develop both the trusted and untrusted versions of the service simultaneously, as done in Android KeyStore/KeyMaster. However, developing two applications implies extra costs. Alternatively, device vendors could make it possible to use a GlobalPlatform compliant TEE for universal TAs that the open-source community can pair with the respective user-land facing app resulting in a richer library of TAs and TEE-backed services.

There are multiple open-source TEEs - Open-TEE and OP-TEE or Google's Trusty. These provide a way to add your own TEE next to the device vendor-specific TEE where you can import your device-agnostic services that adhere to GlobalPlatform TEE Specifications. Alternatives can be also considered due to the lack of trust in the quality of vendor provided services (e.g., Rust based TEEs prioritising memory-safety, the largest source of vulnerabilities in TEEs). Nevertheless, there aren't many examples of devices hosting multiple TEEs - the main reason being that developing and deploying an additional TEE involves a lot of work given that device vendor specific TEEs exist already.

It should be noted that supporting both vendor TEEs and open-source TEEs has its drawbacks. Having multiple TEEs in a TrustZone environment can reintroduce the original problem of having overly large TCBs (trusted computing bases). Originally, the TCB was just the OS, then it expanded to include trusted virtualized OS images, then TrustZone, and now it includes multiple virtualized TEEs within TrustZone. The possibility of hosting multiple TEE kernels has led to the proposal of another higher-priority, access-rights-owning environment inside the TrustZone by Arm. Given the ongoing evolution and dynamism in the field, particularly with the idea of adding additional priority levels, it may be prudent to stick to more universal solutions for now, rather than locking into vendor-provided proprietary solutions. One such universal solution might involve the painstaking support of a library at the OS level (e.g., providing HSM-based plugins with QNX's qcrypto library or with Java's JCA/JCE API) to accommodate various device-provided TEE-based services. However, there is already a vast number of services as listed in the NIST's validation program adhering to various APIs making any generalisation efforts difficult. In cases where there is a lack of TrustZone-based user-land libraries, software equivalents could be provided as an alternative. Alternatively, a strong standard could be created that vendors must adhere to, similar to the AUTOSAR standard in the automotive industry, which has a separate crypto API.

Further analysis requires case studies of systems created using these technologies both in academia and industry.

Conclusion

Contemporary technology has adopted hardware security modules, leveraging features provided by add-on hardware security modules. These features allow bootstrapping the chain of processes that verify the trustworthiness of the data the end-users interact with. In this article, we discussed that there are alternatives that introduce the additional features at all possible levels:

1. User-level
2. Kernel-level
3. Hypervisor-level
4. Hardware level on the same die
5. Coprocessor level

Selecting the optimal option lacks a one-size-fits-all answer. Regardless of the choice, significant integration efforts are required, primarily due to the absence of standardisation. In this realm, contributions from the open-source community are invaluable and highly encouraged.

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.