The Security of “2FLIP” Authentication Scheme for VANETs: Attacks and Rectifications

Wireless broadcast transmission enables Inter-vehicle or Vehicle-to-Vehicle (V2V) communication among nearby vehicles and with nearby fixed equipment, referred to as Road Side Units (RSUs). The vehicles and RSUs within transmission range establish a self-organizing network called Vehicular Ad-hoc Network (VANET). The V2V communication in VANETs is vulnerable to cyber-attacks involving message manipulation. Thus, mechanisms should be applied to ensure both the authenticity and integrity of the data broadcast. However, due to privacy concerns, it is important to avoid the use of identifiers that may aid tracking and surveillance of drivers. This is a serious constraint on authentication mechanisms. Recently, Wang et al. [1] proposed A Two-Factor Lightweight Privacy Preserving Authentication Scheme for VANET named 2FLIP. They claim that their scheme includes a secure systemkey update protocol to restore the whole system when necessary. In this paper, we show that this is incorrect: 2FLIP does not provide perfect forward secrecy. This results in a known-key attack, as well as message forgery attack by an external adversary who may be an unregistered vehicle user. This external adversary can generate valid anonymous messages and further, they cannot be traced. The 2FLIP scheme is efficient, so we propose a modification to improve the security. We provide a formal security proof to show that our proposal is indeed provably secure. We demonstrate the efficiency of our proposal by conducting extensive performance analysis. We believe the enhanced system-key update protocol will be useful for application by researchers and designers in current and future VANET authentication schemes.


FIGURE 1. Vehicular network model.
The CA is assumed to be always online, secure, and fully trusted by other network entities. The CA can be implemented in a multi-layer structure; for example, with a root CA and several sub-CAs. For sake of simplicity, here we show the CA as a single entity. The CA is a managing authority that can act as the root of trust to generate, update, and revoke credentials for other network entities, including vehicles. For example, the department of motor vehicles or the Department of Transportation (DOT) can act as the root CA.
The distributed RSUs are equipped with a higher computational capability and transmission power than OBUs. As shown in Fig. 1, the CA and RSUs can connect to each other through wired (solid line) and/or wireless (half-dashed line) channels. The RSUs work as gateways to deliver data from the CA to roadside vehicles, and vice versa. The range of an RSU-to-vehicle communication can be larger than that of the V2V and vehicle-to-RSU communications [6].
Smart vehicles equipped with OBU, sensors, and Global Positioning System (GPS) move along the roads, and communicate with other vehicles and RSUs according to a defined Intelligent Transportation Systems Radio Service (ITS-RS) standard, such as the Dedicated Short Range Communications (DSRC) protocol [6]. A Tamper Proof Device (TPD) is embedded in each OBU to store the user inaccessible cryptographic keying materials involved in cryptographic operations. Moreover, each vehicle has a unique barcode/identifier that is known to the DOT. Fig. 2 illustrates an envisioned smart vehicle prototype.
This system is useful if all messages are legitimate. Safety messages are broadcast to reach all vehicles within communication range. However, malicious entities could manipulate messages. Mechanisms should be applied to ensure both identification of the data source (entity authentication) and authentication of the message (assurance of data origin and data integrity) [7].
Authentication requirements can often conflict with privacy requirements. A unique identifier, such as a Vehicle Identification Number (VIN), is provided to a vehicle for authentication purposes. However, this vehicle identifier can be associated with an identifiable individual (e.g., driver or vehicle owner). In this case, the exchanged data reveals personal information, (e.g., aggregating location information over time can reveal work or home addresses and travel patterns). An adversary can capture communications and link the identifiers to specific vehicles, and consequently to the drivers (ID disclosure), providing a means for surveillance [8]. Hence, protection and confidentiality of data exchanged is required to avoid privacy breaches. For both identification and message authentication, protection of the driver's identity during authentication must be guaranteed.

