自动密钥验证功能正式推出

# 引入自动密钥验证 来源：https://signal.org/blog/automatic-key-verification/ 一张蓝黑色背景的钥匙风格化插画。 Signal 现在提供一项名为“自动密钥验证”的功能，它补充了现有的安全号码系统（https://signal.org/blog/safety-number-updates/）。Signal 始终采用端到端加密，而自动密钥验证提供了一种额外的、更为简化的方式，用于确认在你与端到端加密会话的另一“端”之间没有意外的一方介入。 它的工作原理是通过一个由你、你的 Signal 联系人和第三方审计者共同执行的验证体系，该体系能够提供与手动验证安全号码同等的保证。与安全号码不同，这些验证是独立完成的，不需要面对面会面或辅助通信渠道。 这个验证体系确保了电话号码或用户名与其公钥之间的关联在 Signal 生态系统中具有全局一致性，并且对所有参与者透明。这可以防止在密钥所有者不知情的情况下密钥被替换的场景——例如，若恶意方攻破了 Signal，并将不同的密钥与您联系人的电话号码关联起来。 要查看此功能的实际效果，请前往 Signal 联系人的个人资料，点击“查看安全号码”，然后点击“自动密钥验证”标题下的“自动验证”按钮。当该功能可用且验证成功时，按钮会显示绿色对勾和“加密已验证”字样。随着时间的推移，此验证加上您的 Signal 联系人和第三方审计者持续执行的验证，可确保该 Signal 联系人的密钥在 Signal 生态系统中保持一致。 一系列演示自动密钥验证流程的截图。 此功能基于一种称为“密钥透明度”的概念构建，我们将在本文其余部分使用这个术语，解释我们为何构建密钥透明度系统，并对其工作原理进行高层次的概述。 ## 公钥和私钥入门 非对称加密（https://en.wikipedia.org/wiki/Public-key_cryptography）使你能够向朋友发送只有你的朋友才能阅读的消息。它涉及一对数学上关联的密钥，称为公钥和私钥，可用于包括发送和接收消息在内的各种应用。 想象你有一个带投信口的带锁邮箱。你的公钥就像你的邮箱地址——你可以与任何想给你寄信的人分享。你的私钥就像邮箱钥匙。只有你拥有它，你可以用它来阅读寄给你的消息。任何人都可以把信件投进你的邮箱（用你的公钥加密），但只有你能打开并阅读（用你的私钥解密）。你的邮箱地址必须公开；如果没人知道往哪里寄，你就无法收到信件。 当你注册 Signal 时，Signal 应用会在注册过程中为你生成一对公钥/私钥（1（https://signal.org/blog/automatic-key-verification/#fn:1））。私钥保留在你的设备上——只有你，而不是 Signal，也不是其他任何人，能够访问这个私钥。你的公钥会被发送给 Signal，Signal 充当所有用户公钥的中央目录。当你想给另一位 Signal 用户发送消息时，你向 Signal 请求你联系人的公钥，然后用 Signal 返回的密钥和你的私钥加密你的消息。 ## 中间的 Mallory 攻击 发送消息需要获取收件人的公钥，而获取公钥意味着依赖中央目录。理论上，恶意目录操作者可能实施所谓的“中间的 Mallory”（https://en.wikipedia.org/wiki/Man-in-the-middle_attack）攻击，尽管这样做需要外部人员绕过主要云服务提供商的安全措施，或者需要拥有特权的内部人员故意针对特定账户。但即使这是一种非常高级且不太可能发生的攻击，我们仍然想要防范它。我们将继续使用邮箱类比来说明这种攻击在假设情况下会如何运作。 假设 Bob 想给他的朋友 Alice 发送一份喝咖啡的邀请，于是 Bob 在中央目录中查找她的邮箱地址。如果目录因某种原因被对手（Mallory）攻破，它可能会将 Bob 引向 Mallory 的邮箱，而不是 Alice 的。当 Bob 把邮件寄到他以为是 Alice 的邮箱时，实际上却寄到了 Mallory 的邮箱。Mallory 接着用自己的邮箱钥匙取出 Bob 的消息，阅读它，如果她愿意还可以修改它，然后把它放进一个新信封，转发到 Alice 的邮箱。 在她的修改中，Mallory 可以更改咖啡店地点或见面时间，导致 Alice 在错误的地点或时间出现。Alice 不会知道消息被拦截或篡改过，因此在她看来，这条消息看起来直接来自 Bob。与此同时，Bob 会徒劳地等待 Alice 出现。即使 Mallory 选择不更改 Bob 的消息，她能够阅读消息本身就构成了对通信隐私的严重侵犯。 关于咖啡的沟通误会风险相对较低，但这种攻击在其他场景中可能造成更大的伤害。 一张说明“中间的 Mallory”攻击的示意图。Mallory 拦截了 Bob 的信件，在转发给 Alice 之前用她自己的信件替换了它，而 Bob 和 Alice 都没有意识到干扰。 这种攻击之所以奏效，是因为 Bob 从未真正验证过 Alice 的地址。Bob 只是相信目录中列出的邮箱就是她的，这是一个合理的假设。 但是，如果 Bob 想格外谨慎，他可以通过当面见面或某种辅助的、可信的通信渠道（2（https://signal.org/blog/automatic-key-verification/#fn:2））直接向 Alice 询问她的地址，但如果 Alice 和 Bob 严格来说是笔友，这可能不可行。 那么，如果 Bob 无法与 Alice 当面见面或使用辅助渠道，他该如何验证 Alice 的地址呢？ 在本文其余部分，我们将概述我们如何设计一个系统，使 Bob 无需直接与 Alice 通信即可自动验证中央目录中的数据。 ## 设计密钥透明度系统的类比 我们可以帮助 Bob 验证目录中 Alice 地址正确性的一种方法是，记录对目录所做的每一次更改。如果有人更改了目录中 Alice 的地址，这一更改将被人捕获到按时间顺序排列的日志中，因此是可检测的。为了具体说明，让我们扩展邮箱类比。 假设一位职员在城市邮局的公共账本中记录每个人的地址变更。每当有人获得新地址或更新现有地址时，职员会在不断增长的账本末尾添加一个新页面，并在那里记录地址变更。职员使用永久性记号笔，因此一旦写下内容，任何人都不能返回某一页撕掉或修改其内容。任何人都可以到邮局在账本中查找地址，包括自己的地址。 ### 使用账本 对于任何给定的地址，邮局顾客可以通过两种方式与账本互动： 1. 像 Bob 这样的顾客可以查找其他人（如 Alice）的地址。 2. 像 Alice 这样的顾客可以查找自己的地址，以确保账本是准确的。 Bob 要找到 Alice 当前的地址，他必须从账本最后一页开始，一页一页向前翻，直到找到 Alice 的那一页。Bob 从账本末尾开始向前查找，因为他想要 Alice 最近的地址，而 Alice 的地址可能随时间变化。随着账本页面不断增加，这对 Bob 来说可能会变成大量工作，尤其是如果 Alice 有段时间没有更新地址，而 Bob 需要筛选大量其他人的地址变更。 账本允许 Alice 验证自己的地址是否被正确列出，但这样做她必须查看自上次访问以来的所有新页面，并检查这些页面从未错误陈述她的地址。和 Bob 一样，随着账本页面不断增加，这也变成大量工作。 如果 Alice 和 Bob 住在一个人们经常更换地址的繁忙城市，他们俩都必须一页一页地翻阅账本，这种使用方式会带来难以承受的工作量。我们需要一种更高效的方式，让 Alice 和 Bob 与账本互动。 #### 引入索引簿 在现实生活中，书籍通常包含按字母顺序排序的索引，使读者能够快速找到他们要找的内容。我们可以将同样的想法应用到我们的账本上，为迄今为止地址已被记录在账本中的每个人的名字引入一本按字母顺序排序的索引簿。 随着账本中不断添加反映新地址或地址变更的新页面，索引簿也必须更新，因此职员每次向账本添加页面时都会发布一份新的索引簿副本，其中包含截至该页面时地址已被记录在账本中的人员集合。这创建了一个包含所有过往索引簿的庞大图书馆，供公众使用。 一张说明账本三个页面的示意图。每个页面包含一条地址变更记录，并对应一个自己的索引簿版本。 目前，让我们假设 Alice 和 Bob 在查看账本的任何给定页面时，总是查看同一本索引簿。在下一节中，我们将讨论该系统的另一个组件，它能让 Alice 和 Bob 验证这一假设。 有了这种构造，Bob 现在可以通过“二分搜索”策略更轻松地在账本中查找 Alice 的地址，这种策略最好通过一个具体例子来说明。 假设在一段时间内有 100 个新增或更新的地址，因此账本有 100 页，职员发布了 100 个不同版本的索引簿。为简单起见，我们假设 Alice 的地址只在账本中出现一次，即她刚搬到镇上时。 Bob 从翻到账本中间开始。然后他检查与该页关联的索引簿。索引簿按字母顺序排序，因此很容易找到一个人的名字。如果索引簿中存在 Alice 的名字，那么这要么是包含 Alice 条目的第一版索引簿，要么是首次出现是在更早的版本中，因此是在账本更早的页面中。 无论哪种情况，Bob 都可以忽略账本的后半部分，对前半部分重复该过程，直到他找到 Alice 地址变更的确切账本页面。具体来说，当 Bob 找到两本相邻的索引簿，第一本不包含 Alice 的地址，而第二本包含时，他的搜索就会结束。 这种搜索过程有几个好处，第一个是效率高。在一个有十亿页的账本中，Bob 不需要（在最坏情况下）向后翻遍十亿页，而最多只需检查 30 个不同的页面就能找到 Alice 的地址。Bob 的工作现在比以前容易多了。 Alice 仍然想确保职员不会添加任何关于她地址错误的新页面。然而，Alice 不需要检查每一页账本和每一本索引簿。她只需要检查 Bob 为了找到她的地址而查看的那些页面和索引簿，这可以确保 Bob 为 Alice 找到的地址已经由 Alice 本人验证过。 这带我们来到搜索过程的第二个好处，即当 Alice 和 Bob 查看页数相同的账本时，搜索过程是确定性的。如果职员在 Bob 和 Alice 搜索之间添加了更多页面，事情会变得更复杂，但主要思路保持不变。在一个有十亿页的账本中，Alice 可以遵循与 Bob 相同的搜索过程，检查 Bob 检查过的相同页面，并确保其中没有任何关于她地址的错误信息。 通过商定一种在账本中搜索的过程，Alice 和 Bob 建立了一种与账本互动的方式，使他们能够切实地实现各自的目标。随着账本不断增长，Bob 有一种高效的方式来找到 Alice 的地址，Alice 也有一种高效的方式来确保 Bob 找到的地址是准确的。 为了清晰起见，这个类比被简化了。在实践中，Alice 可以多次更新她的地址，而支持这种搜索需要在索引簿中存储比仅仅名字更多的数据。我们构建了一个开源的密钥透明度服务器（https://github.com/signalapp/key-transparency-server），将同样的想法应用于 Signal 消息传递。 ### 那职员呢？ 到目前为止，我们描述搜索过程时，似乎 Alice 和 Bob 亲自翻阅账本页面并检查索引簿。在实践中，这并不现实，因为账本和索引簿太大，Alice 或 Bob 无法直接处理。相反，Alice 和 Bob 请职员代表他们执行搜索并报告结果。 但邮局可能被像 Mallory 这样的对手攻破，她冒充职员，最终想欺骗 Bob，让他以为 Alice 的地址实际上是 Mallory 的家。因此，Alice 和 Bob 不能简单地信任职员；他们必须能够独立验证搜索过程本身。 为此，他们要求职员返还搜索过程中查看过的具体账本页面和索引簿中的所有数据，然后自己复核结果。 只有职员返还的数据可以被信任时，复核才有效，这引出一个显而易见的问题：如果 Mallory 冒充职员，谎称记录内容怎么办？例如，Mallory 可以维护一本秘密的第二账本，记录 Alice 的错误地址，或者为同一账本页面发布两个不同版本的索引簿。Mallory 可以向 Alice 提供其中一个视图的数据，向 Bob 提供另一个视图的数据，诱使他们验证所提供的数据，而不会意识到 Mallory 的欺骗。 Alice 和 Bob 需要一位独立的见证人来监督职员保持诚实。 #### 第三方审计者 为了防止 Mallory 向 Alice 和 Bob 提供不同数据，他们依赖第三方审计者。这些审计者就像公证人，在职员将每一页依次添加到账本并发布相应索引簿版本时，从职员肩后监督。 他们检查索引簿的每个版本是否包含与前一版本相同的数据，只有一个条目除外，并且审计者没有移除或以其他方式秘密修改账本中的任何先前页面。如果这些条件成立，审计者会签署（3（https://signal.org/blog/automatic-key-verification/#fn:3））该账本页面和索引簿，表明记录被正确添加。 审计者只会签署每一页和每一本索引簿一次，因此如果职员试图向 Alice 和 Bob 展示第 50 版索引簿的不同版本，职员只能为其中一个版本生成有效的附带审计者签名。通过检查和验证这些审计者签名，Alice 和 Bob 可以确信职员只维护了一份账本和相应的索引簿集合，因此他们看到的是同一套记录。 对于 Signal 的密钥透明度实现，Cloudflare（https://www.cloudflare.com/）和 Trail of Bits（https://blog.trailofbits.com/2026/08/11/how-trail-of-bits-helps-verify-the-integrity-of-your）负责对账本和索引簿进行独立审计。除了这些独立的第三方审计者之外，Signal 应用本身也会执行验证，这些验证共同确保整个系统的完整性。