Improved Chaff-Based CMIX for Solving Location Privacy Issues in VANETs

: Safety application systems in Vehicular Ad-hoc Networks (VANETs) require the dissemination of contextual information about the scale of neighbouring vehicles; therefore, ensuring security and privacy is of utmost importance. Vulnerabilities in the messages and the system’s infrastructure introduce the potential for attacks that lessen safety and weaken passengers’ privacy. The purpose of short-lived anonymous identities, called “pseudo-identities”, is to divide the trip into unlinkable short passages. Researchers have proposed changing pseudo-identities more frequently inside a pre-deﬁned area, called a cryptographic mix-zone (CMIX) to ensure enhanced protection. According to ETSI ITS technical report recommendations, the researchers must consider the low-density scenarios to achieve unlinkability in CMIX. Recently, Christian et al. proposed a Chaff-based CMIX scheme that sends fake messages under the consideration of low-density conditions to enhance vehicles’ privacy and confuse attackers. To accomplish full unlinkability, in this paper, we ﬁrst show the following security and privacy vulnerabilities in the Christian et al. scheme: Linkability attacks outside the CMIX may occur due to deterministic data sharing during the authentication phase (e.g., duplicate certiﬁcates for each communication). Adversaries may inject fake certiﬁcates, which breaks Cuckoo Filters’ (CFs) updates authenticity, and the injection may be deniable. CMIX symmetric key leakage outside the coverage may occur. We propose a VPKI-based protocol to mitigate these issues. First, we use a modiﬁed version of Wang et al.’s scheme to provide mutual authentication without revealing the real identity. To this end, the messages of a vehicle are signed with a different pseudo-identity “certiﬁcate”. Furthermore, the density is increased via the sending of fake messages in low trafﬁc periods to provide unlinkability outside the mix-zone. Second, unlike Christian et al.’s scheme, we use the Adaptive Cuckoo Filter (ACF) instead of CF to overcome the false positives’ effect on the whole ﬁlter. Moreover, to prevent any alteration of the ACFs, only RSU s distribute the updates, and they sign the new ﬁngerprints. Third, the mutual authentication prevents any leakage from the mix zones’ symmetric keys by generating a fresh one for each communication through a Difﬁe–Hellman key exchange.


Introduction
Intelligent transportation systems (ITS), particularly Vehicular Ad Hoc Networks (VANETs), are constantly growing in importance. Efficiency and security are achieved in VANETs mainly through safety applications and non-safety applications such as entertainment and internet access. In safety applications, beaconing services are necessary because they are essential for ITS effectiveness; otherwise, accidents can occur. Open networks that are accessible by any node are characteristic of VANETs. In general, the two types of communication performed by VANETs are Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I), which communicate through the latest Radio Access Technology (RAT) IEEE 802.11bd for Dedicated Short Range Communications (DSRC) and New Radio safety of the system. We then propose an improved version that is resistant to these issues. To comply with Christian et al.'s scheme, we utilise a modified version of [15] by replacing digital certificates with an Identity-Based Signature. In summary, our scheme provides the following features: • We use Adaptive Cuckoo Filter(ACF) instead of CF, as in [14], to mitigate the effect of false positives that may impact the performance of the filter; this enhances the system in sending Chaff messages to confuse eavesdropping adversaries that exploit traffic flow to breach unlinkability. We also use the pseudo-identity generation concept from [15], which has non-malleability to hide the certificates of actual vehicles. • We provide unforgeability and non-repudiation by adding an RSU signature and timestamp in each message, in particular, on the new fingerprinted Chaff messages before inserting them into the ACF. Hence, to preclude any possibility of malicious injections, we also remove the ACFs forwarding task from vehicles, like in [14]; in our scheme, RSUs are the sole authority to distribute them. • We modify the mutual authentication between RSUs and vehicles based on certificates instead of IDs, as in [15], before generating the symmetric key of a mix-zone, as the generation of a shared key follows the Diffie-Hellman key exchange method to provide confidentiality and privacy by preventing any key leakage.
These features allow our protocol to achieve unlinkability, unforgeability, and mutual authentication.

