应用层传输安全

作者：Cesar Ghali、Adam Stubblefield、Ed Knapp、Jiangtao Li、Benedikt Schmidt、Julien Boeuf

本文包含的内容截至 2017 年 12 月是正确无误的。本白皮书代表截至撰文之时的现状。随着我们持续改善对客户的保护机制，Google Cloud 的安全政策和系统未来可能会发生变化。

面向首席信息官级别领导者的摘要

• Google 的应用层传输安全 (ALTS) 是由 Google 开发的双向身份验证和传输加密系统，通常用于在 Google 基础架构内部保护远程过程调用 (RPC) 通信的安全。ALTS 在概念上与双向验证身份的 TLS 类似，但 ALTS 经过了专门的设计和优化，以满足 Google 数据中心环境的需求。
• ALTS 信任模型已针对类似云的容器化应用进行了特别定制。身份与实体而非特定服务器名称或主机绑定。此信任模型有助于实现各主机之间的无缝微服务复制、负载平衡和重新安排。
• ALTS 依赖于两种协议：握手协议（具备会话恢复功能）和记录协议。这些协议控制会话的建立、验证、加密和恢复的方式。
• ALTS 是我们在 Google 使用的自定义传输层安全解决方案。我们针对自己的生产环境定制了 ALTS，因此在 ALTS 和行业标准 TLS 之间存在一些权衡取舍更多详情请参阅权衡部分。

简介

Google 的生产系统由数量庞大的微服务¹组成，这些微服务每秒会发出 O(10¹⁰) 个远程过程调用 (RPC)。当 Google 工程师安排生产工作负载²时，默认情况下，该工作负载发出或接收的任何 RPC 都受 ALTS 保护。这种零配置的自动保护由 Google 的应用层传输安全 (ALTS) 提供。除了自动保护 RPC 外，ALTS 还可以简化生产机器之间的服务复制、负载平衡以及重新安排。本文将对 ALTS 进行介绍，并探讨其在 Google 生产基础架构上的部署。

受众群体：本文档面向有兴趣了解 Google 内部如何大规模执行身份验证和传输安全机制的基础架构安全专业人员。

前提条件：除了本简介之外，我们还假定读者对 Google 的集群管理有基本的了解。

应用级安全协议和 ALTS

从网络浏览器到 VPN，许多应用依赖传输层安全协议 (TLS) 和 IPSec 之类的安全通信协议来保护数据在传输过程中的安全³。Google 使用在应用层运行的双向身份验证和传输加密系统 ALTS 来保护 RPC 通信。使用应用级安全协议允许应用获得经过身份验证的远程对等身份，可用于实现精细的授权政策。

为什么不选择 TLS？

鉴于当前大多数互联网流量都使用 TLS 进行加密，Google 使用 ALTS 这样的自定义安全解决方案似乎有些不太寻常。Google 于 2007 年开始开发 ALTS。当时，TLS 还支持许多不符合我们的最低安全标准的旧式协议。在设计我们的安全解决方案时，我们本可以采用需要的 TLS 组件，然后在其基础上实现我们想要的组件；然而，从头开始构建更适合 Google 的系统的优势超过了修补现有系统能带来的好处。此外，ALTS 与我们的需求更契合，且一直比更早出现的 TLS 更加安全。下面列出了 TLS 和 ALTS 之间的主要区别。

• 采用 HTTPS 语义的 TLS 的信任模型⁴与 ALTS 的信任模型之间存在着显著差异。在 TLS 中，服务器身份与特定名称及相应的命名方案绑定。在 ALTS 中，同一身份可以与不同的命名方案搭配使用。这种间接关系提供了更大的灵活性，并极大地简化了各主机之间微服务复制、负载平衡和重新安排的过程。
• 与 TLS 相比，ALTS 的设计和实现更简洁。因此，使用源代码手动检查或大量模糊测试可以更轻松地监控错误和安全漏洞。
• ALTS 使用 Protocol Buffer 来序列化其证书和协议消息，而 TLS 使用以 ASN.1 编码的 X.509 证书。我们的大多数生产服务使用 Protocol Buffers 进行通信（有时是存储），使得 ALTS 更适合 Google 的环境。

ALTS 设计

