一种利用零知识证明和区块链技术保护隐私的紧急车辆认证方案 李瀚仕（Hanshi Li）、 奥扎·德里斯蒂（Drishti Oza）、 吉田雅巳（Masami Yoshida） 以及野口達（Taku Noguchi）

《IoT》：Privacy-Preserving Emergency Vehicle Authentication Scheme Using Zero-Knowledge Proofs and Blockchain Hanshi Li, Drishti Oza, Masami Yoshida and Taku Noguchi

　　摘要 在车辆自组织网络中，紧急车辆的认证必须满足严格的延迟、隐私和信任约束。现有的基于公钥基础设施（PKI）和有条件隐私保护认证的方案由于证书管理和昂贵的逐跳验证而产生大量开销，因此不适合实时紧急场景。我们提出了一种轻量级的零知识（ZKP）和区块链辅助的认证方案，该方案消除了证书、匿名池以及在认证阶段与可信机构进行在线交互的需求。证书颁发机构（CA）仅在离线初始化阶段（车辆注册和Merkle树构建）参与；一旦配置完成，运行时认证过程无需任何在线CA交互。每辆紧急车辆在证明属于特定类别的Merkle树后，会在区块链上注册一次性哈希承诺，并通过广播哈希和零知识证明来验证消息的真实性。路边单元验证证明并查询区块链状态以执行一次性使用语义，从而创建防篡改的审计跟踪。使用Veins框架（OMNeT++/SUMO）进行的评估显示，认证后的有效载荷大小恒定为288字节，端到端延迟在毫秒级别，且不随跳数增加而变化，并且区块链处理在持续负载下保持稳定。

1. 引言
车辆自组织网络（VANET）使车辆与路边基础设施之间能够进行实时通信，适用于安全关键应用。在紧急情况下，警车、救护车和消防车必须立即获得道路优先权，这要求周围车辆和路边单元（RSUs）在几毫秒内验证优先消息是否真正来自授权的紧急车辆。现有的认证机制仍然不足。基于证书的公钥基础设施（PKI）方案由于证书吊销列表（CRL）分发而产生 heavy 开销，并可能暴露车辆身份[1]；有条件隐私保护认证（CPPA）和群签名方案依赖于双线性配对，这通常超出紧急使用的延迟限制[2,3]。区块链作为一种有前途的补充方案出现，因为它具有不可变更性和去中心化的信任[4]，然而现有的基于区块链的VANET方案要么在区块链上记录明确的标识符[5]，要么依赖于昂贵的在线验证零知识简洁非交互式知识论证（zk-SNARKs）[6,7]，或者无法同时提供细粒度的授权和强隐私保护[8]。此外，大多数先前的研究没有考虑监管监督；因此，授权车辆可能会滥用紧急权限，这就需要防篡改的事后审计[6,8,9]。
为了解决这些问题，我们提出了一个轻量级、保护隐私的、基于区块链的紧急车辆广播认证框架。在离线初始化阶段，证书颁发机构（CA）构建特定类别的Merkle树（例如，警察、消防、救护车），并将其根节点记录在区块链上。车辆通过向智能合约提供Merkle包含证明来预先注册一次性哈希承诺，而不暴露标识符。一旦配置完成，就不再需要在线CA。在运行过程中，紧急车辆在证明属于某个特定类别的Merkle树后，在区块链上注册一次性哈希承诺，并通过广播哈希以及零知识证明来验证消息的真实性。路边单元验证证明并查询区块链状态以确保一次性使用的语义，从而创建防篡改的审计跟踪。使用Veins框架（OMNeT++/SUMO）进行的评估表明，认证后的有效载荷大小恒定为288字节，端到端延迟在毫秒级别，且不随跳数增加而变化，并且在持续负载下区块链处理保持稳定。

2. 相关工作
现有的VANET认证方案大致可以分为（i）基于PKI的；（ii）CPPA；（iii）基于群签名和匿名的；以及（iv）基于区块链的方法。我们在下面回顾了每一类并分析了其局限性。

2.1. 基于PKI的认证
在基于PKI的系统中，CA向车辆颁发数字证书，RSUs分发CRL。尽管已经探索了批量验证和优化的CRL策略[1]，但PKI方案从根本上受到CRL快速增长、高每条消息验证成本、证书与长期身份的关联性以及依赖于连续的CA/RSU连接性的限制。

