EVOKE：面向物联网的高效可验证凭证吊销机制

1. 研究背景与动机

1.1 IoT 信任问题

当前全球约有 150 亿台 IoT 设备在线，产生海量数据，但设备间及跨组织的信任缺失严重限制了数据的协作使用。

传统方案——PKI + 中心化 CA 的主要问题：

可扩展性差：海量设备的证书管理集中于少数 CA；
单点故障：CA 被攻陷或下线影响整个信任体系；
跨域互操作性差：不同 CA 管辖的设备难以互信；
自主权缺失：设备对自身身份数据缺乏控制权。

新兴去中心化方案——DID + VC：

W3C 已标准化 去中心化标识符（DID） 和 可验证凭证（VC）；
欧盟 eIDAS 法规将 VC 列为电子身份认证的关键技术；
数字医疗护照、国家数字身份钱包等应用已落地或在研；
Kantara Initiative 引入 Identity of Things（IDoT）：每台设备拥有 DID，通过 VC 向其他设备证明自身能力。

1.2 VC 撤销的特殊挑战

IoT 场景对撤销机制提出了比 Web PKI 更严苛的要求：

挑战	具体表现	EVOKE的解决办法
计算能力受限	部分设备处理器极弱，无法承担复杂密码学操作	最小化计算，用了一种基于椭圆曲线密码学（ECC）累加器的方法，该方法可以将多个数据高效聚合为一个称为“累加值”的唯一元素，并且无论数据量多少，累加值的大小始终保持不变。一个重要特性是：证明某个元素属于该累加器（成员证明）时，其验证时间也是常数级的。
存储容量有限	几十 KB 的存储开销已难以接受	最小化计算这些特性保证了，即使网络中的凭证和设备数量不断增长，EVOKE 仍然能够保持高效运行。
网络不稳定	设备可能处于省电休眠或低带宽环境，无法实时联系 Issuer	EVOKE 还支持一种重要特性：离线撤销即： - 如果某些设备没有收到撤销更新 - 它们仍然可以通过与“已更新设备”交互来同步状态
设备数量巨大	可能有上万甚至百万个设备参与VC的吊销	由于实验的每个设备只要 ~1.5KB，所以非常适合多台设备的同时更新

典型案例：CCS'17 揭示的 RSA 密钥生成芯片漏洞（Nemec et al.）导致超过 70 万张证书需要同时撤销，现有机制难以高效处理此类大规模批量撤销。

1.3 现有方案的不足

方案	每设备存储（100万凭证）	批量撤销	离线撤销
OCSP / OCSP Stapling	~4 KB/次	✗	✗
TinyOCSP	~1.2 KB（但需可靠连接）	✗	✗
CRL	数 MB	✗	✗
Revocation List 2020（W3C）	~125 KB	✗	✗
CRLite	~112.5 KB	✗	✗
Let’s Revoke	~70 KB	✗	✗
V’CER（目前最优）	~3 KB	✗	✓
EVOKE（本文）	~1.5 KB	✓	✓

W3C 目前尚无专用的 VC 撤销标准（仍处于 draft 阶段），EVOKE 填补了这一空白。

为物联网网络中的虚拟控制器提出了一种新颖且高效的撤销机制。我们的方法提供了设备到设备信任建立的直接应用，显着提高了撤销效率，同时实现了大规模撤销 VC 的能力。
EVOKE 支持离线撤销，有效降低网络开销。如果设备错过更新（即累加器值和见证），EVOKE 允许通过利用与网络中其他设备的交互来更新设备。
EVOKE 确保每个设备仅存储验证其他VC 和建立可信通信所需的最少量数据。这种设计最大限度地减少了存储需求，同时保持了系统的完整性。
为了全面评估我们方法的有效性和性能，我们进行了一系列实验，其中包括在多种商用物联网设备上对 EVOKE 进行直接评估。据我们所知，这项工作代表了 VC 撤销的第一个解决方案和设计。

2. 背景知识

2.1 去中心化标识符（DID）

DID 是 W3C 标准化的去中心化身份标识，结构上由三部分组成：

did : <DID method> : <method-specific identifier>
 ↑        ↑                    ↑
URI前缀  方法标识符           方法特定标识符

每个 DID 解析为一个 DID Document（JSON-LD 格式），包含：

密码学公钥；
服务端点（Service Endpoints）；
认证参数；
时间戳与元数据。

