Skip to content
Back to the collection

Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation

Robert Buhren, Christian Werling, Jean-Pierre Seifert

2019 · arXiv

Read the paper
HN score
0
Mentions
4
Readers
4
Months
4
What’s in a score?

From the abstract

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol.This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol.Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.

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

4 selected excerpts · 4 total mentions

libroot
Neutral mention · rule
Sure, threat models matter, but that's exactly the point. TEEs are marketed as if they solve the "malicious infrastructure" problem. Cloud providers tell you they can't see your data, and vendors pitch TEEs as some kind of hardware-rooted guarantee. If your threat model is "malicious sysadmin" or "host operator" then the fact that the root of trust is opaque, unauditable, and repeatedly compromised does matter. Saying "what's your alternative" also misses the criticism. The issue isn't whether TEEs can reduce some threats compared to no isolation at all. Obviously they can in some scenarios. The issue is that their trust model is misrepresented: you're still trusting…
Read the full comment
vendors and firmware you can't inspect, and history shows that trust is often misplaced. That's not "no alternative", that's "don't build your security story on black boxes with a track record of holes." If the only way TEEs "work" is if you lower your expectations to "slightly better than nothing," then the marketing and security claims around them are deeply misleading. At that point, calling them "trusted" environments is just branding, not security. > Additionally, you still get attestation which gives you cryptographic proof of what code is running. Remote attestation ultimately relies on the same implicit trust it claims to replace. For example this paper[1] from 2019 showed how AMD's PSP secure boot can be compromised, giving an attacker an possibility to load a patched firmware that grants arbitrary read/write access to the PSP memory, which then allows the attacker to extract the Chip Endorsement Key (CEK), which is AMD's attestation root key. Once you have the CEK, you can forge attestation reports (for example impersonate a legitimate SEV platform) or bypass attestation entirely. And the CEK had (changed in 2023) an infinite lifetime and there was no rollback protection, so even if AMD issued a firmware update, attackers could revert to the old vulnerable firmware and re-extract the CEK. [1]: https://arxiv.org/pdf/1908.11680 Edit: And very recently, the new Battering RAM[2] (Sep 2025) and WireTap[3] (Oct 2025) attacks have broken Intel SGX and AMD SEV-SNP remote attestations. [2]: https://batteringram.eu/ [3]: https://wiretap.fail/
Reelin
Neutral mention · rule
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
zimmerfrei
Neutral mention · rule
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'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...
ENOTTY
Neutral mention · rule
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 * https://arxiv.org/pdf/2004.11071.pdf 2020 Any enclave technology will be reliant on the underlying…
Read the full comment
security of the processor itself. Someone was going to have to go first. Intel happened to take greater risks in the name of performance, and all of their technologies (including their first-to-market enclave technology) are suffering reputational hits as a result. I'll also just mention that CrossTalk is the more interesting vulnerability affecting SGX that was disclosed today.

Keep following the thread.

More in Security & cryptography

More from the same topics.

2014arXiv

Explaining and Harnessing Adversarial Examples

Ian J. Goodfellow, Jonathon Shlens, Christian Szegedy

Several machine learning models, including neural networks, consistently misclassify adversarial examples---inputs formed by applying small but intentionally worst-case perturbations to examples from the dataset, such that the perturbed input results in the model outputting an incorrect answer with high confidence.

1.5HN score