An Enhanced Privacy-Preserving Authentication Scheme for Vehicle Sensor Networks.

Vehicle sensor networks (VSNs) are ushering in a promising future by enabling more intelligent transportation systems and providing a more efficient driving experience. However, because of their inherent openness, VSNs are subject to a large number of potential security threats. Although various authentication schemes have been proposed for addressing security problems, they are not suitable for VSN applications because of their high computation and communication costs. Chuang and Lee have developed a trust-extended authentication mechanism (TEAM) for vehicle-to-vehicle communication using a transitive trust relationship, which they claim can resist various attacks. However, it fails to counter internal attacks because of the utilization of a shared secret key. In this paper, to eliminate the vulnerability of TEAM, an enhanced privacy-preserving authentication scheme for VSNs is constructed. The security of our proposed scheme is proven under the random oracle model based on the assumption of the computational Diffie-Hellman problem.

1. Introduction

With the rapid development of the intelligent transportation systems (ITSs) [1], vehicular ad hoc networks (VANETs) have become increasingly popular. The vehicles in VANETs can communicate with each other via wireless communication [2]. If vehicles can interact with other vehicles or the roadside infrastructure to exchange collected data for decision-making and safer driving, traffic jams can be avoided and the safety of drivers can be guaranteed to the utmost extent; consequently, VANETs are a promising means of improving traffic safety and management. At present, vehicles are equipped with various sensors that can provide valuable data. Further equipping vehicles with onboard sensing devices can turn VANETs into vehicle sensor networks (VSNs) [3]. Therefore, the authentication protocols used in VANETs can also be used in VSNs. Moreover, dynamic traffic information and many types of physical data associated with traffic distributions can be sensed and collected by such vehicular communication networks. Therefore, VSNs are expected to significantly facilitate future wireless communication.

Two types of communication exist in VANETs, namely vehicle-to-vehicle (V2V) communication and vehicle-to-infrastructure (V2I) communication, which depend on two essential kinds of components: onboard units (OBUs) and roadside units (RSUs). As shown in Figure 1, OBUs are the wireless communication units equipped on vehicles, whereas RSUs are wireless access units located at significant places on the road. Generally, to assist vehicles and RSUs in performing certain tasks, such as authentication, a backend server should be deployed remotely. The characteristics of VANETs include self-organization, channel-opening behavior, and rapidly changing and multiple-hop topologies. Due to these characteristics, VANETs are more susceptible to malicious attacks. Since safety and privacy are a concern in many applications in VANETs [4,5], communication security issues are worthy of attention. Among the various security mechanisms used in VANETs, authentication is one basic component that is critical for ensuring security. However, a desirable authentication scheme must be efficient and practical for use in fast-moving scenarios, which means that the computation cost for authentication should be as low as possible to enable real-time response. In addition, privacy preservation should be considered, including the identity privacy, location privacy, and interest privacy. Moreover, the location of a vehicle is closely related to who is driving it. When a vehicle communicates with others in a wireless network, it will not be acceptable to the public if the vehicle’s identity and location are disclosed. Thus, privacy preservation must be achieved in the authentication procedure. In addition, it should be possible for the real identities of the malicious vehicles to be revealed by the authorities when necessary [5]. These requirements pose a considerable challenge for the development of an ideal authentication scheme.

Figure 1

Structure of a vehicular ad-hoc network.

The contributions of this paper are as follows: (1) an enhanced privacy-preserving authentication scheme based on the Chuang–Lee’s scheme is proposed that can resist internal attack. In addition, we demonstrate the correctness and security of the improved scheme and analyze its computational costs; (2) to preserve the identity privacy of drivers, anonymity is achieved by randomizing the real identities; and (3) to preserve the location privacy of drivers, unlinkability is achieved in the authentication procedure.

The remainder of this paper is organized as follows. Related work is introduced in Section 2. Preliminaries are presented in Section 3. A review of the Chuang–Lee’s scheme is provided in Section 4. Then, a concrete description of the proposed scheme is offered in Section 5. Section 6 presents the proofs of correctness, security and performance. Finally, the conclusions are provided.

2. Related Work

