I think Trusted Platform Modules (TPMs) are a huge net positive to most computer users.

Maybe this is a hot take. This goes against the position of many computer security researchers and enthusiasts. For example, Microsoft’s TPM 2.0 requirement to run Windows 11 received a huge amount of community blowback. While I can certainly understand that it sucks to have perfectly good hardware made obsolete by the OS, I appreciate Microsoft’s effort to provide a baseline level of security for Windows. My peers in the computer security research group Secret Club also wrote extensively about their concerns.

Put simply, I agree with a lot of their points. But despite that, I still think TPMs are enormously valuable to users – their positives are overlooked and their downsides are exaggerated.

The disk encryption problem

I’m not going to rehash the benefits of full disk encryption, but I will say that I think everyone should use it. Whether you’re a grandma or an employee at a Fortune 500 company, disk encryption is important.

But disk encryption trades a security problem for a key management problem.

The user needs to be able to access their own files while at the same time denying unauthorized users.

The simple solution is to prompt the user for a passphrase every boot. Derive the encryption key from the passphrase (probably through a KEK).

This is pretty decent security, but it has poor usability.

Users do silly things with passwords. They reuse them, write them down on sticky notes and slap them on their laptop, or pick “123456”. They also have to be a certain length and complexity to be secure. An extra Bitlocker prompt contributes to password fatigue which leads to weak passphrases. While I don’t mind entering a secure passphrase every boot, I admit I’m in the minority. The reality is most users find passphrases to be an annoyance.

A 2019 Google / Harris Poll found that 52% of people reuse the same password for multiple accounts. If we relied on users to pick disk encryption passwords, over half of them would likely be using a password that is already compromised in a database somewhere. When not using a TPM, disk encryption is highly vulnerable to devastating offline brute force attacks. Depending on the key derivation function used, millions of password attempts per second is achievable to script kiddies using software like hashcat.

If you forget your passphrase (which users do, a lot) tough luck. Unless you have your recovery key backed up, which is sadly a big if, all your data is lost.

In a business environment, this becomes a massive headache. While you can back up recovery keys to Active Directory, key management is still a concern. Does every user pick their own passphrase? Guiding a user through Bitlocker recovery is a whole lot more hassle than a basic password reset. Do we have a company-wide passphrase? You lack any sort of segmentation if the key is compromised.

If you’re a computer enthusiast, you’re probably OK with passphrases and don’t see a need for anything else. Recognize that you’re in the minority. That’s not true for the vast majority of computer users.

TPMs are security for ordinary people

I contend that key management is the true core challenge in any cryptographic system.

Successful encrypted messaging software like Signal or even iMessage are successful because they abstract away key management. Users don’t want to think about managing keys – all they want to do is chat with their friend without eavesdroppers. Nobody would use Signal if they had to manually type in a 60-character encryption key to start a chat.

TPMs solve key management for disk encryption.

To a regular user, a TPM is magic. It’s completely invisible, requires practically no setup, and protects their data without hassle. Users want security and encryption, they don’t want key management. For the average user, data loss due to forgotten passwords is a statistically higher risk than data theft by hackers.

Apple has been encrypting disks by default using technology similar to a TPM on macOS and iPhone since 2014. Especially on the iPhone, unless you were particularly savvy, you probably had no idea your device was silently protected. They were able to pull this off over a decade before Microsoft due to their tight integration of hardware and software – they had complete control over the platform.

Windows, in comparison, was the wild west. Before Microsoft started cracking down on minimum platform security requirements, it was really a crap shoot what security features you got on a new device. Even if your CPU supported a firmware TPM (Intel PTT or AMD fTPM), your motherboard might not. For example, almost all first-generation AMD Ryzen AM4 motherboards had the fTPM option disabled or entirely missing from the UEFI settings which had to be patched years later.

TPMs allow security by default.

Now you can buy any computer with the Windows 11 badge on it and be sure that it meets baseline security requirements. It will protect your data at rest by default. Users shouldn’t have to go digging in motherboard manuals to know if their platform protects them.

Secure Boot vs measured boot, and why measured boot is awesome

I previously thought that the security of TPMs relied on Secure Boot. Since I’m somewhat of a Secure Boot skeptic, I thought TPMs suffered the same issues. I was wrong.

Secure Boot and TPMs are mostly unrelated technologies that can be configured to work together. TPMs can unlock your disks securely without relying on Secure Boot.

Secure Boot only cares that certain code in the boot process (firmware, drivers, and bootloaders) is signed by some trusted certificate authority. As long as it’s signed, Secure Boot will let it run.

