Privacy-Preserving Emergency Vehicle Authentication Scheme Using Zero-Knowledge Proofs and Blockchain

Abstract

Emergency vehicle authentication in vehicular ad hoc networks must satisfy strict latency, privacy, and trust constraints. Existing Public Key Infrastructure- and Conditional Privacy-Preserving Authentication-based schemes incur substantial overhead from certificate management and expensive per-hop verification, making them unsuitable for real-time emergency scenarios. We propose a lightweight zero-knowledge- and blockchain-assisted authentication scheme that eliminates certificates, pseudonym pools, and the requirement for online interaction with a trusted authority during the authentication phase. The Certificate Authority (CA) is involved only during offline initialization stages (vehicle enrollment and Merkle tree construction); once provisioning is complete, the runtime authentication process operates without any online CA interaction. Each emergency vehicle registers one-time hash commitments on-chain after proving membership in a category-specific Merkle tree, and authenticates messages by broadcasting a hash along with a zero-knowledge proof of preimage knowledge. Roadside units verify the proof and consult the on-chain state to enforce single-use semantics, creating a tamper-resistant audit trail. Evaluation using the Veins framework (OMNeT++/SUMO) demonstrated a constant 288-byte authenticated payload, millisecond-level end-to-end delay independent of hop count, and stable blockchain processing under sustained load.

1. Introduction

Vehicular ad hoc networks (VANETs) enable real-time communication among vehicles and roadside infrastructure for safety-critical applications. In emergency scenarios, police cars, ambulances, and fire trucks must obtain immediate road priority, requiring surrounding vehicles and roadside units (RSUs) to verify, within milliseconds, whether a priority message truly originates from an authorized emergency vehicle. Existing authentication mechanisms remain insufficient. Certificate-based Public Key Infrastructure (PKI) schemes incur heavy overhead from Certificate Revocation List (CRL) distribution and may expose vehicle identities [1]; Conditional Privacy-Preserving Authentication (CPPA) and group signature schemes rely on bilinear pairings that often exceed latency constraints for emergency use [2,3]. Blockchain has emerged as a promising complement due to its immutability and decentralized trust [4], nonetheless existing blockchain-enhanced VANET schemes either record explicit identifiers on-chain [5], rely on expensive on-chain verification of zero-knowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs) [6,7], or fail to provide fine-grained authorization and strong privacy simultaneously [8]. Moreover, most prior studies have excluded regulatory oversight; thus, emergency privileges may be misused by authorized vehicles, necessitating tamper-resistant post-event auditing [6,8,9].

To address these challenges, we propose a lightweight, privacy-preserving, and blockchain-assisted authentication framework for emergency vehicle broadcasts. During an offline initialization phase, the Certificate Authority (CA) constructs category-specific Merkle trees (e.g., police, fire, ambulance) and anchors their roots on-chain. Vehicles pre-register one-time hash commitments by providing Merkle inclusion proofs to a smart contract without disclosing identifiers. Once provisioning is complete, the CA is no longer required to be online. During operation, an emergency vehicle broadcasts a packet containing an emergency message, a pre-registered hash commitment h, and a zero-knowledge proof demonstrating knowledge of a secret r such that $H\left(r\right)=h$. RSUs verify the proof locally and query the blockchain to confirm that h is authorized and unused, then mark h as consumed on-chain, creating a privacy-preserving yet auditable broadcast history. Since intermediate vehicles simply forward packets without cryptographic operations, the scheme inherently supports trustless multi-hop forwarding.

To the best of our knowledge, this is the first VANET authentication framework that simultaneously achieves category-based authorization, lightweight zero-knowledge authentication, blockchain-backed auditability, and trustless multi-hop forwarding for emergency vehicle operations.

The main contributions of this paper are summarized as follows:

• A category-specific Merkle tree authorization mechanism that enables fine-grained, privacy-preserving vehicle enrollment without exposing identities on-chain.
• A lightweight ZKP-based authentication protocol using one-time hash commitments, achieving constant-size proofs and millisecond-level verification.
• A blockchain-enforced single-use commitment model that provides replay resistance and tamper-resistant post-event auditability.
• A trustless multi-hop forwarding design in which intermediate vehicles relay authenticated messages without performing any cryptographic operations.

The remainder of this paper is organized as follows. Section 2 reviews related work. Section 3 presents the system model, threat model, and design goals. Section 4 describes the proposed authentication scheme. Section 5 details the implementation. Section 6 presents the evaluation results. Section 7 provides the security analysis. Finally, Section 8 concludes the paper and discusses future work.

2. Related Work

Existing VANET authentication schemes can be broadly categorized into (i) PKI-based; (ii) CPPA; (iii) group-signature and pseudonym-based; and (iv) blockchain-based approaches. We review each category and analyze its limitations below.

2.1. PKI-Based Authentication

In PKI-based systems, a CA issues digital certificates to vehicles and RSUs distribute CRLs. Although batch verification and optimized CRL strategies have been explored [1], PKI schemes fundamentally are subject to rapidly growing CRLs, high per-message verification cost under dense traffic, linkability of certificates to long-term identities, and dependence on continuous CA/RSU connectivity.

2.2. Conditional Privacy-Preserving Authentication

