SD2PA: a fully safe driving and privacy-preserving authentication scheme for VANETs

Abstract

The basic idea behind the vehicular ad-hoc network (VANET) is the exchange of traffic information between vehicles and the surrounding environment to offer a better driving experience. Privacy and security are the main concerns for meeting the safety aims of the VANET system. In this paper, we analyse recent VANET schemes that utilise a group authentication technique and found important vulnerabilities in terms of driving safety. These systems also suffer from vulnerabilities in terms of management efficiency and computational complexity. To defeat these problems, we propose a lightweight scheme, SD2PA, based on a general hash function for VANET. The proposed scheme overcomes the non-safe driving problem that resulted from the critical driving area. Moreover, the vehicle authentication is only done once by the VANET system administrator during the vehicle’s moving, so the authentication redundancy for the entire system is reduced and system management efficiency is enhanced. The SD2PA scheme also provides anonymity to protect the vehicle’s privacy, unless an important action needs to be taken against a malicious vehicle. A deep computational cost and communicational overhead analysis indicates that SD2PA is better than related schemes, as well as efficiently meeting VANET’s security and privacy needs.

Introduction

The Vehicular Ad-Hoc Network (VANET) is a subset of the wireless network. It is made from the Mobile Ad-Hoc Network (MANET) principle, through which vehicles within communication range can wirelessly exchange traffic-related data and other supplemental information under a transportation system [1]. The aim of VANET is to enhance navigation and transportation systems to increase trustworthiness and safety in the transportation environment. VANETs are efficient as long as they deliver travel efficiency and safety through real-time information assistance by launching connections vehicle to vehicle (V2V) and vehicle to road-side infrastructure (V2I) that can significantly enhance the driving experience through smart controls and offer higher relaxation and travel experience for travelers [2].

A VANET mainly consists of a trusted authority (TA), roadside units (RSUs) and vehicles equipped with on-board units (OBUs) for V2V and V2I communications duty. OBUs communicate with each other and with RSUs through a wireless public channel using the dedicated short-range communication (DSRC) protocol that applies the IEEE 802.11p standard for wireless communication, and RSUs connect to TA via a wired channel [3, 4]. The TA is a large storage capacity and high computational power trusted third party; it is responsible for generating and managing the system parameters and issuing secret tackles. A RSU is a communication bridge party that has better computation abilities and memory capacity than OBUs; it deployed as road-side infrastructure to play specific management and coordination roles. Some VANETs use a Tamper-Proof Device (TPD) attached to OBUs or RSUs. A TPD is fully secured and used to store and calculate sensitive data. [5]. The general architecture of a VANET scheme is shown in Fig. 1. According to the DSRC protocol, OBUs broadcast messages each 100–300 ms, traffic-related messages consist of vehicle speed, position, congestion state, current time, track, and so on. With the help of this information, the system can offer an ideal solution for vehicle route and safety [6, 7].

Fig. 1

System architecture

As a result of the worthy traffic safety and efficiency solutions enabled by launching a VANET, and due to the nature of the open wireless communication used in VANETs, the message exchange in VANETs may be subject to the security risk of data interception, detection, modification and replication by malicious challengers. Thus, a strong mechanism for identity authentication and message integrity is the success key to certify the security of VANETs [8, 9]. Any defect in the authentication mechanism, a malicious vehicle may cause serious disturbance for the traffic through impersonating another true\ valid vehicle or even alter true messages to broadcast fake messages for the nearby vehicles to gain illegal benefits [10].

However, securing strong privacy is another important issue for VANETs. The real identity, location and route of a particular vehicle should not be attainable by the malicious vehicle [11]. Any specific leakage in the vehicle’s information, like the route information, may cause Serious consequences where that information may be used for traffic or criminal accidents by malicious vehicles. Although the vehicle’s privacy should be completely protected in the VANETs, these systems should consider conditional privacy, in which the message sender vehicle usually should involve a piece of non-linkable information such that only TA can identify the message sender vehicle whenever it required [12,13,14,15]. For example, if malicious vehicles start to disturb the system (e.g., sending malicious messages), then the TA should be able to trace this vehicle and take a proper revocation action required. Hence, the conditional privacy-preserving authentication (CPPA) mechanism [8], which can offer both conditional privacy and message authentication is properly able to satisfy the VANETs security and privacy requirements. In summary, three main issues must be well considered in VANET schemes: security, efficiency, and preservation of conditional privacy before such systems are deployed in practice.

Over the past decade, VANET-related systems have attracted massive interest from academia, governmental organizations and industry. Industrial and academic groups have done many VANET-related studies, which have yielded many valuable accomplishments in different related aspects [16,17,18,19,20]. However, although earlier offered authentication schemes could solve some security and privacy issues in VANETs, additional studies are still needed to solve other important issues such as driving safety, system performance, security and privacy. Lately, interesting CPPA VANET schemes have been proposed by various groups [21,22,23]. However, we have discovered important vulnerabilities in these schemes in terms of driving safety, efficiency and performance. We, therefore, propose an efficient CPPA scheme for VANET that successfully handles the aforementioned issues and satisfies the needs and goals of VANETs.

The main contributions of our SD2PA scheme are summarized below.

• We propose a novel efficient and lightweight VANET scheme that overcomes a critical driving area problem found in existing group-based authentication schemes. A general hash function has been adapted during data transitions for the entire system without requiring heavy-weight bilinear pairings or Elliptic-curve cryptography (ECC).

• We made a detailed security analysis and demonstrate that our scheme meets the security requirements for VANETs.

• We have enhanced the vehicle authentication process so that it does not cause a bottleneck for the TA.

• We have mitigated the communication and computation weights for the available schemes.

The motivation of this paper is to give a comprehensive view of the VANET system and its components. Due to the heterogeneous nature and the dynamic topology of this network caused by the fast-moving of the vehicles, the need for a fast-real-time messages exchange and response, and the power\memory limitation especially in the OBUs, make the VANETs under different security and privacy issues. Therefore, in this paper, we highlight the major security and privacy challenges and concerns of VANETs, also, we give a review of some security, privacy, and efficiency vulnerabilities in some existing schemes proposed in related literature. However, the main motivation of this paper is to identify an important weakness in terms of safe driving—within the scope of security mechanism related to real-time V2V traffic-related beacons exchange—in some of the existing group signature\verification based VANET schemes. Finally, we present our lightweight SD2PA scheme that can satisfy the security and privacy needs of the VANETs and overcome the aforementioned issues.

The remainder of this paper is ordered as follows: “Related works” section, summarizes some previous related works. “Preliminaries” section describes the Preliminaries of our proposed scheme, while the “Review of the critical driving area problem” section identifies and discusses a critical driving area problem in recent related VANET schemes. “The proposed scheme” section provides a detailed explanation of our proposed scheme. “Security analysis” gives a detailed security analysis, while the “Performance analysis” discuss the performance of our approach and show its enhancements with compare to other related schemes, while the “Conclusion” section presents the conclusion of this paper.