DID 无需身份提供商，实体通过对应私钥证明 DID 所有权。DID Document 通常托管在可验证数据注册表（Verifiable Data Registry，通常基于 DLT）上。

2.2 可验证凭证（VC）与可验证展示（VP）

VC 生态系统的四个角色（对应论文 Figure 1）：

Issuer ──(②注册 DID/Schema)──► Verifiable Data Registry
  │                                       ▲
  │(③签发 VC)                   (①注册) (⑤验证)
  ▼                                       │
Holder ──(④发送 VP)──────────────► Verifier

Holder：持有一个或多个 VC 的实体（IoT 场景中即为设备本身）；
Issuer：创建并签发 VC（IoT 场景中通常是设备制造商）；
Verifier：请求并验证 VC 以建立信任（例如：智能锁向烟雾探测器请求 VC 以决定疏散时是否开锁）；
Verifiable Data Registry：调解标识符、密钥、凭证模式等的创建与验证，通常基于 DLT 实现。

VC 的组成元素：Subject URI、Issuer URI、唯一凭证标识符、声明过期条件、密码学签名。

VP（可验证展示）：Holder 将 VC 打包并签名后发送给 Verifier 的数据结构，由 W3C VC 工作组引入。

2.3 密码学累加器

密码学累加器于 1994 年由 Benaloh & de Mare 提出，作为消除可信中心机构的去中心化替代方案。

核心概念：

将一组元素压缩为一个固定大小的承诺值（accumulator value）；
通过简短证明（witness）验证某元素是否属于该集合；
基于单向哈希函数族，满足拟交换性（quasi-commutative），确保累加顺序不影响结果。

累加器类型：

正向（Positive）：支持成员资格证明（membership witness）；
负向（Negative）：支持非成员资格证明（non-membership witness）；
通用（Universal）：同时支持两者。

三类累加器性能对比：

类型	累加器值大小	Witness 大小	验证复杂度	适用性
RSA-based	由模数决定（大）	较大	中	安全性强但资源消耗高
Merkle Tree	固定	O(log n)	O(log n)	大集合时 proof 增长明显
ECC-based（本文选用）	固定（常量）	固定（常量）	O(1)	最适合 IoT 受限环境

本文采用 Vitto & Biryukov（CT-RSA 2022） 提出的正向 ECC 累加器，额外支持批量操作（含批量 witness 生成）。

3. 系统模型与威胁模型

3.1 系统模型

IoT 网络结构（参见论文 Figure 2）：

符号表（论文 Table 1）：

符号	含义
$\mathcal{N}$	IoT 网络集合
$\mathcal{I}$	Issuer 集合
$\mathcal{ACC}$	累加器集合
$j$	地理区域标识
$A_j$	$j$ 区域的单个累加器
$a_j$	$j$ 区域的累加器值
$i_j$	$j$ 区域的 Issuer
$D_j$	$j$ 区域的设备集合
$d_i$	单台 IoT 设备
$W_j$	$j$ 区域的 witness 集合
$w_i$	设备 $d_i$ 的 witness
$b$	DLT

地理分区：每个地理位置 $j$（可以是一个 5G 小区）对应子网络 $n_j \in \mathcal{N}$，其中 $d_i \in D_j \subset \mathcal{D}$，每台设备的 VC 由 $i_j \in \mathcal{I}$ 签发。

三条核心假设：

Issuer $i_j$ 具备充足计算资源，可构建 $a_j$、撤销 VC、批量生成 $W_j$，并通过 DLT 分发更新；Issuer 仅向经过认证且未被攻陷的设备签发 VC；
每台设备 $d_i$ 初始被分配：有效 $\text{vc}_i$、$a_j$、$w_i$、密码学材料、Issuer 公钥 $pk_{i_j}$；
网络中存在具备完整连通性（可直连 DLT）的设备；更新信息通过发布/订阅（pub/sub）范式在 $n_j$ 内传播。

3.2 各组件详解

Issuer：

独立部署于安全环境，仅通过 DLT 与网络通信，不直接与 IoT 设备交互；
记录 $n_j$ 内所有已签发 VC 及设备信息；
全权负责 $a_j$ 的生成与更新、$W_j$ 的计算与分发。

DLT（本文采用 IOTA Tangle，DAG-based）：

