Don't fear the TPM

There is a great deal of misunderstanding, and some misinformation, about the Trusted Platform Module (TPM); to combat this, Debian developer Jonathan McDowell would like to clear the air and help users understand what it is good for, as well as what it's not. At DebConf25 in Brest, France, he delivered a talk about TPMs that explained what they are, why people might be interested in using them, and how users might do so on a Debian system.

McDowell started with a disclaimer; he was giving the talk in his personal capacity, not on behalf of his employer. He wanted to talk about "something that is useful to Debian and folks within Debian", rather than the use of TPMs in a corporate environment.

McDowell has been a Debian developer for quite some time—more than 24 years, in fact. Professionally, he has done a lot of work with infrastructure; he has written networking software, high-end storage systems, and software-defined networking. He has also run an ISP. To him, TPMs are simply "another piece of infrastructure and how we secure things".

Unfortunately, there is a lot of FUD around TPMs, he said, especially now that Microsoft is pushing TPM devices as part of the baseline requirement for Windows 11. That has been part of the baseline since it was introduced, of course, but with the end-of-life approaching for Windows 10 people are starting to take more notice.

Many people are responding to TPMs by "throwing up their hands and going, 'this is terrible'"; but they are actually really useful devices. One of the reasons that they are useful is that they are so common. If you buy a new PC, "it is incredibly likely that you have some TPM capability on it". Unless it's an Apple system—they have Secure Enclave instead, "which does a whole bunch of different things that have some overlap".

What is a TPM?

So, he asked rhetorically, "what is a TPM?" He displayed a slide with Wikipedia's definition of a TPM, which says that a TPM is "is a secure cryptoprocessor that implements the ISO/IEC 11889 standard". McDowell said he did not recognize that definition, despite having worked with TPMs for several years. He repeated the definition and said, "that doesn't mean much to me, and it's also not entirely true", because there are multiple TPM implementations that are not secure cryptoprocessors.

There are three variants of TPM that McDowell said he was familiar with: discrete, integral, and firmware. A discrete TPM is a separate chip that lives on the motherboard. Historically, the discrete TPM has been connected over the low pin count (LPC) bus, but modern systems mostly use the serial peripheral interface (SPI) bus. Then there is the integral TPM, which sits on the same die as the CPU, but as a separate processor. Examples of integral TPM include Intel's Management Engine and AMD's Secure Technology (formerly called "Platform Security Processor"). These are logically separate from the CPU that applications run on, which gives some extra security, "but not a full discrete chip".

Finally, there are firmware TPMs, such as the Arm TrustZone technology. In that case, McDowell said, the TPM is actually running on the application processor in a more secure context, but firmware TPMs can be vulnerable to speculative side-channel attacks. The idea is that the TPM is a small, specialized device that "concentrates on cryptographic operations and is in some way more secure than doing it on your main processor".

McDowell digressed a bit to talk about TPM 1.2 devices. "I hate TPM 1.2 devices. I still have to deal with a bunch of them in life. They are ancient." TPM 2.0, which is the baseline that Windows 11 expects, launched in 2014. He would like TPM 1.2 devices to all go away and said that he would not be discussing them further.

Not for DRM

One of the things that TPMs can do is state attestation. The idea is that the TPM can attest to the software that is running on the machine:

And if all of the stars align and you get everything right, you can actually build a full chain from the first piece of code, the firmware that the CPU runs, all the way up to the application layer and say, I am running this stack of software and I will provide you a signed cryptographic proof.

However, he assured the audience, TPMs are not a realistic way of doing digital rights management (DRM), McDowell said—no matter how much Microsoft or Netflix might want to use them in that way. "They could not build a database of all these values for all the legitimate machines in the world." Trying to do so would result in "support calls coming out of their ears". It is absolutely possible to constrain things so that the TPM can provide a level of security for embedded systems and appliances, he said. "In particular, you can potentially use it for some level of knowing that someone hasn't tampered with your firmware image". But full DRM on general-purpose PCs is not going to happen.

A standard TPM for a PC has 24 platform-configuration registers (PCRs), McDowell said. PCR 0 through PCR 7 belong to the firmware and are used by UEFI to measure the bootloader and "base bits" of what the operating system runs. PCR 8 through PCR 15 are "under the control of the bootloader and the OS", and PCR 16 through PCR 23 are "something different, and we'll not talk about those at all".