CPPA schemes conceal the sender’s identity during normal operation while allowing authorized authorities to reveal it when necessary. Representative constructions employ ECC, identity-based signatures, or bilinear pairings [2,3,10], although these computationally intensive primitives result in significant per-message verification overhead. Many CPPA approaches also require online RSU participation and rarely incorporate decentralized auditability, limiting their applicability in latency-sensitive emergency scenarios.

2.3. Group Signature and Pseudonym Approaches

Group signatures allow vehicles to sign on behalf of a group while enabling a trusted authority to trace misbehavior [11] but incur high signing/verification overhead and complex revocation. Pseudonym-based approaches involve a rotation of preloaded certificate pools to achieve unlinkability, although they impose heavy storage requirements and complicate revocation [12]. Both face practical limitations in high-mobility emergency scenarios.

2.4. Blockchain-Based Authentication

Blockchain technology was introduced into VANET authentication systems to enhance decentralization, auditability, and resistance to single-point failures. Recent studies have leveraged blockchain to store vehicle registration information, certificate states, or reputation-related data in a tamper-resistant manner [8,9,13]. However, most designs primarily manage identities or certificates and lack fine-grained authorization control [4,8,9]. Moreover, many schemes rely on on-chain cryptographic verification, which incurs substantial overhead unsuitable for latency-sensitive vehicular environments [6,14,15]. Although several studies have explored combining blockchain with zero-knowledge proofs  [6,7,16], these approaches still impose non-negligible computational costs for emergency vehicle authentication.

2.5. Multi-Hop Communication

Multi-hop forwarding is essential in VANETs where messages must be disseminated beyond single-hop ranges. Most existing secure multi-hop protocols rely on end-to-end encryption or explicit trust assumptions, requiring intermediate nodes to participate in cryptographic operations such as key negotiation or signature verification. These requirements introduce key management overhead and processing delays that grow rapidly with the hop count, leading to unacceptable latency for emergency messages. Very few schemes can achieve truly trustless multi-hop forwarding, whereby intermediate vehicles only relay messages without cryptographic operations [9], and even fewer schemes have combined these operations with decentralized auditability or lightweight zero-knowledge proof (ZKP)-based authentication.

2.6. Summary

Table 1 compares representative schemes with the proposed approach taking into consideration key security and system properties.

Table 1. Qualitative comparison of representative vehicular ad hoc network (VANET) authentication schemes and the proposed approach.

Scheme	S1	S2	S3	S4	S5	S6	S7	S8	S9	S10	S11
1 [1]	✓	✓	✓	✓	×	✓	✓	✓	✓	✓	244
2 [2]	✓	✓	✓	✓	×	✓	✓	✓	✓	✓	144
3 [3]	✓	✓	×	✓	✓	✓	×	✓	×	✓	228
11 [11]	✓	✓	×	✓	✓	✓	×	✓	×	✓	556
12 [12]	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	216
Our scheme	✓	✓	×	✓	✓	✓	✓	✓	✓	✓	288

S1: Message authentication; S2: Identity privacy; S3: Low storage; S4: Traceability; S5: Revocation; S6: Unlinkability; S7: Mutual authentication; S8: No pairing verification; S9: No online TA requirement; S10: Replay attack resistance; S11: Single identity-proof data size (bytes). ✓ indicates that the corresponding property is supported, while × indicates that it is not supported.

As Table 1 illustrates, no existing scheme simultaneously achieves all of the following: pairing-free verification, elimination of online trusted authority interaction, trustless multi-hop forwarding, blockchain-backed auditability, and revocation support. This gap motivates the design of the proposed framework, which targets precisely this combination of properties.

3. System Model

The proposed system model involved five types of entities: emergency vehicles, regular vehicles, RSUs, a CA, and a blockchain network.

• Emergency vehicles (e.g., police cars, fire trucks, ambulances) had priority message-broadcasting rights. They served as authenticated message senders, broadcasting emergency signals that trigger special behavior from regular drivers.
• Regular vehicles received and reacted to emergency messages by adjusting driving behavior accordingly. They could also verify the attached zero-knowledge proof and query the blockchain-stored status of hash commitments to independently confirm message legitimacy. In the multi-hop forwarding model, regular vehicles act as relay nodes by rebroadcasting received emergency packets. This relay behavior is consistent with standard VANET flooding protocols (e.g., IEEE 802.11p-based broadcast), where vehicles cooperatively forward safety-critical messages as part of the communication protocol without requiring an explicit incentive mechanism.
• RSUs acted as local authority nodes and gateways to the blockchain. They verified emergency messages by checking the zero-knowledge proof and consulting the blockchain to ensure hash commitments had not been previously consumed, then recorded verification results on-chain for auditing purposes.
• The CA was a trusted authority that enrolled vehicles by assigning digital identities and authorization categories. For each category, the CA constructed a dedicated Merkle proof tree whose leaves correspond to registered vehicles. The CA periodically published category-specific Merkle roots to the blockchain.
• The blockchain network stored essential authentication data: Merkle roots, one-time hash commitments with usage status, and verification event logs. Its immutable nature ensured tamper-resistant authorization data and audit trails. Figure 1 illustrates the overall interaction among these entities in the proposed scheme.

Figure 1. System model overview illustrating the interactions between emergency vehicles, regular vehicles, roadside units (RSUs), the Certificate Authority (CA), and the blockchain in the proposed zero-knowledge proof (ZKP)-based authentication scheme.

3.1. Threat Model and Assumptions

