BcDKM: Blockchain-Based Dynamic Key Management Scheme for Crowd Sensing in Vehicular Sensor Networks

Abstract

Vehicular sensor networks (VSNs) consist of vehicles equipped with various sensing devices, such as LiDAR. In a VSN, vehicles and/or roadside units (RSUs) can be organized into a vehicular cloud (VC) to enable the sharing of sensing and computational resources among participants, thereby supporting crowd-sensing applications. However, the highly dynamic nature of vehicular mobility poses significant challenges in terms of establishing secure and scalable group communication within the VC. To address these challenges, we first introduce a lightweight extension of the continuous group key agreement (CGKA) scheme by incorporating an administrator mechanism. The resulting scheme, referred to as CGKAwAM, supports the designation of multiple administrators within a single group for flexible member management. Building upon CGKAwAM, we propose a blockchain-based dynamic key management scheme, termed BcDKM. This scheme supports asynchronous join and leave operations while achieving communication round optimality. Furthermore, RSUs are leveraged as blockchain nodes to enable decentralized VC discovery and management, ensuring scalability without relying on a centralized server. We formally analyze the security of both CGKAwAM and BcDKM. The results demonstrate that the proposed scheme satisfies several critical security properties, including known-key security, forward secrecy, post-compromise security, and vehicle privacy. Experimental evaluations further confirm that BcDKM is practical and achieves a well-balanced tradeoff between security and performance.

1. Introduction

Vehicular sensor networks (VSNs) can leverage vehicles equipped with advanced onboard (sensing) devices (e.g., LiDAR, around view monitors and AI chips) to collect high-precision environmental and traffic data, thereby enabling large-scale urban crowd sensing applications (e.g., real-time traffic analysis and road anomaly detection) [1]. However, many vehicles remain stationary for extended periods (e.g., charging or parking), leaving these sensing and computing resources underutilized.

To address this issue, researchers have proposed the concept of vehicular cloud (VC) [2], deployed in the VSN environment. A VC enables a group of nearby authenticated vehicles or roadside units (RSUs) to dynamically form a cooperative sensing system, maximizing the utilization of idle sensing resources from stationary vehicles [3]. Within a VC, vehicles can act as cloud administrators or cloud members. Once the VC is established, cloud users (i.e., entities authorized to access the VC) can submit sensing tasks to the cloud administrator via end-to-end secure channels established through key agreement [4]. Upon receiving the tasks, the cloud administrator distributes them to cloud members for collaborative execution.

1.1. Related Work

In the early stages of VC research, the focus was primarily on the design of VC architectures and their potential applications, such as cooperative sensing and resource sharing. However, relatively limited attention was given to the secure establishment of VCs. In the following, we review the evolution of VC architectures and discuss efforts aimed at ensuring the secure establishment of VCs.

VC Architecture. The concept of a VC was first introduced in [5], where a temporary cloud was formed by neighboring vehicles and/or roadside units (RSUs) through V2V and V2I communications. Early VC architectures supported simple tasks like intelligent traffic light control [6]. However, they lacked effective VC management mechanisms, making it difficult to discover suitable VCs and integrate resources across multiple VCs. As a result, vehicles struggled to dynamically discover and join appropriate VCs, and the system suffered from inefficient resource utilization and limited sensing coverage.

To support large-scale applications such as city-wide traffic flow monitoring, researchers proposed an architecture using a Center Cloud Manager (CCM) [2,7]. The CCM handles VC registration, enables VC discovery, etc. [6]. While effective for coordination, the CCM introduces a single point of failure—its unavailability prevents vehicles from accessing or updating VC information. To mitigate risks associated with a centralized CCM, edge computing concepts have been introduced in recent studies, where certain CCM functions are delegated to edge servers (e.g., RSUs) [8]. However, this architecture introduces new challenges. The lack of effective information-sharing mechanisms among different edge servers prevents vehicles from promptly obtaining the task statuses and resource availability of neighboring VCs, thereby hindering their optimal selection and participation in suitable VCs [9].

Given the challenges faced by existing VC architectures, blockchain technology offers promising features, including decentralization, transparency, and tamper resistance. Despite its potential, the integration of blockchain technology into VC management remains in its infancy, with limited research exploring how blockchains can enhance VC discovery, coordination, and resource sharing in a decentralized manner.

Secure Establishment of VCs. Over time, as the demand for security in VC environments has grown, various GKM schemes for the secure establishment of VCs have proposed—some tailored specifically for VCs and others originally designed for general group communication but potentially applicable in VC environments [10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28]. These schemes can be broadly categorized into two types: group key agreement (GKA)-based and group key distribution (GKD)-based schemes. GKA-based schemes are further divided into Traditional GKA (TGKA), Asymmetric GKA (AGKA), and Continuous GKA (CGKA) schemes.

GKA-based GKM schemes enable a group of entities (e.g., vehicles) to collaboratively establish a shared session key for secure communication. However, traditional GKA (TGKA) schemes, typically based on the Diffie–Hellman key exchange [10], require multiple rounds of interaction and assume that all members are simultaneously online and synchronized [11,12,13]. Furthermore, these schemes generally lack a formalized framework for continuous key updates within the protocol design, security model, and analysis. Their security assumptions are also relatively weak, often presuming fully trusted members without accounting for potential compromises of device states or intermediate computations. As a result, the applicability of TGKA schemes is significantly limited in asynchronous and dynamic environments such as VCs. To reduce interaction overhead, Non-Interactive GKA (NIGKA) schemes have been proposed, allowing users to compute a shared key without additional communication. However, existing constructions either only support small groups (e.g., the three-party scheme proposed by Joux [14]) or rely on expensive cryptographic primitives such as indistinguishability obfuscation (iO) [15], while often lacking essential properties like forward secrecy.

AGKA-based schemes enable a group of entities to negotiate a group public key and their respective private keys in a single round [16]. Several AGKA schemes have recently been proposed for VC environments [17,18,19,20]. While promising, these approaches face certain limitations. For instance, AGKA typically requires the maximum group size to be fixed during initialization, which can lead to unnecessary computational and storage overhead if the actual group size is smaller, limiting scalability in large groups. Furthermore, since VC communication occurs over public networks, open access to the group encryption key may expose the system to malicious requests or denial-of-service attempts. Finally, current AGKA schemes are often tightly coupled with bilinear pairing-based constructions, which may incur reactively high computational costs.

Recently, CGKA has been proposed to provide efficient key management for asynchronous, dynamic, and large-scale groups [21]. CGKA is also a potential candidate for secure communication in VC environments [22]. By leveraging a binary tree structure, CGKA achieves logarithmic communication and computational complexity, i.e., $log\left(N\right)$ where N denotes the group size, for group membership changes such as members joining or leaving. However, CGKA lacks robust group management mechanisms, making it susceptible to insider attacks, and it depends on centralized servers for message delivery, which may limit its applicability in decentralized settings [23].

GKM schemes based on GKD typically rely on a trusted dealer (TD) to generate and distribute a shared group session key to all participating entities [24]. Although this approach avoids multiple rounds of interaction among entities, the reliance on a centralized TD introduces inherent limitations. First, the TD may become a single point of failure [25,26]. Second, due to the high mobility of vehicular clouds (VCs)—especially when the group is composed entirely of vehicles—it can be difficult to maintain a suitable and consistently available TD.

Technological Readiness of Vehicular Sensors. Modern vehicles have become highly integrated sensor platforms, providing rich data sources for VSNs. Commercially available sensors, such as LiDAR [29], 4D mmWave radar [30], and high-precision GPS sensors, can capture millisecond-level 3D information of the surrounding environment [1]. On the computational side, vehicles are equipped with high-performance onboard systems, such as the NVIDIA Orin [31], capable of efficiently processing large volumes of sensor data in real time. In terms of communication, many vehicles feature high-speed modules (e.g., 5.9 GHz C-V2X [32]), enabling low-latency and reliable data exchange. These commercial sensors and computing and communication modules allow for real-time sharing of traffic, road, and infrastructure information, supporting applications such as traffic flow optimization, signal control, and congestion warnings to improve road efficiency and safety. The security of these valuable data is increasingly important. The algorithms of the schemes proposed in this work (see Section 3 and Section 4) are fully compatible with existing commercial vehicle computing modules. At the same time, emerging devices, such as blockchain-enabled units, are beginning to appear in experimental and pilot deployments. Therefore, this work is forward-looking while remaining compatible with current VSN technologies.

1.2. Our Contribution

Due to the high level of mobility and dynamic nature of vehicular sensor networks (VSNs), traditional group key management (GKM) schemes are inadequate for establishing secure group channels for vehicular clouds (VCs) in such settings. To address this challenge, we propose a blockchain-based dynamic key management scheme, referred to as BcDKM. This scheme is built upon a slightly modified continuous group key agreement (CGKA) scheme—namely, CGKAwAM—and incorporates blockchain and smart contract mechanisms to address the core challenges identified in Section 1. The proposed scheme enables vehicles to establish secure group communication channels in VSNs and continuously update session keys to ensure communication security. The main contributions of this work are summarized as follows:

• We propose the CGKAwAM scheme, which extends CGKA scheme with a lightweight administrator-driven group member management mechanism. Unlike the standard CGKA scheme, CGKAwAM supports multiple administrators within a single VC. Each administrator is capable of independently processing user-initiated proposals (such as Join, Remove, and Update) in a single communication round.
• Based on CGKAwAM and blockchain technology, we design the BcDKM scheme, which provides several key advantages. First, it enables distributed VC discovery and management (see Section 2.2). RSUs act as blockchain nodes and use smart contracts to publish VC information, facilitating efficient matching and information sharing between vehicles and VCs. Additionally, multiple cloud administrators collaboratively manage each VC in a decentralized manner, reducing the risk of a single point of failure. Second, the scheme achieves round optimality and large-scale VC scalability (see Section 2.2). VC initialization and member join/leave operations can be completed asynchronously in a single communication round, without requiring all members to be online. Furthermore, the computational complexity grows logarithmically with the number of members, making the scheme suitable for large-scale deployment.
• We provide a rigorous formal security analysis for both the CGKAwAM and BcDKM schemes. Specifically, under a non-adaptive security model, we construct a game-based proof using the game-hopping technique, reducing the security of CGKAwAM to the CPA security of the underlying public key encryption scheme and the security of the pseudorandom generator. Our analysis shows that the proposed scheme satisfies multiple critical security properties, including key independence, forward secrecy, and post-compromise security. In addition, we analyze the security of the BcDKM scheme and show that it not only satisfies basic security requirements but also provides protection for vehicle privacy.
• We conduct a comprehensive evaluation of the proposed scheme through both theoretical analysis and simulation experiments. We also compare our scheme with several existing representative solutions. The results demonstrate that BcDKM achieves a balance between security and efficiency, confirming its practical feasibility.

The remainder of this paper is organized as follows. Section 2 presents the background, including the system model, design goals, and cryptographic tools. Section 3 describes the detailed design of the proposed CGKAwAM scheme and the associated smart contracts. Section 4 introduces the design of the BcDKM scheme. Section 5 provides a security analysis of the proposed schemes—namely, CGKAwAM and BcDKM. Section 6 evaluates the performance of the proposed schemes and presents the analysis results. Finally, Section 7 concludes the paper.

2. Background

2.1. System Model

As shown in Figure 1, our system consists of the following entities:

• Certificate Authority (CA): The CA is a trusted third party responsible for generating public system parameters and issuing digital certificates to vehicles and RSUs.
• Vehicles: Each vehicle is equipped with an onboard unit (OBU) that provides computing and communication capabilities and stores certificates and related secrets. A VC is formed by a group of vehicles and supports dynamic membership, allowing vehicles to join or leave the VC as needed. The vehicle that initiates the VC formation may act as the cloud administrator or delegate this responsibility to another vehicle, while the remaining participants serve as cloud members.
• Roadside Unit (RSU): The RSU is located along the roadside; it communicates with vehicles within its coverage area, authenticates their identities, and publishes the VC information. Additionally, RSUs are assumed to function as part of the blockchain infrastructure, acting as blockchain nodes.
• Blockchain (BC): The BC provides reliable data storage and supports automated execution via smart contracts. In our system, it is used to record VC-related information and assist VC administrators in managing the cloud.
• Cloud Users (CUs): A CU refers to any authorized entity that accesses and utilizes the services provided by a VC. CUs can submit tasks to their selected VC for execution.