2.2. 有条件隐私保护认证
CPPA方案在正常操作期间隐藏发送者的身份，同时在必要时允许授权机构揭示它。典型的实现使用了ECC、基于身份的签名或双线性配对[2,3,10]，尽管这些计算密集型原语会导致显著的每条消息验证开销。许多CPPA方法还需要在线RSU的参与，并且很少结合去中心化的审计能力，这限制了它们在延迟敏感的紧急场景中的适用性。

2.3. 群签名和匿名方法
群签名允许车辆代表一个群体进行签名，同时允许可信机构追踪不良行为[11]，但这会导致高签名/验证开销和复杂的撤销过程。基于匿名名的方法涉及预加载证书池的轮换以实现不可链接性，尽管它们会带来沉重的存储需求并使撤销过程复杂化[12]。这两种方法在高流动性紧急场景中都面临实际限制。

2.4. 基于区块链的认证
区块链技术被引入VANET认证系统，以增强去中心化、审计能力和抵抗单点故障的能力。最近的研究利用区块链以防篡改的方式存储车辆注册信息、证书状态或与声誉相关的数据[8,9,13]。然而，大多数设计主要管理身份或证书，并且缺乏细粒度的授权控制[4,8,9]。此外，许多方案依赖于区块链上的加密验证，这会产生不适合延迟敏感的车辆环境的大量开销[6,14,15]。尽管有几项研究探索了将区块链与零知识证明相结合[6,7,16]，但这些方法仍然对紧急车辆认证施加了不可忽视的计算成本。

2.5. 多跳通信
在VANET中，多跳转发是必不可少的，因为消息必须传播超过单跳范围。大多数现有的安全多跳协议依赖于端到端加密或明确的信任假设，需要中间节点参与加密操作，如密钥协商或签名验证。这些要求引入了密钥管理开销和处理延迟，随着跳数的增加而迅速增加，导致紧急消息的延迟无法接受。很少有方案能够实现真正的无信任多跳转发，即中间车辆仅转发消息而不进行任何加密操作[9]，更少的方案将这些操作与去中心化的审计能力或轻量级零知识证明（ZKP）认证相结合。

2.6. 总结
表1将代表性方案与所提出的方法进行了比较，考虑了关键的安全性和系统属性。如表1所示，没有现有的方案同时实现了以下所有特性：无需配对的验证、消除在线可信机构交互、无信任多跳转发、区块链支持的审计能力和撤销支持。这种差距激发了我们提出的框架的设计，该框架正是针对这些特性的组合。

3. 系统模型
所提出的系统模型涉及五种类型的实体：紧急车辆、普通车辆、RSUs、CA和区块链网络。
紧急车辆（例如，警车、消防车、救护车）具有优先广播消息的权利。它们作为经过认证的消息发送者，广播触发普通驾驶员特殊行为的紧急信号。
普通车辆接收并相应地调整驾驶行为以响应紧急消息。它们还可以验证附带的零知识证明，并查询区块链中存储的哈希承诺状态，以独立确认消息的合法性。在多跳转发模型中，普通车辆作为中继节点重新广播接收到的紧急数据包。这种中继行为与标准的VANET洪水协议（例如，基于IEEE 802.11p的广播）一致，其中车辆作为通信协议的一部分协作转发安全关键消息，而不需要明确的激励机制。
RSUs作为本地权威节点和通往区块链的网关。它们通过检查零知识证明并查询区块链来验证紧急消息，确保哈希承诺未被之前使用，然后在区块链上记录验证结果以用于审计目的。
CA是一个可信的机构，通过分配数字身份和授权类别来注册车辆。对于每个类别，CA构建一个专门的Merkle证明树，其叶子节点对应于已注册的车辆。CA定期将特定类别的Merkle根节点发布到区块链上。
区块链网络存储了必要的认证数据：Merkle根节点、带有使用状态的有一次性哈希承诺以及验证事件日志。其不可变的性质确保了授权数据的防篡改性和审计跟踪能力。图1展示了所提出方案中这些实体之间的整体交互。