ALTS 旨在成为一个高度可靠、值得信赖的系统，让客户只需执行少量操作即可进行服务到服务身份验证，并保障安全性。为实现这一目标，ALTS 的设计考虑了下列属性：

• 透明度：ALTS 配置对应用层是透明的。 默认情况下，服务 RPC 受到 ALTS 的保护。这使应用开发者可以专注于服务的功能性逻辑，而无需担心凭据管理或安全配置。在服务到服务连接建立期间，ALTS 为应用提供经过身份验证的远程对等身份，此身份可用于精细的授权检查和审核。
• 先进的加密技术：ALTS 使用的所有加密原语和协议都是可抵御已知攻击的最新版本。ALTS 在 Google 控制的机器上运行，这意味着所有受支持的加密协议都可以实现轻松升级和快速部署。
• 身份模型：ALTS 主要通过身份而非主机名执行身份验证。在 Google，每个网络实体（例如企业用户、物理机器或生产服务/工作负载）都具有相关联的身份。服务之间的所有通信都需要进行相互验证。
• 密钥分发：ALTS 需要每个工作负载都具有特定身份，该身份表示为一组凭据。这些凭据在初始化期间部署在每个工作负载中，无需用户进行操作。同时，系统将为机器和工作负载针对这些凭据建立信任根和信任链。该系统允许自动证书轮换和撤消，而无需应用开发者进行操作。
• 可伸缩性：ALTS 设计注重极高的可伸缩性，以支持 Google 基础架构的庞大规模。为满足此要求，我们开发了高效的会话恢复功能。
• 长期有效的连接：经过身份验证的密钥交换加密操作在计算成本上非常昂贵。为了适应 Google 基础架构的规模，在初始 ALTS 握手之后，连接将持续较长时间以提高整体系统性能。
• 简洁：TLS 默认支持旧协议且具有向后兼容性。由于 Google 同时控制客户端和服务器，而且我们将两者均设计为原生支持 ALTS，因此 ALTS 的简洁度显著提升。

ALTS 信任模型

ALTS 主要通过身份而非主机执行身份验证。在 Google，每个网络实体（例如企业用户、物理机器或生产服务）都具有相关联的身份。这些身份嵌入在 ALTS 证书中，并在安全连接建立期间用于相应的身份验证。我们追求的模式是，我们的生产服务应作为生产实体运行，可由我们的网站可靠性工程师 (SRE) 管理⁵。这些生产服务的开发版本作为测试实体运行，可由 SRE 和开发者管理。

例如，假设我们的某产品包含两项服务：service-frontend 和 service-backend。SRE 可以发布这些服务的生产版本：service-frontend-prod 和 service-backend-prod。开发者可以构建和发布这些服务的开发版本（service-frontend-dev 和 service-backend-dev）以进行测试。生产服务中的授权配置将配置为不信任该服务的开发版本。

ALTS 凭据

ALTS 凭据有三种类型，所有类型都以协议缓冲区消息格式表示。

• 主证书：由远程签名服务签名，用于验证握手证书。主证书包含与主私钥相关联的公钥，例如 RSA 密钥对。此私钥用于对握手证书进行签名。当与下面讨论的 ALTS 策略搭配使用时，这些证书本质上属于受限的中间证书颁发机构 (CA) 证书。主证书通常针对生产机器和容器化工作负载的调度器（例如 Borgmaster⁶）而颁发。
• 握手证书：由主私钥在本地创建并签名。此证书包含 ALTS 握手（安全连接建立）期间使用的参数，例如静态 Diffie-Hellman (DH) 参数和握手密码。此外，握手证书还包含来源主证书，即与签署握手证书的主私钥关联的证书。
• 恢复密钥：用于加密恢复票证的密钥。此密钥由恢复标识符 ID_R 标识，在同一数据中心单元内使用同一身份运行的所有生产工作负载都共用一个专属的标识符。如需详细了解 ALTS 中的会话恢复功能，请参阅会话恢复。

图 1 显示了由签名服务验证密钥、主证书和握手证书组成的 ALTS 证书链。签名服务验证密钥是 ALTS 中的信任根，在我们生产和企业网络中的所有 Google 机器上均有安装。

图 1：ALTS 证书链

