Revocation Protocol for Group Signatures in VANETs: A Secure Construction

Abstract

Vehicular ad hoc networks (VANETs) enable wireless communication between vehicles and roadside infrastructure to provide a safer and more efficient driving environment. However, due to VANETs wireless nature, vehicles are exposed to several security attacks when they join the network. In order to protect VANETs against misbehaviours, one of the vital security requirements is to revoke the misbehaved vehicles from the network. Some existing revocation protocols have been proposed to enhance security in VANETs. However, most of the protocols do not efficiently address revocation issues associated with group signature-based schemes. In this paper, we address the problem by constructing a revocation protocol particularly for group signatures in VANETs. We show that this protocol can be securely and efficiently solve the issue of revocation in group signature schemes. The theoretical analysis and simulation results demonstrate our work is secure against adversaries and achieves performance efficiency and scalability.

1. Introduction

The growing concern in road safety and traffic efficiency has drawn a significant interest towards the development of vehicular ad hoc networks (VANETs) [1-7]. In VANETs, vehicles can communicate with each other (V2V) and with the roadside units, known as infrastructure (V2I) to announce safety messages [8]. The communication scenario is illustrated in Fig. 1. With the safety information, drivers can anticipate any harmful situations and take actions accordingly. However, safety can only be achieved if messages broadcasted are trustworthy [9]. To evaluate trustworthiness of a message, receiving vehicle performs verification check on the message received. This arises an issue of privacy as such message verification may reveal some information about the sender, leading to profiling of a vehicle by an adversary. Profiling is an act of classifying messages into pre-defined profiles, thus gaining useful information about the sender [10]. The presence of adversaries is a common assumption in VANETs [6,9,11-14]. They can be categorised as internal and external adversaries. An internal adversary is a legitimate user who possesses credentials in VANETs while an external adversary does not possess one [14]. The internal adversary can be further broken down into a revoked adversary who is a legitimate user that has been revoked in the system but still owns its initial keys. This type of adversary may misuse his legitimacy to mislead any other vehicle by manipulating the content of a message, impersonating other vehicle's identity and intercepting communication between two parties. In our work, we assume the presence of internal adversaries since most of external attacks can be prevented by means of authentication and privacy protection. Moreover, this is a common assumption in the literature [12-14].

Fig. 1. Communication in VANETs

Vehicles would be less likely to participate in VANETs if the system is vulnerable to attacks. The system vulnerability may render the technology to be unutilized. In order to protect VANETs against misbehaviours, addressing a secure and efficient revocation is indispensable in the network [15]. Revocation is vital to ensure these misbehaved vehicles are held accountable for their own actions and to prevent them from further participation in the network.

At the same time, privacy should be preserved in VANETs. Group signatures [7,11,12,16-22] and pseudonymous mechanisms [4,8,13,14,23,24] are the two common techniques to provide privacy in VANETs. Some may favour group signatures over pseudonymous public key due to the storage efficiency and ease of certificate management [11]. In order to make VANETs beneficial to the users, a privacy-preserved scheme such as group signatures should address a practical revocation protocol in the construction.

There are two conditions to be considered for a practical revocation protocol. First, the revocation procedure should be integrated with other security requirements. Second, an efficient revocation procedure is required as delay in revoking the misbehaved vehicles may open up the possibility for them to continue jeopardizing the safety of other vehicles. To address these conditions, we propose a secure and efficient revocation protocol particularly for group signature schemes in VANETs. Our proposed protocol can integrate with the requirement of privacy provided by group signature schemes. The identity of an adversary will only be revealed when it has been found misbehaved. The efficiency of our revocation protocol is comparable to other revocation techniques presented in other group signatures schemes in the literature. Furthermore, our work efficiently addresses the issue of revocation in Wu et al.'s scheme [11] where revocation was discussed but no explicit mechanism was presented. While our revocation protocol is proposed to address the gap in [11], it is adaptable to other group signature schemes of similar setup and construction.

The remainder of this paper is organised as follows. We discuss related work in this research topic in Section 2. We then briefly review the group signature scheme proposed in [11] in Section 3. In Section 4, we introduce our revocation construction. We analyse the security and performance efficiency of our protocol in Section 5 and Section 6 respectively. Finally, we conclude the paper in Section 7.

2. Related Work

A number of revocation protocols have been proposed to address the issue of revocation in group signature schemes [7,11,12,16-22]. The most common way to revoke misbehaved vehicles in group signatures is by using Verifier-Local Revocation (VLR) [12,16-18]. VLR was introduced by Boneh and Shacham in 2004 [25] where revocation information stored in the Revocation List (RL) is distributed to verifiers for check-up operation. Calandriello et. al [17] and Studer et. al [18] depend on VLR to achieve revocation. However, VLR method is efficient only if there are a few revoked vehicles in the network. This method becomes computationally inefficient when a large number of revoked vehicles exist in the list.

Some other group signatures schemes such as in [19,20] replaced the RL checking process during message verification phase with a Hash Message Authentication Code (HMAC) checking. A detailed mechanism of HMAC can be found in [26]. Adopting HMAC method requires low storage space as the size of the HMAC is smaller than the size of the certificate. However, the involvement of Road Side Units (RSUs) in these two schemes [19,20] is needed to filter out revoked vehicles who enter their communication range using the revocation lists, so that only unrevoked vehicles are able to obtain group keys and announce messages with HMAC values attached. The same role of RSU is also needed in [7, 21, 22] where revocation check is performed by the RSU before issuing a group key for each legitimate vehicle that passes by its domain.

Meanwhile, in other group signature schemes where no reliance is placed on RSUs during message broadcast phase such as in Lin et al's [16] and Chen et al.'s [12], VLR is used in conjunction with an additional method for a more efficient system. In Lin et al.'s scheme called Group Signature and Identity-based Signature (GSIS) [16], VLR plays its role when the number of revoked vehicles is below a certain threshold. When it exceeds the threshold, updating the key pairs of unrevoked vehicles is required. Thus, the revoked vehicles who are unable to obtain their keying materials updated will automatically be excluded from the network. Meanwhile, in Chen et al.'s scheme, called Threshold Anonymous Announcement (TAA) [12], its revocation construction is almost similar to GSIS scheme, only that TAA requires both Trusted Parties (TPs) and unrevoked vehicles key pairs to be updated. This is necessary in [12] since the TPs key is used in the verification phase by the verifiers. To update the keys, interval communication between vehicles and the TP may be required since TAA does not entirely assume the availability of RSUs. Vehicles may also interact with the TP during regular maintenance visit or at VANET service points. In GSIS, although the role of RSU is not needed during message broadcast between vehicles, its involvement is assumed only to relay information such as to announce key update in executing revocation.

