ECACS: An Enhanced Certificateless Authentication Scheme for Smart Car Sharing

Abstract

Driven by the demand for cost-effective vehicle access, enhanced flexibility, and sustainable transportation practices, smart car-sharing has emerged as a prominent alternative to traditional vehicle rental systems. Leveraging the Internet of Vehicles (IoV) and wireless communication, these systems feature dynamic renter-vehicle mappings, enabling users to access any available vehicle rather than being restricted to a specific one pre-assigned by the service provider. However, many existing schemes in the IoV field conflate users and vehicles, complicating the identification and tracking of the vehicle’s actual driver. Moreover, most current authentication protocols rely on a strict, initial binding between a user and a vehicle, rendering them unsuitable for the dynamic nature of car-sharing environments. To address these challenges, we propose an enhanced certificateless signature scheme tailored for smart car-sharing. By employing a biometric fuzzy extractor and the Chinese Remainder Theorem, our scheme provides a fine-grained authentication mechanism that eliminates the need for local computations on the user’s side, meaning users do not require a smartphone or other digital device. Furthermore, our scheme introduces category identifiers to facilitate vehicle selection based on specific classes within car-sharing contexts. A formal security analysis demonstrates that our scheme is existentially unforgeable against adversaries under the random oracle model. Finally, a comprehensive evaluation shows that our proposed scheme achieves competitive performance in terms of computational and communication overhead while offering enhanced practical functionalities.

1. Introduction

The widespread adoption of digital technologies and the development of the Internet of Vehicles (IoV) are driving the transformation of the automotive sector toward intelligent systems [1]. For instance, connected vehicles exchange real-time traffic information through vehicle-to-vehicle communication, while smart parking systems leverage positional data to optimize space allocation. Furthermore, within the framework of intelligent transportation systems, all automotive entities can contribute to optimizing traffic flow and enhancing overall transportation efficiency through global monitoring and data analytics [2,3]. In recent years, driven by the growing demand for cost-effective mobility, smart car-sharing has gained significant traction as an alternative to traditional vehicle rental services [4]. According to a report by Statista Market Insights, global car-sharing revenue is projected to reach approximately USD 13.89 billion in 2025 and is forecast to grow at a compound annual growth rate (CAGR) of 3.23% over the subsequent five-year period [5].

Traditional car rental services require users to book a specific vehicle in advance and retrieve it from a designated depot, a process that is often time-consuming and inconvenient. In contrast, smart car-sharing providers (e.g., Zipcar, Car2Go) offer a more flexible alternative. As illustrated in Figure 1, a typical smart car-sharing workflow begins with vehicles being classified into categories based on their characteristics (e.g., model, capacity) and registered with the service center. After completing registration and payment, users can select any available vehicle within a category that meets their requirements. This model allows individuals to use vehicles on demand, thereby avoiding the costs and responsibilities associated with private car ownership, such as maintenance expenses [6]. Furthermore, compared with public transportation and conventional car rentals, smart car-sharing provides greater flexibility in travel time and destination, as well as more convenient vehicle access [7].

Despite these benefits, communication in IoV environments relies on wireless channels, which are inherently insecure and susceptible to malicious attacks. Consequently, various authentication schemes [8,9,10] have been proposed for the IoV domain to safeguard against threats such as replay [11] and forgery attacks [12]. However, a prevalent limitation of these protocols is their static binding of users to vehicles, which effectively treats the pair as an inseparable entity. This approach is ill-suited for dynamic car-sharing environments. For instance, when malicious behavior occurs, traditional schemes can typically only identify the specific vehicle involved, not the driver. As a result, preventing the malicious user from accessing other vehicles is a challenging and delayed process, as existing authentication protocols incorporate vehicle-specific, rather than user-specific, information in their computations. In a system characterized by rapid user turnover, this oversight creates a significant security vulnerability.

Furthermore, the high turnover of renters for a single vehicle necessitates schemes with dynamic membership management capabilities. Various approaches have been proposed to achieve this functionality, including the use of area keys [13] and Merkle Hash Trees (MHTs) [14]. However, the former approach is computationally expensive due to the need for individual calculations per user, while the latter incurs significant storage overhead because of the hierarchical structure of hash trees. In contrast, the Chinese Remainder Theorem (CRT) enables efficient and lightweight membership management by maintaining and distributing a global shared secret value through broadcasting, demonstrating advantages in both computational efficiency and storage overhead [15]. Nevertheless, current applications of CRT in the IoV field primarily focus on vehicle-side applications. These implementations often require users to perform computations on their personal digital devices, such as smartphones, which can be impractical or inconvenient for renters in real-world scenarios.

In response to the aforementioned challenges, we propose an enhanced CLS scheme that introduces a fine-grained and user-vehicle decoupled authentication mechanism for smart car-sharing scenarios. Specifically, our scheme employs the fuzzy extractor to securely incorporate user biometric information into the authentication process while eliminating the need for user-side computation. Once a user completes the login procedure, the corresponding vehicle generates a signature embedded with a biometric-derived secret, thereby enhancing authenticity by jointly verifying both the user and the vehicle. Additionally, vehicles within the system are classified into categories, with each assigned a unique identifier. This process enables legitimate users to select and access any available vehicle within their chosen category. Furthermore, we integrate the CRT with user-extracted biometric secrets and facilitate the dynamic revocation of renters in cases of service expiration or malicious behavior. The key contributions of the article are outlined as follows:

(1)

We propose an efficient CLS authentication scheme for smart car-sharing scenarios, built upon the fuzzy extractor and the CRT. Compared with existing authentication schemes, our scheme provides decoupled, fine-grained authentication, supports dynamic user revocation, and eliminates computation on the user side.

(2)

We introduce a novel category-range authentication framework where vehicles are organized into distinct categories with unique identifiers. This enables users to access any vehicle within an authorized category, instead of a single specific one in most IoV frameworks, thereby enhancing the flexibility and efficiency of the rental process.

(3)

We conduct a comprehensive security analysis of our scheme and benchmark its performance against related works. The results demonstrate that our proposal achieves provable security and exhibits competitive overhead in terms of computation, communication, and dynamic membership management.

The remainder of this article is structured as follows: Section 2 reviews the existing related works relevant to our proposed scheme. Section 3 introduces the preliminaries, as well as our system and security models. Section 4 elaborates on the details of our proposed scheme. Subsequently, Section 5 presents the formal security analysis and discusses the security properties of our scheme. In Section 6, we evaluate the performance of our proposed scheme and compare it with other existing schemes. Finally, Section 7 concludes the article.

2. Related Works

Digital signature schemes have been widely adopted in the IoV to secure communication processes. In early approaches based on Public Key Infrastructure (PKI) [16,17], certificates and the corresponding public–private key pairs of the vehicles are issued by a trusted certificate authority (CA). Although the implementation of PKI systems enhances the security level of these schemes, the resource-intensive certificate management process remains a significant concern. To mitigate this issue, subsequent protocols leveraged Identity-Based Cryptography (IBC), which eliminates certificate management overhead by employing a trusted Private Key Generator (PKG) to derive public keys directly from identities [18,19,20]. However, the implementation of PKG also introduces the key escrow problem, which can lead to sensitive information exposure and faulty authentication if the PKG in the scheme is compromised and no longer trusted.

To address the key escrow problem, Al-Riyami and Paterson proposed the concept of certificateless public key cryptography (CL-PKC) [21]. By replacing PKG with a semi-trusted key generation center (KGC) and incorporating random numbers selected by users themselves in the key generation process, certificateless signature (CLS) schemes achieve private key confidentiality, as KGC cannot acquire the complete private key of the participants [22].

Built on the framework of CL-PKC, numerous CLS schemes with varying characteristics have been proposed. For instance, Malip et al. [23] proposed a certificateless anonymous authentication scheme designed to facilitate secure message transmission. Zhong et al. [24] introduced a certificateless aggregate signature scheme (CLAS) incorporating pseudonyms to achieve message authentication and conditional privacy preservation. Wang et al. [25] proposed a novel certificateless authentication scheme and demonstrated its security within the standard model. However, the scheme proposed by Wang et al. was subsequently proven to be insecure [26]. Furthermore, the aforementioned schemes are all based on bilinear mapping, which is computationally intensive, raising significant concerns regarding their efficiency.

To reduce the computational overhead associated with bilinear pairings, schemes based on elliptic curve cryptography (ECC) have been widely proposed [27,28,29,30,31,32]. Ali et al. [33] proposed a certificateless authentication scheme utilizing map-to-point hash functions and short signatures. However, Li et al. [34] later identified that the scheme proposed in [33] is vulnerable against Type-II adversaries and subsequently contributed a new reliable CLAS scheme for VANET. Aiming to solve the weakness of the potential side channel attacks against tamper-proof devices, Xiong et al. [35] proposed a double insurance CLS scheme. Unfortunately, Shim [26] later demonstrated that Xiong’s scheme is susceptible to forgery attacks. Following this, Gong et al. [36] introduced a certificateless authentication protocol, asserting its robustness against both Type-I and Type-II adversaries while claiming superiority over prior schemes in [35,37]. Nevertheless, Wu et al. [38] recently concluded that the scheme by Gong et al. [36] also fails to achieve the claimed resistance against forgery attacks by Type-I adversaries. Crucially, in IoV-based car-sharing scenarios, these schemes focus solely on inter-vehicle authentication while neglecting the essential granular authentications required between users and vehicles, thereby rendering them impractical for dynamic car-sharing applications.

