Efficient Privacy Preserving Anonymous Authentication Announcement Protocol for Secure Vehicular Cloud Network

Abstract

In a Vehicular Cloud (VC) network, an announcement protocol plays a critical role in promoting safety and efficiency by enabling vehicles to disseminate safety-related messages. The reliability of message exchange is essential for improving traffic safety and road conditions. However, verifying the message authenticity could lead to the potential compromise of vehicle privacy, presenting a significant security challenge in the VC network. In contrast, if any misbehavior occurs, the accountable vehicle must be identifiable and removed from the network to ensure public safety. Addressing this conflict between message reliability and privacy requires a secure protocol that satisfies accountability properties while preserving user privacy. This paper presents a novel announcement protocol for secure communication in VC networks that utilizes group signature to achieve seemingly contradictory goals of reliability, privacy, and accountability. We have developed the first comprehensive announcement protocol for VC using group signature, which has been shown to improve the performance efficiency and feasibility of the VC network through performance analysis and simulation results.

1. Introduction

According to the US Department of Transportation (US-DOT), multiple cases of traffic congestion have led to a loss of productivity worth over 75 billion dollars for workers and wastage of more than 8.4 billion gallons of gasoline over the past few years [1]. This has led to a growing interest in the development of secure vehicular communications in the past decade. To address this, researchers have focused on the construction of vehicular ad hoc networks (VANETs) to enable vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications that can improve road safety and traffic efficiency [2-6]. However, VANETs have limited capacity to process, analyze, and evaluate the vast amounts of data generated by vehicles and infrastructure for emerging advanced vehicle technologies [7-8]. Therefore, there has been a proposed shift from traditional VANETs to vehicular cloud (VC) networks.

The concept of vehicular cloud has been evolving with two main paradigms: Vehicular Ad Hoc Network (VANETs) and cloud computing (CC). Cloud computing is a model of distributed computing that provides a range of services to users over the internet, including computing resources, storage, applications, servers, and networks. This technology has attracted a lot of attention from various entities such as governments, research institutes, and industry leaders [2, 10-17]. It has the potential to resolve the computing and storage issues that arise on the internet. The integration of cloud computing with VANETs can enhance road safety and traveling experience. By adopting CC, the computation burden of verifying safety messages on the receiving vehicle can be reduced, as CC offers services on demand to users.

Security and privacy concerns have been a major focus in the development of VC, and several studies have proposed the integration of VANET with cloud computing (CC) [18-25]. Olariu et al. [22] suggested the concept of VC, which refers to a collection of vehicles that collaborate by pooling their computing, sensing, communication, and physical resources that can be assigned to authorized vehicles in a dynamic manner. Similarly, Yan et al. [25] conceptualized VC as the dynamic combination of resources and information while vehicles are in motion.

Announcement protocols in VC broadcast a warning message to nearby vehicles in the network to alert them of a potential safety hazard, such as an accident or road blockage. This ensures that the message is delivered to all nearby vehicles in a timely and reliable manner, and that the authenticity and integrity of the message is verified to prevent any malicious attacks. To utilize the advanced features of VC, safety messages should be delivered in a way that reflects the actual situation while maintaining privacy. Nevertheless, ensuring the reliability of the message may reveal the identity of the sender.

A safety message can be considered trustworthy if it originates from a legitimate vehicle and has not been tampered by any unauthorized adversary. [15]. In VANET it is generally presumed that there are adversaries within the network [2, 3, 5, 26–27]. Adversaries might be insider or outsider. An entity that lacks legitimate access and credentials to engage in the network system is referred to as an outsider. Meanwhile, a legitimate user with current credentials issued by a trusted party (TP) in the network is an insider. An insider may misuse their legitimacy thus impose more harm to other vehicles in the network. We consider the presence of insider in our work.

There are several protocols that address the issues of message reliability, privacy, and accountability in VC networks. A safety message is reliable if and only if satisfy the three requirements:

• The authentic vehicles possess valid credentials issued by a TP (sender’s authenticity).

• The safety message is secured against illegal alteration (message integrity) [44].

• The evaluation of reliability of the safety message (message truthfulness) [2, 5].

The two features of privacy, which are anonymity and unlinkability. Anonymity means that identity of a sender must be protected. When two communications are unlinkable, it signifies that it is impossible to distinguish whether they originate from the same vehicle or not. The accountability requirement must be satisfied to make the network robust and vulnerable against attacks [39]. The misbehaving vehicle may be tracked by the TP in the event of a dispute, and it cannot deny having issued a message. The misbehaving vehicle will be revoked from continuing participation in the network if proven to have misbehaved.

To address the first two requirements of message reliability, digital signature technique is commonly used [18-20, 24, 38, 40, 42-43, 46-47]. Nevertheless, validating the reliability of the message may permit irresponsible entities to track and monitor vehicles for the purpose of profiling. To achieve last requirement of message reliability, one of the techniques is via threshold method. The threshold method is widely adopted in announcement protocols in VANET [2,27,41,44]. In a threshold technique, an announced message is reliable if it was reported by several reputable sender of a particular threshold. The threshold technique, on the other hand, requires a distinguishable message origin so that a verifier may check if the same sender provides two distinct signatures on the same message. However, this is conflicting with privacy. A lack of privacy enables profiling by an adversary which leads to the disclosure of sensitive data. Thus, preserving a privacy of the sender is necessary in a VC network.

To enforce accountability, the VC network must be able to trace the misbehaved vehicle so that a vehicle could not deny as the message originator. However, it contradicts the privacy requirement by opening the signature. The property of revocability is desirable in certain applications. Resolving security conflicts between reliability, privacy and accountability is essential for a secure and efficient announcement protocol in VC network. To address this challenge, we introduce a new announcement protocol for VC that builds upon and extends an existing scheme of [27]. We leverage the latest advancements in VC technology and offer additional benefits such as ease of use, accessibility, and reduced deployment costs [37]. Our protocol is designed with the following desirable features:

• We develop a generic abstraction of a group signature announcement protocol. This generic abstraction intends to serve as a framework for the development of announcement protocols in the future that employ group signature in VC. According to our knowledge, this is the first construction of such an abstraction for VC that has been introduced in the literature.

• We analyse the advantages and disadvantages of the existing literatures, scrutinize the cryptographic primitive adopted in previous work and discuss the elements of security required for a secure deployment of announcement protocol in VC. We then present and propose the first systematic design of an announcement protocol of VC using group signatures and deals with the competing security demands of message reliability, privacy, and accountability simultaneously.

• We provide an analysis and simulation results that demonstrate the practical security level, system robustness, and performance efficiency of our protocol, which can be effectively applied and scaled in real-world implementations.

The structure of the paper is as follows. In Section 2, we discuss the advantages and limitations of current vehicular cloud (VC) schemes, as well as relevant research related to announcement protocols in VC. Section 3 describes the generic announcement construction. Section 4 provides an overview of the WDG scheme that we extend and modify in our work. In Section 5, we introduce and present the proposed announcement protocol. We evaluate the performance and security of our protocol in Section 6. We conclude the paper in Section 7 and provide recommendations for future research directions.

2. Related Work

A number of literatures [18-20, 24, 38, 40, 42-43, 46-47] uses the location-based encryption for announcement protocol in VC network. In these proposed schemes, the reliability of a message is assured by merging geographic and time into conventional encryption algorithm. In [42], the reliability of a message is assured by merging geographic and time into a conventional encryption algorithm. Physical location encryption can provide a way to secure communication by limiting the ability to decrypt the cipher text to a specific geographical area. This method improves security by preventing decryption of the message at any location outside of the specified area, resulting in decryption failure. Therefore, the announcement message would not be broadcasted and utilized. In addition, the issue of privacy and accountability was not addressed in their work.

Yan et al. [24, 38] developed a technique for location-based encryption called Geoencrypt, which builds on prior work [42] and utilizes a symmetric algorithm. This technique uses a vehicle's geographic location to generate a private key that is distributed by the trusted party (TP) to sign messages, thereby fulfilling the first two requirements for message reliability. However, Geoencrypt is not suitable for a threshold mechanism where message origin distinguishability cannot be achieved. To maintain anonymity, the technique employs a pseudonym-changing-based authentication method that regularly changes and updates pseudonyms to keep the identity of the signer hidden. The scheme requires the use of each pseudonym only once or for a limited time based on the desired level of privacy. However, a drawback of this approach is that it necessitates frequent communication between the TP and the vehicles to establish symmetric key authentication each time a vehicle signs a message.

Hussain et al. [18-20] proposed a VANET-based cloud framework called VANET using clouds (VuC) as an improvement over [38]. They introduced geolock encryption, which generates keys based on location information to ensure message authentication through legitimate vehicles with valid credentials from the TP. For privacy, they used identityless beacon messages called Mobility Vectors (MVs) that do not contain any identifiable information linking the sender to the message. However, this approach does not allow for distinguishing the origin of the message, so the threshold mechanism cannot be applied. To achieve accountability, the authors utilized traditional certificate revocation lists (CRLs) to distribute certificate revocation information across the network.

An enhanced identity-based authentication protocol for VC was proposed by Balamesh et al. [40] to improve the efficiency of location-based services while preserving the privacy of a vehicle. It presents anonymous authentication to vehicles and provides dual registration detection. A vehicle adopts pseudo-ID to protect its true identity during a service session. The session key is being kept at different time slots of the service sessions. On the other hand, the involvement of roadside units (RSU) is needed in this scheme to update the session key. From their analysis, they claimed that RSU generate short-time anonymous certificate to each vehicle thus essentially preserve the message linkability. Nonetheless, to authenticate the credential using this approach, frequent communication with the TP is necessary, however the TP might not always be accessible.

Nkenyereye et al. [43] proposed a new security protocol for securing traffic management in VC based on identity-based authentication which is the extension of [18-20]. To create a signature on a message, a tamper proof device (TPD) produces pseudo-identities for each vehicle. Message authentication is satisfied in this case. Due to the indistinguishability of the message's origin, threshold adaptive authentication cannot be used. Various pseudonyms are used to sign communications to ensure anonymity and unlinkability. However, the TP must be entirely trusted because it possesses the private keys to the respective vehicle.

Zhang et al. [46] proposed a dynamic identity-based asymmetric group key agreement scheme for vehicular networks, which involves a one-time pseudonym connected with a vehicle's actual identity. The private key related to the pseudonym, distributed by a trusted party (TP), functions as the vehicle's credential for signing safety messages. The usage of valid credentials from a TP for message signing guarantees message authentication. TP maintains a database for all registered vehicles in the network and can retrieve a vehicle's actual identity if it engages in malicious behavior. The pseudonym guarantees anonymity for the sender, but it cannot differentiate between two messages signed by the same vehicle, making a threshold method implementation unfeasible. Additionally, the scheme suffers from a key escrow problem.

Li et al. [47] proposed a VC security scheme that combines identity-based security and blockchain technology. Under this scheme, each vehicle is assigned a unique identity and uses a group encryption key to sign messages, which provides message authentication. However, the scheme cannot differentiate between messages signed by the same vehicle, making threshold mechanism unfeasible. Short-term anonymous credentials generated by RSU ensure privacy, and TP generates private keys for public keys to enable traceability. However, the paper did not discuss revocability. Additionally, the use of blockchain technology may lead to high communication costs and inefficiencies when there are many vehicles in the network.