作为 Issuer 与 $D_j$ 之间的安全分布式数据源；
安全性来源：数字签名、哈希函数、共识机制、单点故障抵抗性；
即使 DLT 被攻击：可用性可能受影响，但更新完整性不受损（因更新封装在 Issuer 签名 VC 中，伪造需要 Issuer 私钥）；
选用 DAG 而非传统区块链的原因：更低延迟、更低能耗，同时保持透明性与不可篡改性；
每个 $n_j$ 至少有一个 DLT 节点维护账本的最新一致版本。

IoT 设备：

能力差异悬殊（计算力、存储、网络各有不同）；
每台设备仅需存储：$a_j$（区域j的累加器值）、自身 VC、DID 及关联信息、$w_i$（设备$d_i$的witness值），加上最小密码学函数；
具备充足网络能力的设备可直接与 DLT 交互（Direct Retrieval）；
网络能力不足的设备通过邻近设备间接获取更新（Indirect Retrieval）。

3.3 威胁模型

对手模型：采用 Dolev-Yao 模型——攻击者可窃听、拦截、注入任意数量消息，并可尝试攻陷 $n_j$ 中的任意实体。

攻击目标：获取有效 VC，从而建立被网络其他设备信任的通信连接。

三类主要威胁：

① 攻陷 Issuer：

可任意签发合法 VC（虚假声明，非法授权）；
可吊销合法设备的 VC（拒绝服务 DoS，破坏信任关系）；
是危害最大的攻击面。

② 攻陷 IoT 设备：

通过固件漏洞获得未授权访问或控制权；
供应链攻击：出厂时预植入恶意硬件/软件；
通过恶意固件更新分发 malware；
被攻陷设备若持有有效 VC + witness，可冒充合法设备。

③ 攻陷通信链路：

IoT 网络不强制要求加密，易被窃听；
攻击者可截获 VC，以受害设备的身份欺骗其他设备建立信任（身份伪造）。

4. EVOKE 协议详解

4.1 核心数据结构与函数

成员证明：当使用撤销列表时，必须相互验证的两个设备$d_i$和$d_k$呈现它们的VC并验证接收到的VC是否包含在列表中。同样，要使用$j$撤销VC，$d_i$需要提供名为Witness $w_i$ 的成员身份证明。通过这种方式，接收器应用验证功能，允许其声明VC是否已包含在j中。

累加器值 $a_j$：所有有效 VC 哈希值（SHA-256）的 ECC 椭圆曲线聚合，大小恒定（与 VC 数量无关）。

Witness $w_i$：证明 $\text{vc}_i$ 被包含于 $a_j$ 的成员证明，通过累加除 $\text{vc}_i$ 外所有其他有效 VC 得到，大小同样恒定。

七个核心函数：

$$Setup(K) → a_{info}$$

输入椭圆曲线的公开随机生成元集合 $K$，输出累加器参数 $a_{info}$。

$$ ComputeAccumulator(a_{info}, V) → a_j $$

将有效 VC 集合 $V$ 中每个 VC 映射到椭圆曲线上并聚合，得到累加器值。签发新 VC 或 VC 被撤销后重新执行。

$$RemoveFromAccumulator(a_{info}, a_j^{t-1}, V) → a_j^t$$

从已有累加器值中批量移除一组无效 VC $V$。

$$ComputeWitness(a_j, vc_i) → w_i$$

为单个有效 VC 生成成员证明 $witness$，支持批量生成。

$$Verify(a_j, vc_i, w_i, pk_i) → {0, 1}$$

$d_i$ 用私钥 $\text{sk}_i$ 对 $\text{vc}_i$ 签名后发送给验证方；
验证方同时检查：(1) $w_i$ 确实被包含于 $a_j$（撤销状态）；(2) $\text{vc}_i$ 与 $d_i$ 的对应关系（通过 $pk_i$ 验证所有权）。

$$UpdateAccumulator(a_{info}, a_j^{t-1}, V) → a_j^t$$

先调用 RemoveFromAccumulator() 移除无效 VC；若有新签发 VC，再调用 ComputeAccumulator() 加入；得到最新版本 $a_j^t$。

$$UpdateWitness(a_j^t, vc_i) → w_i^t$$

$a_j$ 更新后，旧 $W_j^{t-1}$ 全部失效，需为每个仍有效的 VC 重新计算 witness。

4.2 协议三大阶段

Phase 1：Setup（初始化）