B. EXISTING WORK AND RESEARCH CHALLENGE
Any cryptographic technique for authentication requires the use of a cryptographic key. A key-update mechanism is needed to refresh the key to ensure security, for example after a cryptographic-key breach occurs, or if a cryptographic-key is unknowingly accessed. The key-update mechanism must be carefully designed to satisfy both security against known-key attacks [9, §12.2.3], and perfect forward secrecy; if a cryptographic secret key for the current session is revealed, an adversary must not be able to use this information to assist in recovering messages from past and/or future ciphertexts [9, §12.16]. To achieve this, there must not be any exploitable dependencies among keys for different sessions (keying material).
Wang et al. [1] propose 2FLIP: A Two-Factor Lightweight Privacy Preserving Authentication Scheme for VANET. In 2FLIP, the TPD embedded in each vehicle is equipped with a system key to generate Message Authentication Codes (MACs) for the broadcast messages. Recipient TPDs can verify the messages by creating MACs of the received messages with the same system key. This only requires one hash computation and one MAC operation to accomplish the message verification. Hence, the protocol is very efficient in terms of computation.
In 2FLIP, the same copy of system key must be stored in all vehicle TPDs. However, Huang et al. [17] view this as a single point of failure. If any single vehicle's system-key is compromised, all vehicles in the network will be affected (as they all have the same key), and all will need to be updated with a new system-key. Clearly, a key-update mechanism is required.
The authors of 2FLIP acknowledge the possibility of key compromise. They propose renewing the system key, and claim that the mechanism they provide can restore the system quickly in the event that the system key is leaked. They recognize the importance of the key-update mechanism and state that such a protocol is necessary for a complete secure system (see [1,).
A serious security flaw in the system-key update mechanism of 2FLIP is reported by Baee et al. [24], [25]. There is a clear dependency between successive system keys. In the 2FLIP key-update protocol, a CA that is fully trusted by other network entities encrypts a new system key, treating the system key as the message content and encrypting this using the previous system key. In the case where a past system key is compromised, clearly the new key is not protected and very easily discovered.
As 2FLIP is computationally efficient and has some practical advantage, it would be a shame to discard it due to this system-key update flaw. This research reviews the scheme and suggests modifications to mitigate this flaw, to address the security of the 2FLIP scheme.

C. RESEARCH CONTRIBUTION
This paper contains five major contributions. First, the message signing and verifying protocol, system-key update protocol, and adversary model in 2FLIP scheme are reviewed, and a vulnerability in the system-key update protocol of 2FLIP scheme is identified. Secondly, two attacks that exploit this vulnerability are described and demonstrated. Thirdly, a modification to mitigate the security flaw in 2FLIP system-key update protocol is proposed. Fourthly, a formal security proof for the proposed system-key update protocol is given. This demonstrates that the new protocol is indeed provably secure. Finally, the efficiency of our protocol is demonstrated by conducting extensive performance analysis.

D. ORGANIZATION OF THE PAPER
The remainder of this study is organized as follows. Section II briefly reviews the message signing and verifying protocol, system-key update protocol, and adversary model in 2FLIP scheme. Section III demonstrates the vulnerabilities in 2FLIP. Section IV presents the modification proposed by this research, and Section V provides formal security proof to show the modification is indeed provably secure and preserves the privacy requirements. Section VI evaluates the computational cost and communication overhead of the proposed key-update protocol. Section VII discusses the results, and finally, the paper is summarized in Section VIII. For the convenience of the reader, a list of abbreviations and symbols used throughout the paper is given in Tables 1 and 2, respectively.

II. THE 2FLIP SCHEME
This section reviews the message signing/verifying protocol, system-key update protocol, and adversary model proposed in 2FLIP.
In addition to the notations presented in this section, everywhere in this paper the concatenation symbol " " denotes an operation that combines several strings into one string where the constituent strings are uniquely recoverable from the final one. The symbols "t s " denotes time at generating a message. The symbol "t r " denotes time at receiving a message. A message receiver drops the message if the time interval between the time of receiving t r and the time t s exceeds a predefined threshold denoted by " t". This is used to determine the freshness of the message.
Assume X and Y are two communicating nodes. The symbol "X → Y" denotes a message transmission from X to Y. The symbol "X ↓" denotes processing a message by X, before transmitting a message or after receiving a message. The symbol "X Y" denotes a two-way message transmission from X to Y, and also from Y to X.   3) A receiver TPD j calculates σ * i = mac km (PID i,ts h(m k m ) ts) to verify the legitimacy of the received broadcast tuple {PID i,ts , σ i , ts, m}, and accepts the message if σ * i = σ i ; otherwise, rejects the message.

B. SYSTEM-KEY UPDATE IN 2FLIP
Fig . 4 shows the message exchange in this phase. In 2FLIP, the CA is responsible for updating vehicle TPDs with new system key. The following steps are executed by vehicle TPDs and CA in this phase: TPD ← CA 1) The CA with identifier ID CA encrypts a new system key k m under the previous system key k m such that c = Enc k m (ts key ID CA k m ). Note that Enc is an encryption procedure, and ts key is time at generating this new system key.
2) The CA broadcasts the message {c, sg} to vehicles in the network through the RSUs. Note that sg is the output of an identity-based message signing function (see [1,). TPD ↓ 1) The TPD receives the key-update message {c, sg}, decrypts c, and recovers the payload {ts key ID CA k m }. Then, the TPD checks the ts key to prevent the replay attack. After that, the TPD verifies ID CA with the previously published ID CA to authenticate the origin of this message. Finally, verifies the signature sg to ensure that the message is valid. 2) The TPD updates k m to k m and ts key to ts key .