Location based encryption requires a receiving vehicle to be physically present to be able to decrypt the message, otherwise message announced would not be utilized. In an announcement scheme, location of an event reported should not be kept private to any receiving vehicle as safety-related messages are often associated to an event of a location in the vicinity of the event reported. This contradicts to the nature of an announcement scheme. The VC schemes in [18-20, 24, 38, 40, 42-43, 46-47] satisfies the requirement of user authentication and message integrity. However, there is no means to evaluate message reliability in all the VC schemes proposed. Thus, threshold method cannot be utilized. In terms of privacy, these VC schemes achieve anonymity and unlikability. The responsibility of accountability is placed on the TP, who is considered a completely reliable entity, and has access to the secret key of the vehicle. Consequently, the concept of non-repudiation is not fulfilled in [18-20, 24, 38, 40, 42-43, 46-47], since the vehicle is not the only one with access to the signing key. Furthermore, matter of revocability was also not addressed in [18-20, 24, 38, 40, 42-43, 46-47].

3. Generic Announcement Construction

3.1 System Structure

The network architecture comprises a cloud-based trusted party (C_TP), roadside units (RSUs), and vehicles consisting of a sending vehicle (Vs) and a receiving vehicle (Vr). The responsibilities of each entity are outlined below:

1) Cloud (C_TP). We utilize a cloud network as a trusted third party (TP) for managing vehicle access and revocation of dishonest vehicles. The cloud is responsible for issuing and managing credentials, as well as detecting and identifying misbehaving vehicles. The cloud is also responsible for verifying the trustworthiness of safety messages, which can help reduce the computational burden for the receiving vehicle (Vr).

2) Road Side Unit. The road side unit (RSU) is a physical infrastructure situated at the side of the road, distributed extensively in metropolitan areas due to high population density. RSUs play a limited role in our protocol, serving as intermediaries for relaying information between vehicles and the cloud via short-range communication. Prior to joining the network, the cloud authenticates and verifies each RSU.

3) Vehicle. In a VC network, there are two types of vehicles, namely sending vehicles (Vs) and receiving vehicles (Vr). Safety-related messages are generated and forwarded by Vs, while Vr utilizes and responds appropriately to the received safety-related messages.

In our network, we assume that every vehicle has an onboard unit (OBU) which is a computing device. The OBU's wireless communication capability includes an Event Data Recorder (EDR) that records received messages. Additionally, the OBU has a Trusted Platform Module (TPM) as a built-in component that employs cryptographic tools and manages access control.

3.2 Generic Abstraction

We formulate a generic abstraction for a group signature announcement protocol in VC. The different stages of the outline are depicted in Fig. 1 and can be summarized as follows:

Fig. 1. Generic Abstraction.

Registration Phase

Step 1: V_s sends a request to obtain a credential from the C_TP in order to join the network.

Step 2: C_TP produces, issues, and stores credentials to verify V_s authenticity in the network.

Step 3: The C_TP provides the credential to V_s upon successful authentication.

Transmission Phase

Step 4: By using RSU, V_s generates and broadcasts a safety message related to the incident to the C_TP.

Step 5: Between the C_TP and the Vs, RSU serves as a gateway, transmitting the safety message for authentication.

Validation Phase

Step 6: C_TP authenticates the reliability of a message.

Step 7: Upon successful verification, the C_TP will deliver the safety related announcement to a nearby RSU that associated to the event reported.

Step 8: RSU broadcast the authenticated safety message to V_r corresponding to the vicinity of event reported.

Step 9: V_r verifies the message and utilize the safety related announcement for a safer and more conducive travelling environment.

Tracking and Revoke Phase

Step 10: If V_r encountered any wrongdoing during its interaction with V_s, they may lodge a report to the C_TP via the nearby RSU.

Step 11: The C_TP evaluates the validity and reliability of the information after receiving reports before considering eliminating V_s from the network.

4. The WDG Construction

Wu, Domingo-Ferrer, and Gonzalez-Nicolas (WDG) introduced a group signature scheme that allows message linkage using bilinear-pairing groups and anonymous threshold authentication. This scheme allows receivers to only accept messages that have been verified by a specific minimum number of anonymous vehicles, which prevents Sybil attacks. The scheme includes three Trusted Parties (TPs): Vehicle Manufacturers (𝒱ℳ), the group registration manager (ℛℳ), and the tracing manager (𝒯ℳ). A vehicle must sign a contract with the 𝒱ℳ to be registered and participate in the network. After being registered to the ℛℳ, the vehicle can access the network and generate a public key Y= 𝑈^𝑦₁ for an arbitary value 𝑦 ∈ ℤ*_𝑝, which is its secret key. To ensure traceability, the tracing data 𝑇 = 𝑔^𝑦₂ is submitted to the 𝒯ℳ during registration. The 𝒱ℳ, ℛℳ, and 𝒯ℳ are assumed to be trustworthy as they have no access to the vehicle's private keys. ℛℳ provides a signature to the vehicle's public key after successful network registration, which is used by the vehicle as a group certificate to disseminate safety messages. The objective of the WDG scheme is to achieve a balance between ensuring public safety and maintaining the privacy of the vehicles. Table 1 shows some of the notations used in the protocol adapted from [27] for ease of reading throughout the paper.

Table 1. Table of Symbol and Notation

5. Our Secure Announcement Protocol

5.1 Proposed Model

The system is composed of four main components, namely the cloud which acts as the TP, RSUs, and vehicles (𝒱_𝑠 and 𝒱_𝑟). To join the network, a vehicle establishes a secure channel with the cloud and receives valid credentials during the registration process to prove its authenticity. RSUs play a crucial role in transmitting information between the cloud and vehicles, and in distributing successfully validated safety messages to 𝒱_𝑟 in the vicinity of the reported incident. The cloud performs computations and verifies the validity of safety messages, while 𝒱_𝑟 uses the reliability of the received messages to authenticate secure cloud-based communication. Our protocol considers the insider threat, as insiders can attack other vehicles using their legitimate access. The threat posed by outsiders is not considered as they are less of a risk to other vehicles, and they do not possess legitimate credentials or direct network access. We assume the cloud is reliable since it cannot access a vehicle's private key. The protocol is designed to utilize the presence of cloud providers in each region, with the cloud being linked to a number of grids that divide the traffic area. A grid of a traffic area is illustrated in Fig. 2.

Fig. 2. Grids that represent a traffic area.

5.2 The Setup