在 ALTS 中，签名服务对主证书进行验证，而主证书又对握手证书进行验证。由于握手证书的创建频率高于主证书，上述体系结构可减少签名服务的负载。Google 经常轮换证书，特别是握手证书⁷。握手证书所携带的静态密钥交换对是静态的，而频繁轮换可以弥补这种不足⁸。

证书颁发

为了参与 ALTS 安全握手，需要为网络上的实体预配握手证书。首先，颁发者获得由签名服务进行签名的主证书，并可以视情况将其传递给实体。然后，创建握手证书并由关联的主私钥签名。

通常，颁发者是向机器和人员颁发证书的内部证书授权机构 (CA)，或者是向工作负载颁发证书的 Borgmaster。但是，它可以是任何其他实体，例如数据中心测试单元的受限 Borgmaster。

图 2 显示了如何使用签名服务创建主证书。此过程包括以下步骤。

图 2：证书颁发

1. 证书颁发者向签名服务发送证书签名请求 (CSR)。此请求要求签名服务为身份 A 创建证书。例如，该身份可以是企业用户或 Google 生产服务的身份。
2. 签名服务将证书的颁发者（包含在 CSR 中）设置为请求者（在本例中为证书颁发者）并对证书进行签名。大家应该还记得，所有 Google 机器上都安装了相应的签名服务公开（验证）密钥。
3. 签名服务将签名后的证书返回。
4. 为身份 A 创建握手证书，并由与私钥关联的主证书签名

如上面的流程所示，对于 ALTS 而言，证书的颁发者和签名者是两个不同的逻辑实体。在这种情况下，颁发者是证书发行者实体，而签名者是签名服务。

ALTS 中有三种常见的证书类别，分别为自然人、机器和工作负载。下面的部分概述了如何在 ALTS 中创建和使用这三类证书。

自然人证书

在 Google，我们使用 ALTS 来保护自然人用户向生产服务发送的 RPC。为了发送 RPC，用户必须提供有效的握手证书。例如，如果小丽想要使用应用发出受 ALTS 保护的 RPC，她可以向我们的内部 CA 进行身份验证。小丽可以使用其用户名、密码以双重身份验证方式向 CA 进行身份验证。此操作将使小丽获得有效期为 20 小时的握手证书。

机器证书

Google 数据中心的每台生产机器都有一个机器主证书。每种证书均可用于为相应机器上的核心应用创建握手证书，例如机器管理守护程序。嵌入在机器证书中的主要身份是指机器的典型用途。例如，用于运行不同类型的生产和开发工作负载的机器可能具有不同的身份。主证书仅供运行经过验证的软件栈的机器使用；在某些情况下，这种信任植根于自定义安全硬件中⁹。所有生产机器主证书均由 CA 颁发，且每隔几个月会轮换一次。此外，所有握手证书每隔几个小时会轮换一次。

工作负载证书

ALTS 的一个关键优势是它以工作负载身份运行，这有助于简化各机器之间的服务复制、负载平衡和重新安排。在我们的生产网络中，我们使用一个名为 Borg¹⁰ 的系统进行大规模集群管理和机器资源分配。Borg 颁发证书的方式是与机器无关的 ALTS 工作负载身份实现的一部分。

我们的生产网络中的每个工作负载都在相应 Borg 单元中运行。每个单元包含一个名为 Borgmaster 的逻辑集中控制器，以及在该单元中的每台机器上运行的若干名为 Borglet 的代理进程。工作负载由 Borgmaster 颁发的相关工作负载证书进行初始化。图 3 显示了使用 Borg 在 ALTS 中进行工作负载认证的过程。

图 3：Google 生产网络中的握手证书创建

Borgmaster 现在已准备好安排需要使用 ALTS 的工作负载。当客户端将工作负载安排为在 Borg 上作为给定身份运行时，会发生以下步骤。