Issuer i_j 执行：
  ainfo ← Setup(K)
  a_j ← ComputeAccumulator(ainfo, V)
      // 每个 vc 先做 SHA-256，再映射到椭圆曲线上
  for each vc_i ∈ V:
    w_i ← ComputeWitness(a_j, vc_i)   // 批量生成
  将 a_j 和 W_j 封装进 Issuer 签名的 VC → 发布到 DLT b

每台设备 d_i 初始获得：
  vc_i（有效凭证）+ a_j（当前累加器值）+ w_i（自身 witness）
  + Issuer 公钥 pk_{i_j}（用于验证更新来源）

Phase 2：Authentication（设备间互信认证）

d_i 发起与 d_k 的认证：

[Step 1] 时间戳同步
  d_i → d_k: timestamp(a_j^i)
  d_k 比对本地 timestamp(a_j^k)：
    ├─ 相同 → 版本一致，继续下一步
    └─ 不同 → 较旧方先执行 Update（见 Phase 3）

[Step 2] 互换凭证与证明
  d_i → d_k: Sign_{sk_i}(vc_i)  +  w_i
  d_k → d_i: Sign_{sk_k}(vc_k)  +  w_k

[Step 3] 双向本地验证
  d_k 执行: Verify(a_j, vc_i, w_i, pk_i)
    ① 验证 vc_i 由 i_j 签发（检查 Issuer 签名）
    ② 哈希 vc_i，调用 ECC 累加器验证其在 a_j 中（成员证明）
  d_i 执行: Verify(a_j, vc_k, w_k, pk_k)   // 完全对称

[Step 4] 建立信任
  双方验证通过 → 建立安全可信通信通道
  （敏感数据可用接收方公钥加密传输）

关键设计特性：认证完全本地化，无需实时联系 Issuer；验证同时检查撤销状态与所有权。

Phase 3：Update（撤销与更新）

Issuer 侧撤销流程（参见论文 Figure 3）：

当设备被标记为"已攻陷"或"故障"，需撤销 $V_{revoked}$ 时：

$$a_j^t ← UpdateAccumulator(a_{info}, a_j^{t-1}, V_{revoked)}$$

$$ W_j^t ← { UpdateWitness(a_j^t, vc_i) | vc_i ∈ V_{valid} }$$$$ 将 a_j^t + W_j^t 封装进 Issuer 签名的 VC → 发布到 DLT b$$

设备侧更新：已连网设备通过 pub/sub 订阅 DLT，收到新 VC 后验证 Issuer 签名，更新本地 $a_j$ 和 $w_i$。

离线更新（Offline Revocation）——EVOKE 核心创新：

设备 $d_k$ 离线错过更新时，由邻近的已更新设备 $d_i$ 协助：

Algorithm 1: HandleUpdates（简化伪代码）

for each d_i ∈ D_j:
  d_i 与 d_k 交互（i ≠ k）:

  case: a_j^i 比 a_j^k 旧（d_i 落后）:
    a_j^i ← a_j^k
    if d_i 支持 Direct Retrieval:
      w_i ← 直接从 DLT b 拉取
    elif d_k 支持 Direct Retrieval:
      w_i ← d_k 代为从 DLT 获取后转发（Indirect Retrieval）
    else:
      d_i 禁用信任通信，等待下一次交互

  case: a_j^k 比 a_j^i 旧（d_k 落后）:
    // 对称操作，更新 d_k
    ...

Direct vs Indirect Retrieval：

Direct Retrieval：设备有足够网络能力，直接访问 DLT 拉取最新 witness；
Indirect Retrieval：通过邻近的"中继设备"代为从 DLT 获取 witness 并转发；
更新信息封装在 Issuer 签名的 VC 中，确保即使通过设备中继也可验证真实性。

两种版本不一致场景的处理：

场景 A：双方版本相同但均已过期：

无法相互检测到遗漏的更新，可能发生误认证；
缓解：一旦遇到持有更新版本的第三台设备立即校正；实验证明多数设备在 1 小时内更新，风险时间有限。

场景 B：双方版本不同（Mismatching）：

较旧方（如 $d_k$）：
- 支持 Direct Retrieval → 直接从 DLT 拉取 $w_k$，据此确认最新 $a_j$ 版本并更新；
- 需 Indirect Retrieval → $d_i$ 代取 $w_k$ 并转发，$d_i$ 同步也更新自身；
- 双方均无网络能力 → 暂停信任通信，等待下次交互迭代；
该流程保证了累加器值与 witness 的一致性同步。