We considered three types of adversaries for the model:

• External attackers could eavesdrop on wireless communications and may attempt to impersonate emergency vehicles by forging or replaying messages but lacked valid cryptographic credentials.
• Untrusted relay vehicles may be curious or malicious, potentially dropping messages, injecting bogus data, or tampering with contents in transit. Our scheme must ensure that intermediate vehicles cannot undermine message authenticity.
• Misbehaving emergency vehicles with valid credentials might broadcast false emergency signals. The system should deter and detect such abuse through post-event accountability.

We assumed that (1) the blockchain consensus was secure with an honest majority; (2) the CA was fully trusted; (3) the hash function was collision-resistant and preimage-resistant; (4) the ZKP system was sound and zero-knowledge; and (5) vehicles kept private keys confidential.

3.2. Design Goals

Based on the threat model, our scheme targets the following goals:

• G1: Lightweight authentication. Low communication and computation overhead enabling real-time verification on resource-constrained vehicular platforms.
• G2: Privacy preservation. Vehicles prove authorization without revealing their identity; no personally identifiable information is embedded in messages.
• G3: Category-based authorization. Only vehicles of appropriate categories can send privileged messages; regular vehicles cannot masquerade as emergency vehicles.
• G4: Decentralized auditability. An immutable blockchain-based audit trail enabling post hoc detection of violations without centralized logging.
• G5: Trustless multi-hop forwarding. Message authenticity holds even when forwarded by untrusted intermediate vehicles that do not possess cryptographic keys.
• G6: Scalability. Practical performance as the vehicle population and broadcast frequency grow, with millisecond-level verification and small proof sizes.

4. Proposed Authentication Scheme

4.1. Merkle Tree-Based Category Authorization

To enforce category-based authorization (G3), the CA maintains a separate Merkle tree for each vehicle category (e.g., police, fire, ambulances). Each leaf represents a registered vehicle in that category. The CA periodically publishes category-specific Merkle roots to the blockchain.

Before registering hash commitments on-chain, a vehicle must prove category membership by providing a Merkle proof. The smart contract verifies this proof against the stored root and only accepts commitments from authorized vehicles. This mechanism controls upload permissions without revealing vehicle identities on-chain, and the blockchain only stores evidence that a hash was uploaded by “an authorized vehicle” in a given category.

4.2. Registration and Hash Provisioning

Each vehicle undergoes enrollment and provisioning before participating in authentication.

Initial registration: The CA assigns each vehicle a digital identity (public/private key pair) and places an entry in the appropriate category Merkle tree. The vehicle receives a Merkle membership proof for later authorization.

Hash provisioning: The vehicle generates secret values $\left\{r_i\right\}$ and computes hash commitments $\{h_i=H\left(r_i\right)\}$. Each $h_i$ is registered on-chain by calling the contract’s registration function together with the Merkle proof. The contract verifies the proof and records $h_i$ as an authorized UNUSED commitment. This establishes a pool of one-time tokens for future authentication. To prevent pool exhaustion, the vehicle monitors its remaining commitment count and initiates replenishment when the pool falls below a configurable threshold (e.g., 20% of the initial pool size). Replenishment is performed via the nearest RSU: the vehicle generates a new batch of secrets, computes the corresponding hash commitments, and registers them on-chain using the same Merkle proof-based procedure. The per-commitment registration cost consists of one Merkle proof verification and one on-chain state write, completing within a single block period (1 s in the PoA configuration). For a typical pool size of 100 commitments, an emergency vehicle broadcasting at a sustained rate of one authenticated message per minute would exhaust its pool in approximately 1.5 h; proactive replenishment at the 20% threshold ensures that the pool is refreshed well before depletion. If the pool is fully exhausted before replenishment, the vehicle temporarily cannot broadcast authenticated emergency messages until new commitments are registered; this scenario is avoidable through appropriate threshold configuration.

4.3. Message Formation and ZKP Generation

When broadcasting an emergency alert, the vehicle retrieves an unused hash commitment h from its pool. The corresponding secret r serves as the basis for generating a proof of authenticity.

The vehicle constructs a message M containing emergency instructions, location, and timestamp, with no identity information. It then generates a zero-knowledge proof $\pi$ attesting:   “I know a secret r such that $H\left(r\right)=h$, where h is an authorized commitment.”

The proof $\pi$ reveals nothing about r or the vehicle’s identity. Using a lightweight hash preimage circuit, both proof generation and verification are completed in milliseconds (G1). The final broadcast packet is $(M,h,\pi )$.

4.4. Broadcasting and Trustless Multi-Hop Forwarding

The packet $(M,h,\pi )$ is broadcast over the VANET. Receivers verify by: (1) checking the ZKP $\pi$ against h, whereby invalid proofs lead to message rejection; and (2) querying the blockchain to confirm h is registered and unused, otherwise the message is ignored as unauthorized or replayed.

The scheme supports trustless multi-hop forwarding: any vehicle receiving a valid packet can relay it without being trusted or pre-authorized. Because the packet carries its own proof, relays cannot spoof or alter messages without detection, and need not perform any cryptographic operations. The latency added by forwarding is only a physical propagation delay (G5, G1).

4.5. RSU Verification and Blockchain Enforcement

When an RSU receives an emergency message, it performs verification and updates the blockchain:

• Proof check: Verify $\pi$ against h and confirm h exists and is unused on-chain.
• State update: If valid, mark h as USED to prevent replay, and log the verification event with a timestamp and category.
• Failure handling: Invalid proofs or unauthorized hashes are rejected and optionally logged for audit.

By recording verification results on-chain, the system creates a tamper-resistant audit trail that balances privacy with accountability (G4). It is important to clarify the separation between real-time authentication and blockchain-based auditing, as they operate on fundamentally different timescales. The RSU’s authentication decision (accept or reject an emergency message) is based entirely on local ZKP verification, which completes in milliseconds and does not depend on blockchain confirmation. The blockchain state update that marks h as USED is an asynchronous operation that serves two purposes: (1) preventing future replay of the same commitment, and (2) creating a tamper-resistant audit trail for post-event regulatory review. Because the authentication decision is local, emergency message processing is never delayed by blockchain latency. In the unlikely event that two geographically distant RSUs receive the same hash h nearly simultaneously, both may accept the message locally; however, only the first on-chain state transition will succeed, and the second transaction will fail, generating an auditable anomaly event on-chain. Under extreme network or blockchain congestion, audit log writes may be delayed, but this does not affect real-time authentication decisions. To ensure audit completeness in such scenarios, RSUs maintain a local write-ahead log of pending blockchain transactions and submit them in batch once connectivity is restored, preserving the integrity of the audit trail without impacting authentication latency. This design reflects a deliberate architectural trade-off: millisecond-level local authentication is prioritized for time-critical emergency scenarios, while the blockchain provides eventual consistency and tamper-resistant post-event accountability.

4.6. Revocation Mechanism

When a vehicle’s authorization must be revoked (e.g., due to theft, credential compromise, or privilege cancelation), the CA removes the corresponding leaf from the category-specific Merkle tree and publishes an updated Merkle root to the blockchain. Once the new root is committed on-chain, the revoked vehicle can no longer register new hash commitments, because its Merkle membership proof becomes invalid against the updated root.

For hash commitments that have already been registered on-chain but remain unused, the CA identifies these commitments through the on-chain transaction records associated with the revoked vehicle’s address, and issues a revocation transaction to the smart contract. The contract marks those commitments with a REVOKED status, preventing the revoked vehicle from consuming previously registered commitments. This three-status model (UNUSED, USED, REVOKED) ensures that revocation is both immediate and auditable.

The same Merkle tree update mechanism also supports dynamic role changes. When a regular vehicle is temporarily assigned an emergency role (e.g., a police vehicle performing an urgent task), the CA adds the vehicle’s leaf to the corresponding category-specific Merkle tree and publishes an updated root on-chain. The vehicle then obtains a new Merkle membership proof and can register hash commitments for that category. Once the temporary assignment ends, the CA removes the leaf and updates the root, revoking the temporary privilege. Throughout this process, privacy is preserved because the blockchain records only that an authorized vehicle registered commitments, without revealing the vehicle’s identity.

5. Implementation

5.1. Smart Contract Architecture

The on-chain logic consisted of two Solidity contracts deployed on an Ethereum-compatible blockchain: (i) a zk-SNARK verifier contract auto-generated by the Circom (a programming language for zk-SNARK circuits)/SnarkJS toolchain, and (ii) an application contract, denoted MerkleTreeWhitelist, which maintained the authorization state and enforced one-time usage of hash commitments. The underlying blockchain used Geth with Clique Proof-of-Authority (PoA) consensus and a 1-s block period, providing deterministic finality suitable for low-latency vehicular applications. The overall architecture is depicted in Figure 2, where the smart contract exposed per-category mappings (MAP1–MAPn) and a set of Merkle roots.

Figure 2. Smart contract architecture with category-specific on-chain hash Maps (MAP1–MAPn) for tracking hash usage states. Category-level write authorization is enforced using Merkle roots anchored on-chain, which are derived from off-chain Merkle trees maintained by the CA. These four functions are abbreviated as F1–F4 in subsequent figures.

The verifier contract exposed verifyProof$(a,b,c,\mathtt{input})\to \{\mathtt{true},\mathtt{false}\}$, which checked a Groth16 (a widely used zk-SNARK proving system with constant-size proofs and efficient verification) proof for the relation

$$\mathcal{R}=\left\{(h;r)\mid r\ne 0,r\in [0,2^{252}-1],H_{\mathrm{Poseidon}}\left(r\right)=h\right\},$$

(1)

where r is the private preimage (nullifier) and h is the public hash commitment. Poseidon is an arithmetic-friendly hash function designed for efficient computation inside zk-SNARK circuits. The verifying key was hard-coded at the deployment time.

The MerkleTreeWhitelist contract stored the CA-published Merkle root merkleRoot and a mapping hasherMapping[h], tracking whether each commitment was UNUSED or USED. It emitted events (VerificationResult, ReplayAttackAttempt, etc.) for auditability.

The two core functions were:

• uploadHasher(proof, hasher): called by vehicles during provisioning. It verified the Merkle proof against msg.sender, then inserted h with status UNUSED.
• verifyAndUseHasher(a,b,c,input): called by RSUs during verification. It checked that h was UNUSED, verified the Groth16 proof, and atomically marked h as USED, enforcing single-use semantics.

Implementation availability: The complete smart-contract and client implementation supporting the findings of this study are available from the authors upon reasonable request.