In recent years, numerous schemes have sought to enhance the flexibility of users in IoV by incorporating techniques such as passwords and biometric information [39,40]. Islam et al. [41] proposed a password-based authentication protocol for VANETs that supports the dynamic changes in vehicle membership. Later, Cui et al. [42] introduced an authentication scheme based on the Chebyshev chaotic map, incorporating fuzzy verification and honeywords for rescue scenarios. Regarding the application of biometric information, Azees et al. [43] proposed a hybrid CMOS memristor-based authentication scheme employing bilinear operations, ensuring that only registered users can interact with the vehicle. Wang et al. [44] integrated distance calculation into the biometric authentication process and proposed a fuzzy CLS scheme. Despite these advancements, existing approaches maintain a rigid binding between users and vehicles, preventing users from accessing vehicles beyond their specifically assigned ones. Meanwhile, in smart car-sharing scenarios, it is crucial for service providers to allow renters to access vehicles at their convenience.

A comparative summary of existing schemes is presented in

Table 1. Comparative summary of the existing schemes.

Scheme	Technologies	Unforgeability	GA a	DB b
[33]	ECC, Short signature	Type II weak	✕	✕
[34]	ECC, Registration-based encryption	✔	✕	✕
[35]	ECC, Private key double insurance	Type I weak	✕	✕
[36]	ECC, Pseudonym mechanism, Low resource consumption	Type I weak	✕	✕
[41]	ECC, Password-based auth., Vehicle membership alteration	✔	✔	✕
[42]	Chebyshev chaotic map, Fuzzy verification, Honeywords	✔	✔	✕
[43]	Bilinear mapping, CMOS memristor-based auth.	✔	✔	✕
[44]	ECC, Fuzzy extractor, Biometric-based auth.	✔	✔	✕

✔: The scheme satisfies the feature. ✕: The scheme does not satisfy the feature. ^a GA: Granular authentication. ^b DB: Dynamic binding.

. The limitations identified therein highlight the need for a practical authentication scheme that decouples users from specific vehicles, thereby better addressing the operational requirements of real-world car-sharing services.

3. Preliminaries

In this section, we first provide a concise background explanation of elliptic curve cryptography and the Chinese Remainder Theorem. Then, we introduce the system and security models of our proposed authentication scheme. The symbols used in our scheme are described in

Table 2. Symbols and definitions.

Symbol	Definition
$\lambda$	Security parameter
TA	Trust Authority
KGC	Key generation center
${\mathit{SV}}_i$	Sharing vehicle
${\mathit{User}}_j$	User
s	Secret key of KGC
t	Secret key of TA
$params$	System parameters
${\mathit{VID}}_i$	Identity of the vehicle
${\mathit{PVID}}_i$	Pseudonym of the vehicle
${\mathit{UID}}_j$	Identity of the user
${\mathit{PID}}_j$	Pseudonym of the user
${\mathit{PK}}_i$	Public key of the vehicle
$s{k}_i$	Private key of the vehicle
$d_j$	Private key of the user
$gi{d}_i,GI{D}_i$	Category identifier
z	Group identifier
$\sigma$	Signature
$p_j$	Identifier update secret
$T_{\{i,j,z,l,m,r\}}$	Timestamp

.

3.1. Elliptic Curve Cryptography

In the ECC system, an elliptic curve E is defined by the equation $y^2=x^3+ax+bmodp$ over ${\mathbb{F}}_p$, where ${\mathbb{F}}_p$ is a finite field defined on a large prime number p. Here, $a,b\in {\mathbb{F}}_p$, satisfying the condition $4a^3+27b^{2}modp\ne 0$. Furthermore, let O represent a point at infinity; then an additive elliptic curve group $\mathbb{G}$ with order q and the generator P can be defined with O and the points on E.

Elliptic Curve Discrete Logarithm Problem (ECDLP): Given the instance $(P,aP)$, where $a\in Z_q^{\ast }$ and $P\in \mathbb{G}$, it is computationally infeasible to obtain a from $aP$ in probabilistic polynomial time.

3.2. Chinese Remainder Theorem

Let $m_1,m_2,\cdots ,m_n$ be pairwise coprime positive integers, and let $a_1,a_2,\cdots ,a_n$ denote arbitrary integers. Then, the system

