2026 年 5 月 1 日，Meta 工程博客发布了 HSM Backup Key Vault 架构的最新进展。这套系统为 WhatsApp 和 Messenger 的端到端加密（E2EE）备份提供基础设施，让用户通过恢复码保护聊天历史，而恢复码存储在防篡改的硬件安全模块中。Meta、云存储服务商以及任何第三方均无法访问备份内容。截至 2026 年 1 月，Meta 旗下产品每天处理超过 1000 亿条 E2EE 消息。备份数据的安全是这一生态中最容易被忽视、也最难解决的环节。
端到端加密保障的是传输过程中的数据机密性：消息离开发送者设备后，只有接收者设备能解密。然而用户的聊天历史需要备份到云端，以防止设备丢失或更换时数据永久消失。备份数据长期驻留在云存储服务商的基础设施上，与传输加密面临的威胁模型截然不同。如果备份数据以明文形式存储，云存储服务商、内部员工或任何入侵者都能读取完整的聊天记录。这比传输层攻击的攻击面更大、持续时间更长。
本文围绕 Meta 的 HSM 集群架构展开，分析其密钥管理、协议设计、验证机制以及工程实践，为安全工程师和架构师提供可参考的设计思路。相关的大规模安全配置管理思路可参考Meta 如何在 AI 规模下实现配置安全，更多关于头部科技公司软件安全实践的横向对比见Project Glasswing：12 家科技巨头的软件安全。
端到端加密备份的核心难题
端到端加密的传输层已经有成熟方案：Signal 协议、双棘轮机制、前向保密等技术在业界得到广泛应用。备份加密面临的挑战与之有本质区别。
传输加密保护的是一个瞬时通道。会话结束后，中间人即使获取了历史流量也无法解密。备份数据则长期静止存储在第三方基础设施上。攻击者有充足的时间尝试获取访问权限：通过云服务商的内部权限、存储系统的漏洞、甚至法律强制令状。备份加密的安全性完全依赖于密钥管理方案的设计质量。
最直接的方案是让用户自行管理加密密钥。用户备份时生成随机密钥，加密后上传，恢复时手动输入。问题在于用户体验：一个 64 位的十六进制字符串，绝大多数用户无法安全保管。密钥一旦丢失，备份数据永久不可恢复。
Meta 的方案在两种保护模式之间做了权衡：手动管理 64 位密钥，或者使用密码保护。选择密码模式时，密钥存储在 HSM 保险库中，通过 OPAQUE 协议完成密码验证，密码本身永远不离开用户设备。这一设计将安全性与可用性统一在同一套架构中。
架构深度解析：HSM 备份密钥保险库
每备份独立密钥
每个备份在创建时生成一个独立的随机对称密钥。这一设计遵循最小权限原则：即使单个密钥泄露，影响范围限定在单一用户的单次备份。密钥之间没有任何层级关系或派生关系，避免了单点故障在整个用户群中扩散。
双模式保护
Meta 提供两种保护备份密钥的方式，用户可在创建备份时选择。
第一种是手动模式：系统生成 64 位密钥（以十六进制字符串形式呈现），用户自行记录保管。恢复备份时需要手动输入完整的密钥。这一模式的安全边界很清晰：只要密钥不被泄露或遗忘，备份数据就是安全的。代价在于用户负担较重，密钥丢失意味着数据永久不可恢复。
第二种是密码模式：用户设置一个自定义密码，备份密钥存储在 HSM 保险库中。密码本身通过 OPAQUE 协议进行验证，任何环节都不传输明文密码。这一模式对用户更友好，但引入了密码强度和暴力破解的额外考量。
HSM 保险库的核心设计
硬件安全模块（HSM）是整个密码保护模式的信任根。HSM 是经过物理防护的专用硬件，具有防篡改特性：任何试图物理访问或提取密钥的操作都会触发安全机制，导致密钥被清零。Meta 使用的 HSM 集群地理分布在多个数据中心，通过多数共识复制协议保证数据一致性和可用性。单个数据中心的完全损毁不会导致密钥丢失。
HSM 内部执行严格的密码验证尝试限制。超过预设阈值后，密钥永久不可访问。这一机制从根本上杜绝了暴力破解的可能性：攻击者无法通过无限次尝试来猜测密码，因为 HSM 会在尝试次数耗尽后主动销毁密钥。这一安全属性由硬件保证，不受软件层面的漏洞影响。
OPAQUE 协议：密码不离开设备
OPAQUE 是一种密码认证密钥交换（PAKE）协议，其核心特性在于密码的明文形式永远不离开用户设备。传统的密码验证方案需要服务器接收并验证密码（即使是哈希形式），这就要求密码在某个时刻以某种形式出现在网络传输中。OPAQUE 通过密码盲化和服务器端加密文件，使得服务器在验证过程中仅接触到经过变换的数据，无法获取原始密码。
在 Meta 的实现中，客户端与 HSM 通过加密消息交换完成认证。ChatD 服务作为前端代理处理客户端连接，但 ChatD 仅转发加密消息，无法看到密钥或密码的内容。这种协议层面的信息隔离确保了即使 ChatD 被攻破，攻击者仍然无法获取存储在 HSM 中的密钥。
跨数据中心地理分布与多数共识
HSM 集群的部署需要同时满足可用性和安全性。Meta 将 HSM 节点分布在多个地理位置分散的数据中心。多数共识复制协议确保写入操作只有在多数节点确认后才算成功。这意味着少数节点的故障或被攻破不会影响系统的正确性。
地理分布还提供了物理层面的灾难恢复能力。火灾、地震或区域性断电等事件只会影响部分节点，多数节点仍然保持可用。对于全球数十亿用户的备份数据而言，这一韧性设计是基本要求。
从工程视角看，多数共识复制还解决了 HSM 节点升级和维护的难题。运维人员可以逐个将节点下线进行固件更新或硬件更换，只要集群中仍有足够数量的节点在线，系统就能持续提供服务。这种滚动升级策略在大规模基础设施中是标准做法，而多数共识协议为其提供了理论基础。
ChatD：协议代理层
ChatD 是 Meta 专门开发的前端服务，负责处理客户端与 HSM 集群之间的连接管理和认证逻辑。客户端与 HSM 的所有通信都通过 ChatD 中转，但 ChatD 的设计严格限制了它能看到的信息。
在 OPAQUE 协议的交互过程中，客户端和 HSM 之间交换的是密码盲化后的数据。ChatD 仅负责路由这些加密消息，无法解读消息内容，也无法获取密码或密钥。即使 ChatD 服务被完全攻破，攻击者仅能干扰消息传递（造成拒绝服务），无法获取用户的密码或备份密钥。
这种"最小权限代理"的设计模式在安全架构中很常见：中间层只做路由，不做解密。将信任边界缩小到最小必要范围，降低了单点攻破对整个系统的影响。
加密与解密流程
整个生命周期可以分解为五个清晰的步骤。
第一步：密钥生成。 用户触发备份时，客户端在本地生成一个随机的对称加密密钥。这个密钥的唯一性和随机性由密码学安全的随机数生成器保证。
第二步：备份数据加密。 客户端使用生成的密钥对聊天历史进行对称加密。加密算法采用工业标准的对称加密方案。加密完成后，密文数据准备好上传。
第三步：密钥保护与存储。 根据用户选择的保护模式，密钥被不同方式处理。手动模式下，密钥展示给用户记录。密码模式下，客户端通过 OPAQUE 协议将密钥安全存储到 HSM 保险库中。密钥在传输过程中被密码学包装，HSM 收到后将其与用户的密码凭证绑定存储。
第四步：上传云存储。 加密后的备份数据上传到云存储服务。由于数据已经过加密，云存储服务商仅能看到密文。备份密钥不随数据一起上传，云存储服务商没有解密能力。
第五步：恢复流程。 手动模式下，用户输入 64 位密钥直接解密。密码模式下：用户输入密码，客户端通过 OPAQUE 协议与 HSM 交互验证身份。HSM 验证通过后，返回加密保护的备份密钥。客户端使用该密钥解密从云存储下载的备份密文。如果密码验证失败次数超过阈值，HSM 永久删除对应密钥，备份数据不可恢复。
这一流程的设计要点在于密钥与密文的物理隔离：密钥存储在 HSM 硬件中，密文存储在云存储中，两者需要同时拥有才能恢复数据。攻击者即使同时攻破云存储和 ChatD 服务，仍然无法获取密钥，因为密钥存储在具有物理防护的 HSM 中。
值得注意的是，整个流程中密钥从未以明文形式出现在客户端设备之外。在密码模式下，密钥被 OPAQUE 协议的密码学包装保护后传输到 HSM，在 HSM 内部存储时也处于加密状态。解密时，密钥同样以密码学保护的形式返回给客户端。这种端到端的密钥保护意味着 Meta 的基础设施中没有任何一个组件能看到密钥的明文。
Over-the-Air 密钥分发
2026 年的公告中，Meta 披露了一项重要的基础设施更新：Over-the-Air（OTA）Fleet Key Distribution。
问题背景
客户端在建立与 HSM 集群的安全会话之前，需要验证集群的公钥。这是防止中间人攻击的关键步骤：如果客户端无法确认公钥的真实性，攻击者可以替换公钥并拦截通信。密钥分发问题在密码学中被称为"引导问题"（bootstrapping problem），即在缺乏预共享信任的情况下建立第一条安全通道。
WhatsApp 的解决方案是将密钥硬编码在应用程序中。每次部署新的 HSM 集群时，通过应用更新将新公钥分发到所有客户端。这一方案安全性高：密钥经过应用签名链保护，攻击者需要在应用商店层面进行替换才能分发伪造密钥。代价是依赖应用更新的发布周期和用户升级速度，新集群上线后可能需要数周才能覆盖全部用户。
Messenger 面临不同的约束。Meta 需要在不强制应用更新的情况下部署新的 HSM 集群，以实现更快的基础设施迭代和灾难恢复能力。因此需要一种动态分发密钥的机制，同时保持与硬编码方案相当的安全性。
双重签名验证
Messenger 的 OTA 方案采用双重签名架构。验证包首先由 Cloudflare 签名，然后由 Meta 反签名。Cloudflare 作为独立的第三方，维护审计日志记录每一次签名操作。
这一设计的信任模型是：攻击者需要同时攻破 Cloudflare 和 Meta 的签名系统才能分发伪造的公钥。单一机构的密钥泄露不会导致客户端接受恶意密钥。Cloudflare 的审计日志提供了事后追溯能力：任何异常的签名操作都可以被检测到。
审计与可追溯性
Cloudflare 维护的审计日志是整个 OTA 机制的可信锚点。日志记录每个签名请求的时间、来源和内容，为安全社区提供了独立验证的依据。这一设计体现了"信任但要验证"的安全理念：即使信任 Cloudflare 的签名操作，仍然通过日志确保操作的可审计性。
透明的集群部署
Meta 承诺在工程博客上公开发布每个新 HSM 集群的安全部署证据。由于 HSM 集群的部署频率很低（每隔几年一次），公布这些信息的成本很小，而为安全社区提供的价值很大。
透明部署的核心理念是：安全系统的可信度来自于可验证性，而非保密性。公开部署证据让独立研究人员可以审查 HSM 集群的初始化过程、密钥生成仪式以及安全策略的配置。这一做法借鉴了证书透明度（Certificate Transparency）的设计思想：通过公开日志增强系统的可信度。
用户可以在安全设置中查看并验证当前生效的 HSM 集群信息，将本地客户端的配置与公开记录进行比对。这种端到端可验证性是 Meta 安全架构的重要设计目标。
透明部署的实践也与近年来的安全社区趋势一致。Google 的 Certificate Transparency 日志、Apple 的安全证书透明度计划都采用了类似的思路：将安全关键操作记录在公开的、不可篡改的日志中，让任何感兴趣的人都可以审查。Meta 在 HSM 集群层面实施这一实践，是对"通过不透明性获得安全性"这一传统观念的有力回应。
学术与独立验证
Meta 的 HSM 备份架构经历了多轮外部安全审查，涵盖学术研究和专业渗透测试两个维度。
CRYPTO 2023：形式化验证与漏洞发现
Davies、Evangelista Rosseto、Meiklejohn、Stebila 和 Valenta 在 CRYPTO 2023 上发表了 WhatsApp Backup Protocol（WBP）的首个形式化安全分析。研究团队在通用可组合（UC）安全框架下验证了协议的安全性。UC 框架是密码学协议分析的金标准，它要求协议在任何上下文中都保持安全性，而非仅在特定攻击模型下。
这项分析发现了一个重要漏洞：被污染的服务器（即被攻击者控制的 HSM）可以进行超出预期数量的密码猜测。协议的原始设计中，对服务器端的密码猜测限制依赖于 HSM 的诚实行为。如果 HSM 被攻破，这一限制就会失效。具体而言，恶意 HSM 可以利用协议中的信息泄露，在每次验证尝试中排除多个密码候选，从而将暴力破解效率提高数个数量级。WhatsApp 在论文发表前已经修复了这一漏洞。
这个发现的意义超出 WhatsApp 本身。它说明即使采用了 HSM 这样的硬件信任根，协议层面的设计仍然需要经过形式化验证。硬件保证了密钥的物理安全，但协议逻辑中的漏洞可以让攻击者绕过这些物理防护。UC 框架的分析方法能够系统性地发现这类问题，因为它不信任任何协议参与者的行为，而是证明在任意环境下的安全性。
NCC Group 独立审计
NCC Group 在 2021 年对 HSM Key Vault 进行了独立安全审计。审计投入 35 人天，历时 5 周，由 3 名安全顾问参与。审计范围覆盖 HSM 固件、密钥管理协议、ChatD 服务实现以及客户端密码处理逻辑。NCC Group 的审计报告提供了专业安全机构对系统设计的独立评估。
CCS 2024：客户端认证攻击修复
CCS 2024 上发表的"Password-Protected Key Retrieval with(out) HSM Protection"论文进一步分析了 Davies 等人发现的客户端认证攻击，并提出了修复方案。这篇论文的研究推动了 OPAQUE 协议实现的安全加固，确保客户端在密钥检索过程中的身份验证不被绕过。
这三轮独立验证形成了完整的覆盖：CRYPTO 2023 的形式化分析验证了协议的理论安全性，NCC Group 的工程审计验证了实现质量，CCS 2024 的研究修补了理论到实践之间的剩余缝隙。
共享 HSM 基础设施
HSM 备份密钥保险库并非独立运行的服务。Meta 将这套基础设施扩展到了其他安全敏感的功能。
联系人隐私存储（IPLS）
2024 年，Meta 引入了 IPLS（Identity and Privacy Lockbox Service），使用同一套 HSM 集群为联系人数据提供加密存储。联系人的姓名、电话号码等敏感信息在设备端加密后存储到云端，解密密钥保存在 HSM 中。这一设计确保 Meta 的服务器无法读取用户的联系人信息。
密钥透明度（Key Transparency）
2023 年推出的 Key Transparency 功能使用基于 AKD（Auditable Key Directory）的开源库构建。用户可以验证其他用户的公钥是否被篡改，防止中间人攻击。Cloudflare 对 Key Transparency 系统进行了独立审计。这一功能同样运行在共享的 HSM 基础设施之上。
共享基础设施的经济效益明显：HSM 集群的部署和维护成本很高，多个安全功能共享同一套硬件可以显著降低单位成本。更重要的是，多个功能共享同一信任根意味着对所有这些功能的安全审计可以集中进行，减少了安全评估的盲区。
从架构演进的角度看，HSM 保险库从单一功能（备份密钥保护）逐步扩展为多功能的共享安全基础设施，这一路径反映了大规模系统中常见的"平台化"趋势。当一个安全组件经过充分验证和审计后，将其能力扩展到其他场景的边际成本很低，而收益是安全架构的整体一致性。IPLS 和 Key Transparency 的引入表明 Meta 正在将 HSM 保险库定位为核心安全基础设施，而非某个产品线的专用组件。
企业安全架构启示
从 Meta 的实践中，可以提炼出五条适用于企业安全架构的设计原则。
第一，密钥与数据的物理隔离。加密密钥和密文数据应存储在不同物理位置、由不同系统管理。Meta 将密钥存储在 HSM 中、密文存储在云存储中，攻击者需要同时突破两套系统才能获取明文数据。这种纵深防御的设计显著提高了攻击成本。
第二，密码验证必须限制尝试次数。使用密码保护密钥时，必须在可信执行环境（如 HSM）中实施严格的尝试次数限制。无限制的密码验证等效于将密钥交给攻击者。Meta 通过 HSM 硬件保证这一限制不可绕过。
第三，信任锚点需要外部验证。安全系统的可信度不应依赖于单一人或机构的声明。Meta 通过学术同行评审、专业审计机构、第三方签名（Cloudflare）和公开审计日志构建了多层验证体系。每一层验证都由不同的利益相关方执行，降低了共谋或疏漏的风险。
第四，部署透明化。安全关键组件的部署过程应当公开并可验证。Meta 公布 HSM 集群的部署证据，让安全社区可以独立审查。虽然这种透明度不能完全排除后门的可能性，但它大幅增加了植入后门的难度和被发现的风险。
第五，协议设计应考虑最坏情况。UC 框架的验证之所以有价值，是因为它不假设服务器的诚实行为。Meta 在 CRYPTO 2023 论文中的经验表明，即使 HSM 通常被认为是可信的，协议设计仍然需要考虑 HSM 被攻破的场景。这种"零信任"的设计理念在密钥管理系统中尤为重要。
这五条原则并非 Meta 独有的发现。它们是密码学和安全工程领域长期积累的共识。Meta 的价值在于将这些原则在一个大规模、面向数十亿用户的系统中完整落地，并通过多轮独立验证确认了实现质量。对于正在构建类似系统的安全工程师而言，Meta 的实践提供了一个经过实战检验的参考架构。
FAQ
HSM 保险库被物理攻破后会怎样？
HSM 具有防篡改设计。任何物理侵入尝试会触发密钥清零机制。此外，HSM 集群采用多数共识复制，单个节点的物理攻破无法影响系统整体的正确性。攻击者需要同时物理攻破分布在多个地理位置的多数节点，这在现实中极难实现。
忘记密码后还有办法恢复备份吗？
密码模式下，密码验证失败次数超过 HSM 预设阈值后，密钥被永久删除，备份数据无法恢复。这是安全设计的固有代价：为了防止暴力破解，必须牺牲部分可用性。用户可以选择手动模式（64 位密钥）作为替代，但同样需要安全保管密钥。2025 年 10 月，WhatsApp 增加了通行密钥支持，用户可以通过指纹、面部识别或设备屏幕锁代替密码，降低了遗忘风险。
Meta 能否通过法律强制令获取备份数据？
Meta 可以访问存储在云端的加密备份数据（密文），但无法获取解密密钥。密钥存储在 HSM 中，Meta 的工程师没有提取密钥的技术手段。法律强制令可以要求 Meta 交出密文数据，但无法要求交出密钥，因为密钥在物理上无法被 Meta 提取。
OPAQUE 协议与传统密码哈希有什么区别？
传统方案中，服务器存储密码的哈希值，验证时客户端发送明文密码。OPAQUE 协议通过密码盲化技术，使得密码的明文形式永远不离开用户设备。服务器仅处理经过密码学变换的数据，即使服务器被完全攻破，攻击者也无法获取原始密码。这比传统的加盐哈希方案提供了更强的安全保障。
为什么选择 Cloudflare 作为第三方签名方？
Cloudflare 作为独立的全球基础设施提供商，具有独立的密钥管理和安全审计体系。选择 Cloudflare 意味着攻击者需要同时攻破 Meta 和 Cloudflare 两套独立的签名系统。Cloudflare 维护的审计日志为每一次签名操作提供了不可篡改的记录，增强了系统的可审计性。Meta 也可以选择其他独立的第三方，但 Cloudflare 在全球基础设施和安全社区中的声誉使其成为合适的选择。
参考资料
- Meta Engineering Blog: HSM-based Backup Key Vault（2026/05/01）
- Meta Engineering Blog: End-to-End Encrypted Backups（2021/09/10）
- Davies, Evangelista Rosseto, Meiklejohn, Stebila, Valenta. "Security Analysis of the WhatsApp End-to-End Encrypted Backup Protocol." CRYPTO 2023.
- NCC Group. Independent Security Assessment of HSM Key Vault（2021）
- "Password-Protected Key Retrieval with(out) HSM Protection." CCS 2024.
- OPAQUE: Asymmetric PAKE Protocol（IETF CFRG）
- Meta: IPLS Contact Privacy Storage（2024）
- Meta: Key Transparency with AKD（2023）
- WhatsApp Passkey Support Announcement（2025/10）