How We’re Building Scam Alert on WhatsApp With End-to-End Encryption and Verifiability Guarantees

TL;DR · AI 摘要
WhatsApp通过端到端加密和本地机器学习模型开发Scam Alert,实现诈骗检测与隐私保护的平衡,用户数据不离开设备且可自主控制功能。
核心要点
- Scam Alert使用本地机器学习模型,确保数据不上传至服务器。
- 用户可随时开启/关闭功能,检测结果仅在用户主动上报时传输。
- 模型训练数据来自用户历史举报,不依赖第三方数据源。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Scam Alert设计
- 设计原则
- 本地处理
- 用户控制
- 无自动上报
- 技术实现
- 本地ML模型
- 隐私保护机制
- 用户主动上报
- 验证流程
- Beta测试
- 安全社区反馈
金句 / Highlights
值得收藏与分享的关键句。
Scam Alert的模型在设备本地运行,消息内容不会上传至WhatsApp或Meta服务器。
用户必须主动上报才能触发数据传输,符合WhatsApp现有举报机制。
模型训练数据来自用户历史举报,确保检测模式与真实诈骗行为同步。
我们如何利用端到端加密和可验证性保证在WhatsApp上构建诈骗预警功能 - Meta工程团队
发布日期
2026年8月12日
分类
安全与隐私
我们如何利用端到端加密和可验证性保证在WhatsApp上构建诈骗预警功能
.entry-meta
.entry-header
WhatsApp致力于在保护用户消息隐私的同时帮助人们保持安全。随着诈骗手段的演变——从冒充身份到社会工程学攻击再到AI生成的诱饵——我们也在不断改进防护措施,确保在端到端加密保护用户个人消息的同时,始终领先于诈骗者。
今天,我们首次向大家展示诈骗预警功能的早期版本,这是一个新的可选功能,通过设备端的机器学习模型运行,向用户发出潜在诈骗信息的预警。没有任何消息内容会离开设备进行分类,也不会自动上报给WhatsApp、Meta或任何其他方。该功能在端到端加密的基础上,实现了用户可控的可选诈骗预警,当模型判断存在高概率诈骗时会触发预警。
在向所有WhatsApp用户开放该功能之前,我们将同步发布这项技术的早期概述,并在Beta版中进行有限范围的推送。同时,我们会继续与漏洞赏金社区合作,对系统进行压力测试。为了验证我们的实现方案,我们欢迎更广泛的安全研究社区提供反馈。
设计原则
设备端机器学习模型的最新进展使得在移动设备硬件上运行准确的文本分类成为可能,而无需承担以往设备端分类所带来的性能、电池消耗或模型体积的权衡。诈骗预警功能非常适合这种方案:模型体积足够小,可以在设备端运行;结构足够简单,便于独立审查;且无需服务器组件即可实现有效检测。我们选择的架构反映了对该系统能力边界和限制的明确权衡。
为此,我们设计诈骗预警功能时遵循了以下原则,这些原则符合端到端加密的核心保证:
- 仅设备端处理:模型及其处理的消息数据始终保留在设备端。
- 无自动上报:在没有用户操作的情况下,WhatsApp无法共享任何用户数据。只有当用户明确选择上报时,消息内容或诈骗检测结果才会传输到我们的服务器,这与WhatsApp现有的用户上报机制保持一致。
- 用户控制:诈骗预警是一个用户可控的工具,为用户提供额外信息,用户可以随时开启或关闭该功能。
诈骗预警的工作原理
诈骗预警功能是可选的。当用户启用该功能后,诈骗预警会将机器学习模型下载到设备上,该模型在设备端运行推理,对来自非联系人的入站消息进行分类,判断其是否匹配已知的诈骗模式。该模型是基于用户向我们举报的诈骗对话中观察到的模式进行训练的。它根据对话结构和语言信号进行概率分类。没有任何内容会自动上报给WhatsApp、Meta或任何第三方。
如果模型将某条消息识别为可能的诈骗尝试,用户会在聊天界面看到警告提示,而对方无法看到该提示。从这里,用户可以选择采取以下行动:阻止、举报或继续对话。如果用户认为警告被错误标记,可以将聊天标记为可信,这样警告将被移除,并且Scam Alert不会再对该聊天进行标记。如果用户标记某条聊天为可信,还可以选择将收到的最后5条消息与WhatsApp共享,以帮助提高该功能的准确性。
基础性保障措施
为坚持上述原则,我们为Scam Alert设计了以下基础性要求和保障措施,每个措施均通过架构强制执行,并可通过扩展的漏洞赏金计划由安全研究人员独立验证,也可通过应用内日志由用户自身进行验证。
- 设备端处理与隐私保护分析:所有推理过程均在设备端完成,且不会将任何消息内容发送到用户设备之外进行分类。为衡量功能是否正常运行所需的最小遥测数据(即聚合和匿名的警告数量及用户操作数量)在保密计算环境中进行处理,并以差分隐私聚合形式发送至WhatsApp。保密联邦分析管道基于可信执行环境(TEE)的保密虚拟机(CVMs)构建。我们选择此方案是为了确保其行为可被独立验证。
- 无针对性模型分发:Meta和WhatsApp均无法向特定用户分发特定模型。所有模型版本(包括实验性变体)在部署前都会发布到公共透明账本上。
- 可验证的模型行为:我们公开模型权重,以便独立安全研究人员验证我们是否专门为诈骗场景设计了该模型。
本文其余部分将详细说明每个要求的技术实现。
设备端处理与隐私保护分析
如上所述,所有推理均在设备端完成。但我们需要确认该功能本身是否有效——即它确实能识别真实诈骗——并了解是否需要更新以应对不断演变的诈骗手段,从而持续改进模型。
为此,我们的方法遵循一套数据最小化原则。消息内容不会离开设备,日志记录的设计也仅限于衡量功能是否按预期运行所需的信号。即使是这些信号,也会在基于TEE的保密计算环境中进行处理,确保处理过程在安全环境中进行,Meta和WhatsApp均无法访问。我们在构建和保护类似Private Processing的系统方面的经验,为该系统的设计提供了指导。仅向Meta和WhatsApp提供匿名的差分隐私聚合数据。差分隐私通过精心校准的噪声添加,提供数学保证,即添加或删除任何个人数据对匿名聚合数据的影响可以忽略不计。因此,这些聚合数据能反映功能在整体人群中的表现,但不会泄露任何个人的信息。
对于Scam Alert,这些数据仅限于两类近似聚合统计:
- 警告次数 – 设备上的模型触发诈骗警告的次数。这能告诉我们模型是否以正确的频率触发警告,这对衡量模型精度和检测模型版本间的回归至关重要。
- 用户操作次数 – 当用户看到警告时,可以选择信任发送者或进行封禁和举报。我们会记录用户采取的操作类别汇总次数。这能告诉我们用户是否认为警告准确,这对衡量误报率至关重要。
保密联邦分析
为了对这些警告和用户操作次数进行匿名化处理,我们构建了一条保密联邦分析流水线,围绕以下隐私和安全保证进行设计,每项保证均通过架构强制执行且可外部验证:
- 设备端数据最小化:对于诈骗预警功能,原始信号不会离开设备。客户端会将它们本地汇总为次数后仅发送这些汇总数据。这些指标在随机时间发送,不包含设备标识符,且时间戳信息仅限于粗略的时间间隔。这确保了传输这些指标的行为本身以及指标内容都无法用于识别用户。
- 保密处理:这些指标在TEE(可信执行环境)中进行处理,TEE是基于CPU的机密虚拟化技术构建的安全硬件环境,允许通过硬件信任根验证软件。在任何数据传输之前,客户端会检查TEE中的验证信息,并与第三方可接受二进制文件日志进行核对。客户端与TEE之间的数据是加密传输的,因此中间任何一方(包括Meta、WhatsApp或任何第三方中继)都无法访问这些数据。
- 安全聚合:单个设备的指标数据无法被Meta、WhatsApp或TEE之外的任何人读取。这些数据会被合并到持续聚合中,只有达到最低群体规模且应用了差分隐私噪声的聚合统计结果才会提供给Meta或WhatsApp。对于诈骗预警功能,设备会直接将预聚合的次数发送至TEE进行安全聚合。
- 可强制执行的保证:在任何数据传输之前,客户端会验证TEE中运行的代码是否与第三方账本上发布的代码一致,并验证隐私参数(如差分隐私ε和δ、k-匿名化阈值)是否符合本地强制约束。如果验证失败或隐私参数不足,客户端将拒绝传输数据。任何试图修改处理保证的尝试都会导致系统关闭或被公开发现。
- 加密恢复检查点:由于流水线需要长期聚合数据,系统会定期保存加密的中间聚合检查点,以防止崩溃导致测量必须从头开始。这些检查点仅包含正在计算的聚合次数部分数据,并且是加密存储的:密钥永远不会离开TEE,因此只有运行相同已验证二进制文件的保密联邦分析TEE才能解密检查点,Meta和WhatsApp都无法读取这些检查点。检查点仅保留有限的恢复所需时间。
- 非目标性:攻击者无法在不试图入侵整个系统的情况下针对特定用户。所有指标均通过OHTTP中继传输,该中继会剥离请求者的IP地址,并使用匿名凭证进行身份验证,使系统能够在不识别具体设备的情况下验证指标是否来自合法的WhatsApp客户端。这种设计限制了小规模攻击的影响,确保攻击者无法利用其针对特定用户的数据。
- 可验证透明性:我们将为用户提供应用内功能,使其能够查看与保密联邦分析流水线共享的数据内容、应用的隐私参数(如差分隐私ε和δ、k-匿名化阈值)以及每个安全会话的建立细节。我们将发布驱动流水线的CVM镜像二进制文件及其隐私相关组件的源代码,使安全研究人员能够独立验证发布的代码与TEE中的实际运行代码完全一致。我们还将扩展漏洞赏金计划,将保密联邦分析流水线纳入范围,并发布其设计的详细工程白皮书。
该流水线的基础建立在Meta的同行评审联邦分析工作中,该工作在《PAPAYA联邦分析框架:隐私、可扩展性与实用性工程》(USENIX NSDI 2025)中公开阐述。在此,我们描述了Scam Alert如何应用并扩展这一基础。
保密联邦分析的工作原理
流水线的工作流程如下:
- 设备端数据收集:数据被收集并存储在独立的本地存储中,与其他应用数据隔离。保密联邦分析系统只能访问应用明确提供给它的数据。硬编码的隐私防护机制强制规定数据生命周期、作用范围和访问权限。对于Scam Alert而言,仅包括警告事件计数和用户操作计数。
- 任务选择:在随机间隔期间,当设备处于空闲状态且符合每日资源限制时,客户端通过OHTTP连接到应用服务器。客户端使用匿名凭证进行身份验证,证明其是合法的WhatsApp客户端而不暴露具体身份,并获取流水线的活动任务列表。对于每个任务,客户端会检查隐私参数(ε、δ和k-匿名化阈值)是否符合本地防护规则、设备是否有新指标需要发送、参与该任务是否会超出每日限制。客户端可以拒绝任何不符合这些条件的任务。
- 本地转换:对于客户端接受的任务,它会从本地存储中检索相关数据,并通过将原始信号转换为指定时间段(如每日警告计数、每日用户操作计数)的匿名计数,在设备端执行所需聚合操作。仅传输聚合后的计数,原始信号保留在设备上,并在保留期结束后自动删除。
- 验证、认证与会话建立:客户端与协调器可信执行环境(TEE)建立远程验证 + 传输层安全(RA-TLS)会话。验证引证包含对协调器的度量值,客户端会将其与第三方透明账本进行交叉核对,确保仅连接满足可验证透明性保证的代码。客户端使用匿名凭证进行认证,连接通过第三方OHTTP中继路由,该中继会剥离请求者的IP地址。由于度量值在设备与TEE之间端到端加密,中继无法读取这些数据。
- 协调器TEE — 临时处理:加密后的度量值到达运行在TEE上的无状态协调器。协调器验证客户端的隐私配置与任务配置是否匹配,将来自多个设备的度量值进行批处理,并将批处理后的度量值转发至相应的聚合器TEE。对于诈骗预警功能,这些度量值是预先聚合的统计数。
- 聚合器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 哈希值)在提供给任何人之前,都会发布在第三方仅追加透明度账本上。仅追加账本是公开日志,条目可添加但永不修改或删除,确保研究人员可检查的防篡改历史记录。
我们围绕以下三个保证设计了模型下载系统:
- 可审计性:每个模型版本在提供给任何用户之前,都会在第三方仅追加透明度账本上公开记录。账本具有防篡改特性,条目可添加但永不修改或删除。分发定向模型需要将其发布在任何人都可检查的账本上,使尝试变得公开可发现。要检查账本,用户可以下载其应用内的透明度日志,并使用报告中的命名空间和纪元进行确认,格式如下:https://akd-auditor.cloudflare.com/namespaces/<namespace>/audits/<epoch>。
- 匿名下载请求:模型下载端点无法确定请求模型的用户。所有下载请求均使用匿名凭证进行身份验证,并通过剥离请求者 IP 地址的 OHTTP 中继路由,请求负载中不包含任何身份选择器。模型资产本身由 CDN 提供,仅分发公开发布的文件,不参与决定设备使用哪个模型,因此无法用于针对特定用户。
- 非针对性:即使通过实验,也无法将特定模型分发给特定用户。客户端会随机化下载请求的时间,实验组分配完全在设备端完成:客户端使用本地生成的随机数将自身分配到组,因此服务器无法将特定用户引导到特定模型变体。
模型下载与验证流程
- 模型发布:当新模型版本准备部署时,服务器会计算模型权重、分词器和其他资产的SHA-256哈希值,并构建一个清单文件(manifest)——这是一个包含这些哈希值、模型版本和时间戳的JSON文档。清单摘要(清单的SHA-256哈希值)会提交给第三方签名机构(Cloudflare)使用Ed25519密钥进行签名。Meta并不持有签名密钥。签名后的清单摘要会被发布到第三方仅追加的透明性账本上,同时模型资产会上传至CDN。
- 匿名下载请求:客户端通过OHTTP连接到模型下载端点,使用匿名凭证进行身份验证。OHTTP中继会剥离客户端的IP地址——中继可以看到IP地址但无法解密请求,服务器可以看到请求但只能看到中继的IP地址。服务器会返回清单文件、数字签名以及模型资产的CDN链接。
- 客户端验证:在使用任何下载的模型之前,客户端会执行多步骤验证。首先,它会计算清单摘要并使用硬编码的Cloudflare Ed25519公钥验证数字签名——确认清单是由Cloudflare签名而非Meta或其他方伪造。接下来,它会将清单摘要与透明性账本进行交叉核对,并执行新鲜度检查以防止使用过时条目进行重放攻击。最后,它会从CDN下载模型资产并验证每个资产的SHA-256哈希值是否与清单一致。如果任何步骤失败,客户端将拒绝加载该模型。
- 模型在设备上加载:只有在所有验证步骤通过后,客户端才会安装并使用该模型。
私有实验
在全局发布新模型版本之前,我们必须通过向用户子集提供模型变体来评估其准确性和有效性。此类实验必须防止出现定向分发路径(即向特定用户分发特定模型)。模型下载流程的设计可以防止这种情况:
- 客户端分组分配:下载响应中包含可用的模型配置,这些配置通过相同的匿名OHTTP和ACS流程以随机间隔获取。客户端使用本地生成的随机种子将自身分配到某个组,并从这些配置中选择要使用的模型。服务器无法影响特定用户接收到的模型变体。
- 实验配置完整性检查:客户端会对实验配置执行完整性检查。组属性在发布后无法修改,实验规模只能扩大(不能缩小),且组必须满足最小规模阈值,防止攻击者缩小组规模以针对个别用户。
- 实验模型上账本:每个实验模型变体在提供服务前都会被发布到透明性账本,使用与生产模型相同的签名和验证流程。无论是生产模型还是实验模型,任何模型在到达设备前都必须经过公开记录。
- 匿名化实验指标:不同实验组的性能指标通过本文早前描述的相同机密联邦分析管道进行测量。如果某个实验组在聚合后无法满足k-匿名性阈值,TEE会完全抑制这些数据。
由于整个验证和实验流程在客户端运行,安全研究人员可以检查应用二进制文件以确认这些检查是否被执行。
可验证的模型行为
我们之前已经说明,Meta 和 WhatsApp 都无法将特定模型交付给特定用户,且保密的联邦分析流水线如何保护隐私。但这些内容并未回答一个更根本的问题:在不独立检查模型行为的情况下,如何验证该模型仅用于识别潜在的诈骗信息?
我们的模型验证系统围绕以下两个保证进行设计:
- 用户可见性:用户可以直接在设备上查看模型的行为——包括扫描了哪些消息、分析结果是什么,以及使用了哪个模型版本。
- 独立可验证性:如前所述,外部研究人员可以获取在用户设备上运行的精确模型,通过透明性账本验证其完整性,并独立分析其行为。
模型透明性的工作原理
- 发布的模型构件:每个模型版本的哈希值都会记录在第三方透明性账本的签名清单中,该账本用于验证模型交付。透明性账本是公开的,因此任何人都可以检查它以验证正在提供哪些模型版本,并确认所有版本(包括实验版本)都已公开记录。
- 客户端透明性日志:在设备本身,用户可以启用透明性日志,记录设备上的机器学习模型标记了哪些消息。用户可以通过前往“账户 > 请求信息 > 诈骗警报活动”查看这些日志。透明性日志中包含每次分析的结果(模型是否标记了消息以及是否显示了警告),以及使用的模型版本。这些日志让用户能够直接、细致地了解系统在其设备上的运行方式。
- 漏洞赏金计划:在 Beta 版本发布之前,我们通过漏洞赏金计划邀请外部安全研究人员帮助我们对系统进行压力测试:隐私架构审查:研究人员获得早期访问的 APK 构建版本,以确认没有消息内容离开设备且没有自动报告功能;模型完整性审查:经验丰富的 AI/ML 研究人员获得模型权重,以确认该模型是专门为诈骗设计的,且没有其他用途。
我们将扩大漏洞赏金计划的范围,包括对模型进行测试,以验证其在各种场景下的行为,并报告模型偏离其声明目的或其能力可被系统性规避的任何发现。
构建可验证的信任与下一步计划
保密的联邦分析流水线确保即使测量模型性能的行为也能保护用户隐私。透明性账本和第三方签名确保我们发布的每个模型都公开记录且可检测篡改。发布的模型构件、客户端透明性日志以及专门的漏洞赏金计划确保模型的行为可以被独立验证。
如上所述,该功能目前仅以有限的 Beta 容量开始推出。在生产之前,我们将在 Beta 阶段继续迭代和改进该功能,但我们现在想借此机会阐述我们的原则。
诈骗者将继续演变他们的策略。为了保持领先,我们也将持续改进。
我们通过安全研究计划欢迎用户、安全研究人员以及更广泛的安全社区提供反馈:Contact us 。
致谢
感谢 Ronald Anthony、Shafin Anwarsha、Samyukta Mogily、Lenny Grokop、Riccardo Tortul、Harish Srinivas、Kiran Teja Tummuri、Roman Dashchakivskyi、Chao Zhang、Jitendra Mohanty 以及公司内部的许多其他同事,他们为实现 Scam Alert 做出了贡献。