Merkle Whitelist Tree Construction and Authorization Root

In the deployed prototype, category authorization (Section 4) was achieved via an address-based Merkle whitelist. For each authorized address addr_i, the CA computed the leaf as

$${\ell }_i=\mathtt{keccak}\mathtt{256}(\mathtt{abi}.\mathtt{encodePacked}\left({\mathsf{addr}}_i\right)).$$

(2)

During hash provisioning, the contract reconstructed the leaf from msg.sender and verified the Merkle proof against the stored root, ensuring that only CA-authorized vehicles could register commitments. The Merkle proof was never transmitted during on-line authentication. The complete procedure is illustrated in Algorithm 1.

Algorithm 1 System Setup, Vehicle Activation, and Authorization

Require:  Security parameter $\lambda$, CA whitelist policy Ensure:  Deployed contracts, each vehicle $\mathsf{Veh}$ holds $(sk,pk)$ and Merkle proof ${\pi }_{\mathrm{Merkle}}$   1: /* Phase 1: Infrastructure setup */   2: for each authorized address ${\mathsf{addr}}_i\in {\mathcal{A}}_{\mathrm{EV}}$ do   3:    Compute leaf ${\ell }_i\leftarrow \mathtt{keccak}\mathtt{256}(\mathtt{abi}.\mathtt{encodePacked}\left({\mathsf{addr}}_i\right))$; insert into Merkle tree.   4: end for   5: Compute merkleRoot; run zk-SNARK setup for $\mathcal{R}$ in (1) to obtain $(\mathsf{pk},\mathsf{vk})$.   6: Deploy verifier contract (embedded $\mathsf{vk}$) and MerkleTreeWhitelist (stored merkleRoot).   7: /* Phase 2: Per-vehicle activation */   8: Vehicle generates key pair $(s{k}_{\mathsf{Veh}},p{k}_{\mathsf{Veh}})$ and derives ${\mathsf{addr}}_{\mathsf{Veh}}$.   9: CA verifies authorization, computes leaf ℓ, and delivers Merkle proof ${\pi }_{\mathrm{Merkle}}$ to vehicle. 10: Vehicle stores $(s{k}_{\mathsf{Veh}},p{k}_{\mathsf{Veh}})$ and ${\pi }_{\mathrm{Merkle}}$ in secure memory.

5.2. ZKP Implementation and Workflow

5.2.1. ZKP Circuit and Proof File Implementation

The zero-knowledge component was implemented using Circom 2.2.1 and SnarkJS 0.7.5. The core circuit HasherVerifier took the preimage r as a private input and the commitment h as public input, and enforced the relation $\mathcal{R}$ in (1) via IsZero+NOT (non-zero check), Num2Bits(252) (range check), and Poseidon(1) (hash check).

The circuit was compiled to R1CS and a Groth16 setup yielded $(\mathsf{pk},\mathsf{vk})$. Vehicles generated proofs as $\pi \leftarrow \mathsf{Prove}(\mathsf{pk},(h;r\left)\right)$, obtaining $\pi =(a,b,c)$ and public input = [h]. Witness generation and proof construction are completed in a few milliseconds. The proof was ABI-encoded for submission to the Solidity verifier.

The hash provisioning procedure is illustrated in Algorithm 2.

Algorithm 2 Hash Provisioning On-Chain

Require:  Vehicle $\mathsf{Veh}$ with Merkle proof ${\pi }_{\mathrm{Merkle}}$ Ensure:  On-chain entries $(h,\mathtt{UNUSED})$ in hasherMapping   1: Sample a random preimage $r\in {\mathbb{F}}_p$ with $0<r<2^{252}$.   2: Compute $h\leftarrow H_{\mathrm{Poseidon}}\left(r\right)$.   3: Form the leaf $\mathtt{leaf}=\mathtt{keccak}\mathtt{256}(\mathtt{abi}.\mathtt{encodePacked}(\mathtt{msg}.\mathtt{sender}\left)\right)$ and verify locally that ${\pi }_{\mathrm{Merkle}}$ is consistent with the published root.   4: Vehicle $\mathsf{Veh}$ locally signs a transaction calling uploadHasher(${\pi }_{\mathrm{Merkle}}$, h) and sends it to the RSU, which relays it to the blockchain network.   5: if the Merkle proof is valid and h has not been seen before then   6:     Contract sets hasherMapping[h] = true (UNUSED).   7: end if

5.2.2. Vehicle-Side Workflow

The vehicle-side logic covered three main scenarios: registration, command dissemination, and multi-hop transport.

5.2.3. Scenario 1: Vehicle Registration

Figure 3 illustrates the registration workflow described in Section 4. When the hash pool is exhausted, $V_i$ repeats this process to register additional commitments.

Figure 3. Vehicle registration: the Certificate Authority (CA) distributes zero-knowledge Succinct Non-interactive Argument of Knowledge (zk-SNARK) parameters and Merkle proofs, $V_i$ generates hash commitments, and the roadside unit (RSU) relays transactions to the blockchain.

5.2.4. Scenario 2: Command Dissemination

Figure 4 shows the command dissemination. $V_i$ sent $⟨\mathtt{command},h,\pi ⟩$ to target vehicle(s); the RSU verified $\pi$, marked h as used, and broadcasted a signed verification result.