Roadmap
The rest of the paper is structured as follows: Section 2 presents the VANETs architecture and our scheme's design goals. Section 3 reviews the related work on location privacy that aims to achieve unlinkability. In Section 4, we present the security and privacy model of the improved Chaff-based CMIX. In Section 5, we introduce our improved CMIX scheme. Section 6 gives a comprehensive security analysis. Section 7 is dedicated to a comparison between our scheme and similar schemes in the literature. Finally, Section 8 concludes the paper.

VPKI Architecture
The heterogeneous VANET architecture primarily consists of three bodies, i.e., vehicles, RSUs and CAs. The vehicle is also called an OBU, a transceiver board placed on the vehicle to exchange information with CAs, RSUs and other vehicles. Each RSU and vehicle has credentials and private keys for safe and secure communication. CAs register and certify the public keys to vehicles and RSUs. RSUs are used to monitor road traffic and minimise accidents. They also provide access points for vehicles and other RSUs to disseminate information securely and effectively. Although RSUs use wire-based communication, vehicles use wireless communication between each other and with RSUs. Note that this protocol can be executed in tunnels and other confined areas due to these communications features; see Figure 1 for a standard VANET architecture. In general, the VPKI should have the following list of CAs [8,14]: The root CA (RCA) 1 is at the top of the hierarchy, serving as a governance body that certifies other intermediate authorities.

2.
The long-term CA (LTCA) 1 is an intermediary authority that is responsible for vehicle registration and long-term certificate issuance for vehicles and RSUs.

3.
The resolution authority (RA) 1 is a central authority that can address a pseudoidentity and thereby validate the long-term identity of the vehicle in the event of a fraudulent act by communicating with the LTCA and the PCA.

4.
The pseudo-identity CA (PCA) 1 is an intermediary authority responsible for issuing pseudo-identities for registered vehicles. (1) RCA is a government entity, and it is responsible for managing all subordinate CAs. (2) LTCA is responsible for entity registration and issuing certificates. (3) RA is responsible for retrieving misbehaving entities' credentials. (4) PCA is responsible for pseudonym issuance. Moreover, RSUs are responsible for vehicles entering/leaving the mix-zones. There are two types of communication: (1) through a shared key that is distributed by RSUs inside the mix-zone [8].
(2) Anonymous communication, which is performed outside the mix-zone.
In addition, the RCA manages various domains through cross-certification. There is only one LTCA in each domain, and vehicles must register in the home domain. However, they may cross domains and communicate with foreign LTCAs to gain pseudo-identities. As far as the PCA is concerned, it may be involved in one or even several domains. Therefore, if the vehicle requires a pseudo-identity, the LTCA can only offer one authentication ticket per vehicle, and the authorisation will be with the certificate gained from the LTCA. In PKI-based systems, even though the use of pseudo-identities as anonymised certificates guarantees the anonymity of the identity [16], it cannot guarantee the privacy of the position. For example, a vehicle has to change its pseudo-identity during its trip. However, the eavesdropping monitor with two observation points in the same road will link the changing of a moving vehicle's pseudo-identity.

Design Goals
The proposed work should satisfy security and privacy preservation through the following goals: • Authentication: There are two forms of authentication: mutual authentication and message authentication. Mutual authentication demands the ability of two entities to identify each other at a specified session. Message authentication confirms the integrity of the messages and proves that they are generated from authorised vehicles and have not been unmodified through the transmission. • Nonrepudiation: This property applies to a case in which the recipient is willing to show to a third party that the sender cannot dispute responsibility for the messages' generation. It prevents the attacker from forging messages with other identities.
In a particular scenario of VANET low density, we aim to achieve essential properties.
• Unlinkability: The certificate and information in the messages have to be unlinkable for privacy protection, even if identical vehicles change certificates or the exact vehicle sends new messages with new data, so that an adversary can never discover shared properties in several messages and then link them to a specific vehicle and trace its location. The change time to time in each communication and in the mix-zone on pseudo-identity rather than real identity. In addition, certificates in the communication have a relation with the pseudo-identity.

