对已分解的机器进行远程证明

本页内容的上次更新时间为 2022 年 12 月，代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制，Google 的安全政策和系统今后可能会发生变化。

本文档介绍了 Google 的数据中心机器证明方法。本文档中介绍的架构旨在与可信平台模块 (TPM)、安全协议和数据模型 (SPDM)、Redfish 等开放标准集成。如需了解 Google 提出且与数据中心机器证明相关的新标准或参考实现，请参阅 GitHub 中的平台完整性 (PINT) 项目。本文档面向安全高管、安全架构师和审核人员。

概览

Google 越来越多地设计和部署分散的数据中心机器。许多机器包含单独的信任根（包括用于衡量 (RTM) 的信任根、存储、更新和恢复），而不是单个信任根。每个 RTM 都为整个机器提供一部分服务。例如，一台机器可能有一个 RTM 用于测量和证明在主 CPU 上启动的内容，而另一个 RTM 用于测量和证明在插入 PCIe 槽的 SmartNIC 上启动的内容。下图展示了一个示例机器。

示例机器。

机器中多个 RTM 的复杂性增加了数据中心机器的庞大规模和预期，以及人为、硬件或软件故障可能导致的许多复杂性。总而言之，确保舰队的固件完整性非常重要。

本文档中介绍的系统旨在使分解机器的远程证明问题更易于管理。此证明基础架构可扩展，从而能够为数据中心内更为复杂的机器提供服务。

通过共享这项工作，我们的目标是深入了解如何大规模完成分解的机器证明。通过与行业合作伙伴合作以及对分布式管理任务组 (DMTF)、可信计算组 (TCG) 和开放计算项目 (OCP) 等标准机构的贡献，我们打算继续支持安全创新能力。

远程证明操作

证明方案旨在确保用户数据和作业仅发布到运行预期启动堆栈的机器，同时仍允许大规模进行机群维护自动化以解决问题。在我们的内部云中托管的作业调度器服务可能会挑战机器中的 RTM 收集，并将生成的证明测量结果与该机器独有的政策进行比较。仅当证明的测量结果符合机器政策时，调度器才会向机器颁发作业和用户数据。

远程证明包含以下两项操作：

证明政策生成，每当机器的预期硬件或软件发生更改时就会生成。
证明验证，发生在机器管理流程中定义的时间点。其中一个时间点正好在安排到机器上之前。该机器仅在证明验证通过后才能访问作业和用户数据。

证明政策

Google 使用签名的机器可读文档（称为政策）来描述预计在机器中运行的硬件和软件。此政策可以通过机器的 RTM 集合证明。每个 RTM 的以下详细信息表示在政策中：

可信的身份根证书，可验证 RTM 发出的证明。
唯一标识 RTM 的全局唯一硬件身份。
固件身份，描述了 RTM 应运行的预期版本。
RTM 报告的每个启动阶段的测量结果预期。
RTM 的标识符，类似于 Redfish 资源名称。
将 RTM 与其在机器中的物理位置相关联的标识符。此标识符类似于 Redfish 资源名称，供自动化机器修复系统使用。

此外，该政策还包含一个全局唯一的撤消序列号，有助于防止未经授权的政策回滚。下图展示了一项政策。

证明政策示例。

下图显示了政策中的以下各项：

该签名提供政策身份验证。
撤消序列号提供政策新鲜度，有助于防止回滚。
RTM 预期枚举机器中每个 RTM 的详细信息。

下面几个部分将详细介绍这些内容。

政策组合

组装或维修机器的硬件时，系统会创建硬件模型来定义该机器上所有预期的 RTM。我们的控制平面有助于确保此信息在涉及部分交换或硬件升级的修复等事件中保持最新。

此外，控制平面对要安装在机器上的软件有一套预期，以及哪些 RTM 应该测量哪些软件。控制平面使用这些预期以及硬件模型来生成签名且可撤消的证明政策，用于描述机器的预期状态。

签名政策随后会写入其描述的机器上的永久性存储空间。这种方法有助于减少远程验证器在证明机器时所需的网络和服务依赖项的数量。验证器可以从机器本身提取政策，而不是查询数据库的政策。这种方法是一项重要的设计功能，因为作业调度器具有严格的 SLO 要求，并且必须保持高可用性。减少这些机器在其他服务中的网络依赖项有助于降低服务中断的风险。下图显示了此事件流。

政策组合流程。

该图描述了控制平面在政策组合过程中完成的步骤：

从软件包分配和机器硬件模型派生证明政策。
为政策签名。
将政策存储在数据中心机器上。