C. ADVERSARY MODEL IN 2FLIP
Let A be a Probabilistic Polynomial-Time (PPT) adversary. In the computational world, the PPT adversary A is modeled as a PPT Turing machine [26]. Wang et al. [1] assumed that A has impressive communication abilities through powerful receivers, can control the communication channel, and monitor on-the-fly data exchange, as well as tamper with messages and replace the original messages with modified messages. They assume that the cryptographic keying materials are kept safe in TPDs and key disclosure would never be achieved (see [1,).

III. ATTACKS ON 2FLIP SCHEME
In 2FLIP, a key-update procedure is performed if a cryptographic key breach occur, or if a cryptographic key is unknowingly accessed (see [1,). However, the procedure uses an old system key to encrypt a new system key (key wrapping). This is absolutely a vulnerability. It produces dependencies among keying material (see [1,, or refer to Section II-B). In the case where a past system key k m is compromised, the new key k m is very easily compromised.

A. KNOWN-KEY ATTACK
In 2FLIP, a known system key k m is used by all vehicle TPDs. If a single vehicle's system key is compromised, all vehicles in the network will need to be updated with a new system key. However, the key-update phase proposed in 2FLIP is not secure. Clearly, it is a simple matter for the adversary to successfully perform a known-key attack: 1) The adversary is aware of a compromised key k m .
2) The adversary eavesdrops c = Enc k m (ts key ID CA k m ) on the broadcast message {c, sg} (refer to Section II-B).
3) The adversary decrypts c = Enc k m (ts key ID CA k m ) using the known system key k m , and recovers the new system key k m .

B. MESSAGE FORGERY ATTACK
Lack of perfect forward secrecy results in message forgery attack. Wang et al. [1] claim that 2FLIP is resistant to forgery or modification of message because the adversary cannot forge or modify the message {PID i,ts , σ i , ts, m} (refer to Section II-A) to let it be accepted by other vehicles (see [1, §V -B]). This research proves that an attacker (an external adversary who is an unregistered vehicle user) can launch this attack efficiently. The following steps can be executed by the adversary to successfully perform a message forgery attack: 1) The adversary A randomly picks a personal identifier PID i ∈ Z * q , where q is order of a cyclic additive group G.
2) The adversary uses the k m compromised in the keyupdate phase (explained in Section III-A) to generate a valid tuple {PID A,ts , σ A , ts, m} and broadcast for a long period of time, where σ A = mac k m (PID i,ts h(m k m )||ts), m is an arbitrary message, h is a simple hash function, and ts is current time. 3) A receiver TPD i calculates σ * A = mac km (PID A,ts h(m k m ) ts) to verify the legitimacy of the received broadcast tuple {PID A,ts , σ A , ts, m}, and accepts the message as σ * A = σ A .

IV. THE PROPOSED COUNTERMEASURE
This section proposes a modification to improve the 2FLIP system-key update protocol. Since the scheme is efficient, this research slightly modifies the protocol to improve its security (Section IV-D). Seven steps are added to the System Initialization and Entity Registration phase of 2FLIP (Section IV-C), and propose an alternative System-key Update protocol.

A. SECURITY OBJECTIVES AND DESIGN GOALS
This section focuses on security objectives of the proposed system-key update protocol, including: message integrity and authentication, confidentiality of the new system key, anonymity and unlinkability, and perfect forward secrecy. Message Integrity and Authentication: Message authentication provides assurance of data origin, and also data integrity [9]. The authentication process must be secure against an adversary trying to fabricate (forge) an authentication tag for a message without having access to the respective legitimate sender's secret credential.
Confidentiality of New System key: This is to ensures that no efficient adversary can infer any information about the new system key sent to the vehicle TPD.
Anonymity and Unlinkability: It should be impossible for an adversary and the network entities (except the CA) to link a message to a vehicle/driver correctly. If an observer tried to guess which vehicle transmitted a particular message, there should be only a low probability of linking a vehicle's actions or identifying it among the set of all vehicles.
Perfect Forward Secrecy: Ensures that compromise of past session keys does not allow an adversary to compromise future session keys [9, §12.17]. A protocol is vulnerable to a known-key attack if perfect forward secrecy is not provided.

B. BUILDING BLOCKS
The modification proposed in this research involves the use of Elliptic Curve Integrated Encryption Scheme (ECIES) proposed by Abdalla et al. [27]. The ECIES is a hybrid publickey encryption scheme, and employs the Diffie-Hellman protocol [28] over elliptic curves to establish a symmetric encryption key. This research uses ECIES with the (wellknown) cryptographic primitives. This section briefly reviews these cryptographic primitives and their underlying security assumptions.