Related Work
Several types of research have been published on pseudo-identity unlinkability and vehicle privacy in ITS. This section includes our review of the most recent works on location privacy, which is also a significant element that needs to be considered [17], as well as pseudo-identity change management in VANETs. Due to the data transmission in VANETs for safety applications and the amplification in broadcasting technology, messages can be made open to adversaries; thus, it is easy to listen to the correspondence channels via the ITS infrastructure [18][19][20]. In this context, researchers have attempted to prevent the attacks related to linking the communications' information. Various studies have focused on unlinkability accomplishment by optimising the pseudo-identity change management mechanism to retain vital details, such as position and trajectory. However, we are now seeing that various literature schemes suffer from a vulnerability to linkability attacks that breach privacy.
Note that the following parameters are listed in the ETSI ITS technical report [8] on pseudo-identity change management as not adequate for different reasons, namely: (1) fixed parameters, (2) silent period, (3) randomness, and (4) CMIX. Eckhoff et al. [21] suggested allowing a pool of pseudo-identities for each vehicle to use within one week, whereby each pseudo-identity will be valid for ten minutes without overlapping, which is a fixed parameters scheme. It will deter attacks, such as Sybil attacks, and address the tradeoff between privacy and safety. However, the use of fixed parameters is straightforward, and this allows the adversary to know the parameter values of a given vehicle, making it easier to trace them. Choosing randomness dependent on fixed parameters, such as randomly changing the pseudo-identity every five minutes plus or minus one minute, helps deter the attacker from detecting a change in the pseudo-identity. However, it is still possible to link attacks when a few vehicles change their pseudo-identities while others retain their old ones. Furthermore, an attacker can track vehicles effortlessly by using trajectory predictability algorithms, such as Kalman filters [22], especially when the density is not high or when a few vehicles change their pseudo-identities while others maintain theirs [8]. Some researchers propose shutting off the wireless transmitter at an unspecified point and changing pseudo-identities during the silent period [10,[23][24][25][26][27]. Vehicles would have adequate protection during this time, but this would dramatically limit protection due to the non-broadcasting series of CAMs, which would lead to an increase in vehicle accidents.
In addition to the silent period, Buttyan et al. propose changing the pseudo-identity when the vehicle's speed is less than 30 km/h [26]; however, this does not take into account low-density situations that lead to linking attacks. On the other side, Boualouache et al. in [10] suggested a Vehicular Location Privacy Zone (VLPZ) to regulate service stations (e.g., diesel, fuel and charging stations or toll booths). However, syntactic linking attacks can easily occur due to the lack of coordination caused by the silent period [28], and the attackers may track the pseudo-identity change [22]. Additionally, the link attack's impact worsens in low-density situations due to the simplicity of analysing a low number of vehicles. Conversely, the mix-zones concept does not need to limit the feasibility of safety applications. Initially, the mix-zone approach was proposed by Beresford et al. [12], leading to the use of a pre-defined geographical region to change pseudo-identities. These zones have a CA hierarchy, and the semi-honest RSUs dominate the mix-zone. Freudiger et al. enhanced the scheme by inserting a symmetric key to encrypt messages among vehicles within the mix-zone and called it a CMIX [13]. While CMIX-based systems are sensitive to linking attacks, they depend heavily on vehicle traffic, vehicle arrival, speeds, and probable vehicle movements through mixed zones. These schemes are also vulnerable to linking attacks in low-density [8] scenarios. Lu et al. [29] proposed changing pseudoidentities at social spots, i.e., a public space, which gives the benefit of traffic to confuse the attacker. For example, vehicles stopped at traffic lights can change their pseudoidentities when these turn green, and in shopping mall parking, vehicles can change their pseudo-identities before they exit. However, this scheme is simplistic and inadequate to guarantee unlinkability because high density does not guarantee that certificates can be linked and traced back to identity. The authors in [30] proposed a context-based system to use credibility scores sent in order to cause synchronous pseudo-identity changes; those scores are part of the periodic safety beacons, thus increasing the anonymity set. With the same, i.e., context-based, approach Liu et al. [31] presented another pseudo-identity change management technique, which is an entirely uncoordinated pseudo-identities change in distributed networks after a random delay to allow regular and unlinkable changes, whereby they suppose that the anonymity can be accomplished at trivial throughput loss is in large networks. Zhao et al. [32] proposed a pseudo-identity changing game that is mixed-context and was developed by examining the relationship between changing the pseudo-identity, expense, and privacy. Moreover, Zeng and Xu [33] suggested pseudoidentity changing privacy preservation authentication based on a mixed-context. However, attackers can easily threaten these systems if the density is low, as with traffic-based techniques.
Furthermore, a dynamic zone-based pseudo-identity change management [34] has recently been proposed to set up a temporary on-demand swap zone in which a vehicle will randomly pick and exchange a pseudo-identity with another vehicle without a group manager. This change adapts to reduce the contact cost of establishing pseudo-identity swap zones based on the environment.
Benarous et al.'s [35] is proposal based on two main factors: the strategies of "hiding inside the crowd" and "location obfuscation". When the vehicle either exits a particular geographical area or the pseudo-identity reaches its expiry, it must change it. This change management holds the count of the neighbouring vehicles, and if the pre-defined neighbour threshold matches the current neighbours, then it changes pseudo-identity with other vehicles cooperatively. Otherwise, for the vehicle to change its pseudo-identity, the vehicle obfuscates its location and turns the speed to zero. The downside is that the unreliable broadcasting of speed and location information poses questions regarding safety applications. In 2018, Christian et al. [14] introduced a development for CMIX by adding Chaff messages (representing vehicles on the road) to stabilise the density in low-density scenarios in CMIX. Hence, the Chaff-based CMIX protocol alleviates Freudiger et al.'s CMIX scheme's weaknesses in low-density situations by confusing the attacker to strengthen the CMIX scheme. As ETSI ITS confirmed the importance of considering the low density as mentioned in their report "the higher the density of vehicles, the more efficient the mix-zone is against tracking." [8]. Moreover, this scenario is possible in the peak and off peak hours daily. Furthermore, the lockdown of the Coronavirus Disease of 2019 (COVID-19) pandemic raises the chances of low-density scenarios in different countries. In fact, this emphasises the value of Christian et al.'s scheme. However, their Chaff-based CMIX scheme has some issues that could break the system.

Security and Privacy Issues of Christian et al.'s Chaff-Based CMIX Scheme
Christian et al. [14] proposed a protocol using Chaff messages in low-density scenarios to increase the number of fake vehicles which prevents linkability attacks. However, there is a security vulnerability in their protocol which is run outside the mix-zone. More concretely, the signature and the certificate are not encrypted in the following message which allows attackers to break the unlinkability: where PS V ID j is the pseudo-identity of the j-th vehicle V ID j , PK V ID j is the public key of PS V ID j while Enc PK V ID j denotes message (msg) encryption with the specified key, sk r is the symmetric key of the r-th mix-zone, CF r is the CF of the r-th mix-zone, Cert PS V ID j is the V ID j 's certificate, and Sign RSU i , Sign PS V ID j denote RSU i 's and V ID j 's signatures.
In addition, the message contains non-encrypted values, namely the timestamp t j , the sender's signature Sign V ID j (M V2R ), and the certificate Cert V ID j . Nevertheless, sending these messages outside the mix-zone leads to the following security issues: • The privacy of vehicles can be compromised. Vehicles update their pseudo-identity once they move from one mix-zone to another. However, outside mix-zones, while they communicate with other vehicles securely, they also send Cert V ID j and Sign V ID j separately. Therefore, it is trivial for the adversary to link the old and the new pseudo-identities, meaning they can identify the sender, which breaks the unlinkability property. • Unreliable CFs update. To update the CF, vehicles forward the CF i as a new version in a ciphertext; Christian et al. argue that the signature of RSU i is attached to prevent forgery attacks. It is possible for malicious vehicles to inject real pseudo-identities and send them to the RSU i inside the mix-zone or other vehicles, subsequently denying this malicious activity. Moreover, if an adversary compromises the RSU i and tries to tamper with the CF, the vehicles will discard messages from these fingerprinted pseudo-identities, which leads to accidents by affecting safety applications. • The secret key of the mix-zones can cause leakage. The ciphertext C contains the encryption key sk r , which must only be used in the specified area. The receiving of this key outside the mix-zone by an external unauthorised vehicle (i.e., the mix-zone is compromised) threatens the security of the communication. Hence, an attacker would be able to communicate maliciously with honest vehicles outside the specified area, which would break the system's safety.
Moreover, we should note here that Mitzenmacher et al. [36] specified a drawback that may affect the CF's performance. In particular, they suggested that the false positives that can occur in a CF may affect the search for an element inside these hash tables. To fix this, they proposed a technique that identified the element that caused false positives, then removed it and re-inserted it again differently. Then, if they searched for that element, it would be found. Undoubtedly, the performance of the filter in a Chaff-based scheme plays a vital role. Thus, we are using ACF rather than CF in our scheme.

Our Improved Chaff-Based CMIX Scheme
We are now ready to describe our VPKI-based scheme. We utilise a modified version of Wang et al.'s Identity Based Signature (IBS) construction by replacing IDs with certificates to comply with Christian et al.'s protocol [15]. The setup is as follows:

Setup
Let G 1 , G 2 be cyclic groups of prime order q, and g 1 , g 2 be generators of G 1 , G 2 , respectively. Let also H 1 , H 2 , H 3 , H 4 be hash functions where K is a keyspace, and is a security parameter while Z * q is the multiplicate group (which is a list of integers modulo q and are co-prime with q). Let also RSU i and V ID j be the long-term identities of the i-th RSU and the j-th vehicle, respectively. Furthermore, denote PS V ID j for the pseudo-identity of the j-th vehicle. Let (pk LTCA , sk LTCA ) be a public and private key pair, and msk LTCA be the master secret key of LTCA. During the setup of RSU and vehicle, LTCA first chooses x, y, z ∈ R Z * q and computes X = g x 1 , Y = g y 1 and Z = g z 1 . LTCA maintains a public list List pub and a private list List priv for PCA and RSU. As we describe below, RSU i is going to maintain List pub for mutual authentication, while PCA is going to maintain List priv for tracking the authentication details of registered vehicles. Next, we describe the setup of the RSU and vehicles: • RSU setup: LTCA generates sk RSU i from (msk LTCA , RSU i ) in K and sends it to RSU i . LTCA also generates Cert RSU i = Sign sk LTCA (pk RSU i ), where pk RSU i is the public key with respect to sk RSU i . RSU i then computes R i = g r i 1 and E i = g e i 2 , where r i , e i ∈ R Z * q , and stores the tuple (PP i , R i , E i ) for later to securely communicate with the vehicles entering the mix-zone. • Vehicle Setup: Whenever a vehicle V ID j enters a new LTCA region, LTCA first generates sk V ID j from (msk LTCA , V ID j ) in K and sends it to V ID j . LTCA also generates Cert V ID j = Sign sk LTCA (pk V ID j ), where pk V ID j is the public key with respect to sk V ID j . V ID j stores ((pk V ID j , sk V ID j ), Cert V ID j ). LTCA also incorporates the tuple {Cert V ID j , H j , A j , r j , P j , T j } into List priv in PCA and {A j , P j , T j } into List List pub that is accessible for RSU i , and when Tj expires in each, PCA forces the vehicles to refresh their authentication keys. The LTCA also loads existing RSUs' certificates to the vehicle. Next,

1.
V ID j picks a j ∈ R Z * q and then computes its authentication key a j = H 4 (a j , t j ), where t i is the timestamp.

2.
V ID j computes H j = H 1 (Cert V ID j , a j ), A j = g a j 1 , and sends (M, Sign V ID j (M), Cert V ID j ) to LTCA, where M = (Cert V ID j , H j , A j ). The authentication key a j is saved in V ID j .

3.
LTCA generates a challenge R j = g r j 1 and a dynamic password P j = A r j j , where r j ∈ R Z * q . The challenge R j is sent to V ID j , which stores it locally.

4.
LTCA maintains the tuple {Cert V ID j , H j , A j , r j , P j , T j }, where T j is the expiration date.
• PCA Setup: LTCA generates sk PCA from (msk LTCA , PCA) in K and sends it to PCA. LTCA also generates Cert PCA = Sign sk LTCA (pk PCA ), where pk PCA is the public key with respect to sk PCA . In addition, LTCA sends x, y, z, ∈ R Z * q and List priv to PCA. Then, PCA generates the public parameters s,r j , r * j , e j ∈ R Z * q . • RA Setup: LTCA sends x, y, z, ∈ R Z * q , List priv and the registered RSUs identities to RA, while PCA sends s ∈ R Z * q and PS j . Therefore, these values help RA to detect any malicious vehicles or RSUs.
Note that LTCA obligates vehicles to update their authentication keys if T j is expired.

Mutual Authentication
The authentication between RSUs and vehicles starts once the vehicles are in the transmission range of the RSUs. In the following, we describe the protocol between RSU and vehicles.

1.
RSU where R i along t i is the timestamp and E i is used to generate symmetric keys and ACF i is the ACF of RSU i .

2.
A vehicle V ID j entering the transmission range receives B and validates the signature Sign RSU i (M R2V ). If not verified, it aborts the protocol. Otherwise, V ID j stores B.

3.
V ID j next computes

4.
RSU i now computes the symmetric key K = H 2 (F e i j ) and decrypts C. Next, RSU i (a) First validates the signature Sign V ID j (M VR ), and aborts if it is not valid.
Verifies ACF i and aborts if it is not valid.
Aborts the validation if the tuple is expired or it is not in List pub , or it has more than one tuple.
If P i = P i then V ID j will be authenticated to RSU i without revealing its identity.

Privacy Preservation: Pseudo-Identity Generation and Updating Authentication Key
Our scheme provides privacy preservation by focusing on pseudo-identity generation to achieve untraceability and the update of the authentication key to accomplish full unlinkability.

Pseudo-Identity Generation for Vehicles
To preserve privacy and untraceability between vehicles, they need to use pseudoidentities rather than their real identities. As mentioned previously, PCAs are responsible for pseudo-identity generation. After V ID j is in the transmission range of RSU i , the vehicle generates pseudo-identity as follows: • V ID j computes the pseudo-identity of itself as PS V ID j = (S, Π 0 , Π 1 ) = (g s 1 , H 1 (Cert V ID j , a j )X s , Y s Z θs ), where s ∈ R Z * q and θ = H 4 (g s 1 , H 1 (Cert V ID j , a j )X s ) (note that the pseudo-identity of V ID j is equal to the encryption of H 1 (Cert V ID j , a j ) through the Cramer-Shoup encryption scheme [37], which is non-malleable and secure against adaptive chosen-ciphertext attack (CCA2)).
• PCA manages the generation of fake pseudo-identities Cha f f PS j and fingerprints them FP(Cha f f PS j ) and signs them Sign RSU i (FP(Cha f f PS j )) before inserting them into the ACFs. Then, RSU i signs the whole ACF Sign RSU i (ACF i ) to provide non-depuration and distributes it to the vehicles.
RA can detect the real identity of the vehicle if it has malicious activities, as follows. Let V ID j be a malicious vehicle and its pseudo-identity be PS j . The RA obtains (S, Π 0 , Π 1 ) and computes θ = H 4 (S, Π 0 ), Π 1 = S y+θz . It then checks whether Π 1 ? = Π. The pseudo-identity is invalid if they are not equal. Otherwise, RA computes H = Π/S x . If {Cert V ID j , H j , A j , r j , P j , T j } is valid in List priv and H j = H, then RA attempts to find the Cert V ID j from its database and learns the real identity of V ID j . For privacy reasons, the real identity of the vehicle V ID j must be hidden from other RSUs and vehicles.

Unlinkability through Updating Authentication Key
In order to provide unlinkability, the system must update the authentication key and the ACF regularly. Assume that the tuple (Cert V ID j , H j , A j , r j , P j , T j ) has expired based on the expiration date T j . Here below, to update the authentication key, PCA and the vehicle V ID j run the protocol.

1.
PCA , wherer j , r * j , e j ∈ R Z * q .R j is used for the targeted vehicle V ID j , R * j is used for V ID j , and E j is used to generate a shared key. (c) Computes a signature Sign PCA (M PCA ), where sk PCA = generated from (msk PCA , PS j ) and M PCA = (PS j ,R j , R * j ,t j ), andt j is a timestamp.
Validates the signature Sign PCA (M PCA ) using pk PCA . (c) Checks the freshness of the timestampt j .
, H 1 (Cert V ID j , a j )X a j ) with a j being the authentication key. Note that only the V ID j that holds a j can compute this pseudo-identity.

