文章总结： 本文深入解析匿名凭证系统PrivacyPass的工作原理，包括盲签名流程、元数据绑定和会话特定凭证等关键技术。文章指出该协议已由Cloudflare、苹果等公司大规模部署，但功能单一，仅支持一次性凭证，难以满足年龄验证等复杂场景需求。文档同时预告将探讨谷歌提出的零知识凭证新方案。 综合评分： 82 文章分类： 技术标准,解决方案,应用安全,网络安全,安全工具

匿名凭证系统深入解析下-两大现实案例

幻泉之洲

2026年4月20日 14:51 北京

在小说阅读器读本章

去阅读

本文剖析了目前应用最广的匿名凭证系统Privacy Pass及其工作原理，也探讨了其在年龄验证等复杂场景中的局限性。隐私技术的价值不仅在于精巧的构思，更在于能否被大规模、低成本地部署。

这是匿名凭证系列文章的第二篇。上一讲我们介绍了什么是匿名凭证：一种让用户在向网站验证身份时不必牺牲隐私的技术。

简单回顾一下，一个匿名凭证系统里通常有几方：发行凭证的发行方（Issuer），一个或多个资源提供方（Resource，比如网站），以及众多用户。用户先从发行方那里拿到凭证——这个过程通常需要实名验证。凭证到手后，用户就可以在自己想访问某个资源（比如网站）的时候，“出示”这个凭证。“出示”环节就是匿名性发挥作用的地方：如果系统设计得当，那么无论是接收凭证的网站、发行凭证的机构，还是这两方合谋，都无法将这次的“出示”行为追溯到当初是哪个具体用户领走了那张凭证。

我们还聊了几个对匿名凭证系统特别有用的功能。

• 最有用的一种功能是限制单个凭证的用途，比如限制它能被“出示”的次数。这主要是为了防止凭证克隆攻击：黑客或恶意用户偷走一个凭证，然后复制出成千上万个副本，用来创建“僵尸”账户。在匿名凭证系统里，这类攻击尤其危险，因为这些凭证本身无法直接追查到具体用户，一张被窃的凭证可以在无人察觉的情况下被无限复制。
• 我们还讨论了如何让凭证表达的信息更丰富、更灵活。比如，你的驾照就是一种（非匿名的）凭证，它能证明你的年龄、准驾车型、居住地等各种声明。一个表达力强的匿名凭证同样能让用户证明这些数据背后的多种陈述，而无需泄露你不想透露的任何额外信息。

上一讲是概述，所以我们偏重理论。但这是一个关于密码学工程的博客。所以今天，我们得抛开理论，聊聊实际的东西。

具体来说，就是介绍两个在现实世界里实际用到的凭证系统。第一个是Privacy Pass，它被Cloudflare、苹果等公司广泛使用。然后我们会讨论谷歌正在推动标准化的一个匿名年龄验证新提案。

Privacy Pass：无处不在的匿名“腕带”

Privacy Pass是当前世界上部署最广泛的匿名凭证标准。

它以这样或那样的名字，遍布整个互联网，主要使用者是大型科技公司。其中最出名的可能就是Cloudflare了，其研究人员帮助撰写了这个标准，目的是绕过烦人的验证码和其他反滥用机制。但一模一样的协议也部署在苹果（他们称之为“私人访问令牌”）、谷歌（“私人状态令牌”）、Brave浏览器以及其他一些项目中。Privacy Pass的普及程度令人咋舌，连微软都在其Edge浏览器里用它——要知道，微软可算不上是隐私的坚定拥护者。

作为第一个大规模部署的凭证系统，Privacy Pass简单得令人吃惊，简单到你能想象的那种。它提供经典的、一次性的“腕带”式凭证，这种凭证只携带一个比特的信息：“我拥有一张凭证”。它所用的技术简单到你可以从80年代的学术论文里提取出来，再加点性能优化搞定的程度。真正的看点在于，真的有人在用它。

Privacy Pass已经标准化在IETF的RFC 9576、9577和9578中。标准里有许多部署选项，但核心协议几乎完美地实现了我们在上篇文章中提到的Chaum最初的“盲签名”凭证思路。让我简单回顾一下这种凭证的工作原理。

1. 当用户想获取一个一次性凭证时，他首先选择一个令牌类型（tokentype）和一段元数据MD——一个用户可选择加入的可选字符串。
2. 接着，用户生成一个很长的随机序列号SN，这个序列号最好全球唯一。
3. 随后，用户和发行方运行一个盲签名协议，对一条由（tokentype， SN， MD）构成的消息进行签名。用户最终得到签名sig，而发行方既不知道签名结果，也不知道被签名的消息内容。

最终得到的凭证是一个四元组（tokentype， MD， SN， sig）。向资源提供方“出示”这个凭证时：

1. 用户将上述四元组发送给资源方。
2. 资源方验证tokentype是否是有效的Privacy Pass令牌类型，并决定是否接受包含元数据MD的令牌。
3. 然后，资源方使用发行方的验证密钥（tokentype字段会告诉它如何使用）验证签名sig，并查询数据库以确保SN从未被使用过。如果所有检查都通过，它就把SN添加进数据库。

流程基本就是这样。

你可能要问：这个元数据MD到底是干嘛的？

这个元数据字符串是一段额外的数据块，可以用来将凭证“绑定”到特定的应用，比如某个网站。例如，如果我计划在3月31日星期二访问《纽约时报》，我可以申请一个包含元数据字符串 MD = “nyt.com || 2026-03-31”的凭证。当我“出示”凭证时，该网站可以验证这个字符串，并决定是否为我提供服务。