4.3 两大特性的形式化定义

定义 1（Mass Revocation，批量撤销）：批量撤销是指高效撤销大量 VC 而不影响 Issuer 和设备开销的能力。支持批量撤销的协议须保证：管理 VC 的底层数据结构的内存大小以及验证时间不受已撤销 VC 数量的影响。

定义 2（Offline Revocation，离线撤销）：离线撤销是指设备在断开网络连接时仍能接收并应用撤销更新的能力，且不加重网络资源负担。支持离线撤销的协议须最小化促成此类更新所需的数据传输开销。

5. 安全分析

5.1 Issuer 侧安全

攻击面 1：外部直接访问 $a_j$

防护：Issuer 部署在限制外部直接通信的安全环境；$a_j$ 仅通过 DLT 公开；攻击者无法从外部直接干预累加器计算。

攻击面 2：获取 $a_{info}$（累加器参数）

防护：$\text{ainfo}$ 本身是公开参数，不赋予任何签名能力；攻击者即使获得 $a_{info}$ 也无法伪造有效的 $a_j$ 或 $W_j$——因为需要 Issuer 的 DID 密钥对才能签名包含这些值的 VC。

攻击面 3：Issuer 密钥对泄露

防护：立即将 Issuer 迁移至新服务器，赋予新 DID 和密钥对；被攻陷期间签发的所有 VC 撤销；所有设备更新信任的 Issuer 公钥。

5.2 IoT 设备侧安全

核心防护逻辑：

设备被攻陷后，Issuer 将其 VC 从 $a_j$ 中移除（撤销）；
被撤销设备无法获得新的有效 $w_i$（其 VC 不在 $a_j$ 中，Verify() 返回 0）；
即便攻击者持有该设备旧版本的 $w_i^{t-1}$，也无法通过基于最新 $a_j^t$ 的验证；
注意：EVOKE 本身不负责检测被攻陷设备，这依赖于外部 IDS 方案。

5.3 通信侧安全

威胁 1：选择性 VC 转发（Selective Forwarding）

攻击者刻意不向过期设备转发最新 $a_j$，使其继续信任已撤销设备。

防护层次：

设备只接受时间戳比当前更新的 $a_j$，攻击者无法提供"比正版更新"的假版本；
被撤销设备可能提供一个"不含其被撤销 VC 但比目标设备版本新"的 $a_j$——若目标设备支持 Direct Retrieval，可在拉取 witness 时发现版本不一致（本地 $a_j$ 与 DLT 返回的 witness 对应版本不符）；
即使短暂被欺骗，风险时间有限——实验证明多数设备在 1 小时内完成更新；
此局限性与 CRL 相同（CRL 同样无法保证实时撤销新鲜度）。

威胁 2：VC 窃取伪装（VC Theft & Masquerading）

攻击者截获 $\text{vc}_i + w_i$，尝试冒充 $d_i$。

防护：Verify() 函数同时验证 VC 所有权——需要用 $d_i$ 的私钥 $\text{sk}_i$ 对 VC 签名，攻击者不持有私钥，无法通过此步验证。

6. 实现与评估

6.1 实现细节

技术栈选型：

组件	选用技术	原因
实现语言	JavaScript + WebAssembly（WASM）	跨设备兼容，浏览器即可运行
密码学原语	crypto-wasm-ts（docknetwork）	WASM 实现，高性能密码学操作
DID/VC 管理	identity-wasm/web（IOTA 基金会）	标准 DID/VC 创建、管理、验证
DLT	IOTA Tangle（DAG-based）	专为 IoT 设计，低延迟低能耗

所有结果取 1000 次运行平均值；
代码开源：https://github.com/evokevc/EVOKE

设备兼容性方案：厂商通常限制用户在设备上直接运行代码。解决方案：Python Web 服务器向设备提供含内嵌 JavaScript/WASM 的 HTML 页面，设备在浏览器端执行 EVOKE 操作。这意味着：若厂商原生集成 EVOKE，性能可进一步大幅提升。

6.2 消费级 IoT 设备测试

测试设备规格（论文 Table 2）：

设备	类型	处理器	内存	OS
LG Smart TV	智能电视	LG Quad Core	1.5 GB	WebOS
Amazon Echo Show 5	智能音箱	MediaTek MT8163	1 GB	Linux
Apple iPhone 12	智能手机	Apple A14 Bionic	4 GB	iOS 16
Oculus Quest 2	VR 头显	Qualcomm Snapdragon XR2	6 GB	Oculus OS

