Zoom 收购 Keybase：一场加密基础设施的联姻

本文翻译并深度解析了 Keybase 团队宣布被 Zoom 收购的官方博客，探讨了密码学基础设施、可信密钥管理以及视频通信安全之间的技术接合点。

---

原文链接：https://keybase.io/blog/keybase-joins-zoom
HN 讨论热度：1879 分 / 712 评论

---

背景：当视频会议成为全球基础设施

2020 年 5 月 7 日，Keybase 团队在官方博客上宣布被 Zoom 收购。这看似是一家密码学初创公司被一家视频会议巨头吞并的常规新闻，但如果仔细阅读 Keybase 团队的技术表述，你会发现这里谈的根本不是一次普通的并购，而是一场关于“公钥基础设施（PKI）如何真正落地”的技术路线图宣示。

当时新冠疫情迫使全球数十亿人转而依赖远程工作与线上沟通。Zoom 在短短几个月内从一个企业级工具变成了普通家庭的必备应用——无论是免费还是付费用户，每日参与者数以亿计。与此同时，安全性成为 Zoom 面临的最大质疑：会议轰炸（Zoombombing）、端到端加密缺失、数据采集争议等，都让 Zoom 的信任度受到挑战。

选择收购 Keybase，Zoom 显然意识到：如果自己要成为支撑教育、医疗、政务甚至军工的中枢通信平台，就绕不开“身份信任”和“密钥管理”这两个根基问题。

Keybase 六年以来在做的事：解决“公钥分发”的魔鬼细节

Keybase 并非普通的加密聊天软件，而是一个以公钥身份绑定为核心的协作平台。为了更好地理解这次收购，我们一定要先理解 Keybase 发布的博客里那些话的深层含义。

公钥基础设施（PKI）一直是密码学应用中最“反人性”的部分。 用户不关心你的签名算法是 Ed25519 还是 ECDSA，他们只关心“我发的这条消息，我的同事真的能收到，而且没有中间人偷听”。但传统的 PKI 构建中，证书颁发机构（CA）是最高信任锚点——如果 CA 被攻陷或作恶，整个信任链就瓦解。

Keybase 采取的方式不同。他们在底层反复打磨了六个关键歧义问题，这些问题每个都是安全工程师的噩梦：

1. 如何知道服务器给你的密钥是对的？ 服务器可能返回任意公钥，用户无法验证真实性。
2. 需要支持“信任首次使用”（TOFU）吗？ 如果设备第一次联接服务器就拿到假密钥，后面很难发现。
3. 用户升级设备或重装系统后，如何保证密钥无缝迁移且不破坏其他成员的信任？ 若用 TOFU 原则，新设备会产生新身份，易遭受模拟攻击。
4. 在动态团队协作里，如何使一个被攻陷的服务器无法随便“塞进”一个额外成员，但合法的团队管理员仍然可以新增或移除成员？
5. 当成员离队或丢失设备时，服务器能否“隐瞒”这个撤销事件而不被察觉，从而导致消息依然发给已离队成员？
6. 如何做到不依赖任何中心化信任根，也不依赖繁琐的证书链检查，但依然可审计、可证明？

Keybase 给出的答案通常是构造一条可审计的签名链——也就是说，每个用户操作（密钥更新、成员变更、设备变更）都产生一个签名，并挂在 Merkle 树上以提供全局唯一性证明。这样可以形成一个密钥透明度账本，任何节点都可以验证操作序列是否一致，服务器难以作恶而不留痕。这种设计思想与 Google 推出的 Certificate Transparency 以及 CONIKS（斯坦福开发的密钥透明度系统）有很大相似之处，但 Keybase 是把它嵌入到实际的聊天、文件、团队协作产品中。“签名链+ Merkle 审计”解决的是什么？它提供了两个关键属性：非否认性和可审计性——你无法否认自己签过名，服务器也无法悄悄篡改历史结果。

这些问题的难度在于既要保证安全性，又要让用户操作不复杂。比如在 Keybase 中，新用户在设备上安装应用时，系统会引导你信任一组社交身份（比如你的 GitHub、Twitter）使得其他人可以对你进行多维度交叉验证，而不是只依赖于一个中心数据库。

为何说“收编多个平台接入场景”是安全上最大的挑战

