TPM (Trusted Platform Module) is an international standard that enables trust in computing platforms in general, providing several security-related features for computer systems, including hashing, encryption, signing, random number generation, and many more!
It was created by a computer industry consortium called TCG (Trusted Computing Group) and standardized in 2009 by the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC), becoming ISO/IEC 11889:2009.
In 2011, the TPM main specification version 1.2 was released. TPM 1.2 only supports SHA-1 for hash calculation, and since SHA-1 has been proven to be weak and deprecated by NIST (National Institute of Standards and Technology) to be used in crypto operations since 2014, this makes TPM 1.2 devices sort of useless from the security perspective!
In 2014, the Trusted Computing Group announced a major upgrade to their specification entitled TPM library specification 2.0, which is still evolving (as of this writing, the latest version was released in 2019).
The TPM library specification 2.0 became ISO/IEC 11889:2015 and has many more features compared to TPM 1.2, including new cryptographic algorithms and hash functions, support for larger keys and more flexibility to manage its internal registers and secure storage.
This article is focused on TPM 2.0 specification, which can be downloaded from the TCG website.
And since TPM is just a specification, there may be different implementations, ranging from software-based to dedicated chips.
But before we talk about the TPM implementations, let’s learn about its main features and common use cases.
TPM features
A TPM provides an infrastructure for executing security-related functions, including secure storage and cryptographic operations, as defined in the specification:
Among the main features of the TPM 2.0 specification, we have:
- Hash calculation (SHA-1, SHA-256).
- Random number generation.
- Cryptographic key generation.
- Secure storage of cryptographic keys and message digests.
- Symmetric encryption and decryption (AES).
- Asymmetric encryption and decryption (RSA, ECC).
- Signature checking (HMAC, SMAC).
One question we might raise is: why do we need a TPM for that? Can’t we just have some software (e.g. OpenSSL) executing these cryptographic operations? Yes, we can! However, doing everything in software is not secure because secrets might be exposed in disk and memory during its execution.
A TPM provides secure storage and executes crypto operations securely inside of it, without exposing secrets (e.g. keys) in memory, disk or communication busses (how secure this really is, depends on the TPM implementation).
TPMs are also tamper-resistant, which makes it harder for someone to access the data it stores or the cryptographic keys it generates (again, how secure this is might depend on the implementation).
Are TPMs crypto accelerator devices? No, they are not! Although running cryptographic operations in a TPM might be faster than running in a very small microcontroller, most of the time, TPMs will be much slower. The purpose of a TPM is not to be fast, but to be secure!
It is also important to mention that, on top of these conventional cryptographic operations, a TPM implementation offers a few additional and interesting features:
- PCRs (Platform Configuration Registers): special and protected registers normally used to store measurements of the operating system like hashes of various system software and firmware components.
- Wrapping or binding: the ability to encrypt data using a key stored within the TPM itself. This is used for example to encrypt keys stored in unprotected storage devices (e.g. hard disk or flash memory), so that they can only be decrypted by the TPM itself.
- Sealing: the ability to associate some encrypted data to a measurement stored in a PCR register, so the data can only be decrypted (unsealed) if the current PCR content matches the specified value.
- Endorsement Key (EK): a unique key created when the TPM is manufactured that might have different purposes including device attestation, identity verification, and platform integrity verification.
- Session-based encryption: the ability to encrypt sensitive data when communicating with the TPM.
And how all these features are used in practice?
TPM use cases
First of all, a TPM can be used for generic cryptographic operations like encryption, decryption, signing, hashing, etc. Since these cryptographic operations are executed inside the TPM, without exposing secrets, it is already a good motivation to use it.
A very commonly referenced use case for a TPM is ensuring boot integrity (also called measured boot or trusted boot).
In a system that supports measured boot, the PCR registers from the TPM are used to store measurements (i.e. hashes) of each component of the operating system (firmware, bootloader, kernel, etc). These measurements might be used later to determine the integrity of the operating system and its configuration.
A TPM can also be used for remote attestation, a process used to verify and assess the trustworthiness of a remote computing device or platform. It allows a trusted entity (the verifier) to remotely confirm the integrity of the software, firmware, and hardware components running on a target device (the prover) without relying solely on the claims made by the prover.
Since we have the operating system measurements (hashes) in the PCR registers, the TPM can sign and send a message to a remote machine to certify and validate these measurements. There is even a protocol called Trusted Attestation Protocol Information Model, published by the Trusted Computing Group, that can be used to implement such functionality.
The TPM is also commonly associated with some implementations of full disk encryption.
For small data, TPMs can directly do the encryption and decryption. For large data, TPMs can be used to encrypt and decrypt a symmetric key that can be used for encryption. In the TPM specification, the process of encrypting keys is also called wrapping or binding a key.
Wrapping a key can be extended by sealing. In this case, a wrapped (encrypted) key is tied to certain platform measurements (in the TPM specification, this is called sealing). And the sealed key can only be unwrapped (decrypted) when those platform measurements have the same values that they had when the key was created.
This is a very interesting feature that might be leveraged by full disk encryption utilities such as dm-crypt (Linux) and BitLocker (Windows), where the key used to decrypt the disk is unsealed (released and decrypted) by the TPM only if we have the correct measurements in the PCR registers (i.e. it ensures operating system integrity before releasing the key).
Other TPM use cases might include device identification, protection and enforcement of software licenses, digital rights management (DRM), and even prevention of cheating in online games!
Let’s talk now about how a TPM is implemented…
How a TPM is implemented?
The TPM specification can be implemented in software (leveraging existing hardware features) or in hardware (via dedicated chips).
The TPM specification can be emulated in software. This kind of implementation runs with no more protection than what a regular program gets from the operating system. They depend entirely on the environment that they run in, so they provide no more security than what can be provided by the normal execution environment.
A software-based implementation might be useful only for development purposes. See for example the SWTPM project, a software TPM emulator with socket, character device, and Linux CUSE interface.
A more reasonable software-based approach is to have the TPM code running while the processor is in a special execution mode (e.g. TrustZone on ARM). This is usually called a firmware TPM.
With this approach, a Trusted Execution Environment (TEE) could implement the TPM specification in a trusted application and provide access to TPM features for untrusted applications. This is not as secure as having a dedicated chip implementing the TPM functionality but provides reasonable security without the need for external hardware.
The official TCG reference implementation of the TPM 2.0 specification has been developed by Microsoft and the source code is available on GitHub. This reference implementation can be used as a firmware TPM solution, and it is already integrated into some TEE implementations, including OP-TEE.
But nothing replaces a hardware implementation!
The most secure implementations of TPMs are done in hardware. Also called discrete TPMs, they are dedicated chips that implement the TPM functionality in their own tamper-resistant semiconductor package, attached to the system via a communication bus like I2C or SPI.
A discrete TPM has a processor, RAM, and flash memory, providing a bus and a communication protocol to interface with the host system. The only interaction with a discrete TPM is through the communication bus. Some examples are ST33TPHF20SPI from STMicroelectronics and ATTPM20P from Microchip.
In addition to TPMs, you might also have heard of secure elements and smart cards. What is the difference between them?
Secure Elements vs Smart cards vs TPMs
A Secure Element is a secure computing system. It is basically a secure storage with its own secure applications. What a secure element does is very open and depends on the implementation, but most of them implement PKCS#11 (Public-Key Cryptography Standard 11).
Examples of secure elements are Hardware Security Modules (HSM), SIM cards, and … smart cards!
So smart cards are one example of secure elements. They are physical electronic authentication devices, usually used to control access to some resource and typically in the size of a credit card with an embedded integrated circuit chip.
Now remember, a TPM is just a specification and an international standard. A TPM is not a Secure Element, although it could be implemented inside one.
In summary, while a secure element has a broader scope and its functionalities are implementation-defined, a TPM has a limited and defined scope.
This is an advantage of using TPMs. Because TPMs provide a standardized set of functionalities, it is easier to do software integration. And this is one of the reasons TPMs are a popular solution to improve the security of a computing system.
But wait, are TPMs really secure?
Attacks on TPM devices
Nothing is 100% secure. Given enough time and resources, everything can be exploited!
So if you are wondering whether a TPM has been already hacked or not, just go to your favorite search engine and look for “Attacks on TPM devices”. Really, go, I will wait… :-)
Yeah, TPMs have been already hacked, a lot!
In 2010, Christopher Tarnovsky presented an attack against TPMs at Black Hat Briefings. By spying on the communication bus of a TPM device manufactured by Infineon, he was able to extract secrets from the chip! Unfortunately, this talk is not available. But a newer one called “Attacking TPM Part 2 - A Look at the ST19WP18 TPM Device” was recorded and can be watched on YouTube.
In 2018, a design flaw in the TPM 2.0 specification was reported (CVE-2018-6622), allowing an attacker to reset and forge the content of PCR registers.
In 2021, the security consultancy Dolos Group hacked a Lenovo computer, getting access to the disk encryption key by sniffing the SPI bus used to communicate with the TPM (see this Ars Technica article for the details).
There are also several examples of hardware-based attacks, most of them based on side-channel attacks.
For example, there is the TPM—Fail, where the researchers were able to extract keys via a timing attack: “We discovered timing leakage on Intel firmware-based TPM (fTPM) as well as in STMicroelectronics’ TPM chip. Both exhibit secret-dependent execution times during cryptographic signature generation. While the key should remain safely inside the TPM hardware, we show how this information allows an attacker to recover 256-bit private keys from digital signature schemes based on elliptic curves.”.
The paper is an interesting reading!
In the next article of this series, we will learn how to integrate and manipulate a TPM device on an embedded Linux system.
About the author: Sergio Prado has been working with embedded systems for more than 25 years. If you want to know more about his work, please visit the About Me page or Embedded Labworks website.
Please email your comments or questions to hello at sergioprado.blog, or sign up the newsletter to receive updates.