1. 每个 Borgmaster 都已预安装机器主证书和关联私钥（图中未显示）。
2. ALTSd¹¹ 生成 Borgmaster 握手证书，并使用机器主私钥对其进行签名。此握手证书允许 Borgmaster 颁发受 ALTS 保护的 RPC。
3. Borgmaster 将创建基本工作负载主证书和相应私钥。Borgmaster 发起请求（受 ALTS 保护的 RPC），使该基本工作负载主证书由签名服务进行签名。因此，签名服务将 Borgmaster 列为此证书的颁发者。
4. Borgmaster 验证客户端是否有权以工作负载配置中指定的身份运行工作负载。如果是，Borgmaster 会在 Borglet 上安排 Borg 工作负载，并颁发工作负载握手证书及其相应私钥。此证书由基本工作负载主证书进行链接。然后，工作负载握手证书及其私钥将被安全地传送到 Borglet（通过 Borgmaster 和Borglet 之间的双向身份验证的 ALTS 保护通道）。Borgmaster 大约每两天轮换一次基本工作负载主证书，并重新颁发所有正在运行的工作负载的握手证书。此外，作为同一单元中的同一用户运行的各工作负载会接收由 Borgmaster 预配的同一个恢复密钥和标识符 (ID_R)。
5. 当工作负载需要建立受 ALTS 保护的 RPC时，它使用握手协议中的工作负载握手证书。在启动会话恢复时也会在握手中用到 ID_R。如需详细了解 ALTS 中的会话恢复功能，请参阅会话恢复。

ALTS 政策执行

ALTS 政策是一份文档，其中列出了哪些颁发人有权针对哪些身份颁发特定类别的证书。系统将其分发给我们生产网络中的每台机器。例如，ALTS 政策允许 CA 向机器和自然人颁发证书。它还允许 Borgmaster 向工作负载颁发证书。

我们发现，与证书颁发相比，证书验证期间的政策执行是一种更灵活的方法，因为它允许针对不同类型的部署实施不同的政策。例如，我们可能希望测试集群中的政策比生产集群中的策略更宽松。

在 ALTS 握手期间，证书验证包括 ALTS 政策的检查。该政策确保要验证的证书中列出的颁发者有权颁发相应证书。如果情况并非如此，则证书将遭拒且握手过程将失败。图 4 说明了 ALTS 中的政策执行方式。按照图 2 中的场景，假设小梅（想要升级其权限的企业用户）想要向 Network Admin 颁发主证书。该身份权力很大，可以重新配置网络。毫无疑问，根据 ALTS 政策，小梅无权执行此操作。

图 4：证书颁发和使用

1. 小梅为 Network Admin 身份颁发主证书，并由签名服务签名。这类似于图 2 中的前三个步骤。
2. 小梅使用与创建的主证书关联的主私钥，在本地为 Network Admin 创建握手证书并进行签名。
3. 如果小梅尝试使用创建的握手证书冒充 Network Admin 身份，则小梅尝试与之通信的对等体上的 ALTS 政策 Enforcer 将阻止该操作。

证书撤销

在 Google，证书过期或被列入我们的证书吊销列表 (CRL) 中之后会失效。本部分介绍了 Google 内部证书撤销机制的设计，该机制在撰写本文时仍在处于部署测试阶段。

颁发给自然人企业用户的所有证书都有每日到期时间戳，迫使用户每天重新进行身份验证。颁发给生产机器的许多证书不使用到期时间戳。我们避免依赖时间戳让生产证书过期，由于时钟同步问题，这可能会导致中断。因此，我们使用 CRL 作为证书轮换和突发事件响应处理的可靠来源。图 5 显示了 CRL 的运作方式。

图 5：使用 RevocationID 创建主证书

1. 当我们的 CA 实例初始化后¹²，它会联系 CRL 服务并请求获取撤消 ID 范围。撤销 ID 是 64 位长的 ID，由两个部分组成：一个 8 位证书类别（例如自然人或机器证书）和一个 56 位证书标识符。CRL 服务会选择上述 ID 的特定范围并将其返回给 CA.
2. 当 CA 收到创建主证书请求时，会创建相应证书并嵌入从该范围中选择的撤销 ID。
3. 同时，CA 将把新证书映射到撤销 ID，并将此信息发送到 CRL 服务。
4. CA 颁发主证书。

分配给握手证书的撤销 ID 由证书的使用方式决定。例如，颁发给自然人企业用户的握手证书会继承用户主证书的撤消 ID。对于颁发给 Borg 工作负载的握手证书，撤消 ID 会根据 Borgmaster 的撤消 ID 范围分配。此 ID 范围由 CRL 服务分配给 Borgmaster，其流程类似于图 5 所示。每当对等体参与 ALTS 握手时，它都会检查 CRL 文件的本地副本，以确保远程对等证书未被撤消。