1) SYMMETRIC ENCRYPTION SCHEME
Let (Enc, Dec) denote a symmetric encryption scheme which provides Indistinguishability under Chosen-Plaintext Attacks (IND-CPA): given two messages of equal length, a challenger randomly decides to encrypt one of the messages and to the adversary. It should be hard for the adversary to distinguish which of the messages was encrypted. The symmetric encryption operation Enc(m, k 1 ) outputs ciphertext k 1 C(m): a plaintext m is encrypted under symmetric key k 1 . The corresponding decryption operation Dec( k 1 C(m), k 1 ) outputs message m: ciphertext k 1 C(m) is decrypted under symmetric key k 1 . The maximum advantage of PPT adversary A in breaking the IND-CPA property of (Enc, Dec) is denoted by Adv ind-cpa A (Enc,Dec) . This proposal uses the Advanced Encryption Standard in Counter Mode (AES-CTR) for symmetric encryption, as specified in National Institute for Standards and Technology (NIST) Special Publication (SP) 800-38A [29]. it should be computationally infeasible for the adversary to find a valid pair of message and tag whether the message is new and has never been signed by a legitimate signer, or the message is old and the new tag is not previously attached to this message by a legitimate signer [30]. The HMAC operation HMAC(m, k 2 ) outputs tag k 2 δ(m): a tag is generated on message m under symmetric key k 2 . To verify a received message-tag pair, a new HMAC tag k 2 δ (m) is generated on the message and the tags are compared: the tag k 2 δ(m) is accepted if, and only if, k 2 δ (m) = k 2 δ(m). The maximum success probability of PPT adversary A in finding a forgery is denoted by Succ suf-cma A (HMAC) , where A is given access to the tagging/verification oracle. This proposal uses the HMAC for message authentication, as specified in the (U.S.) Federal Information Processing Standard (FIPS) 198-1 [31], as well a Secure Hash Algorithm Hash, as specified in the FIPS 180-4 [32].

3) HASH-BASED KEY-DERIVATION FUNCTION
Let HKDF () denote a Hash-based Key-Derivation Function (HKDF) based on the HMAC presented in Section IV-B2 which extracts an input master secret key k, and expands it into several additional pseudorandom secret keys [33]. For instance, two secret keys k 1 and k 2 can be derived (extract process) such that k 1 = HKDF (1, k) and k 2 = HKDF (2, k), where 1 and 2 are salt values. The HKDF is defined to operate with and without random salt [34]. The security of HKDF as a HMAC-based KDF is based on the assumption that the compression function of the underlying hash is itself a Pseu-doRandom Function (PRF) [35]. The maximum advantage of PPT adversary A in distinguishing the outputs of PRF better than by a random guess and breaking security of the PRF is denoted by Adv ind-sec A (PRF ) . This proposal uses the HKDF to convert a shared-secret into key material suitable for use in encryption, integrity checking or authentication, as specified in the Request For Comments (RFC) 2898 [36].

C. SYSTEM INITIALIZATION AND ENTITY REGISTRATION
To address the perfect forward secrecy issue, this section adds seven steps to the original version of the protocol in the System Initialization and Entity Registration phase. The CA generates system parameters and cipher suite components. The following steps are executed by the CA and a vehicle user in this phase: 1) The CA chooses a large prime p, a random point P of order q, and an elliptic curve E (F q ) over finite field F to satisfy the Short Weierstrass form of equation, y 2 = x 3 + ax + b (mod q) [37], where q = p m for m ≥ 1 is the smallest positive integer such that q.P = O, a, b ∈ F q are the constant coefficients of the curve, and P be the cyclic subgroup of points generated by P.
2) The CA generates system parameters CA par = {p, q, a, b, P, csc}, where csc is a list of cipher suite components applicable in the network (e.g., NIST P-256 curve and SHA-256).

3) The
CA computes password PW D u = HKDF (salt u , pwd u ) for the vehicle user, where salt u and pwd u are two long unique values (e.g., 16 bytes each) generated truly at random. 4) The CA stores the hash value PW D u in its database. 5) The CA stores salt u in the vehicle TPD. 6) The CA delivers pwd u to the user securely. 7) The user provides further identity information (e.g., national identity/security number), a valid mobile phone number, or alternatively requests a hand-held password generator token. The token generates a password which is synchronized with the server, and is valid for a short period of time (e.g., one minute).