(e)
Updates the authentication key by computing a * j = H 4 (a j , t j ), (d) Computes P j = Ar j j and aborts ifP j = P j . (e) Computes P * j = (A ) is valid and the timestamp t is fresh, then it computes P j = R a * j .

5.
V ID j aborts if P j = P j . Otherwise, the current authentication key a j and challenge R j are replaced with a * j and R * j , respectively.

Security Analysis
We are now ready to provide a security analysis of our scheme.

Mutual Authentication
During the mutual authentication, the vehicle V ID j validates Sign RSU i (M R2V ) and Cert RSU i which are received from the broadcast message by RSU i , i.e., B=(M R2V , Sign RSU i (M R2V ), Cert RSU i ). Therefore, authentication is provided through signatures and certificates as long as LTCA is honest. Next, to be able to generate a shared key, V ID j first computes its P j = A r j j and P i = A r i j , where R i = g r i 1 is sent by RSU i . Then, the RSU i can recover P j = A r j j from {A j , P j , T j } in the list List pub . Hence, even if R i and A j given to other entities, to generate valid P i and P j they must know either a j of V ID j or r i of RSU i . However, since these private values are only known by V ID j , RSU i and certificates are used for authentication, no adversary can compute the shared key due to the underlying Computational Diffie-Hellman (CDH) problem. Therefore, our scheme provides the message confidentially inside the mix-zone.

