Google 如何在生产机器上强制执行启动完整性

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

本文档介绍了 Google 用于在配备 Titan 的生产机器上强制执行启动过程完整性的基础架构控制措施。这些控制措施是在测量启动过程的基础上构建的，有助于确保 Google 能够从整个启动堆栈中的漏洞中恢复数据中心机器，并将计算机从任意启动状态返回到已知的良好配置。

简介

数据中心机器的安全状况在很大程度上取决于机器在启动时的配置。机器的启动过程会配置机器的硬件并初始化其操作系统，同时确保机器能够在 Google 的生产环境中安全运行。

在启动过程的每个步骤中，Google 都会实施业界领先的控制措施，以强制实施我们预期的启动状态并帮助确保客户数据安全。这些控制措施有助于确保我们的机器能够启动其预期软件，从而使我们能够移除可能会损害机器初始安全状况的漏洞。

本文档介绍了启动过程，并说明了我们的控制措施在启动流程中如何运作。我们的控制措施的主要目标如下：

背景

本部分定义以下术语并提供相关上下文：机器凭据、硬件信任根、密封凭据和加密密封。

机器凭据

Google 机器管理系统中的一个核心组件是我们的凭据基础架构，它由内部证书授权机构 (CA) 和负责协调凭据轮替流程的其他控制平面元素组成。

Google 生产机群中的机器在建立安全信道时执行双向身份验证。为了执行双向身份验证，每台机器都拥有 Google 的 CA 公钥。每台机器还具有自己的公钥/私钥对，以及该密钥对的证书。

每台机器的公钥/私钥对以及由 CA 签名的证书都称为“机器凭据”，机器将该凭据用于向机群中的其他机器验证自己的身份。在生产网络中，机器在交换流量之前会检查其他机器的公钥是否经过 Google 的 CA 认证。

硬件信任根和加密密封

随着计算设备的日益复杂，每台设备的攻击面也会扩大。考虑到这一点，设备越来越多地配备了硬件信任根 (RoT)，这是小型可信执行环境，可保护机器的敏感数据。RoT 也出现在笔记本电脑或手机等移动设备中，以及桌面设备 PC 等更传统的设备上。

Google 的数据中心机器具有 Google 设计的定制硬件信任根，这些信任根集成到了每台机器的深层（称为 Titan）。 我们使用 Titan 以及加密密封机制，以确保每台机器都在运行我们预期的配置和软件版本。

加密密封是 Titan 提供的一项服务，用于保护秘密。Titan 的密封功能类似于由可信计算组发布的可信平台模块 (TPM) 规范中的功能。 Titan 的加密封装还有一个额外优势，即 Titan 提高了对低级固件的测量和证明能力。

加密密封由以下两项控制措施组成：

  • 敏感数据加密
  • 解密数据前必须满足的政策

密封凭据

Google 的凭据基础架构使用加密密封，通过由机器的硬件信任根控制的密钥对静态机器凭据进行加密。加密的凭据私钥和相应的证书称为密封凭据。除了机器凭据之外，Google 还使用此密封机制来保护其他敏感数据。

每台机器只有在能够满足指定机器必须启动的软件的解密政策时，才可以解密并访问其机器凭证。例如，将机器的凭证密封到用于指定所需操作系统内核版本的政策，可确保机器无法参与其机器集群，除非该机器启动了所需的内核版本。

解密政策通过名为测量启动的过程强制执行。 启动堆栈中的每个层均测量下一层，机器在启动结束时证明此测量链。此测量结果通常是一个加密哈希。

凭据密封过程

本部分介绍 Google 机器使用的凭据密封和测量启动过程。下图演示了此流程。

凭据密封流程。

如需将机器的凭据密封到特定的启动政策，请执行以下步骤：

  1. Google 的机器自动化基础架构会在机器上启动软件更新。它将预期的软件版本传递给凭据基础架构。
  2. Google 的凭据基础架构会从 Titan 请求一个密封密钥，这受到政策的限制，这样 Titan 只有在机器启动到其预期软件时才使用它。
  3. 凭据基础架构会将返回的密钥政策与机器自动化基础架构传达的意图进行比较。如果凭据基础架构确信政策与意图匹配，则会向机器颁发经过认证的机器凭据。
  4. 凭据基础架构使用第 2 步中获得的封装密钥来加密此凭据。
  5. Titan 会在磁盘上存储加密的凭据，以便在后续启动时进行解密。

测量启动过程

Google 机器的启动堆栈由四个层组成，如下图所示。

测量启动过程的四层。

层级如下：

  • 用户空间：守护程序或工作负载等应用。
  • 系统软件：Hypervisor 或内核。最低级别的软件，为用户空间提供对网络、文件系统或虚拟内存等硬件功能的抽象概念。
  • 启动固件：初始化内核的固件，例如 BIOS 和引导加载程序。
  • 硬件信任根：在 Google 机器中为以加密方式衡量固件和其他低层级 CPU 服务的 Titan 芯片。

在整个启动过程中，每一层都会先测量下一层，然后再将控制措施传递给该层。仅当在启动期间捕获的所有测量结果都符合 Google 的凭据基础架构指定的密集型解密政策时，机器的密封凭据才可供操作系统使用。因此，如果机器可以使用其密封凭据执行操作，则可以证明该机器满足其测量启动政策。此过程的形式是一种隐式证明。