Related works

Extensive studies have been proposed to improve the driving safety and system efficiency of VANETs. In general, three main categories of VANET schemes have been proposed in the literature: schemes based on either public key infrastructure (PKI) or group signature and identity-based schemes.

The authors in [24, 25] have proposed CPPA schemes based on PKI and used pairs of public/private keys and matching certificates to protect the identity of the vehicle. However, this has two evident defects: first, the vehicle’s OBU requires a big storage capacity to store the pairs of certificates and private/public keys; second, the TA needs to perform a full cross-check in its storage area while searching for the real identity of the challenger, which is a time-consuming process and increases memory overheads. Such VANET schemes suffer from a storage and certificate management bottleneck problem.

In the group-based signature VANET schemes, a number of vehicles comprise one group, and each vehicle within a specific group must have its own private key and a public key shared with the other group members. Such authentication schemes will face critical driving problems. Interesting schemes have been presented in [26,27,28,29]; however, in this model, the sender vehicles sign their messages with their private keys, and the vehicles receiving the messages use the corresponding public keys to verify and validate the message. However, high-speed vehicle movement, as well as the rapid changes in VANET topology, creates many management challenges in group manager election and group member management [30]. The group signature is also heavier than a simple signature, which makes the communication cost, computation weight and signature verification not efficient for VANETs.

To deal with the above-mentioned problems, ID-based authentication schemes have been proposed for VANET systems. Zhang et al. [31] proposed an ID-based CPPA VANET scheme based on bilinear pairing. In this scheme, RSUs and vehicles use a pseudo-identity as a public key, while the private key generator (PKG) generates the private keys. Unlike the PKI schemes, it avoids the need to generate, manage and store a large number of certificates in the entities. Chim et al. [32] proved that the scheme proposed by [31] is vulnerable to anti-traceability resistance and impersonation attack and proposed a new secured VANET scheme. Horng et al. [33] showed that the scheme in [32] is vulnerable to impersonation attacks and proposed a new secured scheme to overcome the problem in [32]. Shim [34] suggested a security ID-based CPPA scheme, wherein batch message verification is supported by the RSU to enhance its computation overhead in case the number of messages is high. However, to retrieve the entire revocation list, the TA needs to consume more time; it also does not consider the authentication overheads affected by illegal materials. Moreover, Liu et al. [35] showed that the security level in the ID-based signature scheme in [34] does not satisfy the security requirements and is vulnerable to modification attacks.

Numerous other ID-based CPPA schemes such as [35,36,37,38,39] have been proposed that claim to guarantee the privacy-preserving and security requirements. However, the designs of these schemes are based on bilinear pairings, which, due to their heavy computational cost, are not efficient enough for VANETs. Based on the ECC, numerous ID-based CPPA schemes such as [40,41,42] have been proposed. Although these schemes offer better performance than those that use the bilinear pairing technique, due to the nature of the VANET nodes and system efficiency requirements, these schemes do not satisfy the ideal VANET performance effectiveness. However, although ID-based CPPA schemes could overcome the PKI’s computational, communication and management issues, they are vulnerable to system key escrow, insider attacks and batch verification challenges. In such schemes, the private system key is known to all vehicles, so any insider attack could broadcast a fake beacon on behalf of any other vehicle, and any violation in the system key would also damage the entire system.

Recent attention-grabbing studies have been proposed to deal with the VANET authentication issues. Jie Cui et al. [21] proposed a novel edge-computing concept for a CPPA VANET scheme. Jie Cui et al. [22] proposed a secure hash function–based and group-key agreement CPPA VANET authentication scheme. Jie Cui et al. [23] proposed a VANET pseudonym-based authentication CPPA Scheme with cuckoo filter. Unfortunately, we found that these schemes [21,22,23] were vulnerable to important problems in terms of safety, efficiency and computational cost.

In [21], each RSU has to choose the higher computational resources and closer location of one or more vehicles from among the in-range vehicles to play the role of an edge layer between the RSU and other ordinary vehicles. We know that in VANET networks we cannot guarantee the availability of those kinds of high computational vehicles, and the high speeds of moving vehicles and the fast-changing VANET topology also create difficulties for the RSU to frequently choose special vehicles for edge computing cooperation.

In [22], a scheme based on a group key agreement mechanism is proposed for vehicle authentication, but again, the high vehicle speed and fast-changing network topology create difficulties in group key regeneration, in which the TA needs to regenerate a secret group key each time a vehicle joins or leaves the group, causing a bottleneck for the TA.

In [23], the proposed scheme uses heavy and ineffective signature verification procedures. We also found that the presented schemes [21,22,23] have a serious critical driving area between every two RSUs that may create disastrous accidents and risks.

In this paper, we identify the critical driving area problem available in aforementioned schemes. Besides, we propose a novel and efficient lightweight pseudo-identity-based CPPA VANET solution that overcomes the critical driving area and system key escrow problems, as well as offering better performance in terms of computation cost and communications overhead for the entire VANET system. In addition, our scheme can easily prevent an attacker or a trusted vehicle from continuing to send malicious or fake beacons. Finally, our scheme overcomes the batch verification problems and TA bottlenecking.

Preliminaries

In this section, we give a brief overview of the system model, assumptions, and goals, in addition to the hash function and the cuckoo filter that we used in our proposed scheme. Some notation definitions are shown in Table 1.

Table 1 Notations

System model and components description

The main VANET architecture components in our scheme consist of three items: TA, RSU and OBU, as shown in Fig. 1.

• 1. TA: The TA is a trusted third-party centre that is responsible for registering and managing all of the RSUs and OBUs on the network, and it never gets compromised [43]. We assume that the TA and RSUs use secured wired channels and secured transmission protocol, like the wired Transport Layer Security (TLS) protocol. However, redundant TAs can be installed to avoid a failure point or bottleneck [44].

• 2. RSUs: The RSU is trusted and difficult to compromise. RSUs enjoy better computational power than OBUs. They act as an intermediate communication and management bridge between TAs and OBUs. The RSU–OBU communication range is not less than double the inter-vehicle broadcasting range so that the RSU can ensure that, when it receives messages, all vehicles that received the message will be within its communication and notification range. RSUs can cooperate using a secured communication channel [45]. We assume that RSUs are regionally well distributed according to the real need in a way that guarantees the full interaction between RSUs.

• 3. Vehicles: The vehicles are equipped with an OBU that supports the DSRC protocol; they communicate with each other, as well as with the RSU wirelessly using the OBU. Note: With the help of DSRC, the inter-vehicle broadcasting range can extend across a few hundred meters [46].

Security objectives

