faulTPM: Exposing AMD fTPMs' Deepest Secrets

[0x_rs]

>Our attacks have shown that an fTPM cannot sufficiently protect its internal state against firmware or physical attacks. In such a scenario, a passphrase-only key protector of reasonable length provides better security than a TPM-only protector with a numeric PIN (5.3.1). This is in stark contrast to Microsoft’s claim that “BitLocker provides the most protection when used with a Trusted Platform Module” [29] (see also in 2.3). In fact, of all available protectors (seen in Figure 1), TPM-only is arguably the weakest protection strategy.

This might not be surprising to some, despite Windows hiding the GUI passphrase functionality behind some group policy settings, both "Require additional authentication at startup" and "Enhanced PIN", which isn't perhaps the most intuitive and a normal user might not even realize unless they notice the "normal" PIN is numerical-only. In any case, for the average person that might have their devices stolen, this is likely not to be a threat, but I think a passphrase should always be preferable, BitLocker doesn't support any better option.

[patrakov]

The most important sentences of the article:

"Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks [14] to extract a chip-unique secret from the targeted CPU."

"The attack requires access to the motherboard of the target system (4.1), particularly its SPI bus and voltage regulators."

In other words, it is required to open the laptop and connect custom (but cheap) hardware to the motherboard to disrupt its normal operation.

[moring]

Amateur-me thinks that it would not be too hard to prevent such an attack: Have a voltage fault detection circuit at all (TPM-relevant) supply pins that hard-locks the chip until it gets power cycled, and have those circuits be powered by on-chip capacitors that survive just a little longer than their time-to-trigger. Would that be feasible?

[Arrath]

> voltage fault injection attacks

What's old is new again!

[cryptonector]

Note that the SPI bus sniffing attacks on dTPMs are simpler to mount (being passive) but also require direct access to the bus (motherboard), and unlike this attack can be prevented in software by knowing the public key of a primary key object on the TPM (e.g., the endorsement key) and using it to authenticate the TPM to the host.

That said, even a host using a dTPM with proper authentication of the dTPM has a problem if the SP is vulnerable to voltage fault injection attacks, because even though SPI bus sniffing wouldn't yield the unlocked FDE keys, the attacker presumably could get full control of the CPU and recover the unlocked FDE keys there.

In other words, the problem here is the voltage fault injection vulnerabilities in general. The fTPM part of it is not as big a deal as the total compromise of the whole system due to those voltage fault injection vulnerabilities.

[jhoelzel]

Honestly TPM is probably creating more bad than good at this point.

Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.

[neilv]

Debian Stable welcomes refugees:

https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/

(Or, for laptops with closed WiFi and no Ethernet, use this installer: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in... )

[sidewndr46]

It's called the TPM because it is trusted. The real question is, who is it that trusted that thing?

[cryptonector]

> Honestly TPM is probably creating more bad than good at this point.

The problem isn't the TPM. The problem is the CPU (SP) being vulnerable to voltage fault injection attacks. You could be using no TPM and still have all your secrets leak if the host is fully compromised.

[judge2020]

> Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.

What is this a reference to? Every computer I've found will let you boot into the bios and disable secure boot or add new keys to the trust store.

[IYasha]

Good? It was never intended to do so. )

Also, made me remember (once again) decade old presentation on TPM: https://www.youtube.com/watch?v=XgFbqSYdNK4

[candiddevmike]

There needs to be a way to measure and report on boot order. Hopefully there will be other options besides a TPM for this.

[Cheeeetah]

TPM allows government to request your data in the first place. So it should not be trusted by individuals from the beginning.

[taraharris]

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporations?

Whose computer is this, anyway?

[dathinab]

Mine and I want a TPM, it's a device essential for modern laptop security.

_Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_

through potential a different implementation and not some of the features build on top of it

like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the EFI itself) would probably be a convenient, simple, way to have the necessary security without many of the problems ... or did I just reinvent TPM ?

[jeroenhd]

Mine, and I like it to stay that way. A TPM can be a valuable tool for protecting my data, making it difficult if not impossible for anyone to decrypt my drives. TPM+PIN is hard to beat.