2.2. Threat Model and Design Goals

In our system, we assume that the CA is trusted and faithfully provides registration services to vehicles and RSUs. The blockchain is also assumed to be trusted, offering essential security properties such as resistance to 51% attacks [27]. However, both RSUs and vehicles are considered potentially malicious, as they are typically deployed in open environments and may be compromised by attackers. Additionally, we assume that the attacker has control over the wireless communication channel and is capable of eavesdropping on, injecting, transmitting, or modifying messages transmitted over the network.

Under this model, the security goals of our scheme are outlined as follows:

• Vehicle privacy: This property ensures that no one, except the CA, can learn the true identity of a cloud member (a vehicle) within a VC.
• Known-key security: This property ensures that even if an attacker obtains a session key of a cloud member within a particular VC, the security of other independent session keys remains uncompromised.
• Forward secrecy: This property ensures that if a vehicle is compromised by an attacker at a certain point in time, all session keys generated prior to the compromise remain confidential.
• Post-compromise security: This property ensures that if a vehicle is compromised at a certain point in time and the compromised vehicle subsequently performs a session key update that is not influenced by the attacker, then the updated session key remains confidential.

Our scheme also considers the following goals, in addition to the above security goals:

• Distributed VC discovery: This property enables a vehicle to efficiently discover existing VCs and their metadata via nearby RSUs, avoiding reliance on centralized platforms and mitigating single points of failure.
• Distributed management: This property ensures that each VC is managed by multiple cloud administrators. If one administrator becomes unavailable, others can still handle requests from vehicles inside or outside the VC (e.g., join and leave). This design mitigates insider threats and avoids single points of failure.
• Round optimality: This property ensures that group session key establishment and updates within a VC can be completed in a single round of communication, achieving optimal round complexity.
• Large-scale VC scalability: This property ensures efficient operation in VCs with many cloud members, as key management complexity grows logarithmically with group size.

Remark 1.

It is worth noting that most existing VC-oriented GKM schemes define forward and backward security only against passive adversaries (i.e., eavesdropping capabilities) [12,26]. Forward Secrecy (not to be confused with our Forward secrecy) ensures that a passive adversary who knows a contiguous subset of old group keys cannot derive subsequent group keys, thereby preventing vehicles from accessing current communications after leaving the group. Backward Secrecy (not to be confused with our Post-compromise security) ensures that a passive adversary who knows a contiguous subset of group keys cannot derive preceding group keys, preventing newly joined vehicles from accessing past communications. In contrast, the forward security and post-compromise security offered by our scheme are stronger, as they not only resist passive eavesdropping but also withstand active adversaries (e.g., compromised vehicles) rather than being limited to passive threats.

2.3. Building Blocks

In this section, we introduce several fundamental cryptographic tools that are employed in our system to achieve the desired goals. These building blocks include public key encryption (PKE), digital signature (DS), symmetric encryption (SE), pseudorandom generators (PRNGs), and PRG-based binary trees.

Definition 1

(PKE Scheme). A PKE scheme ($\mathsf{PKE}$ = $\{\mathsf{PInit}$, $\mathsf{PGen}$, $\mathsf{PEnc}$, $\mathsf{PDec}\}$) consists of the following algorithms:

• $\mathsf{PInit}\left(1^{\kappa }\right)\to psp$: This algorithm accepts $1^{\kappa }$ and outputs the system parameters ($psp$).
• $\mathsf{PGen}\left(psp\right)\to (sk,pk)$: This algorithm accepts $psp$ and generates a private–public key pair $(sk,pk)$.
• $\mathsf{PEnc}(pk,m)\to cm$: This algorithm accepts a plaintext (m) and a public key ($pk$) and outputs a ciphertext ($cm$).
• $\mathsf{PDec}(cm,sk)\to m$: This algorithm accepts a ciphertext ($cm$) and a secret key ($sk$) and outputs a plaintext (m).

In our scheme, we rely on a PKE scheme that is secure against chosen plaintext attacks (CPAs), a widely accepted security notion in modern cryptography. Let ${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{CPA}}$ denote the adversary’s advantage in breaking the PKE scheme; the corresponding formal security definition is given in Appendix A.

Definition 2

(DS Scheme). A digital signature scheme ($\mathsf{DS}$ = $\{\mathsf{DInit}$, $\mathsf{DGen}$, $\mathsf{DSign}$, $\mathsf{DVer}\}$) consists of the following algorithms:

• $\mathsf{DGen}\left(1^{\kappa }\right)\to (sk,pk)$: This algorithm takes $1^{\kappa }$ as input and outputs a private–public key pair $(sk,pk)$.
• $\mathsf{DSign}(sk,m)\to \sigma$: This algorithm takes $sk$ and a message (m) as input and outputs a signature (σ).
• $\mathsf{DVer}(pk,m,\sigma )\to \{0,1\}$: This algorithm takes $pk$, a message (m), and a signature (σ) as input and outputs 1 if the signature is valid or 0 otherwise.

In our scheme, we rely on a digital signature scheme that is existentially unforgeable under chosen message attacks (EUF-CMA).

Definition 3

(SE Scheme). A symmetric encryption scheme ($\mathsf{SE}=\{\mathsf{SGen},\mathsf{SEnc},\mathsf{SDec}\}$) consists of the following algorithms:

• $\mathsf{SGen}\left(1^{\kappa }\right)\to k$: This algorithm takes $1^{\kappa }$ as input and outputs a secret key (k).
• $\mathsf{SEnc}(k,m)\to c$: This algorithm takes a secret key (k) and a message (m) as input and outputs a ciphertext (c).
• $\mathsf{SDec}(k,c)\to m$: This algorithm takes k and a ciphertext (c) as input and outputs a message (m).

In our scheme, we rely on a symmetric encryption scheme that is semantically secure.

Definition 4

(RPG). A PRG is a function, i.e., ${\mathsf{H}}_{\mathit{prg}}:\mathcal{R}\to \mathcal{K}\times \mathcal{R}$, where $\mathcal{R}$ denotes the random seed space and $\mathcal{K}$ denotes the secret key space.

Let ${\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{PRG}}$ denote the adversary’s advantage in breaking the PRG; the corresponding formal security definition is given in Appendix A.

We define a helper function (${\mathsf{H}}_{\mathrm{prg}}^d\left(x\right)$) by iteratively invoking the PRG (${\mathsf{H}}_{\mathrm{prg}}$) for d rounds, starting from an initial seed ($x\in \mathcal{R}$). Formally, let $x_1=x$. For each $i\in \{1,\dots ,d\}$, we compute $(s{k}_i,x_{i+1})\leftarrow {\mathsf{H}}_{\mathrm{prg}}\left(x_i\right)$. The output of the helper function is defined as ${\mathsf{H}}_{\mathrm{prg}}^d\left(x\right)=s{k}_d$, i.e., only the secret key ($s{k}_d$) obtained in the d-th iteration is returned as the final result.

Definition 5

(PRG-based Binary Tree). A PRG-based binary tree (PBT) is a full binary tree used for key derivation. A PBT consists of Y nodes, denoted as ${\left\{A_j\right\}}_{j=1}^Y$, and has a height of $h=\lfloor {log}_2\left(Y\right)\rfloor +1$. Specifically, let $A_1$ be the root node. The leaf nodes are represented as ${\left\{A_{2^{h-1}+z}\right\}}_{0\le z\le 2^{h-1}-1}$, while the remaining internal (non-leaf) nodes are represented as ${\left\{A_{z+1}\right\}}_{1\le z<2^{h-1}-1}$. Each node ($A_j\in {\left\{A_j\right\}}_{j=1}^Y$) stores a unique tuple in the form of $(sk,pk,he,e,sv)$, where $sv$ denotes a secret value and $sk$ is a secret key derived from $sv$ using a PRG. The public key ($pk$) is derived from $sk$ using a public key derivation algorithm ($p{k}_{sk}\leftarrow \mathsf{DerivePK}\left(sk\right)$). In our scheme, $pk$ is derived from $sk$ using the same method as in the $\mathsf{PGen}\left(psp\right)$ of a PKE scheme, making the resulting key pairs fully compatible with the corresponding PKE scheme. The value of $he$ indicates the height of the node in the tree (e.g., each leaf node is assigned $he=1$, while the root node is assigned $he=h$), and e indicates whether a node is a leaf (with $e=1$ denoting leaf nodes and $e=0$ denoting non-leaf nodes). The values in each tuple are initialized using the algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Init}}\left({\left\{a_i\right\}}_{i=1}^n\right)\to {\left\{A_j\right\}}_{j=1}^Y$ (defined below) and updated using the algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,I,ra)\to {\left\{A_j\right\}}_{j=1}^Y$ (as defined below). The size of a PBT can also be expanded to include additional nodes using the algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Ext}}\left({\left\{A_j\right\}}_{j=1}^Y\right)\to {\left\{A_k^{\prime }\right\}}_{k=1}^{2Y+1}$. A formal description of the ${\mathsf{PBT}}_{\mathsf{Ext}}$ algorithm is provided in Appendix B (see Algorithm A2).

The algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Init}}\left({\left\{a_i\right\}}_{i=1}^n\right)\to {\left\{A_j\right\}}_{j=1}^Y$ is used to initialize a PBT. In our scheme, it is executed by a cloud administrator and is used to initialize a VC (see Section 4.5 for VC initialization). Given a set of secret values (${\left\{a_i\right\}}_{i=1}^n$, as chosen by a cloud administrator), the algorithm outputs a PBT ${\left\{A_j\right\}}_{j=1}^Y$ with a height of $h=\lceil {log}_2\left(n\right)\rceil +1$ and $Y=2^{\lceil {log}_2\left(n\right)\rceil +1}-1$. A formal description of the ${\mathsf{PBT}}_{\mathsf{Init}}$ algorithm is provided in algorithm is provided in Appendix B (see Algorithm A1).

In our scheme, the algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,I,ra)\to {\left\{A_j\right\}}_{j=1}^Y$ is executed by a cloud administrator or a cloud member to update the nodes along the path from the leaf node at position I (where I denotes the index of a node in the leaf layer) to the root of the PBT (${\left\{A_j\right\}}_{j=1}^Y$) using a random value ($ra$). Given a PBT (${\left\{A_j\right\}}_{j=1}^Y$), a leaf position (I), and a random value ($ra$) selected by the cloud administrator or a cloud member, the algorithm outputs an updated PBT (${\left\{A_j\right\}}_{j=1}^Y$). A formal description of the ${\mathsf{PBT}}_{\mathsf{Upd}}$ algorithmis provided in Appendix B (see Algorithm A3).

In our scheme, the PBT is utilized to support the continuous and dynamic updating of session keys in a VC. To achieve these goals, we define several helper algorithms to retrieve paths and associated nodes from the PBT.

• The algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Path}}({\left\{A_j\right\}}_{j=1}^Y,I)\to {\left\{A_i\right\}}_{i=1}^Z$, where $Z=\lfloor {log}_2\left(Y\right)\rfloor +1$, is used to retrieve the sequence of nodes along the path from the I-th leaf node to the root of the given PBT ${\left\{A_j\right\}}_{j=1}^Y$. It is typically executed by the cloud administrator or a cloud member. Given a PBT (${\left\{A_j\right\}}_{j=1}^Y$) and position (I) selected by the cloud administrator or a cloud member, the algorithm returns a path (${\left\{A_i\right\}}_{i=1}^Z$) that consists of direct references to the original PBT nodes so that any modification of a node in the path immediately affects the original PBT nodes.
• The algorithm expressed as ${\mathsf{PBT}}_{\mathsf{Epath}}({\left\{A_j\right\}}_{j=1}^Y,{\left\{A_i\right\}}_{i=1}^Z)\to {\left\{A_j^{\prime }\right\}}_{j=1}^Y$, where $Z=\lfloor {log}_2\left(Y\right)\rfloor +1$, is used to generate a modified copy of a given PBT (${\left\{A_j\right\}}_{j=1}^Y$), with all sensitive information (i.e., private key and secret value) outside the specified path (${\left\{A_i\right\}}_{i=1}^Z$) masked. It is typically executed by the cloud administrator. Given a PBT (${\left\{A_j\right\}}_{j=1}^Y$) and a path (${\left\{A_i\right\}}_{i=1}^Z$) within the PBT selected by the cloud administrator, the algorithm returns a duplicate PBT (${\left\{A_j^{\prime }\right\}}_{j=1}^Y$), in which the private keys and secret values of all nodes not included in the path (${\left\{A_i\right\}}_{i=1}^Z$) are set to null.
• The algorithm expressed as ${\mathsf{PBT}}_{\mathsf{RCA}}({\left\{A_j\right\}}_{j=1}^Y,A_k,A_{k^{\prime }})\to \{A_{k^{″}},\dots ,A_1\}$ is used to obtain the set of common ancestor nodes shared by $A_k$ and $A_{k^{\prime }}$ in the tree expressed as ${\left\{A_i\right\}}_{i=1}^Y$, ranging from their lowest common ancestor ($A_{k^{″}}$) up to the root node ($A_1$).