博客里特别强调了 Zoom 的“柔性”——任何平台（iOS, Android, Windows, mac, Linux）都有应用，还支持老式铜线电话拨入，也允许通过浏览器以密码身份甚至访客身份加入。这些多样化接入方式是 Zoom 成功的基石，也是安全设计时最难啃的骨头。

传统的端到端加密通信（比如 Signal）要求所有参与者都支持最新认证协议，但如果某人只是用一个老式电话拨入，他怎么验证和分享密钥？若通过网页以访客身份入会，不要求注册，那怎样确定对方身份？若主持人录制了会议并分享，那录制文件如何加密或签名以保证不被篡改？所有这些现实的鸿沟，都必须嵌入到安全模型里。Keybase 想做的是让所有这些接入点都能有合理的安全保证，而且让用户无感知。

举个例子：如果会议主持人使用高安全模式（比如开启端到端加密），而某个参与者只通过普通电话网络拨入，那就必须降级安全强度，但需要向其他参与者明示“该参与者非端到端加密连接”。这种降级策略如何设计？如何防止服务器故意将一个加密连接伪装成安全退化版本？Keybase 所研究的“可审计签名链”就派上了用场——可以设计成：服务器必须为每次降级或转码行为发布签名证明，供其他客户端验证，从而做出相应警告。

团队的短期重点：将安全扩展到一个体量更大的产品上

博客指出，在最短期内，Keybase 团队的头号任务是帮助 Zoom “显著提升安全有效性”。注意，它不是说要立刻给 Keybase 应用强推什么新功。事实上 Keybase 应用依然可以继续使用，团队还未决定去向，未来的完全由 Zoom 说了算。

这种措辞透露出两个信息：

• 第一，Zoom 短期内想得到的是 Keybase 的密码学研发资源和协议工程技术，而不是 Keybase 现有的用户基础。
• 第二，Keybase 团队心中可能有更大的抱负——把自己的技术嵌入到一个日活跃用户数亿的产品中，所获得的实战经验与研究数据量，远超在 Keybase 自身那几十万用户里做实验的价值。

另外博客末尾还透露了一个细节——Keybase 原本正在开发一项关于“团队管理”的重大更新，但由于忙于收购谈判而暂停，现在即将推出。这说明 Keybase 并没有因为被收购而停止研发，只是优先级被调整了。

他们还借机推广了一个小工具：ZoomBot，允许 Keybase 用户在聊天中直接发起 Zoom 会议——这是两种产品生态融合的最初迹象。

对安全社区与密码学研究者的意义

虽然官方没有透露具体的合作路线，但外界推测这标志着 Zoom 决定认真投入后量子密码学、盲签名、非交互式零知识证明等现代密码学技术来重构安全模型。另外，这也推动了行业对“可信服务器+客户端验证”的重新思考：当应用规模达到上亿级，不可能依赖每个用户去手动验证指纹，那么就必须有自动化的透明性机制。

在学术领域里，这类设计已经存在很多年——比如 CONIKS、SEAFile 的加密机制等，但都未能普及到消费者级产品。Zoom 可能将成为第一个将这类技术落地到广泛人群的视频通信应用，如果顺利，这会是密码学真正走向普通用户的标志。

关于收购执行的一个冷幽默

博客最后附录的 FAQ 有一个自嘲式问答：“你们在疫情隔离期间是怎么谈成一笔并购交易的？”回答只有一个词：“用 Zoom。”这句玩笑今天看来既是对自家产品的一次轻量宣传，也侧面说明 Zoom 在极度特殊时期如何支撑了全球商业合作——甚至包括它自己的野心扩张。

结语

一个密码学团队并入视频会议巨头，表面上似乎小众，实际上这是基础设施级安全能力的一次精确换手。Keybase 对于密钥分发、TOFU、动态群体身份管理、可审计签名链的长期工程积累，恰好补足 Zoom 最容易受到专家诟病的部分。如果 Zoom 最终能够将这些技术整合进端到端加密架构里，它就能够宣称自己的用户数据真正做到了“服务商不可见”。而对于所有其他音视频产品而言，压力也随之升高——用户将越来越清楚地问：你们的密钥到底由谁掌管？有没有审计证据？

这也许就是钥匙公司（Keybase, 即“密钥基地”）被收购后真正想写给世界的消息：安全不是锁定某个房间，而是给每个人一把能自我验证的钥匙。

---

原文链接：https://keybase.io/blog/keybase-joins-zoom