文章总结: 本文系统介绍了匿名凭证技术如何在不暴露用户身份的前提下实现条件验证(如年龄验证),通过图解方式阐释了基本模型、克隆问题及其解决方案(一次性凭证、可撤销凭证、硬件绑定)。文章重点分析了零知识证明在实现复杂条件验证与使用次数限制方面的优势,并探讨了凭证过期与撤销机制,最后提及隐私通行证和谷歌方案两个现实案例。 综合评分: 85 文章分类: 技术标准,解决方案,数据安全,应用安全,隐私保护
匿名凭证技术上-入门图解
幻泉之洲
2026年4月20日 10:51 北京
在小说阅读器读本章
去阅读
当法律要求网站验证你年龄时,你的真实身份会暴露给每个网站。匿名凭证能让用户证明自己符合某种条件(如成年人),而无需透露身份信息。本文从隐私需求出发,图解了匿名凭证的基本原理、实现难点(克隆问题)以及更先进的零知识证明方案,讨论了在现实世界中保护在线隐私的密码学武器。
为什么我们今天要谈这个
这篇文章在草稿箱里躺了一年多。这让我很不安,因为每过一个月,我对匿名认证重要性的信念就加深一分。作为密码学家,我感觉这可能是我们能讨论的最重要话题了。原因很简单:我不信任我们生活的这个世界。糟糕的立法和AI的泛滥,正把我们推向一个隐私反乌托邦的深渊,这让我十分担忧。
不过,抱怨解决不了问题。我们还是从头说起吧。
无处不在的身份验证
用户认证是计算机安全的核心问题。登录网站,访问服务器,每次都需要向服务商证明你是合法用户。验证方式五花八门,有的需要用户名密码,现在流行多点登录认证和多设备登录密钥[1],也有些网站不需要明确身份,允许用户注册完全匿名的账号。
即便如此,网站还是要你证明点什么,比如基本的防机器人检查,通常结合长期Cookie、验证码或者像Cloudflare那样的一整套机制[2]。
我猜他们可能是偷偷挖矿。
悄然改变的游戏规则
我年轻时那个互联网对身份验证很随意。只要你不乱发垃圾信息,大多网站都能接受一定程度的匿名。这几年情况变了。部分原因在于广告驱动的网站热衷收集数据,掌握你的确切身份能卖出更好的广告。另一个更直接的推手则是全球范围的年龄验证立法风潮[3]。
美国25个州和数十个国家的新法律要求,网站在展示“不合适”内容前,必须核实用户的年龄。这些法律的初衷是阻挡色情内容,但实际效果是给几乎所有托管用户内容的网站都加上了新的身份检查。
现在,脸书[4]、BlueSky、X和Discord等社交平台都在推出年龄验证,连维基百科在英国《在线安全法案》[5]的压力下,也在艰难地打一场隐私保卫战[6]。
无论你对年龄验证持什么态度,常规身份检查将成为新的重大隐私隐患。用户必须用真实身份证明自己,而不是一个网名。搞砸了的话,你在网上的所有活动都可能被记录,形成一份公民级别的完整档案。
匿名凭证:不暴露身份的认证
大卫·乔姆在1980年代就预见了今天,他不喜欢这个未来。在网络和智能手机出现之前,他就意识到人们未来需要频繁出示电子凭证,这隐私风险巨大。为此,他提出了“匿名凭证”这个概念[7]。他取的论文题目也挺有意思。
基本模型与核心问题
设想一个场景,爱丽丝想访问某个网站。在标准流程里,她必须先获得授权凭证,比如一个Cookie。这个凭证可能来自网站本身,也可能来自第三方如谷歌的单点登录服务[8]。
问题的关键在于,每次爱丽丝需要访问该网站时,她都要出示这个与真实身份绑定的凭证。好奇的网站或广告网络可以利用这个数据,精确地将她的每一次访问都与现实中的她关联起来。这就是我们当下世界的缩影,只是未来的身份将直接绑定姓名和政府ID,不再是“用户38号”。
乔姆的想法是切断凭证颁发与使用之间的链接。当爱丽丝向网站出示凭证时,网站只知道“有用户拿着有效凭证”,但不知道具体是谁。这必须能抵抗网站与凭证颁发方的合谋。这样,对网站而言,爱丽丝的浏览行为就是完全匿名的,她隐藏在众多凭证用户的集合中。
一个生动的比喻
有个不错的类比[9]:把匿名凭证想象成夜店入场手环。你在门口出示身份证,工作人员给你一个无标签的手环,上面只表示“此人满21岁”。到了吧台,调酒师只认手环,不用再看你的驾照。原则上,你不能把点单的偏好和你具体的身份联系起来。
这种手环7美元能买一卷。
一个天真的想法:用同一个凭证?
既然想要用户凭证不可区分,为什么不给所有用户发一样的凭证呢?这在物理世界行得通——所有人戴一样的手环就好。但数字世界完全不同。
数字凭证可以无限复制。黑客只要窃取一份凭证,就能造出无数个克隆品,用来创建海量机器人账号,或者卖给未成年人。所有克隆品在网站看来都一模一样。
传统的非匿名凭证(如会话Cookie)也面临克隆滥用问题,但网站可以通过监测异常模式来检测——比如一个“用户”在短时间内从全球不同IP登录。然而,在匿名凭证的世界里,每次“出示”都长一个样,网站根本无法区分这是来自同一个克隆凭证,还是来自无数个不同的凭证。
所以,任何实用的匿名凭证系统都必须包含某种机制来限制凭证复制。
三种基本限制方式
- 一次性凭证。最常见的办法是签发只能使用一次的凭证。用户想访问网站五十次,就得从颁发方那里获取五十个独立的凭证。黑客就算窃取,也只能用五十次。CloudFlare的隐私通行证[10]就用了这一招。
- 可撤销凭证。构建能被撤销的凭证。当某个匿名用户行为不端(发垃圾信息、网络攻击)时,可以撤销其凭证,阻止其所有克隆体的使用。
- 硬件绑定凭证。像谷歌的新匿名凭证库[11]那样将凭证绑定到硬件上,例如手机的信任平台模块。这样窃取变难了,但硬件一旦被破解,后果会更严重。
如何构建一次性凭证
乔姆的原始方案就是一次性凭证,其底层基石是盲签名方案[12]。简单来说,运行一个协议,用户最终能得到一条消息的有效签名,而签名服务器却不知道自己签了什么消息。
我们假设已经有了可用的盲签名方案,构建一次性匿名凭证的流程大致如下:
- 颁发方生成签名密钥对,公开公钥。
- 用户想获得凭证时,随机选一个足够长的序列号。
- 用户和颁发方运行盲签名协议。用户把序列号作为消息,最终得到序列号的签名。序列号和签名就构成了用户的凭证。
向网站出示时,用户只需给出序列号和签名。网站用公钥验证签名,并检查这个序列号之前没被用过。如果只有一个网站使用这种凭证,它可以自己维护一个已用序列号数据库。如果多个网站都要用,那得靠一个集中化的服务来做检查。
乔姆的凭证方案已有四十年历史。只要颁发方愿意承担运行盲签名协议的成本,而网站也不介意每次验证签名,这个方案依然有效。隐私通行证实际上就是用盲签名实现的[13]。
一次性凭证的两个大麻烦
实用性问题和表达能力问题。想象一下用匿名凭证替代谷歌的会话Cookie,这意味着用户每天可能需要获取和出示成千上万个一次性凭证。
一个折中办法是只在首次注册网站时使用匿名凭证,之后换取网站分配的一个伪身份继续使用。但这样一来,后续所有访问又都能被关联了。
表达能力问题更棘手。
我们需要更复杂的证明
简单的“手环”凭证只能证明一件事:比如你满21岁。有时我们需要数字凭证证明更复杂的信息。假设我要加入一个加密货币交易所,它需要证明我是美国居民,但不是纽约州居民,并且年龄超过25岁。
我可以直接把州车管局颁发的数字驾照(这是一个真实存在的东西[14])交给网站。这份数字文件包含家庭住址、发证州、眼睛颜色、出生地、身高体重、发色性别等大量信息。
坏处是,网站不仅得到了它需要的信息,还看到了我的家庭住址等隐私,这些信息可能被用来给我发垃圾邮件。理想情况是,我只向网站证明我满足它关心的特定条件,别的信息一概不泄露。
在刚才的例子中,我需要证明的就是:
- 我的出生日期早于某个日期。
- 发证州不是纽约。
- 发证国家是美国。
- 签名由某个州车管局的公钥验证通过。
零知识证明:强大的解决方案
一种方案是找个中央颁发方,给它看我的整个驾照,让它给我发一个证明我符合条件的一次性“手环”凭证。这需要我信任这个第三方,而且每次登录都要找它。
另一个更好的办法是使用零知识证明[15]。它允许证明者,在不透露任何额外信息的前提下,证明自己知道某个满足特定约束的秘密值。我可以用零知识证明让网站相信,我持有一份有效的、签过名的驾照,且驾照中的某些字段满足条件。网站能确信我拥有有效驾照,却得不到驾照本身的任何信息。
非交互式零知识证明更棒,用户只需一次性发送消息给网站即可完成证明。
零知识证明功能强大。我不仅可以灵活地证明不同的约束,还能用同一份驾照进行无数次“出示”,而网站无法将这些“出示”关联到同一个人身上。这正好解决了基本一次性凭证的效率问题。
克隆战争:可复用带来的新麻烦
可复用的凭证一旦被窃,后果是灾难性的。黑客可以无限克隆而不被察觉。如果“黑客”本身就是你的合法用户之一呢?
谷歌新提出的匿名凭证方案[16]试图通过将凭证绑定到手机的安全元件来增加窃取难度。这要求全球海量手机的安全性都非常出色。但系统安全是由最薄弱的环节决定的。只要任一型号或批次的手机被破解,整个系统的完整性就可能崩塌。
用零知识证明限制使用次数
一个巧妙的办法[17]是限制单个凭证的使用次数,比如最多能用N次。这与让用户提取N个一次性凭证类似,但工作量小得多。
具体实现可以为凭证嵌入一个密钥,用于伪随机函数生成序列号。每次出示时,用户计算序列号,并同时证明两件事:序列号是用凭证中的密钥按规则生成的,以及当前使用次数计数器i小于N。网站记录所有见过的序列号,一旦发现重复就拒绝。这样一来,诚实用户不会触线,但作弊者试图多用一次就会被发现。
这个概念还有很多变体。比如,可以轻松调整为允许用户每天最多使用100次。只需要把当前的日期也作为伪随机函数的输入即可。相关详细技术可以看一篇很棒的论文[18]。
凭证的过期与撤销
在凭证中添加一个过期时间字段很容易。只要在每次出示的零知识证明中加入一个时间判断即可。
凭证撤销则复杂一些。匿名用户没有身份,如何将其加入黑名单?办法还是有的。
让用户在出示时,证明自己不在已知的黑名单中。黑名单由一系列凭证出示交互记录组成。当网站怀疑某个用户行为不端时,它会将这次交互的唯一标识和用户出示的序列号加入黑名单。此后,其他用户在出示凭证时,必须额外证明他的密钥不会在任何一次黑名单交互中产生对应的序列号。
这增加了用户的工作量——如果黑名单上有M个条目,用户就需要多做M项证明。但只要黑名单规模可控,这办法还是可行的。
下一站:现实世界的真实样貌
上面我们只是浅尝辄止。我们还没讨论如何具体构建这些组件,也还没回答那些棘手的现实问题:这些数字身份证书从哪来?我们到底要拿它们干什么?
在接下来的文章里,我会通过两个现实案例让一切都变得更具体:一个是隐私通行证,另一个是谷歌最新的方案——将匿名凭证与你手机里的驾照信息进行绑定。
头条图片来源:Islington Education Library Service[19]
参考资料
[1] https://www.passkeys.io/
[2] https://en.wikipedia.org/wiki/CAPTCHA
[3] https://www.theverge.com/tech/883855/age-verification-internet-apps-laws-privacy-safety
[4] https://www.facebook.com/help/1386337538619854
[5] https://www.eff.org/deeplinks/2025/08/no-uks-online-safety-act-doesnt-make-children-safer-online
[6] https://www.bbc.com/news/articles/cjr11qqvvwlo
[7] https://dl.acm.org/doi/10.1145/4372.4373
[8] https://knowledge.workspace.google.com/admin/apps/about-sso?hl=en&visit_id=639080578425509551-100583190&rd=1
[9] https://blog.cloudflare.com/privacy-pass-standard/
[10] https://privacypass.github.io/
[11] https://github.com/google/longfellow-zk
[12] https://blog.cryptographyengineering.com/a-note-on-blind-signature-schemes/
[13] https://datatracker.ietf.org/doc/html/rfc9578
[14] https://mva.maryland.gov/Pages/mdMobileID.aspx
[15] https://blog.cryptographyengineering.com/2014/11/27/zero-knowledge-proofs-illustrated-primer/
[16] https://www.w3.org/events/meetings/5d75b3cc-a2c8-45c6-a13a-54c667dcc91a/20250429T120000/
[17] https://eprint.iacr.org/2005/060
[18] https://eprint.iacr.org/2006/454
[19] https://www.iels.org/
[20] https://blog.cryptographyengineering.com/2026/03/02/anonymous-credentials-an-illustrated-primer/
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:幻泉之洲 《匿名凭证技术上-入门图解》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。



![[工具教程]Burp效率封神!xiaLiao插件一键生成测试信息,渗透测试省一半时间](/images/random/titlepic/15.jpg)







评论