3. Building Blocks

In this section, we first design a continuous group key agreement scheme with an administrative mechanism (CGKAwAM), which supports multiple administrators and provides a continuous key stream for dynamic groups. We next introduce two designed smart contracts: VIDSC and VCSC. Based on CGKAwAM and the proposed contracts, we then construct a blockchain-based dynamic key management scheme tailored for vehicle cloud (VC) systems (see Section 4).

3.1. CGKA with Administrator Mechanism (CGKAwAM)

A CGKAwAM $(SetUp,KeyGen,Create,Proposal,Commit,Process)$ comprises the following algorithms:

• SetUp$\left(\kappa \right)\to csp$: This algorithm is executed by a trusted authority (e.g., certification authority) to generate system parameters. Upon input of a security parameter ($\kappa$), it outputs a common system parameter ($csp$). The trusted authority proceeds as follows:

  1.

  Select a public key encryption scheme ($\mathsf{PKE}=\{\mathsf{PInit},\mathsf{PGen},\mathsf{PEnc},\mathsf{PDec}\})$. Invoke $\mathsf{PInit}\left(1^{\kappa }\right)$ to obtain $psp$ (see Definition 1).

  2.

  Choose a secure PRG (${\mathsf{H}}_{\mathrm{prg}}:\mathcal{R}\to \mathcal{K}\times \mathcal{R}$; see Definition A2).

  3.

  Publish the common system parameter ($csp=(\mathsf{PKE}$, ${\mathsf{H}}_{PRG}$, $psp$)).

• KeyGen$(csp,u_i)\to K{P}_{u_i}$: This algorithm is executed by a user with identifier $u_i$ to generate their own key pair. Upon input of $csp$ and $u_i$, it outputs a public–private key pair ($K{P}_{u_i}=(s{k}_{u_i},p{k}_{u_i})$). Internally, it invokes $\mathsf{PGen}\left(psp\right)$ to generate the key pair ($K{P}_{u_i}$).
• Create$(csp,G,u_1)\to$ (${\gamma }_{u_1}^{gid}$, CM): This algorithm is executed by user $u_1$, acting as the group administrator, to initiate a new group. Upon input of $csp$, an identifier set ($G=\{u_1,\dots ,u_n\}$ with $n>1$), and an identifier ($u_1\in G$), it outputs the administrator’s local state (${\gamma }_{u_1}^{gid}$, where $gid$ is the newly assigned group identifier), and a set of control messages ($\mathsf{CM}$) is used to invite the remaining members in G to join the group. The state encapsulates the user’s status in the group, including the session key, the list of group administrators, the list of group members, public parameters, and so on. Furthermore, suppose that each user $u_i\in G$ holds a key pair $(s{k}_{u_i},p{k}_{u_i})$. $u_1$ initializes a group as follows:

  1.

  Set the group identifier ($gid={\mathsf{H}}_{PRG}\left(St{r}_G\right)$, where $St{r}_G=u_1\left|\right|\dots \left|\right|u_n\left|\right|ts$ $ts$ is a timestamp).

  2.

  Select s users from G to serve as administrators, forming the set expressed as $\mathsf{Adm}$. The remaining users form the set expressed as $\mathsf{Mem}=G\setminus \mathsf{Adm}$.

  3.

  Assign each user ($u_i\in G$) a unique random number ($a_i\in \mathcal{R}$). This yields the set expressed as $\{a_1,\dots ,a_n\}$.

  4.

  Invoke ${\mathsf{PBT}}_{\mathsf{Init}}\left({\left\{a_i\right\}}_{i=1}^n\right)$ to construct a PBT ${\left\{A_j\right\}}_{j=1}^Y$, where $Y=2^h-1$ and $h=\lceil {log}_2\left(n\right)\rceil +1$.

  5.

  Compute the session key as $rsk={\mathsf{H}}_{\mathsf{prg}}\left(\overline{A_1}\right)$, where $\overline{A_1}=sk\parallel pk\parallel h\parallel e\parallel sv$ is the serialized string of the tuple stored at the root node $A_1$; see Definition 5.

  6.

  Initialize a mapping array ($\mathrm{Map}\left[\right]$) of length $\mathrm{len}=2^{h-1}$ to associate each PBT leaf node with a user from G. Set $\mathrm{Map}\left[i\right]\leftarrow u_i$ for $1\le i\le n$ and $\mathrm{Map}\left[i\right]\leftarrow \mathrm{null}$ for $n<i\le len$.

  7.

  For each user with identifier $u_z$ in $G\setminus \left\{V_1\right\}$, generate a control message as follows:

  –

  If $u_z\in \mathsf{Adm}$, do the following:

  (a)

  Invoke $\mathsf{PEnc}(p{k}_{u_z},{\left\{A_j\right\}}_{j=1}^Y \Vert ip \Vert n \Vert \mathrm{Map} \Vert len)$ to obtain the ciphertext ($c{m}_z$), where $ip$ denotes the position assigned to user $u_z$ in the PBT (i.e., the $ip$-th leaf node such that $\mathrm{Map}\left[ip\right]=u_z$).

  (b)

  Add the control message ($c{m}_z=(\mathrm{Join} \Vert c{p}_z \Vert u_1 \Vert {\mathsf{sc}}_{vid} \Vert \mathsf{Adm} \Vert \mathsf{Mem})$) to set $\mathsf{CM}$.

  –

  Otherwise, do the following:

  (a)

  Invoke ${\mathsf{PBT}}_{\mathsf{Path}}({\left\{A_j\right\}}_{j=1}^Y,ip)$ to obtain a path (${\left\{A_{j^{\prime }}\right\}}_{j^{\prime }=1}^L$, where $L=\lfloor {log}_2\left(Y\right)\rfloor +1$, $\mathrm{Map}\left[ip\right]=u_z)$.

  (b)

  Invoke ${\mathsf{PBT}}_{\mathsf{Epath}}({\left\{A_j\right\}}_{j=1}^Y,{\left\{A_{j^{\prime }}\right\}}_{j^{\prime }=1}^L)$ to obtain a PBT (${\left\{A_j^{\prime }\right\}}_{j=1}^Y$).

  (c)

  Invoke $\mathsf{PEnc}(p{k}_{u_z}$, ${\left\{A_j^{\prime }\right\}}_{j=1}^Y \Vert ip \Vert n \Vert \mathrm{Map} \Vert len)$ to obtain $c{m}_z$.

  (d)

  Add the control message ($c{m}_z=(\mathrm{Join} \Vert c{p}_z \Vert u_1 \Vert \mathsf{Adm} \Vert \mathsf{Mem})$) to set $\mathsf{CM}$.

  8.

  Set the state as ${\gamma }_{u_1}^{gid}=(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},\mathit{len},n,{\left\{A_j\right\}}_{j=1}^Y,rsk,\mathit{index})$, where $\mathsf{Role}=\mathit{adm}$ indicates that $u_1$ is designated as the administrator and $\mathit{index}=1$ indicates that $u_1$ is mapped to the first leaf node of the PBT, i.e., $\mathrm{Map}\left[\mathit{index}\right]=u_1$.

  9.

  Send each control message in set $\mathsf{CM}$ to the corresponding user.

• Proposal$(csp,gid,u_i,u_a,prop,txt)\to PM$: This algorithm is executed by user $u_i$ to generate a proposal message ($PM$) intended for the group administrator ($u_a$) within the $gid$ group, with the purpose of requesting a group membership change (e.g., join or leave) or a session key update. Upon input of $csp,gid,u_i,u_a$ and a proposal type ($prop\in \{\mathsf{ADD},\mathsf{REM},\mathsf{UPD}\}$), it outputs the proposal message ($PM$). The $prop$ parameter specifies the purpose of the proposal: adding a member, removing a member, or updating the session key. The $\mathit{txt}$ field represents the payload associated with the proposal. We present three example proposal messages used in our scheme as follows.

  –

  $PM=(\mathit{gid} \Vert \mathtt{ADD} \Vert u_a \Vert u_i \Vert \mathit{txt})$: A join request from an external user ($u_i$), asking administrator $u_a$ to add it to group $\mathit{gid}$, where $txt=\mathtt{NULL}$.

  –

  $PM=(\mathit{gid} \Vert \mathtt{REM} \Vert u_a \Vert u_i \Vert \mathit{txt})$: A removal request by current group member $u_i$, requesting to leave or be removed from the $gid$ group, where $\mathit{txt}=\mathtt{NULL}$.

  –

  $PM=(\mathit{gid} \Vert \mathtt{UPD} \Vert u_a \Vert u_i \Vert \mathit{txt})$: A key update request by current group member $u_i$, asking $u_a$ to update the group session key, with $\mathit{txt}=\mathsf{PEnc}(p{k}_{u_a},sd)$, where $p{k}_{u_a}$ is the public key of $u_a$ and $sd$ is randomly selected by $u_i$.

  User $u_i$ sends the proposal message ($PM$) to the administrator ($u_a$).
