自主主权公钥基础设施（PKI）难题待解，Spaces能否带来新突破？

转载于 2026-05-27 08:45:14 发布 · 12 阅读

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

2026年5月6日消息，从密钥端到端的意义上来说，Signal实现了端到端加密。然而，你是否拿到了正确的密钥则是另一个问题，而且几乎没人会去问这个问题。

Signal上的安全号码之所以存在，是因为理论上服务器可能会给你错误的联系人密钥。你理应在与重要联系人首次交谈时核对安全号码，但实际上几乎没人这么做。

2023年末，iMessage推出了类似的功能，名为“联系人密钥验证”。WhatsApp有安全码，Threema会根据联系人的添加方式，将其标记为红色、橙色或绿色，Matrix采用交叉签名设备验证，通过对比表情符号来验证，PGP有指纹验证，这也是整个验证模式的起源。

Signal推出安全号码，是因为该平台未来可能会被迫交出信息或遭受攻击，其架构旨在让用户能够察觉这种情况。但几乎没人进行验证。因此，加密最终能否实现端到端，取决于平台是否诚实，尽管设计初衷是基于更可靠的条件，这几乎就是你最初进行加密时想要避免的情况。

问题的本质

这不仅仅是消息应用的问题。在任何需要将公共名称与密钥绑定的场景中，都会出现同样的问题。

你可以公布一个电子邮件地址。电子邮件由服务提供商提供，他们可以读取、暂停、移交你的邮件，或者拒绝接收来自该地址的邮件。2026年4月，谷歌将一名用户的账户数据移交给美国移民海关执法局（ICE），且未及时通知用户对传票提出质疑，违背了其长达十年的承诺。自行托管邮件也并非万全之策：自2025年11月起，Gmail开始拒绝未通过SMTP级别DMARC对齐的发件人的邮件，而非对其进行过滤。运行自己的邮件服务器意味着要让大多数服务提供商相信你的域名是合法的。电子邮件作为身份标识从未真正成为一种标准，它更像是一种托管关系。

你可以公布一个用户名。Twitter、GitHub、Bluesky、ProtonMail、Telegram、Discord以及域名注册商，它们各自掌控着你身份的一部分，若不依赖另一个平台，就无法证明这些部分属于同一个人。Keybase在十多年前就注意到了这个问题，并构建了跨平台身份验证机制，但底层仍然是密钥指纹，存在与Signal相同的问题。不过，它确实解决了一个较小但实际存在的问题：将分散的身份关联起来。Zoom于2020年收购了Keybase，2023年，其公共托管服务停止，其余功能也逐渐荒废。

如果你已经放弃，也可以公布密钥指纹。

现有PKI为何无法解决问题

我们有用于机器的公钥基础设施（PKI），但没有用于人的PKI。而且我们现有的机器PKI是一个层层托管的体系。

证书颁发机构（CA）通过查询DNS记录来验证域名所有权。直到今年3月15日，CA在进行验证时都无需验证DNSSEC，即便现在，也只是在域名启用DNSSEC时才需要验证，而启用DNSSEC的域名只是少数。因此，BGP路由泄露或注册商被攻击，导致你的域名DNS被转移十分钟，仍可能为你的域名生成一个浏览器信任的有效证书。CA/浏览器论坛的解决方案多视角签发验证从多个网络视角进行检查，以增加BGP攻击的难度，但这也只是一种权宜之计。

DANE是标准层面的解决方案，但它并未在浏览器中得到应用。DNSSEC本身也并非真正的自主主权信任根，因为ICANN掌握着密钥。

证书透明度（Certificate Transparency）有时被视为成功案例。CT解决的是另一个问题：事后检测证书的错误签发，它依赖于目前约六个组织运营的只追加日志。对CT的信任最终归结为相信这些运营商不会相互勾结。这很难做到，而且它也不是自主主权的。此外，CT并非底层基础，DNS才是，CA依靠DNS来决定谁能获得证书。

电子邮件PKI也遵循同样的模式。S/MIME通过企业CA进行验证，WKD则依赖于电子邮件服务提供商，而这正是你试图绕过的一方。每一层都是托管式的，每一层都要求你信任某一方。

真正有效的解决方案

一个类似“grace@key”的名称，它能解析为一个公钥。在每个应用中，对于每个接收者来说，这个密钥都是相同的。它不可转让、不可撤销、不会被暂停，永远属于你。无需在外部验证指纹，因为解析名称的过程就是验证名称与密钥绑定的过程。

这不是一个更好的平台，也不是一个更可审计的CA，而是完全没有特权运营商。现在就可以实现，操作简单。本文接下来将解释其原理。

本质上，双方必须能够在不咨询特定第三方的情况下，就“grace@key”绑定的密钥达成一致。他们需要一个共享的、只追加的记录，记录哪些名称存在以及它们对应的密钥。而且这个记录不能有可被窃取的签名密钥、可被胁迫的运营商或可被游说的委员会。

Spaces就采用了这种模式。已发布的名称存储在一个二进制Merkle树中。该树的根哈希被记录到比特币区块链中，这里比特币区块链被用作一个广泛复制、难以篡改的时间戳服务。其作用与Web PKI中的CT日志类似，不同之处在于它依靠工作量证明而非运营商信任，并且无论批量发布多少名称，其占用空间固定为32字节。