In the setup, system parameters and credentials for the entities in the system were generated. We describe the setup of the cloud and vehicles as follow:

5.2.1 Computational Assumption and System Setup

The algorithm is based on bilinear pairing and takes input a security parameter ∄ , and outputs a public parameter 𝛶 = (𝑝,𝔾₁,𝔾₂,𝔾₃,𝑔₁,𝑔₂,𝑒). Let 𝔾₁ and 𝔾₂ be a finite cyclic group, respectively, of the same prime order, 𝑝. Assume 𝔾₁ = 〈𝑔₁〉 and 𝔾₂ = 〈𝑔₂〉 and 𝑒: 𝔾₁ × 𝔾₁ → 𝔾₂ is an efficient non-degenerate bilinear map such that 𝑒(𝑔₁, 𝑔₂) ≠ 1 and for all ℎ₁ ∈ 𝔾₂ and ℎ₂ ∈ 𝔾₁. Our computational assumption relies upon on Decisional Diffie-Hellman (DDH) assumption and the Diffie-Hellman Knowledge (DHK) assumption [43]. The DDH hold in 𝔾₁ where 𝑔, 𝑔^𝑎, 𝑔^𝑏, 𝑔^𝑐 ∈ 𝔾₄ such that 𝑎, 𝑏, 𝑐 ∈ ℤ*_𝑝 for any probabilistic polynomial time (PPT) adversary A, the probability decides if 𝑐 = 𝑎𝑏 is neglibly away from \(\begin{aligned}\frac{1}{2}\end{aligned}\). While in DHK, given (𝑔, 𝑔^𝑥) ∈ 𝔾² for randomly chosen 𝑥 ∈ ℤ*_𝑝, it creates a Diffie-Hellman tuple (𝑔, 𝑔^𝑥, 𝑔^𝑟, 𝑔^𝑥𝑟) without the knowledge of 𝑟. Then, Assume the DDH and DHK assumptions hold in 𝔾₁ and that is computable isomorphism from 𝔾₂ to 𝔾₁ for instance 𝜙(𝑔₂) = 𝑔₁. Let ℎ₂ and 𝑈₂ be randomly chosen from 𝔾₂ and 𝑢, 𝑣 ∈ ℤ,𝑒 (ℎ^𝑢₁, ℎ^𝑣₂) = 𝑒(ℎ₁, ℎ₂)^𝑢𝑣. The system parameters are 𝜇 = ⟨𝑝, 𝔾₁, 𝔾₂, 𝑔₁, 𝑔₂, 𝑒, ℎ₁, ℎ₂, 𝑈₁, 𝑈_𝑣, 𝐻₁, 𝐻⟩.

5.2.2 Key generation and Vehicle Registration

In the following steps, a 𝓥 establishes communication with the cloud through a secure channel to register for a Vehicular Communication (VC) network

Step 1: 𝓥 self-generate a key pair 𝓟𝓚𝒗 , 𝓢𝓚𝒗 to become a legitimate member in the network. 𝓥 requests validation of its self-generated public key from the cloud (𝓟𝓚𝒗) preserving its secret key (𝓢𝓚𝒗) private at time, t, where 𝓟𝓚𝒗 = 𝑼𝓢𝓚𝒗𝟏 ∈ ℤ*𝒑). A vehicle generates its tracking data, 𝑻𝒗 = 𝒈𝓢𝓚𝒗𝟐 where 𝒈𝒊 represent random generator of 𝔾𝒊. Then, 𝓥 submit (𝓟𝒦𝒗, 𝓟𝒦𝒑, 𝑻𝒗,) to 𝓣𝓚𝓒.

Step 2: 𝓣𝓚𝓒 checks for authenticity of 𝒆(𝓟𝓚_𝒗, 𝓟𝓚_𝒑, 𝒈₂) = 𝒆(𝑼_𝒗, 𝑼_𝒑, 𝑻_𝒗). Upon successful completion verification, 𝓣𝓚𝓒 produces a signature on 𝓟𝓚_𝒗 and forwards to 𝓥. 𝓣𝓚𝓒 then saves data of (𝓟𝓚_𝒗, 𝓟𝓚_𝒑, 𝑻_𝒗) via its internal system.

Step 3: The vehicle, denoted by 𝒱, undergoes the Zero-Knowledge Proof Protocol (ZKPP) represented as 𝒵𝒦{𝒮𝒦𝑣|𝒫𝒦𝑣 = 𝑈𝒮𝒦𝑣1} with ℛ𝒢𝒞 in subsequent phases. The ℛ𝒢𝒞 verifies the vehicle's authenticity by examining the signature on 𝒫𝒦𝑣. ℛ𝒢𝒞 has a key pair (𝒜, 𝒵) = (𝑒(𝒵, 𝑔2), 𝒵), which is used to validate 𝒯𝒦𝒞's signature on 𝒫𝒦𝑣. ℛ𝒢𝒞 checks the validity of ZKPP performed by 𝒱 and runs the computation to obtain 𝐾1 = 𝑔𝑘1, 𝐾2 = 𝑍(ℎ1𝒫𝒦𝑣)−𝑘 where 𝑘 ∈ ℤ*𝑝. After successful computation, ℛ𝒢𝒞 distributes 𝐾𝑣 = (𝐾1, 𝐾2) to legitimate vehicles. The vehicle verifies the signature by checking 𝑒(𝐾2,𝑔2)𝑒(𝐾1, ℎ2)𝑒(𝐾𝒮𝒦𝑣1, 𝑈2) = 𝐴. If the check is successful, the vehicle can use 𝐾𝑣 as a group certificate across the network and is registered to the cloud. The vehicle can sign any safety message using its 𝒮𝒦𝑣.

5.2.3 Message Transmission

In this phase, 𝓥 generates a message that is related to safety and sends it to nearby vehicles through RSUs. The following information provides further details on this process:

Step 4: 𝓥 creates the message denoted as (𝓶) where 𝓶 =(𝑴𝑩, 𝒕_𝒔, 𝒍𝒐𝒄_𝒗, 𝑮𝑰_𝒗, 𝑰_𝑹𝑺𝑼). 𝑴𝑩 represents for message’s broadcast type, 𝒍𝒐𝒄_𝒗 indicates for current position of the moving vehicle, while 𝒕_𝒔 stands for the signature creation time to guarantee message freshness. Let 𝑮𝑰_𝒗 be a group identifier for the vehicle that allows one to determine the group to which the vehicle corresponds. The symbol for RSU's actual identification is 𝑰_𝑹𝑺𝑼.

The group signature method enables a group member to sign a message on behalf of the whole group, and the signature can be verified using a specific public key group without revealing the signer's identity. The group signature comprises three main parts, which are:

1. Randomize 𝑲_𝒗 where 𝓥 computes 𝝈_𝟏 = 𝑲_𝟏𝒈^𝒔_𝟏, 𝝈_𝟐 = 𝑲_𝟐(𝒉_𝟏𝓟𝓚_𝒗)^−𝒔 for a randomly chosen 𝒔 ∈ ℤ*_𝒑.

2. Randomize 𝓟𝓚𝒗 where, 𝝈𝟑 = 𝝈𝓢𝓚𝒗𝟏 and generate a unique identifier for the message 𝝈𝟒 = 𝑯𝟏(𝓶)𝓢𝓚𝒗.

3. Generate the group signature using 𝓢𝓚𝒗 in 𝝈𝟑 = 𝝈𝓢𝓚𝒗𝟏 and 𝝈𝟒 = 𝑯𝟏(𝓶)𝓢𝓚𝒗. 𝓥 executes executes zero knowledge proof to persuade the verifier that a particular information is true while keeping all other information secret.

To generate a group signature, 𝓥 evaluates:

• Set up in random for 𝒓 ← ℤ*_𝒑.

• Compute 𝑹_𝟏 = 𝑯_𝟏(𝓶)^𝒓 and 𝑹_𝟐 = 𝝈^𝒓_𝟏.

• Obtain a challenge of 𝑹_𝟏 and 𝑹_𝟐 where 𝝈_𝟓=𝑯(𝓶||𝝈_𝟏||𝝈_𝟐||𝝈_𝟑||𝝈_𝟒||𝑹_𝟏||𝑹_𝟐).

• Response to the challenge with 𝝈𝟔 = 𝒓 − 𝝈𝓢𝓚𝒗5 𝒎𝒐𝒅 𝒑 and output the group signature as 𝝈 = (𝝈𝟏, 𝝈𝟐, …, 𝝈𝟔) of 𝓶.

𝓥 broadcasts a message tuple, 𝓜 = (𝓶, 𝝈), to other vehicles via RSUs. The tuple includes a message link-identifier, 𝝈_𝟒, which can only be generated once by 𝓥 for the same message. The RSU is used to broadcast messages from 𝓥 to the authentication cloud and 𝓐𝓣𝓒.

Step 5: The RSU sends 𝒨 to the 𝒜𝒯𝒞 to verify the authenticity of safety messages. The RSU prohibits communications containing the same 𝜎₄ component to prevent the repetition of messages signed by the same vehicle. Upon successful verification, the 𝒜𝒯𝒞 verifies a specific number of communications related to the same incident.

5.2.4 Message validation

After receiving the message, the cloud executes the following procedures:

Step 6: To verify the message, the cloud performs the following steps:

𝒜𝒯𝒞 checks 𝑒(𝜎₂,𝑔₂)𝑒(𝜎₁,ℎ₂)𝑒(𝜎₃,𝑈₂) = 𝐴 to confirm the authenticity of the group certificate. and validate σ'₅ = H(𝓂||σ₁||σ₂||σ₃||σ₄||𝐻₁(m)^𝜎6σ₄^𝜎5||σ₁^𝜎6σ3^𝜎5)^_.

When the message's freshness is maintained, 𝒜𝒯𝒞 determines that a message is trustworthy if and only if 𝜎′₅ = 𝜎₅. Furthermore, our protocol uses adaptable threshold authentication, where the authenticity of a message is determined by the 𝒜𝒯𝒞 based on the number of messages it has received reporting similar events.

Step 7: 𝒜𝒯𝒞 transmits the safety message, ℳ, to a nearby RSU upon success verification.

Step 8: The RSU disseminates the safety message 𝒨 to nearby vehicles in the area of the reported incident.

Step 9: 𝒱 analyzes 𝑡_𝑠 to verify the content of the safety message. The message is considered reliable if both message verification tests pass and 𝑡_𝑠 is valid. 𝒱 selects a random s and computes 𝑥 = ℎ(𝑠), where 𝑥 represents knowledge of s without revealing it, to ensure that the message is trustworthy and validated by 𝒜𝒯𝒞. V then calculates the challenge 𝑓 = (𝑠, 𝒫𝒦)_𝒜𝒯𝒞 and sends it to 𝒜𝒯𝒞. Here, ℎ is a one-way hash function and 𝒫𝒦_𝒜𝒯𝒞 represents the public key of 𝒜𝒯𝒞. In response to the challenge, 𝒜𝒯𝒞 decrypts 𝑓 to obtain 𝑠’, computes 𝑥' = ℎ(𝑠)', and terminates if 𝑥' ≠ 𝑥, indicating that 𝑠' ≠ 𝑠. Otherwise, 𝒜𝒯𝒞 sends 𝑠 = 𝑠' back to 𝒱. Consequently, 𝒱 successfully authenticates 𝒜𝒯𝒞 by verifying that the received 𝑠 matches the one that was agreed upon earlier.

5.2.5 Vehicle Tracking and Revocation

Step 10: If a 𝒱 participates in malicious activity within the network, it can be traced and detected.