Figure 4. Command dissemination: $V_i$ sends a ZKP-protected command to target vehicle(s), which is forwarded to the RSU for verification.

5.2.5. Scenario 3: Trustless Multi-Hop Transport

Figure 5 illustrates the multi-hop transport. The ZKP–hash pair $⟨h,\pi ⟩$ remained self-authenticating regardless of hop count; intermediate vehicles only forwarded packets without any cryptographic operations.

Figure 5. Trustless multi-hop transport: the emergency vehicle broadcasts a ZKP-protected message, relay nodes rebroadcast once, and the RSU performs verification.

5.2.6. RSU-Side Verification Workflow

Algorithm 3 indicates the RSU-side procedure.

The on-chain portion of Algorithm 3 was achieved by the verifyAndUseHasher function described in Section 5.1.

All illustrative figures (system architecture diagrams and flowcharts) in this paper were created with the assistance of Claude Opus 4.5 (Anthropic, via Claude Code). The authors reviewed, verified, and manually refined every AI-generated figure to ensure accuracy.

Algorithm 3 RSU-Side Verification and Command Dissemination

Require:  Packet $P=⟨\mathtt{message},h,\pi ⟩$ received from vehicle Ensure:  Boolean decision; optionally a RSU-signed broadcast command   1: Parse P to extract h, proof $(a,b,c)$, and message.   2: $isValid\leftarrow \mathtt{Verifier}.\mathtt{verifyProof}(a,b,c,[h\left]\right)$.   3: if  $isValid=\mathtt{false}$  then   4:    Discard P; return false.   5: end if   6: Call MerkleTreeWhitelist.verifyAndUseHasher(a,b,c,[h]).   7: if call returns false then   8:     Reject as replay/unauthorized; return false.   9: end if 10: Construct Verified Emergency Command from message. 11: Sign with RSU’s ECDSA key and broadcast to vehicles in range. 12: return true.

6. Evaluation

6.1. ZKP Benchmarking (100-Run Test)

We benchmarked the ZKP computational cost on a MacBook Air (Apple M2, 8 GB RAM). The circuit was implemented using Circom 2.2.1 and SnarkJS 0.7.5 with Poseidon hash. Proof generation and verification were each repeated 100 times.

Figure 6 shows that the proof generation time consistently remained in the low millisecond range with minimal run-to-run variation, confirming that the computational cost was stable and suitable for resource-constrained vehicular platforms.

Figure 6. Proof generation time over 100 steady-state runs for the Poseidon-based preimage circuit (platform: Apple M2, 8 GB RAM; toolchain: Circom 2.2.1 + SnarkJS 0.7.5 with Groth16).

Figure 7 shows that verification latency was consistently lower than generation latency and remained within a few milliseconds across all runs. Overall, the ZKP component introduced only a small, bounded processing delay and did not constitute a bottleneck in time-critical VANET environments.

Figure 7. Proof verification time over 100 steady-state runs for the same circuit (platform: Apple M2, 8 GB RAM; toolchain: Circom 2.2.1 + SnarkJS 0.7.5 with Groth16).

It should be noted that the above benchmarking was conducted on a general-purpose laptop (Apple M2), which offers significantly higher computational performance than typical vehicular On-Board Units (OBUs). The primary purpose of this experiment is to confirm the computational characteristics of the ZKP operations and the feasibility of the proposed scheme. Existing studies on Groth16 proof systems report that proof generation on ARM Cortex-A class processors (e.g., Raspberry Pi 4, NVIDIA Jetson Nano) typically incurs a slowdown factor of approximately 5–10× compared to desktop-class hardware for comparable circuit sizes [17]. Applying this factor to the observed millisecond-level generation times on the M2 suggests that proof generation on representative vehicular embedded platforms would remain in the range of tens of milliseconds, which is still within acceptable latency bounds for emergency authentication. Proof verification, which is inherently faster than generation in Groth16, would remain in the low-millisecond range. Nevertheless, direct evaluation on actual Electronic Control Units (ECUs) or ARM-based embedded platforms remains an important subject for future validation.

6.2. Blockchain Smart Contract Evaluation (800 Transactions)

We evaluated the on-chain verifyAndUseHasher function (Section 5.1) under sustained load.

Blockchain environment: We deployed a private Ethereum-compatible blockchain using Geth with Clique PoA consensus and a 1 s block period.

Workload: We sequentially consumed 800 pre-registered hash commitments. Per-transaction time was measured from submission to confirmation. This latency reflected blockchain consensus overhead, not real-time authentication delay: the RSU verified proofs locally and submitted on-chain transactions in parallel for audit logging. Therefore, end-to-end emergency message acceptance latency was dominated by local ZKP verification, whereas blockchain confirmation affected only the audit trail.

Figure 8 depicts the per-transaction processing time course. The majority of transactions were confirmed within a narrow interval governed by the 1 s block period, and no long-term growth trend was observed, indicating effectively constant-time contract execution.

Figure 8. Blockchain processing time course for 800 consecutive RSU verification-and-consumption transactions on a Geth PoA chain with 1 s block period (Verification Sequence Index = transaction order).