PCRs are SHA hash registers; at boot time the TPM sets the values for the registers to zero. Then the hash values for various objects are measured into the registers; For example when GRUB boots, it logs its activity into the TPM event log, and performs a cryptographic hash operation to extend the value of the PCR, explained in more detail in this coverage of a talk by Matthew Garrett. McDowell displayed a slide that showed a command to read the TPM's event log:

    # tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

Each entry in the log shows something that has been measured into the registers. Details about Secure Boot, for example, are put into PCR 7, which provides an attestation that "this machine has used Secure Boot, and these are the keys it has used to do Secure Boot". All of that is machine-state attestation, he said, "which is the thing that people get worried about" being used to enforce DRM.

Key storage

The much more interesting thing from a Debian point of view, he said, is key storage. While TPMs are small and incredibly slow devices, it is possible to securely generate asymmetric keys, such as SSH keys or signing keys, on the device that cannot be exfiltrated:

You can say "make me a key", and it will make you a key, and that private part of the key can only be exported from the device in a way that only the device itself can read.

Obviously an attacker could use the TPM while they are connected to the machine. But if the user kicks them out or fixes whatever has happened, the attacker would not be able to export any keys stored in the TPM to another machine. That, McDowell said, is incredibly useful. He reiterated that TPMs are slow; they are not full-blown high-performance hardware security module devices. But they are almost everywhere, "and that's why they're interesting, right?" They are a standard piece of hardware that most PCs will have if they're not too old.

If one wants to get more into the corporate side of things, he said, some hardware vendors will provide a certificate that ties the TPM's unique endorsement key to the serial number of the laptop. "So I can do a very strong statement of 'this is the machine I think it should be'." But that, he reiterated, involves a slightly complicated procedure. For single-machine use cases, "you don't have to worry about this bit too much".

This also allows the TPM to do attestation for the key. That is more complicated, McDowell said, but "you can do an attestation where the TPM goes, 'that key was definitely generated in me'". That might be desirable, for example, in terms of a certificate authority or when signing packages. If a key is hardware backed, its use demonstrates that a user has access to a specific piece of hardware—such as a company-issued laptop.

He elaborated later that using it for attestation involved an "annoyingly interactive challenge and response dance"; it was not possible to have the TPM simply generate an attestation statement that can be validated and trusted. However, if one does the full attestation dance, "I can guarantee [the key is] hardware-backed and I can guarantee it's hardware-backed by a particular vendor of TPM".

Another neat thing that users can do is to bind a key that can only be used if the PCRs are in a particular state. That means it's possible to ensure that someone hasn't messed with the firmware, to guard against an "evil maid" attack. If the machine is still running the image that the user expected to be running, then they could use their key. "If someone has subverted that with a dodgy firmware or a dodgy kernel, then I will not be able to use my key".

TPMs can also generate random numbers, he said, though that is not necessarily particularly interesting. The TPM needs random numbers for many of its operations, and it exposes that interface "so you can ask the TPM for random numbers". There are faster sources of random numbers, such as the CPU's instruction set and USB-attached random-number generators, but TPMs are still useful largely because they are present in a lot of machines.

Crypto types

McDowell had said he was not going to talk about TPM 1.2 devices, but he mentioned them again to say they did not do cryptography right. The 1.2 specification only allowed for the use of 1024-bit RSA keys, and the SHA1 algorithm. The 2.0 specification added "this thing called crypto agility", and extended the baseline support to 2048-bit RSA keys, SHA256, and NIST P-256 elliptic-curve cryptography.

Post-quantum cryptography is not there yet but it is being actively worked on upstream. Because of the crypto-agility standard, none of the interfaces used to talk to the TPM will change much—it will just be a different key type. All of the TPM vendors are ready, McDowell said; it is just a matter of waiting for the details to settle. "This will come before we need it, which is good".

Using the TPM

Next, he demonstrated how to check to see if the random-number generator was enabled, but did not go into detail on how to use the feature. McDowell cautioned that AMD's integral TPM has some problems with the random-number generator, possibly to do with locking and conflicts over accessing the device over the SPI bus.

