发布于 2025 年 4 月 29 日，归类于 Security & Privacy

在 WhatsApp 上构建 AI 工具的私有处理能力 (Private Processing)

AI 彻底改变了人们与技术和信息交互的方式，使人们能够自动化复杂的任务并从大量数据中获得有价值的见解。 然而，当前的 AI 处理状态——它依赖于通常在服务器上运行的大型语言模型，而不是移动硬件——要求用户的请求对提供商可见。 虽然这适用于许多用例，但在使人们能够使用 AI 处理私人消息，同时保持端到端加密所提供的隐私级别方面，提出了挑战。

我们着手实现 AI 功能，同时兼顾人们期望从 WhatsApp 获得的隐私，以便 AI 可以提供有用的功能，例如总结消息，而 Meta 或 WhatsApp 无法访问它们，并以符合以下原则的方式实现：

Private Processing 简介

我们很高兴分享 Private Processing 的初步概述，这是一项我们构建的新技术，旨在支持人们的需求和愿望，以便以安全和保护隐私的方式利用 AI。 这种构建在可信执行环境 (TEE) 之上的机密计算基础设施，将使人们能够在我们安全和私有的云环境中，指示 AI 处理他们的请求——例如总结未读的 WhatsApp 线程或获得写作建议。 换句话说，Private Processing 将允许用户利用强大的 AI 功能，同时保持 WhatsApp 的核心隐私承诺，确保除了你和你正在交谈的人之外，任何人都无法访问或分享你的个人消息，甚至包括 Meta 或 WhatsApp。

为了维护这种级别的隐私和安全，我们在设计 Private Processing 时考虑了以下基本要求：

但是，我们知道像我们这样的技术平台在一个高度对抗的环境中运行，威胁者不断适应，软件和硬件系统不断发展，从而产生未知的风险。 作为我们的深度防御方法和任何安全关键系统的最佳实践的一部分，我们将以下附加层需求视为 WhatsApp 上 Private Processing 的核心：

Private Processing 的威胁建模

由于我们着手满足这些高安全性要求，因此我们构建 Private Processing 的工作始于开发威胁模型，以帮助我们识别可能危及用户数据的机密性、完整性或可用性的潜在攻击向量和漏洞。 我们已经与安全社区的同行合作，审核了该架构和我们的实施，以帮助我们继续加强它们。

开放构建

为了帮助推动我们的行业在构建私有 AI 处理方面的进展，并支持该领域的独立安全研究，我们将发布 Private Processing 的组件，扩大我们的 Bug Bounty program 的范围以包括 Private Processing，并发布详细的安全工程设计文件，随着我们越来越接近在未来几周内推出 Private Processing。

虽然在用户指导下，对个人消息进行 AI 支持的处理以进行总结和写作建议是 Meta 应用 Private Processing 的第一个用例，但我们预计还会有其他用例，在这些用例中，相同或类似的基础设施可能有利于处理用户请求。 我们将继续透明和负责任地分享我们的经验和进展。

Private Processing 的工作原理

Private Processing 创建了一个安全云环境，AI 模型可以在其中分析和处理数据，而不会将其暴露给未经授权的方。

工作原理如下：

威胁模型

在设计任何安全关键系统时，重要的是开发一个威胁模型来指导我们如何构建其防御。 我们针对 Private Processing 的威胁模型包括三个关键组件：

资产

在将 Private Processing 应用于总结未读消息或在用户指导下提供写作建议的背景下，我们将使用 Private Processing 来保护消息传递内容，无论它们是否已由用户收到，或者仍在草稿中。 在此博客的上下文中，我们使用术语“消息”来指代这些主要资产。

除了消息之外，我们还包括其他辅助资产，这些资产有助于支持 Private Processing 的目标，并且可能与资产交互或直接处理资产：机密虚拟机 (CVM) 的可信计算基础 (TCB)、底层硬件以及用于保护传输中数据的加密密钥。

