Meta 如何在 WhatsApp 以端到端加密与可验证性构建 Scam Alert

WhatsApp 致力于帮助人们在保护消息隐私的同时保持安全。随着诈骗手段不断演变——从冒充身份到社会工程，再到 AI 生成的诱饵——我们也在不断进化，使我们的防护措施始终领先于诈骗者，同时通过端到端加密保护人们的个人消息。

今天，我们提前分享早期版本的 Scam Alert，这是一项全新的可选功能，它运行一个设备端机器学习模型，用于提醒用户可能存在的诈骗消息。消息内容不会离开设备用于分类，也不会被自动举报给 WhatsApp、Meta 或任何其他方。该功能补充了端到端加密，并在模型认为可能存在诈骗时，提供由用户控制的可选诈骗提醒。

在向所有 WhatsApp 用户提供此功能之前，我们将在该功能于 Beta 版有限推出的同时发布这份早期技术概述，并将继续与我们的 Bug Bounty 社区合作，对该系统进行压力测试。为帮助验证我们的实现，我们欢迎更广泛的安全研究社区提供反馈。

设计原则

近期设备端机器学习模型的进展，使得完全在移动硬件上运行准确的文本分类成为可能，而无需再承受此前使设备端分类不太实用的性能、电池或模型大小方面的取舍。Scam Alert 非常适合这种方法：该模型足够小，可以在设备端运行；足够简单，可以公开以供独立审查；并且无需服务器端组件即可有效运行。我们选择的架构反映了一系列经过深思熟虑的选择，明确了该系统能做和不能做的事情。

为此，我们将 Scam Alert 设计为符合以下原则，这些原则遵循端到端加密的核心保证：

• 仅在设备端： 模型及其处理的消息数据都保留在设备上。
• 不自动举报： 未经用户操作，WhatsApp 无法主动共享任何用户数据。消息内容，甚至检测到诈骗这一事实，进入我们服务器的唯一方式是用户明确选择举报，这与 WhatsApp 上用户举报的工作方式一致。
• 用户控制： Scam Alert 是一个由用户控制的工具，为用户提供额外信息，用户可以随时将其关闭或开启。 

Scam Alert 如何运作

Scam Alert 是可选的。用户开启后，Scam Alert 会将机器学习模型下载到设备上，并在设备上运行推理，以分类来自非联系人的传入消息是否匹配已知诈骗模式。该模型基于用户向我们发送的举报中的诈骗对话所观察到的模式进行训练。它根据对话结构和语言信号进行概率分类。任何内容都不会被自动举报给 WhatsApp、Meta 或任何第三方。 

如果模型将某条消息识别为可能的诈骗尝试，用户会在聊天中看到警告，而对方看不到该警告。用户随后可以决定如何处理：屏蔽、举报或继续对话。如果用户认为某条警告属于误判，可以将该聊天标记为可信，此时警告会被移除，Scam Alert 也不会再标记该聊天。如果用户将某个聊天标记为可信，还可以选择与 WhatsApp 分享最近收到的 5 条消息，以帮助提升该功能的准确性。 

基础保障措施

为恪守上述原则，我们为 Scam Alert 设计了以下基础要求和保障措施，每一项都在架构上强制执行，安全研究人员可通过扩展的漏洞赏金计划独立验证，用户也可通过应用内日志自行验证。 

1. 设备端处理与隐私保护分析： 所有推理均在设备端进行，任何消息内容都不会离开用户设备用于分类。用于衡量该功能是否正常工作的最少遥测数据（即聚合且匿名的警告计数和用户操作计数）在机密计算环境中处理，并以差分隐私聚合的形式发送给 WhatsApp。该机密联邦分析流水线构建于机密虚拟机（CVM）之上，CVM 是一种可信执行环境（TEE）。我们选择这种方式，是为了使其行为可以被独立验证。
2. 不进行定向模型投放： Meta 和 WhatsApp 均无法向特定用户投放特定模型。每个模型版本，包括实验性变体，都会在部署前发布到公开的透明度账本上。
3. 可验证的模型行为： 我们公开模型权重，以便独立安全研究人员能够验证我们专门为诈骗场景构建了该模型。

本文的其余部分将详细介绍每项要求的技术实现。

设备端处理与隐私保护分析

如上所述，所有推理均在设备端进行。但我们需要知道该功能本身是否正常工作——即它确实能捕获真实诈骗——并了解是否需要更新它，以跟上不断演变的诈骗手法，并随时间推移改进模型。

