HackerPapers

arXiv:1908.11680cs.CR

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

Robert Buhren, Christian Werling, Jean-Pierre Seifert

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.

arXiv comments
Journal reference
DOI
doi:10.1145/3319535.3354216
Subjects
cs.CRCryptography and Security

On Hacker News

Linked by 4 identifiable commenters in 4 comments across 4 threads, from Jun 2020 to Oct 2025.

Comments linking this paper, per year.

Discussed in comments4 threads

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

      librootView on HNParent context

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

      ReelinView on HNParent context

  1. Confidential VMs 1 comment
    • 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…

      zimmerfreiView on HNParent context

  2. How SGX Fails in Practice 1 comment
    • 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 *…

      ENOTTYView on HNParent context

Submitted to Hacker News

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