Recent works of interest [47,48,49] presented necessary security goals in related systems. However, due to the unique characteristics of VANET environment [15, 24], a well-designed CCPA scheme should satisfy the security goals below:

• 1. Message integrity and authentication: A system of nodes or vehicles has to be able to confirm that the received messages are signed by the sender vehicle and have not been modified.

• 2. Identity privacy preserving: An unauthorised malicious object should not be able to recognise or determine the vehicle’s real identity by considering several messages broadcast by the same sender vehicle.

• 3. Traceability and revocability: Although the vehicle’s identity must be hidden from ordinary message receivers to keep the sender’s privacy and security safe, the TA has to be able to find the real identity in case tracing or revocation action is required.

• 4. Non-repudiation: The vehicle cannot repudiate a message that it sent.

• 5. Un-link-ability: The attacker must not be able to recognise the sender vehicle from the content of the message sent by the same vehicle.

• 6. Resistance to attacks: VANET system design should consider resistance to attacks, like impersonation, replay and modification attacks.

• 7. Lightweight: The nature of VANET scheme topology requires taking into account huge data exchange, fast vehicle mobility and the ordinary processing abilities of the OBUs to create lightweight computation costs and communication overhead, which are the keys success for any VANET scheme.

The one-way hash function

h(.) is said to be secure when it satisfies the following properties [43]:

• 1. h(.) can take a random-length message as input and give a fixed-length message output.

• 2. Finding k = h(n) from a certain x is easy. However, it is difficult to find n = h − 1 (k) from a certain k.

• 3. Computationally, for a given n, it is impractical to detect $n^{\prime}$$\ne$$n$ such that h $(n^{ '} )$$\ne$h($n)$.

Cuckoo filter

The cuckoo filter is a new and efficient data structure that offers ideal performance, more accurateness, and lesser false positives than the other available filters. The cuckoo filter supports dynamic addition and removal, which results in high performance [50]. It is fundamentally a hash table that contains a series of cells, and each cell has a fixed number of entries –the hash function along with a lower-bit output. For a piece of data, d, the hashing function finds the index of two candidate buckets, $Ind_{1}$ and $Ind_{2}$, according to the following:

$$ {\text{Ind}}_{1} = h\;(d)\;\bmod \;N $$

(1)

$$ {\text{Ind}}_{2} = \left( {{\text{Ind}}_{1} \oplus h\left( {Fingerprint\text{(}d\text{)}} \right)} \right)mod\;N $$

(2)

where N is the size of the cuckoo filter. If there is a free bucket from the existing candidate buckets, then we store the fingerprint in it. Otherwise, we pick an existing item from a selected candidate bucket and re-insert it into its alternating buckets; this process is continued until finding a free bucket, as shown in Fig. 2, which shows h1 (d) and h2 (d) assigned to buckets that allocated already. To check whether item d is in the cuckoo filter, we compute Fingerprint (d) and the two linked buckets using (1) and (2). If the result of Fingerprint (d) matches any of the two linked buckets, then the cuckoo filter returns true, otherwise, it returns false. Therefore, utilizing this filter in VANETs can play an efficient notification or verification role through the fast saving and retrieving hashed signatures during the real-time message exchange. Thus, it can enhance the overall system performance efficiency.

Fig. 2

Relocation process in cuckoo filter

Review of the critical driving area problem in the [21,22,23] CCPA schemes

In the schemes proposed by Jie Cui et al. [21,22,23], the vehicle needs to be frequently authenticated by the TA at each time it leaves one RSU\group to join the next RSU\group. In this situation, we found that a critical driving area appears in those systems; that is, when a vehicle $A$ moves from the range of one RSU\group to the range of a new RSU\group, it can be authenticated and exchange beacons only when it has already entered a new RSU\group. At the same time, vehicle $A$ will not be authenticated and cannot exchange beacons with nearby vehicles in the old RSU/group once it joins the new RSU\group. This creates a risky, critical and non-safe driving area, where valid beacons from trusted vehicles will not be accepted by nearby vehicles in the neighbouring RSU, which may result in tragic accidents. As shown in Fig. 3, in schemes [21,22,23] the vehicles within the range of RSU₁ are only authenticated in RSU₁, and the vehicles within the range of RSU₂ are only authenticated in RSU₂, and so forth. The vehicles in the area $C_{1}$ and the vehicles in the area $C_{2}$ will, therefore, ignore each other’s beacons and cannot exchange beacons, which makes those areas ($C_{1} ,C_{2}$) critical driving areas that could cause VANET safety failures. Therefore, in this paper, driving safety-related term\issues fall within the scope of the security-related issues ($C_{1} ,C_{2}$). Where the safe driving aim for VANETs can only be achieved through considering all the valid V2V real-time traffic-related beacon.

Fig. 3

Critical area review

The proposed scheme

In this section, we introduce SD2PA. Our scheme consists of two main parts. The first part is the system initialisation and setup, which is offline and done only once unless there is a need for a system update. Whereas, the second part is an online vehicle authentication procedure and navigation management.

In our SD2PA scheme, the TA arranges the system materials and assigns the setup parameters and data to the system members (RSUs and OBUs). It also can allow valid vehicles to join the VANET, trace, and revoke any misbehavior vehicle. To join the VANET, each OBU needs to trigger a mutual authentication handshake with the TA. Thereafter, using a predefined OBU-RSU secret key, a joined OBU can broadcast signed traffic-related beacons. From a receiving nodes side: the concerning RSU will be in charge of verifying the signatures. Besides, utilising the Cuckoo filter, it stores the positive and negative fingerprints of the valid and non-valid OBUs\signatures. Each RSU broadcasts the Cuckoo filter with a notification message for all the in-range OBUs. In which the receiving OBUs can, efficiently, validate the received traffic-related beacons by considering the positive and negative fingerprints in the Cuckoo filter obtained from the notification message received from the RSU. A detailed explanation in the following subsections.

System initialization and setup phase

This subsection demonstrates the initialisation setup process, carried out by the TA.

• 1. TA initialization

  In SD2PA scheme, the following initialisation procedures will be done once during the system life cycle, unless there is a need for an update.

  • The TA selects the hash function h(.).

  • The TA shares the system hash function to all RSUs and OBUs during their registration to the VANET.

  • The TA assigns a unique identity of RSU $ID_{\text{R}}$ and secrete key $SK_{R - TA}$ for every RSU, as well as sending { ${\text{ID}}_{{{\text{R}} - 1}}$,${\text{ID}}_{{{\text{R}} + 1}}$ }, where (${\text{ID}}_{{{\text{R}} - 1}}$,${\text{ID}}_{{{\text{R}} + 1}}$) represent the identities of the previous and next neighbour for the current ${\text{RSU}}$.

• 2. Vehicle registration

  In this phase, the TA assigns $\left\{ {RID_{i} , PWD_{1} , PWD_{2} , CR_{i} , S_{R - V} } \right\}$ to the OBU for each vehicle $V_{i}$, where $RID_{i}$ is the $V_{i}$’s real identity, $PWD_{1}$ is the $V_{i}$’s password, $PWD_{2} \in Z^{ *}$ is a secret key known only to the OBU and the TA, $CR_{i} \in Z^{ *}$ is a conventional public key and $S_{R - V} \in Z^{ *}$ is a unique authentication secret key to be used for verification purposes between the RSU and OBU during the $V_{i}$ broadcasting phase. After that, the TA saves $\left\langle {RID_{i} , PWD_{1} , PWD_{2} , CR_{i} , S_{R - V} } \right\rangle$ into the registration list $L_{TA - OBU}$ and provides $\left\langle {RID_{i} ,PWD_{1} } \right\rangle$ to the vehicle’s owner. Those procedures are to be done once and offline.

Authentication phase

All of the RSUs in the VANET broadcast the ${\text{ID}}_{R}$ periodically; whenever a vehicle starts working, it needs to be authenticated to join the system through the following handshake procedure. Figure 4 illustrates the procedure of this phase.

Fig. 4

The authentication process

• 1. Vehicle $V_{i}$’s owner has to enter the identity $RID_{i}$ and passwords $PWD_{1}$ to start the OBU, then the OBU checks whether $RID_{i}$ and $PWD_{1}$ match the stored verification data; if they do, it then proceeds to the following steps:

  • The OBU generates a random number $i \in Z$ and then computes $I$ and $PID_{i}$, where $I = i \oplus PWD_{2}$ and $PID_{i} = RID_{i} \oplus h\left( i \right)$.

  • The OBU computes $\mu_{auth} = h\left( {T_{1} ID_{R} PID_{i} ICR_{i} RID_{i} S_{R - V} } \right)$, then sends $\left\{ {T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} } \right\}$ to the current $RSU$.

• 2. Once the current RSU receives the message $\left\{ {T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} } \right\}$ from the OBU, it checks the validity of the timestamp $T_{1}$. The timestamp $T$ is said to be valid if the $\vartriangle T > T_{rs} - T$, where $T_{rs}$ is the receiving timestamp and $\vartriangle T$ is a predefined time difference. If the timestamp $T_{1}$ is valid, then the RSU will store the data $\left\langle {T_{1} , PID_{i} , CR_{i} } \right\rangle$ into the temporary list $L_{tmp}$ and calculates ${\text{SIG}} = {\text{h }}\left( {T_{2} \left\| {ID_{R} } \right\|SK_{R - TA} } \right)$ forward the message $\left\{ {T_{2} , T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} ,SIG } \right\}$ to the TA, where $T_{2}$ is the timestamp for the RSU.