如果机器启动偏离预期状态的软件，则该机器无法使用在机群中运行所需的凭据来解密和执行操作。在机器管理基础架构触发自动修复操作之前，此类机器无法参与工作负载调度。

从内核中的漏洞进行恢复

假设一台机器运行的是内核版本 A，但安全研究人员发现此内核版本存在漏洞。在这些情况下，Google 会修补漏洞，并向机群发布更新后的内核版本 B。

除了修补漏洞之外，Google 还会向机群中的每台机器颁发新的机器凭据。如凭据密封过程中所述，新的机器凭据受限于解密政策，该政策仅在内核版本 B 在机器上启动时才满足。任何未运行其预期内核的机器都无法解密其新机器凭据，因为启动固件测量结果将不满足该机器的启动政策。在此过程中，旧的机器凭据也会被撤消。

因此，除非更新内核以符合控制平面的意图，否则这些机器将无法参与其机器集群。这些控制措施有助于确保运行易受攻击的内核版本 A 的机器在升级到内核版本 B 之前无法接收作业或用户数据。

从启动固件中的漏洞恢复

假设启动固件中存在漏洞，而不是操作系统内核。从内核中的漏洞进行恢复中介绍的相同控制措施可帮助 Google 从此类漏洞中恢复。

Google 的 Titan 芯片会在机器运行之前测量其启动固件，以便 Titan 可以确定启动固件是否符合机器凭据的启动政策。任何未运行预期启动固件的机器都无法获得新的机器凭据，并且该机器无法参与其机器集群，直到其启动固件符合控制平面的意图。

从信任根固件中的漏洞恢复

RoT 并非不受漏洞影响，但 Google 的启动控制甚至可以在 RoT 自己的可变代码内的启动堆栈的这一层从错误中恢复。

Titan 的启动堆栈实现了自己的安全测量启动流程。在 Titan 芯片启动时，其硬件会以加密方式测量 Titan 的引导加载程序，而后者又会测量 Titan 的固件。与机器的内核和启动固件类似，Titan 固件使用版本号进行加密签名。Titan 的引导加载程序会验证签名并提取 Titan 固件的版本号，将版本号提供给 Titan 的基于硬件的密钥派生子系统。

Titan 的硬件子系统实现了有版本控制的密钥派生方案，因此版本为 X 的 Titan 固件可以获取绑定到低于或等于 X 的所有版本的芯片唯一密钥。Titan 硬件支持版本为 X 的固件访问绑定到版本小于或等于 X 但不超过 X 的密钥。封装到 Titan 的所有 Secret（包括机器凭据）均使用版本控制的密钥进行加密。

每个 Titan 芯片的证明和密封密钥都是唯一的。唯一的密钥让 Google 只能信任预期会在 Google 数据中心中运行的 Titan 芯片。

下图显示了使用版本密钥的 Titan。版本 X+1 密钥无法通过版本 X 固件访问，但任何早于此版本的密钥均可访问。

Titan 版本。

如果 Titan 固件中出现严重漏洞，Google 会发布一个版本号更高的补丁，然后颁发绑定到更高 Titan 固件版本的新机器凭据。任何易受攻击的旧版 Titan 固件都无法解密这些新凭据。因此，如果机器在生产环境中使用新凭据执行操作，Google 即可确信该机器的 Titan 芯片启动了最新的 Titan 固件。

确保信任根真实性

本文档中介绍的控制措施均由硬件 RoT 本身的功能决定。Google 的凭据基础架构依赖于这些 RoT 发出的签名，以了解机器是否正在运行预期的软件。

因此，凭据基础架构可以确定硬件 RoT 是否真实可信，以及 RoT 是否正在运行最新的固件。

每个 Titan 芯片在制造时都采用唯一的熵。 Titan 的低级启动例程会将熵转换为设备唯一的键。Titan 制造线上的安全元素认可此芯片唯一的密钥，以便 Google 将其识别为合法的 Titan 芯片。

下图说明了此背书流程。

Titan 背书流程。

在生产环境中，Titan 使用其设备专属密钥来批准其发出的任何签名。Titan 芯片使用的流程类似于设备标识符组合引擎 (DICE)。背书包含 Titan 固件的版本信息。此证明有助于防止攻击者模拟由 Titan 芯片发出的签名，以及回滚到较旧的 Titan 固件，以及模拟较新的 Titan 固件。这些控制措施可帮助 Google 验证从 Titan 接收的签名是否由运行真实的 Titan 固件的真实 Titan 硬件发出。

基于启动完整性构建

此白皮书介绍了确保机器的应用处理器启动预期代码的机制。这些机制依赖于测量启动流程，并与硬件信任根耦合。

Google 的威胁模型包括攻击者可能会物理干预 CPU 和 RoT 之间的总线，其目标是不当获取机器的解密凭据。为了帮助最大限度地降低这种风险，Google 正在推动开发一个基于标准的方法，以击败活跃的干预者，将来自可信计算组的 TPM 和 DPE API 以及 Caliptra 集成信任根结合在一起。

后续步骤

作者：Ed Andersen、Kevin Plybon