CRL 服务会将所有撤消 ID 收集到单个文件中，该文件可以推送到使用 ALTS 的所有 Google 机器。虽然 CRL 数据库为几百兆字节，但由于使用了各种压缩技术，生成的 CRL 文件只有几兆字节大小。

ALTS 协议

ALTS 依赖于两种协议：握手协议（具备会话恢复功能）和记录协议。本节提供每个协议的简要概览。这些概述不应被解读为协议的详尽规格。

握手协议

ALTS 握手协议是基于 Diffie-Hellman 的认证密钥交换协议，支持完全正向保密 (PFS) 和会话恢复。ALTS 基础架构确保每个客户端和服务器均具备带有各自身份的证书和椭圆曲线 Diffie Hellman (ECDH) 密钥，该密钥将链接到受信任的签名服务验证密钥。在 ALTS 中，默认情况下不启用 PFS，因为即使在握手时未使用 PFS，这些静态 ECDH 密钥也会经常进行正向加密更新。在握手期间，客户端和服务器会安全地协商共享传输加密密钥及将使用该加密密钥进行保护的记录协议。例如，客户端和服务器可能会同意使用 128 位密钥，以便通过 AES-GCM 保护 RPC 会话。握手由四条序列化 Protocol Buffer 消息组成，其大致流程如图 6 所示。

图 6：ALTS 握手协议消息

1. 客户端通过发送 ClientInit 消息来启动握手。此消息包含客户端的握手证书，并会列出与握手相关的密码和客户端支持的记录协议。如果客户端尝试恢复已终止的会话，则消息中将包含恢复标识符和加密服务器恢复票证。

2. 收到 ClientInit 消息后，服务器将验证客户端证书。如果有效，则服务器从客户端提供的列表中选择握手密码和记录协议。服务器将结合使用 ClientInit 消息中包含的信息和它自己的本地信息来计算 DH 交换结果。此结果将用作密钥派生函数¹³的输入值，搭配协议转录内容以生成如下会话密钥：

   • 用于加密和验证负载消息的记录协议密钥 M。
   • 在将来的会话中用于恢复票证的恢复密钥 R。
   • 验证器密钥 A。

   服务器将发送 ServerInit 消息，其中包含服务器证书、所选握手密码、记录协议和可选加密恢复票证。

3. 服务器发送包含握手身份验证器的 ServerFinished 消息¹⁴。该验证器的值将使用基于哈希的消息身份验证代码 (HMAC)，通过预定义长度的字符串和验证器密钥 A 计算得出。

4. 客户端收到 ServerInit 后，会验证服务器证书，采用类似于服务器的方式计算 DH 交换结果，并生成相同的 M、R 和 A 密钥。客户端使用生成的 A 来验证收到的 ServerFinished 消息中的身份验证器值。在握手流程中的这个阶段，客户端可以开始使用 M 来加密消息。由于客户端现在能够发送加密消息，我们可以确定 ALTS 具有一个 RTT 握手协议。

5. 在握手结束时，客户端将发送 ClientFinished 消息，该消息包含通过不同的预定义长度的字符串计算得出的类似认证符值（参见步骤 3）。如果需要，客户端可以包含用于将来会话的加密恢复票证。消息被服务器接收并验证后，ALTS 握手协议则结束，且服务器可以开始使用 M 来加密和验证其他负载消息。

握手协议由来自 Google 内部安全分析团队的 Thai Duong 审核，并在 Martin Abadi 的协助下使用 Bruno Blanchet 开发的 Proverif¹⁵ 工具进行正式验证。

记录协议

握手协议部分描述了我们如何使用握手协议来协商记录协议密钥。此协议密钥可用于加密和验证网络流量。执行这些操作的堆栈层被称为 ALTS 记录协议 (ALTSRP)。

ALTSRP 包含一套具有不同密钥大小和安全功能的加密方案。在握手期间，客户端发送其首选方案列表，按优先级排序。服务器将选择客户端列表中与服务器本地配置匹配的第一个协议。这种方案选择方法允许客户端和服务器采用不同的加密首选项，并允许我们逐步采用（或删除）加密方案。