Step 11: The 𝒜𝒯𝒞 checks the authenticity and consistency of message ℳ to revoke 𝒱 if there is any misconduct. It is noteworthy that 𝒜𝒯𝒞 has access to the trapdoor’s information related to 𝒫𝒦_𝒱. To identify 𝒫𝒦_𝒱 associated with 𝒱 's identity for law enforcement and revocation purposes, the 𝒯𝒞 searches its local database.

6. Performance Evaluation

6.1 Security Analysis

This section examines the security concerns with our presented protocol and evaluates its efficiency. We compare our scheme with those presented in [40], [46] and [47] because those schemes proposed the authenticated anonymous announcement protocol in VC. In order to implement VC, it is indispensable that the following security requirements be met:

Reliability. All the schemes satisfy the first two requirements of message integrity and reliability of user identity. Message authentication is often achieved via a secure digital signature. The validity of the message is preserved, and messages announced without modification are guaranteed. Our protocol satisfies the requirements of user authenticity and data integrity as messages are signed with legitimate credentials provided by the cloud.

In contrast, [40, 46, 47] do not satisfy the third requirement for message reliability since no technique for measuring message reliability was put forward. Additionally, because the origin of the message in [40, 46, 47] cannot be distinguished, the threshold technique cannot be adopted. Our approach ensures the required threshold authentication property by utilizing a flexible threshold technique, which enables the cloud to determine the suitable threshold based on the message's content and location. For instance, in a highly populated city with heavy traffic, the threshold can be set higher than in a rural area with lighter traffic.

Claim 1. The proposed protocol achieves the third requirement of message reliability.

Proof: The property of threshold technique is satisfied in this protocol. To resolve the requirement of threshold authentication, we give an example of how threshold authentication technique being adopted in our scheme as below:

We let 𝒱 receive a safety-related message, ℳ = (𝓂, 𝜎) via RSU, 𝒱 then forward ℳ to 𝒜𝒯𝒞 via RSU. When a message is received, the 𝒜𝒯𝒞 verifies the legitimacy of the vehicle in the network by checking the message-link identifier, 𝜎₄. If the vehicle has not signed the message more than once, then 𝒜𝒯𝒞 verifies the message. Otherwise, 𝒜𝒯𝒞 rejects the messages. Assume, the message is valid then 𝒜𝒯𝒞 waits to predefined number of reports for the same events. Subsequently, 𝒜𝒯𝒞 checks for duplicate signature on the same message, 𝒜𝒯𝒞 would log and discard the message if found dishonest.

Next, 𝒜𝒯𝒞 receives (say 𝑛) more messages (𝓂_𝑖, 𝜎_𝑖), 1 ≤ 𝑖 ≤ 𝑛. If these 𝑛 signatures are valid and if 𝑛 satisfies the threshold, 𝒜𝒯𝒞 believes that the reported event is true and disseminate to the vehicles via RSU. When the threshold is not exceeded, the messages will be added to the “waiting list” and deleted at some point in time.

If the messages are not valid then the messages will be added to the “false list” and discarded at the expiration time.

Claim 2. The proposed protocol has high robustness against impersonation attack and forgery of partial signature.

Proof: In our proposed protocol, cloud performs the issuance, distribution and management of credentials to legitimate vehicles. We evaluate the robustness of our scheme against impersonation attack for insider. In this attack, an adversary masquerade as a legitimate vehicle. An outsider is not taken into account as they pose a lower risk to other users within the network. Suppose an adversary impersonate as an honest vehicle:

I. An adversary randomly chooses an integer 𝒮𝒦′𝒱 for a random value, 𝒮𝒦𝒱 ∈ ℤ*𝑝, and let 𝒫𝒦′𝒱 = 𝑈𝒮𝒦′𝑣1.

II. The signing protocol for the message, 𝓂 is executed.

III. A fake message 𝒨′ = (𝓂′, 𝜎′) is announced.

Let adversary be 𝒜 and challenger be 𝒞. Assume adversary 𝒜 is able to forge the valid signature to manipulate other entity in the network without the fear of being arrested. If 𝒜 intends to access the network, 𝒜 requests the system parameters 𝜇 and thus, 𝒞 deliver 𝜇 to 𝒜 where:

𝜇 = ⟨𝑝, 𝔾₁, 𝔾₂, 𝑔₁, 𝑔₂, 𝑒, ℎ₁, ℎ₂, 𝑈₁, 𝑈_𝑣, 𝐻₁, 𝐻⟩       (1)

Meanwhile, 𝒞 generate ℛ𝒯𝒞's public key denoted as 𝐴 then forward 𝐴 to 𝒜. When 𝒜 query a group certificate and the signature of 𝒫𝒦′𝒱 from 𝒯𝒦𝒞, 𝒞 generate the group certificate given that 𝒞 know the valid key pair of 𝒜, (𝒫𝒦′𝒱, 𝒮𝒦′𝒱). In addition, 𝒞 possess a knowledge of ℛ𝒯𝒞's secret key, 𝑍 to satisfy 𝑒(𝑍, 𝑔2). 𝒞 learn the value of 𝑍, except the value of 𝒮𝒦𝒱. In order to get the value of 𝒮𝒦𝒱, 𝒞 run a zero-knowledge proof 𝒵𝒦{𝒮𝒦𝑣|𝒫𝒦𝑣 = 𝑈𝒮𝒦𝑣1} with 𝒜 by invoking 𝒜 twice.

Assume, 𝒜 able to impersonates legitimate vehicle's identity which has a group signature 𝜎 = (𝜎1, ... , 𝜎6). Then, the tracking data in the name of false vehicle’s certificate does not hold 𝑒(𝜎2,𝑔2) = 𝑒(𝜎1, 𝑇𝑣). The challenger 𝒞 firstly sends 𝒮𝒦𝒱 to the 𝒯𝒦𝒞. The 𝒯𝒦𝒞 randomly chooses a secret integer 𝑇′𝑣 ∈ ℤ*𝑝, and send 𝑇′𝑣 to 𝒞. Then 𝒞 computes 𝑇′𝑣 = 𝑔𝒮𝒦′𝑣2 . If the equation 𝑇′𝑣 = 𝑔𝒮𝒦′𝑣2 equal to 𝑇𝑣 = 𝑔𝒮𝒦𝑣2 for a same period, 𝑡. Then, 𝒞 checks the verification equation:

σ₅ =H(m||σ₁||σ₂||σ₃||σ₄||H₁(m)^𝜎6σ₄^𝜎5||σ₁^𝜎6σ3^𝜎5)       (2)

If the equation holds the signature is valid and vice versa. Then, 𝒜 executes the signing protocol. Note that the equation implies 𝜎 = (𝜎1, 𝜎2 ,…, 𝜎6) is a signature on message 𝓂 under one-time public key 𝜎3 = 𝜎𝒮𝒦𝑣1, 𝜎4 = 𝐻1(𝓂)𝒮𝒦𝑣. When 𝒜 requests a group signature on 𝓂, it can always be detected by 𝒯𝒦𝒞. Hence, 𝒜 fails to impersonate an identity and incapable to broadcast bogus message ℳ′ = (𝓂′, 𝜎′). Therefore, our protocol is resilient to impersonation attacks.

Privacy. We discuss two aspects of privacy: anonymity and unlinkability. The necessity of privacy is met in [40, 46, 47] by using pseudonyms where it prevents the matching of the real identification from its source. Additionally, we ensure that there is no linkability between different messages that originate from the same source. This guarantees the privacy requirement is met in our protocol.

Claim 3. Our protocol achieves authenticated privacy requirement.

Proof: When the actual identity is transmitted to the network in plaintext, the adversary can easily obtain the actual identity of a sender by intercepting the message. Let adversary be ℬ, assume there have two honest vehicles denoted as 𝒟₀ and 𝒟₁.

We assume the adversary ℬ owns the legitimate key pair (𝒫𝒦_𝒱, 𝒮𝒦_𝒱). and obtain the system public parameter, 𝜇 = ⟨𝑝, 𝔾₁, 𝔾₂, 𝑔₁, 𝑔₂, 𝑒, ℎ₁, ℎ₂, 𝑈₁, 𝑈_𝑣, 𝐻₁, 𝐻⟩. The adversary ℬ randomly chooses two different messages which are indicated as 𝓂₀ and 𝓂₁ and selects the random bit 𝒷 ∈ {0,1}. Then, ℬ forward 𝓂_𝒷 and 𝓂_1−𝒷 to 𝒟₀ and 𝒟₁ respectively. Note that, 𝒷 is unknown to us. The 𝒟₀ and 𝒟₁ generate two legitimate signatures 𝜎_𝒷 and 𝜎_1−𝒷 which are associated to the message 𝓂₀ and 𝓂₁. We forward in random order the two signatures 𝜎_𝒷 and 𝜎_1−𝒷 to ℬ, otherwise return invalid symbol ⊥ to the ℬ.

When adversary ℬ obtains the signature, ℬ computes the signature and produce 𝒷’ of 𝒷, 𝒷’ ∈ {0,1}. We declare failure if ℬ can guess the value of 𝒷’ = 𝒷. However, given one valid message and two vehicles in the network, ℬ can only decide the originator of the message with a probability non-negligibly greater than \(\begin{aligned}\frac{1}{2}\end{aligned}\) in polynomial time. This is comparable to the random guess of 𝒷. Hence, we prove that our scheme fulfils the authenticated privacy requirement.

Accountability. Throughout the case of traffic collisions and incidents, evidence should be collected for the verification and settlement of claims for the assessment of liability. If some entity has unlawful actions, TP can trace the true origin of that vehicle. When malicious activity is detected later, TP has evidence to revoke the presence of vehicle in the network.

Claim 4. If there are fraudulent behaviour on a certain vehicle, TP may reveal the true identity.

Proof: When a certain vehicle is behaving maliciously, then 𝒯𝒦𝒞 in this scheme can identify the real identity of vehicle. Recall that, the part of the signature under a one-time public key shows that 𝜎3 = 𝜎𝒮𝒦𝑣1 and 𝜎4 = 𝐻1(𝑚)𝒮𝒦𝑣 where 𝒮𝒦𝑣 is the secret key of some group member. Hence, with the tracing information 𝑇𝑣 = 𝑔𝒮𝒦𝑣2 the 𝒯𝒦𝒞 can trace the signer by checking 𝑒(𝜎2, 𝑔2) = 𝑒(𝜎1, 𝑇𝑣). This property allows the prosecutors to locate and detect fraudulent messages that prohibit cheating vehicles. If the same signer signs the same message twice, both signatures then hold the similar element 𝜎4 = 𝐻1(𝑚)𝒮𝒦𝑣. Hence, the signer may be computationally related by evaluating two signatures with the same message. This gives evidence to the 𝒯𝒦𝒞 to revoke the participation of the signer from the network.

We demonstrate that the security requirements in VC network are satisfied by our security analysis. Table 2 provides an overview of our security analysis results. Our protocol effectively addresses the requirements for message reliability, privacy, and accountability. In conclusion, our scheme appears to be more effective and resilient than the protocol proposed in the [40, 46, 47].

6.2 Performance Analysis

With reference to [40, 46, 47] we compare the performance efficiency of our proposed protocol in this section. We compare our protocol to other schemes based on three criteria: the size of the message and signature, computational expenses, and execution time.

Message and Signature Size. We have chosen for the National Institute of Standards and Technology (NIST) curve [45] and a 160-bit prime for 𝑝 to achieve an 80-bit security level, with the 𝔾₁ element being 160 bits long. Our message consists of a payload, a timestamp, a group ID, and the real RSU's identity. By allocating 80 byte, 1byte, 1 byte, and 1 byte, respectively, a vehicle-generated message with an 80-bit security level has a length of 211 bytes. By contrast, the message lengths in [40], [46] and [47] are 300, 280, and 350 bytes, respectively. Our method employs a group signature with a signature size of 128 bytes. Therefore, compared to [40, 46, 47] our protocol effectively achieves lower communication costs and is acceptable for VC networks. This is illustrated in Fig. 3.

