我们实现自我主权公钥基础设施了吗？

# 我们实现自主权 PKI 了吗？ 来源：https://buffrr.dev/blog/are-we-self-sovereign-pki-yet/ Signal 是端到端加密的，从密钥是端到端的这个意义来说确实如此。但你拿到的密钥是否正确，却是一个不同的问题，而且几乎没人会去问。 Signal 安全号码界面 Signal 中存在安全号码，是因为原则上服务器可能给你提供联系人的错误密钥。你第一次和关心的人聊天时，应该要核对一次号码。实际上，几乎没人这么做。 iMessage 在 2023 年底也推出了同样的概念，叫做联系人密钥验证： iMessage 联系人密钥验证：显示公开验证码 WhatsApp 有安全码。Threema 根据联系人添加方式将其标记为红色、橙色或绿色。Matrix 有带比较表情符号的跨签名设备验证。PGP 有指纹，这也是整个模式的起源，关于这点除了引用 Filippo Valsorda 2016 年的文章(https://words.filippo.io/giving-up-on-long-term-pgp/)之外，已没什么好说的了。 Signal 提供安全号码，是因为平台某天可能被强制要求或遭到入侵，其架构旨在让你能够发现这种情况。但几乎没人去验证。所以，加密最终变成了端到端，但其前提是平台是诚实的，即使设计初衷是希望建立在更强大的前提之上。这几乎就是当初你想通过加密来避免的情况。 ## 问题的症结 这不仅仅是即时通讯的问题。只要需要将公开名称绑定到密钥，就会出现同样的漏洞。 你可以发布一个电子邮件地址。电子邮件是从提供商那里租用的，提供商可以读取它、暂停它、交出它，或者拒绝从中投递邮件。2026 年 4 月，Google 将一名用户的账户数据交给了 ICE(https://www.eff.org/deeplinks/2026/04/google-broke-its-promise-me-now-ice-has-my-data)，且未及时通知用户以便其质疑传票，打破了一个长达十年的承诺。自托管并非真正的出路：自 2025 年 11 月起，Gmail 开始在 SMTP 层面拒绝来自未通过 DMARC 对齐的发送者的邮件，而非将其过滤。运行自己的邮件服务器现在意味着要说服主流提供商你的域名看起来是合法的。电子邮件作为身份标识从来就不是一个标准；它是一种托管关系。 你可以发布一个用户名：Twitter、GitHub、Bluesky、ProtonMail、Telegram、Discord 以及你的域名注册商。它们各自拥有你名字的一部分，并且无法证明这些部分属于同一个人，除非信任另一个平台。Keybase 在十多年前就注意到了这一点，并构建了跨平台身份证明：在你每个账户上发布的签名声明，全部链接到单个密钥。其栈的底层仍然是一个密钥指纹，和 Signal 现在的问题一样。但它确实解决了一个更具体且真实的问题：将分散的身份联系起来，这样 Twitter 上的`@_buffrr`和 GitHub 上的`@buffrr`就可以对照同一个密钥进行校验。2020 年，Zoom 收购了 Keybase(https://news.ycombinator.com/item?id=23102430)。公共托管于 2023 年关闭(https://github.com/keybase/client/issues/24577)，其余部分已弃用。 你可以发布一个密钥指纹——如果你已经放弃其他办法的话。 ## 为什么现有 PKI 解决不了这个问题 我们有面向机器的公钥基础设施。但我们没有面向人的。而且我们拥有的机器 PKI 是一个层级托管格局。 CA 通过查找 DNS 记录来验证域名所有权。直到今年 3 月 15 日(https://cabforum.org/2025/06/18/ballot-sc-085v2-require-validation-of-dnssec-when-present-for-caa-and-dcv-lookups/)，CA 在进行此类验证时都不需要验证 DNSSEC，即使现在，他们也只需要在“DNSSEC 存在时”进行验证，而这只适用于少数域名。因此，一次 BGP 路由泄漏或注册商被入侵，导致你的域名 DNS 被劫持十分钟，就可能产生一个真实的、浏览器信任的证书。这并非理论上的可能；它已在现实中被利用(https://community.letsencrypt.org/t/using-bgp-to-acquire-bogus-tls-certificates/38627)。CA/浏览器论坛的回应是“多视角签发确认”(https://blog.citp.princeton.edu/2024/02/13/announcing-the-open-multi-perspective-issuance-corroboration-project/)，从多个网络视角进行检查以增加 BGP 攻击的难度。但这只是一个变通方案。 DANE 是应对这一切的标准追踪解决方案。但它并未在浏览器中实现(https://www.imperialviolet.org/2015/01/17/notdane.html)。DNSSEC 本身也不是一个自主权的信任根；ICANN 掌握着密钥。 证书透明度有时被视为一个成功案例。CT 解决的是另一个问题：在事后检测错误签发，它依赖于目前大约六个组织运营的仅追加日志。信任 CT 等同于相信这些运营者不会合谋。这很难，但这并非自主权。而且 CT 不是栈的底层。DNS 才是，而 CA 使用 DNS 来决定谁获得证书。 电子邮件 PKI 遵循同样的模式。S/MIME 通过企业 CA 路由。WKD 通过电子邮件提供商路由，而提供商正是你想绕过其加密的对象。 每一层都是托管式的。每一层都假设你信任某人。 ## 什么才能真正有帮助 一个像`grace@key`这样的名字，能够解析为一个公钥。在每一个应用中，对每一个收件人，都是同一个密钥。不可分配给其他人，不可撤销，不可暂停。永远属于你。无需带外验证指纹，因为解析这个名字*就是*验证与密钥的绑定。 不是一个更好的平台。不是一个更可审计的 CA。根本没有特权操作者。 这在今天就能实现： ``` $ cargo install --git https://github.com/spacesprotocol/beam $ beam grace@key AGE age1k2spr6duuu07857wqg0922hd7j0rlnjjax4jvvk50yyhcstn6swspyzh4t ``` 就是这样。这篇文章的其余部分将解释为什么它能工作。 从形式上看：双方需要能够就`grace@key`绑定到哪个密钥达成一致，而无需咨询特定的某个人。他们需要一个共享的、仅追加的记录，记录哪些名字存在以及它们属于哪个密钥。而且这个记录不能有可被窃取的签名密钥，不能有可被胁迫的操作者，也不能有可被游说的委员会。 Spaces(https://spacesprotocol.org/)采用了这种形式。*（声明：我在上面工作。）*已发行的名字存储在一个二叉 Merkle 树中。该树的根被提交到比特币链上，比特币链在这里被用作一个广泛复制、难以改写的时间戳服务。其作用与 CT 日志在 Web PKI 中的作用相同；区别在于使用工作量证明而非操作者信任，并且发行任意批量的句柄只需固定的 32 字节空间。 最终用户不需要接触区块链。Spaces 可以在父名称下批量发行句柄；接收者获得一个句柄和一个密钥，无需链上交易。解析其他人的句柄是针对其中一个已提交根进行的 Merkle 证明校验（阅读论文(https://spacesprotocol.org/paper)以深入了解）。接收方无需钱包、无需费用、无需同步区块链。一个句柄就是一个由密钥控制的身份；在其下发布的记录（如 age 公钥、Nostr 公钥、TLS 证书哈希）由该句柄的密钥签名，并通过一个名为 **Certrelay** 的对等网络分发，每条响应都附带一个你在本地验证的 Merkle 包含证明。链上部分证明“谁拥有这个名字”。链下部分说明“这个名字指向什么”。两条路径中都不涉及 DNS。 ## 所有 CA 的 CA 信任锚点通常是一个公钥加上一个你凭信仰接受的签名过程。PKI 的整个问题，归根结底，就是那个签名过程：有人持有私钥，而有人可能丢失它、出售它，或者收到针对它的搜查令。 Spaces 为你提供了一个不同的模式。信任锚点是一个 32 字节的哈希值：整个协议状态的摘要，任何人都可以计算和验证，无需某个权威机构的认可。一旦你的客户端拥有了这个哈希值，每次句柄解析都变成了一次针对它的 Merkle 证明校验。Signal 要求你为每个联系人验证一个指纹，而你不这么做。Spaces 要求你*只*验证一个哈希值，而且你*真的可能*会这么做。称它为整个协议的一个全局安全号码。 好吧，不错。那个 32 字节的哈希值仍然必须来自某个地方，如果你的手机是从服务器获取它的，那么服务器就再次成为了信任根。所以 Spaces 附带了一个名为 Veritas(https://spacesprotocol.org/docs/use/veritas/) 的小型桌面应用。Veritas 从检查点同步，验证比特币头部链，扫描 Spaces 关心的那少量交易，并执行协议规则，在你的机器上生成信任 ID。它不是一个全节点。你将信任 ID 扫描到客户端中，大约两周内有效。信任锚点现在是一个*你*自己计算的值，而不是一个你接受的签名。 更好了一点。但同步仍然需要一些代价。Veritas 必须跟上头部链和相关交易，并且你仍然需要在你的笔记本上运行某些东西。 最终的解决方案是一个零知识证书。它证明与 Veritas 相同的事情（比特币头部链、协议相关交易以及协议规则），但作为一个单一的简洁证明，大小约为 250 KB。 我们现在正开始使用 RISC Zero zkVM 进行这项工作，利用递归证明组合生成一个 zk-STARK——过去一年主要致力于交付句柄发行和周边基础设施；证书是我们接下来要构建的。 客户端下载一次证书，在毫秒内验证它，然后就完成了。无需同步。无需 Veritas。无需签名密钥。证明*就是*凭证。没有什么可被攻破的，不是说攻破它很难，而是说一开始就没有什么秘密可以窃取。 这就是一个没有私钥的 CA。我们已经花了四十年时间迭代 PKI 设计，其信任锚点都是某人持有的密钥。“一个没有密钥的 CA”是另一种不同的事物。 ## 一些考量 大致按我思考频率排序： - **密钥轮换，以及更棘手的密钥丢失问题。**一个句柄绑定到一个密钥。轮换通过发布一个新的 UTXO 将句柄绑定到新密钥来完成；在实践中，这意味着向一个为你处理链上部分的服务支付一小笔费用。可以在单笔交易中完成数百次轮换。与任何基于密钥的身份一样，更棘手的问题是密钥丢失而非轮换时会发生什么。存在合理的答案（拆分密钥托管、社交恢复、时间锁定的备用方案），但没有完全令人满意的。 - **为什么是工作量证明而不是基于见证人的日志。**见证人更简单、更便宜、更容易部署。代价是见证人可能被胁迫，而链重组则不可能（廉价地做到）。对于一个身份层，我认为这是值得的。更硬核的反对观点是，身份层应该是栈中最无聊、最持久的东西，而“依赖比特币的工作量证明在几十年内保持经济安全”这一点是合理的，但并不无聊。我对此没有很好的答案。 - **你仍然需要信任什么。**“没有签名密钥”不等于“没有信任”。这是信任的转变：信任比特币的工作量证明的安全性，信任你运行的 Veritas 二进制文件正是你以为的那个，信任 Veritas 应用的协议规则正是你希望信任锚点应用的规则。其中两个是公开可审计的计算。第三个是每个安全工具都面临的相同软件供应链问题。信任并没有消失，但它从托管者 HSM 中的私钥转变为任何人都可以审计的假设。 - **缓慢的发行。**顶级*空间*（`@` 后面的部分，如 `@key`）通过普通拍卖获得，唯一的区别是中标金额会被销毁而不是支付给任何人。供应上限约为每天 10 个。个人囤积（在拍卖中购买、持有、转售）是可能的。被阻止的是在启动时进行大规模预挖。命名空间随时间慢慢释放，所以好名字会不断进入池中，而不是在第一天就被全部预留。像 `grace@key` 这样的*句柄*由空间所有者批量发行。公开水龙头(https://spacesprotocol.org/faucet/)免费发放。 - **采用。**任何新身份系统最困难的部分是让客户端支持它。有了零知识证书，验证可以嵌入到应用内部，用户永远不需要考虑它。但人们已经在使用的应用是否会嵌入它，则是另一个问题。答案的形式在这里。答案本身是否真的能让你和朋友发消息，却还没有实现。 - **身份的另一半。**将名字绑定到密钥是问题的一半。另一半是社会性的：恢复、声誉、消除歧义、区分正确的 Sarah 和错误的 Sarah。`grace@key` 永远解析为一个固定的密钥，并不能告诉你背后的人是否是你想交谈的对象。前一半问题几十年来一直没有可用的解决方案。Web PKI 是托管式的。区块链命名项目来来去去。ENS 仍然依赖于运行一个完整的以太坊节点或信任 Infura。后一半是一个独立的问题，我也没有答案。 长久以来，缺失的一块一直是如何将一个人可读的名字绑定到一个密钥，而无需信任服务器、注册商或 CA。这一块的形状现在已经足够清晰，可以指出来了。