D. AN ALTERNATIVE SYSTEM-KEY UPDATE PROTOCOL
This section proposes an alternative system-key update protocol. Fig. 5 shows the message exchange in this phase. The modification is based on the use of vehicle user's mobile phone or a password generator token. The CA can update all TPD related keying materials and the user's salt value salt u without relying on the previous keys used by the CA and the TPDs. In addition, the CA can generate a new set of system parameters CA par including its new public/private key pair, and update the vehicles with the new parameters. The key-update procedure can be called by a user, or advertised by the CA through RSUs; for example, at regular intervals (e.g., every 6 months) or when a long-term key is leaked. The following steps are executed by the vehicle and the CA in this phase: If the user does not have a token, the following steps need to be executed by the user and the CA in this phase: User CA 1) The user sends a key-update request to the CA through a Short Message Service (SMS). 2) The CA locates the PID i corresponding to the user's mobile phone number in its database.
3) The CA generates a Personal Identification Number (PIN) pin phone for the user. 4) The CA computes a symmetric key k up = HKDF (pin phone , PW D u ), where PW D u = HKDF (salt u , pwd u ) is the user's password saved in the CA's database (refer to Section IV-C). 5) The CA derives a secret key k 3 such that k 3 = HKDF (3, k up ). 6) The CA generates a HMAC tag re f = k 3 δ(0) for use as a reference number. 7) The CA sends pin phone to the user's mobile phone through SMS. 8) The CA links re f and k up to PID i in its database for a short period of time (e.g., 1 minute). Those users who are provided a hand-held password generator token by the CA can present the PIN pin token to proceed this phase. This PIN is a password generated by the token and is synchronized with the CA. The PIN is valid for a short period of time (e.g., 1 minute). If the user has a token, the following steps need to be executed by the CA periodically (similar to the token's password changing rate) in this phase: CA ↓ 1) The CA computes a symmetric key k up = HKDF (pin token , PW D u ). 2) The CA derives a secret key k 3 such that k 3 = HKDF (3, k up ). 3) The CA generates a HMAC tag re f = k 3 δ(0) as a reference number. 4) The CA links re f and k up to PID i in its database and always replaces a new generated re f value with the old one and updates the link. The following steps are executed by the vehicle TPD and the CA in this phase: TPD → CA 1) The TPD asks the user to enter the pwd u through the OBU's computing interface. The pwd u is the user's registration password which is created in the entity registration phase (refer to Section IV-C).
2) The TPD loads salt u and computes PW D u = HKDF (salt u , pwd u ).
3) The TPD asks the user to enter the pin phone through the OBU's computing interface and computes a key k up = HKDF (pin phone , PW D u ), if this is a phone-based keyupdate. 4) The TPD asks the user to enter the pin token through the OBU's computing interface and computes a key k up = HKDF (pin token , PW D u ), if this is a token-based keyupdate.
5) The TPD derives three secret keys k 1 , k 2 , and k 3 such that k 1 = HKDF (1, k up ), k 2 = HKDF (2, k up ), and k 3 = HKDF (3, k up ). 6) The TPD generates a HMAC tag re f = k 3 δ(0) as a reference number (similar to the CA's generated reference number). 7) The TPD chooses a random temporary private key d t ∈ R Z * q and computes a temporary public key Q t = d t .P. 8) The TPD computes ciphertext k 1 C(Q t ). Note that the key Q t must be encrypted, because it is used to establish a Diffie-Hellman shared secret key by the CA when it responds to this request. Otherwise, the adversary can forge an authentication tag on any malicious response. 9) The TPD generates a HMAC tag k 2 δ(m) on message m = {re f , k 1 C(Q t ), t s }. 10) The TPD sends tuple {m k 2 δ(m)} to the CA. This tuple is only sent once, which does not harm the privacy requirements (anonymity and unlinkability). TPD ← CA 1) The CA determine the freshness, and accepts the message if, 0 ≤ t r − t s ≤ t, otherwise drops the message.
2) The CA reads reference number re f in message m, and searches for the corresponding PID i linked to re f in its database (the CA drops the message if nothing is found).
3) The CA verifies that the vehicle PID i is not recently blocked because of malicious activity, otherwise stops the process. 4) The CA loads the corresponding k up value linked to PID i and derives two secret keys k 1 and k 2 such that k 1 = HKDF (1, k up ) and k 2 = HKDF (2, k up ). 5) The CA generates a new HMAC tag k 2 δ (m) and accepts the message if, and only if, k 2 δ (m) = k 2 δ(m). This is to ensure that message m has not been altered. 6) The CA decrypts ciphertext k 1 C(Q t ) and recovers the vehicle TPD's temporary public key Q t . 7) The CA chooses a random integer b ∈ R Z * q , and computes β = b.P and k = b.Q t . 8) The CA derives two secret keys k 1 and k 2 such that k 1 = HKDF (1, k ) and k 2 = HKDF (2, k ). 2) The TPD computes k = d t .β. It works because 3) The TPD derives two secret keys k 1 and k 2 such that k 1 = HKDF (1, k) and k 2 = HKDF (2, k ). 4) The TPD generates a new HMAC k 2 δ (m) and accepts the message if, and only if, k 2 δ (m) = k 2 δ(m), otherwise drops the message. This is to ensure that message m has not been altered. 5) The TPD decrypts ciphertext k 1 C(T skup ) and extracts T skup = {k m , salt u }. 6) The TPD stores the new system key k m , salt u , and CA par .