• 3. Once the TA receives the message $\left\{ {T_{2} , T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} ,SIG } \right\}$ from the RSU, it checks the validity of the timestamp $T_{2}$; if it is valid, it then proceeds to the steps below.

  • According to the receiving $RSU$’s $ID_{R}$, the TA finds the corresponding $SK_{R - TA}$ from its repository and examine the $RSU$’s signature ${\text{SIG}}_{ = }^{?} {\text{h }}\left( {T_{2} \left\| {ID_{R} } \right\|SK_{R - TA} } \right)$. If invalid, it drops the message, otherwise, it performs the coming steps.

  • Based on the receiving OBU’s key, $CR_{i}$, the TA extracts the corresponding secret key $PWD_{2}$ from the registration list $L_{TA - OBU}$ and calculates $i '= I \oplus PWD_{2}$ and $RID_{i}^{ '} = PID_{i} \oplus h\left( {i '} \right)$.

  • The TA matches $RID_{i} '$ with the supposed $V_{i}$’s $RID_{i}$ that is already stored in $L_{TA - OBU}$; if these match, then the TA extracts the $V_{i}$’s corresponding $S_{R - V}$ and checks the equation $[{\mu _{auth}}_ = ^?h\left( {{T_1}\left\| {I{D_R}} \right\|PI{D_i}\left\| I \right\|C{R_i}\left\| {RI{D_i}} \right\|{S_{R - V}}} \right)]$. If this is valid and the $V_{i}$ is not in the revocation list, the TA calculates $\beta = {\text{h}}\left( {{\text{T}}_{3} \left\| {{\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right.} \right) \oplus S_{R - V}$ then sends the message $\left\{ {T_{3} , T_{1} , \beta , PID_{i} , CR_{i} ,\uplambda} \right\}$ to the RSU, where $\uplambda = {\text{h}}\left( {T_{1} \parallel T_{3} \parallel S_{R - V} \parallel PID_{i} \parallel CR_{i} \parallel {\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right)$.

• 4. Once the RSU receives the message $\left\{ {T_{3} , T_{1} , \beta , PID_{i} , CR_{i} ,\uplambda} \right\}$, it checks the timestamp $T_{3}$; if it is valid, then, the RSU extracts the ${\text{RSU}}\_{\text{OBU }}$ authentication key $S_{R - V}$ from the equation $S_{R - V} = {\text{h}}\left( {{\text{T}}_{3} \left\| {{\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right.} \right) \oplus \beta$, and checks if ${\uplambda }_{ = }^{?} {\text{h}}\left( {T_{1} \parallel T_{3} \parallel S_{R - V} \parallel PID_{i} \parallel CR_{i} \parallel {\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right)$. If valid, it retrieves the corresponding data $\left\langle {T_{1} , PID_{i} , CR_{i} } \right\rangle$ from $L_{tmp}$. It then stores $\left\langle {S_{R - V} , PID_{i} ,indx } \right\rangle$ into its ${\text{RSU}}\_{\text{OBU }}$ authentication list $L_{RSU - OBU}$. Note: we assume that the coverage capacity for each RSU is 400 to 600 vehicles. For efficient performance, we propose adding a group index ($indx$) for every 30 OBUs on the $L_{RSU - OBU}$. That is, we add one group index $indx$ for every 30 OBUs within the RSU, although the group amount is adjustable by RSU. In another word, we propose to repeat the same $indx$ (row) number for the true vehicles on the $L_{RSU - OBU}$_ in our case, we repeat the same $indx$ number for every 30 rows on the $L_{RSU - OBU}$_ so that, we can achieve an efficient performance as well as avoiding any traceability or likability attempt of an adversary vehicle or attacker. Finally, the RSU sends the message $\left\{ {T_{4} , L, index} \right\}$ to the OBU, where $L = h\left( {S_{R - V} \left\| {PID_{i} } \right\| CR_{i} \left\| {T_{4 } } \right\|indx} \right)$.

• 5. Once the OBU receives the message $\left\{ {T_{4} , L, index} \right\}$, it checks the timestamp $T_{4}$, if it is valid, it then checks $L_{ = }^{?} h\left( {S_{R - V} \left\| {PID_{i} } \right\|CR_{i} \left\| {T_{4 } } \right\|indx} \right)$. If this holds, it then stores the $indx$ into its repository. This completes the authentication handshake process, and the vehicle can broadcast beacons.

Broadcasting phase

When a vehicle, ${\text{V}}_{\text{i}}$, wants to broadcast a beacon, the OBU calculates a signing key $\upgamma = {\text{h}}\left( {{\text{T}}_{5} \left\| {{\text{PID}}_{\text{i}} } \right\| {\text{S}}_{{{\text{R}} - {\text{V}}}} \left\| {{\text{M}}_{\text{i}} } \right\| {\text{ID}}_{\text{R}} \left\| {\text{indx}} \right.} \right)$ and broadcasts the beacon $\left\{ {\upgamma, {\text{T}}_{5} , {\text{M}}_{\text{i}} , {\text{ID}}_{\text{R}} , {\text{indx}}} \right\}$.

Verification phase

According to the location of the sender vehicle, $V_{i}$, there are two possible verification cases, as shown below.

Case 1:

If the vehicle $V_{i}$ broadcasts beacons while it is not inside the critical area, then the RSU does the following steps.

• 1. When the RSU receives the beacon $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, it checks the timestamp $T_{5}$ and the $ID_{R}$. If the $ID_{R}$ is for itself not for any neighbouring RSUs and the timestamp is valid, it then examines the legitimacy of the OBU by verifying the receiving signed key $\gamma_{ = }^{?} h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right.} \right)$ with the help of the authentication data $\left\langle {S_{R - V} , PID_{i} ,indx } \right\rangle$ already stored in $L_{RSU - OBU}$. According to the $indx$, in the worst case, the RSU needs to identify 30 items in the $L_{RSU - OBU}$. If valid, the RSU then stores $fingerprint\left( {\gamma \parallel T_{5} } \right)$ in the positive cuckoo filter; otherwise, it stores it in the negative filter. The positive filter holds the fingerprints of the legal vehicles and the negative filter holds the fingerprints of the illegal vehicles. Finally, the RSU broadcasts the filters with each notification message.

• 2. When a vehicle $V_{j}$ receives the beacon $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$ from vehicle $V_{i}$, it checks the $ID_{R}$. If this is valid for its current RSU and the timestamp is also valid, it then verifies $V_{i}$’s signature by computing its fingerprint $f_{i} = fingerprint\left( {\gamma \parallel T_{5} } \right)$. It then gets two locations, $Ind._{1} = h\left( {\gamma \parallel T_{5} } \right)mod M$ and $Ind._{2} = Ind._{1} \oplus h\left( {f_{i} } \right)mod M$. Finally, it matches the result with the positive and negative filters received from the RSU broadcast. Four possible actions will be taken according to matching results shown in Table 2. Note: there is a very small probability of a false positive may occur in the cuckoo filter report [21, 47]. However, case 4 in Table 2 handles this issue.

  Table 2 Validation status and results on cuckoo filter

Case 2:

Sometimes vehicle $V_{i}$ broadcasts beacons while it is within the range of a critical area $C_{1}$, and the broadcasting range exceeds the range of vehicle $V_{j}$ in critical area $C_{2}$ of the neighbouring RSU. The broadcasting range of vehicle $V_{j}$ in the critical area $C_{2}$ will also exceed the range for vehicle $V_{i}$ in the critical area $C_{1}$. The vehicles on both sides of $C_{1}$,$C_{2}$ need to consider and verify each other’s beacons for the safety reasons mentioned earlier. However, in our SD2PA scheme, when a vehicle $V_{i}$ approaches critical area $C_{1}$, its current RSU sends the information $\left\langle {S_{R - V} , PID_{i} , ID_{R} ,indx} \right\rangle$ through a secured channel to the upcoming neighbour RSU, while the neighbouring RSU will do the same for vehicle $V_{j}$ in critical area $C_{2}$. The RSUs will temporarily store this information into the temporary list $Tlist$. According to the location of the beacon’s recipient, there are two possible verification procedures, as shown below:

• 1. If the recipient is the vehicle in the same RSU as $V_{i}$, steps 1 and 2 in case 1 are sufficient for the verification.

• 2. If the recipient is a vehicle $V_{j}$ in critical area $C_{2}$, then $V_{j}$ will follow the steps shown in the critical area verification phase.

Critical area verification phase

When a vehicle $V_{j}$ in the area $C_{2}$ receives a beacon from vehicle $V_{i}$, if first checks the $ID_{R}$ attached to the received beacon as well as the timestamp. Once it finds that the $ID_{R}$ is not its current RSU and the timestamp is valid, it then verifies $V_{i}$’s signature by computing its fingerprint and checks the result with positive and negative filters already received from its RSU. In case of positive or negative matches, it follows the procedures from the first and second result cases mentioned in Table 2. Otherwise, it forwards the entire beacon to the current RSU to help the sender vehicle $V_{i}$ be authenticated in the area $C_{2}$ while it is in $C_{1}$. As soon as this RSU receives the forwarded message, it will go through the following steps:

• 1. The RSU checks the $ID_{R}$ belonging to the neighbouring RSU. After that, it examines the legitimacy of the OBU by verifying the received signed key $\gamma_{ = }^{?} h\left( {T_{5} \left\| {PID_{i} } \right\|S_{R - V} \left\| {M_{i} } \right\|ID_{R} \left\| {indx} \right.} \right)$ with the help of the information $\left\langle {PID_{i} , S_{R - V} } \right\rangle$ from the vehicle ${\text{V}}_{i}$ that is already stored in $Tlist$.

• 2. If the verification check is valid, then the RSU stores $fingerprint \left( {\gamma \left\| {T_{5} } \right.} \right)$ in the positive cuckoo filter; otherwise, it stores it in the negative filter. Finally, the RSU broadcasts the filters with the notification message. The $Tlist$ will be vacated whenever the vehicle $V_{i}$ enters this new RSU coverage area or after a specified period of time.

New RSU joining phase

When the vehicle $V_{i}$ enters into the range of a new RSU, it will send a joining request message to the new RSU to get a new valid $indx$ in the new RSU authentication list $L_{RSU - OBU}$ as follows:

• 1. The OBU sends $\left\{ {T_{1} ,\gamma } \right\}$ to the RSU, where $\gamma = h\left( {T_{1} \parallel PID_{i} \parallel S_{R - V} } \right)$.

• 2. Once the new RSU receives the joining request message $\left\{ {T_{1} ,\gamma } \right\}$, it checks the timestamp. If this is valid, it then refers to $Tlist$ to verify the joining signature $\gamma_{ = }^{?} h\left( {T_{1} \parallel PID_{i} \parallel S_{R - V} } \right)$. If the joining signature is valid, it then proceeds to the next steps, otherwise, it ignores the request.

• 3. The new RSU shifts the relevant authentication information from $Tlist$ to $L_{RSU - OBU}$. Furthermore, it acknowledges the previous RSU of vehicle $V_{i}$ and forwards the new $indx$ to it, so that the previous RSU shifts the relevant authentication data from $L_{RSU - OBU}$ to $Tlist$ and acts as a neighbouring RSU. At the same time, the new RSU sends the message $\left\{ {T_{2} ,indx, L} \right\}$ to $V_{i}$, where $L = h\left( {T_{2} \parallel indx\parallel PID_{i} \parallel S_{R - V} } \right)$.

• 4. Once the OBU receives the message $\left\{ {T_{2} ,indx, L} \right\}$, it checks the timestamp $T_{2}$; if this is valid, it verifies the equation $L_{ = }^{?} h\left( {T_{2} \parallel indx\parallel PID_{i} \parallel S_{R - V} } \right)$. If this, too, is valid, then the joining authentication is complete.

Vehicle revocation phase

When a trusted vehicle $V_{i}$ broadcasts fake information, the TA in our scheme can efficiently find and revoke the vehicle’s real identity as follows:

• 1. The RSU finds the authentication information $\left\{ {PID_{i} \parallel S_{R - V} } \right\}$ in the $L_{RSU - OBU}$ that meets $V_{i}$’s signature $\gamma_{ = }^{?} h\left( {T_{5} \left\| {PID_{i} } \right\|S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right.} \right)$ and sends the $S_{R - V}$ to the TA.

• 2. According to the $S_{R - V}$, the TA extracts the $RID_{i}$ corresponding to $V_{i}$$S_{R - V}$ from $L_{TA - OBU}$.

• 3. The TA adds the $V_{i}$ authentication $\left\langle {RID_{i} ,S_{R - V} } \right\rangle$ data into the revocation list and reports it to the RSU.

• 4. Once the RSU receives the revocation report from the TA, it deletes the $V_{i}$’s authentication $\left\langle {PID_{i} ,S_{R - V} } \right\rangle$ from $L_{RSU - OBU}$, immediately preventing the malicious $V_{i}$ from disturbing the system.

Security analysis

This section discusses the security of the SD2PA scheme. It firstly demonstrates that SD2PA scheme can meet all the goals mentioned in the preliminaries section through the informal security analysis. Moreover, it presents the formal security analysis proof between OBU and RSU in SD2PA scheme using BAN Logic [51].

Security discussion

In this subsection, we prove that the SD2PA scheme fulfills all the mentioned security goals and compare it with the other schemes as shown in Table 3.

Table 3 The security and privacy comparison

• 1. Message integrity and authentication: In our scheme, the hash function h(.) is applied to the message signature. According to the definition of the hash function h(.), it is impossible to fabricate a valid beacon [43]. The secret key $S_{R - V}$ is also attached to the hashed data of the beacons. With the help of the signature $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\|S_{R - V} \left\| {M_{i} } \right\|ID_{R} \left\| {indx} \right.} \right)$, the RSU can efficiently ensure the validity and integrity of the message. The SD2PA scheme, therefore, provides the desired message integrity and authentication properties.

• 2. Identity privacy preserving: In the SD2PA scheme, the beacon contains $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, in which there is no identity-related information that can be used by an adversary to retrieve the vehicle’s real identity. The scheme, therefore, offers the desired identity privacy-preserving property.

• 3. Traceability and revocability: According to the vehicle revocation phase mentioned earlier, the SD2PA scheme provides the desired traceability and revocability properties.

• 4. Non-repudiation: In the SD2PA scheme, the beacon contains $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, where $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right\|} \right)$. As the vehicle has to use the secret key $S_{R - V}$ that is only known to the RSU, the vehicle cannot deny that it has sent the beacon in question. The SD2PA scheme, therefore, provides the desired non-repudiation property.

