Can Google access data in their Confidential Computing VMs?

Question

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?

Answer 1

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.