验证时延（论文 Table 3，1000次平均）：

操作	LG Smart TV	Amazon Echo Show 5	Apple iPhone 12	Oculus Quest 2
验证有效 VC	477.44 ms	499.70 ms	12.62 ms	48.69 ms
验证已撤销 VC	476.89 ms	498.67 ms	12.58 ms	47.89 ms

关键观察：

所有设备均在 500 ms 以内完成验证，对 IoT 交互场景完全可接受；
有效 VC 与已撤销 VC 的验证时延几乎相同（体现 ECC 累加器的常量验证时间特性——撤销不增加验证成本）；
每台设备的存储开销约 1.5 KB（$a_j$ + $w_i$），且该值与网络中 VC 总数无关；
iPhone 12 性能最优（~13 ms），LG TV 和 Echo Show 较慢，主要受限于 WASM 执行效率（原生实现可显著优化）。

6.3 混合网络测试

测试场景：智能家居，模拟 Zigbee / Z-Wave 典型 IoT 协议的网络拓扑。

硬件配置：5 台 Raspberry Pi 4（8GB RAM），同一 Wi-Fi 网络，使用 NTP 同步时钟。

两种拓扑（论文 Figure 4）：

星形拓扑（Star Network，Figure 4a）：

所有通信经过中心 Hub（如 Amazon Alexa / Google Home）；
特点：管理简单，但可扩展性和容错性受限于中心节点；
IoT 代表场景：智能家居中控。

网格拓扑（Mesh Network，Figure 4b，Full-mesh）：

每台设备可直接与所有其他设备通信（完全连通）；
特点：多路径鲁棒性强，动态适应性好，但管理复杂度随设备数增加；
IoT 代表场景：工业 IoT、楼宇自动化。

性能结果（论文 Table 4）：

拓扑	方案	Total Latency（Verify + Transfer）	E2E Latency
星形	EVOKE	1152.7 ms	948.3 ms
星形	Baseline（仅最小数据）	967.7 ms	705.5 ms
网格	EVOKE	545.2 ms	307.5 ms
网格	Baseline	97.4 ms	91.7 ms

分析：

星形延迟约为网格的 2 倍以上：星形需经中心节点中转，交互设备数更多；
NTP 时钟同步延迟是总延迟的主要贡献者，而非 EVOKE 自身计算；
EVOKE 的 VC 验证计算额外引入仅几毫秒开销，其余差异来自撤销信息的数据传输；
EVOKE 与 Baseline 的差距（传输 $a_j$ + $w_i$）远小于 CRL 等方案（CRL 数据量约为 EVOKE 的 100 倍）；
混合架构优势：通过 Raspberry Pi 作控制器，可为没有计算能力的微型传感器代理执行 EVOKE 操作，显著扩展适用范围。

6.4 大规模仿真

仿真配置：

参数	值
设备规模	10K / 50K / 500K / 1M
仿真时长	一周
硬件	Intel i7-11370H @ 3.30GHz，4核，16GB RAM
撤销比例	~0.028%/天（约 10%/年，参考 Heartbleed 对 PKI 的影响）
错过更新比例	10% / 30% / 50%
交互频率（主实验）	5 次/设备/小时
交互频率（附录对比）	1 次/设备/小时

1 小时内更新完成率（论文 Figure 5，5次/小时）：

错过更新比例	1小时更新率	备注
10%	~100%	完全收敛
30%	~98%	极少数未更新
50%	~96%	即使半数离线仍高效更新

重要发现：更新完成率与设备总数基本无关（10K 和 1M 的曲线几乎重叠），体现了 EVOKE 出色的可扩展性。

通信开销（论文 Table 5，5次/小时）：

设备总数	10% 错过	30% 错过	50% 错过
10K	1.49 MB	4.42 MB	7.19 MB
50K	7.45 MB	22.03 MB	36.05 MB
500K	74.51 MB	220.44 MB	360.70 MB
1M	155.43 MB	452.13 MB	721.67 MB

Issuer 侧开销（论文 Figure 6，对数坐标，1M 设备）：

操作	耗时（1M 设备）	说明
累加器值生成（初始）	~1 s	一次性
Witness 批量生成	~80 s	主要瓶颈，理论下界 $\Omega(w)$
累加器更新（撤销 10%）	~40 s	撤销越多，剩余 witness 越少，反而更快
累加器更新（撤销 25%）	~20 s
累加器更新（撤销 50%）	~10 s	批量撤销反而最快