威胁者

我们已经确定了三种威胁者类型，它们可能会攻击我们的系统以尝试恢复资产。

  1. 可以访问我们基础设施的恶意或受损内部人员。
  2. 可以访问基础设施组件的第三方或供应链供应商。
  3. 针对平台上其他用户的恶意最终用户。

威胁情景

在构建 Private Processing 以抵御这些威胁者时，我们会考虑可能针对我们的系统采取的相关威胁情景，包括（但不限于）以下情景：

外部参与者直接利用暴露的产品攻击面或破坏在 Private Processing CVM 中运行的服务来提取消息。

系统处理不受信任数据的所有位置都存在潜在的攻击面，威胁者可以利用它。 此类攻击的示例包括利用零日漏洞或 AI 独有的攻击，例如提示注入。

Private Processing 旨在通过将暴露的入口点限制为一小组经过彻底审查的组件（这些组件会定期进行保证测试）来减少此类攻击面。 服务二进制文件经过强化并在容器化环境中运行，以降低代码执行的风险并限制受损二进制文件从 CVM 内将数据泄露给外部方的能力。

内部或外部攻击者提取通过 CVM 暴露的消息。

可观察性和可调试性在高度安全的环境中仍然是一个挑战，因为它们可能与机密计算的目标相冲突，从而可能暴露侧信道以识别数据，并且在最坏的情况下会意外泄露消息本身。 但是，大规模部署任何服务都需要一定程度的可观察性来识别故障模式，因为即使频率不常见，它们也可能对许多用户产生负面影响。 我们实施了一个日志过滤系统，以将导出限制为仅允许的日志行，例如错误日志。

与任何复杂系统一样，Private Processing 由组件构建而成，以形成硬件和软件的复杂供应链。 在内部，我们的 CVM 构建过程发生在受限环境中，这些环境维护出处并需要多方审查。 CVM 环境的透明度（我们将通过发布 CVM 二进制摘要和 CVM 二进制映像的第三方日志来提供），将允许外部研究人员分析、复制和报告他们认为日志可能泄露用户数据的实例。

拥有对 Private Processing 主机的物理或远程访问权限的内部人员会在启动和运行时干扰 CVM，从而可能绕过保护以提取消息。

TEE 软件利用是安全研究中一个日益增长的领域，漏洞研究人员已经反复证明能够绕过 TEE 保证。 同样，对 Private Processing 主机的物理攻击可能用于破坏 TEE 保证或将受损主机呈现为对最终用户的合法主机。

为了解决这些未知风险，我们通过积极跟踪该领域的新漏洞、最小化和清理对 TEE 的不受信任的输入、通过 CVM 强化最小化攻击面以及通过增强的主机监控启用滥用检测，在深度防御原则的基础上构建了 Private Processing。

因为我们知道防御物理访问会带来显着的复杂性和攻击面，即使采用业界领先的控制措施，我们也会不断追求进一步的攻击面强化。 此外，我们通过加密 DRAM 和标准物理安全控制等措施来降低这些风险，以保护我们的数据中心免受不良行为者的侵害。

为了进一步解决这些未知风险，我们力求通过通过第三方 OHTTP 中继路由会话来消除有针对性的攻击的可行性，以防止攻击者能够将特定用户路由到特定机器。

设计 Private Processing

以下是我们如何设计 Private Processing 以满足这些基本的安全和隐私要求，以应对我们开发的威胁模型。

(更多技术文档和安全研究参与更新即将发布)。

机密处理

共享给 Private Processing 的数据在一种环境中进行处理，该环境不会将其提供给任何其他系统。 通过在客户端和 Private Processing 应用程序之间对数据进行端到端加密来进一步维护此保护，以便只有 Private Processing，而中间的任何人（包括 Meta、WhatsApp 或任何第三方中继）都无法访问数据。