Fig. 3. The message and signature size of our protocol compared with [40, 46, 47].

Computational expenses. In the process of message broadcast, we analyse and assess the computational complexity associated with both signature generation and verification. To simplify the comparison, we focus on the computational costs of scalar multiplication in 𝔾₁ and pairing evaluation. Exponentiation is considered and converted to scalar multiplication if it is used. We compare the computational costs of our proposed method with those of [40, 46, 47]. According to [2], one exponentiation in 𝔾_𝕋 is equivalent to about four scalar multiplications in 𝔾₁ in the standard implementation. Therefore, we convert the cost of exponentiation to scalar multiplication in Table 3. Furthermore, the overhead of a multi-base pairing is approximately the same as that of a single-base pairing. Now, in order to complete the performance analysis, we add the "signature check" and "verification check" operations. In this table, ℯ. 𝔾₁ indicates ℯ scalar multiplications in 𝔾₁, 𝒻. 𝑃 signifies 𝒻 operations for pairing. The process of signing in [40] involves two scalar multiplications, while the verification process requires one pairing and three scalar multiplications. In contrast, the signing process in [46] requires two pairings and five scalar multiplications, with the verification process requiring one pairing and six scalar multiplications. In [47], the signing process requires two pairings and seven scalar multiplications, with the verification process requiring two pairings and four scalar multiplications. For our proposed protocol, the signing process involves six scalar multiplications, while the verification process involves one pairing and four scalar multiplications. Table 3 summarises these results. We note that the computational expense of our scheme is equivalent to that of the [40, 46, 47] schemes.

Execution time. To evaluate the execution time of our proposed method, we relied on the implementation results presented in previous studies [2, 45], which showed that a single multiplication in 𝔾₁ and one pairing evaluation can be completed within 0.6 ms and 4.5 ms, respectively, to achieve an 80-bit security level. These results were obtained by running an Intel Pentium IV 3.0 GHz which has similar performance to the CVIS vehicle machine developed for future communications in VC [2]. Using this information, we calculated the computation time required for the operations listed in the computational cost column of Table 3. The results of our execution time calculations are presented in the computation time column of Table 3. Based on these results, we conclude that our proposed method has the most efficient communication cost when compared to [40, 46, 47]. Our proposed method achieves the lowest communication cost and outperforms the other studies in terms of computing cost and time. Furthermore, our proposed method meets all necessary security requirements for the successful implementation of an announcement protocol in VC. The overall performance of our proposed method is presented in Table 2 and Table 3.

Table 2. Security Analysis in VC

Table 3. Comparison of Performance Analysis

6.3 Simulation

In this section, we conducted simulations to demonstrate the feasibility of our scheme in a real-world scenario, implemented using cryptographic library MIRACL [2] and the NS-2.35 network simulator. The simulations were performed on a Linux machine running an Intel Core i5-4790 processor at a frequency of 3.6 GHz. We evaluated performance of our scheme in the context of V2V communication, using metrics such as average transmission message delay in VC (MD_𝑣c) and average message loss rate in VC (ML_𝑣c). We assume that the vehicular nodes were randomly distributed. To evaluate our performance metrics, we developed a formulation such a way:

\(\begin{aligned}M D_{v c}=\operatorname{Avg} \sum_{i=1}^{N_{v}} \operatorname{Avg}\left(\frac{M_{\text {sent }_{i}} \times T_{\text {sign }}}{M_{\text {received }_{i}}}\right)\end{aligned}\)

\(\begin{aligned}M L_{v c}=A v g \sum_{i=1}^{N_{v}} \frac{M_{\text {received }_{i}} \times T_{\text {verify }}}{N_{c} \times N_{v}}\end{aligned}\)

In this simulation, we consider the number of vehicles and cloud as 𝑁_𝑣 and 𝑁_𝑐, respectively. Meanwhile, 𝑀_sent is amount of message that have been transmitted and 𝑀_received known as amount of message that have been received. 𝑇_sign represents the total time taken for signature generation, while 𝑇_verify denotes the total time taken for signature verification. This protocol was simulated under the following design settings:

Table 4. Simulation Parameters

The simulation results are shown in Fig. 4 and Fig. 5 for VC communication. Fig. 4 shows the simulation result of the correlation between the number of vehicles and the average message delay. According to Fig. 4, we can see that the average transmission delay rises proportionally with the growth of vehicle density. As the number of vehicles increases, the number of messages generated and broadcasted also increases, causing congestion to the network channel. As a result, this congestion leads to message transmission delay as vehicles experience interference caused by other vehicle’s transmission. We can infer that our proposed protocol has an advantage over other schemes as our work yields the lowest message delay, followed by [40, 46, 47].

Fig. 4. The correlation between the number of vehicles and the average message delay.

The results in Fig. 5 demonstrate that the average message loss rate increases as the number of vehicles in the network increases. This is understandable since the increase in the number of messages transmitted requires more cryptographic computations to be performed in order to verify the messages received. These computations can lead to network congestion, resulting in messages being dropped if they are not verified before a certain time interval elapses. Our scheme is shown to have comparable or better message loss performance than the schemes proposed in [40, 46, 47].

Fig. 5. The correlation between the number of vehicles and the average message loss rate.

7. Conclusion

In this study, we introduce a new protocol for privacy-preserving authentication in VC based on group signature. According to our knowledge, this is the first generic abstraction for the announcement protocol using group signatures in VC has been proposed in literature, which can serve as a guideline for designing future protocols. Our proposed protocol addresses the conflicting security requirements, providing a reliable announcement protocol while protecting user privacy against adversaries. Implementation of our protocol on NS-2.35 simulator demonstrates its practicality and suitability for real-world deployment.

Future work may aim to expand the present protocol so that more vehicles can receive a message in a larger area without compromising security. Additionally, it would be interesting to investigate the formal definitions of various security properties desired in VC and provide rigorous proofs for the security of the proposed announcement protocol in VC networks.