• Commit$(csp,{\gamma }_{u_a}^{gid},PM)\to ({{\gamma }^{\prime }}_{u_a}^{gid},\mathsf{CM})$: This algorithm is executed by user $u_a$, who serves as the administrator of the $gid$ group. It is used to process a proposal message ($PM$) submitted by another user. Upon input of $csp,{\gamma }_{u_a}^{gid},PM$, it outputs the updated state (${{\gamma }^{\prime }}_{u_a}^{gid}$) and a set of control messages ($\mathsf{CM}$), which are used by the other group members to update their local states. Suppose $u_a$ in a group ($gid$) has a local state of ${\gamma }_{u_a}^{gid}$ = ($\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n,{\left\{A_j\right\}}_{j=1}^Y,rsk$, $index$). Suppose $PM=(gid \Vert prop \Vert u_a \Vert u_i \Vert txt)$. $u_a$ then processes the $PM$ as follows:

  –

  If $prop=\mathrm{ADD}$, do the following:

  1.

  Search the Map array for an index ($ip$) such that $\mathrm{Map}\left[ip\right]=⌀$. If no such index exists (i.e., all current leaf nodes are occupied), invoke the helper function (${\mathsf{PBT}}_{\mathsf{Ext}}\left({\left\{A_j\right\}}_{j=1}^Y\right)$) to extend the PBT, and search again for an empty index ($ip$). Once an empty index is found, set $\mathrm{Map}\left[ip\right]=u_i$, $n=n+1$, and add $u_i$ to the the $\mathsf{Mem}$ set.

  2.

  Select a random value ($a_r$) for user $u_i$.

  3.

  Generate the corresponding control messages for user $u_i$ as follows:

  (a)

  Invoke ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,ip,a_r)$ to update the path in the PBT (${\left\{A_j\right\}}_{j=1}^Y$).

  (b)

  Invoke ${\mathsf{PBT}}_{\mathsf{Path}}({\left\{A_j\right\}}_{j=1}^Y,ip)$ to obtain the updated path (${\left\{A_{j^{\prime }}\right\}}_{j^{\prime }=1}^{L=\lceil {log}_2\left(n\right)\rceil +1}$).

  (c)

  Invoke ${\mathsf{PBT}}_{\mathsf{Epath}}({\left\{A_j\right\}}_{j=1}^Y,{\left\{A_{j^{\prime }}\right\}}_{j^{\prime }=1}^L)$ to obtain ${\left\{A_j^{\prime }\right\}}_{j=1}^Y$.

  (d)

  Invoke $\mathsf{PEnc}(p{k}_{u_i}$, ${\left\{A_j^{\prime }\right\}}_{j=1}^Y \Vert ip \Vert n \Vert \mathrm{Map} \Vert len)$ to obtain $c{p}_i$.

  (e)

  Add the message expressed as $c{m}_i=(\mathrm{Join} \Vert c{p}_i \Vert u_a \Vert u_i \Vert \mathsf{Adm} \Vert \mathsf{Mem})$ to set $\mathsf{CM}$.

  4.

  Generate the corresponding control messages for administrators ($u_z\in \mathsf{Adm}\setminus \left\{u_a\right\}$) as follows:

  (a)

  Invoke $\mathsf{PEnc}(p{k}_{u_z},{\left\{A_j\right\}}_{j=1}^Y,len,n,\mathrm{Map})$ to obtain the ciphertext ($c{p}_z$).

  (b)

  Add the message expressed as $c{m}_z=(\mathrm{Admin} \Vert c{p}_z \Vert u_a \Vert u_i \Vert \mathsf{Adm} \Vert \mathsf{Mem})$ to set $\mathsf{CM}$.

  5.

  Generate the corresponding control messages for the other group members (i.e., $\{\mathsf{Mem}\setminus u_i\}$) as follows:

  (a)

  Invoke ${\mathsf{PBT}}_{\mathsf{Path}}({\left\{A_j\right\}}_{j=1}^Y,ip)$ to obtain the path expressed as

  ${\left\{A_{j^{‴}}\right\}}_{j^{‴}=1}^{L=\lceil {log}_2\left(n\right)\rceil +1}$.

  (b)

  For each node on the path expressed as $A_k\in {\left\{A_{j^{‴}}\right\}}_{j^{‴}=1}^L$, do the following:

  i.

  If node $A_k$ has a non-empty sibling node ($A_{k^{\prime }}$) in the PBT (${\left\{A_j\right\}}_{j=1}^Y$, i.e., $A_k$ and $A_{k^{\prime }}$ share the same direct parent node, where $k^{\prime }=k+1$ or $k^{\prime }=k-1$), then retrieve the tuple expressed as $(sk,pk,he,e,sv)$ from node $A_{k^{\prime }}$ and invoke ${\mathsf{PBT}}_{\mathsf{RCA}}({\left\{A_j\right\}}_{j=1}^Y,A_k,A_{k^{\prime }})$ to obtain the node set expressed as $\{A_{k^{″}},\dots ,A_1\}$, which represents the sequence of common ancestor nodes of $A_k$ and $A_{k^{\prime }}$, up to the root node $A_1$. The total number of nodes in this set is $he$. Otherwise, continue the loop.

  ii.

  Invoke $\mathsf{PEnc}(pk,\{A_{k^{″}},\dots ,A_1\} \Vert {\mathrm{L}}_{PK})$ to obtain the ciphertext $c{p}_k$, where ${\mathrm{L}}_{PK}$ is a list of public keys corresponding to those stored in the node along the path expressed as ${\left\{A_{j^{‴}}\right\}}_{j^{‴}=1}^L$.

  iii.

  For each non-administrator user ($u_v\in \mathsf{Mem}\setminus \left\{u_i\right\}$) whose identifier is stored in the array ($\mathrm{Map}\left[q\right]$, where q satisfies $k·2^{he-1}\le q\le (k+1)·2^{he-1}-1$), set the control message as $c{m}_v=(prop \Vert c{p}_k \Vert u_a \Vert u_v \Vert u_i \Vert ip)$. Note that the control messages for these users are identical, except for the recipient identifier ($u_v$). Add each message ($c{m}_v$) to the control message set ($\mathsf{CM}$).

  –

  If $prop=\mathrm{REM}$, do the following:

  1.

  Search the array (Map) for an index ($ip$) such that $\mathrm{Map}\left[ip\right]=u_i$. Then, set $\mathrm{Map}\left[ip\right]=⌀$, $n=n-1$ and remove $u_i$ from the $\mathsf{Mem}$ set.

  2.

  Select a random value ($a_r$).

  3.

  Invoke ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,ip,a_r)$ to update the path in the PBT (${\left\{A_j\right\}}_{j=1}^Y$).

  4.

  Generate the corresponding control messages for the other administrators (i.e., $\mathsf{Adm}\setminus \left\{u_a\right\}$) in the same way as Step 4 under the condition of $\mathsf{prop}=\mathsf{ADD}$ in this algorithm.

  5.

  Generate the corresponding control messages for the other group members (i.e., $\mathsf{Mem}\setminus \left\{u_i\right\}$) in the same way as Step 5 under the condition of $\mathsf{prop}=\mathsf{ADD}$ in this algorithm.

  –

  If $\mathit{prop}=\mathrm{UPD}$, do the following:

  1.

  Search the array (Map) for an index ($ip$) such that $\mathrm{Map}\left[ip\right]=u_i$.

  2.

  Obtain the tuple expressed as $(sk,pk,he,e)$ from the node leaf ($A_{{\displaystyle \frac{Y+1}{2}}-1+ip}$).

  3.

  Compute $a_r=\mathsf{PDec}(s{k}_{u_a},txt)$, where $s{k}_{u_a}$ is the private key stored in the node expressed as $A_{{\displaystyle \frac{Y+1}{2}}-1+index}$.

  4.

  Invoke ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,ip,a_r)$ to update the path in the PBT (${\left\{A_j\right\}}_{j=1}^Y$).

  5.

  Generate the corresponding control message for $u_i$, and proceed as follows:

  (a)

  Invoke ${\mathsf{PBT}}_{\mathsf{Path}}({\left\{A_j\right\}}_{j=1}^Y,ip)$ to obtain a path (${\left\{A_{j^{″}}\right\}}_{j^{″}=1}^{L=\lceil {log}_2\left(Y\right)\rceil +1}$).

  (b)

  Set the cipher to $c{p}_i=NULL$.

  (c)

  Add the control message ($c{m}_i=(prop \Vert c{p}_i \Vert u_a \Vert u_i \Vert ip)$) to set $\mathsf{CM}$.

  6.

  Generate the corresponding control messages for the other administrators (i.e., $\mathsf{Adm}\setminus \left\{u_a\right\}$) in the same way as Step 4 under the condition of $\mathsf{prop}=\mathsf{ADD}$ in this algorithm.

  7.

  Generate the corresponding control messages for the other group members (i.e., $\mathsf{Mem}\setminus \left\{u_i\right\}$) in the same way as Step 5 under the condition of $\mathsf{prop}=\mathsf{ADD}$ in this algorithm.

  –

  Compute the updated session key as $rs{k}^{\prime }={\mathsf{H}}_{\mathsf{prg}}(rsk \Vert \overline{A_1})$. Note that ${\mathsf{H}}_{prg}(rsk \Vert \overline{A_1})$ denotes the PRG computation with the concatenation of the session key ($rsk$) and the tuple stored in node $A_1$.

  –

  Update the state (${\gamma }_{u_a}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map}$, $len$, n, ${\left\{A_j\right\}}_{j=1}^Y$, $rs{k}^{\prime }$, $index)$).

• $\mathsf{Process}(gid,u_i,{\gamma }_{u_i}^{gid},cm)\to \left({{\gamma }^{\prime }}_{I{D}_u}^{gid}\right)$: This algorithm is executed by user $u_i$, who is a member of the $gid$ group. It is used to process a control message ($cm$) sent by the group administrator within the $gid$ group for the purpose of updating the user’s local session state. Upon input of $gid$, $u_i$, ${\gamma }_{u_i}^{gid}$, and $cm$, it outputs the updated state (${{\gamma }^{\prime }}_{u_a}^{gid}$). If user $u_i$ receives the control message ($cm$) for the first time, then inputs $gid$ and ${\gamma }_{ID}^{gid}$ are set as ⌀. Suppose that $u_i$ receives the control message ($cm$) from administrator $u_a$ within the $gid$ group and $u_i$ is associated with a key pair $(s{k}_{u_i},p{k}_{u_i})$. $u_i$ then processes $cm$ as follows:

  –

  A $cm$ format of $(\mathrm{Join} \Vert cp \Vert u_a \Vert u_i \Vert \mathsf{Adm} \Vert \mathsf{Mem})$ indicates that $u_i$ is joining group $gid$ for the first time, then proceeds as follows:

  1.

  Invoke $\mathrm{DEnc}(s{k}_{u_i},cp)$ to obtain $({\left\{A_j\right\}}_{j=1}^Y \Vert ip \Vert n \Vert \mathrm{Map} \Vert len)$, where $\mathrm{Map}\left[ip\right]=u_i$.

  2.

  Compute the session key as $rsk$ = ${\mathsf{H}}_{\mathsf{prg}}\left(\overline{A_1}\right)$.

  3.

  If $u_i\in \mathsf{Adm}$, then set $\mathsf{Role}=adm$; otherwise, set $\mathsf{Role}=mem$.

  4.

  Set state ${\gamma }_{u_i}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n,{\left\{A_j\right\}}_{j=1}^Y,rsk,ip)$.

  –

  Otherwise, a $cm$ format of $(\mathrm{Admin} \Vert cp \Vert u_a \Vert u_i \Vert \mathsf{Adm} \Vert {\mathsf{Mem}}^{\prime })$ indicates that $u_i$ is a cloud administrator within the $gid$ group. Suppose $u_i$ possesses a local state of ${\gamma }_{u_i}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n,{\left\{A_j\right\}}_{j=1}^Y,rsk,ip)$. Then, $u_i$ proceeds as follows:

  1.

  Invoke $\mathrm{DEnc}(s{k}_{u_i},cp)$ to obtain (${\left\{A_j^{\prime }\right\}}_{j=1}^Y,le{n}^{\prime },n^{\prime },\mathrm{Map}’$).

  2.

  Compute the session key as $rs{k}^{\prime }$ = ${\mathsf{H}}_{PRG}(rsk \Vert \overline{A_1})$.

  3.

  Set state ${\gamma }_{u_i}^{gid}$ = ($\mathsf{Role},\mathsf{Adm},{\mathsf{Mem}}^{\prime },\mathrm{Map}’,le{n}^{\prime },n^{\prime },{\left\{A_j^{\prime }\right\}}_{j=1}^Y,rs{k}^{\prime },ip$).

  –

  Otherwise, the control message ($cm$) originates from the $gid$ group, which $u_i$ has already joined. Suppose $cm$ has a format of $(prop \Vert cm \Vert u_a \Vert u_i \Vert u_i^{\prime } \Vert ip)$ and user $u_i$ possesses a local state of ${\gamma }_{u_i}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n$, ${\left\{A_j\right\}}_{j=1}^Y$, $rsk$, $index)$. $u_i$ does the following:

  *

  If $prop\in \{\mathrm{ADD}/\mathrm{UPD}/\mathrm{REM}\}$ and $u_i\ne u_i^{\prime }$, another member has either joined the group, updated the group session key, or exited. $u_i$ proceeds as follows:

  1.

  If $prop=\mathrm{ADD}$, then set $\mathrm{Map}\left[ip\right]=u_i^{\prime }$, $n=n+1$ and add $u_i^{\prime }$ to the $\mathsf{Mem}$ set.

  2.

  If $prop=\mathrm{REM}$, then set $\mathrm{Map}\left[ip\right]=⌀$, $n=n-1$ and remove $u_i^{\prime }$ from the $\mathsf{Mem}$ set.

  3.

  Invoke ${\mathsf{PBT}}_{\mathsf{RCA}}({\left\{A_j\right\}}_{j=1}^Y,A_{{\displaystyle \frac{Y+1}{2}}-1+ip},A_{{\displaystyle \frac{Y+1}{2}}-1+index})$ to obtain the node set expressed as $\{A_{lca},\dots ,A_1\}$, which represents the sequence of common ancestor nodes of $A_{{\displaystyle \frac{Y+1}{2}}-1+ip}$ and $A_{{\displaystyle \frac{Y+1}{2}}-1+index}$, up to the root node ($A_1$). $A_{lca}$ is the lowest common ancestor.

  4.

  Obtain the tuple expressed as $(sk,pk,he,e,sv)$ from the child node of $A_{lca}$, which is also an ancestor of $A_{{\displaystyle \frac{Y+1}{2}}-1+\mathit{index}}$.

  5.

  Invoke $\mathsf{PDec}(sk$, $cm)$ to obtain $(\{A_{k^{\prime \prime }},\dots ,A_1\} \Vert {\mathrm{L}}_{pk})$.

  6.

  Replace the nodes in the set expressed as $\{A_{lca},\dots ,A_1\}$, which belong to the PBT ${\left\{A_j\right\}}_{j=1}^Y$, with the corresponding nodes in the set expressed as $\{A_{k^{\prime \prime }},\dots ,A_1\}$.

  7.

  Replace the public keys in the tuples stored in the nodes along the path from the leaf node ($A_{{\displaystyle \frac{Y+1}{2}}-1+\mathit{index}}$) to the root node ($A_1$) with the corresponding public keys in list ${\mathrm{L}}_{pk}$.

  8.

  Compute the updated session key as $rs{k}^{\prime }$ = ${\mathsf{H}}_{PRG}\left(rsk\right||\overline{A_1})$.

  9.

  Set state ${\gamma }_{u_i}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n,{\left\{A_j\right\}}_{j=1}^Y,rs{k}^{\prime },index)$.

  *

  Otherwise, the received control message ($cm$) is the administrator’s response to the proposal message submitted by $u_i$, where $PM=(\mathit{gid} \Vert \mathtt{UPD} \Vert u_a \Vert u_i \Vert \mathit{txt})$, with $\mathit{txt}=\mathsf{PEnc}(p{k}_{u_a},sd)$ and $sd$ being a random value chosen by $u_i$. The message is processed as follows:

  1.

  Invoke ${\mathsf{PBT}}_{\mathsf{Upd}}({\left\{A_j\right\}}_{j=1}^Y,index,sd)$ to update the corresponding path.

  2.

  Compute the updated session key as $rs{k}^{\prime }$ = ${\mathsf{H}}_{PRG}\left(rsk\right||\overline{A_1})$.

  3.

  Set state ${\gamma }_{u_i}^{gid}$ = $(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},len,n,{\left\{A_j\right\}}_{j=1}^Y,rs{k}^{\prime },index)$.