$$\left\{\begin{array}{c}x\equiv a_1\left(\mathrm{mod}{m}_1\right)\hfill \\ x\equiv a_2\left(\mathrm{mod}{m}_2\right)\hfill \\ \cdots \hfill \\ x\equiv a_n\left(\mathrm{mod}{m}_n\right)\hfill \end{array}\right.$$

has a unique solution modulo $N={\prod }_{i=1}^n{m}_i$. Specifically, the solution can be expressed as $x\equiv {\sum }_{i=1}^n{a}_i\times {\alpha }_i\times {\beta }_{i}modN$, where ${\alpha }_i={\displaystyle \frac{N}{m_i}}$ and ${\alpha }_i\times {\beta }_i\equiv 1mod{m}_i$.

3.3. System Model

In our proposed scheme, four main participants are involved, namely the TA (trust authority), the KGC (key generation center), the SV (sharing vehicle), and the users.

• TA: It represents the service center in smart car-sharing, which is a fully trusted authority that generates the system parameters and manages the service membership of users within the system by distributing and updating the group identifier. Moreover, it is also responsible for generating pseudonyms for users and can track and reveal their real identities when malicious behaviors occur.
• KGC: It represents a key generation center that generates the partial private keys for vehicles and the private keys for users and is considered to be a semi-trusted third party.
• SV: It represents a vehicle in the car-sharing service. In our scheme, SVs are classified into individual categories based on their characteristics (e.g., model and capacity). After an SV is logged in by a legitimate renter via biometric information, it can authenticate with other verified SVs by generating signatures utilizing the derived group identifier.
• User: It represents the actual user of the car-sharing service. Additionally, it is important to emphasize that no local computational abilities are required for users in our proposed scheme.

The system model of our proposed scheme is demonstrated in Figure 2. Initially, SVs register with KGC to obtain their partial private keys and category identifiers. Subsequently, users complete the registration process by submitting biometric information to TA. When a legitimate user requires access to a vehicle, they may access any vehicle that shares the same category identifier selected during user registration. Upon successful user login, the vehicle can generate signatures to enable secure authentication with other accessed vehicles. In the event that a malicious user is detected, TA will update the group identifier and broadcast the auxiliary information to process revocation, and legitimate vehicles can obtain the updated group identifier using their identifier update secrets derived from the users.

3.4. Security Model

In the field of CLS schemes, two types of attacks are often considered, namely Type-I attacks launched by external adversaries and Type-II attacks launched by internal adversaries [45]. In a Type-I attack, an adversary is able to launch public key replacement attacks but cannot gain access to the master secret key. In contrast, in a Type-II attack, an adversary can acquire the system’s master secret key but cannot replace the public key of any entity.

To demonstrate the security of our proposed scheme, we will prove its existential unforgeability against chosen-message attacks (EUF-CMA). This proof is based on two challenge-response games, each formalizing one of the aforementioned attack scenarios.

Game I: This game is performed by a Type-I adversary ${\mathcal{A}}_1$ and the challenger $\mathcal{C}$. The details are as follows:

Setup: $\mathcal{C}$ runs Setup to generate its master secret key s and the system parameters $params$. Then it sends $params$ to ${\mathcal{A}}_1$ and keeps s secret.

Queries: In this phase, ${\mathcal{A}}_1$ can adaptively access the following queries.

(1)

Vehicle Registration Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, $\mathcal{C}$ generates the related information for the corresponding vehicle.

(2)

User Registration Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ generates the related information for the corresponding user.

(3)

Reveal Vehicle Partial Key Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, $\mathcal{C}$ returns the corresponding $d_i$.

(4)

Reveal User Private Key Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ returns the corresponding $d_j$.

(5)

Reveal Vehicle Secret Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, $\mathcal{C}$ returns the corresponding $x_i$.

(6)

Reveal Vehicle Public Key Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_j$ as input, $\mathcal{C}$ returns the corresponding $(X_i,R_i)$.

(7)

Reveal User Public Key Query: When receiving this query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ returns the corresponding $R_j$.

(8)

Replace Vehicle Public Key Query: When receiving this query from ${\mathcal{A}}_1$ with $({\mathit{PVID}}_i,X_i^{\prime },R_i^{\prime })$ as input, $\mathcal{C}$ replaces the public key of the corresponding vehicle with $X_i^{\prime },R_i^{\prime }$.

(9)

Replace User Public Key Query: When receiving this query from ${\mathcal{A}}_1$ with $({\mathit{PID}}_j,R_j^{\prime })$ as input, $\mathcal{C}$ replaces the public key of the corresponding user with $R_j^{\prime }$.

(10)

Sign Query: When receiving this query from ${\mathcal{A}}_1$ with $({\mathit{PVID}}_i,{\mathit{PID}}_j,m_i)$ as input, $\mathcal{C}$ outputs a legitimate signature ${\sigma }_i$.

Forgery: In this phase, ${\mathcal{A}}_1$ outputs a signature ${\sigma }^{\ast }$ for the tuple $({\mathit{PVID}}_i,{\mathit{PID}}^{\ast },m^{\ast })$, and ${\mathcal{A}}_1$ wins in this game if the following conditions are satisfied.

• Sign Query has never been queried with the submitted tuple.
• Reveal User Private Key Query and Replace User Public Key Query have never been queried with the pseudonym ${\mathit{PID}}^{\ast }$ by ${\mathcal{A}}_1$.
• ${\sigma }^{\ast }$ is a valid signature for the submitted tuple.

Game II: This game is performed by a Type-II adversary ${\mathcal{A}}_2$ and the challenger $\mathcal{C}$. The details are as follows:

Setup: $\mathcal{C}$ runs Setup to generate its master secret key s and the system parameters $params$. Then it sends $params$ and s to ${\mathcal{A}}_2$.

Queries: In this phase, ${\mathcal{A}}_2$ can adaptively access the following queries.

(1)

Vehicle Registration Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_i$ as input, $\mathcal{C}$ generates the related information for the corresponding vehicle.

(2)

User Registration Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ generates the related information for the corresponding user.

(3)

Reveal User Private Key Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ returns the corresponding $d_j$.

(4)

Reveal Vehicle Secret Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_i$ as input, $\mathcal{C}$ returns the corresponding $x_i$.

(5)

Reveal Vehicle Public Key Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_j$ as input, $\mathcal{C}$ returns the corresponding $(X_i,R_i)$.

(6)

Reveal User Public Key Query: When receiving this query from ${\mathcal{A}}_2$ with ${\mathit{PID}}_j$ as input, $\mathcal{C}$ returns the corresponding $R_j$.

(7)

Sign Query: When receiving this query from ${\mathcal{A}}_2$ with $({\mathit{PVID}}_i,{\mathit{PID}}_j,m_i)$ as input, $\mathcal{C}$ outputs a legitimate signature ${\sigma }_i$.

Forgery: In this phase, ${\mathcal{A}}_2$ outputs a signature ${\sigma }^{\ast }$ for the tuple $({\mathit{PVID}}^{\ast },{\mathit{PID}}_j,m^{\ast })$, and ${\mathcal{A}}_2$ wins in this game if the following conditions are satisfied.

• Sign Query has never been queried with the submitted tuple.
• Reveal Vehicle Secret Query has never been queried with the pseudonym ${\mathit{PVID}}^{\ast }$ by ${\mathcal{A}}_2$.
• ${\sigma }^{\ast }$ is a valid signature for the submitted tuple.

4. Proposed Scheme

In this section, we describe our proposed scheme in detail.

4.1. Setup

First, TA and KGC will initialize the system by generating public and secret parameters.

(1)

Given $\lambda$ as the security parameter, TA chooses a cyclic group $\mathbb{G}$ of order q with P as its generator. Then, TA randomly selects $t\in {\mathbb{Z}}_q^{\ast }$ and calculates $T_{pub}=t·P$.

(2)

Then, TA selects five secure hash functions: $H_0:\mathbb{G}\times {\{0,1\}}^{\ast }\to {\mathbb{Z}}_q^{\ast }$, $H_1:{\{0,1\}}^{\ast }\times {\mathbb{G}}^3\to {\mathbb{Z}}_q^{\ast }$, $H_2:{\{0,1\}}^{\ast }\times {\mathbb{G}}^2\times {\{0,1\}}^{\ast }\to {\mathbb{Z}}_q^{\ast }$, $H_3:{\{0,1\}}^{\ast }\times {\{0,1\}}^{\ast }\times {\mathbb{G}}^4\times {\{0,1\}}^{\ast }\times {\{0,1\}}^{\ast }\to {\mathbb{Z}}_q^{\ast }$, $H_4:{\{0,1\}}^{\ast }\times {\{0,1\}}^{\ast }\times {\mathbb{G}}^2\times {\{0,1\}}^{\ast }\times {\{0,1\}}^{\ast }\to {\mathbb{Z}}_q^{\ast }$.

(3)

KGC randomly selects $s\in {\mathbb{Z}}_q^{\ast }$ and calculates $P_{pub}=s·P$.

(4)

TA selects n unique prime numbers ${Prime}_{k=1,2,\cdots ,n}$ and calculates ${\varphi }_g={\prod }_{k=1}^{n}Prim{e}_k$. Then, for each ${Prime}_k$, TA calculates ${\alpha }_k={\displaystyle \frac{{\varphi }_g}{{Prime}_k}}$, ${\alpha }_k\times {\beta }_k\equiv 1modPrim{e}_k$, ${\rho }_k={\alpha }_k\times {\beta }_k$ individually.

(5)

Finally, TA calculates $\Omega ={\sum }_{k=1}^n{\rho }_k$ and publishes the system parameters, which are denoted as $params=\{\mathbb{G},q,P,P_{pub},T_{pub},H_0,H_1,H_2,H_3,H_4,\Omega \}$.

4.2. Registration

Every entity, both the SVs and the users, will first complete the registration after system initialization. The registration process includes vehicle registration, user registration, and group identifier distribution.

4.2.1. Vehicle Registration

As demonstrated in Figure 3, when an SV proceeds with registration, it first generates its partial key and transmits its unique identity to KGC. Upon receiving the request, KGC generates the corresponding partial private key and assigns a category identifier to the SV. Later, according to the received information from KGC, SV can complete its public–private key pair.

(1)

A vehicle ${\mathit{SV}}_i$ first randomly selects $x_i\in Z_q^{\ast }$ and calculates $X_i=x_{i}P$. Then, it sends $\{{\mathit{VID}}_i,X_i\}$ to TA through a secure channel, where ${\mathit{VID}}_i$ denotes the unique identifier of ${\mathit{SV}}_i$.

(2)

Upon receiving the request from ${\mathit{SV}}_i$, TA randomly selects $\delta \in Z_q^{\ast }$ and calculates ${\mathit{PVID}}_i={\mathit{VID}}_i\oplus H_0(\delta T_{pub},T_v)$, where $T_v$ is the current timestamp. Consequently, TA transmits ${\mathit{PVID}}_i$ to KGC through a secure channel.

(3)

After receiving information from TA, KGC randomly selects $r_i\in Z_q^{\ast }$ and calculates $R_i=r_{i}P$, $h_{1i}=H_1({\mathit{PVID}}_i,X_i,R_i,P_{pub})$, $d_i=r_i+s{h}_{1i}modq$. Then, based on the characteristics of the vehicle (e.g., model, capacity), KGC assigns an existing or creates a new class identifier $gi{d}_i\in Z_q^{\ast }$ to ${\mathit{SV}}_i$ and transmits $\{d_i,R_i,gi{d}_i\}$ to ${\mathit{SV}}_i$ through a secure channel. Note that every time after a new class identifier $gi{d}_{new}$ is created and assigned, KGC calculates $GI{D}_{new}=gi{d}_{new}P$ and discloses it to all the entities within the system.

(4)

After obtaining the message from KGC, ${\mathit{SV}}_i$ sets its public key as ${\mathit{PK}}_i=(X_i,R_i)$ and its private key as $s{k}_i=(x_i,d_i)$.

4.2.2. User Registration

As presented in Figure 4, when registering, users are required to provide their biometric information. Then, based on the pre-selected category identifier and the pseudonym generated, KGC generates the corresponding credentials, which are consequently encrypted and broadcast to all SVs within the system by TA.

(1)

With the real user identity ${\mathit{UID}}_j$, the target category identifier $GI{D}_j$, and the biometric information $Bi{o}_j$ acquired from ${\mathit{User}}_j$, TA first utilizes the fuzzy extractor to calculate $Gen\left(Bi{o}_j\right)=({\theta }_j,{\tau }_j)$. Then, TA randomly selects $\upsilon \in Z_q^{\ast }$ and calculates ${\mathit{PID}}_j={\mathit{UID}}_j\oplus H_0(\upsilon T_{pub},{\theta }_j\left|\right|T_j)$, where $T_j$ is the current timestamp. Consequently, TA transmits $\{{\mathit{PID}}_j,{\theta }_j,GI{D}_j\}$ to KGC through a secure channel.

(2)

Upon receiving the data of TA, KGC randomly selects $r_j\in Z_q^{\ast }$ and calculates $R_j=r_{j}P$. Then, KGC calculates the credential $d_j=r_j+s{h}_{1j}modq$ for ${\mathit{User}}_j$ and transmits it to TA via a secure channel, where $h_{1j}=H_1({\mathit{PID}}_j,GI{D}_j,R_j,P_{pub})$.

(3)

Next, TA randomly selects $u_j\in Z_q^{\ast }$ and an identifier update secret $p_j\in Z_{prime}$. Then, TA calculates $U_j=u_{j}P$ and $V_j=(d_j\left|\right|p_j) \oplus H_0(u_{j}GI{D}_j,{\theta }_j\left|\right|T_j)$.

(4)

TA calculates ${\varphi }_g\times {\beta }_j\equiv 1mod{p}_j$, ${\rho }_j={\varphi }_g\times {\beta }_j$ and records the parameters in a list L.

(5)

Finally, TA updates ${\varphi }_g$ with ${\varphi }_g^{\prime }={\varphi }_g\times p_j$, $\Omega$ with ${\Omega }^{\prime }=\Omega +{\rho }_j$ and broadcasts $({\mathit{PID}}_j,R_j,{\tau }_j,V_j,U_j,T_j)$ through a public channel.

4.2.3. Group Identifier Distribution

To transmit the latest group identifier to all SVs, TA first randomly selects $w,z\in Z_q^{\ast }$ and calculates $W=wP$, $\zeta =z\Omega$, and $\xi =w+H_2(\zeta ,W,T_{pub},T_z)t$, where $T_z$ denotes the current timestamp. Later, TA broadcasts $(\zeta ,W,\xi ,T_z)$ to all vehicles within the system.

Upon receiving the message from TA, SVs will first check the freshness of the message. Then, they will verify the authenticity of $\zeta$ by checking whether the equation $\xi P=W+H_2(\zeta ,W,T_{pub},T_z)T_{pub}$ holds. If not, the message will be rejected. Otherwise, SVs will accept the broadcast message and store $\zeta$ locally for the subsequent derivation of the group identifier.

4.3. Authentication

By providing the biometric information, registered users can log into any SV within the same pre-selected target category. Subsequently, the authenticated SVs can establish communications with signature generation and verification. The detailed process of the authentication phase is illustrated in Figure 5.

4.3.1. User Login

Suppose that ${\mathit{User}}_j$ is requesting to log in to ${\mathit{SV}}_i$, where the target identifier $GI{D}_j=GI{D}_i$.

(1)

Upon receiving the biometric data $Bi{o}_j$ from ${\mathit{User}}_j$, ${\mathit{SV}}_i$ utilizes the fuzzy extractor to obtain ${\theta }_j=Rep(Bi{o}_j,{\tau }_j)$.

(2)

Next, ${\mathit{SV}}_i$ calculates $d_j\left|\right|p_j=V_j\oplus H_0(gi{d}_i{U}_j,{\theta }_j\left|\right|T_j)$, $h_{1j}^{\prime }=H_1({\mathit{PID}}_j,GI{D}_i,R_j,P_{pub})$ and checks whether the equation $d_{j}P=R_j+h_{1j}^{\prime }{P}_{pub}$ holds. If not, ${\mathit{SV}}_i$ rejects the request. Otherwise, ${\mathit{User}}_j$ succeeds in the login process.

4.3.2. Signing

Prior to generating the signature for message $m_i$, ${\mathit{SV}}_i$ extracts the group identifier from the locally stored $\zeta$ by calculating $z=\zeta mod{p}_j$. Subsequently, ${\mathit{SV}}_i$ proceeds with the signing process, which is detailed as follows:

(1)

${\mathit{SV}}_i$ randomly selects $y_i\in Z_q^{\ast }$ and calculates $Y_i=y_{i}P$.

(2)

${\mathit{SV}}_i$ then acquires the hash values $h_{3i},h_{4i}$ by calculating $h_{3i}=H_3(m_i,EI{D}_{ij},{\mathit{PK}}_i,Y_i,R_j,z,T_i)$ and $h_{4i}=H_4(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,z,T_i)$, where $T_i$ denotes the current timestamp and ${\mathit{EID}}_{ij}={\mathit{PVID}}_i\left|\right|{\mathit{PID}}_j$.

(3)

${\mathit{SV}}_i$ calculates ${\sigma }_i=z^{-1}(y_i+h_{3i}{x}_i+h_{4i}(d_i+d_j))modq$, where $z^{-1}$ denotes the multiplicative inverse of z on $Z_q^{\ast }$.

(4)

Finally, ${\mathit{SV}}_i$ constructs the signature $c_i=({\sigma }_i,Y_i)$ and sends the tuple $(m_i,c_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,R_j,T_i)$ to the receiver.

4.3.3. Verification

Upon receiving the tuple from the sender, ${\mathit{SV}}_i$, a logged-in SV can verify the signature and proceed with authentication.

(1)

Upon receiving the message, vehicle ${\mathit{SV}}_k$ will first check its freshness and will abort it if the timestamp is considered invalid. Then, as mentioned in the signing process, ${\mathit{SV}}_k$ will extract z from $\xi$ stored locally by calculating $z=\zeta mod{p}_l$, where $p_l$ denotes the identifier update secret obtained during the user login phase.

(2)

With the received parameters, ${\mathit{SV}}_k$ calculates $h_{3i}=H_3(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,Y_i,R_j,z,T_i)$ and $h_{4i}=H_4(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,z,T_i)$.

(3)

Finally, ${\mathit{SV}}_k$ checks whether the equation $z{\sigma }_{i}P=Y_i+h_{3i}{X}_i+h_{4i}(R_i+R_j+(h_{1_i}+h_{1j})P_{pub})$ holds. If not, the authentication process fails. Otherwise, ${\mathit{SV}}_k$ accepts $c_i$ as a valid signature from ${\mathit{SV}}_i$.

4.4. User Logout

When the service of ${\mathit{User}}_j$ terminates, ${\mathit{SV}}_i$ erases the credentials and sends a logout notification containing ${\mathit{User}}_j$’s information to TA and KGC. Upon receiving the logout message, TA and KGC generate the new credential and identifier update secret for ${\mathit{User}}_j$ to enable future vehicle usage.

• Upon service termination of ${\mathit{User}}_j$, ${\mathit{SV}}_i$ randomly selects $\kappa \in Z_q^{\ast }$ and calculates $\chi =\kappa P$ and $\iota =\kappa +H_2({\mathit{PID}}_j,\chi ,X_i,T_l)x_i$, where $T_l$ denotes the current timestamp. Then, ${\mathit{SV}}_i$ transmits $({\mathit{PID}}_j,\chi ,\iota ,T_l)$ to TA and KGC. When receiving the message, TA and KGC can verify its authenticity by checking whether the equation $\iota P=\chi +H_2({\mathit{PID}}_j,\chi ,X_i,T_l)X_i$ holds.
• After successful verification, based on the received ${\mathit{PID}}_j$, KGC randomly selects $r_j^{\prime }\in {\mathbb{Z}}_q^{\ast }$ and generates the corresponding credential $d_j^{\prime }$ for ${\mathit{User}}_j$ with operations described in the User registration section, which are then transmitted to TA.
• According to the received information, TA retrieves the relevant parameters from the list L, selects a new identifier update secret $p_j^{\prime }\in Z_{prime}$, and calculates $V_j^{\prime } = (d_j^{\prime }\left|\right|p_j^{\prime }) \oplus H_0(u_j{\mathit{GID}}_j,{\theta }_j\left|\right|T_m)$, where $T_m$ is the current timestamp.
• TA then updates the recorded parameters in list L with ${\rho }_j^{\prime }$, which is calculated based on the newly generated $p_j^{\prime }$.
• Finally, TA updates ${\varphi }_g$ and $\Omega$ with ${\varphi }_{g_{new}}={\varphi }_g\times {\displaystyle \frac{p_j^{\prime }}{p_j}}$, ${\Omega }^{\prime }=\Omega +{\rho }_j^{\prime }-{\rho }_j$, and broadcasts $({\mathit{PID}}_j,R_j^{\prime },{\tau }_j,V_j^{\prime },U_j,T_m)$ via a public channel. Additionally, TA performs the operations described in the Group identifier distribution section to prevent potential illegal access with the outdated group identifier.

4.5. Revocation

Upon the detection of irregular behaviors, TA is responsible for revealing the real identity of the malicious user and revoking the corresponding user from the system by generating a new group identifier. Suppose the user to be revoked is ${\mathit{User}}_r$.

• TA first acquires the corresponding ${\rho }_r$ by searching the maintained list L and updates $\Omega$ by calculating ${\Omega }^{\prime }=\Omega -{\rho }_r$.
• Next, TA randomly selects $z^{\prime },\psi \in Z_q^{\ast }$ and calculates ${\zeta }^{\prime }=z^{\prime }{\Omega }^{\prime }$, $\Psi =\psi P$, and $\nu =\psi +H_2({\zeta }^{\prime },\Psi ,T_{pub},T_r)t$, where $T_r$ denotes the current timestamp.
• TA then broadcasts $({\zeta }^{\prime },\Psi ,\nu ,T_r)$ to all SVs within the system.
• Upon receiving the update message from TA, each SV first checks the timestamp of the message. If the message is fresh, then vehicles will continue to check whether the equation $\nu P=\Psi +H_2({\zeta }^{\prime },\Psi ,T_{pub},T_r)T_{pub}$ holds. If not, then the update process is aborted. Otherwise, a new group identifier can be calculated with $z^{\prime }={\zeta }^{\prime }mod{p}_{user}$, where $p_{user}$ denotes the individual identifier update secret held by each SV within the system.

5. Security Analysis

In this section, we first prove the existential unforgeability of our scheme under the random oracle model. Then, we analyze the security features of our scheme utilizing the defined security model.

5.1. Security Proof

The proofs of Theorem 1 and Theorem 2 are based on a security reduction from the ECDLP, as illustrated in Figure 6. Specifically, we design simulators ${\mathcal{B}}_1$ and ${\mathcal{B}}_2$ to interact with two distinct types of adversaries, ${\mathcal{A}}_1$ and ${\mathcal{A}}_2$, respectively. Given an ECDLP instance $(P,aP)$ provided by the challenger $\mathcal{C}$, the simulator $\mathcal{B}$ engages with the adversary $\mathcal{A}$ in a simulated environment to produce a forged signature. Subsequently, by applying the Forking Lemma [46,47]$, \mathcal{B}$ is able to obtain a second forgery corresponding to a different random oracle query made by $\mathcal{A}$. From these two distinct forgeries, the simulator can extract and output the solution to the given ECDLP instance, thus completing the reduction.

Theorem 1.

With the hardness assumption of the ECDLP, our proposed ECACS scheme realizes EUF-CMA security against Type-I adversaries under the random oracle model.

The following Lemma 1 concludes the proof of Theorem 1.

Lemma 1.

If there exists a Type-I adversary ${\mathcal{A}}_1$ who can successfully forge a valid signature with obvious advantage ${ϵ}_1$, then a simulator ${\mathcal{B}}_1$ can be constructed to solve the ECDLP with non-negligible advantage ${\displaystyle \frac{(e-1){ϵ}_1}{e^2·Q_{ur}\left(Q_{h_4}+Q_{sig}+1\right)}}$, where $Q_{ur}$, $Q_{sig}$, and $Q_{h_4}$ denote the times of User Registration Query, Sign Query, and $H_4$ Query, respectively.

Proof. 

For the proof of Lemma 1, the challenger $\mathcal{C}$ will first set up an ECDLP instance $\{P,aP|a\in Z_p^{\ast }\}$ and send it to ${\mathcal{B}}_1$. Then, ${\mathcal{B}}_1$ will play the following game with ${\mathcal{A}}_1$ in order to acquire the solution to the ECDLP instance. The detailed process is as follows:

Setup: ${\mathcal{B}}_1$ sets $P_{pub}=aP$ and sends the system parameters $\{\mathbb{G},q,P,P_{pub},H_0,H_1,H_2,H_3,H_4,\Omega \}$ to ${\mathcal{A}}_1$. Meanwhile, ${\mathcal{B}}_1$ maintains six lists to record the query results, namely $L_v,L_u,L_1,L_2,L_3,L_4$.

Query Stage: In this stage, ${\mathcal{A}}_1$ will adaptively submit the following queries.

(1)

Hash Query: ${\mathcal{B}}_1$ will respond to the hash queries from ${\mathcal{A}}_1$ as follows:

(a)

$H_1$ Query: When receiving an $H_1$ hash query with $(\mathit{str},\mathit{G},R_i,P_{pub})$, if $(\mathit{str},\mathit{G},R_i,P_{pub},h_{1_i})\in L_1$, ${\mathcal{B}}_1$ returns $h_{1i}$. Otherwise, ${\mathcal{B}}_1$ selects $h_{1_i}\in Z_q^{\ast }$, adds the tuple $(\mathit{str},\mathit{G},R_i,P_{pub},h_{1_i})$ to $L_1$, and then returns $h_{1_i}$. Note that the $\mathit{str}$ and $\mathit{G}$ here generally represent a random string and a point on the defined elliptic curve.

(b)

$H_2$ Query: When receiving an $H_2$ hash query with $(\zeta ,W,P_{pub},T_z)$, if $(\zeta ,W,P_{pub},T_z,h_{2_i})\in L_2$, ${\mathcal{B}}_1$ returns $h_{2_i}$. Otherwise, ${\mathcal{B}}_1$ selects $h_{2_i}\in Z_q^{\ast }$, adds the tuple $(\zeta ,W,P_{pub},T_z,h_{2_i})$ to $L_2$, and then returns $h_{2_i}$.

(c)

$H_3$ Query: When receiving an $H_3$ hash query with $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,Y_i,R_j,z,T_i)$, if the corresponding tuple $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,Y_i,R_j,z,T_i,h_{3_i})\in L_3$, then ${\mathcal{B}}_1$ returns $h_{3_i}$. Otherwise, ${\mathcal{B}}_1$ selects $h_{3_i}\in Z_q^{\ast }$, adds $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,Y_i,R_j,z,T_i,h_{3_i})$ to $L_3$, and then returns $h_{3_i}$.