终端用户无需与区块链交互。Spaces可以在一个父名称下批量发布名称；接收者会得到一个名称和一个密钥，无需进行链上交易。解析他人的名称时，只需对其中一个已记录的根哈希进行Merkle证明检查。接收方无需钱包、无需支付费用、无需同步区块链。一个名称是一个由密钥控制的身份；在其下发布的记录由该名称的密钥签名，并通过一个名为Certrelay的对等网络进行分发，每个响应都带有一个你可以在本地验证的Merkle包含证明。链上部分证明了谁拥有该名称，链下部分说明了该名称指向什么。这两条路径都不涉及DNS。

万CA之CA

信任锚通常是一个公钥和一个你基于信任接受的签名过程。PKI的核心问题最终在于这个签名过程：有人持有私钥，而这个人可能会丢失、出售私钥，或者收到针对私钥的传票。

Spaces提供了一种不同的解决方案。信任锚是一个32字节的哈希值：它是整个协议状态的摘要，任何人都可以计算和验证，无需权威机构的认可。一旦你的客户端获得了这个哈希值，每次名称解析都是对该哈希值进行Merkle证明检查。Signal要求你为每个联系人验证指纹，但你不会这么做。而Spaces只要求你验证一个哈希值，你可能真的会去做。可以将其视为整个协议的一个全局安全号码。

这个32字节的哈希值仍然需要有来源，如果你的手机从服务器获取它，那么服务器就又成了信任根。因此，Spaces推出了一个名为Veritas的桌面小应用。Veritas从一个检查点进行同步，验证比特币头链，并扫描Spaces关注的少量交易，按照协议规则在你的设备上生成信任ID。它不是一个完整的节点。你将信任ID扫描到客户端后，大约两周内都有效。此时，信任锚变成了你自己计算的值，而不是你接受的签名。

这样更好了，但同步仍然需要一定成本。Veritas需要跟上头链和相关交易，你仍然需要在笔记本电脑上运行它。

最终目标是实现零知识证书。它能证明与Veritas相同的内容，但以一个约250KB的简洁证明形式呈现。我们现在正使用RISC Zero zkVM开始这项工作，通过递归证明组合生成zk - STARK。过去一年我们致力于名称发布和周边基础设施的开发，接下来将构建这个证书。

客户端只需下载一次证书，在毫秒内完成验证，之后就无需再进行同步。无需运行Veritas，也没有签名密钥。证明本身就是凭证。没有什么可被攻击的，不是说攻击难度大，而是根本没有可窃取的秘密。这就是一个没有私钥的CA。四十年来，我们一直在迭代PKI设计，其中信任锚是由某人持有的密钥。“没有密钥的CA”是一种不同的概念。

一些考虑因素

以下是按思考频率大致排序的一些考虑因素：

密钥轮换和更棘手的密钥丢失问题：一个名称与一个密钥绑定。密钥轮换通过发布一个新的UTXO将名称与新密钥绑定来实现；实际上，这意味着你要向一个提供链上操作服务的机构支付少量费用。一次交易可以进行数百次密钥轮换。与任何基于密钥的身份验证一样，更棘手的问题是密钥丢失而非轮换时该怎么办。有一些合理的解决方案，但没有一个能完全令人满意。
为何采用工作量证明而非基于见证人的日志：见证人机制更简单、成本更低且更容易部署。但问题是，见证人可能会被胁迫，而区块链重组相对难以实现。对于身份验证层，采用工作量证明是值得的。更具争议的观点是，身份验证层应该是整个系统中最稳定、可靠的部分，而“依赖比特币的工作量证明在未来几十年内保持经济安全”虽然有一定可能性，但并不稳定。对此没有很好的答案。
仍然需要信任的方面：“没有签名密钥”并不意味着“无需信任”。这只是重塑了信任关系：信任比特币的工作量证明安全机制、信任你运行的Veritas二进制文件就是你认为的那个文件，以及信任Veritas应用的协议规则是你希望信任锚应用的规则。其中两个方面是可以公开审计的计算过程。第三个方面是所有安全工具都面临的软件供应链问题。信任并没有消失，只是从托管方HSM中的私钥转变为任何人都可以审计的假设。
发布速度慢：顶级“空间”（“@”后面的部分，如“@key”）通过普通拍卖获得，不同的是中标出价会被销毁，而不是支付给任何人。每天的供应量上限约为十个。存在个别囤积行为，但可以防止在项目启动时大规模预挖。命名空间会随着时间逐步释放，这样好的名称会不断进入可用池，而不是在第一天就被全部预留。像“grace@key”这样的“名称”由空间所有者批量发布，公共水龙头会免费发放一些。
推广问题：任何新的身份验证系统面临的最大挑战是让客户端支持它。有了零知识证书，验证过程可以嵌入应用中，用户无需再为此操心。但现有的应用是否会嵌入该验证机制则是另一个问题。解决方案的框架已经存在，但要让人们能够用它与朋友交流，还有很长的路要走。
身份验证的另一半：将名称与密钥绑定只是问题的一半。另一半是社交层面的问题：恢复、声誉、身份识别，以及区分不同的人。“grace@key”永远解析为一个稳定的密钥，但这并不能告诉你背后的人是否是你想联系的人。前半部分问题几十年来一直没有得到有效的解决方案。Web PKI是托管式的，区块链命名项目来了又走。以太坊名称服务（ENS）仍然依赖于运行完整的以太坊节点或信任Infura。后半部分是一个独立的问题，也没有答案。

长期以来，缺失的一环是一种无需信任服务器、注册商或CA就能将人类可读的名称与密钥绑定的方法。现在，这一环的大致轮廓已经清晰可见。那么，这种方法能否真正落地并广泛应用呢？