To cope with the challenges associate with VANETs, many types of authentication schemes have been investigated. Porambage et al. [6] introduced a two-phase authentication protocol for sensor networks that uses certificates and consequently cannot preserve the unlinkability of messages. Raya and Hubaux [7] proposed an authentication scheme for VANETs using anonymous certificates, in which each vehicle can utilize distinct key pairs in each authentication stage to avoid being tracked. However, frequent changing of key pairs is likely to result in burdensome management and storage requirements. Lu et al. [8] proposed an alternative way to avoid the complexity of preloading a large number of anonymous certificates with the support of RSUs. When a vehicle passes an RSU, it will be issued a short-term anonymous certificate; thus, the unlinkability of messages is preserved. However, the efficiency will inevitably be low because each vehicle must frequently interact with RSUs. Subsequently, Lin et al. [9] introduced another secure scheme that does not require interaction with RSUs, in which membership managers, rather than RSUs, are responsible for the issuing of certificates based on group signatures. However, the efficiency of this solutions is low. Zhang et al. [10] presented two additional authentication schemes with privacy preservation; however, the computational costs of their methods are somewhat high because of the utilization of bilinear pairing. Similarly, Zheng et al. [11] introduced an authenticated key agreement scheme based on bilinear pairing. Ou et al. [12] later showed that Zheng et al.’s scheme is susceptible to impersonation attacks, and proposed a more secure authenticated key agreement scheme; however, the computational cost of this scheme is again somewhat high because of the utilization of bilinear pairing. In addition, an authentication scheme with access control for VANETs was investigated by Yeh et al. [13]; however, Horng et al. [14] later showed that Yeh et al.’s scheme [13] is susceptible to privilege escalation attacks.

Recently, Chuang and Lee [15] developed a trust-extended authentication mechanism, called TEAM, for VANETs. In TEAM, vehicles are classified into three types, namely, law executors (LEs), mistrusted vehicles (MVs) and trusted vehicles (TVs), as shown in Figure 1. Moreover, it required each vehicle is equipped with a tamper-proof device from which no attacker can extract any stored data, which is so strong that it is not practical. The performance of this mechanism in response to several types of attacks has been analyzed; however, the linkability of messages in the authentication procedure and the possibility of internal attacks during the secure communication procedure, which can easily be executed by a malicious vehicle, have been ignored. A malicious vehicle can trace a driver by intercepting the message sent during the authentication procedure because the values and are constant. Moreover, a malicious trusted vehicle can compute the real identity of a user and the session key by intercepting a message communicated via the secure communication procedure because it possesses the authorized parameter. Kumari et al. [16] proposed an enhanced trust-extended authentication scheme based on TEAM. However, their scheme fails to protect against internal attacks. Therefore, we have developed an improved authentication procedure and secure communication procedure and have proven their correctness and security. The updating of the constant values used in the authentication procedure is performed by the user himself. Finally, we analyze the computational costs and security features of the improved secure communication procedure.

3. Preliminaries

3.1. Security Model

To accurately capture the capabilities of an attacker, an experiment concerning the interaction between an adversary and a challenger is introduced. The random oracle model, which originates from the work of Bellare et al. [17], is adopted in our security proof. An adversary A can be allowed to communicate with the participants through defined oracle queries; thus, the adversary’s behavior during a real attack can be modeled. In our proposed protocol, each participant is either a common vehicle’s OBU or an LE . Let U represent all participants that is the union of common vehicle’s OBUs and LEs.

3.1.1. Protocol Execution

Let represent the ith instance of a participant and let b denote a randomly chosen bit. All possible oracle queries are described as follows:

: The passive attack capability of the adversary A is tested by this query. Executing this query will output an honest execution transcript of the protocol.

: The active attack capability of the adversary A is tested by this query. A can send a request on a message M to . Upon receiving this message, proceeds with the normal execution of the protocol, and then returns the calculated result to the adversary A.

: This query models an attack that steals a vehicle’s OBU attack. Upon execution of this query, all the information stored in the OBU of vehicle will be extracted by A.

: This query models a known key attack. If a session key has been obtained by , then the session key of instance is returned to A. Otherwise, ⊥ is returned.

: This query models the ability of the adversary A to distinguishing a real session key from a random key. If the session key of participant has not been defined, ⊥ will be returned. Otherwise, if , then the session key of instance will be returned; if , a random key of the same size will be returned.

3.1.2. Notation

An instance is said to have been opened if A has issued a query to it; otherwise, it is said to be unopened [18]. After receiving the last expected protocol message, enters an accept mode and it is said to be accepted.

3.1.3. Partnering

To illustrate the process of partnering, the concept of a session identification code is introduced. Given , instances and are called partners only when the following conditions hold: (1) and have entered accept mode. (2) The same is shared between and . (3) and are partners of each other.

3.1.4. Freshness

To avoid cases in which the security of the scheme is trivially broken by the adversary, the concept of freshness is introduced. The objective is to only permit the adversary to issue queries to fresh oracle instances. Specifically, an instance is called fresh when it enters accept mode and both and its partner are unopened.

3.1.5. Semantic Security

