Re-volting: AMD Secure Encrypted Virtualization undone by electrical attack

Fault injection technique presents risk in cloud environments from rogue admins

Updated AMD's Secure Encrypted Virtualization (SEV) scheme is not as secure as its name suggests.

Boffins from the Technische Universität Berlin have devised an attack that defeats the primary purpose of this silicon safe room technology: protecting the data in virtual machines from rogue administrators in cloud environments.

In a paper titled "One Glitch to Rule Them All: Fault Injection Attacks Against AMD’s Secure Encrypted Virtualization," Robert Buhren, Hans Niklas Jacob, Thilo Krachenfels, and Jean-Pierre Seifert from TU Berlin's Security in Telecommunications group, describe how they succeeded in mounting a voltage fault injection attack.

This shock to the system allowed them to recover secret encryption keys and execute arbitrary code on all AMD chips with Secure Processors (SP).

"By manipulating the input voltage to AMD systems on a chip (SoCs), we induce an error in the read-only memory (ROM) bootloader of the AMD-SP, allowing us to gain full control over this root-of-trust," the researchers explain in their paper.

The attack was inspired by a separate cunning plan, dubbed Voltpillager, used to defeat Intel's Software Guard Extensions (SGX), a similar secure enclave system for x86 microarchitecture.

As with SGX, the SEV attack relies on cheap, off-the-shelf components: a ~$30 Teensy µController (microcontroller) and a $12 flash programmer. Non-material prerequisites pose more of a challenge – they include insider access at a cloud company, an opportunity to attach wires to the server motherboard without arousing suspicion, and some technical proficiency.

The Register asked AMD to comment. A spokesperson pointed to the physical access requirement to underscore this is not a remote attack scenario but otherwise didn't have anything to say.

SEV utilizes the Secure Processor, a microcontroller that provides the root of trust in AMD Naples (Zen 1), Rome (Zen 2), and Milan (Zen 3) chips and manages the VM lifecycle. It is supposed to protect VM data from the hypervisor and from other VMs.

But by lowering the voltage applied when the AMD-SP's ROM bootloader runs, the researchers were able to extract Chip Endorsement Keys (CEKs), which can be used to mount fully remote attacks.

The boffins were also able to defeat a new key-versioning scheme introduced by the SEV Secure Nested Paging (SEV-SNP) extension last year [PDF]. Using the electrical glitch to extract the seed values for the Versioned Chip Endorsement Key (VCEK), they were able to derive the valid VCEKs for all possible combinations of firmware versions. This represents the first publicly disclosed attack on the SEV-SNP extension, they claim.

The paper suggest two possible mitigation paths. One involves modifying software or hardware to detect voltage modulation in order to prevent execution in the presence of faults.

The other involves the addition of specific circuitry to defend against voltage glitches. The researchers observe that this is already routine for smartcards and point to a recent Nvidia patent for a cross-domain voltage glitch detection circuit that can be implemented in an SoC. ®

Updated to add

In an email to The Register Robert Buhren, one of the paper’s co-authors, challenged AMD’s claim that physical access is required to carry out the attack.

“Our attack allows to extract keys from AMD CPUs that can be used to attack VMs running on *other* CPUs,” explained Buhren. “There is no relation between the CPU that we extracted the keys from and the CPU of the target system except for that the CPUs are from the same AMD microarchitecture, i.e, both CPUs are Epyc Milan CPUs ( Zen 3 ).

“A malicious administrator can, for example, buy a AMD Epyc CPU online, extract the keys and then use these keys to target SEV systems in a data-center without needing to physically access the target systems. In our paper we specifically describe an attack scenario that allows an attacker to decrypt a SEV protected VM’s memory without physical access to the system hosting the VM.”

So when we wrote physical access was required, that’s true only for the initial glitching attack and it can be on any applicable AMD machine. After that, key extraction can be done remotely.