(d)

$H_4$ Query: When receiving an $H_4$ hash query with $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,z,T_i)$, if the corresponding tuple $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,z,T_i,h_{4_i})\in L_4$, then ${\mathcal{B}}_1$ returns $h_{4_i}$. Otherwise, ${\mathcal{B}}_1$ selects $h_{4_i}\in Z_q^{\ast }$, adds $(m_i,{\mathit{EID}}_{ij},{\mathit{PK}}_i,z,T_i,h_{4_i})$ to $L_4$, and then returns $h_{4_i}$.

(2)

Vehicle Registration Query: When ${\mathcal{B}}_1$ receives a Vehicle Registration Query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, if ${\mathit{PVID}}_i$ exists in $L_v$, ${\mathcal{B}}_1$ returns ⊥. Otherwise, ${\mathcal{B}}_1$ selects $x_i,d_i,gi{d}_i,h_{1_i}\in Z_q^{\ast }$ and calculates $R_i=d_{i}P-h_{1_i}{P}_{pub}$, $X_i=x_{i}P$ and $GI{D}_i=gi{d}_{i}P$. Then, ${\mathcal{B}}_1$ adds $({\mathit{PVID}}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)$ to $L_v$ and $({\mathit{PVID}}_i,X_i,R_i,P_{pub},h_{1_i})$ to $L_1$.