The revocation protocols discussed earlier may not be a suitable solution to be implemented in [11] due to inefficiency of adopting VLR alone in [17,18], zero reliance on RSUs to broadcast message in [11] as opposed to [7,19-22] and challenges to update credentials compared to [12,16] as vehicles generate their own tracing information that was sent to the TP during registration phase. Our main goal is to provide a promising solution for revocation, which is imperative in VANETs. The contributions of this paper are as follows:

• We highlight the flaw in [11], which shows that the scheme does not achieve its security objectives when revocation protocol is not presented in the scheme.

• We design a generic abstraction of revocation protocols for group signature-based schemes which aims to provide the basis for designation of revocation protocol in group signatures.

• We propose a new revocation protocol that completes the scheme in [11] which combines the use of VLR with an additional technique of updating credentials and tracing information.

• We run a simulation of our revocation protocol. We provide an analysis and present experimental results that validate the efficiency and scalability of our protocol.

3. Wu et al.’s Scheme 

In this section, we provide an overview of Wu et al.'s scheme [11], called Message-Linkable Group Signature (MLGS). There are three different roles of authorities in this scheme, which are a vehicle manufacturer (𝒱ℳ) , a group registration manager (ℛℳ) , and a tracing manager (𝒯ℳ). To enroll into a VANET system, each vehicle, 𝒱 signs a contract with the (𝒱ℳ) to confirm the vehicle ownership and generates its own public key 𝑌 = \(\begin{equation} U_{1}^{y} \end{equation}\) for a random value 𝑦 ∈ \(\begin{equation} \mathbb{Z}_{p}^{*} \end{equation}\), where 𝑦 is the secret key. Then, 𝒱 registers to the ℛℳ to become a legitimate group member by sending its public-private key pair (𝑌, 𝑦). During registration, 𝒱 also sends a tracing information 𝑇 = \(\begin{equation} g_{2}^{y} \end{equation}\) to the 𝒯ℳ so that 𝒯ℳ can trace the vehicle if in case of dispute. When 𝒱 has successfully registered to the system, 𝒱 will receive a sign on its public key from the ℛℳ and use the signature as a group certificate to announce safety messages. 𝒱ℳ, ℛℳ, and 𝒯ℳ are assumed as semi-trusted parties since they have no access to the private key of vehicles. Table 1 shows the lists of some notations related to our work which was adopted from MLGS [11] to ease the reading throughout this paper.

Table 1. Notations and Descriptions [11]

The goal of MLGS scheme is to provide an efficient trustworthy system with a balanced public safety and vehicle privacy. Threshold authentication is used to satisfy the trustworthiness property. (Say 𝑛) MLGS signatures are generated by 𝑛 distinct registered vehicles on messages of the same content. A receiver verifies 𝑛𝑛 signatures using the ℛℳ's public key, 𝐴 to validate the group certificates. If these 𝑛 signatures are valid and if 𝑛𝑛 satisfies the threshold, the message is considered trustworthy. To protect the privacy of vehicles, this scheme allows each vehicle to generate only one message-link identifier 𝜎₄ = 𝐻₁(𝑚)^𝑦 for the same message. This approach enables a vehicle to remain anonymous if it generates one signature on each message but this vehicle can be traced once it produces two signatures on the same message as the two signatures share the same component 𝜎₄. Thus, anonymity is preserved as long as the vehicle does not misbehave by generating two signatures on the same message. However, user safety is compromised in MLGS when no revocation technique was proposed. This leads to system vulnerabilities when adversaries are not accountable for their attacks. In the next section, we show our construction of a revocation scheme that can be efficiently deployed in MLGS.

4. Revocation Construction 

4.1 Generic Revocation Construction 

Based on our analysis of different revocation protocols proposed in existing group signature schemes (presented in Section 2), we formulate a generic abstraction of revocation protocols for group signature-based schemes. To the best of our knowledge, this is the first generic revocation construction exists in the literature that systematically studies and generalise revocation protocols of group signatures schemes in VANETs.

In this section, we present our generalisation of the protocols demonstrated in Fig. 2. The network consists of a trusted party (𝒯P), and vehicles (𝒱). Before describing the abstraction, we review the main role of each entity as follows:

Fig. 2. Generic Revocation Construction 

Trusted Party (𝓣P). A 𝒯P is responsible for the distribution and management of the revocation list (RL). This 𝒯P is commonly known as a Trusted Authority (𝒯A) [18-20], a Tracing Manager (𝒯ℳ) [7, 11, 16, 22], a Certificate Authority (𝒞A) [17,21], and an Issuer (ℐ) [12].

Vehicle (𝓥). 𝒱 has two roles in VANETs:

• Sending vehicle 𝒱_𝑠 sends messages in the network. 𝒱_𝑠 is further divided into two categories; unrevoked vehicles 𝑉_𝑠𝑢 and revoked vehicles 𝒱_𝑠𝑟.

• Receiving vehicle 𝒱_𝑟 receives and verifies the messages. In some schemes [7,19-22], revocation check is not performed during message verification phase, but it is performed during authentication phase by RSUs whenever a vehicle sends a message request to acquire a short-term group key. In such situation, we refer RSUs as 𝒱_𝑟 . We do not distinguish between revoked and unrevoked vehicles in 𝒱_𝑟 since the task of receiving messages could cost no harm to the network.

4.1.1 Description of the Revocation Construction 

The abstraction of revocation shown in Figure 2 is composed of the following steps:

①Firstly, 𝒯P updates the revocation list (RL). There are two cases to be considered after updating the RL.

• CASE A: Either a threshold method is not adopted in the mechanism, denoted by ∄𝑛 in Figure 1 (such as RSU reliance revocation, VLR without threshold or traditional distribution of RL) or if it does, the number of revoked vehicles 𝒱𝒱𝑠𝑠𝑟𝑟 in the RL is less than a predefined threshold 𝑛, denoted by 𝑅L < 𝑛.