为此，我们的方法遵循一系列数据最小化原则。消息内容不会离开设备，且日志记录在设计上仅限于衡量该功能是否按预期工作所需的信号。即便是这些信号，也在基于 TEE 构建的机密计算环境中处理，从而确保处理发生在一个任何人都无法访问的安全环境中——包括 Meta 和 WhatsApp。我们在构建和保护 Private Processing 等系统方面的经验，为本系统的设计提供了参考。只有匿名、差分隐私的聚合数据才会提供给 Meta 和 WhatsApp。差分隐私的工作原理是加入经过精心校准的噪声，以提供数学保证：添加或移除任何单个人的数据，对匿名聚合数字的影响都可以忽略不计。因此，这些聚合数据展示了该功能在整体人群中的表现，同时不会透露任何关于个人的信息。

对于 Scam Alert，这些数据仅限于两类近似、汇总的计数：

• 警告次数 ——设备端模型触发诈骗警告的次数。这告诉我们模型是否以正确的频率触发，这对于衡量精确率和捕捉模型版本间的回归至关重要。
• 用户操作次数 ——当用户看到警告时，可以选择信任发送者，或屏蔽并举报。我们会以汇总计数的形式记录用户采取了哪类操作。这告诉我们用户是否认为警告准确，这对于衡量误报率至关重要。

机密联合分析

为了对这些警告次数和用户操作次数进行匿名化处理，我们构建了一条机密联合分析流水线，围绕以下隐私和安全保障进行设计，每项保障均在架构上强制实施且可被外部验证：

• 设备端数据最小化：对于 Scam Alert，原始信号不会离开设备。客户端在本地将其汇总为计数，仅发送这些汇总计数。这些指标在随机时间发送，不包含设备标识符，并将任何时间戳信息限制为粗略的时间间隔。这确保无论是发送这些指标的行为还是指标本身，都无法被用于识别用户。
• 机密处理：这些指标在 TEE 内处理，TEE 是基于 CPU 的机密虚拟化技术构建的安全硬件环境，可基于硬件信任根对软件进行远程认证。在传输任何数据之前，客户端会检查这些认证，并与第三方可接受二进制文件日志进行比对确认。客户端与 TEE 之间的数据经过加密，因此中间的任何一方，包括 Meta、WhatsApp 或任何第三方中继，都无法访问。
• 安全聚合：单个设备的指标无法被 Meta、WhatsApp 或 TEE 之外的任何人读取。它们会被合并到持续运行的聚合中，只有超过最小群组规模并应用了差分隐私噪声的汇总统计数据，才会提供给 Meta 或 WhatsApp。对于 Scam Alert，设备将预聚合的计数直接发送到 TEE 进行安全聚合。
• 可强制执行的保障：在传输任何数据之前，客户端会验证 TEE 中运行的代码是否与第三方账本上发布的内容一致，以及隐私参数（如差分隐私 ε 和 δ，以及 k-匿名阈值）是否满足本地强制执行的护栏要求。如果验证失败或隐私参数不足，客户端将拒绝传输数据。任何修改处理保障的尝试，要么会导致系统故障关闭，要么会被公开发现。
• 加密恢复检查点：由于该管道会长期聚合数据，系统会定期保存进行中聚合数据的加密检查点，这样即使发生崩溃，也不会迫使某项测量从头重新开始。这些检查点仅包含已经在计算的部分聚合计数，并且经过加密：密钥从不离开 TEE，因此只有运行相同经认证二进制文件的机密联合分析 TEE 才能解密检查点，Meta 和 WhatsApp 都无法读取。检查点仅在恢复所需的有界期限内保留。
• 不可针对性：攻击者无法在不试图攻破整个系统的情况下针对特定用户。所有指标都通过 OHTTP 中继进行路由，该中继会剥离请求者的 IP 地址，并使用匿名凭证进行身份验证，以便系统能够验证指标来自合法的 WhatsApp 客户端，而无需知道具体是哪一个。这通过确保小规模攻击无法被用于针对特定用户的数据，限制了其影响。
• 可验证透明度：我们将提供应用内功能，让用户能够查看与机密联合分析管道共享了哪些数据、所应用的隐私参数（例如差分隐私 ε 和 δ，以及 k-匿名阈值），以及每个安全会话如何建立的详细信息。我们将发布驱动该管道的 CVM 镜像二进制文件，以及其隐私相关组件的源代码，以便安全研究人员能够独立验证所发布的代码正是 TEE 中运行的代码。我们将扩展 漏洞赏金计划，将机密联合分析管道纳入其中，并发布一份关于其设计的详细工程白皮书。

该管道的基础建立在 Meta 经过同行评审的联合分析工作上，并已通过“PAPAYA Federated Analytics Stack: Engineering Privacy, Scalability and Practicality”（USENIX NSDI 2025）公开概述。在此，我们描述 Scam Alert 如何应用并扩展这一基础。

机密联合分析的工作原理

该管道的工作方式如下：

1. 设备端数据收集：数据被收集并存储在专用的本地存储中，与其他应用数据隔离。机密联合分析系统只能访问应用已明确向其提供的数据。硬编码的隐私护栏强制执行数据生命周期、范围和访问控制。对于 Scam Alert，这仅包括警告事件和用户操作的计数。
2. 任务选择：在随机间隔内，当设备处于空闲状态且受限于自我执行的每日资源限额时，客户端通过 OHTTP 连接到应用服务器。客户端使用 匿名凭证 进行身份验证，证明其是合法的 WhatsApp 客户端而不泄露具体是哪一个，并获取该管道的活跃任务列表。对于每个任务，客户端会检查隐私参数（ε、δ 和 k-匿名阈值）是否满足本地执行的保护措施、设备是否有新的指标需要发送，以及参与是否会超出其每日限额。客户端可以拒绝任何不符合这些标准的任务。
3. 本地转换： 对于客户端接受的任务，它会从本地存储中检索相关数据，并通过将原始信号转换为指定时间段内的匿名计数（例如，每日警告计数、每日用户操作计数）来执行所请求的设备端聚合。仅传输聚合后的计数；原始信号保留在设备上，并在保留期后自动删除。
4. 认证、鉴权与会话建立： 客户端与编排器 TEE 建立远程认证 + 传输层安全（RA-TLS）会话。认证报价包含编排器的度量值，客户端将其与第三方透明度账本进行交叉检查，以确保仅连接到满足我们可验证透明度保证的代码。客户端使用匿名凭证进行身份验证，连接通过第三方 OHTTP 中继路由，该中继会剥离请求者的 IP 地址。中继无法读取指标，因为它们在设备与 TEE 之间进行端到端加密。
5. 编排器 TEE — 临时处理： 加密的指标到达托管在 TEE 上的无状态编排器。编排器验证来自客户端的隐私配置是否与任务的配置匹配，将来自多个设备的指标分批，并将分批后的指标转发到相应的聚合器 TEE。对于 Scam Alert，这些指标是预聚合的计数。
6. 聚合器 TEE — 安全聚合： 聚合器 TEE 将传入的指标合并到运行直方图中。聚合后，单个指标会被丢弃。聚合器会定期执行 k-匿名阈值，以抑制贡献者过少的结果，并应用差分隐私噪声。发布的数量和时间受到限制，以确保在所有发布中不超过整体隐私预算（ε、δ）。只有带噪声的、经过阈值处理的聚合结果才会发送给 WhatsApp。
7. 数据存储： 只有差分隐私的匿名聚合结果（例如所有用户的总警告计数和操作率）会离开 TEE 边界。这些聚合结果不包含任何消息内容、无每用户数据，也无对话级别信号。它们仅用于衡量该功能是否按预期工作。

机密联邦分析管道的构建方式是，当任何统计数据到达 WhatsApp 时，这些计数已经在众多用户之间进行了聚合，并加入了差分隐私噪声——因此我们只能看到有多少警告被展示、有多少被处理的大致计数。我们不会知道消息内容是什么、谁发送或接收了它们，或者哪个对话触发了警告。

威胁模型与纵深防御

这条机密联邦分析管道运行在一个高度对抗性的环境中。我们的威胁模型考虑了三种攻击者：能够访问系统组件的第三方或供应链供应商，能够访问基础设施的恶意或已被攻破的内部人员，以及试图利用管道攻击面的外部行为者。

外部行为者试图在传输途中或处理过程中拦截或提取未聚合的数据。

传输中的数据在设备和 TEE 之间加密，并通过第三方 OHTTP 中继路由。中继的作用仅限于剥离客户端的 IP 地址——它无法解密、检查或修改数据本身。由于这些数据对第三方本就不可见，被攻破的中继也无法访问数据或将数据集与特定用户关联。在处理过程中，数据受到 TEE 代码隔离的保护，入口点仅限于一小组经过审查的组件。

拥有基础设施访问权限的内部人员试图访问 TEE 内的未聚合数据。

TEE 禁止远程 shell 访问，包括来自宿主机的访问。Meta 工程师和网络系统均无法在运行时访问 CVM shell。软件仅由已检入的源代码和构建产物构建，任何更改都需要多名工程师修改构建产物或构建管道。所有代码更改均可审计，使内部持续审计和外部安全研究人员都能检查我们的二进制文件。未聚合的数据在 TEE 之外永远不可读；存储时，数据使用仅向运行相同经认证二进制的 TEE 发布的密钥进行加密，并且仅在有限期限内保留，之后被合并到运行中的聚合数据中并丢弃。

拥有物理或远程访问权限的攻击者干扰 TEE，以绕过机密处理保证。

由于 TEE 保证并非绝对，我们采用纵深防御：加密 DRAM、CVM 加固、增强的主机监控，以及 OHTTP 中继路由，防止将特定用户的数据定向到特定机器。有针对性的攻击需要以可通过可验证透明度被公开发现的方式攻破整个系统。

无定向模型分发

模型从 CDN 下载，而非硬编码到应用中，这样在准确性和对新兴诈骗手法的覆盖方面的改进无需强制应用升级即可触达用户。为此，我们还确保不存在向特定用户分发不同模型的途径。

每个模型版本——包括其 SHA-256 哈希——在向任何人提供之前，都会发布在第三方仅追加的透明度账本上。仅追加账本是一种公共日志，条目只能添加，永远不能被修改或删除，从而确保研究人员可以检查的防篡改历史。

我们围绕三项保证设计了模型下载系统：

1. 可审计性：每个模型版本在向任何用户提供服务之前，都会公开记录在第三方仅追加的透明度账本上。该账本具有防篡改特性，因此条目只能添加，永远不能被修改或删除。要投递定向模型，就必须将其发布在任何人都可以检查的账本上，从而使这种企图可被公开发现。要检查账本，用户可以下载其应用内透明度日志，并使用报告中的命名空间和纪元进行确认，格式如下：https://akd-auditor.cloudflare.com/namespaces/<namespace>/audits/<epoch>。
2. 匿名下载请求：模型下载端点无法确定是哪个用户在请求模型。所有下载请求都使用匿名凭证进行身份验证，并通过 OHTTP 中继路由，该中继会剥离请求者的 IP 地址，且请求负载中不包含任何身份选择器。模型资产本身由 CDN 提供，CDN 仅分发公开发布的文件，不参与决定设备使用哪个模型，因此无法被用来针对特定用户。
3. 不可定向性：任何人都无法将特定模型投递给特定用户，即使通过实验也不行。客户端会随机化下载请求的时机，实验分组完全在设备上进行：客户端使用本地生成的随机性将自己分配到某个组，因此服务器无法将特定用户引导至特定的模型变体。

模型下载与验证的工作原理

1. 模型发布：当新模型版本准备好部署时，服务器会计算模型权重、分词器和其他资产的 SHA-256 哈希值，并构建清单——一个包含这些哈希值、模型版本和时间戳的 JSON 文档。清单摘要（清单的 SHA-256）会提交给第三方签名者（Cloudflare），使用 Ed25519 密钥进行签名。Meta 不持有签名密钥。随后，已签名的清单摘要会发布到第三方仅追加的透明度账本，模型资产则上传到 CDN。
2. 匿名下载请求：客户端通过 OHTTP 连接到模型下载端点，并使用匿名凭证进行身份验证。OHTTP 中继会剥离客户端的 IP 地址——中继可以看到 IP 但无法解密请求，而服务器可以看到请求但只能看到中继的 IP。服务器返回清单、数字签名以及模型资产的 CDN URL。
3. 客户端验证：在使用任何已下载的模型之前，客户端会执行多步验证。首先，它计算清单摘要，并对照硬编码的 Cloudflare Ed25519 公钥验证数字签名——确认清单由 Cloudflare 签名，而非由 Meta 或任何其他方伪造。接着，它将清单摘要与透明度账本进行交叉比对，并执行新鲜度检查，以防止使用陈旧条目的重放攻击。最后，它从 CDN 下载模型资产，并验证每个资产的 SHA-256 哈希值与清单匹配。如果任一步骤失败，客户端将拒绝加载该模型。
4. 模型已加载到设备：只有在所有验证步骤都通过后，客户端才会安装并使用该模型。

私密实验

在向全球推出新模型版本之前，我们必须通过在一部分用户中测试模型变体来评估其准确性和有效性。这种实验绝不能形成定向投放的途径（即向特定用户下发特定模型）。模型下载流程的设计可防止这一点：

• 客户端分组：下载响应中包含可用的模型配置，这些配置通过相同的匿名 OHTTP 和 ACS 流程以随机间隔获取。客户端使用本地生成的随机种子，将自己分配到一个组，并从这些配置中选择要使用的模型。服务器无法影响特定用户收到哪个模型变体。
• 实验配置篡改检查：客户端对实验配置强制执行完整性检查。组属性在发布后不可修改，实验规模只能扩大（绝不能缩小），并且组必须达到最小规模阈值，从而防止攻击者将某个组缩小以定向针对个别用户。
• 账本上的实验模型：每个实验模型变体在下发之前都会先发布到透明度账本，其签名和验证流程与生产模型相同。任何模型——无论是生产模型还是实验模型——未经公开记录都不会到达设备。
• 匿名化实验指标：来自不同实验组的性能指标通过本博客前文所述的同一套机密联邦分析流水线进行衡量。如果某个实验组在聚合后规模过小、无法满足 k-匿名阈值，TEE 会完全抑制该数据。

由于整个验证和实验流程都在客户端运行，安全研究人员可以检查应用二进制文件，以确认这些检查确实被执行。

可验证的模型行为

我们在上文概述了 Meta 和 WhatsApp 都无法向特定用户下发特定模型，以及机密联邦分析流水线如何保护隐私。但这二者都没有回答一个更根本的问题：除非模型的行为可以被独立审查，否则任何人如何能验证该模型只是为了识别潜在诈骗消息而构建的？

我们围绕两项保证设计了模型验证系统：

1. 用户可见性：用户可以直接在设备上查看模型做了什么——扫描了哪些消息、结果是什么，以及使用了哪个模型版本。
2. 独立可验证性：如前所述，外部研究人员可以获取在用户设备上运行的精确模型，对照透明度账本验证其完整性，并独立分析其行为。

模型透明度如何运作

• 已发布模型工件：每个模型版本的哈希值都记录在签名清单中，该清单存于用于验证模型交付的同一第三方透明度账本上。透明度账本是公开的，因此任何人都可以查看，以验证正在提供哪些模型版本，并确认每个版本（包括实验性变体）都被公开记录。
• 客户端透明度日志： 在设备本身上，用户可以启用透明度日志，记录哪些消息被设备端机器学习模型标记。用户可以通过前往 账户 > 请求信息 > 诈骗提醒活动 查看。透明度日志中包含每次分析的结果（模型是否标记了该消息以及是否显示了警告），以及使用了哪个模型版本。这些日志让用户能够直接、细致地了解系统在其设备上的运行方式。
• Bug Bounty Program: Ahead of Beta rollout, we engaged external security researchers through our Bug Bounty program to help us stress-test our system:
  • 隐私架构审查： 研究人员获得了一个带有该功能的早期访问 APK 构建版本，以确认没有消息内容离开设备，并且没有自动上报；并且；
  • 模型完整性审查： 经验丰富的 AI/ML 研究人员收到模型权重，以确认该模型是专为诈骗检测而构建，而非其他用途。 

我们将扩大漏洞赏金计划的范围，将模型纳入其中，以便用它们自己的输入对模型进行测试，分析它们在一系列场景中的行为，并报告任何模型偏离其声明用途或能力可被系统性规避的发现。

构建可验证的信任与后续步骤

机密联邦分析管道确保即使是在衡量模型性能的过程中也能保护用户隐私。透明度账本和第三方签名确保我们发布的每个模型都被公开记录且防篡改。而已发布的模型工件、客户端透明度日志和专门的漏洞赏金计划确保模型的行为可以被独立验证。

如上所述，此功能目前仅以有限的 Beta 容量开始推出。我们将在 Beta 阶段继续迭代和改进，然后再投入生产，但我们想借此机会概述我们的原则。

诈骗者将继续演变他们的手段。为了持续领先于他们，我们也将如此。

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

致谢

感谢 Ronald Anthony、Shafin Anwarsha、Samyukta Mogily、Lenny Grokop、Riccardo Tortul、Harish Srinivas、Kiran Teja Tummuri、Roman Dashchakivskyi、Chao Zhang、Jitendra Mohanty，以及公司内许多其他帮助实现 Scam Alert 的人。

文章 我们如何利用端到端加密和可验证性保障在 WhatsApp 上构建 Scam Alert 首次发表于 Engineering at Meta。