[flangola7]

Without a TPM servers can't verify that their genuine app is being used. https://developer.apple.com/documentation/devicecheck/valida...

[cryptonector]

This isn't a TPM spec vulnerability. This is a CPU (SP) vulnerability, and it's devastating regardless of whether you use a TPM or not.

TFA is fine, but thinking that this is specifically a vulnerability because of TPM is a serious mistake. Not using a TPM won't make you safer.

[rasz]

Obviously computer belongs to Microsoft. They are the ones paying for AMD SOC development and millions of units per year under multi year contracts.

[aceazzameen]

It says any TPM can be defeated in 2-3 hrs with physical access. Is the AMD one different? Can it be defeated over networks? And is this something I should be concerned about since I just bought a new AMD machine?

[cwerling]

One of the authors here. This attack is relevant if your machine is physically exposed to attacks, e.g., in an office environment or while traveling, and if you don't use any additional pre-boot passphrase to protect the disk (but rely solely on AMD's fTPM).

When TPMs became popular, dedicated TPMs were mainly used, being a separate chip on the mainboard connected via the SPI or LPC bus. These were prone to (relatively primitive) bus sniffing attacks, where you would hook up a Logic Analyzer to the bus, watch a regular boot procedure grab the disk key, and then use software like Dislocker to extract all data from a USB Live Linux or alike.

Nowadays, most modern CPUs (both on Intel and AMD) ship firmware TPMs that are "included" with CPU die, making them safe against the bus sniffing attacks. However, they can still be prone to more sophisticated attacks like ours.

[smarx007]

Yes, relevant in case of a lost device:

"Motivated by Windows 11’s push to use the TPM for even more applications, we apply the vulnerability to Microsoft BitLocker and show the first fTPM-based attack against the popular Full Disk Encryption solution. BitLocker’s default TPM-only strategy manages – without any changes to the user experience – to swiftly step up a user’s security in the face of a lost or stolen device. However, as our work complements the established at- tacks against dTPMs with an even more potent attack against AMD fTPMs, a TPM-only configuration lulls a non-technical user with high protection needs into a false sense of security."

"Users who fear a physical attacker with reasonable resources should opt for a TPM and PIN configuration. When BitLocker identifies that the underlying TPM is an fTPM, users should be urged to turn their PIN into a passphrase."

[goolz]

I am wondering the same, considering the proliferation of AMD in the last few years I would be devastated to have to go back to Intel. Just when the Framework came out with their AMD versions too.

[daneel_w]

Access/privileges to execute on the host is required. I, personally, would not feel concerned unless I was a TPM user and knew I was a specific target.

[gen3]

"security properties of the TPM - like Bitlocker's TPM- only protector - can be defeated by an attacker with 2-3 hours of physical access to the target device"

So I take this is more of a data exfiltration type of attack?

Edit: here is the POC https://github.com/PSPReverse/ftpm_attack

[cryptonector]

I've not yet read past the abstract, though I've read (and responded to) a lot of the commentary here.

QUESTION FOR THE AUTHORS: Is there any way in which a voltage fault injection vulnerability in the SP can affect only the fTPM and not actually be a full host compromise but for the fTPM compromise?

I believe the answer to that has to be no. If you can compromise the SP you can compromise the whole system. Therefore this isn't really about fTPM. But you'll notice that many commenters are running away with this and saying that TPMs make systems less secure, which is not really correct.

Yes, TPMs are not used correctly by most BMC/BIOS implementations, or even by OSes, and there are vulnerabilities that arise from that misuse. But TPM 2.0 does provide what is needed to solve those issues.

The wholesale attacks on TPM 2.0 itself here are not warranted, especially if the SP vulnerabilities are more general rather than being specifically limited to fTPMs.

[nyanpasu64]

Relying on an TPM to rate-limit an attacker's ability to brute-force a comically short PIN and get the encryption key (Microsoft's promoted way to login to a Windows device), is less secure (once the TPM is exploited) than relying on the attacker to guess a high-entropy password to get the encryption key.

[1827163]

Yet one more reason the Platform Security Processor is a nightmare and should be removed completely from future processors.