• CASE B: The number of revoked vehicles 𝒱_𝑠𝑟 in the RL exceeds the threshold 𝑛, denoted by 𝑅L > ��.

For CASE A:

②𝒯P distributes the updated RL to 𝒱_𝑟 via the wireless channel.

③𝒱_𝑟 uses the received RL to perform revocation check in order to verify if a vehicle is revoked or not. If there is an identity matched, 𝒱_𝑟 rejects the message. If not, the message is accepted, provided the message originates from a legitimate sender.

④If 𝒱_𝑟 experiences any misbehaviours, it may lodge a report and send it to 𝒯P via the wireless channel.

For CASE B:

⑤TP announces a credential update via wireless channel. If the credential update is performed by 𝒯P the process is simple as 𝒯P only updates unrevoked vehicle, 𝑉_𝑠𝑢 's credential and makes it available to 𝑉_𝑠𝑢. However, if the credential update is performed by vehicles; 𝒱_𝑠 and 𝒱_𝑟, thus step ⑥ and ⑦ follow.

(Note that, there is a circumstance where 𝒯P's credential also should be updated. Such update will be performed by 𝒯P.) These last two steps can be discarded if the credential update was performed by the 𝒯P.

⑥𝒱_𝑠 and 𝒱𝑟 update its own credential using a unique value distributed by 𝒯P.

⑦𝒱_𝑠 and 𝒱_𝑟 send to 𝒯P its updated credential for authentication or tracing purposes.

4.2 Our Proposed Construction 

Our proposed revocation protocol has minimal reliance on RSUs. The involvement of the RSUs is only needed to relay information and to provide a gateway between a trusted party and vehicles. Furthermore, we utilize the generic abstraction presented in Section 4.1 to define the structure of our revocation protocol.

4.2.1 VLR Adoption

The construction begins with the adoption of VLR method [25]. This is a common approach for group signature schemes in VANETs. VLR is used in the revocation check during the verification of a signature. According to Bringer in [27], the verification phase should be divided into two parts; `revocation check' and `signature check'. The former is to verify if the signing vehicle has been revoked or not whereas the latter is to check if the signing vehicle is a legitimate member in the network. When analysing the MLGS scheme, we found its verification phase only applies `signature check' without being curious to identify if the vehicles have been revoked from the system or not. Hence, the adoption of VLR is applicable in MLGS since there is no `revocation check' being implemented. Nevertheless, due to the downside of VLR discussed in Section 2, we choose to apply VLR when a number of revoked vehicles in RL is below a certain threshold, and credential update when the number of revoked vehicles in RL exceeds the threshold.

The detailed mechanism of VLR adoption is described according to the generic revocation structure in Section 4.1 as below:

①𝒯ℳ updates the Revocation List, 𝑅𝑅𝑅𝑅 = {𝑌𝑣₁, … , 𝑌𝑣_𝑖}.

②𝒯ℳ distributes the revocation list to 𝒱 when 𝑖 < 𝑛 is a predefined threshold.

③Upon receiving a message 𝑚 that contains a signature 𝜎_𝑣𝑖 , 𝒱 first performs revocation check operation by checking 𝜎₂ = 𝐾₂{(ℎ₁𝑌_𝑖)}^𝑠 for each 𝑌_𝑖 in the RL. If there is a matched 𝑌_𝑖, the message will be discarded. If not, the message is considered as valid and 𝒱 continues to perform signature check operation to validate the signature.

④𝒱 also lodges a revocation report to 𝒯ℳ when repetition of 𝜎₄ is found as it indicates an attempt of misbehavior in MLGS.

4.2.2 Credentials Update

We apply an additional revocation mechanism when the number of revoked vehicles exceeds the predefined threshold. Similar technique was also adopted in [12,16]. In MLGS, since the ℛℳ's key is used by the verifiers during the verification phase, updating both its ℛℳ's key and vehicles' credentials is necessary for revocation. However, updating vehicles' credentials is an issue in MLGS since the vehicles generate their own tracing information which was sent to the 𝒯ℳ during the registration phase. Our proposed revocation protocol includes the process of updating the tracing information, thus solving the issue in MLGS.

Since we adopt a threshold method for the size of revoked vehicles in the revocation list, the revocation construction follows until the last step of the generic abstraction presented in Section 4.1:

⑤𝒯ℳ announces a credential update to be performed by 𝒱. At the same time, ℛℳ updates its credential. The ℛℳ has public-private key pair (𝐴, 𝑍) where 𝐴 = 𝑒(𝑍, 𝑔₂). To update its key, the ℛℳ first updates its private key 𝑍 to a new value \(\begin{equation} \dot{Z} \in \mathbb{Z}_{p}^{*} \end{equation}\) . The ℛℳ then updates its public key 𝐴 to 𝐴̇ = 𝑒(𝑍̇, 𝑔₂). The ℛℳ can now publish its new public key 𝐴̇ to be used across the network via the RSU while its secret key is kept private. The detailed algorithm is illustrated in Fig. 3.

Fig. 3. ℛℳ’s Credential Update

⑥𝒱 updates its credential (shown in Fig. 4) in which tracing information is also updated in this process. Since the credential update is performed by 𝒱 in MLGS, the 𝒯ℳ distributes a new value \(\begin{equation} x \in \mathbb{Z}_{p}^{*} \end{equation}\)  to 𝒱 in the system. 𝒱's public-private key pair is (𝑌, 𝑦) where 𝑌 = \(\begin{equation} U_{1}^{y} \end{equation}\). By having the new value 𝑥, 𝒱 updates its private key 𝑦 first to 𝑦̇ = 𝑦^𝑥. Then, 𝒱 updates its public key 𝑌 to \(\begin{equation} \dot{Y}=\left(U_{1}^{y}\right)^{x} \end{equation}\). Now, 𝒱 has its new key pair (𝑌̇, 𝑦̇) = \(\begin{equation} \left(\left(U_{1}^{y}\right)^{x}, y^{x}\right) \end{equation}\) and can use 𝑌̇ across the network. Using the new key, 𝒱 computes a new tracing information \(\begin{equation} \dot{T}=\left(g_{2}^{y}\right)^{x} \end{equation}\).

Fig. 4. 𝒱𝒱’s Credential Update

⑦𝒱 sends its new tracing information together with the old signature of 𝒱ℳ on 𝑌𝑌 and the new 𝑌̇ to 𝒯ℳ. Upon receiving the information, 𝒯ℳ first verifies the legitimacy of 𝒱 by checking the signature and the new key. Then, 𝒯ℳ verifies the traceability of 𝒱 in case of dispute by checking the new tracing information if 𝑒(𝑌̇, 𝑔₂) = 𝑒(𝑈₁, 𝑇̇) where \(\begin{equation} e\left(\left(U_{1}^{y}\right)^{x}, g_{2}\right)=e\left(x U_{1}, x \dot{T}\right) \end{equation}\). If both checks hold, 𝒯ℳ generates a signature on 𝑌̇ and sends it to 𝒱. Then 𝒱 sends the received signature to ℛℳ to acquire a new group certificate 𝐾_𝒱 = (𝐾₁,𝐾₂). Upon receiving the signature ℛℳ checks its validity. If the check holds, ℛℳ generates 𝐾_𝑣 to 𝒱.

𝒯ℳ will be able to identify a revoked vehicle if it attempts to update its credential by sending its tracing information. 𝒯ℳ will not sign its key nor will it validate the tracing information sent. This prevents revoked vehicles from further contacting ℛℳ to acquire a new group certificate, thus no longer be able to continue its future participation in the network.

5. Security Analysis

5.1 Fulfilment of Accountability Requirement 

Some schemes in the literature [6,8,9,11,12] highlighted the following three security requirements as critical concerns to be met towards VANETs deployment:

• Trustworthiness. To view a message as trustworthy, it must be sent unmodified by a legitimate vehicle. Moreover, the message sent must reflect the actual event.

• Privacy. The identity of the sending vehicle should be protected unless it misbehaved. Furthermore, if two different messages are generated by the same sender, they cannot be linked to each other.

• Accountability. If misbehaviour arise, the misbehaved vehicles can be traceable. Moreover, they must satisfy non-repudiation, that is, the assurance that they are the message originator. The misbehaved vehicle can then be revoked from the network.

We show that our construction completes the security requirement of accountability in MLGS. The requirement of trustworthiness and privacy are not discussed here as these properties have been addressed in [11].

Accountability can only be achieved if it satisfies the properties of traceability, nonrepudiation and revocation. Traceability is satisfied in MLGS when a malicious vehicle who produces two or more signatures on the same message can be traceable since 𝒱 can only generate one identifier, indicated by 𝜎₄ for the same message. Non-repudiation is attained as each vehicle generates its own secret key 𝑦𝑦 without being known by other entities, including semi-trusted entities (𝒱ℳ,𝒯ℳ, ℛℳ). However, revocation is not supported in MLGS since there is no explicit revocation mechanism presented in [11]. Thus, the requirement of accountability is not achieved in MLGS. By adopting our proposed revocation protocol presented in this paper, the accountability requirement is now satisfied.

We compare the functionalities of accountability requirement with other group signature schemes in VANETs (illustrated in Table 2). All schemes satisfy the traceability property. However, only MLGS and TAA achieve non-repudiation since the vehicle in both of these schemes is the sole holder of its secret key. Lastly, looking at the revocation column in Table 2, MLGS is the only scheme that does not achieve revocation property, but with our proposed revocation construction, the issue is solved.

Table 2. Comparison of Accountability Analysis 

5.2 Robustness against Attacks 

We analyze the robustness of our revocation protocol in the presence of adversaries which we classify into three categories; external adversaries, internal adversaries, and revoked adversaries. External adversaries are outsiders who did not register in the network. Internal adversaries are registered vehicles who are in possession of all valid keys. Meanwhile, revoked adversaries who are also registered vehicles, do not possess updated keys but still keeping the initial keys.

 In this paper, we consider the attacks originated from registered vehicles; internal adversaries and revoked adversaries since the purpose of revocation is to remove registered misbehaved vehicles from the network. We then define the probable attacks in vehicular networks namely impersonation attack, sybil attack, and man-in-the-middle attack below. We then present the robustness of our work against these attacks in the next subsection.

1. Impersonation attack. An adversary masquerade as other legitimate vehicles by impersonating their identities and use them to manipulate revocation report.

2. Sybil attack. An internal adversary reports a false revocation and endorse the report by computing as many signatures as required to make the trusted party believe that the report is generated by different vehicles.

3. Man-in-the-middle attack. An adversary eavesdrops, intercepts, and may modify the revocation report sent by the vehicle to the trusted party, who believe they are directly communicating with each other.

We adopt proof technique similar to that used in [11] since the construction of protocol is based on similar computational assumptions i.e. the Diffie-Hellman Knowledge (DHK) assumption. The DHK is described as follows. Let 𝔾 be a finite cyclic group of prime order 𝑝 and 𝑔 the generator of 𝔾 . Given (𝑔, 𝑔^𝑎) ∈ 𝔾² where 𝑎 ∈ \(\begin{equation} \mathbb{Z}_{p}^{*} \end{equation}\) , any probabilistic polynomial-time (PPT) adversary 𝒜 has only negligible probability of creating a DiffieHellman tuple (𝑔, 𝑔^𝑎, 𝑔^𝑟, 𝑔^𝑎r) without knowing 𝑟.

5.2.1 Robustness against Internal Adversaries 

1. Robustness against Impersonation Attacks

Claim 1: An internal adversary is not able to impersonate other legitimate vehicle's identity to generate false revocation reports.

To execute this attack, the internal adversary has to impersonate a vehicle's certificate and make a false revocation report in the name of the vehicle. However, the protocol is able to detect the forgery, hence, the internal adversary cannot impersonate an identity, let alone make false accusation to deceive other vehicles. 

Proof. We consider an internal adversary ℬ attempts to steal identity of a vehicle 𝒱. We show that if ℬ can steal a valid group signature, then the DHK assumption in 𝔾₁ of pairing groups 𝛶 holds.

Given that ℬ can request the public system parameters. We run the DHK challenger in pairing groups 𝛶 = (𝑝, 𝔾₁, 𝔾₂, 𝔾₃, 𝑔₁, 𝑔₂, 𝑒) ← 𝑃Gen(1^λ) where the DHK assumptions hold in 𝔾1. Let 𝜓 is an isomorphism from 𝔾₂ to 𝔾₁ such that 𝜓(𝑔₂) = 𝑔₁. Let ℎ₂,𝑈₂ be randomly chosen from 𝔾𝔾2 and hence, we can efficiently compute 𝜓(ℎ₂) = ℎ1, 𝜓(𝑈₂) = 𝑈₁. We receive a challenge \(\begin{equation} \left(g_{2}, h_{2}\right)=\left(g_{2}, g_{2}^{\beta}\right) \in \mathbb{G}_{2}^{2} \end{equation}\) where 𝛽 ∈ ℤ_𝑝^∗ is undisclosed. Then, we compute (𝑔₁, ℎ₁) where ℎ₁ = 𝜓(ℎ₂). Note that 𝛽 is unknown to us such that ℎ₁ = 𝑔^𝛽. We choose two hash functions 𝐻1(. ):{0,1}^∗ → 𝔾₁ and 𝐻(. ):{0,1}^∗ → ℤ𝑝 at randoms where 𝐻 and 𝐻₁ are modeled as random oracles which makes the outputs of both hash functions are also random. ℬ has to query the oracles in order to compute its output. Then, we have system parameters

𝜇 = ⟨𝑝, 𝔾₁, 𝔾₂, 𝔾_{3, 𝑔1, 𝑔2, 𝑒; ℎ2, ℎ1;𝑈2,𝑈1; 𝐻1, 𝐻⟩       (1)}

When ℬ wants to enter the network, ℬ requests the system parameters 𝜇 and thus, we forward 𝜇 to ℬ. Then, we generate 𝐴 and send 𝐴 to ℬ where 𝐴 is ℛℳ's public key. When ℬ requests a group certificate and the signature of 𝑌 from 𝒯ℳ, we can generate the group certificate provided we know the secret key of ℬ, 𝑦 of the registered public key, 𝑌 and ℛℳ's secret key, 𝑍 to satisfy 𝑒(𝑍, 𝑔₂). 𝑍 is known to us, but not 𝑦. To obtain 𝑦, we run a zeroknowledge proof 𝑍K{𝑦|𝑌 = 𝑔₁^𝑦} with ℬ by invoking ℬ twice according to Forking Lemma in [28].

Now, ℬ impersonates legitimate vehicle's identity which has a group signature 𝜎𝜎 = (𝜎𝜎1, . . . , 𝜎𝜎6). Due to the impersonation, the tracing information equation

𝑒(𝜎₂, 𝑔₂) = 𝑒(𝜎₁, 𝑇)       (2)

does not hold since the illegal activity is valid. At this point, we proceed with the verification procedure assuming revocation check is not able to locate ℬ. The two verification equations

𝑒(𝜎₂, 𝑔₂) = 𝐴e(𝜎₁, ℎ₂)𝑒(𝜎₃, 𝑔₂)       (3)

\(\begin{equation} \sigma_{5}=H\left(m\left\|\sigma_{1}\right\| \sigma_{2}\left\|\sigma_{3}\right\| \sigma_{4}\left\|H_{1}(m)^{\sigma_{6}} \sigma_{4}^{\sigma_{5}}\right\| \sigma_{1}^{\sigma_{6}} \sigma_{3}^{\sigma_{5}}\right) \end{equation}\)       (4)

hold as the impersonation is valid. We note that the second verification equation implies that 𝜎 = (𝜎₁, 𝜎₂, 𝜎₃, 𝜎₄, 𝜎₅, 𝜎₆) is a group signature of a message 𝑚 under one-time public key 𝜎₃ = \(\begin{equation} \sigma_{1}^{\hat{y}} \end{equation}\) and 𝜎₄ = 𝐻₁(𝑚)^ŷ which is generated by zero-knowledge proof to keep ^_ŷ hidden. Since we can extract ^_ŷ by invoking ℬ twice according to Forking Lemma in [28], we obtain

\(\begin{equation} \begin{aligned} e\left(\sigma_{2}, g_{2}\right) e\left(\sigma_{1}, h_{2}\right) e\left(\sigma_{1}^{\hat{y}}, U_{2}\right) &=A \\ e\left(\sigma_{2}, g_{2}\right) &=A e\left(\sigma_{1}^{-1}, h_{2}\right) e\left(\sigma_{1}^{-\hat{y}}, U_{2}\right). \end{aligned} \end{equation}\)       (5)

We know 𝑔₁, ℎ₁ ∈ 𝔾₁ and recall \(\begin{equation} h_{1}=g_{1}^{\beta} \end{equation}\). Thus, there exists 𝛽, \(\begin{equation} \hat{k} \in \mathbb{Z}_{p}^{*} \end{equation}\) such that 𝜎₁ = \(\begin{equation} g_{1}^{\widehat{k}} \end{equation}\) and ℎ₁ = \(\begin{equation} g_{1}^{\beta} \end{equation}\), where we do not know 𝛽, \(\begin{equation} \hat{k} \end{equation}\) as ℎ₁ produces from the challenge. We also recall the isomorphism 𝜓(ℎ2) = ℎ1, 𝜓(𝑔₂) = 𝑔₁, 𝜓(𝑈₂) = 𝑈₁. Then, we obtain ℎ₂ = \(\begin{equation} g_{2}^{\beta} \end{equation}\) and 𝑈₂ = \(\begin{equation} g_{2}^{u} \end{equation}\). It follows that

\(\begin{equation} \begin{aligned} e\left(\sigma_{2}, g_{2}\right) &=A e\left(\sigma_{1}^{-1}, h_{2}\right) e\left(\sigma_{1}^{-\hat{y}}, U_{2}\right) \\ &=e\left(Z, g_{2}\right) e\left(g_{1}^{-\hat{k}}, g_{2}^{\beta}\right) e\left(\left(g_{1}^{\hat{k}}\right)^{-\hat{y}}, g_{2}^{u}\right) \\ &=e\left(Z, g_{2}\right) e\left(\left(g_{1}^{\beta}\right)^{-\hat{k}}, g_{2}\right) e\left(\left(g_{1}^{u \hat{y}}\right)^{-\hat{k}}, g_{2}\right) \\ &=e\left(Z, g_{2}\right) e\left(h_{1}^{-\hat{k}}, g_{2}\right) e\left(\sigma_{1}^{-u \hat{y}}, g_{2}\right) \\ &=e\left(Z h_{1}^{-\hat{k}} \sigma_{1}^{-u \hat{y}}, g_{2}\right). \end{aligned} \end{equation}\)       (6)

Thus, we have \(\begin{equation} \sigma_{1}=g_{1}^{\hat{k}}, \sigma_{2}=Z h_{1}^{-\hat{k}} \sigma_{1}^{-u \hat{y}} \end{equation}\). Since we can extract ŷ, we have \(\begin{equation} \hat{\sigma}_{2}=\sigma_{2} \sigma_{1}^{u \hat{y}}= Z h_{1}^{-\hat{k}} \end{equation}\) where \(\begin{equation} \hat{k} \end{equation}\) is an unknown value to us. We note that \(\begin{equation} \left(\sigma_{1}, \hat{\sigma}_{2}\right) \end{equation}\) is an ElGamal ciphertext of 𝑍 encrypted under the public key ℎ₁. Hence, we have a Diffie-Hellman tuple

\(\begin{equation} \begin{aligned} \left(g_{1}, h_{1}, \sigma_{1}, \hat{\sigma}_{2}\right) &=\left(g_{1}, h_{1}, g_{1}^{\hat{k}}, Z h_{1}^{-\hat{k}}\right) \\ \left(g_{1}, h_{1}, \sigma_{1},\right.& / \hat{\sigma}_{2} =\left(g_{1}, h_{1}, g_{1}^{\hat{k}}, h_{1}^{\hat{k}}\right) \end{aligned} \end{equation}\)       (7)

We obtain an accompanied Diffie-Hellman tuple \(\begin{equation} \left(g_{2}, h_{2}, \sigma_{1},{ }^{Z} /{\hat{\sigma}}_{2}\right) \end{equation}\) where we can use to answer the challenge and subsequently contradicts the DHK assumption in 𝔾₁ . This contradiction completes the proof. ∎

2. Robustness against Sybil Attacks

 Claim 2: An internal adversary is not able to produce multiple signatures to sign a false accusation report for personal benefits.

To commit this attack, an internal adversary produces at least two signatures on the same revocation report. When an internal adversary signs the same report more than once, the trusted party can trace the identity of the adversary and reject the report. Thus, sybil attack can be prevented in our protocol.

Proof. We consider an internal adversary 𝒞 generates two signatures to endorse a false revocation report. Assuming the trusted party performs verification procedure similar to message authentication when receiving the report, the attempt of sybil attack can be identified when the two signatures share

𝜎₄ = 𝐻₁(𝑚)^𝑦.       (8)

We recall \(\begin{equation} \sigma_{3}=\sigma_{1}^{y} \end{equation}\) and 𝜎₄ = 𝐻₁(𝑚)^𝑦 is a one-time public key of the group signature, 𝜎 which specifies that the knowledge of 𝑦 is hidden in (𝜎₃, 𝜎₄). We can say 𝑦 is the secret key of some group member since we have proved that impersonation is not valid in Claim 1. Thus, the trusted party is able to use the tracing information \(\begin{equation} T=g_{2}^{y} \end{equation}\) to trace the group member by checking

𝑒(𝜎₃, 𝑔₂) = 𝑒(𝜎₁, 𝑇).       (9)

If credentials update is performed, the trusted party will use \(\begin{equation} \dot{T}=\left(g_{2}^{y}\right)^{x} \end{equation}\) and check

\(\begin{equation} e\left(\left(U_{1}^{y}\right)^{x}, g_{2}\right)=e\left(x U_{1}, x \dot{T}\right) \end{equation}.\)       (10)

This enables the trusted party to trace 𝒞 when the same component of 𝜎₄ is identified upon receiving the report. The trusted party will then discard the report and put 𝒞 in the revocation list so that 𝒞𝒞 will no longer be able to participate in the network. ∎

3. Robustness against Man-in-the-middle Attacks

Claim 3: An internal adversary is not able to launch man-in-the-middle attack on the revocation report delivered from other vehicle to the trusted party.

To launch this attack, an internal adversary generates a valid report replacing the actual report generated by other vehicle. Since the protocol requires verification procedure between two communicating parties, it is not possible for the man-in-the-middle to pass the verification and further intercept with the communication.

Proof. We consider an internal adversary 𝒟 performs man-in-the-middle attack. 𝒟 captures the revocation report generated by other vehicle. We assume 𝒟 is able to modify the report and the trusted party performs verification procedure similar to message authentication when receiving the report. Since it is impossible to forge a report according to Claim 1, the modified report cannot satisfy the two verification equations

𝑒(𝜎₂, 𝑔₂) = 𝐴e(𝜎₁, ℎ₂)𝑒(𝜎₃, 𝑔₂)       (11)

\(\begin{equation} \sigma_{5}=H\left(m|| \sigma_{1}|| \sigma_{2}|| \sigma_{3}|| \sigma_{4}|| H_{1}(m)^{\sigma_{6}} \sigma_{4}^{\sigma_{5}} \| \sigma_{1}^{\sigma_{6}} \sigma_{3}^{\sigma_{5}}\right) \end{equation}\)       (12)

when the trusted party received the report. The modified revocation report will be rejected and thus, the protocol is secured against man-in-the-middle attack. ∎

5.2.2 Robustness against Revoked Adversaries 

1. Robustness against Impersonation Attacks

Claim 4: Our protocol is robust against a revoked adversary conducting impersonation attack that aims to falsify revocation reports.

The revoked adversary who has been found guilty in the past attempts to reenter the network. However, being a revoked user would not pass the verification procedure due to our proposed revocation check process. Thus, the revoked adversary is not able to impersonate other vehicle's identity to make a false revocation report.

Proof. We consider a revoked adversary ℰ with its public key, 𝑌_𝑖 performs the impersonation attack. We recall the proof in Claim 1, where we assume revocation check procedure is not able to locate the adversary since we want to show the contradiction of DHK challenge. In contrast, here we assume revocation check procedure is able to locate ℰ (since ℰ is a revoked adversary) by checking

𝜎₂ = 𝑘₂(ℎ₁𝑌_𝑖)^𝑠       (13)

for each 𝑌_𝑖 in the revocation list. Once identifying 𝑌_𝑖 , the revocation report will not be accepted and thus ℰ is discarded from the network. This shows our protocol is robust against impersonation attack. ∎

2. Robustness against Sybil Attacks

Claim 5: Our protocol is robust against a revoked adversary attempting sybil attack to lodge a false revocation report.

The revoked adversary who is able to lodge a revocation report using its non-updated key attempts to produce multiple signatures on the same report in order to make it look reliable when the report is generated by multiple vehicles. However, the trusted party can identify this activity since the generation of two or more signatures (either by using updated keys or revoked keys) on the same report produce similar component of 𝜎₄. Since the repetition of 𝜎₄ is present, the proof runs similarly to the proof in Claim 2.

3. Robustness against Man-in-he-Middle Attacks

Claim 6: Our protocol is robust against a revoked adversary performing man-in-the-middle attack in order to alter revocation reports.

To execute this attack, the revoked adversary intercepts a revocation report from other vehicle and modify the content before relaying it to the trusted party. Since revoked certificate is no longer be able to use its revoked key in the network, this attack is preventable.

Proof. We consider an adversary ℱ whose certificate has been revoked performs man-in-themiddle attack. ℱ intercepts the communication between other vehicle and a trusted party by capturing the report from the vehicle, inject a new report using its own credentials and sends it to the trusted party. Upon receiving the report, we assume the trusted party performs revocation check during verification procedure. Since ℱ is a revoked user, there are two possible situations. First, if ℱ was revoked by VLR, the trusted party will find ℱ's certificate in the revocation list . If ℱ was revoked by credential update procedure, ℱ will not be verified correctly under ℛℳ's public key 𝐴 = 𝑒(𝑍, 𝑔₂) which has been updated to 𝐴𝐴̇ = 𝑒(𝑍̇ , 𝑔₂). Thus, ℱ is unable to proceed with the attack. Consequently, our protocol providesstrong robustness against man-in-the-middle attacks.

6. Performance Analysis 

This section presents the performance of our proposed revocation protocol. We compare the computational cost and computation time of our protocol with other revocation protocols designed for VANETs. We then evaluate our protocol by conducting a simulation.

6.1 Computational Cost and Computation Time

We compare the performance efficiency of our work with revocation protocols adopted in GSIS [16], and TAA [12] schemes. We do not compare our work with revocation protocols in [7,19-22] since the schemes rely on RSU during message broadcast between vehicles. Meanwhile, revocation protocols in [17-18] only adopted VLR mechanism which is known to be inefficient if a large number of revoked vehicles exists in the revocation list. Thus, only GSIS and TAA are suitable schemes for a comparison. Moreover, we do not compare our work with pairing-based work as our construction is based on pairing in group signature.

We only evaluate the performance of verification phase because this is the phase where `revocation check' and `signature check' are being conducted. Table 3 summarizes the comparison of the performance efficiency for 𝑡 = 1 as GSIS does not support a threshold method. In this table, 𝑟. 𝔾₁ indicates 𝑟 scalar multiplications in 𝔾₁, 𝑠. 𝑃 indicates 𝑠 pairing operations and 𝑛 in the fifth column denotes the size of the revocation list. Specifically, we conduct our comparison in two categories: computational cost and computation time.

Table 3. Comparison of Performance Analysis

• Computational cost. We consider the two most expensive operations, particularly scalar multiplication and pairing evaluation. If exponentiation is used, it will be changed into scalar multiplication to ease the comparison. According to [12], in usual implementation, one exponentiation in 𝔾_𝑇 (𝔾₃ in MLGS) costs about 4 scalar multiplication in 𝔾₁. We use this trick to transform our observation of operation used in [11, 12, 16] into the operation presented in computational cost column of Table 3. In addition, a multi-base pairing is similar to a single-base pairing as they almost have the same overhead [29]. Now, we add both `revocation check' and `signature check' operations to get a full operation of verification phase. We then have 5. 𝔾₁ + 3. 𝑃 for GSIS, 8. 𝔾₁ + 5.𝑃 for TAA, and 6. 𝔾₁ + 2. 𝑃 for the improved MLGS. Since the cost of pairing evaluation is more expensive compared to scalar multiplication [30], we see that the computational cost for our work is better than GSIS and more costly efficient compared to TAA as our work has the least pairing operation compared to others. Our work requires two pairings, while GSIS and TAA require three and five pairings respectively.

• Computation time. According to the experiment in [31], to calculate the time taken to perform a pairing operation and a scalar multiplication, we observe the processing time for an MNT elliptic curve running on an Intel Pentium IV 3.0 GHZ machine. We set the curve with embedding degree 𝑘 = 6 and 𝑞 = 160 bits to achieve security level of 80 bits. Then, we obtain the following results: one pairing evaluation and one scalar multiplication in 𝔾1 can be done within 4.5 ms and 0.6 ms respectively. Using this information, we calculate the computation time of operations tabulated in the computational cost column of Table 3. For instance, we take `revocation check' operation in our work, i.e 1. 𝑃, then we multiply it by 4.5 ms × 𝑛, where 𝑛 is the length of the revocation list to obtain 4.5 ms × 𝑛. Similarly for the `signature check', i.e. 6. 𝔾₁ and 1.𝑃, we multiply each of them with 0.6 ms and 4.5 ms respectively before adding them up together to obtain 8.1 ms as a total. We present the rest of the calculation result in Computation Time column of Table 3. We observe that our revocation check is twice as fast as GSIS but it is slower than TAA. However, TAA takes three times significantly longer to perform signature check. Even though GSIS outperforms in term of signature check, its revocation check is the longest compare with other schemes. We note that the difference of signature check between GSIS and our work differ by less than 1 ms.

We depict Fig. 5 and Fig. 6 for a clear comparison of the computation time by calculating the value of 𝑛𝑛 (the length of the revocation list). Fig. 5 shows that our work requires the least computation time when 𝑛 < 5 MB. Meanwhile, when 𝑛 ≥ 5 MB illustrated in Fig. 6, our work is more efficient than GSIS but slower than TAA. However, we note that our work proposes credentials update procedure when the size of the revocation list is larger than a certain threshold. Thus, when the threshold is set at 5 MB, Fig. 6 will not be applicable as revocation will be carried out by credentials update procedure.

Fig. 5. Increase of computation time when 𝑅L < 5 MB

Fig. 6. Increase of computation time when 𝑅L ≥ 5 MB

From the above analysis, our work shows better performance compared to GSIS in both computational cost and computation time and achieves comparable performance to TAA. TAA competes in terms of computation time when the size of revocation list is 5 MB and above, but this is not applicable when credentials update takes it roll. In addition, TAA's computation cost is the most expensive compared to others. In this comparison, we note that our work shows better performance which requires the least cost and operates at comparable pace.

6.2 Simulation 

We evaluate the performance of our revocation protocol by using the MATLAB platform. This MATLAB platform has also been used in other previous works [32-36]. We use the freeway mobility model that is of size 10000 m² with 4 lanes, 3 entry ramps, 3 exit ramps, and vehicles move in one direction. The simulation road scenario is shown in Fig. 7. In this model, we allow a vehicle to change lanes and overtake the leading vehicle only if there is no vehicle within the vehicle’s safety distance, 𝑑_𝑠 of 10 m. We note that this freeway mobility setting which represents a common scenario encountered in Europe and North America has also been used in other work such as in [37-39]. We selected 500 vehicles randomly distributed on the freeway lanes with each vehicle has a transmission range of 300m. This is a common range used in [9, 16, 18, 19] and it follows the IEEE 802.11p standard, that is, the transmission range can be up to 1000m [40]. The adopted simulation parameters are listed in Table 4. The simulations run for 5 trials for 10 minutes duration each. We simulate our protocol from the following aspects:

Fig. 7. Road scenario for simulation

Table 4. Simulation Parameters

• Revocation delay versus the number of revocation reports: The time taken to perform cryptographic operations to verify revocation reports.

• Revocation delay versus the number of revoked vehicles: The increment of revocation delay due to the increasing number of revoked vehicles in the certificate revocation lists.

Revocation delay is an important issue in revocation protocols in VANETs as it evaluates the efficiency of a protocol to revoke the misbehaved vehicles from the network. The longer the delay times, the lower the number of misbehaved vehicles can be removed from the network. We classify the issue of revocation delay into two categories: 1) the time taken to perform the cryptographic operations in order to verify the validity of a revocation report, and 2) the time taken to perform the cryptographic operations when the number of revocation reports increases. We note that the cryptographic operations are the scalar multiplication and pairing operation as they are the most time-consuming operations for a revocation protocol [41]. The first issue has been addressed in Section 6.1 where we have shown that our protocol achieves better cryptographic performance than the other two schemes [12,16]. Meanwhile, the second issue which focuses on scalability matter will be evaluated as follows.

