As part of a semester project I worked on integrating a firmware-based trusted platform module (fTPM) on a Arm-based SoC. In the following article I’d like to share my experience with the project and my thoughts on use cases and benefits of TPMs.

What TPMs are

Trusted Platform Modules (TPMs) are defined by an international ISO standard, drafted by an industry consortium known as the Trusted Computing Group. The standard defines the architecture of the device and the command set a TPM must support. In summary, a TPM can perform various cryptographic operations using its internal cryptographic subsystem, such as key generation or data sealing. Also, TPMs incorporate a random number generator and offer memory to store integrity measurements. A TPM provides an isolated environment, which means that sensitive data such as cryptographic keys are protected even in case of an operating system level compromise.

What TPMs are not

TPMs cannot execute user code, and are different from trusted execution environments or secure enclaves. Instead, they only provide a standardized API for a (rather small) predefined set of cryptographic operations. They can not store a lot of data, and are usually only used to encrypt secondary keys which are then used to encrypt bulk data residing on main storage. A TPM is not a magical security chip that makes a product immune to attacks. By itself, it does not prevent the execution of malicious code or defend against exploitation of application or OS vulnerabilites.

Discrete TPM chips only offer very little protection against physical attackers in some scenarios, because these devices communicate in clear text with the main processor, so an attacker with physical, board-level access can easily eavesdrop on the communication. This has been known for a while, but it was shown again recently in a nice proof of concept attack by Thomas Roth (stacksmashing). While fTPMs do not have this particular problem, they can still be vulnerable to side-channel, and other, more sophisticated, attacks. Firmware-based TPMs in AMD processors have also been broken by security researchers in the past.

At least in my opinion, TPMs are not an evil plot by Microsoft to take away user freedom. TPMs are not responsible for DRM, and are not to blame for secure-boot-enabled systems only executing Microsoft-signed code. While Microsoft provides the open-source reference implementation of the TPM firmware, and was likely the main reason for widespread TPM adoption due to mandating it for Windows 11, all TPM functionality and benefits can be achieved on Linux and other open-source software. After all, a TPM is a rather passive component in the sense that it does not actively prevent code execution, so it is up to the user software whether or not to make use of it. If this choice does not exist on a particular system, this is the fault of firmware designers, not of the underlying security mechanisms.

TPM Applications

In my view, the most promising TPM application for embedded systems is measured boot. In this scenario, each software component in the boot chain calculates a cryptographic hash of the next component or its configuration and stores the result in special registers (platform configuration registers, PCRs) within the TPM’s memory. The following figure illustrates this.

These “measurements” in the TPM are representative of the system state. If any component in the boot chain had been tampered with, this would reflect in different PCR values. Those values can be used to derive cryptographic keys (e.g., to decrypt the rootfs), so that the decryption key is only available on a system that is not compromised. Important to note is that the TPM does not decide whether or not a hash is “valid”, it only acts a trusted memory location. If the hashes are actively validated by system software before continuation of the boot process, this is called trusted boot. The measurement values can also be sent to a remote party to convince it of the integrity of the system. This is known as remote attestation.

A TPM can also directly assist the main application by performing cryptographic operations, such as encrypting keys used for cloud communication. However, in the context of embedded systems, I don’t see great benefit in this approach. In many applications, there is no user present to enter a pin or passphrase, so the operating system must be able to communicate with the TPM in an unrestricted way. This implies that even in the case of a compromised operating system, a TPM will continue to decrypt or sign any data on behalf of the operating system, offering no security advantage in comparison to storing the keys within the OS. The fact that the attacker does not have access to the TPM’s key material directly is probably not relevant in most cases.

Implementation

TPMs are traditionally implemented as specialized microcontrollers, acting as a separate crypto coprocessor. They usually communicate with the main application processor over SPI or LPC. However, they can also be implemented completely in software. To maintain an acceptable level of security in these cases, this software runs in isolation from the untrusted operating system in a trusted execution environment.

For Arm-based systems, this is usually OP-TEE, which leverages the TrustZone hardware present in many application processors. With TrustZone, the CPU and some peripherals can exist in one of two states: Secure or Normal world. This hardware extension prevents access to Secure world resources when executing in the Normal world state, effectively creating two computing environments on the same physical hardware. The context switch between the two states is done through trusted firmware (Secure monitor).

OP-TEE includes a trusted OS, user space libraries and Linux kernel drivers. The fTPM runs on top of OP-TEE as a trusted application.

For my project, I worked with the TI AM625 SoC, which incorporates four Cortex-A53 processing cores, a Cortex-M4 coprocessor, integrated graphics, a security subsystem and lots of connectivity peripherals. For testing, I used a BeaglePlay board and a TI development kit.

Using Yocto, I built a custom Linux image which incorporates the OP-TEE stack and the fTPM software. I was struggling for quite a while to get the fTPM to work, but with some external help I was eventually able to make use of the fTPM from within Linux using the standard TPM user space utilities. From a (user) software perspective, there is no difference in using a discrete or firmware-based TPM, as Linux exposes an implementation-independent interface.

As for measured boot, there exist some examples that use this fTPM, although I have not experimented with this possibility myself.

Conclusion

During this project, I learned a lot about TPMs, OP-TEE and TrustZone as well as how (not) to debug and troubleshoot them, but also gained more experience in Linux debug facilities and Yocto intricacies.

Before using a TPM in a design, it’s important to be clear about the threat model of the specific application and how exactly a TPM can help to mitigate a specific threat. Considering some embedded systems lack the possibility of user input to, e.g., verify a pin, a TPM can not verify the legitimacy of a request in such systems. This means that even if the TPM’s private key is protected, the TPM will perform all cryptographic operations on behalf of the operating system, even if it is compromised. This compromise might be detected by a TPM-assisted trusted boot process, but considering some embedded systems might not be rebooted in years, this still poses a significant risk.

A TPM is not a cure-all for security problems, but they can definitely be beneficial for device security in some scenarios. In my opinion, TPMs can be most useful in embedded systems by adding support for a trusted boot process. Especially considering fTPMs, which do not contribute to added BOM costs, may be a suitable addition to next-generation IoT devices.