TPMs provide measured boot, which is a cryptographic ledger of all code executed during the boot process. Each time a new piece of code is loaded, the TPM hashes it along with the previous hash value and stores it in a register. This process is conceptually similar to a blockchain.

These registers are called Platform Configuration Registers (PCRs) and each TPM has a few dozen of them. Many of them have defined purposes, measuring specific phases of the boot process. For example, the core UEFI firmware code is hashed into PCR #0, whereas the operating system bootloader is typically hashed into PCR #4. Importantly, the CPU has no direct control over the PCR values – it can read them, but it can only modify them by extending the hash. The CPU cannot set a PCR to an arbitrary value.

Now here’s the really cool part. You can configure a TPM to reveal a decryption key only if these PCRs are equal to a known-good value.

You can “lock” your disk encryption key to the current state of the PCRs, locking them to a known-good, untampered firmware, bootloader, and OS. Now if anything about the boot changes, say the bootloader is modified to steal your decryption key, the TPM will refuse to reveal the key.

In other words, the TPM acts like a bank vault that only opens if the security guard (the bootloader) looks exactly the same as he did yesterday. If malware changes the bootloader, the TPM sees a stranger and keeps the vault locked.

Measured boot is far more powerful than Secure Boot. It asserts, and proves cryptographically, what exact code was executed in the boot process. Secure Boot only tries to prevent unsigned code from running.

The downside with PCRs is that they break. If you update your motherboard’s firmware, or even update your operating system, the PCR values change. You can control this to some extent by limiting what PCRs you bind your key to. This is why TPMs are often used in conjunction with Secure Boot. The TPM extends the computer’s Secure Boot configuration into PCR #7 – whether it’s enabled, but also the list of trusted certificates. Binding to PCR #7 trades off some security for robustness against OS and firmware updates. This is the default configuration on Windows.

TPMs have security flaws

I don’t want to paint a picture that TPMs are invincible. They aren’t.

Because they have physical wires connecting them, discrete (hardware) TPMs have known vulnerabilities that are really hard to protect against. Over the past decade, security researchers have developed TPM interposers that sniff the communications between the CPU and TPM. This typically involves soldering wires and some specialized tools, but in total can be accomplished for just a few hundred bucks. The fundamental flaw is that the TPM must eventually give the decryption key to the CPU, so if you monitor the wires, you can intercept the key.

Now I would have thought that the key would be encrypted over the wire. Something akin to TLS, maybe. Apparently the people behind the TPM spec (the Trusted Computing Group) thought of this too, but Microsoft has historically neglected this. Years later, Windows 11 is now starting to enforce parameter encryption.

Linux is following suit too, but I’m actually not so sure it’s very effective. Chris Fenner has a fantastic blog post about how the Linux implementation is not all that effective for mitigation.

Adding a TPM PIN adds resistance to interposer attacks, but now we’re back to the passphrase problem. I have seen enterprise Bitlocker deployments where the TPM PIN was the same across the organization and printed on a label on every laptop.

I’m also not so sure that software TPMs built into the CPU are much better. Intel’s implementation runs inside their rather (in)famous Management Engine (CSME). Intel ME has never had any security issues… right? Due to the lengths Intel goes to protect the ME code, we don’t have a great understanding of how the TPM component works. But regardless, secrets stored on there are probably only a single CVE away from getting out.

Sadly, the situation with AMD’s fTPM is actually much worse. We know that their ME equivalent, Platform Security Processor, is based on Arm’s TrustZone. While originally less researched than Intel, we now know they are vulnerable too. In 2023, researchers executed the “faulTPM” attack, using ~$10 of hardware to glitch the AMD processor’s voltage and dump the secrets.

That being said, if I had to choose between a discrete TPM and a firmware TPM, my preference is to firmware TPMs. Discrete TPMs have known vulnerabilities against them that vendors just say “lol nope, not in our threat model” and ignore. Eliminating the physical bus is simply safer. Firmware TPMs are vulnerable to fault injection attacks, but these are more complicated than interposers – they require precise timing and are harder to execute reliably.

Going down one step further, the security of any TPM (discrete or firmware) depends on the security of the firmware itself. If an attacker gets control over the firmware, they can control exactly what is measured by the TPM. Sadly, even modern systems have pretty lax firmware security, especially on consumer motherboards. A lot of vendor code is riddled with memory safety issues and lacking even basic exploit mitigation – it’s pretty common to find RWX pages everywhere in firmware.