3.1. 威胁模型和假设
我们考虑了三种类型的对手：
外部攻击者可以窃听无线通信，并可能尝试通过伪造或重放消息来冒充紧急车辆，但他们缺乏有效的加密凭证。
不可信任的中继车辆可能出于好奇或恶意行为，可能会丢弃消息、注入虚假数据或篡改传输中的内容。我们的方案必须确保中间车辆不能破坏消息的真实性。
行为不端的紧急车辆即使持有有效凭证也可能广播虚假的紧急信号。系统应该通过事后责任机制来阻止和检测这种滥用。
我们假设（1）区块链共识是安全的，具有诚实的多数派；（2）CA是完全可信的；（3）哈希函数具有抗碰撞性和抗原像性；（4）ZKP系统是健全的且基于零知识的；（5）车辆保持私钥的机密性。

3.2. 设计目标
基于威胁模型，我们的方案旨在实现以下目标：
G1：轻量级认证。低通信和计算开销，使得在资源受限的车辆平台上可以进行实时验证。
G2：隐私保护。车辆证明其授权权限而不暴露其身份；消息中不嵌入任何可识别个人信息。
G3：基于类别的授权。只有相应类别的车辆才能发送特权消息；普通车辆不能伪装成紧急车辆。
G4：去中心化的审计能力。基于不可变区块链的审计跟踪，可以在没有集中日志记录的情况下事后检测违规行为。
G5：无信任的多跳转发。即使由没有加密钥匙的不可信任中间节点转发，消息的真实性也能得到保证。
G6：可扩展性。随着车辆数量和广播频率的增长，系统性能仍然实用，验证时间为毫秒级别，证明大小小。

4. 提出的认证方案
4.1. 基于Merkle树的类别授权
为了实施基于类别的授权（G3），CA为每个车辆类别维护一个单独的Merkle树（例如，警察、消防、救护车）。每个叶子节点代表该类别中的一个已注册车辆。CA定期将特定类别的Merkle根节点发布到区块链上。
在将哈希承诺注册到区块链之前，车辆必须提供Merkle证明来证明其类别成员身份。智能合约根据存储的根节点验证此证明，并仅接受来自授权车辆的承诺。这种机制控制上传权限，同时不在区块链上暴露车辆身份，区块链仅存储“授权车辆”上传了哈希的证据。