The TPM can also be used to produce trust paths in software using the kernel's integrity-measurement architecture (IMA). For example, if a developer was building an appliance, it would be possible to use the kernel's IMA to create a list of the privileged code, with its hashes. To test this out without messing with the system TPM he recommended the swtpm package, which provides a TPM emulator.

What's more interesting about swtpm, McDowell said, is that it can be used in conjunction with QEMU to provide a TPM to a virtual machine. "I suspect a bunch of people are doing this to boot Windows 11" in virtual machines. It is a fully-featured TPM 2.0 implementation, and it was what he had used for the examples in his presentation. He also recommended the tpm2-tools package, which he called a kind of Swiss Army knife for working with TPMs. He put up a slide showing the tpm2_pcrread command being used to read PCRs 0-7 from the TPM:

    $ tpm2_pcrread sha256:0,1,2,3,4,5,6,7

The version of GNU Privacy Guard (GnuPG) in Debian 13 (trixie) includes a feature that allows users to generate a key and store it in the TPM. "That means you've got a hardware-backed key, no need for the Yubikey plugged into your machine". Even if an attacker has access to the machine they cannot copy the key from it. "That, to me, is amazing." That feature is not available in the GnuPG version in Debian 12 ("bookworm").

I asked how users could back up their key if the machine with the TPM died and was unusable. He said there were two options: generate the key in the CPU and store it in the TPM, with an offline backup on a USB key, or use a GPG subkey. "Then you have the ability to put another subkey on your laptop because the primary key is not the one stored in the TPM." His approach was to use an offline primary key, stored in a hardware token, and then to use subkeys extensively for different machines.

McDowell also showed examples of using the TPM to store a PKCS#11 token for use with SSH, which he said was "a bit annoying" because the process was convoluted. There was another method, using an SSH agent for TPM written in Go, which he described as "cheating" because it was not yet packaged for Debian. He lamented the fact that he was speaking at the same time as the Go team BoF, so he was unable to get help figuring out Debian's Go ecosystem.

Every now and again he thinks about "jumping through all those hoops" to be able to sign his own operating system images to use with Secure Boot. If he did that he could use the OpenSSL TPM 2.0 provider as a certificate authority with a secure backend stored in the TPM. But, he reminded the audience, TPMs are slow. "If you can get 10 signing operations a second out of your TPM, you're doing exceptionally well." It would never be possible to back a TLS web server with a TPM. It was much better for one-offs, such as certificate-authority operations, where a system is not being used to issue a lot of certificates.

A really interesting use of the TPM, McDowell said, was to automatically unlock a LUKS-encrypted drive. A user could set things up to automatically unlock the drive if the firmware, bootloader, and so forth are unchanged and avoid having to enter a passphrase just to decrypt the disk. He noted that users would still need to have a recovery password for LUKS, because if anything were to change about the machine—including rebuilding the initrd—then a user would have to have a passphrase to decrypt the disk. He showed a slide with an example using systemd-cryptsetup and dracut to enable this feature and said, "this is my first time playing with dracut; I didn't like it." He also noted he could not fit the entire example on the slide, but he included a link to a blog post about using TPM for disk decryption.

An audience member asked how much of a pain it would be to "magically incorporate" the proper values when the kernel is updated so that the next time the system is booted it expects the new kernel. McDowell said that systemd does have tooling that will "attempt to do the calculations for what the PCR values will end up as"; he had not looked at that tooling extensively, however. There was still more pain than there should be in automating this, which is "one of the reasons that the systemd folks are pushing unified-kernel images" (UKIs). That would allow distributions to provide the initrd as part of the whole package and provide the PCR value along with it. In the current model, where everyone builds their own initrd, "we have no way of distributing those values as a project".

In general, he said, the systemd folks have been really good about trying to drive the use of TPMs forward. LWN covered some of this work in December. McDowell also gave a call out to James Bottomley for doing a lot of work on the kernel side of things "in terms of just generally improving the infrastructure" around TPMs.

One audience member wanted to know if he had seen any work that would allow programs like Firefox to have passkeys in the TPM. He was not aware of any implementations of passkeys in the TPM; the problem with the passkey approach and TPMs, he said, is that a passkey "normally wants some proof of user presence", such as a button press on a Yubikey. There is no equivalent of user presence with a TPM that couldn't be faked programmatically.

The slides for McDowell's talk are online now, and videos from DebConf25 should be published soon.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Brest for DebConf25.]