Suppose that an adversary A executes a protocol P. A can ask a query to a fresh instance after being given access to , , , and queries, and outputs a guess bit . If where b is chosen in the query, A is said to win this experiment defining semantic security. Let represent the event in which A is successful. The advantage of A in breaking the semantic security of P is defined as follows where the password is selected from a dictionary D.

3.2. Elliptic Curve Discrete Logarithm Problem

Let G be an elliptic curve group defined by a generator P and a prime number p. Then, the two central mathematical problems in elliptic curve cryptography (ECC), namely, the discrete logarithm problem and the computational Diffie–Hellman assumption, can be defined as follows [19].

Elliptic curve discrete logarithm (ECDL) problem. Let , where and . The objective of the elliptic curve discrete logarithm problem is to find a when given two points .

Elliptic curve computational Diffie–Hellman (ECCDH) assumption. Let G denote a representative group of order p and A denote an adversary. Consider the following experiment:

The advantage of A in solving the ECCDH problem is defined as follows: where the maximum is taken over all A with time-complexity at most t.

4. Review of the Chuang–Lee’s Scheme

In this section, we review Chuang and Lee’s trust-extended authentication scheme (TEAM) [15]. In their scheme, the vehicles are classified into three types, namely, law executors (LEs), mistrusted vehicles (MVs) and trusted vehicles (TVs), as shown in Figure 1. An LE, such as a police vehicle, is treated as permanently trusted and plays a role similar to that of a mobile authentication server (AS). When a normal vehicle is authenticated successfully, it is deemed to be trusted, otherwise, it is treated as mistrusted. A TV will turn into an MV once the lifetime of its key has expired. To ensure the security of communication, an OBU can obtain service from providers only if it has been authenticated successfully.

TEAM consists of eight procedures: registration, login, password change, general authentication, trusted-extended authentication, secure communication, key update and key revocation. Before each vehicle joins the network, its OBU performs the registration procedure to register itself with the AS. The login procedure is performed when a vehicle intends to access service from the vehicular ad hoc network. After successfully completing the login procedure, the OBU checks its authentication state. If the vehicle is an MV, it needs to perform either the general authentication procedure or the trust-extended authentication procedure; it will then turn into a TV once it has been authenticated successfully and has obtained an authenticated key. Then, it can play the role of an LE to authenticate other mistrusted OBUs via the trust-extended authentication procedure. Two trusted vehicles can perform the secure communication procedure to interact with each other. A trusted vehicle can choose to perform the key update procedure with an LE when its key is approaching expiration. Otherwise, the state of the TV changes to mistrusted when the lifetime of the key has expired.

The OBU of each vehicle is equipped with secure hardware, including a tamper-proof device (TPD) and an event data recorder (EDR). The TPD hinders an attacker from obtaining information from the OBU. Recording important data, such as public parameters, preloaded secret keys, times, and locations, is the responsibility of the EDR. In addition, each vehicle is synchronized via a GPS device. Finally, each vehicle periodically broadcasts a hello message with its authentication state (mistrusted or trusted). The related notations are briefly defined in Table 1. The details of the TEAM protocol follow.

Table 1

The notations.

Notation	Definitions
x	A private key for the AS
x_i	A private key for user i
PSK	A pre-shared secure key set among the LEs and the AS
ID_i	The identification code for entity i
PW_i	The password for user i
AID_i	The alias for entity i
h	A secure hash function
⊕	The XOR operator
∥	The combination of strings
P_pub_i	A public key for user i and P_pub_i=x_iP
p	A secure large prime
E(F_p)	A secure elliptic curve
P	The primitive generator for G
G	The subgroup of E(F_p) with order p
Zp*	The set consisting of all primes in {0,1,…,p−1}
r,y∈_RZp*	An element selected randomly from Zp*
SK_ij	A session key between entity i and entity j
MSG_KU	A key update message

4.1. Registration

LE Registration: In this procedure, an LE registers itself with the AS via the manufacturer or a secure channel. The secure key set is sent to the LE by the AS. Only this secure key set is required to be stored in the secure hardware of the LE. No other user information needs to be stored. Furthermore, the lifetime of each is set to be short for robust security. When the lifetime of each trusted vehicle’s key expires, this vehicle is required to perform the key update procedure with the LE. The procedure for the key set generation is depicted in Figure 2. It can be seen that the old (e.g., ) cannot be used to derive the new (e.g., ) because a one-way hash function is introduced in the key generation procedure.

Figure 2

Key set generation scheme based on the hash–chain method.

Normal Vehicle Registration: All vehicles except LEs need to perform this procedure when they are delivered to market. This registration procedure is performed only once by each vehicle.

: A user chooses his password and sends its public identity and to the AS via the manufacturer or a secure channel.

The AS evaluates the following parameters for after it receives and : , , , and .

