HackerPapers

arXiv:2108.04575cs.CR

One Glitch to Rule Them All: Fault Injection Attacks Against AMD's Secure Encrypted Virtualization

Robert Buhren, Hans Niklas Jacob, Thilo Krachenfels, Jean-Pierre Seifert

Abstract

AMD Secure Encrypted Virtualization (SEV) offers protection mechanisms for virtual machines in untrusted environments through memory and register encryption. To separate security-sensitive operations from software executing on the main x86 cores, SEV leverages the AMD Secure Processor (AMD-SP). This paper introduces a new approach to attack SEV-protected virtual machines (VMs) by targeting the AMD-SP. We present a voltage glitching attack that allows an attacker to execute custom payloads on the AMD-SPs of all microarchitectures that support SEV currently on the market (Zen 1, Zen 2, and Zen 3). The presented methods allow us to deploy a custom SEV firmware on the AMD-SP, which enables an adversary to decrypt a VM's memory. Furthermore, using our approach, we can extract endorsement keys of SEV-enabled CPUs, which allows us to fake attestation reports or to pose as a valid target for VM migration without requiring physical access to the target host. Moreover, we reverse-engineered the Versioned Chip Endorsement Key (VCEK) mechanism introduced with SEV Secure Nested Paging (SEV-SNP). The VCEK binds the endorsement keys to the firmware version of TCB components relevant for SEV. Building on the ability to extract the endorsement keys, we show how to derive valid VCEKs for arbitrary firmware versions. With our findings, we prove that SEV cannot adequately protect confidential data in cloud environments from insider attackers, such as rogue administrators, on currently available CPUs.

arXiv comments
Journal reference
DOI
Subjects
cs.CRCryptography and Security

On Hacker News

Linked by 5 identifiable commenters in 5 comments across 5 threads, from Apr 2022 to Aug 2025. Found in 1 HN submission from Aug 2021 to Aug 2021. Open submission discussions.

Comments linking this paper, per year.

Discussed in comments5 threads

  1. A privacy VPN you can verify 1 comment
    • I actually spent a few months prototyping SGX/SEV VPNs before settling on a Multi-Party Relay scheme for obscura.net Things may have changed since mid-2023 but here were my takeaways: ----- Re: Vendor lock-in Vendor lock-in is (was?) a huge problem (at least for process-based…

      dongcarlView on HNParent context

    • An attacker would need to compromise our build pipeline to publish a backdoored VM image [1] and extract key material to forge an attestation from the hardware [2]. The build process publishes a hash of the code to Sigstore’s transparency log [3], which would make the attack…

      natesalesView on HNParent context

    • There's also voltage glitching which has been used with great success as well[1][2]. [1]: https://web.archive.org/web/20190801014726/https://www.cl.ca... [2]: https://arxiv.org/abs/2108.04575

      magicalhippoView on HNParent context

    • AMD was impacted by a Meltdown-style attack[0], and the AMD Secure Encrypted Virtualization voltage attack[1] that, recently, was used to jailbreak Teslas. This culture of corporate fandom "console wars" mentality that has permeated almost every facet of technical discussion…

      nazgulsenpaiView on HNParent context

    • In terms of security these technologies are (mostly) strictly worse than SGX, and there hasn't been nearly enough security research done on them. Also, the physical attack vectors remain (e.g. https://arxiv.org/abs/2108.04575). A small but interesting counterexample is x86 TSC…

      exfalsoView on HNParent context

Submitted to Hacker News

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