• 5. Unlinkability: In the SD2PA scheme, the vehicle broadcasts the beacon $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, which is different in each broadcasting operation. The $ID_{R}$ will be the same for all the vehicles within the RSU, and the $indx$ will be the same for every 30 vehicles within the RSU. It is therefore difficult for an adversary to expect that two beacons belong to the same vehicle. The scheme, therefore, provides the desired unlinkability property.

• 6. Resistance to attacks:

  • Modification attack: In the SD2PA scheme, the beacon contains $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, where $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right\|} \right)$. The adversary must, therefore, have the secret key $S_{R - V}$, if he or she wants to modify the beacon, which means this scheme is able to resist this type of attack.

  • Replay attack: In the SD2PA scheme, the timestamp is attached to each beacon and is added to the hashed signature $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right\|} \right)$. It is therefore impossible for an adversary to replay the beacon, making this scheme resistant to this type of attack.

  • Impersonation attack: In the SD2PA scheme, the beacon contains $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, where $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right.} \right)$. The adversary must have the secret key $S_{R - V}$, if he or she wants to impersonate the vehicle, making this scheme resistant to this type of attack.

• 7. Lightweight: In the SD2PA scheme, the beacon contains $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, where $\gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right.} \right)$. Only the one-way hash function is used for security, so the computation and communication costs are reduced. The authentication process with the TA is also only needed once during the driving phase. More details will be discussed in the next section.