3.2. Design of Smart Contract

A smart contract is a self-executing program deployed on the blockchain, typically written in a Turing-complete programming language such as Solidity, Vyper, or DAML. It consists of variables for data storage and methods that can be invoked by entities to manipulate these variables. Each smart contract has a unique (public) address on the blockchain. All state changes resulting from method invocations are ultimately recorded on all blockchain nodes through the underlying consensus mechanism.

3.2.1. Vehicle Identity Smart Contract (VIDSC)

In our scheme, each RSU deploys and maintains a VIDSC to securely record and manage information about authenticated vehicles that intend to join the VC. The VIDSC is formally defined in Appendix C (see Algorithm A4).

Specifically, the VIDSC contract declares a data structure named VID to store essential vehicle information. This structure contains two fields: CredID, representing the vehicle’s (anonymous) authentication certificate, and Source, describing the vehicle’s sensing or computational capabilities. Additionally, the contract maintains a dynamic array variable, IDList, which stores all registered VIDs.

The contract provides an Upload method invoked by an RSU when a vehicle requests to join a VC (see Section 4.4). The RSU uses the Upload method to store the requesting vehicle’s CredID and Source information in the IDList array on the blockchain.

3.2.2. Vehicular Cloud Smart Contract (VCSC)

We design a VCSC to securely manage essential VC-related data. It is deployed for each VC and maintained by the corresponding cloud administrators. The formal definition of the VCSC is provided in Appendix C (see Algorithm 5).

Specifically, the contract declares several VC-related data (variables): VID, representing the unique identifier of the VC; ADM and MEM, arrays holding the identifiers of cloud administrators and members, respectively; MAP, which records the mapping from PBT leaf nodes to vehicle identifiers; and ProMess, a dynamic array storing proposal messages, along with their processing status.

The contract provides the following functions:

• Update: Invoked by cloud administrators to initialize VC-related variables;
• Upload: Invoked by vehicles or administrators to append new proposal messages;
• Return: Invoked by administrators to retrieve unprocessed proposal messages.

4. Blockchain-Based Dynamic Key Management (BcDKM) Scheme

4.1. High-Level Description

Our proposed blockchain-based dynamic key management (BcDKM) scheme for vehicle cloud (VC) systems consists of several phases: In the Setup phase, the Certification Authority (CA) initializes the entire system by establishing essential system parameters. The subsequent Registration phase involves vehicles and RSUs generating cryptographic keys and registering with the CA to obtain certificates. During the Preparation phase, registered vehicles submit participation requests to local RSUs, which verify and record vehicle information on the blockchain. The Initialization phase allows vehicles to initialize VCs by deploying smart contracts and establishing initial session keys. Finally, the VC Management phase supports dynamic operations such as allowing external vehicles to securely Join an existing VC, enabling current members to securely Remove themselves from a VC, and facilitating secure and dynamic group key Update operations among existing members. An overview of the BcDKM scheme phases is depicted in Figure 2.

4.2. Setup

Upon input of $1^{\kappa }$, the CA performs the following steps:

1.

Invoke the SetUp$\left(\kappa \right)$ algorithm of the CGKAwAM (see Definition 3) to obtain the common system parameters ($csp=(\mathsf{PKE},{\mathsf{H}}_{PRG},psp)$).

2.

Select a digital signature scheme ($\mathsf{DS}=\{\mathsf{DInit},\mathsf{DGen},\mathsf{DSign},\mathsf{DVer}\}$). Invoke $\mathsf{DInit}\left(1^{\kappa }\right)$ to obtain the $dsp$ parameters, and invoke $\mathsf{DGen}\left(dsp\right)$ to generate a key pair $(s{k}_{ca},p{k}_{ca})$ (See Definition 2).

3.

