论文:A Survey on Credential Revocation and DID Deactivation in Self-Sovereign Identity Systems 来源:IEEE Access, Volume 14, 2026(收稿 2025-12-12,接收 2025-12-26) 作者:Younho Lee(首尔科学技术大学)、Hojune Shin(首尔科学技术大学)、Daeseon Choi(崇实大学,通讯作者) DOI:10.1109/ACCESS.2025.3649792
一、论文定位与贡献
本文是第一篇专门聚焦 SSI(自主主权身份)凭证与 DID 撤销机制的全面综述,采用叙事性文献综述(NLR)方法,覆盖学术研究、W3C/IETF 标准及 Hyperledger Indy 等商业生态部署。
主要贡献:
- 提出 VC 撤销的四类结构化分类框架:列表式、累加器式、正向确认、治理感知,并独立覆盖 DID 注销
- 评估安全性、隐私性与性能的权衡,弥合理论方案与实际部署之间的差距
- 识别若干持续性挑战:隐私与问责的平衡、离线验证、密钥泄露处理、后量子就绪性、监管合规
二、SSI 基础架构
信任三角(Triangle of Trust)
SSI 系统围绕三个核心角色运作:
Issuer(颁发者):对主体做出权威声明并颁发 VC 的实体,包括政府机构、教育机构、雇主、医疗机构等。Issuer 用私钥对 VC 进行密码学签名,使其可被独立验证,无需与颁发机构持续通信。这一"颁发后独立性"特征既是 SSI 的核心优势,也构成了撤销机制的根本挑战——Verifier 无法在验证时实时询问 Issuer 当前状态。
从撤销角度,Issuer 承担以下职责:管理签名密钥对;向 VDR(可验证数据注册表)发布公钥与撤销信息;在凭证失效时触发撤销流程;遵守凭证元数据标准。Issuer 同时需要制定撤销策略,明确触发事件(员工离职、执照暂停、密钥泄露)、处理时间线、撤销粒度(单个凭证 vs 批量)及监管合规要求。
Holder(持有者):在数字钱包中管理一张或多张 VC,自主决定向谁披露何种信息的个体或机构。Holder 在撤销机制中处于双重位置:既可能是被撤销的对象,也需主动向 Verifier 证明自身凭证的有效状态(提供非撤销证明)。
Holder 在撤销问题上面临利益冲突:当私钥被盗时希望立即撤销;而当凭证因离职或执照暂停被撤销时,则可能希望存在宽限期。设计健全的系统确保 Holder 无法控制撤销状态——Verifier 直接从可信来源(签名状态列表或密码学累加器)检查状态,Holder 仅提供验证所需的最少信息。
在使用累加器或状态列表时,钱包通常缓存一个小的见证值(witness),使访问控制系统可在不获取额外信息的前提下确认"仍然有效"。在网络断开时,该见证值支持一个策略约束的短暂宽限窗口;恢复连接后再对当前状态制品进行刷新。
Verifier(验证者):接收并审查 VP(可验证陈述)并决定是否信任相关声明的一方。验证流程包括:检查 Issuer 的公钥签名、有效期、撤销状态,并做出接受或拒绝决定。Verifier 与 Issuer 之间的信任关系通过治理安排或监管监督预先建立。
Verifier 面临实时撤销状态不一定可获取的问题——注册表可能因维护而离线,本地网络可能中断。此时 Verifier 只有缓存数据,需要基于风险评估做出决策:高风险交易直接实时确认撤销状态;低风险交易可通过缓存检查。
技术组件
DID(去中心化标识符):格式为 did:method:identifier,解析为包含公钥、服务端点与认证方法的 DID Document,通常存储于 VDR。DID Document 中与撤销直接相关的组件包括:公钥(用于签名验证)、服务端点(用于接收撤销通知)、能力委托机制(在紧急撤销场景中可授权他人代为操作)。
不同 DID 方法对撤销的影响存在显著差异:
| DID 方法 | 存储机制 | 撤销特点 |
|---|---|---|
did:web |
HTTPS/DNS | 实现简单,但依赖域名控制的持续性,域名到期可能导致控制权丧失 |
did:ethr |
以太坊区块链 | 强防篡改性,但频繁更新面临吞吐量限制与交易成本 |
did:indy |
Hyperledger Indy | 专为身份设计,内置完善的撤销支持 |
did:key |
无外部存储 | DID 直接派生自公钥,撤销等价于密钥撤销 |
VC(可验证凭证):包含声明与元数据的数字凭证,由 Issuer 密码学签名,无需实时通信即可验证。与撤销相关的关键字段:credentialStatus 字段引用外部撤销机制(状态列表或累加器),是 Verifier 检查撤销状态的入口;proof 部分包含 Issuer 的数字签名以及见证更新或零知识证明生成所需的附加信息。
VP(可验证陈述):VC 的集合或派生证明,支持选择性披露。VP 的选择性披露特性与撤销机制之间存在张力——许多撤销机制在状态检查时会暴露稳定标识符,使 Verifier 能够跨多次陈述进行关联,损害 VP 的隐私性。
VDR(可验证数据注册表):存储 DID 文档、公钥、凭证 Schema、撤销状态数据与治理记录的共享防篡改存储库。实践中通常采用混合架构:区块链作为不可变锚点处理关键或低频更新,数据库或文件系统层(如 IPFS)处理频繁变化的撤销列表,以平衡信任与性能。
SSI 工作流中的撤销
颁发阶段:Issuer 在签发 VC 的同时启用撤销机制,发布初始状态,并为 Holder 提供展示非撤销状态所需的见证材料。
验证阶段:撤销状态检查须在每次 VP 验证时执行,同时维护隐私并避免 “calling home” 问题(即每次验证都联系 Issuer,使 Issuer 获知 Holder 的凭证使用行为)。Holder 可能需要在 VP 中附加非撤销证明,Verifier 则需对此进行密码学验证。
三、撤销在 SSI 中的挑战来源
传统 PKI 的 CRL 和 OCSP 与 SSI 的三条核心原则存在根本冲突:
- 避免持续的三方交互:OCSP 每次验证都须实时联系 CA,直接违反颁发后独立性原则
- 强隐私保障:CRL 暴露完整撤销列表;OCSP 使 CA 获知验证双方的身份与时间信息
- 防止单点故障:中心化撤销服务一旦不可用,全网验证即告中断
SSI 因此需要同时满足去中心化、保密性、可扩展性与离线可验证性的全新撤销机制。
四、典型用例
VC 撤销场景
员工凭证撤销:员工离职后,关联凭证须立即失效以防止对公司资源的持续访问。在 SSI 环境中,Verifier 不能直接向公司(Issuer)查询状态,否则构成隐私侵犯。撤销须在不揭示 Holder 行为的前提下独立完成。
医师执照暂停:医师执照因法律原因须临时或永久吊销。撤销系统需支持临时与永久两种模式,同时保证患者可在离线状态下及时验证医师凭证的有效性。
学位证书欺诈:大学发现伪造材料获得的学位须予以撤销。系统在撤销时须保护合法持有者的个人信息,同时具备抵御关联攻击的能力(防止通过多次撤销检查推断同一 Holder 持有哪些凭证)。
DID 注销场景
私钥泄露(EU 数字新冠证书事件,2021年):黑客泄露 EU 数字新冠证书签名私钥,导致可为任意主体生成通过官方验证的假健康码。当局撤销泄露密钥后,所有依赖该密钥颁发的证书即刻失效。该事件展示了 DID 私钥泄露后须立即注销对应 DID 的实际场景。
设备丢失(移动驾照,mDL):DID 通常与存储在设备上的密钥绑定。手机丢失时,现代 mDL 系统允许 Issuer 或用户远程注销关联的数字身份,使其无法再被任何人使用。该能力已成为数字身份部署的标准安全实践。
did:web 域名到期劫持:did:web 依赖互联网域名托管 DID Document。域名注册到期后,第三方可购买该域名并发布自定义的 DID Document,完全劫持原来的 DID 控制权。社区已意识到此风险,并催生了 did:webs 等内嵌密码学证明的新方法以防止域名易主后的控制权丧失。
基础设施关闭(Sovrin MainNet,2024年):Sovrin 基金会因可持续性与监管挑战,宣布于 2025 年 3 月前关闭 MainNet 账本。此后,所有基于 did:sov 的 DID 将无法解析或更新,等同于批量注销。使用这些 DID 的组织须迁移至其他 DID 方法,该事件揭示了 DID 可移植性规划的重要性。
五、撤销机制分类详解
A. 基于列表的撤销(List-Based Revocation)
A1. 证书撤销列表(CRL)及 SSI 变体
Issuer 维护被撤销凭证标识符(或哈希)的签名列表,定期推送至 VDR,Verifier 下载后比对。在 SSI 语境中,列表存储凭证标识符或哈希,而非传统的证书序列号,存储位置为 VDR 而非中心化服务器。
主要限制:公开列表会暴露 Issuer 的撤销频率及凭证类型分布;列表大小随系统规模线性增长;时效性存在缺陷——Issuer 即时记录撤销,但 Verifier 仅在下次拉取时才获知变更。
A2. 位字符串状态列表(Bitstring Status List, BSL)
W3C 推荐的主流方案。每张凭证在颁发时分配固定索引位置,BSL 为压缩位数组,撤销时将对应 bit 从 0 翻转为 1。Issuer 对整个位字符串签名并重新发布至 VDR,Verifier 检查凭证索引处的单个 bit,时间复杂度 O(1)。
压缩技术:BSL 使用 GZIP 减少存储与传输开销。GZIP 通过 LZ77 风格的子串去重检测重复字节模式,再应用霍夫曼编码对剩余符号进行熵编码。撤销率低时(大量 bit 为 0),压缩比极高。
隐私问题:跨多次陈述复用同一状态索引可能导致可关联性——Verifier 可通过索引追踪同一 Holder 的使用行为。缓解措施包括:短期索引、按用途分区、结合零知识证明进行索引保护。
BSL 可配合 CDN 分发,支持高效的离线验证路径。微软 Entra Verified ID 采用了该方案。
A3. 在线状态协议(Online Status Protocol, OSP)
类比传统 PKI 的 OCSP,Verifier 实时向状态服务查询特定凭证的当前状态,服务返回状态、时间戳与密码学证明。部分协议采用零知识证明或盲签名等隐私保护扩展。
根本缺陷为"calling home"问题:每次查询使状态服务或 Issuer 获知验证双方的身份与时间信息,严重违反 SSI 隐私原则,并引入对在线服务可用性的依赖,可能开启监控与审查。该方案仅适用于高安全性场景下隐私代价可接受的情形。
OpenAttestation 框架采用 OSP 进行验证,但其状态信息服务是中心化的,网络故障或服务中断会中断验证流程。
B. 密码学累加器(Cryptographic Accumulators)
密码学累加器用紧凑值表示集合,支持高效的成员关系证明而不暴露其他成员信息。在 SSI 撤销中,累加器维护有效或已撤销凭证标识符的集合,提供优于列表式方案的隐私特性。
基本机制
工作流程:
- 初始化:Issuer 基于强 RSA 假设或双线性配对初始化累加器
- 累积:颁发凭证时将凭证标识符加入累加器,更新累加器值
- 见证生成:为每张凭证生成见证值 $w_i$——证明该凭证包含于集合的密码学证明,不暴露其他成员信息
- 撤销更新:撤销凭证时将其从有效集合移除(或加入撤销集合),更新累加器值;未撤销凭证的见证值通常须随之更新
- 验证:Holder 在 VP 中提供见证值,Verifier 用当前累加器值验证成员关系(或非成员关系),无需查看完整撤销列表或联系 Issuer
两种类型:正向累加器(Positive Accumulator)累积有效凭证集合,见证值证明"属于有效集合";通用累加器(Universal Accumulator)同时支持成员证明与非成员证明。
B1. RSA 累加器
经典构造(Benaloh & de Mare, 1994):
在 RSA 模数 $n = pq$(安全素数)、生成元 $g \in QR_n$ 下,对集合 $S = {x_1, ..., x_k}$ 的素数编码元素,累加器值为:
$$A_S = g^{\prod_{x \in S} x} \mod n$$元素 $x$ 的成员见证:$w_x = g^{\prod_{y \in S \setminus {x}} y} \mod n$,验证:$w_x^x \equiv A_S \mod n$
安全性基于强 RSA 假设,但传统构造要求所有累积元素为素数,导致代价高昂的哈希到素数操作,在处理大型数字对象时尤为突出。
无素数要求的 RSA 累加器(Kemmoe & Lysyanskaya, CCS 2024):
使用随机预言机 $H$ 将输入映射至大奇数集合 $\text{Odds}(2^{\ell-1}, 2^\ell - 1)$,累加器定义为 $A_S = g^{\prod_{x \in S} H(x)} \mod n$。随机大奇数几乎必然有大素因子,从而避免了除数泄露漏洞,同时维持方案的可靠性。
该方案的关键创新在于见证更新机制:当元素 $y$ 被撤销时,协议维护 $H(x)$ 与所有已撤销元素哈希值之间的 GCD 信息,利用 Shamir 技巧在 $H(x)$ 与 $H(y)$ 非互质时仍能正确计算更新见证——此为与此前方案相比的核心突破(此前构造均要求哈希结果互质)。
该方案还结合 Wesolowski 的 VDF 处理任意奇数,支持通过指数证明(Proof of Exponentiation)生成批量成员证明,同时具备正向累加器与通用累加器特性,适合 WebPKI 场景中计算能力有限的 CA。
B2. 双线性配对累加器(Bilinear Accumulators)
基本构造:
参数:$G_1, G_2$ 为素阶 $q$ 的循环群,$g_1 \in G_1, g_2 \in G_2$ 为生成元,$e: G_1 \times G_2 \to G_T$ 为双线性配对,$\alpha \in \mathbb{Z}_q$ 为秘密陷门值。
对集合 $S = {x_1, ..., x_n}$,累加器为 $V = g_1^{\prod_{x \in S}(x+\alpha)}$;$y \in S$ 的见证 $w_y = g_1^{\prod_{x \in S, x \neq y}(x+\alpha)}$;验证:$e(w_y, g_2^{y+\alpha}) \stackrel{?}{=} e(V, g_2)$。
方案演进:
-
Nguyen(2005):首次提出双线性累加器,证明代数可行性,但每次更新须重新计算累加器值并刷新所有未撤销成员的见证,计算成本随集合大小增长;缺乏高效的删除与批量撤销机制
-
Karantaidou & Baldimtsi(CSF 2021):构造正向与通用累加器,引入常数大小的成员/非成员证明及零知识变体,解决了此前方案缺乏高效非成员证明、见证大小或验证成本随撤销数量增长的问题,支持高效动态更新
-
Vitto & Biryukov(RSA 2022):提出基于多项式的批量更新机制。设 $A$ 为新增元素集,$D$ 为撤销集,定义 $A(X) = \prod_{a \in A}(X-a)$,$D(X) = \prod_{d \in D}(X-d)$,新累加器 $V' = \frac{A(-\alpha)}{D(-\alpha)} \cdot V$,见证对应批量更新。更新可委托给不可信服务器执行(结果仍可公开验证),安全性基于广义 $t$-强 Diffie-Hellman 假设
-
ALLOSAUR(Jaques et al., AsiaCCS 2024):专注于见证更新过程中的隐私保护。传统方案中见证更新须由权威方或外部服务执行,可能泄露敏感信息。ALLOSAUR 使用安全多方计算(MPC):多个独立方联合执行更新,确保无单一方获取 Holder 的更新见证,且见证更新匿名且不可关联至特定 Holder。协议复杂度 $O(\sqrt{m})$($m$ 为撤销数量),实践中处理 1000 次撤销耗时不超过 500ms,通信开销仅 16KB
B3. Merkle Tree 累加器
仅依赖密码学哈希函数构造,无需特殊密码学假设,适合区块链原生与资源受限场景。叶子为消息哈希,父节点为子节点哈希的拼接哈希,根哈希即累加器值。见证为目标消息的所有兄弟节点与祖先节点,大小 $O(\log n)$,验证仅需哈希运算,速度快,实现简单,易于审计。
非成员证明的挑战:传统 Merkle Tree 优化于成员证明,非成员证明(“该凭证不在撤销集合中”)需要额外策略。Sparse Merkle Tree(SMT)通过覆盖所有可能的哈希值位置并为空叶子赋予明确默认值,同时高效支持成员证明与非成员证明。SMT 已被 Ethereum 2.0 与 Diem(前 Libra)用于状态及撤销注册表。
隐私增强的近期工作:
- Prevoke(IEEE Blockchain 2024):可配置的隐私保护撤销,支持对披露策略的细粒度控制
- Sitouah et al.(ICBC 2024):通过随机哈希值构造不可追踪的 Merkle Tree 累加器,防止跨不同验证的非撤销证明之间的关联
- 零知识友好 Merkle Tree:使用 ZK 友好哈希函数与电路设计,使用户无需暴露树中位置即可证明非撤销状态
B4. 累加器更新与见证管理
动态累加器面临固有的同步挑战:每次撤销改变公开累加器值,使所有未撤销 Holder 的见证值失效。主要解决策略:
广播更新(Broadcast Updates):Camenisch & Lysyanskaya 的开创性工作——Issuer 广播公开更新数据 $U_t$,Holder 无需交互即可自行更新见证,保护隐私。异步累加器支持延迟更新,通用累加器增加非成员证明。发布间隔 $\Delta$ 直接决定撤销延迟。
见证更新服务(Witness Update Services):专用服务代替资源受限设备(智能手机、IoT 节点)计算见证更新。可观察的更新模式带来隐私风险,需配合匿名交互协议与密码学审计日志缓解。
批量更新(Batch Updates):将多次撤销事件打包处理。批次大小 $B$ 或时间间隔 $\Delta$ 是新鲜度与效率的权衡参数。双线性配对构造在批量操作上表现最优;ALLOSAUR 通过遗忘式批处理实现亚秒级延迟;IoT 环境受益于更低的通信开销。
见证与证明聚合(Proof Aggregation):配对基累加器天然支持证明聚合,验证速度线性提升;RSA 变体需要专用例程实现类似效果。大规模聚合降低验证成本,但在成员状态变化时使更新复杂化。
B5. 零知识集成
将密码学累加器与零知识证明(ZKP)结合,可实现最强隐私保护:Holder 证明"撤销句柄不在 Issuer 的撤销累加器中",而不暴露句柄本身。
在 W3C VC 生态中,ZK 非撤销模式可与 VCDM 2.0 标准化的 BSL 机制并行使用;非成员证明可与选择性披露证明组合,使 Verifier 同时获得所需属性与隐私保护的撤销状态。
代表性方案的特性对比:
- BBS+:在 W3C Data Integrity 下支持不可关联派生证明,适合选择性披露与非撤销证明的组合
- SD-JWT:通过加盐哈希承诺实现选择性披露,本身不是 ZK 证明;ZK 非撤销证明须在展示层单独附加
- Groth16:证明体积最小,但需要可信设置
- PLONK:支持灵活电路与长期部署,通用可更新设置
- STARKs:无可信设置,趋向后量子安全,但证明体积较大
设备约束:ZK 证明生成(Prover)远比验证(Verifier)消耗资源,在受限设备上是瓶颈。缓解措施包括:专用电路设计、SNARK 友好哈希(如 Poseidon)、隐私保护的外包证明(zkSaaS)。
Hyperledger Indy / AnonCreds:历史上依赖累加器"尾文件(tails)“与非撤销见证实现不可关联性。在未经仔细分区与分发的情况下,尾文件可能扩展至 GB 级,对存储与网络传输构成实际压力。
C. 正向确认模型(Positive-Confirmation Approaches)
与传统"负向确认”(证明凭证不在撤销列表中)不同,正向确认模型要求凭证被明确且当前地确认为有效,缺乏确认即视为无效。
C1. 短期凭证自动重颁发(Short-Lived Re-Issuance)
Issuer 定期刷新有效期极短(数小时至数天)的凭证或证明,到期即视为撤销,无需维护独立的撤销列表。代表标准为 RFC 8739(ACME-STAR),标准化了 TLS 短期证书的自动化续期。
优势:无需始终在线的撤销查询,与操作密钥或策略轮换对齐,Verifier 仅检查有效期即可,离线友好。
限制:Holder 须频繁与 Issuer 联系,与 SSI 的颁发后独立原则存在张力;无法应对紧急情况(如密钥泄露后须等到当前凭证自然到期);刷新模式本身可能引入时序关联风险。
C2. 允许列表分发(Trust-Anchor/Allow-List Distribution)
Verifier 仅接受当前允许列表中的 Issuer 或密钥签发的凭证,允许列表的更新本身代表信任状态的变化。在 ISO/IEC 18013-5(移动驾照标准)中,AAMVA 的 DTS/VICAL 分发当前 Issuer 公钥,使 Verifier 依赖"当前可信的 Issuer"而非全局撤销检查。
C3. 关联有效性可验证凭证(LVVC, Linked Validity Verifiable Credential)
将内容 VC 与状态解耦:内容 VC 包含相对稳定的声明内容,LVVC 是一个小型、频繁刷新的有效性令牌(仅包含最少状态与时间戳信息)。Verifier 同时需要两者;若内容 VC 须被撤销,Issuer 停止颁发对应 LVVC 即可——“缺乏正向确认即为无效”。
优势:更新体积小(只需更新 LVVC),限制内容暴露;由于 LVVC 频繁刷新而 Verifier 始终获得最新 LVVC,Verifier 无需联系 Issuer,提升 Holder 隐私。
权衡:需要 Holder 定期与 Issuer 联系(与颁发后独立性原则存在张力);刷新模式可能带来时序/关联风险。缓解措施包括随机化刷新窗口、不可关联刷新令牌与隐私保护状态证明。Procivis 已在实践中实现 LVVC,与 BSL 并行部署。
D. 治理感知与自适应撤销(Governance-Aware and Adaptive Revocation)
该类方案关注撤销的组织、政策与监管层面,而非密码学机制本身。
层级管理(Hierarchical Management):在大型组织中,各级管理者在可控范围内拥有撤销权限,全局管理员控制全局范围。优势在于精细管理,挑战在于防止未授权的权限提升,以及建立有效的审计机制。
联邦撤销(Federated Revocation):多组织环境中,撤销决策须经跨组织的司法管辖协调与共识机制。须考虑与 SSI 现有方法的兼容性。
可配置/自适应策略控制(Adaptive Policy-Based Control):可配置系统允许管理员设置隐私级别、新鲜度要求与传输格式参数;自适应系统则根据当前网络条件和安全威胁自动调整撤销策略,确保系统韧性与跨格式互操作性。
E. DID 注销(DID Deactivation)
DID 注销与 VC 撤销是两个正交的层次,须独立处理以避免"过度撤销"。
W3C 规范的信号机制:DID 注销通过 DID 解析元数据(didDocumentMetadata.deactivated = true)表示,而非修改 DID Document 内部字段。DID Core 规范将注销的存在性、授权方式与效果委托给具体 DID 方法规范及其关联治理框架。
控制者发起的注销(Owner-Initiated Deactivation):DID 控制者使用专用恢复密钥授权 deactivate 操作。成功后,解析器返回 deactivated = true,方法规则不再处理该 DID 的任何后续操作(实质上不可逆)。Sidetree/ION 方法明确区分 recover 与 deactivate 操作,deactivate 执行后所有后续操作均被忽略。
不同 DID 方法的注销实现存在差异:追加式账本方法记录墓碑/Deactivate 条目;did:web 通过使 did.json 不可访问(如删除)来表示注销;链下方法依赖解析器元数据或代理中介状态。
行政撤销(Administrative Revocation):部分 SSI 环境中,网络管理员或监管机构在满足特定条件(政策违规、法律命令、安全事件)时拥有有限的 DID 注销权力。此类能力须在规则规范与治理框架中明确界定,以维持与 SSI 用户控制原则的一致性。Sierra Leone 的 Kiva/Indy 项目展示了基于行政措施(而非技术手段)进行治理设计的实践。
密钥泄露与应急响应(Key Compromise and Emergency Procedures):私钥泄露时,优先选择密钥恢复或轮换(保持标识符连续性),仅在恢复不可行或风险评估要求退休时才执行注销。支持机制包括:专用恢复密钥(区别于更新密钥)、多签名或社会恢复机制。推荐分阶段响应:将 DID 标记为高风险 → 尝试恢复/轮换 → 确认泄露后执行完全注销。
与 VC 撤销的关系:DID 注销影响该标识符下的所有密钥与服务,间接影响依赖该 DID 的 VC 验证流程。但凭证撤销状态由 VC 状态列表或累加器管理,与 DID 注销正交,系统应独立处理两个层次以避免过度撤销。
六、隐私分析
隐私泄露的三类场景
Manimaran et al. 在研究 SSI 环境中通过 Issuer 查询撤销信息时,识别了三类具体隐私泄露场景:
场景一:Holder-Verifier 关联泄露:若 Verifier 向 Issuer 查询撤销状态,Issuer 即可获知验证双方的身份与时间信息。典型案例:雇主 A(Issuer)为员工 X(Holder)颁发工作凭证,员工 X 在雇主 B(Verifier)处面试时,雇主 B 向雇主 A 查询凭证状态,使雇主 A 获知员工 X 的求职行为。
场景二:Holder 状态与唯一标识泄露:任何第三方均可向 Issuer 查询特定 Holder 的 VC 状态,可用于推断其就业状况等敏感信息。
场景三:撤销率泄露:Issuer 的批量撤销率变化可能揭示商业敏感信息,如员工离职率或监管调查情况。
各利益相关方的隐私风险
在线撤销系统使 Issuer 可以观察到凭证被使用的时间与地点,违背颁发后独立性原则。Verifier 不应获得 Holder 的其他凭证或历史交互的可见性,可通过零知识撤销证明实现。网络观察者可从流量模式中提取元数据(如使用时间、地理位置),须通过缓存、批量分发或匿名化技术缓解。组织层面的撤销率本身也可能泄露敏感商业信息,部分实现通过将撤销证据与原始凭证标识符解耦(如 LVVC),或应用时延发布策略来降低推断风险。
七、可扩展性与性能比较
论文 Table 2 对各方案可扩展性与性能的系统比较:
| 方案 | 典型存储 | 验证时间 | 更新频率 | 网络开销 |
|---|---|---|---|---|
| CRL / OCSP | 线性增长(WebPKI 达数十 MB) | <10ms(缓存/Stapled 状态) | 每次撤销或缓存过期时 | 无 Stapling 时高;频繁在线查询 |
| BSL | 每人群分段常数大小(KB 级) | <50ms(bit 检查 + 签名验证) | 周期性批量更新(日/周) | 低(CDN/缓存分发;CRLite 式推送可行) |
| 累加器(RSA/配对基) | 常数大小公开累加器 + 每 Holder 见证(数百字节至 KB 级) | 50–200ms(模指数/双线性配对) | 频繁见证刷新(每次撤销事件) | 中等(见证更新随撤销率增长) |
| ZKP 选择性披露(BBS+/Groth16/PLONK/STARKs) | 每次陈述的证明制品(数十 KB) | 200–800ms(移动端,含预计算/批处理) | 陈述时;Issuer 更新与证明解耦 | 中-高(制品比列表大,但离线友好) |
| Hyperledger Indy / AnonCreds | 尾文件可能达 GB 级(无分区时) | 取决于证明类型;含缓存时实践中亚秒级 | 撤销事件时注册表更新 | 中等(须仔细分片/CDN 策略处理尾文件) |
各方案无法在所有维度同时占优。BSL 提供优秀的 Verifier 端性能与简单的离线分发语义,代价是 Issuer 定期发布与 CDN 维护。累加器缩减公开状态大小,但将见证刷新责任转移给 Holder,使设备能力与连接模式成为一类设计约束。ZKP 栈实现强隐私与最小关联面,可扩展性取决于预计算、简洁证明系统与跨用户会话的摊销。
八、开放挑战与未来方向
隐私与问责的平衡
SSI 对隐私、不可关联性与用户控制的强调,与合法监管对可追踪性、可审计性与合规性的需求之间存在根本张力。反洗钱(AML)法规要求保留详细的身份验证记录;GDPR 赋予数据删除权与区块链不可变性存在冲突;执法机构可能需要调查凭证滥用或欺诈行为,而 SSI 的隐私保护特性增加了此类调查的难度。
研究方向包括:选择性审计能力(特定凭证可审计,其余保持隐私)、时延透明度(审计信息在指定延迟后公开)、门限披露(仅在满足特定条件时披露审计信息)、基于密码学方法的隐私保护审计技术。
离线验证的复杂性
在移动、IoT 与应急场景中,网络连接不能保证。离线 Verifier 只有本地缓存数据,面临三重困境:信息新鲜度与存储开销的权衡、多个离线 Verifier 之间撤销状态视图的一致性问题、资源受限设备难以执行复杂密码学运算。研究方向包括高级缓存策略、基于使用模式的预测性预加载、优雅降级的混合在线-离线验证,以及支持间歇连接的分布式共识机制。
密钥管理与恢复
SSI 的去中心化将密钥管理责任完全压给终端用户,带来如下挑战:私钥丢失导致无法证明凭证有效性;传统密钥托管(如可信密钥代管)与 SSI 最小化中介原则冲突;SSI 环境中密钥泄露难以自动检测;长期凭证面临密码算法在凭证到期前即遭破解的风险;多设备场景下部分密钥安全、部分密钥泄露的处理更为复杂。
研究方向包括:社会恢复机制(向可信对等方委托部分恢复权)、基于安全飞地/HSM/TEE 的硬件保护、门限密码学(密钥分割为多份,需一定份额才能重建)、支持前向安全性的自动化密钥轮换协议。
后量子密码就绪性
Shor 算法在足量量子比特的量子计算机上可在多项式时间内破解 RSA、ECC 与离散对数问题,直接威胁 SSI 中广泛使用的密码学基础。SSI 系统须同时处理两个难题:迁移至后量子密码算法(PQC),以及为已颁发的长期凭证(生命周期可达数十年)维持向后兼容的可验证性。ZKP 系统同样须 PQC 化——STARKs 与基于格的 ZK 协议是候选方案,但效率与集成至现有 SSI 架构的难度仍是挑战。PQC 就绪性不仅是技术挑战,更是系统性挑战,需在算法变更、基础设施更新与信任锚迁移中全程维持可验证性。
IoT 与边缘计算集成
IoT 设备面临与通用互联网环境不同的撤销约束:计算能力弱、内存小、网络带宽低;设备数量百万级且高度异构;物理安全难以保证(攻击者可能物理接触设备)。研究方向包括:专为资源受限设备设计的轻量级撤销机制、将复杂操作委托给更强边缘设备或网关的层级撤销系统、能在对抗性部署场景中提供更强保证的安全硬件方案。
九、相关综述比较
论文 Table 3 系统比较了此前 8 篇 SSI/DID 相关综述对撤销机制的处理深度:
| 综述 | 对撤销的处理 |
|---|---|
| Soltani et al. (2021) | 提到 VDR 可持有撤销信息,无技术规范或协议细节 |
| Čučko & Turkanović (2021) | 宏观视角梳理 SSI 研究生态,撤销仅作为其中一个位置 |
| Bai et al. (2022) | 提到链上证书撤销与钱包密钥撤销,无具体方法 |
| Ernstberger et al. (2023) | 将撤销与 DID 注销认定为基本功能,但不提供专项分析 |
| Tan et al. (2023) | 强调撤销是核心问题,聚焦去中心化与离线验证需求,无方法细节 |
| Krul et al. (2024) | 列出相关威胁与部分规范参考,无方法细节 |
| Mazzocca et al. (2025) | 引入 W3C Revocation List 2020,认为撤销是"相对欠研究的领域" |
| Misra et al. (2025) | 无撤销相关内容 |
上述综述均未对 SSI 撤销机制提供系统性技术分类与比较,本文填补了这一空白。
十、结论
论文的核心结论是:SSI 中没有单一撤销方案能同时满足所有需求,每种方案均有不同的权衡关系。
列表式方案设计简单、部署广泛,但可能因可关联状态检查损害隐私;带零知识证明的累加器方案增强隐私并减少网络开销,代价是更高的计算复杂度;正向确认策略(短期凭证或 LVVC)避免持续状态检查,但引入频繁的凭证刷新需求;DID 注销支持全局凭证失效,但带来互操作性与治理挑战。
若干根本性技术挑战仍未解决:隐私保护的离线验证、安全的密钥管理与恢复、后量子就绪性、IoT 等资源受限环境的支持,以及异构 SSI 生态系统间的互操作性。此外,法律与监管需求(可审计性、法律责任、数据保护)进一步复杂化了撤销系统的设计空间。
参考
- 论文原文:IEEE Access 2026
- W3C Bitstring Status List v1.0:https://www.w3.org/TR/vc-bitstring-status-list/
- W3C VC Data Model v2.0:https://www.w3.org/TR/vc-data-model-2.0/
- Hyperledger AnonCreds Spec:https://hyperledger.github.io/anoncreds-spec/
- EVOKE(IoT VC 撤销,USENIX Security 2024):Mazzocca et al.
- ALLOSAUR(AsiaCCS 2024):Jaques et al.
- CRLite(IEEE S&P 2017):Larisch et al.
- Prevoke(IEEE Blockchain 2024):Manimaran et al.
- Kemmoe & Lysyanskaya RSA 累加器(CCS 2024)