帧

帧是 ALTS 中最小的数据单位。根据其大小，每条 ALTSRP 消息可以包含一个或多个帧。每个帧包含以下字段：

• 长度：32 位无符号值，表示帧的长度，以字节为单位。该 4 字节长度字段不包括在总帧长度中。
• 类型：指定帧类型的 32 位值，例如数据帧。
• 载荷：将要发送的经过身份验证和加密（可选）的实际数据。

帧的最大长度为 1MB 加上 4 个长度字节。对于当前的 RPC 协议，我们进一步限制帧长度，因为较短的帧需要较少的内存来进行缓冲。在拒绝服务 (DoS) 攻击期间，潜在的攻击者也可能利用较大的帧来试图大量消耗服务器资源。除了限制帧长度之外，我们还限制可以使用同一记录协议密钥 M 进行加密的帧数。该限制会根据用于加密和解密帧载荷的加密方案而变化。达到上限后，连接就必须关闭。

负载

在 ALTS 中，每个帧都包含一个完整性受保护并可视情况进行加密的载荷¹⁶。截至本文发布时，ALTS 支持以下模式：

• AES-128-GCM、AES-128-VCM：AES-GCM 和 AES-VCM 模式，分别采用 128 位密钥。这些模式分别使用 GCM 和 VCM 方案¹⁷保护载荷的机密性和完整性。
• AES-128-GMAC、AES-128-VMAC：这些模式分别支持使用 GMAC 和 VMAC 仅保护完整性，用于标签计算。载荷以明文形式传输，带有保护其完整性的加密标签。

在 Google，我们根据威胁模型和性能要求使用不同的保护模式。如果通信实体位于由 Google 或代表 Google 控制的同一物理边界内，则采用仅保护完整性模式。这些实体仍然可以根据数据的敏感性选择升级到经过身份验证的加密。如果通信实体处于由 Google 或代表 Google 控制的不同物理边界中，并且通信通过广域网传输，则无论选择何种模式，我们都会自动将连接的安全升级为经过身份验证的加密。由于无法应用同样严格的安全措施，Google 会在 Google 控制或代表 Google 控制的物理边界外传输数据时，对传输中的数据应用不同的保护措施。

每个帧都是单独进行完整性保护，并视情况进行加密。两个对等体都维护着请求和响应计数器，这些计数器会在正常操作期间同步。如果服务器收到无序或重复的请求，则加密完整性验证失败，请求将被丢弃。同样，客户端会丢弃重复或错误排序的响应。此外，让两个对等体都维护计数器（而不是在帧头中包含它们的值）还可以在传输中节省额外的字节。

会话恢复

ALTS 允许其用户恢复以前的会话，而无需执行繁重的非对称加密操作。会话恢复是 ALTS 握手协议的内置功能。

ALTS 握手允许客户端和服务器安全地交换（和缓存）可用于恢复未来连接的恢复票证¹⁸。每个缓存的恢复票证都按恢复标识符 (ID_R) 编入索引，在同一数据中心单元中以相同身份运行的所有工作负载都使用同一个专属标识符。这些票证使用与其对应标识符相关联的对称密钥加密。

ALTS 支持两种类型的会话恢复：

1. 服务器端会话恢复：客户端创建并加密包含服务器身份和所派生的恢复密钥 R 的恢复票证。在握手结束时，恢复票证会通过 ClientFinished 消息发送到服务器。在将来的会话中，服务器可以选择通过其 ServerInit 消息将票证发送回客户端，以恢复会话。收到票证后，客户端便可以对恢复密钥 R 和服务器身份进行恢复。客户端可以使用这些信息恢复会话。

   ID_R 始终与特定身份（而非特定连接）相关联。在 ALTS 中，多个客户端可以使用同一数据中心中的相同身份。这允许客户端恢复与它们未曾通信过的服务器的会话，例如，如果负载均衡器将客户端发送到运行相同应用的其他服务器。

2. 客户端会话恢复：在握手结束时，服务器通过 ServerFinished 消息向客户端发送经过加密的恢复票证。该票证中包含恢复密钥 R 和客户端的身份。客户端可以使用此票证恢复与使用相同 ID_R 的任何服务器的连接。

