来宾所有者在 Google 机密虚拟机中如何生成磁盘加密密钥？

Question

according to the AMD SEV API specification [1], the guest owner authenticates the AMD platform and verifies the integrity measurement of the launched VM guest, and later encrypts the disk encryption key and sends it to the guest (this flow is shown in Appendix A). However, when searching through the docs of Google confidential VM [2] I could not find any information about either authenticating the platform or sending the wrapped disk encryption keys to the guest.

My specific question is: in the Google Confidential VM implementation, which party generates the disk encryption key? How can the guest owner verify the launch and generate the disk encryption key? If the key is generated by the firmware under the platform provider's control, Google Cloud Platform (GCP) in this case, then the user does not gain any additional security/privacy protection from GCP insiders (as claimed in the docs [2]).

PS A bug in the docs: to get support one is advised to post on Stack Overflow with the "confidential-vm-tag" [3], however, no such tag exists as of 2020-07-29.

[1] AMD Secure Encrypted Virtualisation API v0.24 https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf

[2]https://cloud.google.com/compute/confidential-vm/docs/about-cvm

[3] https://cloud.google.com/compute/confidential-vm/docs/getting-support

Answer 1

Technically , the answer to the questions depends on which of three available approaches is chosen:

1. Google-managed keys;
2. Customer-managed;
3. Customer-supplied.

Practically , data protection issues are rarely purely technical. Crucial points are the data sensitivity level and Data Protection and Privacy agreement between the customer and the cloud provider. In other words, whether the customer can trust Google in terms of data protection, or due to the existing compliance policies the Cloud is considered as a hostile environment.

1. Google-managed keys (default). Google uses its infrastructure to generate and manage keys for the customer automatically. The customer has no control over the encryption keys.

2. Customer-managed keys (CMEK). Google uses its infrastructure to create, maintain and rotate keys for the customer. But CMEK gives the customer control over the keys via Cloud KMS . KMS used for CMEK is a cloud-hosted service that helps customers to ensure the lifecycle of encryption keys: generate, rotate, disable, revoke. Thus the customer gets more control over protected data, because the customer, for instance, can quickly terminate access to data by disabling or destroying the CMEK key.

3. Customer-supplied keys (CSEK). Data is encrypted using the keys owned by the customer. These keys are not sent to Google, but are stored and managed outside of the Google Cloud Platform. Key maintenance, rotation and deprecation is the responsibility of the customer.

The downside of the customer-managed or customer-supplied keys is that access to the encrypted data can be lost due to an unintentional deletion or loss of the key.

Cloud HSM . Encryption keys can be securely stored on a fully managed Hardware Security Modules in Google datacenters. Customers are provided with strong guarantees that their keys cannot leave the boundary of certified HSMs, and that their keys cannot be accessed by malicious persons or insiders. Permissions on key resources are managed with IAM.

Update

The document [1] provided by AMD is a technical preview. It shouldn't be considered as an established standard. That is why the cloud providers are not required to strictly follow this specification, and the offering "Confidential VM" based on a technical preview is reasonably in Beta.

For those who is concerned in verifying the platform by following the example implementation from the AMD's technical preview, Google provides a validation mechanism

Google Cloud > Confidential VM > Doc > Validating Confidential VMs using Cloud Monitoring :

Cloud Monitoring and Cloud Logging let you monitor and validate your Confidential VM instances.
Integrity monitoring is a feature of both Shielded VM and Confidential VM that helps you understand and make decisions about the state of your VM instances.
You can view integrity reports in Cloud Monitoring and set alerts on integrity failures . You can review the details of integrity monitoring results in Cloud Logging.
Confidential VM generates a unique type of integrity validation event, called a launch attestation report event . Every time an AMD Secure Encrypted Virtualization (SEV) -based Confidential VM boots, a launch attestation report event is generated as part of the integrity validation events for the VM.

AMD SEV does not deal with the generation of disk encryption keys. Within the CSEK approach the keys are generated by the customer. The AMD SEV role is to provide a safe environment with the encrypted memory in order to protect the customer supplied key while in use . To safely encrypt memory, AMD SEV relies on the 2nd Gen AMD EPYC™ processors. "These keys are generated by the AMD Secure Processor during VM creation and reside solely within it , making them unavailable to Google or any VMs running on the host ."

Please see links below for more details:
Google Cloud Blog > Introducing Google Cloud Confidential Computing with Confidential VMs
Google Cloud > Confidential VM > Doc > Confidential VMs and Compute Engine
Google Cloud > Compute Engine > Doc > Encrypt disks with customer-supplied encryption keys
SUSE > AMD Secure Encrypted Virtualization (AMD-SEV) Guide

Answer 2

mebius99's answer is correct. I think, based on your reply, that you expect something unique for Confidential VMs. This is not the case, and ultimately why Confidential VMs are so powerful...you don't need to drastically change your existing tooling/orchestration. Google's implementation is flexible so you can use disk encryption in a variety of ways... But Google does not allow users to give the LAUNCH_SECRET per the AMD doc.

I don't think this is "going against the spec", Appendix A of the AMD spec says

The following flow charts are provided to illustrate how the usage of the SEV API might be implemented. Note that these are only examples and there may be other implementation strategies.

Unless I am completely missing the boat on what you are asking...

Answer 3

I totally agree with Nico. One way would be to extract PDH and PEK keys from Confidential VM but so far, I have not found any way to do this.