Non-Repudiation
Every message generated by the vehicle V ID j or RSU i uses the digital signature as evidence of non-repudiation. Moreover, digital certificates, which are issued by LTCA, contain an expiration date. Therefore, Sign V ID j already involves the timestamp t j and the receiver checks whether the Cert V ID j is valid or not for the pseudo-identity PS j . Thus, if V ID j or RSU i behaves maliciously, RA can easily detect and revoke their certificates. Hence, non-repudiation is guaranteed.

Unlinkability
Our scheme preserves privacy by signing the messages with different pseudo-identities. The real identity is secretly hidden in these messages because PS j = (g a j 1 , H 1 ( Cert V ID j , a j ) X a j , Y a j Z θa ) is computed by the authentication key a j where θ = H 4 (g a j 1 , H 1 ( Cert V ID j , a j )X a j ). Note that this key is only accessible by V ID j . For accountability reasons, RA can compute because the public parameters x, y, z ∈ R Z * q are known by all the certificate authorities LTCA, RA, and PCA. Hence, no adversaries can obtain the real identity from the ciphertext H 1 (Cert V ID j , a j ). Moreover, we also prevent information leakage by providing mutual authentication and sending Chaff messages on the road to mitigate the risk of linkability attacks by eavesdropping adversaries due to the low-density traffic. Therefore, our scheme provides unlinkability.