会话恢复后，恢复密钥 R 可用于生成新的会话密钥 M'、R' 和 A'。M' 用于对负载消息进行加密和身份验证，A' 用于对 ServerFinished 和 ClientFinished 消息进行身份验证，R' 将封装在新的恢复票证中。请注意，同一恢复密钥 R 仅可以使用一次。

权衡

密钥泄露伪装攻击

从设计上来说，ALTS 握手协议容易遭受密钥泄露伪装 (KCI) 攻击。如果攻击者破解了工作负载的 DH 私钥或恢复密钥，就可以使用密钥来用其他工作负载冒充该工作负载¹⁹。我们的恢复威胁模型中明确允许这一过程，因为我们希望由身份的实例颁发的恢复票证可由该身份的其他实例使用。

ALTS 握手协议有一种变体可以防范 KCI 攻击，但它只会用于不需要恢复的环境。

握手消息的隐私

ALTS 并非旨在掩盖哪些内部身份正在通信，因此它不会加密任何握手消息以隐藏对等体的身份。

完全正向加密

ALTS 支持完全正向加密 (PFS)，但默认情况下不启用。不过，我们使用频繁的证书轮换来为大多数应用建立正向加密。使用 TLS 1.2（及其较低版本）时，会话恢复不受 PFS 保护。当 ALTS 中启用 PFS 时，恢复的会话也将启用 PFS。

零往返恢复

TLS 1.3 提供需要零往返 (0-RTT) 的会话恢复，但是这种恢复具有较弱的安全属性²⁰。我们决定不在 ALTS 中包含 0-RTT 选项，因为 Google 的 RPC 连接通常是长期有效的。因此，以 0-RTT 握手更高的复杂性和/或更低的安全性来换取信道建立延时的降低并不划算。

其他参考信息

• 如需了解 Google 如何对传输中的数据进行加密，请参阅我们的 Google Cloud 中的传输加密白皮书。
• 如需简要了解 Google 技术基础架构如何将安全性纳入设计当中，请参阅我们的 Google 基础架构安全设计概述。

脚注

¹ “微服务”是一种架构样式，使用一组可实现业务功能的松散耦合服务构建应用。

² “生产工作负载”是指 Google 工程师安排在 Google 数据中心运行的应用。

³ 如需详细了解 Google 如何保护传输中的数据，请参阅我们的白皮书 Google Cloud 中的传输加密。

⁴ “信任模型”是指安全协议识别、分发及轮换凭据和身份所采用的机制。

⁵ 某些服务由开发者直接管理。

⁶ Borgmaster 负责安排和初始化 Google 生产工作负载。如需了解详情，请参阅使用 Borg 在 Google 进行大规模集群管理。

⁷ 如需详细了解证书轮换频率，请参阅 Google Cloud 中的加密传输。

⁸ 如果某个密钥遭到破解，攻击者只能发现此密钥对生命周期内的流量。

⁹ Titan 深入介绍：明文安全。

¹⁰ 使用 Borg 在 Google 进行大规模集群管理。

¹¹ ALTSd：一个守护程序，负责握手证书创建及其他 ALTS 操作。

¹² 在实际工作中，CA 可以访问签名服务私钥，使两个逻辑实体成为单个物理实体。

¹³ 具体是指 RFC-5869 中定义的 HKDF-Extract 和 HKDF-Expand。

¹⁴ ALTS 握手协议实现操作会将 ServerInit 和 ServerFinished 消息串联为一个线路载荷。

¹⁵ ProVerif：正式模型中的加密协议验证程序。

¹⁶ 载荷加密将在握手中作为记录协议的一部分进行协商。

¹⁷ 128 位 AES-GCM 方案在 NIST 800-38D 的基础上构造；如需详细了解 AES-VCM，请参阅 AES-VCM：使用基于整数的通用哈希函数的 AES-GCM 构造。

¹⁸ 仅当不涉及临时参数时，会话恢复才涉及轻量级对称操作。

¹⁹ 密钥协商协议及其安全分析。

²⁰ 零往返时间的重放攻击：TLS 1.3 握手候选协议的情况。