关键解读：

Witness 批量生成是 Issuer 侧的唯一瓶颈，但 Issuer 通常具备充足算力，80 秒可接受；
撤销比例越高，更新耗时越短：因为被撤销设备不再需要 witness，需生成的总数减少；
设备侧的存储（1.5 KB）和验证时延（毫秒级）完全不受 Issuer 侧开销影响。

7. 与现有方案的详细对比

7.1 OCSP 系列

标准 OCSP：验证方在线查询 Issuer；假设稳定连接；每次约 4 KB；不适合 IoT。

OCSP Stapling：持有方定期预取 OCSP 响应并附在 VC 上；无需验证方联系 Issuer；但响应有时效，不保证实时撤销新鲜度，且 4 KB 仍超过 EVOKE。

TinyOCSP（JISA 2023）：将 OCSP 响应大小减小约 70%（至约 1.2 KB）；但仍需可靠连接，IoT 环境难以保证；不支持批量或离线撤销。

7.2 CRL 系列

标准 CRL：完整列表存储在设备上；百万证书场景需数 MB；对 IoT 完全不可行。

Revocation List 2020（W3C draft）：

位串（bitstring）方案：每个 VC 对应一位（1=撤销，0=有效）；
100 万 VC → 约 125 KB；
ZLIB 压缩后约 62.5 KB（假设 50% 压缩率）；
即使压缩后仍是 EVOKE 的 40 倍以上；
不支持批量撤销（bitstring 大小随撤销数线性增长）；
不支持离线撤销。

CRLite（IEEE S&P 2017）：约 112.5 KB，针对 Web PKI 优化，IoT 不适用。

Let’s Revoke（NDSS 2020）：约 70 KB，同上。

7.3 V’CER（USENIX Security 2022）

V’CER 是面向受限网络的高效证书验证方案，采用 Sparse Merkle Tree（SMT）：

将所有有效证书哈希值串联，生成 hash root（类似 $a_j$）；
Co-path（witness）= 路径上所有兄弟节点的哈希 = O(log n) 大小；
100 万证书场景：约 3 KB（EVOKE 的 2 倍）；
支持离线撤销：设备可分布式自行修复 proof（无需 CA 参与）；
不支持批量撤销（SMT 的 proof 大小随撤销数对数增长）。

EVOKE vs V’CER 全面对比：

维度	EVOKE	V’CER
基础结构	ECC 累加器	Sparse Merkle Tree
Witness 大小	O(1)（常量~1.5 KB）	O(log n)（~3 KB @ 1M）
存储效率	最优	次优（EVOKE 的 2 倍）
批量撤销	✓	✗
离线撤销	✓	✓
离线更新机制	邻居设备中继（含 Issuer 签名 VC）	设备间自行修复 proof
DLT 依赖	是（IOTA Tangle）	否（独立）

7.4 综合对比表

方案	存储（1M VC）	批量撤销	离线撤销
EVOKE	1.5 KB	✓	✓
V’CER	3 KB	✗	✓
Revocation List 2020	125 KB	✗	✗
CRLite	112.5 KB	✗	✗
Let’s Revoke	70 KB	✗	✗
TinyOCSP	需实时连接	✗	✗

8. 相关工作梳理

8.1 传统VC 撤销方案

- Abraham 等人的方案 [2]：通过在撤销列表中包含 VC 来实现。为了支持离线验证，节点可以生成“新鲜度证明（Attestations）”，让验证方确认凭证当前是否有效。
Fotiu 等人的方案 [18] (基于 W3C 草案)：采用位图（Bitstring）机制。给每个 VC 分配一个位置下标，如果对应位置是 1 则代表已撤销。这种方式简单，但只适合 VC 数量较少的场景。
DNS 方案 [19]：将撤销列表存放在 DNS 的 TXT 记录中。这种方案局限于群组设备管理，不适合非集群化的通用 IoT 场景。

8.2 基于累加器的方案

Parameswarath 等人的方案 [39]：虽然使用了累加器，但侧重于用户权限/策略的撤销，而非针对受限网络环境的效率优化。
V’CER [27]：使用稀疏默克尔树（SMT）** 作为哈希累加器。它在存储效率上表现优异（100 万个证书仅需不到 3KB 空间），且支持离线更新。