: The parameters (i.e., ) are stored in the OBU’s secure hardware by the AS via a secure channel.

4.2. Login

The login procedure is performed when a user intends to access the service from vehicle sensor networks. The login procedure is described as follows:

: and are input to by .

First, verifies . Then, it checks whether holds. If so, launches the general authentication procedure or the trust-extended authentication procedure. Otherwise, the login request will be rejected.

4.3. Password Change

When a user wants to update his password, he invokes the optional password change procedure. The steps of this procedure are described below:

and are input to its by .

First, verifies checks whether . If so, will be requested to input his new password . computes and replaces with . Otherwise, the request will be rejected.

4.4. General Authentication

The general authentication procedure is performed between and after has completed the login procedure. The steps of this procedure are described below:

chooses a random number and computes its alias . Then, it produces the request messages and .

: The authentication messages (i.e., ,, and ) are sent from to .

Upon receiving the authentication request message (i.e., ,,,), uses to retrieve and and then checks whether holds. The authentication request will be rejected if this equation does not hold. Otherwise, computes and produces a random number with which to calculate and . Finally, calculates the response messages , and .

: returns its response messages (i.e., ,,,) to .

computes to retrieve and checks whether holds. terminates the process if this equation does not hold. Otherwise, computes , calculates , and stores in its secure hardware.

: The message is sent to by .

uses to retrieve . Then, it checks whether the retrieved hash value is equal to the pre-computed hash value using the chosen . In this way, a replay attack from an illegal OBU is avoided.

As this time, the state of changes to trusted since has been authenticated successfully and has obtained the parameter . Now, not only LE but also can authenticate other mistrusted OBUs.

4.5. Trust-Extended Authentication

A mistrusted OBU becomes trusted once it has been authenticated successfully and has obtained . Then, it can play the role of an LE to authenticate other mistrusted OBUs. The corresponding trust-extended authentication procedure is the same as the general authentication procedure.

4.6. Secure Communication

The secure communication procedure is performed between two trusted vehicles and when they intend to interact with each other.

After completing the login procedure, generates a random number and computes the messages , and , where was obtained in a previous authentication procedure.

: A secure communication request (i.e., ,,) is sent to by .

Upon receiving (i.e., ,,), uses to retrieve from and then computes and checks whether it is equal to . The request will be rejected if this equality does not hold. Otherwise, randomly chooses and computes , , and a session key .

: returns the response messages (i.e., ,,) o .

After receiving the messages ,,, verifies whether is trusted: uses to retrieve from and checks whether holds. If so, computes a session key and a reply message . Otherwise, the process is terminated.

: sends to .

After receiving the message , computes and then checks whether it is equal to . If this quality holds, then the two trusted vehicles can communicate securely using . Otherwise, terminates the process.

4.7. Key Revocation

Key revocation will be triggered when the lifetime of a key expires. The state of a mistrusted vehicle changes to trusted when the mistrusted vehicle is authenticated successfully and obtains via performing either the general authentication procedure or the trust-extended authentication procedure. Then, a timer is instantiated by the secure hardware and begins to count down. The state of the vehicle becomes mistrusted when the lifetime of the key expires. When key expiration is approaching, the system requests that the trusted vehicle performs the key update procedure.

4.8. Key Update

The key update procedure will be invoked by when the key lifetime of the TV is approaching expiration. The steps of this procedure are described as follows.

randomly chooses to compute the messages , , and .

: A key update request (i.e., ,,) is sent to by .

retrieves and using the current (i.e., ). The key update request will be rejected if does not match . Otherwise, chooses a random number and computes , , and , where is produced via the hash–chain method. Therefore, the new cannot be inferred by other OBUs using the current . Finally, computes .

: returns the reply messages (i.e., ,, and ) to .

Upon receiving the reply messages, computes to retrieve , and obtains . Next, checks whether and . If this condition holds, renews the and computes . Otherwise, terminates the process.

: sends the message to .

retrieves using . Then, it checks whether the retrieved hash value is equal to the pre-computed hash value using the chosen . In this way, a replay attack from an illegal OBU is avoided. Now, this session key can be used to communicate securely between two trusted vehicles.

5. Improved Scheme

A concrete description of our enhanced privacy-preserving authentication scheme is presented in this section. In our scheme, the vehicles are also classified into three types: law executors (LEs), mistrusted vehicles (MVs) and trusted vehicles (TVs) as displayed in Figure 1. The LEs are equipped with TPD, but the normal vehicles such as TV and MV are not equipped with TPD. Our improved scheme consists of nine procedures: initialization, registration, login, password change, general authentication, trust-extended authentication, secure communication, key update and revocation. The notations used in this section are also briefly defined in Table 1.

