7

A cloud operator such as Google can take a snapshot of a normal VM. This includes CPU state, RAM and disk. This can then be copied to another physical and resumed there. Or it can be analyzed off-line, and any cryptokeys in memory or in the CPU state can be extracted.

This means that if you do not trust your cloud VM provider (maybe your cloud VM provider is owned by your worst competitor), you should not process confidential data on those VMs.

https://cloud.google.com/confidential-computing seems to use AMD's Secure Encrypted Virtualization which includes hardware RAM encryption: https://developer.amd.com/sev/

If the RAM is encrypted, it will make it harder to use attacks like https://rambleed.com/

But will it also protect against Google?

It seems the RAM is encrypted with a key, that lives in the CPU. But is this key included when Google takes a snapshot of the CPU state of the VM?

In theory I could see it work like this: The CPU has a small web server with a TLS certificate signed by AMD. I access the web server, verify AMD's certificate, and now I have a secure connection to the CPU that Google cannot access.

Then I give the CPU a secret key to encrypt RAM with. Then I give it a disk image encrypted with the same key. Then I boot the VM.

If the secret key physically cannot leave the CPU, then it should be impossible for Google to access my data: The RAM is encrypted, data to the disk and to the network is encrypted. So I do not need to trust neither the RAM, the storage, nor the network. It will, however, also mean Google cannot snapshot my VM and restore it on another CPU.

This would also mean that this answer is outdated: https://security.stackexchange.com/a/215927/84564

Currently I see no way to do something similar to verifing the AMD certificate in Google's current solution. And thus I see no way to securely set a key that Google does not have access to.

Can Google take a snapshot of a running confidential computing VM and restore it?

Using AMD's SEV can CIA safely process their most secret data on North Korea's Confidential cloud (assuming they have that) without North Korea being able to access the data - assuming that AMD is trustworthy, but all other hardware apart from the CPU is made in North Korea?

9
  • What if google backdoors it before you have set all this up?
    – yeah_well
    Commented Dec 1, 2020 at 16:39
  • @VipulNair Where would you (Google) put the backdoor? Let's us assume Google does not change the AMD CPU. We can assume all other hardware than the CPU is "evil".
    – Ole Tange
    Commented Dec 1, 2020 at 17:33
  • @reed I think I can answer all of those by watching the first half of youtube.com/watch?v=0-ISmJNxGiY (especially 9:26-15:30). Have you watched that? Did you understand it?
    – Ole Tange
    Commented Dec 5, 2020 at 3:04
  • @OleTange assuming that OS will be stored in disk,when the disk is unencrypted,whats going to stop google from backdoorinng it when they have the physical access to the disk?
    – yeah_well
    Commented Dec 5, 2020 at 6:59
  • 1
    Ok, I watched part of the video and thought about this a bit more, although I'm not sure I understand some important details yet. Correct me if I'm wrong: all your data (i.e. guest OS images, applications, etc.) never leaves your local machine unencrypted, right? Everything is encrypted with keys that, ultimately (at the end of the chains), can be trusted because they are signed by AMD that guarantees that only one of their CPUs can decrypt your code. If so, then you really only have to trust AMD and no one else.
    – reed
    Commented Dec 5, 2020 at 12:13

1 Answer 1

3

I found: https://www.youtube.com/watch?v=0-ISmJNxGiY

Watching 11:00-15:30 it seems my theory with the internal web server is pretty close to how it is designed.

So this confirms that it is indeed possible. This is HUGE: In time we will be able to run on untrusted hardware as long as we trust the CPU. So this answer is indeed outdated: How to prevent a hosting company from accessing a VM's encryption keys? The answer is not entirely wrong, because a dedicated attacker could open the AMD CPU and attach wires inside the CPU, but it would make the attack much harder - especially if AMD actively made the CPU tamperresistant.

But since Google does not seem to provide the information from the slide at 15:00 (i.e. I do not get the PDH and do not get to talk directly to the CPU) it seems Google still has control over the server: They have an (undisguised) Man-in-the-middle, namely their control panel, which could be lying about your VM being spawned on an AMD CPU.