Similarly to the ZKP benchmarking, this blockchain evaluation serves as an initial feasibility validation under controlled conditions. The 800-transaction sequential workload demonstrates that per-transaction contract execution time remains stable and does not degrade with cumulative state growth within this scale. To provide a preliminary scalability estimate, consider a city-scale deployment with 10,000 emergency vehicles, each pre-registering 100 hash commitments. The resulting on-chain state comprises 1,000,000 mapping entries, each storing a 32-byte hash and a 1-byte status flag, yielding approximately 33 MB of contract storage—well within the capacity of modern blockchain nodes. On the transaction throughput side, the PoA chain with a 1 s block period can accommodate hundreds of transactions per block; even if all 10,000 vehicles simultaneously consumed one commitment, the backlog would clear within minutes, and real-time authentication would remain unaffected since RSUs verify proofs locally. Extending the evaluation to city-scale vehicle densities with high-concurrency multi-RSU deployments, as well as investigating state management strategies such as commitment pruning and Layer-2 solutions, are identified as important directions for future work.

Gas Cost Analysis

To quantify the computational cost of on-chain verification, we measured the gas consumption of the verifyAndUseHasher function over 400 consecutive transactions on the private PoA chain. Figure 9 summarizes the results. The gas cost remained highly consistent across all transactions, with a minimum of 32,709 units, a maximum of 32,769 units, a median of 32,757 units, and an average of 32,753.55 units. The narrow range (60 gas units) confirms that the contract execution cost is effectively constant and independent of the accumulated on-chain state. All 400 transactions succeeded with a 100% success rate. Although a private PoA chain does not impose monetary transaction fees, the gas measurement provides a hardware-agnostic metric of computational overhead that remains applicable if the scheme were deployed on a public or consortium blockchain.

Figure 9. Gas cost of the verifyAndUseHasher smart contract function over 400 consecutive transactions on a Geth PoA chain (minimum, average, median, and maximum gas used in units).

6.3. VANET Simulation

6.3.1. Simulation Setup

We integrated the authentication protocol into the Veins framework based on the OMNeT++ + SUMO simulator with IEEE 802.11p communication. Emergency vehicles broadcasted 288-byte authenticated messages containing the zk-SNARK proof and the hash commitment.

6.3.2. Realistic Emergency Scenario

To validate the scheme under realistic traffic conditions, we simulated a congested highway scenario in which an ambulance broadcasted authenticated emergency messages while navigating through a traffic jam consisting of approximately 100 regular vehicles on a six-lane road segment. A single RSU performed the ZKP verification and blockchain state updates.

Figure 10 shows the SUMO simulation map used in this scenario. The ambulance (red vehicle) was surrounded by densely packed regular vehicles (shown in yellow), emulating a realistic traffic congestion situation in which emergency broadcasts must propagate under high vehicle density. This end-to-end delay included wireless communication effects (e.g., channel contention, queuing, and multi-hop forwarding) in addition to the RSU’s local ZKP verification time.

Figure 10. Simulation scenario: an ambulance weaves through a traffic jam on a six-lane road segment with approximately 100 regular vehicles. The red vehicle represents the ambulance broadcasting authenticated emergency messages.

Figure 11 shows that the end-to-end authentication delay for each verification event. The delay remained within several tens of milliseconds across all events, confirming that authenticated emergency messages could be processed quickly even under conditions of extreme traffic density.

Figure 11. End-to-end authentication delay per verification event in the simulation scenario.

Figure 12 illustrates the resulting RSU-side processing time, which consistently fell within a low millisecond range, indicating that the RSU computation remained lightweight and did not dominate the overall end-to-end delay.

Figure 12. RSU processing time in the simulation scenario (from message reception to completion of verification and state update).

6.3.3. Multi-Hop Forwarding Experiments

We investigated how multi-hop forwarding influenced the end-to-end delay using a linear topology with 0, 1, 2, and 3 relay hops.

Figure 13 shows that the delay increased roughly linearly with hop count due to channel access delays. The cryptographic cost was independent of hop count since proof generation occurred once at source and verification once at RSU.

Figure 13. Combined end-to-end authentication delay for 0-, 1-, and 2-hop scenarios.

We also evaluated flooding-based forwarding up to 20 hops. Figure 14 shows that delays remained acceptable for emergency applications. Figure 15 confirmed that RSU processing time increased moderately with the hop count under flooding, reflecting the higher volume of forwarded messages received by the RSU.

Figure 14. End-to-end delay in flooding-based multi-hop experiment (up to 20 hops).

Figure 15. RSU processing time in the flooding-based multi-hop experiment.

6.3.4. Comparison with State-of-the-Art Schemes

We compared the multi-hop delay of our scheme against a representative per-hop authentication design, as described by Rabieh et al. [18].

Figure 16 shows that the baseline scheme resulted in a steeper delay increase due to per-hop cryptographic operations, whereas our scheme increased more slowly because ZKP verification was performed only once at the RSU and intermediate relays did not generate additional cryptographic operations. As shown in the qualitative comparison in Table 1, existing schemes typically require either pairing-based verification, online trusted authority interaction, or per-hop cryptographic operations. In contrast, the proposed scheme achieves a unique combination of no-pairing verification, no online TA requirement, and trustless multi-hop forwarding, while maintaining a compact 288-byte authenticated payload size. The trade-off is that the scheme does not achieve low storage (S3) due to the on-chain commitment model; however, the storage overhead per commitment is minimal (a single hash-to-status mapping entry).

Figure 16. Multi-hop end-to-end delay comparison with Rabieh [18].

7. Security Analysis