5.1. Initialization

The initialization procedure is performed by the AS when it sets up the system parameters:

Let G be an elliptic curve group defined by a generator P and a prime number p. The AS randomly selects as its secret key.

The AS computes the secure key set using the hash–chain method as shown in Figure 2, e.g., .

5.2. Registration

LE Registration: In this procedure, an LE registers itself with the AS via the manufacturer or a secure channel. The secure key set and the public parameters are sent to the LE by the AS. Only the secure key set and the public parameters are required to be stored in the secure hardware of the LE. No other user information needs to be stored. Similarly, the lifetime of each is set to be short for robust security. When the lifetime of each trusted vehicle’s key expires, this vehicle is required to perform the key update procedure with an LE.

Normal Vehicle Registration: All vehicles except LEs need to perform this procedure when they are delivered to market. This registration procedure is performed only once by each vehicle. The steps of the normal vehicle registration procedure are described in Figure 3.

Figure 3

Normal vehicle registration procedure.

: A user chooses his password and sends its public identity and to the AS via the manufacturer or a secure channel.

The AS chooses a random number with which to evaluate the following parameters for after it receives and : , ,, and .

: The parameters (i.e., , , , , ,G,p,P) are stored in the OBU’s secure hardware by the AS via a secure channel.

chooses a number as his private key and computes as his public key, and then computes and stores (, ) in its OBU secure hardware.

5.3. Login

The login procedure is performed when a user intends to access service from the vehicle sensor network. The login procedure is described as follows:

: and are input to by .

First, retrieves . Then, it checks whether holds. If so, launches the general authentication procedure or the trust-extended authentication procedure. Otherwise, the login request will be rejected.

5.4. Password Change

When a user wants to update his password, the optional password change procedure will be invoked. The steps of this procedure are described as follows:

and are input to by .

First, retrieves . Then, it checks whether holds. If so, will be requested to input his new password . computes and and replaces and with and . Otherwise, the request will be rejected.

5.5. General Authentication

The general authentication procedure is performed between and after has completed the login procedure. The general authentication procedure is shown in Figure 4 and the steps are described as follows.

Figure 4

General authentication procedure.

chooses a random number and computes its alias . Then, it produces the request messages and , where is obtained from the login procedure.

: The authentication messages (i.e., , , , , and ) are sent from to .

Upon receiving the authentication request messages (i.e., , , , , and ), uses to retrieve and and then checks whether holds. The authentication request will be rejected if it does not. Otherwise, produces a random number to calculate and . Finally, calculates the response messages , , and .

: return response messages (i.e., , , , and ) to .

computes to retrieve , , and and checks whether holds. terminates the process if it does not. Otherwise, calculates the reply message ; computes and ; replaces and with and , respectively, and stores in its secure hardware.

: The message is sent to to by .

uses to retrieve . Then, it checks whether the retrieved hash value is equal to the pre-computed hash value using the chosen . In this way, a replay attack from an illegal OBU is avoided .

At this time, the state of changes to trusted since has been authenticated successfully and has obtained the parameter . Now, not only but also can authenticate other mistrusted OBUs.

5.6. Trust-Extended Authentication

This procedure is the same as in the Chuang–Lee scheme.

5.7. Secure Communication

The secure communication procedure is performed between two trusted vehicles and when they intend to interact with each other. The secure communication procedure is shown in Figure 5 and the steps are described as follows.

Figure 5

Secure communication procedure.

After completing the login procedure, retrieves ,, then it generates a random number and computes the messages , , , and , where was obtained from a previous authentication procedure.

: A secure communication request (i.e., , , ) is sent to by .

Upon receiving (i.e., , , ), uses to retrieve T from and then computes , and checks whether is equal to . The request will be rejected if this equality does not holds. Otherwise, randomly chooses and computes

: returns the response messages (i.e., , , ) to .

After receiving the messages , verifies whether is trusted: computes , , and , and then checks whether holds. If so, computes a reply message . Otherwise, the process is terminated.

: sends to .

After receiving the message , checks whether holds. if so, the two trusted vehicles can communicate securely using k. Otherwise, terminates the process.

5.8. Key Revocation

This procedure is the same as in the Chuang–Lee scheme.

5.9. Key Update

This procedure is the same as in the Chuang–Lee scheme.

6. Analysis

In this section, we first validate the correctness of the critical general authentication procedure and secure communication procedure using the BAN logic, and we then prove the security of our improved scheme. Finally, we evaluate the performance of our scheme against that of the existing related schemes.

6.1. Correctness

The BAN logic is a useful way to validate the correctness of security protocols, especially for the authentication protocols [20]. Some relevant notations are listed in Table 2. The verification procedure consists of the following steps.