Defence against Compromised RSU
In the proposed system, we assume that the CAs are fully trusted while the RSUs and the vehicles are semi-trusted which means that they are trusted but cannot know some sensitive and private data of the vehicles. Thus, LTCA generates the private key sk RSU i and the Cert RSU i based on its master key. Therefore, if RSU i s corrupted, it can be detected through the credentials generated by LTCA which can immediately revoke the RSU's certificate. Moreover, the corrupted RSU i can also manipulate the ACF. This manipulation impairs the safety application and can cause accidents. However, in our scheme, RSU i signs the fingerprinted Chaff Sign RSU i (FP(Cha f f PS j )), which helps to detect the RSU i in case it has malicious activities.

A Comparison of Proposed and Existing Schemes
In the previous section, we focused on three desired properties, namely mutual authentication, non-repudiation and unlinkability. Furthermore, it is also essential to show that our scheme is robust against low density. Note that previous studies have not given much attention to low density scenario. The comparison in Table 1 shows more factors related to existing VANETs' location privacy schemes. Moreover, it summarises that our scheme overcomes the vulnerabilities of [14] which are presented in Section 4. Here we illustrate a security and privacy vulnerabilities in related existing schemes: • Unlinkability: The fixed parameters schemes like [21] or schemes using the randomness such as [31] are vulnerable to linkability attacks. In addition, most of the existing works does not consider the traffic variability, which may help the attackers to break the unlinkability. • Non-repudiation: Some schemes rely on identity changes after a random delay, if malicious vehicles do not change the pseudo-identity intentionally, then they will break the system. The randomness and the delay will break the non-repudiation. Moreover, this whas also the case in [35] which is based on location obfuscation and hiding in the silent period. The location obfuscation means the vehicle can turn its speed to zero and obfuscate the position while changing the pseudo-identity. Hence, it affects the safety applications. Thus, if a malicious vehicle tried to harm those applications purposely, it can deny it because the location obfuscation is part of the system. The non-repudiation issues of [14] are related to the quality of CF that can breach the system. Furthermore, the scheme in [15], considers the RSU fully trusted; without a digital signature in the communication, it can deny any malicious activities. • CMIX: The schemes tending to the CMIX are [13,14] and our scheme. The concept of cryptography in a mix-zone around RSU is efficient, but it is associated with road density. The higher the density, the better the effect against tracking. • No interference with safety application: The necessity of updating the information via messages without any interruption, like silent period, assures the safety application quality. Scheme such as [10,35] using the silent period with different structure. However, this threatens the safety application technologies as reported in [8] technical report. Furthermore, other schemes like [14] that added filter for Chaff messages may weaken the safety application technologies if the filter has been corrupted. In addition, in [15] that relies on RSU, if it is compromised, it will be easy to abuse the safety application and jeopardise the passengers' safety.
Christian et al. [14] evaluated the performance of their system using three metrics: chaff pseudonym pool size, the number of simultaneously active chaff pseudonyms, and the RSU signature generation overhead. We are consume more overhead because our system requires mutual authentication as we are using DDH. However, they did not measure the overhead of the filter's hash tables. Our scheme uses ACF which also uses hash functions while it has a lower false-positive rate compared to CF. The ACF can find the elements that caused the false-positives after they occur, delete and re-insert them again in the hash table. Hence, it will help to find them in the search more efficiently than CF [36].

