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

【问题标题】：How is the Disk Encryption Key generated by the guest owner in Google confidential VMs?来宾所有者在 Google 机密虚拟机中如何生成磁盘加密密钥？
【发布时间】：2020-07-29 20:30:51
【问题描述】：

根据 AMD SEV API 规范 [1]，来宾所有者对 AMD 平台进行身份验证并验证启动的 VM 来宾的完整性测量，然后加密磁盘加密密钥并将其发送给来宾（此流程显示在附录 A）中。但是，在搜索 Google 机密 VM [2] 的文档时，我找不到任何有关验证平台或将打包的磁盘加密密钥发送给来宾的信息。

我的具体问题是：在 Google Confidential VM 实施中，由哪一方生成磁盘加密密钥？来宾所有者如何验证启动并生成磁盘加密密钥？如果密钥是由平台提供商控制下的固件生成的，在这种情况下是谷歌云平台（GCP），那么用户不会从 GCP 内部人员那里获得任何额外的安全/隐私保护（如文档 [2] 中所述）。

附：文档中的一个错误：为了获得支持，建议使用“confidential-vm-tag”[3] 在 Stack Overflow 上发布，但是，截至 2020 年 7 月 29 日，不存在这样的标签。

[1] AMD 安全加密虚拟化 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

【问题讨论】：

尝试为您添加标签，但需要评分为 1500 或以上的人
@RobEvans - 我创建了标签并将其添加到问题中。
Google 可以为您管理密钥 (CMEK)，或者您可以自己提供密钥 (CSEK)。 cloud.google.com/compute/docs/disks/customer-managed-encryption 和 cloud.google.com/compute/docs/disks/…

标签： google-cloud-platform confidential-vm-tag

【解决方案1】：

mebius99 的回答是正确的。我认为，根据您的回复，您期望机密虚拟机有一些独特的东西。事实并非如此，这也是机密虚拟机如此强大的最终原因……您无需彻底改变现有的工具/编排。 Google 的实施非常灵活，因此您可以通过多种方式使用磁盘加密……但 Google 不允许用户根据 AMD 文档提供 LAUNCH_SECRET。

AMD 规范的附录 A 说，我不认为这“违反规范”

提供以下流程图来说明如何使用的 SEV API 可能会被实现。请注意，这些只是示例并且可能还有其他实施策略。

除非我完全错过了你所要求的内容......

【讨论】：

机密虚拟机不能以任何方式“强大”，除非来宾有办法验证（称为“证明”）它们的完整性，否则通过机密虚拟机 GCP 只会增加一层间接而不实际提高用户安全性（或启用新用例）。

【解决方案2】：

技术上，问题的答案取决于选择了三种可用方法中的哪一种：

Google 管理的密钥；
客户管理；
客户提供。

实际上，数据保护问题很少纯粹是技术问题。关键点是客户与云提供商之间的数据敏感度级别以及数据保护和隐私协议。换句话说，客户是否可以在数据保护方面信任 Google，或者由于现有的合规政策，云被认为是一个敌对的环境。

Google 管理的密钥（默认）。 Google 使用其基础架构自动为客户生成和管理密钥。客户无法控制加密密钥。
客户管理的密钥 (CMEK)。 Google 使用其基础架构为客户创建、维护和轮换密钥。但是 CMEK 让客户通过Cloud KMS 控制密钥。用于 CMEK 的 KMS 是一项云托管服务，可帮助客户确保加密密钥的生命周期：生成、轮换、禁用、撤销。因此，客户可以更好地控制受保护的数据，因为例如，客户可以通过禁用或销毁 CMEK 密钥来快速终止对数据的访问。
客户提供的密钥 (CSEK)。使用客户拥有的密钥对数据进行加密。这些密钥不会发送给 Google，而是在 Google Cloud Platform 之外存储和管理。密钥维护、轮换和弃用是客户的责任。

客户管理或客户提供的密钥的缺点是，由于无意删除或丢失密钥，可能会丢失对加密数据的访问。

Cloud HSM。加密密钥可以安全地存储在 Google 数据中心内完全托管的硬件安全模块中。向客户提供强有力的保证，即他们的密钥不会离开经过认证的 HSM 的边界，并且他们的密钥不会被恶意人员或内部人员访问。关键资源的权限由 IAM 管理。

更新

AMD 提供的文档[1] 是技术预览版。它不应被视为既定标准。这就是为什么云提供商不需要严格遵守这个规范，并且基于技术预览的“机密虚拟机”产品合理地处于测试阶段。

对于那些关注通过 AMD 技术预览中的示例实现来验证平台的人，Google 提供了一种验证机制

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

Cloud Monitoring 和 Cloud Logging 可让您监控和验证您的机密虚拟机实例。
完整性监控是两者的一个特点受保护的 VM 和机密 VM，可帮助您了解和制作决定您的虚拟机实例的状态。
您可以查看 Cloud Monitoring 中的完整性报告并设置完整性警报失败。您可以查看完整性监控结果的详细信息在 Cloud Logging 中。
机密虚拟机生成一种独特类型的完整性验证事件，称为启动证明报告事件。每次 AMD 安全加密虚拟化 (SEV) - 基于机密虚拟机启动时，会生成启动证明报告事件作为虚拟机完整性验证事件的一部分。

AMD SEV 不处理磁盘加密密钥的生成。在 CSEK 方法中，密钥由客户生成。 AMD SEV 的作用是为加密内存提供一个安全的环境，以便在使用时保护客户提供的密钥。为了安全地加密内存，AMD SEV 依赖于第二代 AMD EPYC™ 处理器。 “这些密钥由 AMD 安全处理器在虚拟机创建过程中生成并且仅驻留在其中，这使得它们对 Google 或主机上运行的任何虚拟机都不可用强>。”

【讨论】：

感谢您的评论，但它实际上并没有回答我的问题，因为我专门询问机密虚拟机 - 在这种情况下，虚拟机所有者应在启动虚拟机时立即提供密钥验证 AMD 服务器平台的真实性，但 Google 实现（至少如文档中所述）似乎不遵循 AMD SEV API 规范。
已更新答案以更好地解决问题。
感谢您的更新。我重新访问了 GCP 文档，然而，它自最初发布以来并没有太大变化。 SEV API 规范不能也不太可能成为“标准”（不打算），因为它是专有文档。本质上，GCP 的“机密虚拟机”产品不会以任何方式限制或减少访客所有者对 GCP 的信任，除非至少满足以下条件：访客所有者可以证明VM 实例的完整性（通过与 SEV 固件的直接通信，而不是通过检查控制台日志）。