4.2. 注册和哈希提供
每辆车在参与认证之前都要进行注册和配置。
初始注册：CA为每辆车分配一个数字身份（公钥/私钥对），并在相应的类别Merkle树中放置一个条目。车辆收到Merkle成员证明以供后续授权使用。
哈希提供：车辆生成秘密值并计算哈希承诺。每个秘密值通过调用合同的注册函数以及Merkle证明一起注册到区块链上。合同验证证明并将这些承诺记录为已授权的未使用承诺。这建立了一个用于未来认证的一次性令牌池。为了防止池子耗尽，车辆监控其剩余的承诺数量，并在池子低于可配置的阈值（例如，初始池大小的20%）时启动补充。补充通过最近的RSU进行：车辆生成新的秘密值批次，计算相应的哈希承诺，并使用相同的基于Merkle证明的程序将它们注册到区块链上。每次承诺的注册成本包括一次Merkle证明验证和一次区块链状态写操作，在一个区块周期内完成（在PoA配置中为1秒）。对于典型的100个承诺的池子大小，以每分钟一条认证消息的持续速率广播的紧急车辆大约在1.5小时内耗尽其池子；在20%的阈值下主动补充可以确保池子在耗尽之前得到充分更新。如果哈希池在补充之前被完全消耗，那么车辆将暂时无法广播经过身份验证的紧急消息，直到新的哈希承诺被注册；通过适当的阈值配置可以避免这种情况。4.3. 消息生成和零知识证明（ZKP）生成在广播紧急警报时，车辆从其哈希池中检索一个未使用的哈希承诺h。相应的秘密r作为生成真实性证明的基础。车辆构建一条包含紧急指令、位置和时间戳的消息M，但不包含任何身份信息。然后生成一个零知识证明，证明：“我知道一个秘密r，使得……”，其中h是一个经过授权的承诺。该证明不会透露关于r或车辆身份的任何信息。使用轻量级的哈希原像电路，证明的生成和验证都在几毫秒内完成（G1级别）。最终的广播数据包就是这样的。4.4. 广播和无需信任的多跳转发该数据包通过车载网络（VANET）进行广播。接收者通过以下方式验证：（1）检查ZKP是否与h匹配，无效的证明将导致消息被拒绝；（2）查询区块链以确认h已被注册且未使用，否则消息将被视为未经授权或重复发送。该方案支持无需信任的多跳转发：任何接收到有效数据包的车辆都可以中继发送，而无需被信任或预先授权。因为数据包自带证明，中继节点无法伪造或篡改消息而未被检测到，并且不需要执行任何加密操作。由于转发而增加的延迟仅是物理传播延迟（G5级别）。4.5. 路侧单元（RSU）验证和区块链执行当RSU接收到紧急消息时，它执行验证并更新区块链：验证：检查h是否存在于链上并且未被使用。状态更新：如果有效，将h标记为已使用（USED），以防止重复发送，并将验证事件连同时间戳和类别一起记录下来。异常处理：无效的证明或未经授权的哈希将被拒绝，并可选地记录下来以供审计。通过在链上记录验证结果，系统创建了一个抗篡改的审计跟踪，平衡了隐私和问责性（G4级别）。需要明确的是，实时身份验证和基于区块链的审计之间的区别，因为它们在根本不同的时间尺度上运行。RSU的身份验证决策（接受或拒绝紧急消息）完全基于本地的ZKP验证，该验证在几毫秒内完成，不依赖于区块链的确认。区块链的状态更新将h标记为已使用是一个异步操作，具有两个目的：（1）防止同一承诺的重复发送；（2）为事后监管审查创建一个抗篡改的审计跟踪。由于身份验证决策是本地的，紧急消息的处理永远不会因区块链的延迟而延迟。在极少数情况下，两个地理位置相远的RSU几乎同时接收到相同的哈希h，两者都可能在本地接受消息；然而，只有第一个在链上的状态变更才会成功，第二个交易将会失败，并在链上生成一个可审计的异常事件。在极端的网络或区块链拥堵情况下，审计日志的写入可能会延迟，但这不会影响实时身份验证决策。为了确保此类情况下的审计完整性，RSU维护一个本地的前置日志，记录待处理的区块链交易，并在连接恢复后批量提交，从而保持审计跟踪的完整性，而不影响身份验证的延迟。这种设计反映了一个故意的架构权衡：对于时间敏感的紧急情况，优先考虑毫秒级的本地身份验证，而区块链则提供了最终一致性和抗篡改的事后问责性。4.6. 撤销机制当车辆的授权需要被撤销时（例如，由于被盗、凭证泄露或权限取消），证书颁发机构（CA）从特定类别的Merkle树中移除相应的叶子节点，并向区块链发布一个更新的Merkle根节点。一旦新的根节点在链上被确认，被撤销的车辆就无法再注册新的哈希承诺，因为其Merkle成员身份证明相对于更新的根节点变得无效。对于已经注册在链上但仍未使用的哈希承诺，CA通过与该车辆地址相关的链上交易记录来识别这些承诺，并向智能合约发出一个撤销交易。合约将这些承诺标记为REVOKED状态，防止被撤销的车辆使用之前注册的承诺。这种三状态模型（UNUSED、USED、REVOKED）确保了撤销操作的即时性和可审计性。相同的Merkle树更新机制也支持动态的角色变更。当普通车辆暂时被分配紧急角色（例如，执行紧急任务的警车）时，CA将该车辆的叶子节点添加到相应的特定类别的Merkle树中，并在链上发布一个更新的根节点。然后车辆获得一个新的Merkle成员身份证明，并可以为该类别注册哈希承诺。一旦临时分配结束，CA会移除叶子节点并更新根节点，从而撤销临时权限。在整个过程中，隐私得到了保护，因为区块链只记录了授权车辆注册的承诺，而不会暴露车辆的身份。5. 实现5.1. 智能合约架构链上逻辑由两个部署在兼容以太坊的区块链上的Solidity合约组成：（i）由Circom（一种用于zk-SNARK电路的编程语言）/SnarkJS工具链自动生成的zk-SNARK验证合约；（ii）一个名为MerkleTreeWhitelist的应用程序合约，用于维护授权状态并执行哈希承诺的一次性使用。底层区块链使用Geth和CliqueProof-of-Authority（PoA）共识机制，以及1秒的区块周期，为低延迟的车辆应用提供了确定性的最终性。整体架构如图2所示，智能合约暴露了每个类别的映射（MAP1–MAPn）和一组Merkle根节点。图2. 智能合约架构，包括用于跟踪哈希使用状态的特定类别的链上哈希映射（MAP1–MAPn）。使用链上锚定的Merkle根节点来执行类别级别的写入授权，这些根节点是从CA维护的链下Merkle树派生出来的。在后续的图中，这四个功能分别用F1–F4表示。验证合约暴露了verifyProof函数，用于检查Groth16（一种广泛使用的zk-SNARK证明系统，具有固定大小的证明和高效的验证）证明，以验证关系（1），其中r是私有的原像（取消器），h是公开的哈希承诺。Poseidon是一种适用于zk-SNARK电路内高效计算的算术友好型哈希函数。验证密钥在部署时被硬编码。MerkleTreeWhitelist合约存储了CA发布的Merkle根节点merkleRoot和映射hasherMapping[h]，用于跟踪每个承诺是 UNUSED还是USED状态。它还发布了事件（VerificationResult, ReplayAttackAttempt等）以支持审计。两个核心功能是：uploadHasher(proof, hasher)：在车辆配置期间被调用。它验证Merkle证明与msg.sender是否匹配，然后将h的状态设置为USED。verifyAndUseHasher(a,b,c,input)：在RSU验证期间被调用。它检查h是否为UNUSED状态，验证Groth16证明，并原子性地将h的状态设置为USED，从而执行一次性使用的语义。实现的可用性：支持本研究发现的完整智能合约和客户端实现可以从作者处获得，只需提出合理请求即可。5.2. ZKP实现和工作流程5.2.1. ZKP电路和证明文件实现零知识组件使用了Circom 2.2.1和SnarkJS 0.7.5实现。核心电路HasherVerifier将原像r作为私有输入，承诺h作为公共输入，并通过IsZero+NOT（非零检查）、Num2Bits(252)（范围检查）和Poseidon(1)（哈希检查）来执行关系（1）。该电路被编译成R1CS格式，Groth16设置产生了相应的证明。车辆生成证明后，将其ABI编码以提交给Solidity验证器。哈希配置过程如算法2所示。算法2 哈希配置在链上要求：车辆具有Merkle证明确保：链上的条目在hasherMapping中1: 采样一个随机的原像；2: 计算叶子节点；3: 在本地验证该叶子节点是否与发布的根节点一致；4: 车辆在本地签名一个调用uploadHasher(, h)的交易，并将其发送给RSU，后者将其转发到区块链网络；5: 如果Merkle证明有效且h之前未被看到，则6: 合同将hasherMapping[h]设置为true（USED）。5.2.2. 车载单元（RSU）侧工作流程车辆端逻辑涵盖了三种主要场景：注册、命令传播和多跳传输。5.2.3. 场景1：车辆注册图3展示了第4节中描述的注册工作流程。当哈希池耗尽时，重复此过程以注册额外的承诺。5.2.4. 命令传播图4显示了命令传播过程。将命令发送到目标车辆；RSU验证后，将h标记为已使用，并广播一个签名的验证结果。5.2.5. 无需信任的多跳传输图5展示了多跳传输过程。ZKP-哈希对无论跳数多少都能保持自我认证；中间车辆仅转发数据包，不执行任何加密操作。5.2.6. RSU端验证工作流程算法3说明了RSU端的处理流程。算法3的链上部分由第5.1节中描述的verifyAndUseHasher函数实现。本文中的所有示意图（系统架构图和流程图）都是在Claude Opus 4.5（Anthropic，通过Claude Code）的帮助下制作的。作者审查、验证并手动完善了每个AI生成的图表，以确保准确性。5.3. RSU端验证和命令传播要求：从车辆接收的数据包确保：布尔决策；可选地，RSU签名的广播命令1: 解析P以提取h、证明和消息；2: 如果……，则返回false；3: 如果调用返回false，则返回false；4: 从消息中构建经过验证的紧急命令；5: 用RSU的ECDSA密钥签名并向范围内的车辆广播。6. 评估6.1. ZKP基准测试（100次运行测试）我们在MacBook Air（Apple M2，8 GB RAM）上对ZKP的计算成本进行了基准测试。电路使用Circom 2.2.1和SnarkJS 0.7.5以及Poseidon哈希实现。证明生成和验证各自重复了100次。图6显示证明生成时间始终保持在低毫秒范围内，且运行间的变化很小，确认计算成本稳定，适合资源受限的车辆平台。图7显示验证延迟始终低于生成延迟，并且在所有运行中保持在几毫秒范围内。总体而言，ZKP组件仅引入了轻微的、有界的处理延迟，并未成为时间敏感的VANET环境中的瓶颈。应该注意的是，上述基准测试是在普通笔记本电脑（Apple M2）上进行的，其计算性能明显高于典型的车载单元（OBUs）。这项实验的主要目的是确认ZKP操作的计算特性和所提出方案的可行性。关于Groth16证明系统的现有研究表明，在ARM Cortex-A类处理器（例如Raspberry Pi 4、NVIDIA Jetson Nano）上进行证明生成时，与桌面级硬件相比，通常会有大约5-10倍的延迟[17]。将此因素应用于在M2上观察到的毫秒级生成时间，表明在代表性的车辆嵌入式平台上进行证明生成仍然会在几十毫秒的范围内，这仍然在可接受的延迟范围内。证明验证在Groth16中本质上比生成更快，其时间仍保持在毫秒级别。尽管如此，直接在实际的电子控制单元（ECUs）或基于ARM的嵌入式平台上进行评估仍然是未来验证的重要课题。6.2. 区块链智能合约评估（800笔交易）我们在持续负载下评估了链上的verifyAndUseHasher函数（第5.1节）。区块链环境：我们使用Geth部署了一个私有的、兼容以太坊的区块链，该区块链采用Clique PoA共识机制，块周期为1秒。工作负载：我们依次消耗了800个预先注册的哈希承诺。每笔交易的时间从提交到确认进行了测量。这种延迟反映了区块链共识的开销，而不是实时认证的延迟：RSU在本地验证证明，并并行地在链上提交交易以记录审计日志。因此，端到端的紧急信息接收延迟主要由本地的ZKP验证决定，而区块链确认仅影响审计追踪。图8显示了每笔交易的处理时间过程。大多数交易在由1秒块周期决定的狭窄时间间隔内得到确认，没有观察到长期增长趋势，表明合约执行时间实际上是恒定的。图8. 在Geth PoA链上连续进行800笔RSU验证和消费交易的区块链处理时间过程（验证序列索引=交易顺序）。与ZKP基准测试类似，这次区块链评估是在受控条件下进行的初步可行性验证。800笔交易的序列工作负载表明，在这种规模下，每笔交易的合约执行时间保持稳定，并不会随着累积状态的增加而下降。为了提供一个初步的可扩展性估计，考虑一个城市规模的部署，其中有10,000辆紧急车辆，每辆车辆预先注册100个哈希承诺。由此产生的链上状态包含1,000,000个映射条目，每个条目存储一个32字节的哈希和一个1字节的状态标志，大约占用33MB的合约存储空间——完全在现代区块链节点的容量范围内。在交易吞吐量方面，1秒块周期的PoA链每块可以处理数百笔交易；即使所有10,000辆车同时消费一个承诺，积压也会在几分钟内清除，而且由于RSU在本地验证证明，实时认证也不会受到影响。将评估扩展到具有高并发多RSU部署的城市规模车辆密度，以及研究状态管理策略（如承诺修剪和第2层解决方案）被认为是未来工作的重要方向。气体成本分析为了量化链上验证的计算成本，我们在私有PoA链上连续进行了400笔交易的verifyAndUseHasher函数的气体消耗量测量。图9总结了结果。气体成本在所有交易中都保持高度一致，最小为32,709单位，最大为32,769单位，中位数为32,757单位，平均数为32,753.55单位。狭窄的范围（60个气体单位）证实了合约执行成本实际上是恒定的，并且与累积的链上状态无关。所有400笔交易都成功完成，成功率为100%。尽管私有PoA链不收取货币交易费用，但气体测量提供了一个与硬件无关的计算开销指标，如果该方案部署在公共或联盟区块链上，这个指标仍然适用。图9. 在Geth PoA链上连续进行400笔交易的verifyAndUseHasher智能合约函数的气体成本（使用的最小、平均、中位数和最大气体单位）。6.3. 车联网（VANET）模拟 6.3.1. 模拟设置我们将认证协议集成到了基于OMNeT++ + SUMO模拟器的Veins框架中，该模拟器使用了IEEE 802.11p通信协议。紧急车辆广播包含zk-SNARK证明和哈希承诺的288字节数字签名认证（hash commitment）消息。6.3.2. 真实紧急场景为了在真实交通条件下验证该方案，我们模拟了一个拥堵的高速公路场景，其中一辆救护车在六车道道路段上导航时广播了经过认证的紧急消息，该路段大约有100辆普通车辆。一个RSU执行ZKP验证和区块链状态更新。图10显示了此场景中使用的SUMO模拟地图。救护车（红色车辆）被密集排列的普通车辆（黄色显示）包围，模拟了在高车辆密度下紧急广播必须快速传播的真实交通拥堵情况。这种端到端的延迟包括无线通信效应（例如，信道竞争、排队和多跳转发）以及RSU的本地ZKP验证时间。图10. 模拟场景：一辆救护车在大约有100辆普通车辆的六车道道路上穿行。图11显示了每次验证事件的端到端认证延迟。所有事件的延迟都保持在几十毫秒范围内，证实即使在极端交通密度下，经过认证的紧急消息也可以快速处理。图11. 模拟场景中每次验证事件的端到端认证延迟。图12展示了RSU端的处理时间，始终保持在低毫秒范围内，表明RSU的计算负担较轻，没有主导整个端到端的延迟。图12. 模拟场景中的RSU处理时间（从消息接收完成验证和状态更新）。6.3.3. 多跳转发实验我们研究了使用具有0、1、2和3个中继跳数的线性拓扑结构时多跳转发如何影响端到端延迟。图13显示，由于信道访问延迟，延迟大致与跳数成线性增加。由于证明生成在源处进行一次，验证在RSU处进行一次，因此加密成本与跳数无关。图13. 0跳、1跳和2跳场景的合并端到端认证延迟。我们还评估了最多20跳的基于泛洪式的转发。图14显示，对于紧急应用来说，延迟是可以接受的。图15确认，在泛洪式多跳实验中，RSU的处理时间随着跳数的增加而适度增加，反映了RSU接收到的转发消息量增加。图14. 基于泛洪式的多跳实验中的端到端延迟。图15. 泛洪式多跳实验中的RSU处理时间。6.3.4. 与现有技术方案的比较我们将我们的方案的多跳延迟与Rabieh等人[18]描述的代表性每跳认证设计进行了比较。图16显示，基线方案由于每跳的加密操作导致延迟增加得更明显，而我们的方案增加得较慢，因为ZKP验证仅在RSU处进行一次，中间中继不会生成额外的加密操作。如表1中的定性比较所示，现有方案通常需要基于配对的验证、在线可信权威交互或每跳加密操作。相比之下，提出的方案实现了无需配对验证、无需在线TA要求以及无需信任的多跳转发的独特组合，同时保持了紧凑的288字节认证有效载荷大小。然而，由于采用了链上承诺模型，该方案没有实现低存储（S3）；但是，每次承诺的存储开销很小（单个哈希到状态映射条目）。图16. 与Rabieh [18]的多跳端到端延迟比较。7. 安全性分析我们在第3.1节提到的威胁模型下分析了安全属性，假设Poseidon哈希函数具有抗碰撞性和抗预图像性，zk-SNARK系统是完备的、正确的且零知识的。正确性：属性：遵循协议的授权车辆生成的消息会被诚实的验证器以极高的概率接受。论证：CA正确构建Merkle树并发布有效的根节点。每辆授权车辆接收一个有效的Merkle证明，并在链上注册哈希承诺。当车辆为已承诺的哈希生成ZKP时，见证者满足电路关系。由于zk-SNARK的完备性，验证器几乎必然会接受该证明。合约确认哈希存在且未被使用，然后将其标记为已消耗。不可伪造性：属性：对手无法使验证器接受非授权车辆发出的紧急消息，除非概率极低。论证：要伪造有效消息，对手必须生成h，使其被注册且未被使用，并且满足条件。没有有效的预图像，这需要破坏哈希抗预图像性或zk-SNARK的正确性。未经授权的哈希注册将失败Merkle成员检查。被破解的RSU无法伪造消息，因为所有哈希注册交易都由车辆的私钥签名。抗重放：属性：该方案对重放攻击是安全的。论证：每个哈希h是一次性使用的。成功验证后，合约会永久将h标记为已消耗。任何后续尝试重新使用h的行为，即使之前证明有效，也会被可用性检查拒绝。消息中的时间戳进一步使接收者能够丢弃过时的消息。可追溯性：属性：即使操作匿名，违规的紧急车辆也可以被授权机构追踪。论证：CA维护了车辆注册记录与Merkle叶子之间的机密映射。区块链记录了每个哈希的使用时间和地点。在合法授权下，调查人员可以通过链上日志识别问题哈希，并且CA可以将其对应的Merkle叶子与现实世界中的车辆关联起来。区块链的不可变性防止了否认。多跳鲁棒性：属性：即使在不可信的中间车辆存在的情况下，多跳转发也能保持安全保证。论证：正确性和不可伪造性仅依赖于最终验证器（RSU）的ZKP验证和哈希状态检查以及区块链的完整性。中间车辆不生成或验证证明，也不能在链上创建有效消息或重置已消耗的哈希状态。控制中继节点的对手只能影响网络层方面（延迟和数据包丢失），但不能影响认证安全性。抗Sybil攻击：属性：对手无法创建多个虚假的紧急车辆身份来充斥网络并发送欺诈性优先级消息。论证：哈希承诺注册需要针对CA发布的根节点进行有效的Merkle成员证明。由于只有CA可以向Merkle树中添加叶子，对手无法为不存在的车辆注册承诺。每个承诺都绑定到一个链上注册交易，防止单个车辆超出其注册的广播容量进行复制。中间人攻击抵抗：属性：对手无法通过拦截和操纵车辆与RSU之间的通信来伪造或滥用紧急授权。论证：RSU处的认证决策基于ZKP的有效性和哈希承诺h的链上状态，而不是伴随消息M的内容。紧急授权的语义（车辆类别和合法性）通过其在特定类别Merkle根下的链上注册来携带；对手无法更改h或，否则会破坏证明的有效性，也无法在没有有效Merkle成员证明的情况下注册未经授权的承诺。关于消息内容完整性：虽然ZKP电路不直接将M绑定到h，但在VANET传输过程中对M的篡改通过两种互补机制得到缓解。首先，IEEE 802.11p短距离广播使得在车辆环境中实时拦截和修改数据包变得 praktically difficult。其次，RSU在链上审计日志中记录了接收到的消息和哈希承诺；不同节点接收到的消息之间的任何差异都可以通过不可变的区块链记录发现。此外，一旦RSU验证了紧急授权，它会使用自己的ECDSA密钥签名并重新广播验证后的指令，为所有下游接收者提供加密完整性保护。8. 结论本文提出了一种轻量级的、保护隐私的车联网（VANET）中紧急车辆的认证框架。通过结合特定类别的Merkle树授权、哈希承诺和零知识证明，该方案消除了对证书和CRL的需求，同时保持了强大的安全性。区块链确保了哈希的一次性使用，并提供了不可变的审计日志。我们的评估结果确认了毫秒级别的加密延迟、稳定的RSU处理以及最多20跳的鲁棒多跳性能。未来的工作应该将评估扩展到更大规模的部署，并探索批量机制以减少运营开销。特别是，直接在实际的ECUs或基于ARM的嵌入式平台上评估ZKP的生成和验证是一个重要的下一步，尽管第6.1节中提供的初步性能估计表明该方案在代表性的车辆硬件上仍然可行。此外，研究超出第6.2节中提供的分析估计的区块链可扩展性，包括在城市规模车辆密度下的实证验证（同时有多个RSU提交），以及探索状态管理策略（如链上承诺修剪和第2层扩展解决方案），被认为是未来研究的关键方向。将紧急消息的哈希作为ZKP电路的额外公共输入，从而在证明和消息内容之间提供直接的加密绑定，也被认为是未来工作的一个有价值的改进。