Mutual authentication proof

In this subsection, we prove the mutual authentication validity between OBU and RSU with the help of the widely used BAN logic technique. The analysis shows that SD2PA scheme can achieve the designed authentication goals. Table 4 explains the relevant notations in the BAN logic analysis.

Table 4 The notations of BAN logic

Rules: The used rules for BAN logic analysis is shown below:

• R₁: Message meaning rule: $\frac{{\rho | \equiv \rho \mathop \leftrightarrow \limits^{K} \varrho , \rho \triangleleft \left( {X_{m} } \right)_{K} }}{{\rho \left| { \equiv \varrho } \right|\sim X_{m} }}$

• R₂: Freshness rule: $\frac{{\rho | \equiv \# \left( {X_{m} } \right)}}{{\rho | \equiv \# \left( {X_{m} ,Y_{m} } \right)}}$

• R₃: Nonce-verification rule: $\frac{{\rho | \equiv \# \left( {X_{m} } \right),\rho \left| { \equiv \varrho } \right|\sim X_{m} }}{{\rho \left| { \equiv \varrho } \right| \equiv X_{m} }}$

• R₄: Jurisdiction rule: $\frac{{\rho \left| { \equiv \varrho } \right| \Rightarrow X_{m} , \rho \left| { \equiv \varrho } \right| \equiv X_{m} }}{{\rho | \equiv X_{m} }}$

Goals: Our scheme fulfills the ultimate requirements of authentication for VANETs if it can achieve the following goals:

• G₁: $TA\left| { \equiv OBU} \right| \equiv \left( {\mu_{auth} } \right)$

• G₂: $TA\left| { \equiv RSU} \right| \equiv \left( {SIG} \right)$

• G₃: $RSU| \equiv \left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)$

• G₄: $OBU\left| { \equiv RSU} \right| \equiv \left( L \right)$

The idealized form: The transformation of our proposed scheme is viewed in the following:

• 1. The protocol messages are:

  • PM₁: ${\text{OBU}} \to {\text{RSU}}:\left\{ {T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} } \right\}$.

  • PM₂: $RSU \to TA:\left\{ {T_{2} , T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} , SIG} \right\}$

  • PM₃: $TA \to RSU:\left\{ {T_{3} , T_{1} , \beta , PID_{i} , CR_{i} , {\lambda }} \right\}$

  • PM₄: $RSU \to OBU:\left\{ {T_{4} , L, index} \right\}$

• 2. Idealizing the protocol messages are:

  • IM₁: ${\text{OBU}} \to {\text{TA}}:\left( {\mu_{auth} } \right)_{{h\left( {RID_{i} \parallel S_{R - V} } \right)}}$

  • IM₂: ${\text{RSU}} \to {\text{TA}}:\left( {SIG} \right)_{{h\left( {SK_{R - TA} } \right)}}$

  • IM₃: $TA \to RSU:\left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)_{{h\left( {SK_{R - TA} } \right)}}$

  • IM₄: $RSU \to OBU:\left( L \right)_{{h\left( {S_{R - V} } \right)}}$