Table 2

Symbol and description of BAN logic.

Symbol	Description
P∣≡X	Entity P trusts opinion X
P◃X	Entity P sees opinion X, or P holds X
P∣∼X	Entity P has said opinion X
P∣⇒X	Entity P completely control over X
♯(X)	X is fresh
Rule1Rule2	Rule2 comes from Rule1
↦kP	k is the public key of entity P
P⟷kQ	k is a secret key or information between P and Q
{X}_PSK	X is encrypted by key K

6.1.1. The Correctness of the General Authentication Procedure

Idealization

First, we use formal logical language to idealize the general authentication procedure in our improved scheme in accordance with the rules of the BAN logic as follows:

:

:

:

Goal

There are two roles in the general authentication procedure: and . Since needs to obtain the authorized parameter from the , it must believe . Moreover, and must believe each other and each other’s aliases, and they must believe the session key computed in the general authentication procedure. Thus, there are five goals of the general authentication procedure in our improved scheme as follows:

: believes .

: believes and his alias .

: believes and his alias .

: believes the share key between himself and .

: believes the share key between himself and .

Assumptions

With the goals set, the assumptions also need to be stated as follows:

: possesses an alias .

: possesses an alias .

: believes the freshness of and .

: believes the freshness of , and .

: believes the share key between himself and .

: believes the share key between himself and .

: believes the share key between himself and .

Verification

In this subsection, we will verify the correctness of our proposed general authentication procedure using the BAN logic. The detailed steps of the proof are as follows:

computes and

,

computes , ,

,

,

,

,

,

,

computes

,

,

,

,

In formula and formulas and , believes that has sent and believes that has sent . Because has verified the correctness of message and has verified the correctness of message , and each believe the other party and its alias, and believes the obtained from . In formula , because is able to calculate and believes this value which is necessary to compute , believes the freshness of , and believes the session key that it computes. Similarly, in formula , believes the value and the freshness of , thus believes the session key that it computes. According to formulas , , , and , we can infer that our improved general authentication procedure achieves our goals.

6.1.2. The Correctness of the Secure Communication Procedure

First, we use formal logical language to idealize the secure communication procedure in our improved scheme in accordance with the rules of the BAN logic as follows:

:

:

:

There are two roles in the secure communication procedure: and , which are the on-board units of the two communication vehicles. Since and need to generate a common session key for their communication, they must believe each other and each other’s identities, and they must believe the session key computed in the secure communication procedure. Thus, there are four goals of the secure communication procedure in our improved scheme as follows:

: believes and its identity .

: believes and its identity .

: believes the shared key between itself and .

: believes the shared key between itself and .

With the goals set, the assumptions also need to be stated as follows:

: owns its identity .

: owns its identity .

: holds own private key .

: holds own private key .

: believes own public key .

: believes own public key .

: holds own public key and ’s public key .

: holds own public key and ’s public key .

: believes the freshness of and .

: believes the freshness of and .

: believes the share key between himself and .

: believes the share key between himself and .

In this subsection, we will verify the correctness of our proposed secure communication procedure using the BAN logic. The detailed steps of the proof are as follows:

computes and

,

,

,

computes ,

,

,

,

,

,

computes

,

.

In formula and formula , believes that has sent and believes that has sent . Because has verified the correctness of message and has verified the correctness of message , and each believe the other’s identity and that the other party is a trusted vehicle. In formula , because can use its private key to obtain and calculate k, can verify by means of and k; thus, believes the session key k that it computes. Similarly, in formula , can compute the session key k to verify , so believes the session key k that it computes. According to formulas , , and , we can infer that our improved secure communication procedure achieves our goals.

6.2. Security Analysis

In this section, the security proof of the critical secure communication procedure and general authentication procedure is presented. We show that the proposed improved protocol is secure through a formal security analysis in the random oracle model as well as an informal security analysis.

Let

To complete the proof, four experiments are constructed, where the first one simulates a real attack. For every experiment , we use an event to denote the event in which the adversary successfully guesses the bit b from the query. ☐

This experiment simulates an actual attack. According to definition, we have

In this experiment, the oracles , , , , as in an actual attack are simulated. It can be seen that one cannot distinguish this experiment from the actual experiment. Thus,

All oracles considered in experiment are also simulated in this experiment; however, all executions are halted where a collision occurs when simulating the and the h oracle. A issues to try to deceive the other participants into accepting a modified message. Simultaneously, it can query the h oracle to verify whether a hash collision exists. Since the messages transmitted in the network are all associated with a participant’s identity, a temporary secret random number and a long-lived key, and the authentication procedure only uses an XOR operation and a hash function, there is no other collision except hash collision. The probability of collision in the h oracle is at most by the birthday paradox. Hence,