Firmware security suffers from fragmentation: there are dozens of motherboard vendors, and each firmware requires drivers from dozens more vendors. Intel and AMD recognize the massive hole and attack surface firmware represents, and developed extensive security features to defend the firmware from tampering. But ultimately, it’s up to the firmware vendor to implement these security features correctly (and they often don’t).

Dynamic Root of Trust for Measurement (DRTM) is an interesting technology from the TCG that basically acknowledges that firmware security is hopeless and allows the system to regain root-of-trust even if the firmware is compromised. Microsoft implements this technology in their System Guard technology. But unless you have a “secured-core” PC (common really only on enterprise laptops) your firmware is probably terribly insecure.

Security is relative, not absolute

You might think that it’s hard to rationalize TPMs when they have all these flaws.

One of my pet peeves is security absolutism – thinking that if something isn’t perfectly secure, it’s not worth using at all. Security is always a game of economics. We aren’t trying to make our data impossible to access; we are trying to make it too expensive to access.

Will a TPM stop the NSA from getting access to your encrypted files? Probably not. Heck, it might not even stop a skilled teenager with a Raspberry Pi. But you know what? It doesn’t matter. A thief who stole a laptop at Starbucks to turn on eBay is not installing a TPM interposer. A computer repair person is not installing a bootkit to launch an “evil maid” attack on you.

The threat model that most people are trying to defend against is not a nation-state actor. It’s stopping a laptop thief from getting their credit card number, or checking the box for regulatory compliance. And for 99% of users, TPMs cover their needs. It’s not perfect, but it solves real problems in a good enough way.

In many jurisdictions, if a laptop is lost but the drive is confirmed to be encrypted, it is not considered a ‘data breach’ that requires public disclosure. That little chip saves companies millions in legal headaches

And as technology progresses, CPU and OS vendors are making it harder and harder to launch attacks against the TPM. Intel and AMD take pretty extensive measures to protect the early boot process from tampering. Microsoft is deploying technology like System Guard to sidestep firmware problems. OS vendors are implementing mitigations for discrete TPM interposers. The gaps are closing very quickly, and the cost of attacking TPMs is growing exponentially.

TPMs are decentralized… for now

I have to talk about the elephant in the room: remote attestation. Remote attestation is ringing a lot of alarm bells for software freedom advocates, and is the root of a lot of controversy surrounding TPMs.

All TPMs have a unique root of trust called the endorsement key (EK). This key is signed by the TPM manufacturer and stored on the TPM in secure storage during manufacturing. The gist of remote attestation is that the TPM will sign special messages with its EK that attest to the current state of the TPM. A remote server or computer can check this signed message, and confirm that it was signed by an EK issued from a legitimate and trusted TPM manufacturer.

This technology can be leveraged to implement all sorts of unsavory “security” features, like Digital Rights Management. This could allow Netflix to remotely check if your computer was booted with an approved version of Microsoft Windows. Your bank could restrict online banking to only Windows computers that have “secured-core”.

This has free software advocates freaking out, and for good reason. Android uses TPM-like technology to implement remote attestation, and banking apps can and do block users running alternate operating systems (like LineageOS or GrapheneOS). Unless you’re running a “blessed” vendor OS, you’re locked out. Critics of TPMs highlight how this technology will come to PCs, crippling the Linux desktop.

Here’s my counterpoint: historically, there has been no central root-of-trust for TPMs. The endorsement keys are signed by the chip manufacturers (Infineon, Nuvoton, STM), not Microsoft.

This decentralization is a hurdle for global control. For a third party to verify every PC in the world, they would need to trust dozens of different vendors and handle the revocation lists for all of them. It is messy, and that messiness has arguably saved us from a total DRM lockdown on PC so far.

Decentralization in this case actually enhances security. If Infineon has a vulnerability (like the ROCA attack in 2017), only Infineon chips are affected. If Nuvoton’s root certificate authority keys are leaked, only Nuvoton’s TPMs are vulnerable. No centralized root of trust substantially limits the blast radius of a potential attack.

However, Microsoft Pluton changes this calculus.

Microsoft is inching towards their Pluton technology. This is a Microsoft-developed security co-processor located inside the CPU, representing a shift in TPM technology towards a single vendor (Microsoft). While this will no doubt bring security benefits, this is also a huge blow to software freedom. When the root of trust on PCs is centralized on Microsoft, they gain complete control over what can run on your PC.

To me, Pluton is a serious threat to computing. Not TPMs, whose standards and specifications are developed by relatively open working groups and implemented by many vendors. But Pluton is changing this, and widespread deployment is something that we should keep an eye on.