政策撤消

给定机器的硬件和软件意图会随着时间的推移而变化。当意图发生变化时，必须撤消旧政策。每个签名的证明政策都包含唯一的撤消序列号。验证者获取适当的公钥来对签名政策进行身份验证，并获取适当的证书吊销列表，以确保政策仍然有效。

以交互方式查询密钥服务器或撤消数据库会影响作业调度器的可用性。Google 使用异步模型。用于对签名证明政策进行身份验证的一组公钥将作为每台机器的基本操作系统映像的一部分进行推送。CRL 使用 Google 用于其他凭据类型的同一集中式撤消部署系统异步推送。该系统经过专门设计，可在正常情况下可靠地运行，能够在突发事件响应期间执行快速紧急推送。

通过使用验证者机器上本地存储的验证公钥和 CRL 文件，验证者可以从远程机器验证证明语句，而无需关键路径中的任何外部服务。

检索证明政策和验证测量结果

远程证明机器的过程包括以下阶段：

检索和验证证明政策。
从机器的 RTM 获取证明的测量结果。
根据政策评估已证明的测量结果。

下图和各部分进一步介绍了这些阶段。

远程证明阶段。

检索和验证证明政策

远程验证器检索机器的签名证明政策。如政策组合中所述，出于可用性的原因，该政策会以目标文档的形式存储在目标机器上。

为了验证返回的政策是否真实，远程验证器会查询验证者相关 CRL 的本地副本。此操作有助于确保检索到的政策由可信实体进行加密签名，并且政策未被撤消。

获取证明的测量结果

远程验证器验证机器，要求每个 RTM 提供测量结果。验证器在这些请求中包含加密随机数，以确保新鲜度。机器实体（例如基板管理控制器 (BMC)）会将每个请求路由到其各自的 RTM，收集签名响应，并将其发送回远程验证器。从证明的角度来看，此机器内实体没有权限，因为它只能用作 RTM 有符号测量值的传输。

Google 使用内部 API 对测量结果进行证明。我们还对 Redfish 进行了改进，让机器外验证器能够使用 SPDM 挑战 BMC 进行 RTM 测量。内部机器路由通过特定于实现的协议和渠道完成，包括：

子网上的 Redfish
智能平台管理接口 (IPMI)
基于 i2c/i3c 的管理组件传输协议 (MCTP)
PCIe
串行外设接口 (SPI)
USB

评估证明的测量结果

Google 的远程验证器会验证每个 RTM 发出的签名，从而确保它们以根用户身份返回到机器的证明政策中包含的 RTM 身份。RTM 证书链中存在的所有硬件和固件身份都根据该政策进行验证，从而确保每个 RTM 都是正确的实例并运行正确的固件。为确保新鲜度，系统会检查签名加密随机数。最后，对证明的测量结果进行评估，以确保其符合设备的政策预期。

对远程证明结果做出响应

证明完成后，结果必须用来确定正在证明的机器的命运。如图所示，有两种可能的结果：证明成功，机器获得任务凭据和用户数据，或者证明失败并将提醒发送到修复基础架构。

远程证明结果。

以下部分详细介绍了这些过程。

失败的证明

如果机器的证明失败，则 Google 不会使用该机器来处理客户作业。相反，系统会向修复基础架构发送提醒，它会尝试自动重装机器映像。虽然证明失败可能是由恶意意图造成的，但大多数证明失败都是软件发布中的 Bug 造成的。因此，具有不断证明失败的发布会自动停止，以防止更多机器未通过证明。此事件发生时，系统会向 SRE 发送提醒。对于未由自动重新修复功能修复的机器，此类发布会回滚，或者发布固定软件。在机器再次成功进行远程证明之前，该机器不会用于处理客户作业。

成功的证明

如果机器的远程证明成功，Google 会使用该机器来提供生产作业，例如 Google Cloud 客户的虚拟机或 Google 相册的图片处理。Google 要求所有涉及网络服务的有意义的作业操作都受到短期 LOAS 任务凭据的控制。这些凭据会在成功的证明验证后通过安全连接授予，并提供作业所需的权限。如需详细了解这些凭据，请参阅应用层传输安全。

软件证明只有在构建该软件的基础架构时才能发挥作用。为了帮助确保生成的工件能够准确反映我们的意图，我们在构建流水线的完整性方面投入了大量资金。如需详细了解 Google 提出的关于软件供应链完整性和真实性的标准，请参阅软件供应链完整性。

后续步骤

了解 BeyondProd 如何帮助 Google 数据中心机器建立安全连接。