Assumptions

The proof of our scheme relies on some assumptions as follow:

• A₁: ${\text{RSU}}| \equiv \# \left( {{\text{T}}_{1} ,{\text{T}}_{3} } \right)$

• A₂: ${\text{TA}}| \equiv \# \left( {{\text{T}}_{2} } \right)$

• A₃: ${\text{OBU}}| \equiv \# \left( {{\text{T}}_{4} } \right)$

• A₄: $TA| \equiv OBU\mathop \leftrightarrow \limits^{{RID_{i} \parallel S_{R - V} }} TA$

• A₅: $RSU| \equiv RSU\mathop \leftrightarrow \limits^{{SK_{R - TA} }} TA$

• A₆: $TA| \equiv RSU\mathop \leftrightarrow \limits^{{SK_{R - TA} }} TA$

• A₇: $RSU| \equiv TA \Rightarrow RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU$

• A₈: $OBU| \equiv RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU$

Proof

The proof is shown below:

Based on IM₁, we obtain

S₁: ${\text{TA}} \triangleleft \left( {\mu_{auth} } \right)_{{h\left( {RID_{i} \parallel S_{R - V} } \right)}}$

Based on S₁, A₄, and by using R₁, we can obtain

S₂: $TA\left| { \equiv OBU} \right|\sim \left( {\mu_{auth} } \right)$

Based on S₂, A₂, and by using R₂ and R₃, we can obtain

S₃: $TA\left| { \equiv OBU} \right| \equiv \left( {\mu_{auth} } \right)$G₁

Based on IM₂, we get

S₄: ${\text{TA}} \triangleleft \left( {SIG} \right)_{{h\left( {SK_{R - TA} } \right)}}$

Based on S₄, A₆, and by using R₁, we can obtain

S₅: $TA\left| { \equiv RSU} \right|\sim \left( {SIG} \right)$

Based on S₅, A₂, and by using R₂ and R₃, we can obtain

S₆: $TA\left| { \equiv RSU} \right| \equiv \left( {SIG} \right)$G₂

Based on IM₃, we get

S₇: ${\text{RSU}} \triangleleft \left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)_{{h\left( {SK_{R - TA} } \right)}}$

Based on S₇, A₅, and by using R₁, we can obtain

S₈: $RSU\left| { \equiv TA} \right|\sim \left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)$

Based on S₈, A₁, and by using R₂ and R₃, we can obtain

S₉: $RSU\left| { \equiv TA} \right| \equiv \left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)$

Based on S₉, A₇, and by using R₄, we can obtain

S₁₀: $RSU| \equiv \left( {{\text{RSU}}\mathop \leftrightarrow \limits^{{S_{R - V} }} {\text{OBU}}} \right)$G₃

Based on IM₄, we get

S₁₁: ${\text{OBU}} \triangleleft \left( L \right)_{{h\left( {S_{R - V} } \right)}}$

Based on S₁₁, A₈, and by using R₁, we can obtain

S₁₂: $OBU\left| { \equiv RSU} \right|\sim \left( L \right)$

Based on S₁₂, A₃, and by using R₂ and R₃, we can obtain

S₁₃: $OBU\left| { \equiv RSU} \right| \equiv \left( {\text{L}} \right)$G₄

Consequently, it is clear that SD2PAscheme satisfies all the earlier said goals. Thus, our scheme is fully protected.

Performance analysis

Computational overhead

In this subsection, we analyse and compare the computational overhead for three of the recent interesting VANET schemes [21,22,23], as well as our proposed SD2PA scheme, in terms of computational complexity. The schemes proposed by Jie Cui et al. [21] and Jie Cui et al. [23] have been designed based on ECC, whereas the scheme proposed by Jie Cui et al. [22] has been designed based on the Advanced Encryption Standard algorithm (AES). Our proposed SD2PA scheme is designed based on the hash function. The ECC technology adopted in the schemes [21] and [23] is based on an 80-bit security level and built on the following: G is an additive group of order q, generated by a point P on a non-singular elliptic curve $\bar{E}:Y^{2} = x^{3} + ax + b\;\bmod p$, where $a, b \in Z_{q}^{*}$, $p, q$ are 160-bit prime numbers.

To assure comparison accuracy, the crypto-operations metrics have to be under the same environments and conditions. The VANET computation evaluation method proposed in [22] is here adopted to guarantee an accurate comparison and results. For simplicity, let BG, SBV and NBV denote the execution times for beacon generation, single beacon verification and n beacon verification, respectively. The cryptographic operation notations, along with their execution time, are shown in Table 5. A detailed computational analysis for [21,22,23] is discussed below.

Table 5 Different cryptographic symbol descriptions and execution time

In Jie Cui et al.’s scheme [21], BG consists of two scalar multiplication operations and three hash function operations, so the overall cost of BG is $2T_{sm - e} + 3T_{h} = 0.6988$. SBV consists of three scalar multiplication operations, one point addition operation and two hash function operations, so the overall cost of SBV is $3T_{sm - e} + T_{pa - e} + 2T_{h} = 1.0472$. NBV consists of (n + 2) scalar multiplication operations, (2n) small-scale scalar point multiplications operations, one point addition operation and (2n) hash function operations, so the overall cost of NBV is $\left( {2 + n} \right)T_{sm - e} + \left( {2n} \right)T_{sm - e - s} + T_{pa - e} + \left( {2n} \right)T_{h} = 0.6972 + 0.3983n$.