We analyzed the security properties under the threat model in Section 3.1, assuming that the Poseidon hash function was collision-resistant and preimage-resistant, and the zk-SNARK system was complete, sound, and zero-knowledge.

Correctness: Property: Messages generated by authorized vehicles following the protocol are accepted by honest verifiers with overwhelming probability. Argument: The CA correctly constructs Merkle trees and publishes valid roots. Each authorized vehicle receives a valid Merkle proof and registers hash commitments on-chain. When the vehicle generates a ZKP for a committed hash, the witness satisfies the circuit relation. By completeness of the zk-SNARK, the verifier accepts the proof except with negligible probability. The contract confirms the hash exists and is unused before marking it as consumed.

Unforgeability: Property: An adversary cannot cause a verifier to accept an emergency message not originating from an authorized vehicle, except with negligible probability. Argument: To forge a valid message, an adversary must produce $(h,\pi )$ such that h is registered and unused, and $\pi$ verifies for $H\left(r\right)=h$. Without a valid preimage, this requires breaking either hash preimage resistance or zk-SNARK soundness. Registering unauthorized hashes fails the Merkle membership check. Compromised RSUs cannot forge messages because all hash registration transactions are signed by the vehicle’s private key.

Anti-replay: Property: The scheme is secure against replay attacks. Argument: Each hash h is single-use. After successful verification, the contract permanently marks h as consumed. Any subsequent attempt to reuse h, even with a previously valid proof, is rejected by the availability check. Timestamps in the message further enable receivers to discard stale messages.

Traceability: Property: Misbehaving emergency vehicles can be traced by authorized authorities despite operational anonymity. Argument: The CA maintains a confidential mapping between vehicle enrollment records and Merkle leaves. The blockchain records when and where each hash was used. With legal authorization, investigators identify problematic hashes via on-chain logs and the CA resolves the corresponding Merkle leaf to the real-world vehicle. Blockchain immutability prevents repudiation.

Multi-hop Robustness: Property: Security guarantees are preserved in multi-hop forwarding, even with untrusted intermediate vehicles. Argument: Correctness and unforgeability depend solely on ZKP verification and hash-status checks at the final verifier (RSU) and on blockchain integrity. Intermediate vehicles do not generate or verify proofs and cannot create valid messages or reset consumed hash states on-chain. Adversaries controlling relay nodes can only affect network-layer aspects (delay and packet loss) but not authentication security.

Sybil Attack Resistance: Property: An adversary cannot create multiple fake emergency vehicle identities to flood the network with fraudulent priority messages. Argument: Hash commitment registration requires a valid Merkle membership proof verified against a CA-published root. Since only the CA can add leaves to the Merkle tree, an adversary cannot register commitments for non-existent vehicles. Each commitment is tied to a single on-chain registration transaction, preventing a single vehicle from multiplying its broadcast capacity beyond its registered pool.

Man-in-the-Middle Resistance: Property: An adversary cannot forge or misuse emergency authorization by intercepting and manipulating communication between vehicles and RSUs. Argument: The authentication decision at the RSU is based on the validity of the ZKP $\pi$ and the on-chain status of the hash commitment h, not on the content of the accompanying message M. The emergency authorization semantics (vehicle category and legitimacy) are carried by h through its on-chain registration under a specific category Merkle root; an adversary cannot alter h or $\pi$ without invalidating the proof, and cannot register unauthorized commitments without a valid Merkle membership proof. Regarding message content integrity: while the ZKP circuit does not directly bind M to h, tampering with M during VANET transmission is mitigated by two complementary mechanisms. First, IEEE 802.11p short-range broadcast makes real-time interception and modification of packets practically difficult in vehicular environments. Second, the RSU records the received message alongside the hash commitment in the on-chain audit log; any discrepancy between the message as received by different nodes becomes detectable through the immutable blockchain record. Furthermore, once the RSU verifies the emergency authorization, it signs and rebroadcasts the verified command using its own ECDSA key, providing cryptographic integrity protection for all downstream recipients. As a future enhancement, incorporating a hash of M as an additional public input to the ZKP circuit would provide direct cryptographic binding between the proof and the message content.

8. Conclusions

This work proposes a lightweight, privacy-preserving authentication framework for emergency vehicles in VANETs. By combining category-specific Merkle tree authorization with hash commitments and zero-knowledge proofs, the scheme eliminates the need for certificates and CRLs while maintaining strong security. The blockchain ensures one-time hash usage and provides immutable audit logs.

Our evaluation results confirmed the millisecond-level cryptographic latency, stable RSU processing, and robust multi-hop performance up to 20 hops. Future work should extend the evaluation to larger-scale deployments and explore batching mechanisms to reduce operational overhead. In particular, direct evaluation of ZKP generation and verification on actual ECUs or ARM-based embedded platforms is an important next step, although the preliminary performance estimates presented in Section 6.1 suggest that the scheme remains feasible on representative vehicular hardware. Additionally, investigating blockchain scalability beyond the analytical estimates provided in Section 6.2, including empirical validation under city-scale vehicle densities with concurrent multi-RSU submissions, and exploring state management strategies such as on-chain commitment pruning and Layer-2 scaling solutions, are identified as key directions for future research. Incorporating a hash of the emergency message as an additional public input to the ZKP circuit, thereby providing direct cryptographic binding between the proof and the message content, is also identified as a valuable protocol enhancement for future work.