We recall in Table 3 that our work requires 6. 𝔾₁ + 2. 𝑃, GSIS [16] requires 5. 𝔾₁ +3. 𝑃, and TAA [12] requires 8. 𝔾₁ + 5. 𝑃 to verify a revocation report. We now use this information to evaluate the revocation delay of our work when the increasing number of revocation reports is considered and we compare the result with TAA and GSIS schemes to assess overall performance. We also assume that each vehicle may broadcast one revocation report and thus 500 vehicles may broadcast a total of 500 reports in this experiment. Fig. 8 shows the simulation result of the revocation delay with respect to the number of revocation reports. The results of the experiments show that the revocation delay increases when the number of revocation reports increases. This is natural since if there are more revocation reports to be verified, there will be more cryptographic operations to be performed and thus resulting in longer revocation delay. We observe our work has the lowest revocation delay, followed by GSIS and TAA schemes. This is due to the fact that our proposed protocol has the least pairing operation. Our protocol uses 2. 𝑃, GSIS uses 3. 𝑃 and TAA uses 5. 𝑃. As discussed in Section 6.1, pairing operation takes longer computation, that is, 4.5 ms compared to scalar multiplication which only takes 0.6 ms for computation. This proves that our proposed protocol significantly outperforms the other schemes in terms of revocation delay when the number of revocation reports increases in the network.