In Jie Cui et al.’s scheme [22], BG consists of one AES encryption operation and two hash function operations, so the overall cost of BG is $T_{aes - e} + 2T_{h} = 0.1854$. SBV consists of one AES decryption operation and four hash function operations, so the overall cost of SBV is $T_{aes - d} + 4T_{h} = 0.1618$. NBV consists of (n) decryption operations and four hash function operations, so the overall cost of NBV is $(n)T_{aes - d} + 4T_{h} = 0.0048 + 0.157n$.

In Jie Cui et al.’s scheme [23], BG consists of two scalar multiplication operations and two hash function operations, so the overall cost of BG is $2T_{sm - e} + 2T_{h} = 0.6976$. The verification process consists of two main stages:

• OBU–RSU authentication key verification, in case of SBV, this stage requires one scalar multiplication operation and one hash function operation. For NBV, it requires (n) scalar multiplication operation and (n) hash function operation.

• Message signature validation requires two scalar multiplication operations, one point addition operation and one hash function operation for SBV. NBV consists of (n + 2) scalar multiplication operations, (2n) small-scale scalar point multiplications operations, (n + 1) point addition operations and (n) hash function operations.

Overall SBV is therefore $\left( {T_{sm - e} + T_{h} } \right) + \left( {2T_{sm - e} + T_{pa - e} + T_{h} } \right) = 1.0472$, while overall NBV is $\left( {\left( n \right)T_{sm - e} + \left( n \right)T_{h} } \right) + \left( {\left( {n + 2} \right)T_{sm - e} + \left( {2n} \right)T_{sm - e - s} + \left( {n + 1} \right)T_{pa - e} + \left( n \right)T_{h} } \right) = 0.6972 + 0.7488n$.

In our scheme, BG consists of only three hash function operations for the authentication process and one for broadcasting, so the overall cost of BG is $4T_{h} = 0.0048$. The beacon verification in our scheme is done by the RSU, which has more resources than the OBUs. It broadcasts the verification results in a notification message that is encrypted by its private key and the OBUs only need to decrypt this notification message in a negligible time, using the RSU’s public key. However, once the RSU receives the beacon, it needs to find the items $\left\langle {S_{R - V} , PID_{i} ,indx } \right\rangle$ in $L_{RSU - OBU}$ that satisfy the signature. With the help of the $indx$, in the worst case, the ${\text{RSU}}$ needs to identify 30 items in $L_{RSU - OBU}$ as long as each $indx$ refers to information for only 30 vehicles in $L_{RSU - OBU}$. SBV, therefore, consists of thirty hash function operations, so the overall cost of SBV is $30T_{h} = 0.036$. NBV consists of (30n) hash function operations, so the overall cost of NBV is $\left( {30n} \right)T_{h} = 0.036n$. Table 6, Figs. 5 and 6 show the comparative findings. It is obvious that the SD2PA scheme superior the other mentioned VANET solutions in terms of computational costs, and can highly enhances the system performance.

Table 6 Computation costs for the four schemes

Fig. 5

Execution time for BG

Fig. 6

Execution time for SBV

From Table 6, we can find that the SD2PA scheme enhances BG time by 99.3%, 97.4% and 99.3% compared with the Jie Cui et al. [21], Jie Cui et al. [22] and Jie Cui et al. [23] schemes, respectively. It also enhances SBV time by 96.6%, 77.8% and 96.6% compared with the Jie Cui et al. [21], Jie Cui et al. [22] and Jie Cui et al. [23] schemes, respectively, while NBV time is enhanced by 91.3%, 77.1% and 95.3% for 50 beacons compared with the Jie Cui et al. [21], Jie Cui et al. [22] and Jie Cui et al. [23] schemes, respectively. The enhancements of SD2PA over the other schemes are presented in Table 7.

Table 7 (SD2PA) scheme enhancement compared to others

The delay time for the generation and verification of numerous beacons is illustrated in Figs. 7 and 8. From these figures, it is clear that the SD2PA scheme is more rapid and more suitable than the other available schemes for VANET systems.

Fig. 7

Generation delay time for numerous beacons

Fig. 8

Verification delay time for numerous beacons

Communication overhead

In this subsection, we compare the SD2PA scheme with the schemes of Jie Cui et al. [21], Jie Cui et al. [22] and Jie Cui et al. [23] in terms of communication costs. During the computation overhead subsection, we mentioned that the size of $p$ is 20 bytes. Each element in $G$, therefore, requires 40 bytes. We also suppose that the size of the timestamp output, the hash function output and the elements in $Z_{q}^{*}$ and int. are 4 bytes, 20 bytes, 20 bytes and 4 bytes, respectively. Table 8 shows the comparison of communication overhead regardless of the size of the traffic-related message, which is used in all the compared schemes and is the same size.

Table 8 Communication costs for the four schemes

In the Jie Cui et al. [21] scheme, the beacon message is $\left\{ {PID_{i} , M_{i} , \sigma_{i} , T_{i} } \right\}$ where $PID_{i} = \left\{ {PID_{i1} PID_{i2} } \right\},$$\left\{ {PID_{i1} \in G} \right\}, \left\{ {PID_{i2} ,\sigma_{i} \in Z_{q}^{ *} } \right\}$ and $T_{i}$ is a timestamp. The beacon size is, therefore, $40 + 2 *20 + 4 = 84$ bytes. The remaining calculations for [22, 23] were found in the same way. In our scheme, the beacon message is $\left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\}$, where $\left\{ {\gamma , ID_{R} \in Z^{ *} } \right\}$, $indx \in int.$ and $T_{5}$ is a timestamp. The beacon size is therefore $2 *20 + 2 *4 = 48$ bytes. Our scheme is, therefore, more efficient than the schemes of [21,22,23] in terms of communication costs.

Conclusion

In this paper, we have shown that recently proposed CPPA schemes by Jie Cui et al. [21,22,23], have failed to offer sufficient driving safety for vehicles in a critical driving area and that, moreover, they are vulnerable in terms of VANET’s computational, communicational and management efficiency. We, therefore, proposed an efficient, fully safe driving and lightweight CPPA VANET scheme based on a general hash function. For ideal vehicle authentication and message verification, we used the cuckoo filter database in cooperative RSUs such that, when a vehicle leaves one RSU and joins the next, the new RSU can authenticate the vehicle efficiently without burdening the TA or creating a bottleneck. The security and privacy analysis indicates that the proposed scheme satisfies the VANET requirements. Extensive and deep performance analysis directories show that the proposed scheme yields much better performance in terms of computational costs and communication overhead compared with the recently proposed schemes. The proposed scheme is therefore much more suitable for practical use in VANET conditions.