(3)

User Registration Query: When ${\mathcal{B}}_1$ receives a User Registration Query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, if ${\mathit{PID}}_j$ exists in $L_u$, ${\mathcal{B}}_1$ returns ⊥. Otherwise, ${\mathcal{B}}_1$ continues the game as follows:

• If ${\mathit{PID}}_j={\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ selects $r_j,h_{1_i}\in Z_q^{\ast }$ and calculates $R_j=r_{j}P$. Then, ${\mathcal{B}}_1$ adds the tuple $({\mathit{PID}}_j,GI{D}_j,\perp ,R_j)$ to $L_u$ and the tuple $({\mathit{PID}}_j,GI{D}_j,R_j,P_{pub},h_{1_j})$ to $L_1$, where $GI{D}_j$ is selected from the existing records in $L_v$.
• If $\mathit{PID}j\ne {\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ selects $d_j,h_{1_i}\in Z_q^{\ast }$ and calculates $R_j=d_{j}P-h_{1_i}{P}_{pub}$. Then, ${\mathcal{B}}_1$ adds $({\mathit{PID}}_j,GI{D}_j,d_j,R_j)$ to $L_u$ and $({\mathit{PID}}_j,GI{D}_j,R_j,P_{pub},h_{1_j})$ to $L_1$, where $GI{D}_j$ is selected from the existing records in $L_v$.

(4)

Reveal Vehicle Partial Key Query: When ${\mathcal{B}}_1$ receives a Reveal Vehicle Partial Key Query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, if the tuple $(PVI{D}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)\in L_v$, ${\mathcal{B}}_1$ returns the corresponding $d_i$. Otherwise, ${\mathcal{B}}_1$ first executes the Vehicle Registration Query with ${\mathit{PVID}}_i$ as input and then returns the corresponding $d_i$.

(5)

Reveal User Private Key Query: When ${\mathcal{B}}_1$ receives a Reveal User Private Key Query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, if ${\mathit{PID}}_j={\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ aborts the game. Otherwise, ${\mathcal{B}}_1$ continues the game as follows:

• If ${\mathit{PID}}_j\in L_u$, ${\mathcal{B}}_1$ returns the corresponding $d_j$.
• If ${\mathit{PID}}_j\notin L_u$, ${\mathcal{B}}_1$ first executes the User Registration Query and then returns the corresponding $d_j$.

(6)

Reveal Vehicle Secret Query: When ${\mathcal{B}}_1$ receives a Reveal Vehicle Secret Query from ${\mathcal{A}}_1$ with $PVI{D}_i$ as input, ${\mathcal{B}}_1$ returns $x_i$ if $(PVI{D}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)\in L_v$. Otherwise, ${\mathcal{B}}_1$ first executes the Vehicle Registration Query with $PVI{D}_i$ as input and then returns the corresponding $x_i$.

(7)

Reveal Vehicle Public Key Query: When ${\mathcal{B}}_1$ receives a Reveal Public Key Query from ${\mathcal{A}}_1$ with ${\mathit{PVID}}_i$ as input, if $(PVI{D}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)\in L_v$, ${\mathcal{B}}_1$ returns the corresponding $(X_i,R_i)$. Otherwise, ${\mathcal{B}}_1$ first executes the Vehicle Registration Query with ${\mathit{PVID}}_i$ as input and then returns the corresponding $(X_i,R_i)$.

(8)

Reveal User Public Key Query: When ${\mathcal{B}}_1$ receives a Reveal User Public Key Query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, if $({\mathit{PID}}_j,GI{D}_j,d_j,R_j)\in L_u$, ${\mathcal{B}}_1$ returns the corresponding $R_j$. Otherwise, ${\mathcal{B}}_1$ first executes the User Registration Query with ${\mathit{PID}}_j$ as input and then returns the corresponding $R_j$.

(9)

Replace Vehicle Public Key Query: When ${\mathcal{B}}_1$ receives a Replace Vehicle Public Key Query from ${\mathcal{A}}_1$ with $(PVI{D}_i,X_i^{\prime },R_i^{\prime })$ as input, ${\mathcal{B}}_1$ sets $(X_i^{\prime },R_i^{\prime })$ as ${\mathit{PVID}}_i$s new public key and updates the record in $L_v$.

(10)

Replace User Public Key Query: When ${\mathcal{B}}_1$ receives a Replace User Public Key Query from ${\mathcal{A}}_1$ with $({\mathit{PID}}_j,R_j^{\prime })$ as input, ${\mathcal{B}}_1$ sets $R_i^{\prime }$ as ${\mathit{PID}}_j$’s new public key and updates the record in $L_u$.

(11)

Sign Query: When ${\mathcal{B}}_1$ receives a Sign Query from ${\mathcal{A}}_1$ with $({\mathit{PVID}}_i,{\mathit{PID}}_j,m_i)$ as input, ${\mathcal{B}}_1$ first checks whether ${\mathit{PVID}}_i$ and ${\mathit{PID}}_j$ exist in $L_v$ and $L_u$. If not, ${\mathcal{B}}_1$ first executes the Vehicle Registration Query and User Registration Query with the input identities. Then, after acquiring the corresponding records, ${\mathcal{B}}_1$ continues the game as follows:

• If ${\mathit{PID}}_j\ne {\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ selects $z,y_i,h_{3_i},h_{4_i}\in Z_q^{\ast }$ and obtains $h_{1_i}$, $h_{1_j}$ from $L_1$. Then, ${\mathcal{B}}_1$ calculates $Y_i=y_{i}P$, ${\sigma }_i=z^{-1}(y_i+h_{3_i}{x}_i+h_{4_i}(d_i+d_j))$. Then, ${\mathcal{B}}_1$ adds $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,Y_i,R_j,z,T_z,h_{3_i})$ to $L_3$ and $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,z,T_z,h_{4_i})$ to $L_4$, where ${\mathit{EID}}_{ij}=PVI{D}_i\left|\right|{\mathit{PID}}_j$. Finally, ${\mathcal{B}}_1$ returns $({\sigma }_i,Y_i,T_z)$ to ${\mathcal{A}}_1$.
• If ${\mathit{PID}}_j={\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ selects $z,y_i,h_{3_i},h_{4_i}\in Z_q^{\ast }$ and obtains $h_{1_i}$, $h_{1_j}$ from $L_1$. Then, ${\mathcal{B}}_1$ sets ${\sigma }_i=z^{-1}{y}_i$, $Y_i=z{\sigma }_{i}P-h_{3_i}{X}_i-h_{4_i}(R_i+R_j+h_{1_{ij}}{P}_{pub})$, where $h_{1_{ij}}=(h_{1_i}+h_{1_j})$. Then, ${\mathcal{B}}_1$ adds $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,Y_i,R_j,z,T_z,h_{3_i})$ to $L_3$ and $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,z,T_z,h_{4_i})$ to $L_4$, where ${\mathit{EID}}_{ij}={\mathit{PVID}}_i\left|\right|{\mathit{PID}}_j$. Finally, ${\mathcal{B}}_1$ returns $({\sigma }_i,Y_i,T_z)$ to ${\mathcal{A}}_1$.

Forgery Stage: After all the queries have been made and replied to, ${\mathcal{A}}_1$ outputs a forged signature $({\sigma }_1^{\ast },Y_i)$ for the identity-message pair $({\mathit{PVID}}_i,{\mathit{PID}}_j^{\ast },m^{\ast })$. If ${\mathit{PID}}_j^{\ast }\ne {\mathit{PID}}^{\ast }$, ${\mathcal{B}}_1$ outputs ⊥ and aborts the game. Otherwise, according to the Forking Lemma, ${\mathcal{B}}_1$ can rewind the game process and make ${\mathcal{A}}_1$ output another forged signature $({\sigma }_2^{\ast },Y_i)$ by changing the output of $H_4$. Hence, we have

$$\left\{\begin{array}{c}{\sigma }_1^{\ast }=y_i^{\ast }+h_3^{\ast }{x}_i^{\ast }+h_4^{\ast }(d_i^{\ast }+r_j^{\ast }+h_{1_{ij}}^{\ast }a)\hfill \\ {\sigma }_2^{\ast }=y_i^{\ast }+h_3^{\ast }{x}_i^{\ast }+h_4^{{\ast }^{\prime }}(d_i^{\ast }+r_j^{\ast }+h_{1_{ij}}^{\ast }a)\hfill \end{array}\right.$$

From the above equations, ${\mathcal{B}}_1$ outputs $a={\displaystyle \frac{1}{h_{1_{ij}}^{\ast }}}({\displaystyle \frac{{\sigma }_1^{\ast }-{\sigma }_2^{\ast }}{h_4^{\ast }-h_4^{{\ast }^{\prime }}}}-d_i^{\ast }-r_j^{\ast })$ as the solution to the ECDLP instance.

Let $E_1$ denote the event that the game does not abort in the Query Stage, $E_2$ denote the event that the game does not abort in the Forge Stage, and $E_3$ denote the event that ${\mathcal{A}}_1$ successfully outputs two valid forged signatures in the game. Then the advantage of ${\mathcal{B}}_1$ solving the ECDLP instance can be presented with $Pr\left[{ϵ}_{{\mathcal{B}}_1}\right]=Pr[E_1\wedge E_2\wedge E_3]=Pr\left[E_1\right]Pr\left[E_2\right|E_1]Pr\left[E_3\right|E_1\wedge E_2]$. Furthermore, we have $Pr\left[E_1\right]\ge {\left(1-{\displaystyle \frac{1}{Q_{ur}}}\right)}^{(Q_{upk}+Q_{sig})}$, $Pr\left[E_2\right|E_1]\ge {\displaystyle \frac{1}{Q_{ur}}}$, where $Q_{ur}$ denotes the times of User Registration Query, $Q_{upk}$ denotes the times of Reveal User Private Key Query, and $Q_{sig}$ denotes the times of Sign Query.

According to the Forking Lemma, we have $Pr\left[E_3\right|E_1\wedge E_2]\ge (1-{\displaystyle \frac{1}{e}}){\displaystyle \frac{{ϵ}_1}{Q_{h_4}+Q_{sig}+1}}$, where ${ϵ}_1$ represents the advantage that ${\mathcal{A}}_1$ can successfully forge a signature, and $Q_{h_4}$ represents the times of $H_4$ Query.

Therefore, ${\mathcal{B}}_1$’s advantage of solving the ECDLP instance is

$$\begin{array}{cc}\hfill Pr\left[{ϵ}_{{\mathcal{B}}_1}\right]& =Pr[E_1\wedge E_2\wedge E_3]\hfill \\ \hfill & =Pr\left[E_1\right]Pr\left[E_2\right|E_1]Pr\left[E_3\right|E_1\wedge E_2]\hfill \\ \hfill & \ge \left[{\left(1-{\displaystyle \frac{1}{Q_{ur}}}\right)}^{(Q_{upk}+Q_{sig})}\right]{\displaystyle \frac{1}{Q_{ur}}}(1-{\displaystyle \frac{1}{e}}){\displaystyle \frac{{ϵ}_1}{Q_{h_4}+Q_{sig}+1}}\hfill \\ \hfill & \ge {\displaystyle \frac{(e-1){ϵ}_1}{e^2·Q_{ur}\left(Q_{h_4}+Q_{sig}+1\right)}}\hfill \end{array}$$

Thus, if there exists an adversary ${\mathcal{A}}_1$ who can successfully forge a signature with advantage ${ϵ}_1$, then ${\mathcal{B}}_1$ can output the solution to the ECDLP instance with probability ${\displaystyle \frac{(e-1){ϵ}_1}{e^2·Q_{ur}\left(Q_{h_4}+Q_{sig}+1\right)}}$. □

Theorem 2.

With the hardness assumption of the ECDLP, our proposed ECACS scheme realizes EUF-CMA security against Type-II adversaries under the random oracle model.

The following Lemma 2 concludes the proof of Theorem 2.

Lemma 2.

If there exists a Type-II adversary ${\mathcal{A}}_2$ who can successfully forge a valid signature with obvious advantage ${ϵ}_2$, then a simulator ${\mathcal{B}}_2$ can be constructed to solve the ECDLP with non-negligible advantage $(1-{\displaystyle \frac{1}{e}}){\displaystyle \frac{{ϵ}_2}{e·Q_{vr}{Q}_{h_3}}}$, where $Q_{vr}$ and $Q_{h_3}$ denote the times of Vehicle Registration Query and $H_3$ Query, respectively.

Proof. 

For the proof of Lemma 2, the challenger $\mathcal{C}$ will set up an ECDLP instance $\{P,bP|b\in Z_p^{\ast }\}$ and send it to ${\mathcal{B}}_2$. Then, ${\mathcal{B}}_2$ will play the following game with ${\mathcal{A}}_2$ in order to acquire the solution to the ECDLP instance. The detailed process is as follows:

Setup: ${\mathcal{B}}_2$ sets $P_{pub}=sP$ and sends s and the parameters $\{\mathbb{G},q,P,P_{pub},H_0,H_1,H_2,H_3,H_4,\Omega \}$ to ${\mathcal{A}}_2$. Meanwhile, ${\mathcal{B}}_2$ maintains six lists to record the query results, namely $L_v,L_u,L_1,L_2,L_3,L_4$.

Query Stage: In this stage, ${\mathcal{A}}_2$ will adaptively submit the following queries.

(1)

Hash Query: ${\mathcal{B}}_2$ answers the Hash Query the same as in Game I.

(2)

Vehicle Registration Query: When ${\mathcal{B}}_2$ receives a Vehicle Registration Query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_i$ as input, if ${\mathit{PVID}}_i$ exists in $L_v$, ${\mathcal{B}}_1$ returns ⊥. Otherwise, continue the game as follows.

• If ${\mathit{PVID}}_i={\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ selects $r_i,gi{d}_i,h_{1_i}\in Z_q^{\ast }$ and calculates $R_i=r_{i}P$, $GI{D}_i=gi{d}_{i}P$ and $d_i=r_i+h_{1_i}s$. Then, ${\mathcal{B}}_2$ sets $X_i=bP$ and adds the tuple $({\mathit{PVID}}_i,\perp ,X_i,d_i,R_i,gi{d}_i,GI{D}_i)$ to $L_v$ and $({\mathit{PVID}}_i,X_i,R_i,P_{pub},h_{1_i})$ to $L_1$.
• If ${\mathit{PVID}}_i\ne {\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ selects $x_i,r_i,gi{d}_i,h_{1_i}\in Z_q^{\ast }$ and calculates $R_i=r_{i}P$, $X_i=x_{i}P$, $GI{D}_i=gi{d}_{i}P$ and $d_i=r_i+h_{1_i}s$. Then, ${\mathcal{B}}_1$ adds the tuple $({\mathit{PVID}}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)$ to $L_v$ and $({\mathit{PVID}}_i,X_i,R_i,P_{pub},h_{1_i})$ to $L_1$.

(3)

User Registration Query: When ${\mathcal{B}}_1$ receives a User Registration Query from ${\mathcal{A}}_1$ with ${\mathit{PID}}_j$ as input, if ${\mathit{PID}}_j$ exists in $L_u$, ${\mathcal{B}}_1$ returns ⊥. Otherwise, ${\mathcal{B}}_2$ selects $d_j,h_{1_i}\in Z_q^{\ast }$ and calculates $R_j=d_{j}P-h_{1_i}{P}_{pub}$. Then, ${\mathcal{B}}_2$ adds the tuple $({\mathit{PID}}_j,GI{D}_j,d_j,R_j)$ to $L_u$ and the tuple $({\mathit{PID}}_j,GI{D}_j,R_j,P_{pub},h_{1_j})$ to $L_1$, where $GI{D}_j$ is selected from the existing records in $L_v$.

(4)

Reveal User Private Key Query: When ${\mathcal{B}}_2$ receives a Reveal User Private Key Query from ${\mathcal{A}}_2$ with ${\mathit{PID}}_j$ as input, if the tuple $({\mathit{PID}}_j,GI{D}_j,d_j,R_j)\in L_u$, $\mathcal{B}2$ returns the corresponding $d_j$. Otherwise, ${\mathcal{B}}_2$ first executes the User Registration Query with ${\mathit{PID}}_j$ as input and then returns the corresponding $d_j$.

(5)

Reveal Vehicle Secret Query: When ${\mathcal{B}}_2$ receives a Reveal Vehicle Secret Query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_i$ as input, if ${\mathit{PVID}}_i={\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ aborts the game. Otherwise, ${\mathcal{B}}_2$ continues the game as follows:

• If ${\mathit{PVID}}_i\in L_v$, ${\mathcal{B}}_2$ returns the corresponding $x_i$.
• If ${\mathit{PVID}}_i\notin L_v$, ${\mathcal{B}}_2$ first executes the Vehicle Registration Query and then returns the corresponding $x_i$.

(6)

Reveal Vehicle Public Key Query: When ${\mathcal{B}}_2$ receives a Reveal Public Key Query from ${\mathcal{A}}_2$ with ${\mathit{PVID}}_i$ as input, if $({\mathit{PVID}}_i,x_i,X_i,d_i,R_i,gi{d}_i,GI{D}_i)\in L_v$, ${\mathcal{B}}_2$ returns the corresponding $(X_i,R_i)$. Otherwise, ${\mathcal{B}}_2$ first executes the Vehicle Registration Query with ${\mathit{PVID}}_i$ as input and then returns the corresponding $(X_i,R_i)$.

(7)

Reveal User Public Key Query: When ${\mathcal{B}}_2$ receives a Reveal User Public Key Query from ${\mathcal{A}}_2$ with ${\mathit{PID}}_j$ as input, if $({\mathit{PID}}_j,GI{D}_j,d_j,R_j)\in L_u$, ${\mathcal{B}}_2$ returns the corresponding $R_j$. Otherwise, ${\mathcal{B}}_2$ first executes the User Registration Query with ${\mathit{PID}}_j$ as input and then returns the corresponding $R_j$.

(8)

Sign Query: When ${\mathcal{B}}_2$ receives a Sign Query from ${\mathcal{A}}_2$ with $({\mathit{PVID}}_i,{\mathit{PID}}_j,m_i)$ as input, ${\mathcal{B}}_2$ first checks whether ${\mathit{PVID}}_i$ and ${\mathit{PID}}_j$ exist in $L_v$ and $L_u$. If not, ${\mathcal{B}}_2$ first executes the Vehicle Registration Query and User Registration Query with the input identities. Then, after acquiring the corresponding records, ${\mathcal{B}}_2$ continues the game as follows:

• If ${\mathit{PVID}}_j\ne {\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ selects $z,y_i,h_{3_i},h_{4_i}\in Z_q^{\ast }$ and obtains $h_{1_i}$, $h_{1_j}$ from $L_1$. Then, ${\mathcal{B}}_2$ calculates $Y_i=y_{i}P$, ${\sigma }_i=z^{-1}(y_i+h_{3_i}{x}_i+h_{4_i}(d_i+d_j))$. Then, ${\mathcal{B}}_2$ adds $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,Y_i,R_j,z,T_z,h_{3_i})$ to $L_3$ and $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,z,T_z,h_{4_i})$ to $L_4$. Finally, ${\mathcal{B}}_2$ returns $({\sigma }_i,Y_i,T_z)$ to ${\mathcal{A}}_2$.
• If ${\mathit{PVID}}_j={\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ selects $z,y_i,h_{3_i},h_{4_i}\in Z_q^{\ast }$ and obtains $h_{1_i}$, $h_{1_j}$ from $L_1$. Then, ${\mathcal{B}}_2$ sets ${\sigma }_i=z^{-1}{y}_i$ and calculates $Y_i=z{\sigma }_{i}P-h_{3_i}{X}_i-h_{4_i}(R_i+R_j+h_{1_{ij}}{P}_{pub})$, where $h_{1_{ij}}=(h_{1_i}+h_{1_j})$. ${\mathcal{B}}_2$ then adds $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,Y_i,R_j,z,T_z,h_{3_i})$ to $L_3$ and $(m_i,{\mathit{EID}}_{ij},GI{D}_j,{\mathit{PK}}_i,z,T_z,h_{4_i})$ to $L_4$, where ${\mathit{EID}}_{ij}={\mathit{PVID}}_i\left|\right|{\mathit{PID}}_j$. Finally, ${\mathcal{B}}_2$ returns $({\sigma }_i,Y_i,T_z)$ to ${\mathcal{A}}_2$.

Forgery Stage: After all the queries have been made and replied to, ${\mathcal{A}}_2$ outputs a forged signature $({\sigma }_1^{\ast },Y_i)$ for the identity-message pair $({\mathit{PVID}}_i,{\mathit{PID}}_j^{\ast },m^{\ast })$. If ${\mathit{PVID}}_i^{\ast }\ne {\mathit{PVID}}^{\ast }$, ${\mathcal{B}}_2$ outputs ⊥ and aborts the game. Otherwise, according to the Forking Lemma, ${\mathcal{B}}_2$ can rewind the game process and make ${\mathcal{A}}_2$ output another forged signature $({\sigma }_2^{\ast },Y_i)$ by changing the output of $H_3$. Hence, we have

$$\left\{\begin{array}{c}{\sigma }_1^{\ast }=y_i^{\ast }+h_3^{{\ast }^{\prime }}b+h_4^{\ast }(d_i^{\ast }+d_j^{\ast })\hfill \\ {\sigma }_2^{\ast }=y_i^{\ast }+h_3^{\ast }b+h_4^{\ast }(d_i^{\ast }+d_j^{\ast })\hfill \end{array}\right.$$

From the above equations, ${\mathcal{B}}_1$ outputs $b={\displaystyle \frac{{\sigma }_1^{\ast }-{\sigma }_2^{\ast }}{h_3^{\ast }-h_3^{{\ast }^{\prime }}}}$ as the solution to the ECDLP instance.

Let $E_1$ denote the event that the game does not abort in Query Stage, $E_2$ denote the event that the game does not abort in Forge Stage, and $E_3$ denote the event that ${\mathcal{A}}_2$ successfully outputs two valid forged signatures in the game. Then the advantage of ${\mathcal{B}}_2$ solving the ECDLP instance can be presented with $Pr\left[{ϵ}_{{\mathcal{B}}_1}\right]=Pr[E_1\wedge E_2\wedge E_3]=Pr\left[E_1\right]Pr\left[E_2\right|E_1]Pr\left[E_3\right|E_1\wedge E_2]$. Furthermore, we have $Pr\left[E_1\right]\ge {\left(1-{\displaystyle \frac{1}{Q_{vr}}}\right)}^{(Q_{rvs}+Q_{sig}+1)}$, $Pr\left[E_2\right|E_1]\ge {\displaystyle \frac{1}{Q_{vr}}}$, where $Q_{vr}$ denotes the times of Vehicle Registration Query, $Q_{rvs}$ denotes the times of Reveal Vehicle Secret Query, and $Q_{sig}$ denotes the times of Sign Query.

According to the Forking Lemma, we have $Pr\left[E_3\right|E_1\wedge E_2]\ge (1-{\displaystyle \frac{1}{e}}){\displaystyle \frac{{ϵ}_2}{Q_{h_3}+Q_{sig}+1}}$, where ${ϵ}_2$ represents the advantage that ${\mathcal{A}}_2$ can successfully forge a signature and $Q_{h_3}$ represents the times of $H_3$ Query.

Therefore, ${\mathcal{B}}_2$’s advantage of solving the ECDLP instance is

$$\begin{array}{cc}\hfill Pr\left[{ϵ}_{{\mathcal{B}}_2}\right]& =Pr[E_1\wedge E_2\wedge E_3]\hfill \\ \hfill & =Pr\left[E_1\right]Pr\left[E_2\right|E_1]Pr\left[E_3\right|E_1\wedge E_2]\hfill \\ \hfill & \ge \left[{\left(1-{\displaystyle \frac{1}{Q_{vr}}}\right)}^{(Q_{rvs}+Q_{sig}+1}\right)]{\displaystyle \frac{1}{Q_{vr}}}(1-{\displaystyle \frac{1}{e}}){\displaystyle \frac{{ϵ}_2}{Q_{h_3}+Q_{sig}+1}}\hfill \\ \hfill & \ge {\displaystyle \frac{(e-1){ϵ}_2}{e^2·Q_{vr}(Q_{h_3}+Q_{sig}+1))}}\hfill \end{array}$$

Thus, if there exists an adversary ${\mathcal{A}}_2$ who can successfully forge a signature with advantage ${ϵ}_2$, then ${\mathcal{B}}_2$ can output the solution to the ECDLP instance with probability ${\displaystyle \frac{(e-1){ϵ}_2}{e^2·Q_{vr}(Q_{h_3}+Q_{sig}+1))}}$. □

5.2. Security Features

In particular, our CLS scheme satisfies the following security objectives: message authenticity and integrity, anonymity, traceability, revocability, and resistance against replay and MITM attacks.

5.2.1. Message Authenticity and Integrity

Based on the existential unforgeability proof presented above, it is computationally infeasible for either Type-I or Type-II adversaries to forge a valid signature. Furthermore, since the corresponding identifier update secrets of revoked users are no longer included in $\Omega$, no revoked user can generate a valid signature with any SV due to the inability to extract the latest group identifier z. Consequently, our proposed scheme ensures both the authenticity and integrity of the transmitted message.

5.2.2. Anonymity

In our proposed scheme, the identities utilized by vehicles and users in the authentication process are pseudonyms generated based on their real identities and TA’s secret key t. Consequently, no adversary can obtain the real identity of any entity without access to TA’s secret key. Hence, our proposed scheme achieves anonymity.

5.2.3. Traceability

When emergencies occur, TA can reveal the real identity of any entity by calculating ${\mathit{VID}}_i={\mathit{PVID}}_i\oplus H_0(t{R}_j,T_i)$ or ${\mathit{UID}}_i={\mathit{PID}}_i\oplus H_0(\upsilon T_{pub},{\theta }_j\left|\right|T_j)$. Thus, our proposed scheme meets the requirement of traceability.

5.2.4. Revocability

In the event of a user with unusual behaviors, it is imperative for TA to promptly revoke the user’s ability to process authentication within the system. By updating the group identifier z and distributing it through the application of the Chinese Remainder Theorem, only vehicles authenticated with the current legitimate users can generate valid signatures and perform the verification process. Thus, our proposed scheme effectively supports the revocation feature.

5.2.5. Resistance Against Replay Attacks

In our scheme, the messages transmitted during the signing and verification processes all contain timestamps. Any message that fails to meet the freshness requirements will be rejected. Therefore, our scheme is capable of resisting replay attacks.

5.2.6. Resistance Against MITM Attacks

To launch a man-in-the-middle (MITM) attack, an adversary would first need to forge a valid signature; otherwise, it would not be able to modify the signature it captures. Moreover, based on the existential unforgeability proof provided above, neither Type-I nor Type-II adversaries can forge a valid signature. Therefore, our proposed scheme is resistant to MITM attacks.

6. Performance Evaluation

In this section, we provide the performance comparison between our proposed scheme and the related schemes [48,49,50,51,52,53,54]. Given that practical communications among entities are established over wireless channels, necessitating timely and lightweight information transmission, our evaluation primarily focuses on the calculation time cost and information payload size. Specifically, our evaluation encompasses four key aspects: functional properties, computational overhead, communication overhead, and the revocation feature.

6.1. Experiment Environment

Our experiments are conducted on a Lenovo personal computer (Lenovo Group Ltd., Beijing, China) equipped with an Intel Core i5-9500T 2.20 GHz CPU and 8 GB of RAM. The standard open-source MIRACL Crypto SDK is employed on the Ubuntu 22.04 operating system to implement the cryptographic operations, with the security parameter $\lambda$ set to 128 bits to meet the required security standards. The bilinear pairing operations for pairing-based schemes are performed over a Tate pairing-based curve with an embedding degree of 2, while the scalar operations for ECC-based schemes are executed over the secp256r1 curve. The measured results of the operation time cost are presented in

Table 3. Execution time of cryptographic operations.

Symbol	Meaning	Time (ms)
$T_{bp}$	Bilinear Pairing	27.844
$T_{bpm}$	Pairing-based Scalar Multiplication	9.027
$T_{bpa}$	Pairing-based Point Addition	0.055
$T_{em}$	Scalar Multiplication	2.632
$T_{ea}$	Point Addition	0.018
$T_{htp}$	Hash to Point Operation	5.433
$T_h$	General Secure Hash	0.001

.

6.2. Functional Properties

The comparison results of the functionalities of our proposed scheme with other state-of-the-art relatives are illustrated in

Table 4. Properties of the related schemes.

Scheme	Pairing-Free	Unforgeability	Revocation	User Decoupling	Category Range Selection
[48]	✕	✔	✕	✕	✕
[49]	✔	✔	✔	✕	✕
[50]	✔	✔	✔	✕	✕
[51]	✔	✔	✕	✕	✕
[52]	✔	✕	✕	✕	✕
[53]	✔	✕	✕	✕	✕
[54]	✔	✔	✕	✔	✕
Our scheme	✔	✔	✔	✔	✔

✔: The scheme satisfies the feature. ✕: The scheme does not satisfy the feature.

. While the scheme proposed in [48] achieves unforgeability, its reliance on bilinear pairings incurs substantial computational overhead. Regarding ECC-based schemes, though the schemes proposed in [49,50] support revocation, they overlook the need for a decoupled user authentication phase. The scheme proposed in [54] utilizes passwords and biometric data to realize the authentication processes for users, but it is based on individual relationships between users and vehicles, which lacks the flexibility required in rental scenarios. In contrast, our scheme utilizes the Chinese Remainder Theorem to achieve user revocation. Furthermore, the fuzzy extractor and category identifier mechanism allow our scheme to support both user decoupling and category-range selective authentication. Hence, our scheme demonstrates superior performance under the smart car-sharing situations.

6.3. Computational Overhead

To conduct a comprehensive evaluation, we assess the computational overhead of the schemes by analyzing the time cost associated with signature generation and verification, with the results detailed in

Table 5. Comprehensive overhead comparison with the related schemes.

Scheme	Computational Overhead		Communication Overhead (byte)
	Signature Generation (ms)	Signature Validation (ms)
[48]	$5T_{bpm}+5T_{bpa}+2T_{htp}+2T_h=56.278$	$5T_{bp}+2T_{bpm}+2T_{bpa}+4T_{htp}+2T_h=179.118$	$|2{\mathbb{G}}_1|+3|{\mathbb{Z}}_q^{\ast }|+|T|$
[49]	$4T_{em}+2T_{ea}+4T_h=10.568$	$5T_{em}+3T_{ea}+4T_h=13.218$	$\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$
[50]	$3T_{em}+T_h=7.897$	$5T_{em}+3T_{ea}+T_h=13.215$	$2\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$
[51]	$T_{em}+2T_h=2.634$	$4T_{em}+3T_{ea}+3T_h=10.585$	$\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$
[52]	$T_{em}+T_h=2.633$	$5T_{em}+3T_{ea}+2T_h=13.216$	$\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$
[53]	$T_{em}+2T_h=2.634$	$4T_{em}+3T_{ea}+3T_h=10.585$	$\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$
[54]	$2T_{em}+2T_{ea}+2T_h+T_{htp}=10.735$	$4T_{em}+3T_{ea}+2T_h+T_{htp}=16.017$	$2\left|\mathbb{G}\right|+|{\mathbb{Z}}_q^{\ast }|+|T|$
Our scheme	$T_{em}+2T_h=2.634$	$4T_{em}+4T_{ea}+4T_h=10.604$	$\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|$

and Figure 7.

For our scheme, the signature generation process involves one scalar multiplication operation and two general secure hash operations, and the computational cost is $T_{em}+2T_h=2.634$ ms. As for signature verification, our proposed scheme requires four ECC scalar multiplication operations, four ECC point addition operations, and four general secure hash operations, which cost $4T_{em}+4T_{ea}+4T_h=10.604$ ms. Based on the evaluation, our scheme demonstrates competitive computational efficiency compared with other related schemes. Moreover, our scheme offers additional functionalities, including category-range selection when performing authentication between vehicles and users, as well as the feature of revocation. Therefore, it is reasonable to conclude that our scheme demonstrates outstanding performance in terms of computational overhead.

6.4. Communication Overhead

In our evaluation, we measure the communication overhead of the related schemes based on the length of the transmitted signature tuples. To meet the requirements of the security parameter, we set the size of elements in ${\mathbb{G}}_1$ to 384 bytes, the size of elements in $\mathbb{G}$ to 64 bytes, and the size of elements in ${\mathbb{Z}}_q^{\ast }$ to 32 bytes. Considering schemes implying timestamps to resist replay attacks, we set the size of the timestamps to 4 bytes. The comparison results are presented in Table 5 and Figure 8.

In our proposed scheme, the communication overhead for a signature is $\left|\mathbb{G}\right|+2|{\mathbb{Z}}_q^{\ast }|+|T|=132$ bytes. As demonstrated in Table 5 and Figure 4, our scheme is superior to the schemes in [48,54] and is at the same low overhead level as the schemes in [49,51,52,53]. Moreover, while maintaining communication efficiency, our proposed scheme realizes enhanced functionality that increases its practicality in real-world scenarios. Therefore, our scheme outperforms the related scheme in the field of communication overhead.

6.5. Revocation Feature

Table 6. Comparison of the revocation feature.

Scheme	Support Revocation	Method	Overhead Complexity
[48]	✕	N/A	N/A
[49]	✔	Revocation list	Linear
[50]	✔	Blockchain database	Linear
[51]	✕	N/A	N/A
[52]	✔	Revocation list	Linear
[53]	✕	N/A	N/A
[54]	✕	N/A	N/A
Our scheme	✔	CRT	Constant

✔: The scheme satisfies the feature. ✕: The scheme does not satisfy the feature.

presents a comparative analysis of the revocation feature of our proposed scheme against related schemes. Specifically, the schemes in [48,51,53,54] lack the functionality of revocation. Meanwhile, the schemes in [8,52] implement revocation through the use of revocation lists. However, this approach inherently incurs a linear increase in overhead as the system scales and the number of entities grows. Likewise, the revocation mechanism in [50] requires synchronization with the blockchain database, introducing additional latency while still exhibiting linear growth in resource consumption.

In contrast, our proposed scheme leverages the CRT and achieves revocation by broadcasting the group identifier through public channels, thereby ensuring that revocation efficiency remains independent of system scale. This inherent scalability makes our scheme particularly suitable for large-scale applications.

7. Conclusions

In this paper, we introduced an enhanced certificateless authentication scheme tailored for smart car-sharing environments. By incorporating biometric information and leveraging the Chinese Remainder Theorem for user membership management, our scheme provides a lightweight, decoupled, and fine-grained authentication mechanism between users and vehicles, eliminating the need for user-side computation. The implementation of category identifiers further enhances flexibility, allowing users to access any vehicle within a designated class, which is a feature essential for the dynamic nature of practical car-sharing. A formal security analysis proves our scheme is secure against both Type-I and Type-II adversaries under the random oracle model. Furthermore, performance evaluations demonstrate that our scheme achieves competitive efficiency while delivering significant practical functionalities. Future work will focus on extending this framework to multi-domain environments and developing practical cross-domain authentication protocols.