8.3 基于 DLT 的方案

传统区块链方案 [16, 28, 44, 59]：虽然能存撤销信息，但存在延迟高、能耗大、吞吐量低的问题，不适合资源受限的 IoT 设备。
DAG（有向无环图）方案 [49, 57]：作为区块链的替代方案，DAG（如 IOTA）更轻量，能在保持安全性的同时满足 IoT 网络的特定需求。

8.4 EVOKE 的差异化定位

EVOKE 是现有所有方案中第一个同时满足以下四点的方案：

专为 VC（而非 PKI 证书）设计；
专为 IoT 受限环境裁剪；
支持批量撤销；
支持离线撤销，且存储开销最小（1.5 KB）。

9. 总结

极低存储开销：比 V’CER 更强，每个设备仅需 1.5KB 即可处理百万级 VC（V’CER 需要 3KB）。
空间恒定性：无论撤销多少个 VC，累加器和证明（Witness）的大小固定不变，不会随数量增加而膨胀。
支持批量撤销：这是传统方案（如 SMT）难以高效实现的，EVOKE 可以在保持小体积的同时处理大规模撤销。
离线能力：继承并优化了离线验证功能，专门为断网或弱网的 IoT 环境设计。

1. 核心定位与价值

填补空白：指出 VC（可验证凭证）虽然能增强 IoT 设备的信任，但“如何高效撤销”仍处于早期研究阶段。EVOKE 为该领域奠定了基础。
技术核心：明确了 EVOKE 是利用 ECC（椭圆曲线密码学）累加器来解决 IoT 网络中计算和存储资源极度受限的问题。

2. 三大核心特性

高效管理：极低的计算和存储开销。
批量撤销 (Mass Revocation)：能够大规模处理凭证废止。
离线撤销 (Offline Revocation)：在没有持续网络连接的情况下依然有效，解决了 IoT 的痛点。
Witness 生成瓶颈：Issuer 侧生成 1M witness 约需 80 秒，高频撤销场景下有优化空间（可研究增量更新算法）；
非最优实现：当前 JS/WASM 实现非最优，原生实现（C/Rust）可大幅降低设备侧延迟；
设备检测依赖外部：被攻陷设备的检测完全依赖 IDS，EVOKE 自身不提供检测能力；
低交互频率场景：1次/小时且 50% 离线时更新率降至 75%，需研究主动推送补充机制；
DAG-DLT 中心化风险：早期 IOTA Tangle 对协调器（Coordinator）有依赖，IOTA 2.0 正在解决该问题，EVOKE 可考虑支持其他 DAG-DLT。

10.个人疑点

为什么说选用 DAG 而非传统区块链的原因：更低延迟、更低能耗，同时保持透明性与不可篡改性；（如何说明DAG更优）
3.3威胁模型为什么要采用 Dolev-Yao 模型——攻击者可窃听、拦截、注入任意数量消息，并可尝试攻陷 $n_j$ 中的任意实体。

1. 研究背景与动机#

1.1 IoT 信任问题#

1.2 VC 撤销的特殊挑战#

1.3 现有方案的不足#

2. 背景知识#

2.1 去中心化标识符（DID）#

2.2 可验证凭证（VC）与可验证展示（VP）#

2.3 密码学累加器#

3. 系统模型与威胁模型#

3.1 系统模型#

3.2 各组件详解#

3.3 威胁模型#

4. EVOKE 协议详解#

4.1 核心数据结构与函数#

4.2 协议三大阶段#

Phase 1：Setup（初始化）#

Phase 2：Authentication（设备间互信认证）#

Phase 3：Update（撤销与更新）#

4.3 两大特性的形式化定义#

5. 安全分析#

5.1 Issuer 侧安全#

5.2 IoT 设备侧安全#

5.3 通信侧安全#

6. 实现与评估#

6.1 实现细节#

6.2 消费级 IoT 设备测试#

6.3 混合网络测试#

6.4 大规模仿真#

7. 与现有方案的详细对比#

7.1 OCSP 系列#

7.2 CRL 系列#

7.3 V’CER（USENIX Security 2022）#

7.4 综合对比表#

8. 相关工作梳理#

8.1 传统VC 撤销方案#

8.2 基于累加器的方案#

8.3 基于 DLT 的方案#

8.4 EVOKE 的差异化定位#

9. 总结#

1. 核心定位与价值#

2. 三大核心特性#

10.个人疑点#