对分拆机器进行远程证明

本页内容的上次更新时间为 2024 年 5 月，代表截至本文撰写之时的状况。由于我们会不断改善对客户的保护机制，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 数据中心机器建立安全连接。