Modern software is layers upon layers upon layers. Most of us only really work in one or two of those layers but we rely on all of the others below us to keep working. Not only do we rely on their performance and functionality, we rely on them for security. If we’re developing a system or application, how can we trust that one of the many layers below us hasn’t been compromised? The world might be turtles all the way down but software does eventually end with hardware. If trust could be established at the lowest level of hardware, could that trust be extended, and verified all the way up?
Red Hat’s Emerging Technologies blog includes posts that discuss technologies that are under active development in upstream open source communities and at Red Hat. We believe in sharing early and often the things we’re working on, but we want to note that unless otherwise stated the technologies and how-tos shared here aren’t part of supported products, nor promised to be in the future.
This is actually the goal of a Trusted Platform Module (TPM), to establish a hardware root of trust that can be used to measure and extend that “trust” up the stack to user-level software.
What is a TPM?
The TPM specification is an operating system agnostic, international standard (from the Trusted Computing Group and International Standards Organization). The specification is designed to provide a secure hardware cryptoprocessor, a dedicated chip designed to secure hardware using cryptographic keys and operations. These chips provide several features, including (but not limited to):
- A hardware random number generator (RNG)
- Cryptographic hash functions
- Data encryption – symmetric and asymmetric
- Secure generation and storage of cryptographic keys
- “Sealing” of data: encryption that can only be unlocked if the TPM is in a specified state
Each TPM chip has a secret Endorsement Key (EK) that is burned into it during manufacturing. TPMs are designed so that this secret key is sealed inside the chip and can’t be obtained without destroying the chip itself. From this key are derived other keys used by the TPM including:
- Storage Root Key (SRK), which is based on the EK and an owner-specific password
- Attestation Key (AK) which can be used to hash critical measurements to prove they came from the TPM. An EK can prove the AK came from a particular TPM, but to protect privacy the design prevents tracing an AK back to its EK/TPM.
Another important part of a TPM is the Platform Configuration Register (PCR). Similar to registers on Central Processing Units (CPUs) these are slots that contain data that can be read. But unlike registers in a CPU they can’t be directly written.
When a TPM is powered up these PCRs are reset. And each operation that wants to add a value to these PCRs doesn’t set them, but rather “extends” them, which essentially means creating a new hash based on the current value plus the new value (new_hash = old_hash|measurement). This means the value in a PCR is not just a single measurement, but the result of every other measurement before it. Like the root node of a Merkle Tree, it relies on every previous value which is designed to prevent faking or tampering with it..
TPMs are becoming more common in just about every computing device from laptops, smartphones, servers, PCs, routers, edge devices, and even available for small devices like a RaspberryPi. They are even mandated in some organizations like the US Department of Defense for all new computer assets.
There are a lot of different types of TPMs, some considered more secure than others, but they all have their place and associated security trade offs. Going from what’s considered the most secure to the least we have: Discrete, integrated, firmware-based, hypervisor-based, and software-only TPMs. That last one might seem like an oxymoron, but even though a pure software TPM can’t give you a hardware root-of-trust, it can still provide features like Measured Boot and Remote Attestation. And they are very useful for development, testing and CI/CD pipelines.
Because the TPM specification is open, there are multiple open source software stacks for working with TPMs depending on your language and level of abstraction. Some great examples include the following:
Now that we have an introductory understanding of what a TPM is, let’s talk about what you can do with it.
Password Protection and Key Storage
Before TPMs, secure storage of passwords was very difficult. Those passwords could be encrypted but then the question is where do you put the key to unlock them? Some implementations tried to hide or split up the keys on the same disk to make it difficult to find, but that’s just a temporary solution until someone clever or dedicated enough figures it out.
Others tried to derive those keys from user-provided passwords, but that has the same problem as any other passwords – they are easier for a computer to crack than for a human to remember. TPMs provide a hardware limit on password attempts with enforced delays. This means another computer can’t keep running a dictionary attack trying to guess the passwords stored inside.
The secret keys themselves are protected with asymmetric encryption (public and private key pairs). The private key is kept in the TPM’s hardware and the public key and secrets are stored on the local hard disk. This means those secrets can be encrypted by anyone, but only decrypted by the TPM. Because of the use of the hard disk for secret storage, we aren’t limited by the small size of the TPM and could theoretically create lots of secrets with various levels of access and sensitivity.
Full disk encryption means that the underlying bits on your hard drive can’t be used without first decrypting the hard drive. If the disk is lost or stolen the data itself is protected, assuming the disk isn’t unlocked when stolen. If someone swipes an unlocked system off your desk while you’re still logged in, TPM won’t help you.
Decryption can’t happen without the key that unlocks it. But similar to the password problem above, where do you store that key? If an encryption key is short enough for people to remember, it won’t be long enough to provide any actual protection. So the key is stored in the TPM and can be unlocked with a user provided password, or in some cases, the key is encrypted and the passphrase unlocking it is in the TPM.
But you might ask, does this indirection mean you can still unlock a stolen disk if you can find the password? No, because with the key stored in the TPM you need that exact disk and that exact TPM chip together with the password. And since you can’t remove or tamper with the TPM without invalidating it, the stolen disk cannot be decrypted even if you guess the password.
Because a TPM is attached to the motherboard itself, it is available before and during the machine’s boot. This means it can be used to store measurements taken during the boot process which would not be possible using other hardware (like a smart card).
The term “measured boot” refers to the BIOS and bootloader taking measures of various things (like boot images and OS arguments) and recording those measurements in the TPM’s PCRs. There’s a full spec for how those things are measured and which PCRs the values are extended into, but that could be its own article. Suffice it to say that not only can you compare those PCR values to known good values (by booting a different computer with the exact same hardware and software images and recording those PCR values), but you can also use tools like `tpm2-tools` along with the boot log to reconstruct those PCRs values and validate them.
This gives you confidence that before your Operating System has even started that your system is exactly the way you want it. The first step in extending that hardware root-of-trust upwards.
It’s not uncommon to use an Intrusion Detection System (IDS) to remotely monitor a server to make sure an attacker doesn’t install anything malicious, compromise your existing software, or reconfigure it in a less secure manner.
But what if that attack compromises the software doing the monitoring? Or changes underlying libraries so that what appear to be simple system calls are actually hiding the attack from being discovered? If you’re monitoring your software with other software on top of it, you’re always subject to a sophisticated attack that reports itself healthy when it is not.
Remote Attestation is the concept of using your TPM to bring the hardware root-of-trust into your Operating System and User-level software in such a way that it can be verified either on the machine itself, or by a remote 3rd party.
The Linux kernel has a relatively new subsystem named the Integrity Measurement Architecture (IMA). IMA is very powerful and has many features, but the one we care about in this discussion is the ability to monitor files on your installation. If a file is accessed IMA will generate a hash fingerprint of that file and store it in the kernel’s measurement list (viewable at /sys/kernel/security/ima/ascii_runtime_measurements).
IMA can then be configured to extend a PCR (usually #10) with this new measurement. This seems relatively simple, but it has some nice tamper-resistant properties. First, the IMA PCR can’t be faked or changed (as mentioned above in the discussion about PCRs in general) and the PCR value can be reconstructed and verified by processing the measurements in the kernel’s measurement list.
This allows a remote system (such as Keylime) to independently and continuously verify the hashed value of any file accessed on your local system. It is designed so that you can’t tamper with the kernel’s measurement list without invalidating the PCR quote, and you can’t change the PCR quote without invalidating the measurement list. And if the remote system has access to the TPM’s AK, it can verify that the measurements came from that specific machine. And if you combine this with a list of every file path that’s allowed to be on your host and their corresponding hash fingerprints that you create (or one provided by your software vendor) you have a solution that goes above and beyond what an IDS is capable of.
What a TPM cannot do
In all this talk about how a TPM can help protect your system from malicious software it’s good to keep in mind what a TPM can’t do. It can’t control what software is running on the hardware. All it can do is measure and attest those measurements.
It’s up to the user, their organization and their policies to decide what to do with those measurements. If while booting, your computer fails your measured boot policy you could decide you want the machine to immediately stop booting so nothing further could be compromised.
Or you could decide to allow it to boot up but not connect to the network so forensic analysis can be performed. If a remote edge node fails attestation you can create a system that blocks it from reaching other devices on the network. But the TPM itself doesn’t do that. It’s just there to let you know what state the system is in. Your policies and how you implement them decide the rest.
I hope you’ve enjoyed this brief introduction to TPMs and the many opportunities they open up for creating more secure systems. Hopefully reading through these capabilities has given you an interest in exploring how TPMs can be used to enhance your personal and organizational security. But it’s important to remember that nothing is a silver bullet.
TPMs like everything else, have had vulnerabilities. New attacks could be discovered that remove some of their protections or a bug could be found in a particular vendor’s implementation of the TPM spec. And since software is complicated, they could be used incorrectly, thus invalidating some of their protections. But security happens in layers, and starting with the hardware and extending upward, we give ourselves a much better chance to keep malicious actors out.