为了防止可能的用户数据泄露，只允许有限的服务可靠性日志离开 CVM 的边界。

系统软件

为了防止对 Private Processing 的特权运行时访问，我们禁止远程 shell 访问（包括来自主机的访问），并实施包括代码隔离在内的安全措施。 代码隔离可确保只有 Private Processing 中的指定代码才能访问用户数据。 禁止的远程 shell 访问可确保主机或联网用户都无法访问 CVM shell。

我们通过实施既定的行业最佳实践来防御潜在的源代码控制和供应链攻击。 这包括专门从签入的源代码和工件构建软件，其中任何更改都需要多个工程师来修改构建工件或构建管道。

作为另一层安全措施，所有代码更改都是可审核的。 这使我们能够确保发现任何潜在问题——无论是通过我们对代码的持续内部审核，还是通过外部安全研究人员审核我们的二进制文件。

系统硬件

Private Processing 利用基于 CPU 的机密虚拟化技术以及机密计算模式 GPU，这些技术可防止主机操作系统发起的某些类别的攻击以及某些物理攻击。

可执行的保证

Private Processing 利用基于 CPU 的机密虚拟化技术，该技术允许基于硬件信任根的软件证明，以保证每次客户端服务器连接之前的系统安全。 在传输任何数据之前，Private Processing 会检查这些证明，并根据可接受二进制文件的第三方日志确认它们。

无状态且前向安全的

我们将 Private Processing 作为无状态服务运行，该服务在会话完成后既不存储也不保留对消息的访问权限。

此外，Private Processing 不会将消息存储到磁盘或外部存储中，因此不会维护对该数据的持久访问权限。

作为我们数据最小化工作的一部分，对 Private Processing 的请求仅包括对处理提示有用的数据——例如，消息摘要将仅包括用户指示 AI 摘要的消息。

非目标性

Private Processing 实施 OHTTP 协议以建立与 Meta 路由层的安全会话。 这可确保 Meta 和 WhatsApp 不知道哪个用户正在连接到哪个 CVM。 换句话说，Meta 和 WhatsApp 不知道哪个用户启动了对 Private Processing 的请求，而请求正在路由中，因此无法将特定用户路由到任何特定硬件。

Private Processing 使用匿名凭证通过 OHTTP 对用户进行身份验证。 这样，Private Processing 可以在 Private Processing 系统上对用户进行身份验证，但仍然无法识别他们。 在建立系统会话期间，Private Processing 不会将任何其他可识别信息作为请求的一部分包含在内。 我们通过确保它们不能用于针对特定用户的数据来限制小规模攻击的影响。

可验证的透明性

为了让用户可以了解其数据的处理情况并帮助验证任何客户端行为，我们将提供获取应用内 Private Processing 请求日志、与之共享的数据以及该安全会话的设置方式的详细信息的功能。

为了提供可验证性，我们将提供为 Private Processing 供电的 CVM 映像二进制文件。 我们将向研究人员提供这些组件，以允许对我们的实施进行独立、外部验证。

此外，为了支持该领域更深入的漏洞赏金研究，我们将发布系统某些组件的源代码，包括我们的证明验证代码或负载承载代码。

我们还将扩大我们现有的 Bug Bounty program 的范围，以涵盖 Private Processing，从而支持对 Private Processing 的设计和实施进行进一步的独立安全研究。

最后，我们将发布一份关于 Private Processing 安全工程设计的详细技术白皮书，以进一步提高我们安全实践的透明度，并帮助业内其他人构建类似的系统。

参与其中

我们坚定地致力于为我们的用户提供最佳的消息传递体验，同时确保只有他们和与他们交谈的人才能访问或分享他们的个人消息。 Private Processing 是这一承诺的关键组成部分，我们很高兴在未来几周内推出它。

我们欢迎我们的用户、研究人员和更广泛的安全社区通过我们的安全研究计划提供反馈：

分享此内容:

TAGS: WhatsApp