Analyzing AMD SEV's Remote Attestation | Robert Buhren | Hardwear.io Webinar

Webinar:
----------

About Webinar:
------------------
Cloud computing is one of the most prominent technologies to host Internet services that unfortunately leads to an increased risk of data theft. 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. Executing in a higher-privileged CPU mode, the hypervisor has direct access to the memory of virtual machines. While data at rest can be protected using well-known disk encryption methods, data residing in main memory is still threatened by a potentially malicious cloud provider. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in such 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 protocol is a crucial component of the SEV technology that can prove that SEV protection is in place and that the virtual machine was not subject to manipulation. 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.

About Speaker:
----------------
Robert Buhren is a security researcher and firmware reverse engineer currently pursuing a PhD at the Technische Universität Berlin. His research focuses on cloud security and shielding systems. Previously he presented his work on the AMD Platform Security Processor at the Chaos Communication Congress and the Chaos Communication Camp.

#Hardware #Security #Firmware
----------------------------------------------------------------------------------

-------------------------------------------------------------------------------------

[ManGo]

at 9:45, why can't we GCP/AWS buy an AMD system, and copy the data that's in the secure processor and create a emulator for secure processor? How do we know this is actually a hardware level guarantee?

[ManGo]

Are there any safeguards against a bad actor with physical access messing with the secure processor's firmware?