V. SECURITY AND PRIVACY ANALYSIS
This section defines a security model, and conducts a security proof to show that our proposed system-key update protocol F skup for 2FLIP scheme 2FLIP is indeed provably secure. Next, based on the requirements explained in the security objectives and design goals in Section IV-A, the security and privacy analysis are carried out in detail.

A. SECURITY MODEL AND DEFINITIONS
The actual security proof consists of a reduction of the underlying computational problem to an attack against the cryptographic scheme: if there exists an adversary that has a significant advantage against F skup , then there is an adversary to solve the computational problem. In the computational world the PPT adversary A is modeled as a PPT Turing machine [26]. This section shows that the view of A in the reduction remains unchanged from the one it has during a real attack.

Definition 1 (Adversary's Advantage):
A can guess b for a bit b where b is a fair coin. The advantage Adv A is the probability taken over all coin tosses made by A, which is: The advantage Adv A measures that how much A is better than an adversary who simply guesses at random. An adversary who guesses at random has a success probability of 1/2, and an advantage of Adv = 0. When the adversary always correctly finds the value of b , we have Pr[b = b ] = 1 and thus an advantage of Adv = 1.
Definition 2 (Negligible Function): A function : N → R is negligible if for every positive polynomial p(.) there exists an N ∈ N such that for all N < n ∈ N it holds that (n) < 1/p(n) [38].

Definition 3 (Security Model):
Based on the network model and the adversary's ability, we define the security model of our proposed system-key update protocol F skup for 2FLIP scheme 2FLIP through a game played between the PPT adversary A and a simulator S which simulates the protocol F skup specification and answers all queries of the adversary.

Definition 4 (Adversarial Queries):
The adversary A participates in the actual execution of the system-key update protocol instance F skup and may, at any time, send the following queries to an oracle: r Execute query Execute(TPD,CA): This query models passive attacks. The adversary A eavesdrops the execution of the system-key update protocol instance F skup between a chosen TPD and the CA. A learns the corresponding transcript. Game G 1 . [Same random secret k up in F skup-req ] In this game the simulation aborts if during the interaction the simulator on behalf of the TPD chooses random k up in the vehicle system-key update protocol F skup-req during TPD → CA key-update request. Considering the probability for the collision of two random choices (λ-bit length each) we obtain: [Pseudo-randomness of k 1 , k 2 , and k 3 in F skup-req ] In this game the simulator on behalf of the TPD chooses random k 1 , k 2 , and k 3 instead of computing them using the pseudo random function PRF in the vehicle system-key update protocol F skup-req during TPD → CA key-update request, where the random secret k up was used to compute k 1 = HKDF (1, k up ) (secret key for encrypting Q t ), k 2 = HKDF (2, k up ) (secret key for generating HMAC tag), and k 3 = HKDF (3, k up ) (secret key for generating a HMAC tag as a reference re f ). Due to the pseudo-randomness of PRF, we obtain: [HMAC Forgery in F skup-req ] In this game the simulation aborts if A queries on the message {m k 2 δ(m)} in the vehicle system-key update protocol F skup-req such that k 2 δ(m) is a valid HMAC authentication tag on a TPD → CA key-update request string {m = re f , k 1 C(Q t ), t s }. To achieve this, A must find a new message/tag pair, or an old message as long as the output tag was not previously attached to this message by a legitimate TPD. If A can do this, we can say that A breaks the SUF-CMA security of the applied HMAC scheme. Thus: In this game the simulator replaces the ciphertext k 1 C(Q t ) with k 1 C(y) = Encrypt(y,k 1 ) for randomly chosen y in the vehicle system-key update protocol F skup-req during TPD → CA key-update request. Due to the IND-CPA property of (Enc,Dec) we obtain: [Same random secret k in F skup-res ] In this game the simulation aborts if during the interaction the simulator on behalf of the CA chooses the same random secret k = b.Q t in the vehicle system-key update protocol F skup-res during TPD ← CA key-update response. Considering the probability for the collision of two random choices (λ-bit length each) we obtain: [Pseudo-randomness of k 1 and k 2 in F skup-res ] In this game the simulator on behalf of the CA chooses random k 1 and k 2 instead of computing them using the pseudo random function PRF in the vehicle system-key update protocol F skup-res during TPD ← CA key-update response, where the random secret k = b.Q t was used to compute k 1 = HKDF (1, k ) (secret key for encrypting T skup ) and k 2 = HKDF (2, k ) (secret key for generating HMAC tag). Due to the pseudo-randomness of PRF we obtain: [HMAC Forgery in F skup-res ] In this game the simulation aborts if A queries on the message {m k 2 δ(m)} in the vehicle system-key update protocol F skup-res such that k 2 δ(m) is a valid HMAC authentication tag on a TPD ← CA key-update response string {m = re f , k 1 C(T skup ), β,CA par , t s }. To achieve this, A must find a new message/tag pair, or an old message as long as the output tag was not previously attached to this message by a legitimate TPD. If A can do this, we can say that A breaks the SUF-CMA security of the applied HMAC scheme. Thus: In this game the simulator replaces the ciphertext k 1 C(T skup ) with k 1 C(y) = Encrypt(y,k 1 ) for randomly chosen y in the vehicle system-key update protocol F skup-res during TPD ← CA response. Note that T skup contains new key-material. Due to the IND-CPA property of (Enc,Dec) we obtain: The probability of A in winning Game G 8 is: which yields the result stated as the following theorem. Theorem 1: If PRF is pseudo random, (Enc,Dec) is IND-CPA secure, and HMAC is SUF-CMA secure (as defined in Section IV-B), then F skup in 2FLIP (refer to Section IV-D) is secure in the following sense: the maximum probability of success for A to break the security of F skup (as defined in Section IV-A) is a negligible function of the security parameter λ as follows: (1) Corollary 2: The vehicle system-key protocol F skup provides anonymity and unlinkability in the sense of randomness presented in Games G 1 , G 2 , G 5 , and G 6 . That is, A has a low probability of success in identifying a vehicle TPD among the set of all vehicles using its transmitted data.
Corollary 3: The vehicle system-key protocol F skup provides confidentiality of new system key in the sense of indistinguishability presented in Games G 8 .

VI. PERFORMANCE ANALYSIS
This section evaluates the performance of the new system-key update protocol presented in Section IV-D.
The investigation covers the Average Computation Time (ACT) of the various cryptographic operations providing 128bit security level, including: Elliptic Curve Cryptography (ECC) base point scalar multiplication (T scal mul ), AES-128 CTR mode encryption (T aes enc ) and decryption (T aes dec ), HKDF-256 (T hkdf sha ), and HMAC-256 (T hmac sha ). The investigation is performed using the newest stable release branch (1.1.1 series) of the OpenSSL software library [39]. All ECC operations are evaluated over NIST P-256 curve for achieving 128-bit security level [40]. The experiment for each cryptographic operation involved 10 6 trials in Debian Linux distribution running on an Intel Core 2 Duo Processor T6570 (2Megabytes Cache, 2.10 GHz, 4 GB RAM). Note that the latest highperformance automotive single chip modem for vehicular communications made by NXP Semiconductors (the Road-LINK SAF5400 [41]) offers the same performance as the 2.10 GHz Intel Core 2 Duo-T6570 processor used in this study [5], [7], [42].
To have more useful results, this research practically estimates the cryptographic overhead of the new system-key update protocol on packet size. Table 3 lists the results of investigation.

A. COMPUTATIONAL COST
This section evaluates the computational cost of the new system-key update protocol presented in Section IV-D. We use the evaluated ACT (for each single cryptographic operation in Table 3) to calculate the total computational cost in each step of our proposed system-key update protocol.
For the first step, the CA requires to perform two HKDF and one HMAC calculations (overall 1.11×10 −5 sec), then sends the PIN to the user. This preparation is only required for the phone-based key-update.
For the third step TPD ← CA, the CA requires to perform four HKDF, two HMAC, one point scalar multiplication, one symmetric decryption, and one symmetric encryption computations (overall 1.63×10 −4 sec).
For the fourth step, the TPD requires to perform two HKDF, one HMAC, one point scalar multiplication, and one symmetric decryption computations (overall 1.51×10 −4 sec). Table 4 summarizes the results of investigation. Please refer to Table 3 to find the ACT corresponding to each single operation.

B. COMMUNICATION OVERHEAD
This section evaluates the communication overhead of the new system-key update protocol presented in Section IV-D.
The new system-key update protocol produces 100 bytes of overhead during TPD → CA key-update request, including: one HMAC tag (the reference number) re f = k 3 δ(0) = 32 bytes, one AES ciphertext k 1 C(Q t ) = 32 bytes (for 32 bytes ECC point Q t in compressed size), one time stamp t s = 4 bytes, and one HMAC k 2 δ(m) = 32 bytes. Note that the AES-CTR encrypted ECC point k 1 C(Q t ) has a size similar to the  point Q t before encryption, for example k 1 C(Q t ) = 100 bytes where Q t = 100 bytes.
The protocol also produces 148 bytes of overhead during TPD ← CA key-update response, including: one HMAC tag re f = 32 bytes, one AES ciphertext k 1 C(T skup ) = 48 bytes (for 32 bytes new system key k m and 16 bytes new salt u in T skup = {k m , salt u }), one ECIES parameter (ECC point in compressed size) β = 32 bytes, one time stamp t s = 4 bytes, and one HMAC k 2 δ(m) = 32 bytes. Table 5 summarizes the results of investigation. Please refer to Table 3 to find the cryptographic overhead corresponding to each payload.

VII. COMPARISON AND DISCUSSION
Unlike Wang et al.'s protocol [1], the proposed system-key update protocol in this paper does not use an old system key to encrypt and decrypt a new system key, and as a result, it does not produce dependencies among keying material. In case of compromise of past system key, a new system key is not compromised.
In terms of computational cost, the 2FLIP system-key update protocol requires one symmetric encryption/decryption, one hash, and two cryptographic pairing computations (see [1, §VI - Table 6]). To calculate the computational cost of cryptographic pairing [42], [44], an investigation is performed using the newest stable release branch (1.1.1 series) of the OpenSSL software library [39], as declared in Section VI. The elliptic curve arithmetic and optimal Ate pairing [45] are over the Barreto-Naehrig (BN) curve [46] in the evaluation, where the minimum bit-length of p is estimated as 382 bits (achieving 127-bit security level [47]), an optimistic parameter to use in cryptographic pairings for 128-bit security level (384 bits p) [48]. Table 6 summarizes the results of investigation for computational cost in 2FLIP key-update protocol (CA to TPD). The result for one optimal Ate pairing is 5.4×10 −3 sec. Ignoring the symmetric decryption and hash calculation, only two cryptographic pairing computations requires 10.8×10 −3 sec, approximately 70 times slower than our proposed protocol in   this paper with 1.6×10 −4 sec computational overhead (refer to Section VI-A).
In terms of communication overhead, the 2FLIP systemkey update protocol generates 88 bytes of overhead (see [1, §VI - Table 6]). However, our new protocol presented in this paper generates 148 bytes of overhead (refer to Section VI-B), only 60 bytes more than 2FLIP. Table 7 summarizes the results of investigation for communication overhead in 2FLIP key-update protocol (Broadcast from CA).
In our proposal, the key-update procedure can be called by a vehicle TPD (TPD → CA), or advertised by the CA (TPD ← CA) through RSUs. However, the system-key update request from TPD to CA (TPD → CA) in 2FLIP is a missing functionality. The only entity that can call a system-key update procedure is CA. Table 8 shows the performance overhead comparison between 2FLIP and our proposed system-key update protocol. Please refer to Figs. 6 and 7 to see a detailed comparison for each computational and communication overhead, respectively. The new system-key update protocol presented in this paper uses the encrypt-then-MAC method [49] where the encryption scheme is IND-CPA secure (refer to Section IV-B1) and the MAC is SUF-CMA secure (refer to Section IV-B2). This method implies that decryption will only be carried on ciphertext that passed an integrity test. The adversary thus cannot observe use of the decryption key on ciphertext which is chosen randomly, since that ciphertext will not pass the MAC verification and will not be decrypted. Hence, the ECIES used in this protocl should provide Indistinguishability under Chosen-Ciphertext Attacks (IND-CCA) [30]: the adversary has an additional capability over the IND-CPA, calling an encryption or decryption oracle for encrypting or decrypting arbitrary messages before obtaining the challenge ciphertext.

VIII. CONCLUSION AND FUTURE DIRECTION
This paper presents an analysis of Wang et al. [1] 2FLIP: A Two-Factor Lightweight Privacy Preserving Authentication Scheme for VANET. The 2FLIP authors claimed that their scheme provides a secure system-key update and resists message forgery attacks. However, we demonstrated that this is incorrect. Their scheme could not achieve the claimed goals as it does not provide perfect forward secrecy. We demonstrated this with two successful attacks on 2FLIP: a known-key attack reveals subsequent keys, and following this, a message forgery attack using the known key can be performed. We have proposed a new system-key update protocol that addresses the security flaws in the 2FLIP scheme. We performed an indepth security analysis supported by formal security proof to demonstrate that our solution can effectively satisfy the security and privacy requirements. We demonstrated the efficiency of our protocol by conducting extensive performance analysis. The enhanced system-key update protocol will also be useful for researchers and designers to apply in VANET authentication schemes.
As quantum computing becomes feasible, many of the current public-key cryptographic schemes will be broken. Most of the existing authentication and key-management protocols in public literature rely on these algorithms. However, to the best of our knowledge, there have been no research efforts that examine the quantum-safety aspects of key-management protocols in the context of vehicular communications. This is a potential avenue for future research.