Conclusions
In this paper, we investigated Christian et al.'s Chaff-based CMIX scheme [14] that concentrated on low-density situations as essential and possible daily scenarios. However, their scheme is not sound in achieving security and privacy. Furthermore, the scheme cannot resist linkability attacks in vehicles communication, CF malicious injections, which affect safety applications, and the leakage of mix-zones' symmetric keys to unauthorised vehicles. To overcome the weaknesses of Christian et al.'s scheme, we utilised a version of [15] by using certificates instead of IDs to accomplish mutual authentication to enhance the security and privacy of the legitimate entities. Furthermore, we accomplish unlinkability by preventing low-density exploitation via increasing the density securely and by generating unlinkable pseudo-identities for each message based on an unexampled secret authentication key. Moreover, we increase the efficiency of the Chaff messages by using ACF to overcome the CF disadvantages. To prevent malicious injection in ACFs, the RSU signs the new fingerprinted Chaff pseudo-identities and keeps the distribution for RSUs only. We apply a Diffie-Hellman key exchange method after the mutual authentication to prevent unauthorised vehicles from symmetric key access to mitigate any leakage of the mix-zone symmetric key. In future work, we believe that we have to evaluate our scheme and provide performance evaluation results to make the work more convincing. In addition, we will investigate our scheme efficiency in tunnels and confined area.