HackerPapers

arXiv:2304.14717cs.CR

faulTPM: Exposing AMD fTPMs' Deepest Secrets

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

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.

arXiv comments
The first two authors contributed equally. We publish all code necessary to mount the attack under https://github.com/PSPReverse/ftpm_attack. The repository further includes several intermediate results, e.g., flash memory dumps, to retrace the attack process without possessing the target boards and required hardware tools
Journal reference
DOI
Subjects
cs.CRCryptography and Security

On Hacker News

Linked by 5 identifiable commenters in 12 comments across 9 threads, from Jul 2023 to May 2026. Found in 2 HN submissions from May 2023 to May 2023. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments9 threads

    • fTPMs also have similar issues. The real takeaway is that if your threat model includes actors capable of executing attacks against BitLocker you need to put a password/pin on it in addition to the TPM. https://arxiv.org/pdf/2304.14717

      bootsmannView on HNParent context

    • 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…

      pregnenoloneView on HNParent context

    • > 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…

      pregnenoloneView on HNParent context

  1. How Kernel Anti-Cheats Work 1 comment
    • 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…

      pregnenoloneView on HNParent context

    • > 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…

      pregnenoloneView on HNParent context

    • 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…

      chlorionView on HNParent context

    • 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…

      chlorionView on HNParent context

    • 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…

      chlorionView on HNParent context

    • 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…

      dhxView on HNParent context

    • > 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…

      dhxView on HNParent context

    • 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…

      dhxView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.