This leads me to the conclusion that Google Confidential computing VMs are probably well guarded against attacks from other VMs running on the same server (like https://rambleed.com/), but they are not currently guarded against an attack from Google.

If, however, Google gave me access to the PDH this could change.

With the certificate from the AMD Secure Processor I can set up a secure channel to this unique CPU using Diffie-Hellman (the chip endorsement key https://youtu.be/0-ISmJNxGiY?t=728 and the platform Diffie-Hellman https://youtu.be/0-ISmJNxGiY?t=660) - pretty much like https, where you can also check the certificate is from the correct website by following its chain of trust.

The hardware outside the CPU will thus be similar to the internet when talking https: You do not need to trust the hardware (just like you do not need to trust the internet), because it only sees encrypted data.

Said differently: With normal computers we have no problem connecting them to internet that we do not regard trustworthy: We use encryption, so that anyone spying on the data going into and out of the computer will only see encrypted data. We can still check that we are communicating with the correct recipient using digital certificates.

AMD SEV just moves this limit inside the CPU: Everything going in and out of the CPU will be encrypted. And a cloud customer can check he is talking to the unique AMD Secure Processor by using the digital certificates.

The hypervisor (which is the first OS that boots on the machine and which is used to provide internet access to the AMD Secure Processor) does not have to be trusted. The hypervisor is isolated from the VM: The hypervisor can read and write the encrypted memory, but not the key for this encryption (https://youtu.be/0-ISmJNxGiY?t=86). A bit like VPN: You can have an untrusted connection carry a trusted connection on top of it.

The hypervisor can control VMs, but it cannot set the encryption key for the VM. A bit like an ISP who can throttle your internet connection without being able to decrypt your VPN.

The trusted VM starts by having a unencrypted, untrusted BIOS (https://youtu.be/0-ISmJNxGiY?t=563). This BIOS is then hashed and encrypted by the trusted CPU, and the hash is given to the customer. This way the customer will know if the BIOS for the VM is changed. If the customer accepts the hash as correct, he will then inject a secret (e.g. an encrypted disk image or a key to open an encrypted disk image stored on untrusted storage) (https://youtu.be/0-ISmJNxGiY?t=639), and then the VM boots in the encrypted RAM.

Summing up the similarities between https and AMD SEV:

Feature HTTPS SERVER AMD SEV
Untrusted features
Fast storage Full disk encrypted SSD Encrypted RAM
Slow storage Encrypted remote backup Full disk encrypted SSD
Control channel ("network traffic") https encrypted Diffie Hellman encrypted
Trusted features The whole server AMD Secure Processor
Certificate TLS-certificate for https certificate for secure processor
Certificate authority e.g. Thawte AMD
Key for fast storage full disk encryption key RAM encryption key
Key for slow storage backup encryption key full disk encryption key
Key storage small boot disk secure encrypted NV-storage

Would I recommend CIA do their confidential data processing in North Korea's confidential cloud (assuming they have one)?

No: AMD's SEV makes it much harder for an attacker. An attacker cannot simply take a snapshot and use that. He can, however, still corrupt memory, and if he is willing to open the CPU he may be able to bypass some security by attaching wires. But these attacks are out of reach for a normal cloud hosting provider.

So it does not protect against a truly dedicated evil hosting provider, but it does seem to protect against a sloppy hosting provider, who does not have major resources for attacking the customer's data.

6
  • You're badly over thinking it. Can google access data in their confidential computing VMs? Absolutely, because it is their computing VMs. This is like asking, "If I hand you a box to put in the safe at your house, do you have access to my box?" Unless you are encrypting your data with a key that is never sent to Google's servers, they could access your data if they really wanted to. Commented Dec 4, 2020 at 18:25
  • @ConorMancone You use a bad analogy. Please show how Google would get the key if I can communicate directly with AMD's Secure Processor.
    – Ole Tange
    Commented Dec 5, 2020 at 1:42
  • 1
    @ConorMancone the OP proposes public private keys for communicating with the said box that will be signed by third party(AMD).How would google tamper with that?
    – yeah_well
    Commented Dec 5, 2020 at 7:01
  • @yeah_well It's as secure as the key, which is sitting inside Google's datacenter. Granted, Google would have no motivation to try to extract the keys if such a thing was in use, but could they if they wanted to? Probably eventually. There have been plenty of cases of keys being extracted from hardware that was designed to keep it secure. Here's the first of many examples from google: nccgroup.com/us/our-research/… The point though is that if Google is a "normal" cloud hosting provider then these attacks are not out of their reach. Commented Dec 11, 2020 at 15:04
  • @ConorMancone So basically your argument is: If there is a design flaw in the CPU, Google may be able to use that and extract the key. Basically the same argument I include in the section on CIA's use of North Korea's data center.
    – Ole Tange
    Commented Dec 11, 2020 at 20:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .