WhatsApp如何利用端到端加密与Verifiability Guarantees构建Scam Alert
WhatsApp 致力于在保护用户消息隐私的同时，帮助大家远离诈骗。随着诈骗手段不断升级——从冒充身份、社交工程，到 AI 生成的钓鱼诱饵——我们的防护机制也在持续演进，确保始终快人一步，用端到端加密守护用户的私人消息。
今天，我们首次介绍 Scam Alert——一项全新的可选功能，通过运行设备端的机器学习模型来提示用户注意潜在诈骗消息。没有任何消息内容会在分类过程中离开设备，也不会自动上报给 WhatsApp、Meta 或其他任何第三方。该功能作为端到端加密的补充，在模型判断存在较高诈骗风险时，向用户提供由用户自主控制、可随时开启或关闭的预警通知。
在面向全体 WhatsApp 用户开放此功能之前，我们将在 Beta 版小范围推广的同时发布这篇技术概览，并继续与 Bug Bounty 社区协作，对系统进行充分的压力测试。为验证我们的实现方案，我们也欢迎更广泛的安全研究社区提供反馈。
设计原则
设备端机器学习模型的近期进展，使得完全在移动端硬件上执行精准文本分类成为可能，不再需要在性能、续航或模型体积上做出妥协——这正是过去制约设备端分类实用性的主要瓶颈。Scam Alert 非常契合这一方向：模型体积小巧、足够轻量可供独立审查，且不依赖服务端组件也能发挥实效。我们选择的架构体现了对系统能力边界的一系列审慎权衡。
基于此，我们设计了 Scam Alert 以下核心原则，确保其严格遵循端到端加密的基本保证：
- 仅运行于设备端：模型和处理的消息数据均保留在设备上。
- 不自动上报：未经用户主动操作，WhatsApp 无法发起任何用户数据的共享。消息内容，甚至检测到诈骗这一事实本身，只有通过用户明确选择举报后才会到达我们的服务器，这与 WhatsApp 现有的用户举报机制保持一致。
- 用户可控：Scam Alert 是由用户控制的工具，为用户提供额外的提示信息，用户可随时开启或关闭。
Scam Alert 工作原理
Scam Alert 是可选功能。用户开启后，该功能会将机器学习模型下载至设备，在本地运行推理，判断来自非联系人的消息是否符合已知诈骗模式。模型基于用户上报的诈骗对话中的模式进行训练，根据对话结构和语言特征进行概率分类。任何内容都不会自动上报给 WhatsApp、Meta 或任何第三方。 若模型判定某条消息疑似诈骗，用户会在聊天中收到警告提示，对方无法看到该提示。用户可自行选择处理：屏蔽、举报或继续对话。若用户认为警告存在误判，可将该聊天标记为信任，警告随即移除，且 Scam Alert 不会再对该聊天进行标记。标记信任后，用户还可选择共享最近收到的 5 条消息给 WhatsApp，以帮助改进功能准确性。基础保障措施
为践行上述原则，我们为 Scam Alert 设计了以下基础要求与保障措施，每项均在架构层面强制执行，并可由安全研究人员通过扩展的黑客漏洞赏金计划独立验证，用户也可通过应用内日志自行核验。
- 设备端处理与隐私保护分析：所有推理均在设备端完成，消息内容不会离开用户设备用于分类。用于衡量功能运行效果的最小遥测数据（即聚合且匿名的警告次数与用户操作次数）在机密计算环境中处理，并以差分隐私聚合形式发送至 WhatsApp。该机密联邦分析管道基于机密虚拟机（CVM）构建，CVM 是一种可信执行环境（TEE）。我们选择此方案旨在确保其行为可被独立验证。
- 无定向模型推送：Meta 或 WhatsApp 均无法向特定用户推送特定模型。每个模型版本（包括实验性变体）在部署前均会发布至公共透明账本。
- 可验证的模型行为：我们公开发布模型权重，使独立安全研究人员能够验证我们确实仅针对诈骗场景进行专门构建。
本文其余部分将详细介绍各项需求的技术实现。
端侧处理与隐私保护分析
如上所述，所有推理均在端侧完成。但我们仍需确认功能本身运行正常——即确实能拦截真实诈骗——并判断是否需要更新以应对不断演变的诈骗手段、持续优化模型。
为此，我们的方案遵循一套数据最小化原则。消息内容不会离开设备，日志记录在设计上仅捕获衡量功能是否正常所需的关键信号。即便如此，这些信号也在基于 TEE 构建的机密计算环境中处理，确保在包括 Meta 和 WhatsApp 在内的任何人都无法访问的安全环境下进行处理。我们在构建和保护 Private Processing 等系统方面的经验为本系统设计提供了指导。仅有匿名且符合差分隐私的聚合数据才会提供给 Meta 和 WhatsApp。差分隐私通过在数据中添加精心校准的噪声来工作，从而提供数学保证：添加或删除任何单个人的数据对匿名聚合结果的影响微乎其微。因此，这些聚合数据能反映功能在整体用户群中的表现，而不会透露任何个人层面的信息。
对于 Scam Alert，这些数据仅限于两类近似聚合计数：
- 预警计数——端侧模型发出诈骗预警的次数。这帮助我们判断模型触发率是否合理，对衡量精确率和检测各模型版本间的回归问题至关重要。
- 用户操作计数——用户看到预警后可以选择信任发送方或拉黑举报。我们记录各类操作的聚合计数。这帮助我们判断用户是否认为预警准确，对衡量误报率至关重要。
机密联邦分析
为了对这些预警和用户操作计数进行匿名化处理，我们构建了一套机密联邦分析流水线，其设计围绕以下隐私和安全保障展开，每项保障均由架构强制执行且可外部验证：
- 设备端数据最小化：在 Scam Alert 中，原始信号不会离开设备。客户端会在本地将信号聚合为计数值后再上传，仅发送这些聚合结果。指标会随机时间发送，不包含任何设备标识符，时间戳信息也仅保留粗粒度区间，从而确保无论是发送行为还是指标本身都无法用于识别用户。
- 机密处理：上述指标均在 TEE（可信执行环境）中处理。该环境基于 CPU 级机密虚拟化技术构建，支持基于硬件信任根对软件进行可信证明。数据发送前，客户端会校验这些证明，并与第三方可信二进制列表进行比对。客户端与 TEE 之间的数据全程加密，因此途中经过的任何一方——包括 Meta、WhatsApp 或第三方中继——均无法访问数据。
- 安全聚合：单个设备的指标对 Meta、WhatsApp 及 TEE 外部人员均不可读。这些数据会被合并为累计聚合值，只有达到最低群体规模、并叠加差分隐私噪声后的聚合统计结果，才会提供给 Meta 或 WhatsApp。对于 Scam Alert，设备将预聚合计数直接发送给 TEE 进行安全聚合。
- 可强制执行的保障：在数据传输前，客户端会验证 TEE 中运行的代码是否与第三方账本上发布的版本一致，并检查隐私参数（如差分隐私 ε、δ 和 k-匿名阈值）是否满足本地强制设定的安全基线。若验证未通过或隐私参数不足，客户端将拒绝上传数据。任何试图篡改处理保障的行为，要么导致系统自动失败关闭，要么会公开暴露。
- 加密恢复检查点：由于聚合流程会跨较长周期持续运行，系统会定期保存当前聚合结果的加密检查点，避免崩溃导致测量任务从头开始。检查点仅包含已计算的部分聚合计数，且已加密：密钥永远不出 TEE，只有运行同一经可信证明二进制的机密联邦分析 TEE 才能解密检查点，Meta 和 WhatsApp 均无法读取。检查点仅保留到恢复所需的最短期限。
该管道的基础建立在 Meta 经过同行评审的联邦分析研究之上，公开展示于《PAPAYA 联邦分析栈：隐私、可扩展性与实用性工程》（USENIX NSDI 2025）。本文描述 Scam Alert 如何在此基础上应用并扩展。
机密联邦分析的工作原理
管道工作流程如下：
- 端侧数据采集：数据在专用设备本地存储中收集并保存，与其他应用数据隔离。机密联邦分析系统只能访问应用主动暴露给它的部分数据。硬编码的隐私护栏对数据生命周期、范围和访问权限加以约束。对于 Scam Alert，仅包括警告事件计数和用户操作。
- Job Selection: 客户端以随机间隔在设备空闲时且受每日资源限制约束的情况下，通过 OHTTP 连接应用服务器。客户端使用匿名凭证进行身份验证——证明自己是合法的 WhatsApp 客户端而不暴露具体身份——并获取流水线中活跃任务列表。对每项任务，客户端检查隐私参数（ε、δ 及 k-匿名阈值）是否满足本地执行的保护约束、设备是否有待发送的新指标、以及参与后是否会超出每日限额。不满足条件的任务可被直接拒绝。
- Local Transformation: 对于接受的任务，客户端从本地存储获取相关数据，并按指定时间窗口将原始信号转换为匿名计数（如每日预警次数、每日用户操作次数），完成设备端聚合。仅有聚合后的计数会被传输；原始信号保留在设备上并在保留期结束后自动删除。
- Attestation, Authentication, and Session Establishment: 客户端与编排器 TEE 建立远程可信执行 + 传输层安全（RA-TLS）会话。证明中包含编排器的度量信息，客户端将其与第三方透明账本交叉验证，确保仅连接到满足可验证透明性保证的代码。客户端使用匿名凭证认证，连接通过第三方 OHTTP 中继路由，该中继会剥离请求者的 IP 地址。中继无法读取指标，因为数据在设备与 TEE 之间端到端加密。
- Orchestrator TEE — Ephemeral Processing: 加密指标抵达托管在 TEE 上的无状态编排器。编排器验证客户端的隐私配置与任务配置一致，将来自多个设备的指标分批，并将批次转发至对应的聚合器 TEE。对于 Scam Alert，这些指标为预聚合计数。
- 聚合 TEE — 安全聚合：聚合 TEE 将接收到的指标数据合并到运行中的直方图里，聚合完成后即丢弃单个指标。每隔一段时间，聚合器会强制执行 k-匿名阈值来抑制贡献者数量不足的结果，并施加差分隐私噪声。发布的次数和时机均受限制，以确保所有发布累积的总隐私预算 (ε, δ) 不被超出。最终只有经过噪声处理和阈值过滤的聚合数据才会发送至 WhatsApp。
- 数据存储：仅有经过差分隐私处理的匿名聚合数据——例如全用户的警告总数和操作率——才会越过 TEE 边界。这些聚合数据不含任何消息内容、单用户数据或对话级信号，仅用于衡量该功能是否按预期运行。
我们的机密联邦分析管道设计确保，在任何汇总数据抵达 WhatsApp 时，计数已经跨大量用户完成聚合并叠加了差分隐私噪声——因此我们看到的只是警告展示数量和被处理数量的近似值，无法得知具体消息内容、收发双方身份，或是哪场对话触发了警告。
威胁模型与纵深防御
这套机密联邦分析管道运行于高度对抗性的环境中。我们的威胁模型涵盖三类攻击者：可访问系统组件的第三方或供应链供应商、可访问基础设施的恶意或被攻陷的内部人员，以及试图利用管道攻击面的外部行为者。
外部行为者试图在传输或处理过程中拦截或提取未聚合数据。
数据在传输过程中由设备至 TEE 全程加密，并通过第三方 OHTTP 中继路由。中继的作用仅限于剥离客户端 IP 地址——它无法解密、检查或篡改数据本身。由于第三方本就看不到这些数据，即使中继被攻陷，也无法获取数据或将数据集关联到特定用户。处理阶段，数据受 TEE 代码隔离保护，入口点限制为少量经审计的组件。
拥有基础设施访问权限的内部人员试图在 TEE 内部获取未聚合数据。
TEE 禁止远程 shell 访问，包括来自宿主机的访问。Meta 工程师和联网系统在运行时均无法访问 CVM shell。软件仅基于经过代码审核的源代码和构件构建，任何变更均需多名工程师共同修改构建构件或构建流水线。所有代码变更均可审计，支持持续的内部审计以及外部安全研究人员的二进制文件审查。未聚合的数据在 TEE 外部不可读；存储时使用仅向运行相同已验证二进制文件的 TEE 发布的密钥进行加密，且仅在有限时间内保留，之后合并到运行中的聚合数据中被丢弃。具有物理或远程访问权限的攻击者干扰 TEE，以绕过机密处理保证。
由于 TEE 的保证并非绝对，我们采用纵深防御策略：加密 DRAM、加固 CVM、增强主机监控，以及 OHTTP 中继路由，避免将特定用户的数据定向到特定机器。针对性攻击需要以通过可验证透明度可公开发现的方式破坏整个系统。
无针对性模型交付
模型从 CDN 下载，而非硬编码到应用内，这样对新兴诈骗手法的准确率和覆盖率改进就能触达用户，无需强制应用升级。为此，我们也确保不会向特定用户交付不同的模型。
每个模型版本——包括其 SHA-256 哈希值——都在服务任何用户之前发布到第三方的追加式透明账本。追加式账本是一种只能添加条目、不可修改或删除的公共日志，确保研究者可以审查的防篡改历史。
我们围绕三项保证设计模型下载系统：
- 可审计性：每个模型版本在交付给用户之前，都会公开记录在第三方追加式透明账本上。该账本具备防篡改特性，条目只能新增，无法修改或删除。若要定向投放某个模型，就必须在任何人可核查的账本上公开发布，从而暴露其行为。用户可通过下载应用内透明日志，使用报告中提供的命名空间和周期（epoch），按照以下格式核验账本：https://akd-auditor.cloudflare.com/namespaces/<namespace>/audits/<epoch>。
- 匿名下载请求：模型下载端点无法识别具体是哪位用户在请求模型。所有下载请求均通过匿名凭证进行认证，并经由 OHTTP 中继转发，剥离请求者的 IP 地址，且请求载荷中不包含任何身份标识。模型资源本身由 CDN 提供服务，CDN 仅分发公开文件，不参与决定设备使用哪个模型，因此无法用于定向特定用户。
- 不可定向性：即使是实验也无法向特定用户投递特定模型。客户端会随机化下载请求的时机，实验分组也完全在设备端完成：客户端利用本地生成的随机数自行分配到某个分组，服务器无法将特定用户引导至特定的模型变体。
模型下载与验证机制
- 模型发布：当新模型版本准备就绪时，服务端会对模型权重、分词器及其他资源计算 SHA-256 哈希值，并构建一份清单——一个包含这些哈希值、模型版本和时间戳的 JSON 文档。清单摘要（清单的 SHA-256）由第三方签名方（Cloudflare）使用 Ed25519 密钥进行签名，Meta 并不持有该签名密钥。随后，签名后的清单摘要被发布至第三方追加式透明账本，模型资源则上传至 CDN。
隐私保护实验
在向全球推出新版模型之前，我们必须通过在不同用户子集上测试模型变体来评估其准确性和有效性。这种实验绝不能开辟定向投放（即向特定用户交付特定模型）的路径。模型下载流程正是为杜绝此类风险而设计：
- 客户端侧分组：下载响应中会包含可用的模型配置列表，这些列表通过相同的匿名 OHTTP 和 ACS 流程以随机间隔获取。客户端利用本地生成的随机种子自行分配到某一组，并从这些配置中选择要使用的模型。服务器无法影响特定用户获得哪个模型变体。
- 实验配置防篡改检查：客户端对实验配置执行完整性校验。分组属性发布后不可修改，实验规模只能扩大不能缩小，且分组必须满足最低规模阈值，从而防止攻击者将分组压缩至个体级别以实现定向投放。
- 在分类账上验证模型：每种实验模型变体在投放前都会发布到透明度分类账，签名和验证流程与生产模型完全相同。无论是生产模型还是实验模型，都必须在公开记录后才会上发到设备。
- 匿名化实验指标：不同实验组的性能指标通过博客前文所述的隐私保护联邦分析管道进行测量。如果某个实验组聚合后规模不足以达到 k-匿名性阈值，TEE 将直接屏蔽该数据。
由于整个验证和实验流程都在客户端运行，安全研究人员可以检查应用二进制文件来确认这些检查确实得到了执行。
可验证的模型行为
上文我们阐述了 Meta 和 WhatsApp 都无法将特定模型定向投放给特定用户，以及隐私保护联邦分析管道如何守护用户隐私。但这里还有一个更根本的问题：如果模型的行为无法被独立检验，任何人都无法确认模型仅用于识别潜在诈骗消息。
我们围绕两项核心保证来设计模型验证系统：
- 用户可见性：用户可在设备上直接查看模型的处理结果——哪些消息被扫描、扫描结果如何、使用了哪个模型版本。
- 独立可验证性：如前所述，外部研究人员可以获取运行在用户设备上的精确模型版本，对照透明度分类账验证其完整性，并独立分析其行为。
模型透明度如何运作
- 已发布的模型制品：每个模型版本的哈希值都记录在签名的清单中，该清单存储在用于验证模型投递的同一第三方透明度分类账上。透明度分类账是公开的，任何人都可以查阅，以验证当前投放了哪些模型版本，并确认包括实验变体在内的每个版本都已在公开记录中备案。
- 客户端透明日志：在设备本地，用户可以启用透明日志来记录哪些消息被设备端机器学习模型标记。用户可以通过「账户 > 请求信息 > 诈骗提醒活动」来查看。这些日志包含每次分析的结果（模型是否标记了该消息、是否显示了警告）以及所使用的模型版本。这些日志让用户可以直接、细致地了解系统在其设备上是如何运行的。
- 漏洞赏金计划：在 Beta 发布之前，我们通过漏洞赏金计划与外部安全研究员合作，对我们的系统进行压力测试：
- 隐私架构审查：向研究员提供了包含该功能的早期 APK 构建版本，以确认没有消息内容离开设备、不存在自动上报；以及
- 模型完整性审查：资深 AI/ML 研究员获得了模型权重，以确认模型专用于识别诈骗，而非其他用途。
我们将进一步扩大漏洞赏金范围，纳入模型测试环节——让模型接受自身输入、在不同场景下分析其行为表现，并报告任何模型偏离其声明用途或能力可被系统性规避的发现。
构建可验证的信任与下一步计划
加密联邦分析管道确保，即便是在测量模型性能的过程中，用户隐私也得到保护。透明账本和第三方签名确保我们发布的每一个模型都经过公开记录且不可篡改。此外，发布的模型工件、客户端透明日志以及专门的漏洞赏金计划，确保模型的实际行为可以被独立验证。
如上所述，该功能目前仅在有限的 Beta 阶段逐步推出。我们将在正式生产发布前持续迭代优化，但也想借此机会阐述我们的核心原则。
诈骗分子会不断演进其手段。为了保持领先，我们也将持续进化。
我们欢迎来自用户、安全研究员以及更广泛安全社区的反馈，可通过我们的安全研究计划：联系我们。
致谢
感谢 Ronald Anthony、Shafin Anwarsha、Samyukta Mogily、Lenny Grokop、Riccardo Tortul、Harish Srinivas、Kiran Teja Tummuri、Roman Dashchakivskyi、Chao Zhang、Jitendra Mohanty，以及公司里许多其他为 Scam Alert 贡献力量的同事。