[anthk]

And IntelME.

[dist-epoch]

Password-less TPMs will always be fundamentally vulnerable. The only question is what is the price to break them. It can be very high (as seen in the Xbox).

[FeistySkink]

Does this affect OPAL 2.0 in any way? I tried to search through the spec [1] but didn't find immediate clues.

[1]: https://trustedcomputinggroup.org/wp-content/uploads/TCG_Sto...

[cwerling]

Thanks for the pointer, we haven't checked out OPAL yet. It seems to be the most popular standard when it comes to "Self Encrypting Drives" (SED).

Looking into it shortly, I've found a paper from 2019 from Meijer et al. ([1]) finding several flaws with OPAL-compliant drives. They further find that BitLocker entirely depends on SSD-based encryption if the hardware advertises it. This finding's nature is very similar to ours in that BitLocker's Disk Encryption is insecure/unreliable in particular hardware configurations.

[1] https://ieeexplore.ieee.org/document/8835339

[riedel]

Stupid question: was there no responsible disclosure and is there no cve assigned? Seems like a rather practical attack (or am I missing something?

Do the researchers consider it a known fact that that fTPM is broken by design and thus do think that nobody will get hurt? It would make sense to require an additional passphrase on fTPM devices for bitlocker. Was there a statement from Microsoft or AMD?

[hnj2]

From the paper: "All security-relevant findings discussed in this paper were responsibly disclosed to AMD, Microsoft, and the systemd-cryptenroll maintainers. The systemd-cryptenroll maintainers quickly got back to us to discuss specific mitigation strategies."

[goolz]

To anyone with a bit more breadth on this topic: is this as terrible as it sounds or more just in the realm of academia and nation-states?

[creshal]

TPM based disk encryption is mostly useful as theft protection, so that companies, education facilities or government agencies can provision 100,000 devices without having to match smartcards/fobs/disk passwords to devices and users. (Which often leads to terrible security practices, like backup passwords shared between devices etc.)

So cracking it in 3 hours by amateurs is pretty bad, because now even not too sophisticated thieves can start looking for crypto wallets or sensitive data to ransom.

[dist-epoch]

> Bitlocker's TPM- only protector - can be defeated by an attacker with 2-3 hours of physical access to the target device

That sounds pretty practical.

[spacebanana7]

Not an expert, but I think the biggest exposure most consumers might face is lost/stolen devices where it's conceivable an adversary could have physical access.

[cryptonector]

They have a voltage fault injection attack on the SP. That's game over, never mind the fTPM.

[drakythe]

Mostly academia and nation states. Physical access will always be king and this provides one more avenue for adversaries to bypass encryption more easily.

[asldkfjaslkdj]

Question, this is a widely used tpm since it's 'free', so it makes sense it was the first one looked into, but

anyone did similar tests to the el-cheapo ones that will end up on 99% of computers around the world?

My bet is that messing with voltages on those chips too will expose all sorts of exploits too.

[als0]

It's worth mentioning that standalone TPM chips from Infineon and others are a lot more hardened than Intel or AMD's fTPMs. Infineon's TPMs are tested against fault injection attack, package removal, side channels and so on.

[charcircuit]

This works up to Zen 3. This is going to set the PC consumer space's security back even further than it already is compared to mobile.

[dschuetz]

Wait isn't that the fancy MS Pluton thing AMD decided to add to their processors to make the systems more "secure"?

[jeroenhd]

Gnarly, especially because these vulnerabilities seem unpatchable. Luckily, it seems TPM+PIN should remain safe if your PIN is difficult enough to brute-force, though.

As this includes an attack against the secure processor, does this also pose risks to any DRM keys?

[anthk]

And now I remember people telling me Windows is more secure than Unix because of TPM, foo... bar...

No, thanks, bioctl(4) works well under OpenBSD for disk encryption and so will do under HyperbolaBSD.

[sampa]

shows that people shouldn't trust closed HW crypto (HW SSD passwords - same)

trust only open-source software crypto

[snvzz]

Unsurprisingly, a key is better protected with a good passphrase than a TPM, if you have to pick one.