论文: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 撤销中,累加器维护有效或已撤销凭证标识符的集合,提供优于列表式方案的隐私特性。

基本机制

工作流程

  1. 初始化:Issuer 基于强 RSA 假设或双线性配对初始化累加器
  2. 累积:颁发凭证时将凭证标识符加入累加器,更新累加器值
  3. 见证生成:为每张凭证生成见证值 $w_i$——证明该凭证包含于集合的密码学证明,不暴露其他成员信息
  4. 撤销更新:撤销凭证时将其从有效集合移除(或加入撤销集合),更新累加器值;未撤销凭证的见证值通常须随之更新
  5. 验证: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)