Select a symmetric encryption scheme ($\mathsf{SE}=\{\mathsf{SGen},\mathsf{SEnc},\mathsf{SDec}\}$. Invoke $\mathsf{SGen}(1^{\kappa }$) to generate a secret key (k).

4.

Initialize a blockchain system, denoted as $\mathcal{BC}$, which supports the VCSC for the management of VC-related information and the VIDSC for the recording of information of vehicles willing to join a VC. Those smart contracts are defined in Section 3.2.

5.

Publish the system parameter as $sp$ = $(csp$, $\mathsf{DS}$, $\mathsf{SE}$,$\mathcal{BC}$, $dsp,ssp,p{k}_{ca})$. We assume $sp$ is pre-stored in vehicles and RSUs.

4.3. Registration

Before joining the system, vehicles and RSUs must register with the CA. For a vehicle ($V_i$), let $I{D}_{V_i}$ denote its true identity. Each vehicle uses a unique anonymous certificate when participating in different VCs. Typically, a vehicle can obtain multiple such certificates from the CA during a single registration process. As an example, we describe the process in which a vehicle $V_i$ registers with the CA and obtains one anonymous certificate. The message transmission sequence of this procedure is illustrated in Figure 3a.

1.

$V_i$ invokes $\mathbf{KeyGen}(csp,V_i)$ to generate a private–public key pair, i.e., $K{P}_{V_i}=(s{k}_{V_i},p{k}_{V_i})$, and sends $R{e}_i=I{D}_{V_i} \Vert p{k}_{V_i}$ to the CA via a secure channel. For simplicity, we assume that the key pair is used for both CGKAwAM and digital signature schemes.

2.

Upon receiving $R{e}_i$, the CA does the following:

(a)

Issue an anonymous certificate ($C_{V_i}$ = $(ps{e}_{V_i}$, $p{k}_{V_i}$, $v{p}_{V_i}$, $si{g}_{V_i})$, where $ps{e}_{V_i}$ is a pseudonym generated by the CA by running $\mathsf{SEnc}(k,I{D}_{V_i}\parallel s{n}_i)$, $s{n}_i$ is a serial number, $v{p}_{V_i}$ denotes the validity period, and $si{g}_{V_i}$ is a signature generated by running $\mathsf{DSign}(s{k}_{ca},ps{e}_{V_i} \Vert p{k}_{V_i} \Vert v{p}_{V_i})$).

(b)

Send $C_{V_i}$ to $V_i$ over a secure channel.

3.

$V_i$ can then easily verify the signature ($si{g}_{V_i}\in C_{V_i}$) using the $\mathsf{DVer}$ algorithm and store $C_{V_i}$ locally.

For an RSU ($R_i$), privacy is generally not a concern. RSUs generate their certificates in the same way as vehicles; however, the only difference is that the pseudonym in the certificate is set to the true identity rather than an anonymized identifier. Let $I{D}_{R_i}$ denote the true identity of $R_i$. $R_i$ generates a private–public key pair ($K{P}_{R_i}=(s{k}_{R_i},p{k}_{R_i})$). $R_i$ submits $I{D}_{R_i} \Vert p{k}_{R_i}$ to the CA via a secure channel and obtains a certificate ($C_{R_i}=(I{D}_{R_i},p{k}_{R_i},v{p}_{R_i},si{g}_{R_i})$) issued by the CA.

4.4. Preparation

In this phase, registered vehicles submit participation requests to their local RSUs. The RSUs are responsible for verifying the vehicles’ identities and recording their information for VC admission. As an example, we describe the process in which a vehicle ($V_i$) submits its participation request to RSU $R_i$. Suppose that RSU $R_i$ deploys a contract (${\mathsf{VIDSC}}_{R_i}$) on the blockchain. Let $V_i$ and $R_i$ hold certificates $C_{V_i}$ and $C_{R_i}$ and key pairs $(s{k}_{V_i},p{k}_{V_i})$ and $(s{k}_{R_i},p{k}_{R_i})$, respectively. The message transmission sequence of this procedure is illustrated in Figure 3b. They then proceed as follows:

1.

When $V_i$ enters the area managed by $R_i$, it generates a signature ($S_{V_i}$) on the message expressed as $m_i=(C_{V_i}\parallel V_i\parallel R_i\parallel ts\parallel \mathit{mess})$ using $\mathsf{DSign}(s{k}_{V_i},m_i)$, where $ts$ is a timestamp and $\mathit{mess}$ is the description of $V_i$’s resource information. Then, $V_i$ sends $(S_{V_i},m_i)$ to $R_i$.

2.

Upon receiving $(S_{V_i},m_i)$, $R_i$ does the following:

(a)

Verify the validity of the signature by invoking $\mathsf{DVer}(p{k}_{V_i},m_i,S_{V_i})$. If the signature is invalid, abort; otherwise, invoke the Upload$(C_{V_i},\mathit{mess})$ method (see Section 3.2) within ${\mathsf{VIDSC}}_{R_i}$ to store the vehicle information.

(b)

Generate a signature ($R{v}_{V_i}$) on the message ($m{v}_i=(C_{R_i}\parallel m_i\parallel sc)$) using $\mathsf{DSign}(s{k}_{R_i}$, $m{v}_i)$, where $sc$ is the address of ${\mathsf{VIDSC}}_{R_i}$.

(c)

Send $(R{v}_{V_i},m{v}_i)$ to $V_i$.

3.

$V_i$ can easily verify the validity of the received signature by invoking $\mathsf{DVer}(p{k}_{R_i}$, $m{v}_i$, $R{v}_{V_i})$. Moreover, since the blockchain is public, it is straightforward to check the correctness of the contract address.

4.5. Initialization

Suppose a vehicle ($V_1$) intends to initialize a VC. As an example, assume that it obtains a set of authenticated vehicle identifiers ($G=\{V_1,\dots ,V_n\},n>1$), representing the initial set of authenticated vehicle identities acquired from the nearest RSU. Furthermore, suppose that each vehicle $V_i\in G$ holds a key pair $(s{k}_{V_i},p{k}_{V_i})$ and an anonymous certificate ($C_{V_i}$). The message transmission sequence of this procedure is illustrated in Figure 3c. $V_1$ initializes a VC as follows:

1.

Invoke the Create$(csp,G,V_1)$ algorithm of CGKAwAM (see Section 3) to obtain the initialization local state (${\gamma }_{V_1}^{vid}=(\mathsf{Role},\mathsf{Adm},\mathsf{Mem},\mathrm{Map},\mathit{len},n,{\left\{A_j\right\}}_{j=1}^Y,rsk,\mathit{index},{\mathsf{vcsc}}_{vid})$) and a set of control messages ($\mathsf{CM}$).

2.

Deploy a VCSC smart contract (see Section 3.2.2) for the VC identified by $\mathit{vid}$ via the RSU on the blockchain as follows:

(a)

Deploy the ${\mathsf{VCSC}}_{vid}$ on the blockchain. If the deployment is successful, the RSU returns the contract address (${\mathsf{sc}}_{vid}$); otherwise, the process is aborted.

(b)

Invoke the Update$(vid,\mathrm{Map},\mathsf{Adm},\mathsf{Mem},n)$ method within the ${\mathsf{VCSC}}_{vid}$ contract to initialize the VC-related data (see Section 3.2.2).

3.

Send each control message ($cm\in \mathsf{CM}$) to its corresponding vehicle in $G\setminus \left\{V_1\right\}$, attaching the same ${\mathsf{sc}}_{vid}$ to all messages.

When a vehicle ($V_z\in G\setminus \left\{V_1\right\}$) receives the control message ($cm$) from the cloud administrator ($V_1$), the Process$(gid,V_z,{\gamma }_{V_z}^{vid},cm)$ algorithm of CGKAwAM (see Definition 3) is invoked to obtain the initialization local state (${\gamma }_{V_z}^{vid}$ = $(\mathsf{Role}$, $\mathsf{Adm}$, $\mathsf{Mem}$, Map, $len$, n, ${\left\{A_j\right\}}_{j=1}^Y$, $rsk$, $ip$, ${\mathsf{sc}}_{vid})$).

4.6. VC Management

This subsection describes how cloud members in a created VC are managed. Specifically, a vehicle may Join a VC as a new member, an existing member may Remove itself from a VC, and a member may trigger a group key Update. All three operations follow a unified procedure, where the main difference lies in the command (cmd) type and, in the case of Update, the inclusion of an additional ciphertext ($\mathit{txt}$). The message transmission sequence of this procedure is illustrated in Figure 3d. The generalized procedure is expressed as follows:

1.

A vehicle ($V_u$) invokes the Proposal$(csp,vid,V_u,V_a,\mathtt{cmd},\mathit{txt})$ algorithm of CGKAwAM (see Section 3) to generate a proposal message ($\mathsf{P}=(\mathit{vid} \Vert \mathtt{cmd} \Vert V_a \Vert V_u \Vert \mathit{txt})$). Here, cmd$\in \{\mathtt{ADD},\mathtt{REM},\mathtt{UPD}\}$ correspond to Join, Remove, and Update, respectively. For Join and Remove, $\mathit{txt}=null$, while for Update, $\mathit{txt}=\mathsf{PEnc}(p{k}_{V_a},sd)$, where $sd$ is a random number selected by $V_u$.

2.

$V_u$ uploads message $\mathsf{P}$ to the smart contract (${\mathsf{VCSC}}_{vid}$) through the RSU by invoking the Upload$(\mathsf{P},f)$ method, where $f=0$.

3.

Once message $\mathsf{P}$ has been successfully stored, the RSU notifies the administrator ($V_a$) to handle the message.

4.

$V_a$ invokes the Return(cmd) method within ${\mathsf{VCSC}}_{vid}$ to retrieve $\mathsf{P}$.

5.

$V_a$ runs the Commit$(csp,{\gamma }_{V_a}^{vid},\mathsf{P})$ algorithm of CGKAwAM to update its local state (${\gamma }_{V_a}^{vid}$), yielding a new state (${{\gamma }^{\prime }}_{V_a}^{vid}$) and a set of control messages ($\mathsf{CM}$).

6.

$V_a$ invokes the Update$(vid,\mathrm{Map},\mathsf{Adm},\mathsf{Mem},n)$ method in ${\mathsf{VCSC}}_{vid}$ to update the VC-related data using ${{\gamma }^{\prime }}_{V_a}^{vid}$.

• In the case of Join, $V_u$ is added to the membership set.
• In the case of Remove, $V_u$ is excluded from the membership set.

7.

$V_a$ sends each control message ($cm\in \mathsf{CM}$) to the corresponding vehicles. The recipient set differs slightly depending on the operation:

• Join: all members in $\{G\setminus \left\{V_a\right\}\}\cup \left\{V_u\right\}$;
• Remove: all members in $G\setminus \{V_a,V_u\}$;
• Update: all members in $G\setminus \{V_a,V_u\}$.

Each recipient vehicle ($V_z$) executes the Process$(vid,V_z,{\gamma }_{V_z}^{vid},cm)$ algorithm of CGKAwAM to update its local state accordingly.

It is worth noting that in highly dynamic vehicular networks, temporary disconnections of vehicles are inevitable. Nevertheless, the asynchronous design of our scheme ensures that such disconnections do not hinder the execution of group key updates. Specifically, if a vehicle disconnects after submitting a Proposal message, the administrator continues processing the request and distributes the corresponding Control message to other VC members, who can update the session key locally. The disconnected vehicle may later request the Control message upon reconnection or reinitiate its join request. If a vehicle disconnects before its Proposal message reaches the VC administrator, no session key update is triggered, and the VC remains unchanged. Therefore, both the correctness and security of the group are preserved, even in the presence of frequent disconnections.

5. Security Analysis

This section presents the security analysis of the proposed schemes. First, we formally prove that the CGKAwAM scheme (see Section 3) is secure against adversaries in VC environments and achieves the security properties of known-key security, forward secrecy, and post-compromise security (see Section 2.2), as detailed in Section 5.1. Based on this result, we further demonstrate that the proposed blockchain-based dynamic key management (BcDKM) scheme for VC systems (see Section 4) achieves the intended security goals, as shown in Section 5.2.

5.1. Security Analysis of CGKAwAM

5.1.1. Security Definition and Model

Definition 6

(Game-Based Security Notions). We capture the security of our CGKAwAM through a security game played between an adversary ($\mathcal{A}$) and a challenger ( $\mathcal{C}$). In the security game, $\mathcal{C}$ simulates the execution of the scheme, while $\mathcal{A}$ interacts with the oracles (see Definition 7) maintained by $\mathcal{C}$, through issuing queries (see Definition 8).

Definition 7

(Oracles). We consider μ users (e.g., vehicles), i.e., $V_1,\dots ,V_{\mu }$ in this system. Each user ($V_i$) is represented by a set of oracles, denoted as ${\pi }_{V_i}^s$, which corresponds to the s-th group session that $V_i$ participates in. Furthermore, we use the ${\pi }_{V_i}^s\left[t\right]$ symbol to denote the t-th stage of oracle (group session) ${\pi }_{V_i}^s$, where $s,t\in \mathbb{N}$. A stage corresponds a specific key update within a group session. Each time the group executes a proposal message (e.g., member join, leave, or session key update), a new stage is triggered, and the session key is updated accordingly. For example, ${\pi }_{V_i}^s\left[0\right]$ represents the initial establishment of a group session and the computation of the corresponding initial group session key. Each oracle (${\pi }_{V_i}^s$) has access to the key pair of the $V_i$: $(s{k}_{V_i},p{k}_{V_i})$. The oracle (${\pi }_{V_i}^s$) is associated with a collection of variables (initially set to empty), defined as follows:

• ${\pi }_{V_i}^s.gid$ represents the identifier of the group session (${\pi }_{V_i}^s$).
• ${\pi }_{V_i}^s.role\in \{\mathsf{A},\mathsf{M}\}$ represents the role of $V_i$ in the group session (${\pi }_{V_i}^s$). If ${\pi }_{V_i}^s.role=A$, the user is the administrator; otherwise, the user is the group member.
• ${\pi }_{V_i}^s.uid$ represents the number of stages that have occurred in the group session (${\pi }_{V_i}^s$) since its creation. This variable is used solely within the security model.
• ${\pi }_{V_i}^s\left[t\right].pid$ represents a set containing the identifiers of the users in the group session (${\pi }_{V_i}^s$) at stage t with whom $V_i$ intends to establish a session key, including $V_i$ himself.
• ${\pi }_{V_i}^s\left[t\right].gsk$ represents the group session key associated with the group session (${\pi }_{V_i}^s$) at stage t.
• ${\pi }_{V_i}^s\left[t\right].st\in \{accepted,unaccepted\}$ represents the status associated with group session ${\pi }_{V_i}^s$ at stage t. If the status is accepted, the session key (${\pi }_{V_i}^s\left[t\right].gsk$) has been computed; otherwise, the status is unaccepted.
• ${\pi }_{V_i}^s\left[t\right].sa$ represents the local state associated with group session ${\pi }_{V_i}^s$ at stage t. It corresponds to the γ state in our scheme (see Section 3).
• ${\pi }_{V_i}^s\left[t\right].ms$ represents the messages sent and received in group session ${\pi }_{V_i}^s$ at stage t.

Definition 8

(Query). We formalize the security game using the oracles defined above. During the simulation of the security game, $\mathcal{C}$ allows $\mathcal{A}$ to issue the following queries:

• $Q_{\mathit{Setup}}\left(\kappa \right)$: This query models the Setup algorithm of CGKAwAM. Upon receiving the security parameter (κ), $\mathcal{C}$ simulates the CA to generate the common system parameter ($csp$).
• $Q_{\mathit{KG}}(csp,V_i)$: This query models the KeyGen algorithm of CGKAwAM. Upon receiving the $csp$ and a user identifier ($V_i$) chosen by $\mathcal{A}$, $\mathcal{C}$ returns to $\mathcal{A}$ the key pair ($p{k}_{V_i},s{k}_{V_i}$) associated with the user identified by $V_i$.
• $Q_{\mathit{Create}}(csp,V_a,G)$: This query models the Create algorithm of CGKAwAM. In this query, $\mathcal{A}$ is allowed to select an initial administrator ($V_a$) to cr(eate a VC with a group of users $G=\{V_1,\dots ,V_n\}$, where $V_a\in G$). Then, $\mathcal{C}$ initializes the oracle (${\pi }_{V_a}^s$) and outputs a set of control messages.
• $Q_{\mathit{Prop}}(csp,gid,V_i,V_a,prop,txt)$: This query models the Proposal algorithm of CGKAwAM. In this query, $\mathcal{A}$ is allowed to submit a proposal message ($\mathsf{P}=(gid \Vert prop \Vert V_a \Vert V_i \Vert txt)$), which suggests that the administrator ($V_a$) execute a command ($prop\in \{ADD,REM,UPD\}$). $\mathcal{C}$ then uploads the proposal message to the smart contract.
• $Q_{\mathit{Comm}}(csp,{\pi }_{V_a}^s,\mathsf{P})$: This query models the Commit algorithm of CGKAwAM. In this query, $\mathcal{A}$ is allowed to request the administrator ($V_a$) to execute the proposal message ($\mathsf{P}$) within the session (${\pi }_{V_a}^s$). $\mathcal{C}$ updates the variables associated with the oracle (${\pi }_{V_a}^s$) and outputs a set of control messages.
• $Q_{\mathit{Proc}}(gid,V_i,{\pi }_{V_i}^s,\mathsf{cm})$: This query models the Process algorithm of CGKAwAM. In this query, $\mathcal{A}$ is allowed to request the user ($V_i$) to execute the control message ($\mathsf{cm}$). $\mathcal{C}$ updates the variables associated with the oracle (${\pi }_{V_i}^s$).
• $Q_{\mathit{Rev}}({\pi }_{V_i}^s,t)$: This query models the adversary’s ability to reveal a group session key in session ${\pi }_{V_i}^s$ at stage t. $\mathcal{C}$ returns the group session key (${\pi }_{V_i}^s\left[t\right].gsk$).
• $Q_{\mathit{Cor}}({\pi }_{V_i}^s,t)$: This query models the adversary’s ability to compromise the user ($V_i$) in session ${\pi }_{V_i}^s$ at stage t. $\mathcal{C}$ returns all the values stored in session ${\pi }_{V_i}^s\left[t\right]$ at stage t, except the group session key.
• $Q_{\mathit{Test}}({\pi }_{V_i}^s,t)$: It requires that ${\pi }_{V_i}^s\left[t\right].st=accepted$ and the output of $\mathit{Freshness}({\pi }_{V_i}^s,t)$ be fresh (see Definition 10). If either of these two conditions is not satisfied, the query outputs ⊥. Otherwise, the output of this query is determined as follows: If $b=0$ (where the bit (b) is defined in Definition 9), it outputs ${\pi }_{{\mathrm{ID}}_i}^s\left[t\right].gsk$; otherwise (i.e., $b=1$), it outputs a random session key.

Definition 9

(Security Model). We define our security model through a security game played between an adversary ($\mathcal{A}$) and a challenger ($\mathcal{C}$). In the security game, $\mathcal{C}$ simulates the execution of the scheme using oracles (see Definition 7), while $\mathcal{A}$ interacts with the oracles by issuing queries (see Definition 8). We further define a non-adaptive security model to formalize the security of our scheme. In this model, the adversary ($\mathcal{A}$) is considered non-adaptive, meaning that it must determine all of its queries in advance, before the security game begins. Once the queries are fixed, $\mathcal{A}$ is no longer allowed to modify any query or its target. The security game is defined as follows:

1.

Before $\mathcal{C}$ begins simulating the security game, it chooses a random bit ($b\in \{0,1\}$).

2.

$\mathcal{A}$ outputs a fixed query set of $\mathcal{Q}=\{q_1,\dots ,q_{\alpha }\}$ to $\mathcal{C}$, specifying the exact sequence of queries it intends to issue. Each query ($q_i\in \mathcal{Q}$) corresponds to a specific query type defined in Definition 8. Note that the $Q_{\mathit{Setup}}$ and $Q_{\mathit{Test}}$ queries are each restricted to be issued once, at most.

3.

Once the game begins, $\mathcal{C}$ allows $\mathcal{A}$ to issue only the predefined queries in set $\mathcal{Q}$ and returns the corresponding responses.

4.

After completing all queries, $\mathcal{A}$ outputs a bit ($b^{\prime }\in \{0,1\}$). If $b^{\prime }=b$, we say that $\mathcal{A}$ wins the game. The advantage of $\mathcal{A}$ is defined as ${\mathsf{Adv}}_{\mathcal{A}}=\left|Pr\left[\mathit{Wins}\right]-{\displaystyle \frac{1}{2}}\right|$.

Definition 10

(Freshness). Freshness is used to prevent the adversary from trivially winning the game described in the security model. We define $\mathit{Freshness}({\pi }_{V_i}^s,t)$ as fresh if and only if the following boolean expression holds: $F_1\wedge F_2\wedge F_3\vee F_4=1,$ where $F_1$, $F_2$, $F_3$, and $F_4$ are boolean predicates defined as follows:

1.

$F_1$: If ${\pi }_{V_i}^s\left[t\right].st=\mathit{accepted}$, then set $F_1=1$. Otherwise, set $F_1=0$.

2.

$F_2$: If the adversary has not issued query $Q_{\mathit{Rev}}\left({\pi }_{V_i}^{s}t\right)$ and has not issued $Q_{\mathit{Rev}}$ for any stage that is a partner of ${\pi }_{V_i}^s\left[t\right]$ (see Definition 11), then set $F_2=1$; otherwise, set $F_2=0$. $F_2=1$ ensures that the group session key is not trivially accessible by the adversary and is used to capture the notion of known-key security.

3.

$F_3$: If the adversary has not issued query $Q_{\mathit{Crr}}({\pi }_{V_i}^s,t)$ and has not issued $Q_{\mathit{Crr}}$ for any stage that is a partner of ${\pi }_{V_i}^s\left[t\right]$ (see Definition 11), prior to ${\pi }_{V_i}^s\left[t\right].st=\mathit{accepted}$, and the same condition holds for all related stages with $t>0$, then set $F_3=1$; otherwise, set $F_3=0$. $F_3=1$ is used to capture forward secrecy.

4.

$F_4$: For any $V_j\in {\pi }_{V_i}^s\left[t\right].pid$, if $V_j$ has been queried by $Q_{\mathit{Crr}}$ at any time prior to ${\pi }_{V_i}^s\left[t\right]$, then there must exist a stage (${\pi }_{V_j}^{s^{\prime }}\left[t^{\prime }\right]$) such that

• ${\pi }_{V_j}^{s^{\prime }}\left[t^{\prime }\right].uid<{\pi }_{V_i}^s\left[t\right].uid$, indicating that both stages belong to the same group and that ${\pi }_{V_j}^{s^{\prime }}\left[t^{\prime }\right]$ occurred earlier than ${\pi }_{V_i}^s\left[t\right]$.
• The ${\pi }_{V_j}^{s^{\prime }}\left[t^{\prime }\right]$ stage corresponds to a group key update for $V_j$ initiated via a proposal with a UPD command and successfully executed, without being influenced by the adversary.

If this condition is satisfied for all such $V_j$ values, set $F_4=1$; otherwise, set $F_4=0$. $F_4=1$ is used to capture post-compromise security.

It should be noted that the vehicle ($V_j$) targeted by the query ($Q_{\mathit{Crr}}({\pi }_{V_i}^s,t)$) must not serve as an administrator during the session (i.e., ${\pi }_{V_i}^s\left[t\right].\mathsf{role}\ne \mathsf{A}$).

Definition 11

(Partner Stage). Partner stages refer to a set of stages ($\mathcal{S}=\{{\pi }_{V_i}^s\left[t\right],\dots ,{\pi }_{V_j}^u\left[v\right]\}$) that correspond to the stages held by all members of the same group at a specific point in time. We define the stages in $\mathcal{S}$ to be partner stages of each other if, for any two stages (${\pi }_{V_i}^s\left[t\right],{\pi }_{V_j}^u\left[v\right]$), the following conditions hold:

1.

They have the same status, i.e., ${\pi }_{V_i}^s\left[t\right].st={\pi }_{V_j}^u\left[v\right].st$.

2.

They are associated with the same group identifier, i.e., ${\pi }_{V_i}^s\left[t\right].vid={\pi }_{V_j}^u\left[v\right].vid$.

3.

They share the same participant list, i.e., ${\pi }_{V_i}^s\left[t\right].pid={\pi }_{V_j}^u\left[v\right].pid$.

4.

They correspond to the same update stage of the group, i.e., ${\pi }_{V_i}^s\left[t\right].uid={\pi }_{V_j}^u\left[v\right].uid$.

5.1.2. Security Proof

Theorem 1.

Assume that $\mathsf{PKE}$ is a public-key encryption scheme that is secure under chosen plaintext attacks (CPAs) and that ${\mathsf{H}}_{PRG}$ is a secure pseudorandom generator. Then, for the adversary ($\mathcal{A}$) defined in our non-adaptive security model, the advantage of $\mathcal{A}$ in winning the security game is bounded as follows:

$${\mathsf{Adv}}_{\mathcal{A}}\le (2^d-1)·({\mathsf{Adv}}_{\mathcal{A}}^{\mathit{PRG}}+{\mathsf{Adv}}_{\mathcal{A}}^{\mathit{CPA}})+{\displaystyle \frac{1}{2}}.$$

(1)

where $d=\lceil {log}_2\left(n\right)\rceil +1$ and n denotes the maximum number of users allowed in a group.

For completeness, the full proof of Theorem 1 is presented in Appendix D.

5.2. Security Analysis of the Blockchain-Based Dynamic Key Management (BcDKM) Scheme

This section evaluates the security of our proposed blockchain-based dynamic key management (BcDKM) scheme for VC systems (see Section 4). Specifically, our BcDKM scheme is primarily built upon the CGKAwAM scheme. In addition, it incorporates symmetric encryption and blockchain technology to enhance vehicle privacy and improve the manageability of vehicular clouds (VCs). Symmetric encryption is employed to construct anonymous certificates, with the private key generated and securely maintained by a trusted CA for encryption of the real identities of vehicles. Since this key is known only to the CA, the use of symmetric encryption does not introduce additional security risks. Moreover, to support decentralized VC discovery and management, blockchain technology is leveraged to record VC and vehicle-related information. As outlined in the threat model (see Section 2.2), we assume that the blockchain provides basic security guarantees. Under this assumption, even if an adversary compromises some RSUs functioning as blockchain nodes, it remains infeasible to gain control over the entire blockchain and thereby tamper with VC and vehicle data. Therefore, such attacks do not pose a substantive threat to the security of our scheme. We demonstrate that our BcDKM scheme meets the intended design goals and security requirements, as formally proven in the following theorem. For completeness, detailed proofs of all theorems are provided in Appendix D.

Theorem 2.

The proposed BcDKM scheme satisfies vehicle privacy.

Theorem 3.

The proposed BcDKM scheme satisfies known-key security.

Theorem 4.

The proposed BcDKM scheme satisfies forward secrecy.

Theorem 5.

The proposed BcDKM scheme satisfies post-compromise security.

Theorem 6.

The proposed BcDKM scheme achieves distributed VC discovery.

Theorem 7.

The proposed BcDKM scheme achieves distributed management.

Theorem 8.

The proposed BcDKM scheme achieves round optimality.

Theorem 9.

The proposed BcDKM scheme achieves large-scale VC scalability.

Theorem 10.

The proposed BcDKM scheme supports asynchrony.

6. Performance Analysis

In this section, we comprehensively evaluate the performance of our proposed BcDKM scheme from three perspectives. First, in Section 6.1 (Functional Comparison), we compare the functional characteristics of our scheme with those of several related key management schemes. Next, in Section 6.2 (Computation and Communication Overhead), we provide a theoretical analysis and comparison of the computational and communication costs between our scheme and the benchmark schemes. Finally, in Section 6.3 (Simulation), we conduct simulations to validate the efficiency and practicality of our scheme.

6.1. Functional Comparison

In this section, we compare our scheme with several representative works, focusing on whether they meet the design goals outlined in Section 2.2. Specifically, our primary contribution lies in designing the CGKAwAM group key agreement scheme, and building on this foundation we further develop the BcDKM key management scheme for VC systems. Therefore, when selecting comparison schemes, we primarily consider the representative schemes discussed in Section 1.1 that are either designed for VC systems or serve as potential solutions from different categories of GKM schemes. Specifically, we select AGKA [17], ER-CGKA [22], TGKA [12], and NIGKA [15] as representative GKA-based GKM schemes; GKD [26] as a representative GKD-based GKM scheme; and BcGKM [28] as a recently proposed blockchain-based GKM scheme. AGKA [17] is a bilinear pairing-based group key agreement scheme for vehicular networks, but it requires the group size to be fixed during initialization, which limits scalability. ER-CGKA [22] is built on the CGKA scheme for vehicular scenarios but lacks administrator-driven group management. TGKA [12] is a classical tree-based group key agreement that requires multiple rounds of interaction when group membership changes, resulting in lower communication efficiency. NIGKA [15] is a representative non-interactive group key agreement but only supports static groups with fixed membership. GKD [26] is a key distribution-based scheme for vehicular networks, but it suffers from inherent centralization issues. BcGKM [28] is a recently proposed blockchain-based key management scheme for VCs; however, its key management lacks asynchronous capabilities.

In

Table 1. Comparison of features with those reported in related works.

Property	TGKA [12]	NIGKA [15]	GKD [26]	AGKA [17]	ER-CGKA [22]	BcGKA [28]	Ours
Vehicle privacy	×	×	✓	✓	✓	✓	✓
Known-key security	✓	✓	✓	✓	✓	✓	✓
Forward secrecy	×	×	×	×	✓	×	✓
Post-compromise security	×	×	×	×	✓	×	✓
Distributed VC Discovery	×	×	×	×	×	✓	✓
Distributed Management	×	×	×	×	×	×	✓
Round optimality	✓	✓	×	✓	✓	×	✓
Large-scale VC scalability	×	×	×	×	✓	×	✓

, we compare the features and security properties of the selected schemes, focusing on the following aspects: vehicle privacy, known-key security, forward secrecy, post-compromise security, distributed VC discovery, distributed management, round optimality, and large-scale VC scalability (as described in Section 2.2). In the Table 1, the “✓” symbol indicates the feature is supported, and “×” indicates it is not supported.

As shown in Table 1, all schemes satisfy the fundamental requirement of known-key security. However, TGKA and NIGKA focus solely on cryptographic constructions, without explicit consideration of VC scenarios, and, therefore, do not support vehicle privacy. Only ER-CGKA and our scheme achieve forward secrecy and post-compromise security under active adversaries. In addition, only BcGKA and our scheme leverage blockchain technology, enabling RSUs to act as blockchain nodes for distributed VC discovery; however, only our scheme supports distributed management. GKD and BcGKA require multiple rounds of online interaction for key establishment and updates, failing to achieve round optimality. In contrast, the other schemes require, at most, one round of interaction and inherently support asynchronous operations. Moreover, only ER-CGKA and our scheme exhibit logarithmic computational complexity with respect to the number of VC members, thereby achieving large-scale VC scalability. In summary, our proposed scheme is the only one that fulfills all the desired properties.

6.2. Computation and Communication Overhead

6.2.1. Computation Overhead

In this section, we compare our proposed BcDKM scheme with several recently introduced schemes designed for VC systems, including GKD [26], AGKA [17], and BcGKA [28], as they share similar design goals and requirements.

Table 2. Computation overheads (I).

Scheme	VC Initialization	Join
GKD [26]	$\mathcal{O}\left(N\right)·(9T_{Pm}+10T_H+14T_{Am}+4T_{Mm})$	$(5T_{Pm}+5T_H+7T_{Am}+T_{Mm})$ + $\mathcal{O}\left(N\right)·(3T_{Mm}+T_{Am})$
AGKA [17]	$\mathcal{O}\left(N\right)·(3T_{Pm}+2T_{Mm}+T_{Pa})$ + $\mathcal{O}(N^2+N)·T_{Mm}$ + $2T_{Pa}$	$\mathcal{O}\left(N\right)·(3T_{Pm}+4T_{Mm}+T_{Pa})+2T_{Pa}$
BcGKA [28]	$\mathcal{O}\left(N\right)·(3T_{Pm}+3T_{Mm}+9T_H+\mathcal{O}\left(N\right)·T_{Am})$	$\mathcal{O}\left(N\right)·(T_{Pm}+2T_{Mm}+2T_H)+5T_{Pm}+4T_H+2T_{Am}$
Ours	$\mathcal{O}\left(N\right)·(3T_{Pm}+2T_{Mm}+2T_H)$	$\mathcal{O}\left(N{log}_{2}N\right)·T_H+\mathcal{O}\left({log}_{2}N\right)·(2T_{Pm}+T_{Mm})$ + $\mathcal{O}\left(N\right)·(T_{Pm}+T_{Mm})$

and

Table 3. Computation overheads (II).

Scheme	Remove	Update
GKD [26]	$\mathcal{O}\left(N\right)·(3T_{Mm}+T_{Am})$	$\mathcal{O}\left(N\right)·(3T_{Mm}+T_{Am})$
AGKA [17]	$\mathcal{O}\left(N\right)·(3T_{Mm}+2T_{Pm}+T_{Pa})+2T_{Pa}$	$\mathcal{O}\left(N\right)·(3T_{Pm}+4T_{Mm}+T_{Pa})+2T_{Pa}$
BcGKA [28]	$\mathcal{O}\left(N\right)·(T_{Pm}+2T_{Mm}+2T_H)+5T_{Pm}+4T_H+2T_{Am}$	$\mathcal{O}\left(N\right)·(T_{Pm}+2T_{Mm}+2T_H)+T_H+T_{Am}$
Ours	$\mathcal{O}\left(N{log}_{2}N\right)·T_H+\mathcal{O}\left({log}_{2}N\right)·(2T_{Pm}+T_{Mm})$ + $\mathcal{O}\left(N\right)·(T_{Pm}+T_{Mm})$	$\mathcal{O}\left(N{log}_{2}N\right)·T_H+\mathcal{O}({log}_{2}N+1)·(2T_{Pm}+T_{Mm})$ + $\mathcal{O}\left(N\right)·(T_{Pm}+T_{Mm})$

present a comparison of the total computation overhead incurred by all members during the VC Initialization, Join, Remove, and Update phases.

To facilitate a clearer comparison of computation overheads, we define the following notations and assumptions. We assume that the VC contains N vehicles. We also denote the time costs of various cryptographic operations as follows: $T_{Pm}$ for modular exponentiation, $T_{Am}$ for modular addition, $T_{Mm}$ for modular multiplication, $T_H$ for a hash function, and $T_{Pa}$ for a pairing operation. Since both our schemes employ a public key encryption scheme, we instantiate the PKE component using the ElGamal encryption scheme [33]. Accordingly, the computational cost of a single encryption operation is estimated as $2T_{Pm}+T_{Mm}$, while the decryption cost is $T_{Pm}+T_{Mm}$. In general, the cost of a pairing operation ($T_{Pa}$) significantly exceeds that of other cryptographic operations. It is followed by modular exponentiation $T_{Pm}$, while the remaining operations (e.g., modular addition and hash functions) incur relatively lower computation overhead.

As shown in Table 2 and Table 3, in the VC initialization phase, our BcDKM scheme achieves the lowest computation overhead of $\mathcal{O}\left(N\right)·(3T_{Pm}+2T_{Mm}+2T_K)$, while GKD, AGKA, and BcGKA incur significantly higher costs. Although the GKD scheme exhibits relatively low computation overhead in the VC management phase, it requires $(5T_{Pm}+5T_H+7T_{Am}+T_{Mm})+\mathcal{O}\left(N\right)·(3T_{Mm}+T_{Am})$ for the Join phase and $\mathcal{O}\left(N\right)·(3T_{Mm}+T_{Am})$ for the Remove and Update phases. However, it lacks essential security guarantees, such as forward secrecy and post-compromise security. In addition, the AGKA scheme consistently incurs high computational costs across all phases due to its reliance on a large number of pairing operations ($T_{Pa}$), which are substantially more expensive than other cryptographic primitives.

6.2.2. Communication Overhead

In this section, we compare the communication overhead of our BcDKM scheme with that of GKD [26], AGKA [17], and BcGKA [28].

Table 4. Communication overhead.

Scheme	VC Initialization		Join		Remove		Update
Overhead	Rounds	Messages	Rounds	Messages	Rounds	Messages	Rounds	Messages
GKD [26]	4	$\mathcal{O}\left(N\right)·4$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$
AGKA [17]	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$
BcGKA [28]	2	$\mathcal{O}\left(N\right)·2$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$
Ours	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$	1	$\mathcal{O}\left(N\right)$

summarizes the number of communication rounds and total messages exchanged by all members in a VC during the VC Initialization, Join, Remove, and Update phases. Here, we define one communication round as a single broadcast message sent by a user to all other members in a VC. As shown in Table 4, our scheme achieves optimal communication efficiency in all phases, requiring only one communication round and $\mathcal{O}\left(N\right)$ total messages per phase, which is on par with optimal schemes such as AGKA. In contrast, GKD and BcGKA incur higher communication overhead in the VC Initialization phase.

6.3. Simulation

In this section, we first evaluate the computational overhead of cryptographic operations employed in our scheme, followed by a comparative analysis of the overall runtime efficiency against representative existing schemes. We then assess the gas consumption incurred by the smart contracts used in our scheme to demonstrate its practical feasibility on blockchain platforms. Finally, we simulate the message transmission latency of our scheme under vehicular network scenarios.

6.3.1. Computational Efficiency Evaluation

To evaluate the runtime efficiency of the proposed scheme in a vehicular system, we employed a laptop equipped with an AMD Ryzen 7 4800H 2.90 GHz CPU and 16 GB of memory, running Ubuntu 22.04 OS, as a simulation of the in-vehicle environment. All cryptographic operations were implemented in C/C++ using the Miracl C/C++ library [34]. We adopted the finite-field Diffie–Hellman parameters (ffdhe2048) from RFC 7919 [35] to evaluate the computational costs of $T_{Pm}$, $T_{Am}$, and $T_{Mm}$. For pairing operations ($T_{Pa}$), we used BN curves with 128-bit security. The SHA-256 hash function was used to measure the execution time of hash operations, denoted as $T_H$. The average computation times of these basic operations were obtained through multiple experimental runs and are summarized as follows: $T_{Pm}\approx 1.1$ ms, $T_{Am}\approx 0.0005$ ms, $T_{Mm}\approx 0.0052$ ms, $T_H\approx 0.01$ ms, and $T_{Pa}\approx 3.5$ ms.

In Figure 4, we compare the computation time of our proposed BcDKM scheme with that of GKD [26], AGKA [17], and BcGKA [28] across the four respective phases. Specifically, we evaluate the execution time overhead under varying VC member sizes of 20, 40, 60, 80, and 100. As illustrated in the figures, our scheme and BcGKA exhibit lower computational overhead in the VC initialization phase, whereas GKD and AGKA incur significantly higher costs. Although the GKD scheme shows relatively low overhead during the Join, Remove, and Update phases, it lacks essential security properties, as discussed in Section 6.2. In contrast, our scheme is able to complete all four phases, including VC initialization, Join, Remove, and Update, within 1 s, even when the VC size reaches 100 members. These results demonstrate the practical efficiency and effectiveness of our proposed scheme.

To further assess the practicality of our scheme in vehicular systems, we evaluate its energy consumption. The AMD Ryzen 7 4800H 2.90 GHz CPU has a thermal design power (TDP) of 45 W. The energy consumption during the VC initialization phase, which is the most computationally demanding phase of our scheme, is estimated by multiplying the measured execution time by the assumed power. Figure 5 presents the energy consumption for different VC sizes, reported in joules (J).

6.3.2. Smart Contract Overhead Evaluation

We implemented the VIDSC and VCSC smart contracts described in Section 3.2 using Solidity version 0.8.26 and deployed them on a local Ethereum blockchain instance simulated via Remix [36]. The gas consumption for each contract method is summarized in

Table 5. Gas Consumption.

Method	Deploy	Upload	Update	Return
VIDSC	504,155	91,498	-	-
VCSC	1,246,805	185,560	29,618	25,193

. The “Deploy” method represents the default cost of deploying each contract. For the VIDSC contract, the deployment consumes 504,155 gas, and the Upload method requires 91,498 gas to store the information of a registered vehicle intending to join a VC during the preparation phase of our scheme. The VIDSC contract does not include the Update or Return method, as these functions are not applicable in this contract. In the case of the VCSC contract, the deployment consumes 1,246,805 gas, under the assumption that each instance manages a VC comprising up to 100 vehicles. The Upload method, used to submit proposal messages, incurs a cost of 185,560 gas per invocation. The Update method, which updates the status of a proposal message, consumes 29,618 gas, while the Return method, which retrieves unprocessed proposal messages matching specific commands, requires 25,193 gas. These two methods are specific to the VCSC contract and are not used in VIDSC.

6.3.3. Network Simulation

To evaluate the message transmission latency of the proposed scheme, we conduct network-level simulations using the NS-3 platform (version 3.43) [37]. The simulations are executed on a laptop equipped with an AMD Ryzen 7 4800H 2.90 GHz CPU and 16 GB of memory, running Ubuntu 22.04 OS. The simulated scenario covers a $1.0\times 1.0$ km² network area, where dynamic nodes (simulating vehicles) exchange messages with static nodes (simulating RSUs) over a wireless channel. The communication range of the nodes is set to 400 m, and the channel bandwidth is limited to 6 Mb/s. Dynamic nodes broadcast messages every 100 ms, with mobility patterns randomly generated at an average speed of 50 km/h.

According to our scheme, the application-layer messages exchanged in the network include Proposal messages and Control messages. The maximum size of a Proposal message is approximately 150 bytes, while that of a Control message is about 200 bytes. The message exchange process required for group establishment and dynamic management is outlined as follows. First, a dynamic node (member) sends a Proposal message to a static node. The static node records the message and notifies the corresponding dynamic node (administrator) to process it and generate the associated Control messages, which are then broadcast to all members. Let $P_{DtS}$ denote the latency of a Proposal message from a dynamic node to a static node. Let $P_{StD}$ denote the latency of a Proposal message from a static node to a dynamic node. Let $C_{DtD}$ denote the latency of a Control message exchanged between dynamic nodes. The experimental results indicate that $P_{DtS}\approx 0.35$ ms, $P_{StD}\approx 0.34$ ms, and $C_{DtD}\approx 0.41$ ms, demonstrating that the message transmission delays in our scheme remain within acceptable limits. These measurements allow us to assess the time required for each phase of the scheme under near-realistic wireless communication conditions.

7. Conclusions

In this paper, we proposed a blockchain-based dynamic key management scheme, BcDKM, tailored for VSNs. To support secure and efficient group communication in highly dynamic VC systems, we introduced CGKAwAM, a lightweight extension of the CGKA scheme that enables administrator-driven group management. By integrating CGKAwAM with blockchain technology and smart contracts, the BcDKM scheme achieves decentralized VC discovery/management and asynchronous key updates. We formally proved that the scheme satisfies essential security properties, including key independence, forward secrecy, post-compromise security, and vehicle privacy. Experimental evaluations demonstrated that BcDKM maintains low computational and communication overheads, even for large-scale VCs, and achieves a practical balance between security and performance. These results validate the feasibility and effectiveness of our proposed schemes.