关键在于，发行方看不到这个元数据字符串。它完全由用户选择，但一旦选定就无法更改。这种方法允许网站要求具有有限用途的令牌——例如，只绑定到某一个特定网站，或限制在特定的时间段内使用。

在Privacy Pass中，元数据的一个主要应用是实现所谓的会话特定凭证。这是一种不同的凭证发放流程：用户不是在访问网站之前就获得凭证，而是在开始访问某个站点（比如一个受Cloudflare保护的网站）之后才拿到凭证。

1. 当用户开始访问一个资源时，资源方会发送一个会话特定的“挑战”给他（比如一个随机字符串）。
2. 用户随后实时向发行方请求一个凭证，并将MD设置成那个“挑战”值。
3. 当用户向资源方“出示”凭证时，资源方验证凭证中的挑战值是否与它在步骤（1）中选择的相匹配。

整个协议流程如图。

这种组合协议的好处是，每个凭证只能用于用户已经发起的那个特定会话。它不能用于其他任何事情：例如，用户没法留着这个凭证下周再用。这对于像Cloudflare这样的网站来说可能有些好处，因为它们需要一定的能力来实时控制访问站点的用户数量。

当然，这种方法也有些缺点。

一个缺点是，对于实时凭证发放，发行方必须持续在线：如果发行方宕机，那么基本上所有访问资源的通道都会被切断，因为用户无法获取新的凭证。（在之前的发放流程中，用户可以预先获取一批凭证，即使在发行方离线时也能使用。）另一个缺点是，实时发放协议在理论上可能导致时序关联攻击。也就是说，如果资源方和发行方比对各自收到消息的时间戳，他们就有可能将用户的会话与凭证发放请求关联起来。

当发行方和资源方由同一家公司运营时——Cloudflare的部署就属于这种情况——最后这点尤其令人担忧。幸运的是，Cloudflare每秒处理数十万笔交易，流量如此巨大，以至于这种关联攻击可能不太容易实施。

技术细节：签名方案与令牌类型

搞清楚了基本流程，描述Privacy Pass时剩下的主要问题就很简单了：我们如何实现盲签名？

Privacy Pass定义了两个标准化的“发放协议”，每个协议使用了略有不同的密码学技术。第一个描述了一种用于公开可验证令牌的Privacy Pass变体。这基本上就是我们上一讲讨论过的Chaum式凭证：在这里，发行方使用盲RSA签名来签署令牌，其方式与Chaum在80年代提出的原始协议几乎完全相同。这类令牌的好处在于，资源方可以使用发行方的公钥来验证令牌——这意味着发行方和资源方无需共享任何密钥材料。

盲RSA签名的主要问题是体积大，而且构造起来有点昂贵。这是因为RSA需要很大的公钥，通常至少2048位才能达到约112位的对称加密等效安全级别。这使得签名相对较大，签名过程也略显耗费资源。

显而易见的替代方案是使用椭圆曲线（EC）原语，比如Schnorr签名，甚至是ECDSA。这种方法有个无聊的问题：我们没有很好的基于椭圆曲线的盲签名工具箱。

• 一些老的“盲Schnorr”协议在允许并发发放（即允许攻击者同时运行多个盲签名请求协议）时，被证明是极其不安全的。这些攻击足以在有合理计算能力的硬件上伪造Schnorr签名。
• 要让这些协议安全运行，我们需要一次只进行一次签名会话，也就是说，不能并行发放。
• 最近的一些论文试图解决这个问题，但得到的协议比盲RSA还要慢。

因此，Privacy Pass完全不支持基于椭圆曲线的盲签名。

对于那些需要极快速度的部署场景，Privacy Pass定义了第二种发放方式，用于私有可验证令牌。这些令牌使用基于遗忘伪随机函数的遗忘消息认证码。这种私有可验证令牌的优点是，它们使用基于椭圆曲线的原语，创建和验证速度极快。缺点在于，验证者（在这种情况下是资源方）必须拥有发行方的密钥才能验证凭证。

总结与思考

Privacy Pass可能是你能构建的最不令人惊讶的匿名凭证协议。它为用户提供了一种简单、一次性的“腕带”凭证，并针对速度进行了优化。虽然协议背后的基本思想在80年代就已确立，但现在它们已被标准化为一种非常快速且可用的东西。让这个协议有趣的，与其说是背后的技术，不如说是部署的广泛程度：在苹果、谷歌、Cloudflare之间，每天可能有数十亿人在使用Privacy Pass——尽管他们可能并不自知。

与此同时，Privacy Pass也确实“乏味”：除了“获取令牌，使用令牌”的腕带凭证模式，它几乎没有提供更多有用的功能。在年龄验证这类问题上，它肯定没有给出太多解决方案，除非我们愿意每次上网时都与发行方反复通信来获取凭证。

在下一篇文章中，我们将讨论一个更强大、号称能解决其中一些问题的提案：谷歌提出的支持零知识凭证的新方案。

相关阅读 匿名凭证：图解入门（https://blog.cryptographyengineering.com/2026/03/02/anonymous-credentials-an-illustrated-primer/） 对Worldcoin的一些粗浅印象（https://blog.cryptographyengineering.com/2023/08/21/some-rough-impressions-of-worldcoin/） 非政府加密攻击（https://blog.cryptographyengineering.com/2011/11/28/non-governmental-crypto-attacks/）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《匿名凭证系统深入解析下-两大现实案例》