All oracles considered in experiment are simulated in this experiment, in addition to stopping the stimulation of a query to an OBU. Note that the information , ,, , and stored in the OBU can be extracted by A when the query is issued. However, this information is useless to A for calculating the session key since it would also need the secret , and it is difficult to derive from without also obtaining the user’s correct password via the password attack. Hence, we obtain

6.2.1. The Formal Security Analysis

In addition, we know that the adversary A can only win the game by guessing the bit b when querying the oracle because the adversary has no advantage. Therefore,

From Equations (2) to (5), we have

Therefore, from Equation (1), we get

Let G represent a group with a prime order p, and where

To complete the proof, six experiments are constructed, where the first one simulates a real attack. For every experiment , we use to denote the event in which the adversary successfully guesses the bit b from the query. ☐

This experiment simulates an actual attack, which begins with the random selection of a secure key . According to definition, we have

In this experiment, the oracles , , , , and , as in the actual attack with a chosen random secure key are simulated. It can be seen that one cannot distinguish this experiment from the actual experiment. Thus,

All oracles considered in experiment are also simulated in this experiment. In addition, we stop simulating the adversary to execute guessing attacks on the real identity of a participant. In this case, we have

Each participant’s real identity is always converted into an alias using a random number (i.e., ). Therefore, the adversary cannot determine the participant’s real identity because every alias is different and there is nothing that can be used to verify the real identity. ☐

All oracles considered in experiment are also simulated in this experiment; however, all executions are halted where a collision occurs among , , , ,,, and . The probability of colliding in the h oracle is at most by the birthday paradox. Similarly, the probability of colliding in the transcript is at most , Consequently,

All oracles considered in as experiment are simulated in this experiment, in addition to stopping the stimulation of a query to an OBU. Note that the information , , , , , , and stored in the OBU can be extracted by A when the query is issued. However, this information is useless to A for calculating the session key since it would require the secure key , a private key and a temporary secret random number, and it is difficult to derive and from and without obtaining the user’s correct password via the password attack. Hence, we obtain

In this experiment, we use the private oracle in place of the oracle h for computing k as shown in Table 3, such that the session key is totally independent of h. More precisely, one obtains in queries. Therefore, the experiments and are indistinguishable except for the occurrence of the following event : A issues queries to h on , i.e., the value . In addition, regardless of the b value that is chosen to be used in a query, the response is independent for all sessions since it is a random number. Therefore,

Table 3

Simulation of random oracles h and .

A hash query h(m) (resp.h^′) that matches a record (m,r^′) in the list Λ_h (resp.Λ_h^′), returns r^′.

Otherwise, it chooses a random number r, adds the record (m,r) to the list Λ_h (resp.Λ_h^′), and returns r.

The execution of the random self-reducibility of the elliptic curve computational Diffie–Hellman assumption given an instance is simulated in this experiment. We randomly select , and let , , , and . Note that means that a query h on has been issued by A, where . Indeed, . We have: Therefore,

If A knows the session key k constructed by , it must have issued queries to h on that was recorded in the list . Therefore, we can conclude that

From Equations (7) to (12), we have

Therefore, from Equation (6), we get

6.2.2. Informal Security Analysis

Confidentiality of Session Key

In our proposed scheme, when an authentication, secure communication or key update procedure is performed, a session key is generated using two random numbers chosen by the participants. Then, the generated key is used to ensure a secure communication. Moreover, the random numbers used to generate each session key are different. Therefore, it is difficult for an adversary A to successfully guess the session key or derived it from the communicated messages.

Anonymity

In our proposed scheme, to preserve users’ privacy, the original identity of every participant is converted into an alias via an XOR operation with a hash that takes a random number as an input (i.e., , ). Therefore, an adversary A cannot determine a user’s original identity without the random number or the private key even if T has been obtained because of the hardness of the ECCDH problem in G.

Unlinkability

In our proposed scheme, the original identities of the participants are not transmitted over the unsecure network; instead, every participant’s identity is converted into an alias. Moreover, the authentication, secure communication and key update phases are independent of each other. In addition, after every authentication procedure performed by , the value updates itself. Therefore, for two or more authentication messages that are sent by the same user, the adversary A cannot determine whether they have the same origin. Thus, A cannot trace the location of a user by intercepting messages.

Resistance to Impersonation Attack

In the authentication procedure of our improved scheme, if an adversary wishes to impersonate , it must obtain both the and of . Otherwise, it cannot compute a valid authentication request, since the original identity of is converted into an alias via an XOR operation with a random number chosen by itself and this random number is hidden by its . Moreover, the adversary can successfully impersonates only by correctly guessing the random number, which is difficult because the random number is reselected with each authentication. Furthermore, in the secure communication procedure, the original identity of is also converted into an alias with a random number (). The adversary cannot successfully impersonate the OBU since the random number cannot be guessed.