Fig. 8. Revocation delay versus the number of revocation reports

Fig. 9 shows the simulation results of the revocation delay with respect to the number of revoked vehicles in the revocation lists. In this experiment, we set the threshold 0.25 for the number of revoked vehicles in the revocation list as in [42] to evaluate the effectiveness of the protocol. In other words, the number of revoked vehicles must be within one fourth from the selected 500 vehicles. If the number of revoked vehicles appears to be above the said threshold, credential updates operation takes over the situation. The results of the experiment show that the revocation delay increases when the number of revoked vehicles increases. This is reasonable, as when the size of the revocation list grows longer due to an increase of the number of revoked vehicles in the network, the time taken to look up for the revoked vehicles in the list also becomes longer. From Fig. 9, it is clear that our work has the least revocation delay with respect to the number of revoked vehicles, followed by GSIS and TAA schemes. The reason for the least delay in our work is because of the efficiency of the proposed cryptographic operations. The same operation is used for the revocation look up operation, that is, 2. 𝑃 in our work, 3. 𝑃 in GSIS [16] and 5. 𝑃 in TAA [12]. Hence, our protocol is faster and outperforms [12,16].

Fig. 9. Revocation delay versus the number of revoked vehicles

The simulation results demonstrate the practicability and efficiency of our proposed revocation protocol when evaluated using real VANET environment. Our protocol requires the least pairing operation which performs significantly faster than the existing schemes of [12,16] and this allows our protocol to scale well with the increase in the number of revocation reports and revoked vehicles in the network. Hence, our protocol provides better efficiency and scalability.

7. Conclusion

In this paper, we have presented a secure and efficient revocation protocol for group signature schemes in VANETs. Our protocol adopted VLR technique and credentials update procedure to remove misbehaved vehicles from the network. We have shown that our revocation protocol can solve the revocation issue for group signature schemes that proposes vehicles to generate its own tracing information in the system. Meanwhile, our generic abstraction may assist to provide guidelines to design future revocation protocol based on group signatures. As far as we are aware of, this is the first generic abstraction for revocation in group signatures exists in the literature. Our proposed revocation protocol not only provides the desired level of security but also performs better than the other group signaturebased schemes of GSIS [16] and TAA [12].

For future work, it might be of interest to explore other cryptographic techniques that can vastly improve the performance efficiency for a secure revocation protocol. Moreover, it would be interesting to design revocation protocol based on other cryptographic primitives.