<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2304.14717/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2304.14717/feed.xml" rel="self" type="application/rss+xml" /><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by pregnenolone</title><link>https://news.ycombinator.com/item?id=48172020</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:48172020</guid><pubDate>Sun, 17 May 2026 18:51:01 GMT</pubDate><description>&lt;p&gt;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&amp;#x27;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…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by bootsmann</title><link>https://news.ycombinator.com/item?id=48170470</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:48170470</guid><pubDate>Sun, 17 May 2026 16:34:53 GMT</pubDate><description>&lt;p&gt;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&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by pregnenolone</title><link>https://news.ycombinator.com/item?id=48137528</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:48137528</guid><pubDate>Thu, 14 May 2026 16:17:34 GMT</pubDate><description>&lt;p&gt;&amp;gt; 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&amp;#x27;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. &amp;gt; I don&amp;#x27;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 &amp;gt; Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by nextaccountic</title><link>https://news.ycombinator.com/item?id=47384501</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:47384501</guid><pubDate>Sun, 15 Mar 2026 04:59:16 GMT</pubDate><description>&lt;p&gt;what about faulTPM? https://arxiv.org/abs/2304.14717&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by pregnenolone</title><link>https://news.ycombinator.com/item?id=46708174</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:46708174</guid><pubDate>Wed, 21 Jan 2026 16:49:47 GMT</pubDate><description>&lt;p&gt;They’re useful for attestation, boot measurement, and maybe passkeys, but I wouldn&amp;#x27;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&amp;#x27;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…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by pregnenolone</title><link>https://news.ycombinator.com/item?id=46539181</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:46539181</guid><pubDate>Thu, 08 Jan 2026 09:46:58 GMT</pubDate><description>&lt;p&gt;&amp;gt; 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&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by chlorion</title><link>https://news.ycombinator.com/item?id=38155329</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:38155329</guid><pubDate>Sun, 05 Nov 2023 20:29:21 GMT</pubDate><description>&lt;p&gt;Just a heads up for anyone using AMD CPUs fTPM, it is completely broken and cannot be used even for &amp;quot;someone stealing your laptop&amp;quot;. A few hours time and a few tools can fully compromise the TPM&amp;#x27;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. From my understanding all of the &amp;quot;zen&amp;quot; CPUs are effected except for maybe the very most recent models. https://arxiv.org/abs/2304.14717&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by chlorion</title><link>https://news.ycombinator.com/item?id=38155274</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:38155274</guid><pubDate>Sun, 05 Nov 2023 20:24:21 GMT</pubDate><description>&lt;p&gt;This is very important. For some reason in these threads nobody seems to bring up or realize that modern AMD CPU&amp;#x27;s fTPM is completely broken and not fixable via ucode updates. The AMD TPM exploit is exploitable by a &amp;quot;regular&amp;quot; person too, it doesn&amp;#x27;t have to be a state level actor, just some techy person with a few tools and physical access to the system. We can&amp;#x27;t audit these things at all and I don&amp;#x27;t think we should just trust that they are safe, and we know for a fact that many of them aren&amp;#x27;t safe, even against &amp;quot;regular&amp;quot; threats. (AMD fTPM exploit source) https://arxiv.org/abs/2304.14717&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by chlorion</title><link>https://news.ycombinator.com/item?id=38155205</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:38155205</guid><pubDate>Sun, 05 Nov 2023 20:18:10 GMT</pubDate><description>&lt;p&gt;That&amp;#x27;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&amp;#x27;t fix this since it&amp;#x27;s a flaw in the hardware itself, you&amp;#x27;d need to buy new hardware to fix this. https://arxiv.org/abs/2304.14717&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by dhx</title><link>https://news.ycombinator.com/item?id=36996082</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:36996082</guid><pubDate>Fri, 04 Aug 2023 06:15:40 GMT</pubDate><description>&lt;p&gt;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&amp;#x27;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&amp;#x27;t do much about…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by dhx</title><link>https://news.ycombinator.com/item?id=36857870</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:36857870</guid><pubDate>Tue, 25 Jul 2023 04:23:27 GMT</pubDate><description>&lt;p&gt;&amp;gt; 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&amp;#x27;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…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — mentioned by dhx</title><link>https://news.ycombinator.com/item?id=36789624</link><guid isPermaLink="false">urn:hackerpapers:mention:2304.14717:36789624</guid><pubDate>Wed, 19 Jul 2023 17:00:36 GMT</pubDate><description>&lt;p&gt;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&amp;#x27;t lost their keys recently, technology companies don&amp;#x27;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&amp;#x27;s assuming technology such as ptychographic X-ray computed tomography and focused ion beam machining won&amp;#x27;t become more commonplace and commercially viable to readily break TPM attestation…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — HN submission</title><link>https://news.ycombinator.com/item?id=35787195</link><guid isPermaLink="false">urn:hackerpapers:submission:2304.14717:35787195</guid><pubDate>Tue, 02 May 2023 13:35:25 GMT</pubDate><description>&lt;p&gt;faulTPM: Exposing AMD fTPMs&amp;#x27; Deepest Secrets&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;287 points; 262 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item><item><title>faulTPM: Exposing AMD fTPMs' Deepest Secrets — HN submission</title><link>https://news.ycombinator.com/item?id=35778336</link><guid isPermaLink="false">urn:hackerpapers:submission:2304.14717:35778336</guid><pubDate>Mon, 01 May 2023 20:01:02 GMT</pubDate><description>&lt;p&gt;FaulTPM: Exposing AMD fTPMs&amp;#x27; Deepest Secrets&lt;/p&gt;&lt;p&gt;&lt;/p&gt;&lt;p&gt;3 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/2304.14717/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item></channel></rss>