Resistance to Internal Attack

In our proposed scheme, an internal attack refers to the case in which the owner of a vehicle, who possesses the common secure key , attempts to reveal the session key for a communication channel. Under our improved scheme, in the secure communication procedure, even if the adversary can intercept all exchanged messages, , of and , of and compute T and R using the secure key , it cannot determine the user’s original identity or compute the session key k under the assumption of the hardness of problem in G.

6.3. Performance Analysis

In our proposed scheme, the general authentication procedure is based only on an XOR operation and a hash function; thus, the computation cost is low. To demonstrate the performance of the proposed scheme, we compare the the critical secure communication procedure with the existing two-party secure communication schemes with session key agreement [6,11,12,15,16]. Next, we implement our scheme based on cryptographic libraries and present a concrete comparison of execution times. Then, we compare the security features of these schemes. Some notations are defined as follows for convenience:

T : The execution time of a hash function operation.

T : The execution time of a bilinear pairing operation.

T : The execution time of an ECC-based scalar point multiplication operation.

T : The execution time of an ECC-based scalar point addition operation.

The detailed comparison is presented in Table 4, where the middle and right columns list the complexity and total execution time, respectively, of each scheme. The transmission time is not considered in the comparison since it depends on the actual characteristics of the network, not the scheme. All operations listed in Table 4 were implemented using the OpenSSL library and the JPBC library, and the experiments were conducted on a Windows 7 PC (Samsung Electronics, Hwaseong, Korea) equipped with an Intel(R) Core(TM) i7-6500U CPU (Santa Clara, CA, USA).

Table 4

The execution time of basic operation.

Operation	T_h	T_mul	T_bp	T_add
Execution time (ms)	0.004	0.326	6.28	0.038

As seen in Table 5 and Figure 6, the execution time of our scheme is less than those of some other schemes [11,12]. Although the execution times of Chuang–Lee’s scheme and Kumari’s scheme are less than that of our scheme, their schemes fail to resist internal attack because the participants’aliases depend only on a random number that is hidden by as shown in Table 6. Therefore, a trusted vehicle can reveal a participant’s real identity because it holds . Meanwhile, because Porambage’s scheme uses certificates for authentication, the unlinkability of messages cannot be preserved, and a user’s anonymity can be violated. Therefore, our proposed scheme is a preferable solution for secure communication in vehicle sensor networks compared with the existing similar schemes presented in [6,11,12,15,16].

Table 5

Comparison of efficiency.

Scheme	Computation Cost	Computation Time (ms)
Reference [6]	4T_h+4T_mul+2T_add	≈1.838
Reference [11]	10T_h+6T_mul+2T_bp+4T_add	≈14.7
Reference [12]	10T_h+6T_mul+2T_bp+4T_add	≈14.7
Reference [15]	8T_h	≈0.032
Reference [16]	10T_h	≈0.04
Proposed	12T_h+10T_mul+6T_add	≈3.54

Figure 6

Execution time(ms) of different authentication protocols.

Table 6

Comparison of security features.

Security Threats and Scheme	Ref. [6]	Ref. [11]	Ref. [12]	Ref. [15]	Ref. [16]	Proposed
Provides user anonymity	×	×	×	×	×	√
Resistance to user traceability attack	×	×	×	×	×	√
Resistance to impersonation attack	√	×	√	√	√	√
Resist inside attack	√	√	√	×	×	√
Unlinkability of message	×	√	√	×	√	√

7. Conclusions

With the emergence of intelligent transportation, the security of vehicle sensor networks is attracting attention from individuals and vehicle manufacturers, and privacy preservation in communication over vehicle sensor networks has become a critical issue. In this paper, we have demonstrated that Chuang and Lee’s TEAM scheme exists the linkability of messages in the authentication protocol; thus, a malicious vehicle can track a driver by intercepting transmitted message. Simultaneously, TEAM scheme can suffer the internal attack in the secure communication protocol; thus, a malicious trusted vehicle can compute the real identity of a user and the session key. To address this shortcoming, an improved authentication scheme based on elliptic curves for better performance and security has been constructed, in which the difficulty of deriving real identities arises from the need to solve an elliptic curve discrete logarithm problem. In this way, privacy preservation is achieved since the real identities of users are protected. The correctness of our proposed scheme has been proven using BAN logic, and a rigorous security proof has been provided based on the random oracle model. In future work, elliptic curves based authentication schemes involving three parities will be investigated.