How SGX Fails in Practice

SEV (a hypothetical version that wasn't broken) would give you encrypted memory and some basic remote attestation protocols.

The point of this is to stop a cloud vendor from peeking into your VM.

But the problem is, none of the software inside your VM is designed to resist attacks by a malicious hypervisor. This isn't just side channel attacks but also so-called Iago attacks. This is where a formerly higher privileged piece of software is trying to break into a lower privileged bit of software by manipulating the API responses.

For SGX it was shown that running a whole standard Linux process inside an enclave and relaying system calls outside (i.e. a similar arrangement to what SEV does) could lead to the process being hacked the moment it did something trivial like call malloc(). The reason was, the software didn't expect the kernel to try and manipulate it via syscall return values because there is no point normally.

In SEV we have the same issue. Hypervisors were previously more privileged than kernels. Therefore kernels and apps aren't designed on the assumption of a malicious hypervisor. It's highly likely that not only side channel attacks but also Iago attacks apply there too.

Now you could say, well, one step at a time, maybe it doesn't matter, better than nothing etc. Sure. All true. At the very least it complicates the attack process and is more likely to generate an audit trail inside the cloud vendor.

But actually Intel had a somewhat comparable solution for a long time called TXT. It lets you start a trusted/measured hypervisor that can then supervise VMs on the box. This is in some ways stronger as you can actually check the hypervisor won't attack the VMs. But it's hardly used because cloud vendors use proprietary hypervisors, and actually the threat model people care about is "malicious cloud vendor trying to break into the VM", not "incremental security improvement of unknown utility".

I suspect Intel will implement encrypted memory for VMs at some point anyway because of the viewpoint you raise here being quite common - "I'll encrypt the RAM for free and then I'm done" although of course it needs tooling integration as well. It's not actually quite for free.

But I guess if this takes off then AMD will start to see a lot of research papers where people break into the encrypted memory space in various clever ways, and of course, you're also vulnerable to any exploits in the software stack on the VM itself. That was the main reason the security community ended up with the SGX type model. When your trusted computing base is an entire virtual machine it doesn't give you much because VMs have so much software in them, they get hacked all the time. The idea of enclaves is you design your app so the bulk of the software stack is untrusted, and only small parts get to directly touch sensitive data.

Instead, this attack extracted the sealing and attestation keys stored by the current version of Intel's Quoting Enclave under the current microcode revision (and presumably all previous microcode revisions).

Assuming Intel fixes the vulnerability in the next revision of microcode (lets call it Rev H), the Quoting Enclave will need to generate and/or store new attestation keys. Because the root secrets were not leaked AND the microcode revision has revved forward, these cannot be derived under previous microcode revisions. Thus, they are assumed not to be available to the attacker under the SGXAxe/Cacheout vulnerabiilty.

Intel generates or provides access to new public keys that correspond to the attestation keys. You use these to verify the Quoting Enclave's attestations.

Intel additionally asserts that these new public keys will only verify attestations created by the Quoting Enclave running under Rev H of the microcode.

You must determine whether to trust this assertion.

For example, every smartcard is essentially a device in your physical possession, running somebody else's code. I'd argue that for example in the case of EMV payment cards, the benefit is mutual (less fraud).

Android supports a variant of this for generic secure transaction confirmation: https://android-developers.googleblog.com/2018/10/android-pr...

I don't think SGX + PAVP ever made it past the prototype stage, and the SDK is proprietary. My company actually wanted to use it for a trusted computing application (think "secure transaction approval") and Intel told us it was deprecated and unsupported.

I'm literally asking you, what do you use for that purpose?

But if you were a cloud service provider, I'd give my data and money to the competition (assuming I believe their claims regarding trusted computing).

  $ grep vendor_id /proc/cpuinfo
  vendor_id       : AuthenticAMD