Skip to content
The methodOpen data
Back to the collection

faulTPM: Exposing AMD fTPMs' Deepest Secrets

Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert

2023 · arXiv

Security & cryptographyComputer systemsAlgorithms
Read the paper
HN score
0
Mentions
11
Readers
4
Months
5
What’s in a score?

From the abstract

Trusted Platform Modules constitute an integral building block of modern security features. Moreover, as Windows 11 made a TPM 2.0 mandatory, they are subject to an ever-increasing academic challenge. While discrete TPMs - as found in higher-end systems - have been susceptible to attacks on their exposed communication interface, more common firmware TPMs (fTPMs) are immune to this attack vector as they do not communicate with the CPU via an exposed bus. In this paper, we analyze a new class of attacks against fTPMs: Attacking their Trusted Execution Environment can lead to a full TPM state compromise. We experimentally verify this attack by compromising the AMD Secure Processor, which constitutes the TEE for AMD's fTPMs. In contrast to previous dTPM sniffing attacks, this vulnerability exposes the complete internal TPM state of the fTPM. It allows us to extract any cryptographic material stored or sealed by the fTPM regardless of authentication mechanisms such as Platform Configuration Register validation or passphrases with anti-hammering protection. First, we demonstrate the impact of our findings by - to the best of our knowledge - enabling the first attack against Full Disk Encryption solutions backed by an fTPM. Furthermore, we lay out how any application relying solely on the 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. Lastly, we analyze the impact of our attack on FDE solutions protected by a TPM and PIN strategy. While a naive implementation also leaves the disk completely unprotected, we find that BitLocker's FDE implementation withholds some protection depending on the complexity of the used PIN. Our results show that when an fTPM's internal state is compromised, a TPM and PIN strategy for FDE is less secure than TPM-less protection with a reasonable passphrase.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

11 selected excerpts · 11 total mentions

