The keys used to encrypt the confidential VM memory is kept in the hw registers and not accessible and extractable by any sw, google or AMD. The keys are per a VM, ephemeral, so not stored anywhere.
RE: storage level, you can encrypt your disk on the file system level if confidentiality of the data is important to you, dm-crypt with dm-verity are good choices.
I agree with you that Google SREs are probably the best, no argument there.
The answer to your question: The AES mode AMD SEV uses is similar to XEX. AMD computes a tweak value based on the physical memory address and performs an xor-encrypt-xor operation. The tweak algorithm used on Rome (2nd gen EPYC) is based on GF math and uses a random value that is changed on each boot.
Actually, the integrity of the AMD microcode can be verified using Google stackdriver as part of VM audit logs, together with the integrity of the VM kernel.
But everything else is not actually confidential... Confidentiality means limited visibility, when you process your data, the memory is in clear without this tech, or Intel SGX that offer confidentiality and integrity.
You can access memory within a VM, not outside of a VM. Host machine with a hypervisor is not within a VM instance, so it will not be able to read your VM memory. The memory is encrypted all the time, but when the instruction has to be executed on CPU, memory controllers (only and only have access to the keys of this VM) decrypt the instruction to execute it on cpu in clear. For FHE, cpu instructions are executed on AES encrypted blocks, and will take significant time, so not very practical today. Does it make sense?
You are right, data is private and confidential when it is ingested to the cloud and/or stored in the cloud, not when processed. Encryption of "data-in-use" is the 3rd leg in data protection of sensitive data, and it became possible with hw capabilities in new CPU chipsets, from AMD and Intel, as it has to be hardware based (better security and performance).
Quite a few: protect sensitive data in the cloud from the tenants and cloud providers, protect my clients sensitive data, address some requirements of the regulated markets, mitigate some privacy regulations, and a few new: collaborative computing with untrusted parties?
SEV is targeted to the VM instances, with a single key per VM.
SME is applicable to the entire server, similar to total memory encryption with a single key for all host kernel/machine. SME is not super applicable to the cloud, more suitable for a single server environments.
GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.
Homomorphic encryption enables computation to be performed on encrypted data without the need to decrypt it on the CPU. Compared to Confidential Computing approaches, the processing complexity of FHE is quite high, especially for tasks that require execution of complicated algorithms, making it hard to scale with this approach.
Confidential VMs with AMD SEV decrypt data within VMs and keep it encrypted "in-use" by encrypting memory with a key generated by AMD secure processor (non-extractable) per VM. After processing data and code can be encrypted back to keep it protected at-rest.
SEV: No changes are required to the apps, better performance, but bigger TCB. GCP mitigate this with Shielded VMs, in particular integrity of the kernel in your trusted boundary, notifications to users if the integrity state changed from the baseline and made it default and free. https://cloud.google.com/blog/products/identity-security/sec...
SGX: smaller TCB, but limited scale, and you have to partition your app to secure and no-secure parts using one of the SDK available, Intel SGX SDK, Microsoft OpenEnclave or Google Asylo.
"Neither Amazon.com nor Microsoft - which hold 41 percent and 13 percent of cloud market share, respectively, according to Synergy Research Group - have said if they have similar features."
Great question. We are working on it. LOAS is about server or device credentials that only will be issued if Titan will pass the validation of bios firmware.
Hey there, I am one of the authors behind this blog. How about we will share our Titan earrings swag instead for your close examination? We fixed captions on the blog, thanks for pointing it out.
You are right, some instructions are not suitable for userspace due to their performance implications and have to stay in the kernel. We identified a small set of them, for example, some parts of IOAPIC support have to stay put.