<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1908.11680/</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/1908.11680/feed.xml" rel="self" type="application/rss+xml" /><item><title>Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation — mentioned by libroot</title><link>https://news.ycombinator.com/item?id=45542751</link><guid isPermaLink="false">urn:hackerpapers:mention:1908.11680:45542751</guid><pubDate>Fri, 10 Oct 2025 19:25:57 GMT</pubDate><description>&lt;p&gt;Sure, threat models matter, but that&amp;#x27;s exactly the point. TEEs are marketed as if they solve the &amp;quot;malicious infrastructure&amp;quot; problem. Cloud providers tell you they can&amp;#x27;t see your data, and vendors pitch TEEs as some kind of hardware-rooted guarantee. If your threat model is &amp;quot;malicious sysadmin&amp;quot; or &amp;quot;host operator&amp;quot; then the fact that the root of trust is opaque, unauditable, and repeatedly compromised does matter. Saying &amp;quot;what&amp;#x27;s your alternative&amp;quot; also misses the criticism. The issue isn&amp;#x27;t whether TEEs can reduce some threats compared to no isolation at all. Obviously they can in some scenarios.…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1908.11680/"&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>Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation — mentioned by Reelin</title><link>https://news.ycombinator.com/item?id=24081643</link><guid isPermaLink="false">urn:hackerpapers:mention:1908.11680:24081643</guid><pubDate>Fri, 07 Aug 2020 13:39:15 GMT</pubDate><description>&lt;p&gt;I feel the need to disclaim that I have no actual experience using SEV. Also it looks like the attestation protocol may have been broken by attacking the PSP firmware? I have no idea what the current state of affairs is, particularly regarding the claimed firmware downgrade vulnerability. https://arxiv.org/abs/1908.11680 https://berlin-crypto.github.io/event/amdsev.html&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1908.11680/"&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>Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation — mentioned by zimmerfrei</title><link>https://news.ycombinator.com/item?id=23843284</link><guid isPermaLink="false">urn:hackerpapers:mention:1908.11680:23843284</guid><pubDate>Wed, 15 Jul 2020 10:19:35 GMT</pubDate><description>&lt;p&gt;This is using SEV-ES (SEV2) which is vulnerable to the severe attack described last year in [1], and unfixable due to the lack of antirollback functionality. Only SEV-SNP [2] is supposed to address it, but only on new silicon which doesn&amp;#x27;t exist yet, and that probably not even Google has. So why is Google releasing this feature if it is so flawed? [1] https://arxiv.org/pdf/1908.11680.pdf [2] https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1908.11680/"&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>Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation — mentioned by ENOTTY</title><link>https://news.ycombinator.com/item?id=23469377</link><guid isPermaLink="false">urn:hackerpapers:mention:1908.11680:23469377</guid><pubDate>Tue, 09 Jun 2020 18:39:07 GMT</pubDate><description>&lt;p&gt;SEV has been subjected to its own share of attacks (and design/implementation fails), but note that it has a different threat model. * https://arxiv.org/pdf/1712.05090.pdf 2017 * https://arxiv.org/pdf/1612.01119.pdf 2017 * https://arxiv.org/pdf/1805.09604.pdf 2018 * https://ipads.se.sjtu.edu.cn/_media/publications/fidelius_hp... 2018 * https://seclists.org/fulldisclosure/2019/Jun/46 2019 * https://www3.cs.stonybrook.edu/~mikepo/papers/severest.asiac... 2019 * https://www.usenix.org/system/files/sec19-li-mengyuan_0.pdf 2019 * https://arxiv.org/pdf/1908.11680.pdf 2019 *…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1908.11680/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item></channel></rss>