pregnenolone
Neutral mention · rule
Lots and lots of smattering around here. If anything, this is a secure boot flaw (and partially TPM), but that is a separate conversation. Also, it's been known for years that TPM based encryption should always be protected with a PIN for truly sensitive data: https://learn.microsoft.com/en-us/windows/security/operating... The author claims to be able to bypass TPM + PIN protection, but I seriously doubt it because that would require breaking or exploiting the TPM itself. Perhaps the author was referring to existing fTPM flaws but even then, brute-forcing the PIN would still be required because on BitLocker, the wrapped VMEK depends on the PIN, which brings me to the…
Read the full comment
"backdoor" topic. As I have already mentioned, exploits have been found in AMD fTPMs in the past (https://arxiv.org/abs/2304.14717). This flaw is particularly severe on Linux/cryptenroll because the TPM returns the actual FVEK, unlike BitLocker, where the VMEK itself depends on the PIN. This cryptenroll flaw has been known for years and remains unfixed on cryptenroll (https://github.com/systemd/systemd/pull/27502). Yet, I see no one yelling and crying, or accusing Lennart of being compromised. Cryptography, especially when combined with hardware security, is inherently not easy — and people make mistakes.
Original comment Security researcher says Microsoft built a Bitlocker backdoor, releases exploit
chlorion
Neutral mention · rule
Just a heads up for anyone using AMD CPUs fTPM, it is completely broken and cannot be used even for "someone stealing your laptop". A few hours time and a few tools can fully compromise the TPM's secrets. This can be performed by anyone who has a little experience tinkering with electronics, someone who can use a soldering iron for example can almost certainly pull this off. https://arxiv.org/abs/2304.14717
Original comment Linux and TPMs with systemd measured boot [video]
dhx
Neutral mention · rule
This is the same attack (and same people who developed) faulTPM[1] that was previously discussed[2]. This article is the same people demonstrating that attack against Tesla vehicles. The paper[1] and previous discussion[2] address the underlying problems with AMD's Secure Processor (AMD-SP) that is embedded in their CPU SoCs and previously and more commonly known as Platform Security Processor (AMD-PSP). Unlike a web browser where W3C AntiFraudCG folk propose that websites would blacklist all impacted AMD-SP hardware and create massive amounts of e-waste[3], Tesla likely can't do much about this attack because Tesla (not users) would be responsible for a very expensive…
Read the full comment
change of vehicle hardware. If it's not an easy-to-execute attack like faulTPM, there are more complex (but becoming more mainstream and cheaper) IC reverse engineering methods like polishing the die down to take photos of each metal layer and regenerating VHDL, FIB editing an operational IC to bypass tamper detection methods, etc[4]. A security architect of the Xbox One presented a talk[5] a few years ago which provides some good background too. Largely the Xbox One has managed to avoid piracy because they made it economically not worth anyone's time to attack due to competitive pricing models versus high cost of attack. Similar to use of Denuvo for a month or two after release of a PC game, attackers aren't going to bother if their work amounts to nothing a month later. Hacking a Tesla to enable additional features is worth a lot of money, so the economics are quite different. It's also different economics for printer cartridges, "pay to enable more features or performance" network equipment, etc. The cost of IC reverse engineering / FIB editing attacks (or other future attack methods) will keep reducing. IC tamper detection features will get more complex. Perhaps attackers will even get an advantage once they can readily reverse engineer 3nm ICs and defenders can't do much other than implementing ever more complex and obfuscated IC tamper detection features and VHDL logic (kind of like a Denuvo situation in hardware). [1] https://arxiv.org/abs/2304.14717 [2] https://news.ycombinator.com/item?id=35787195 [3] https://github.com/antifraudcg/proposals/issues/19 [4] https://www.youtube.com/watch?v=6390Zqca3Mg [5] https://www.youtube.com/watch?v=U7VwtOrwceo
Original comment Hackers manage to unlock Tesla software-locked features
pregnenolone
Neutral mention · rule
> No, the KEK is stored inside the TPM No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM. > I don't think Bitlocker does that It does, which is why cryptsetup was much more affected by the faulTPM exploit: https://arxiv.org/abs/2304.14717 > Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too. Not only do they do the same thing,…
Read the full comment
they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.
Original comment Microsoft BitLocker – YellowKey zero-day exploit
pregnenolone
Neutral mention · rule
They’re useful for attestation, boot measurement, and maybe passkeys, but I wouldn't trust them to securely handle FDE keys for several reasons. Not only do you have to trust the TPM manufacturer – and there are many – but they also have a bad track record (look up Chris Tarnovsky’s presentation about breaking TPM 1.x chips). While parameter encryption has been phased out or not used in the first place, what's even worse is that cryptsetup stores the key in plaintext within the TPM, and this vulnerability remains unaddressed to this day. https://arxiv.org/abs/2304.14717 https://github.com/systemd/systemd/issues/37386 https://github.com/systemd/systemd/pull/27502
Original comment TPM on Embedded Systems: Pitfalls and Caveats to Watch Out For
pregnenolone
Neutral mention · rule
> Bitlocker encryption key in plaintext Actually, this is not the case. BitLocker wraps the key, meaning even if the TPM were compromised, one would still have to brute-force the PIN for the actual key. It’s cryptsetup on Linux that stores the key on the TPM in plaintext. This vulnerability has been known for quite a while and nothing has been done about it so far. https://arxiv.org/abs/2304.14717 https://github.com/systemd/systemd/issues/37386 https://github.com/systemd/systemd/pull/27502
Original comment Tailscale state file encryption no longer enabled by default
chlorion
Neutral mention · rule
This is very important. For some reason in these threads nobody seems to bring up or realize that modern AMD CPU's fTPM is completely broken and not fixable via ucode updates. The AMD TPM exploit is exploitable by a "regular" person too, it doesn't have to be a state level actor, just some techy person with a few tools and physical access to the system. We can't audit these things at all and I don't think we should just trust that they are safe, and we know for a fact that many of them aren't safe, even against "regular" threats. (AMD fTPM exploit source) https://arxiv.org/abs/2304.14717
Original comment Linux and TPMs with systemd measured boot [video]
chlorion
Neutral mention · rule
That's not really true all of the time, some AMD fTPMs have physical vulnerabilities for example, that allow compromising the entire thing with some tools and a few hours of time. Software can't fix this since it's a flaw in the hardware itself, you'd need to buy new hardware to fix this. https://arxiv.org/abs/2304.14717
Original comment Linux and TPMs with systemd measured boot [video]
dhx
Neutral mention · rule
> giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting. What prevents a website from using invasive fingerprinting _AND_ WEI together? I strongly suspect websites will end up using both WEI and invasive fingerprinting because: 1. Websites will want to use invasive fingerprinting on old browsers and it would work within browsers that deliberately don't implement WEI. 2. Websites will want to get as much invasive fingerprinting information as they can get their hands on. 3. It is another layer of fingerprinting in the likely event that WEI is ineffective due to TPM exploits[1], operating system/driver…
Read the full comment
exploits, web browser exploits, determined actors using rooms of computer display recording devices and robotic arm mouse movers, etc. Invasive fingerprinting further increases the cost and complexity to actors the website is trying to block. > This is not DRM - WEI does not lock down content It is absolutely 100% DRM. Your proposal states that devices would need to attest their configuration to the website. The website can then block the user because it doesn't want to show the news article to a Linux device where the user can block annoying pop-up ad videos, copy and paste the text or save the web page. The website can instead only allow devices which are factory-configured to block copy+paste, block saving web pages, block screenshots, etc. It's still DRM even with the proposed holdback mechanism because in the best case, a user will still be blocked 9/10 times (or whatever the holdback mechanism is set to). The more likely scenario is a website owner will just refuse to serve content until the client has attested itself. "The requested page can not be provided due to an unexpected problem. Try again in a few minutes." There are so many flaws with the scheme as currently proposed I feel I could write for days: Will websites be expected to block and ban users of AMD-SP now that it is broken[1]? Or will whoever conducts ad fraud just buy all the AMD-SP devices they can get their hands on? As another author replied, are Gentoo users that compile their web browsers and operating systems from scratch just ignored, and the proposal pretends it won't impact these users? How does the proposal allow users with specialist accessibility software to browse the web without being blocked for being a minority group that is not economically worth website owner's time to support? What prevents abuse of said specialist accessibility software for other purposes? How would a new start-up developing a competing browser or phone from scratch, and are very much unknown and in a minority position, be able to convince millions of website owners to unblock/allow their new browser or phone? Cloudflare's Friendly Bots program refuses to respond to open source projects, so why would Cloudflare as an implementer of WEI care about new start-ups or small open source software projects? [1] https://arxiv.org/abs/2304.14717
Original comment Web Environment Integrity API
dhx
Neutral mention · rule
Why should anyone trust a remote server providing a signed statement of authenticity when Intel[1], MSI[2], Lenovo[3], NVIDIA[4], Microsoft and others keep losing their keys? Even if they haven't lost their keys recently, technology companies don't have a great track record of producing foolproof hardware designs (e.g. recent case of [5]), if foolproof was ever a reasonable expectation. For starters, it's assuming technology such as ptychographic X-ray computed tomography and focused ion beam machining won't become more commonplace and commercially viable to readily break TPM attestation schemes. Or that with wider use of TPM attestation, more effort will be expended into…
Read the full comment
breaking it whereas for the current state with minimal adoption, few people care. The issue client-side is that if a single vendor or TPM design is compromised, threat actors have ample motive, resources and ability to exploit this compromised hardware, whilst everyone else has few choices, such as dumping at great expensve some more e-waste. And critically, you as a user are blocked by your acceptance of TPM attestation technology from discovering attacks and auditing your own system security, as you ceded control of your own systems. Instead, your systems are controlled by a few technology companies that have a proven terrible track record of fulfilling their alleged intent of keeping your systems and data secure. And why should they care if it doesn't lead to a higher profit at the end of the year? [1] https://github.com/binarly-io/SupplyChainAttacks/blob/main/M... [2] https://github.com/binarly-io/SupplyChainAttacks/blob/main/M... [3] https://github.com/binarly-io/SupplyChainAttacks/blob/main/L... [4] https://news.ycombinator.com/item?id=30565985 [5] https://arxiv.org/abs/2304.14717
Original comment Web Environment Integrity Explainer

Keep following the thread.

More in Security & cryptography

More from the same topics.