Can Google access data in their Confidential Computing VMs?
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-Hellmann (the chip endorsement key https://youtu.be/0-ISmJNxGiY?t=728 and the platform Diffie-Hellmann 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.