ON-THE-FLY KEY GENERATION FOR AN EFFICIENT ROAD SIDE UNITS BASED AUTHENTICATION IN VEHICULAR NETWORKS

Obtaining efficient security without compromising privacy is a primary issue in vehicular communication. Though many counterparts proposed solutions in this regard, accommodating scalability, security and traceability altogether is a difficult task due to the contradictions between these qualities. Some of the previous studies suggests RSU based authentication to address the above issues, while others propose independent OBU authentication. In either scheme, any one of the entities is overloaded during key generation and verification processes. The proposed scheme addresses these issues, by distributing the workload between OBUs and RSUs to outperform other protocols. We propose a novel scheme, in which OBUs generate short-lived public keys on the fly and other vehicles can verify them with the help of RSUs. This protocol also admits certificate-less authentication, in addition to aggregated signature verification. Therefore, the total verification time can be drastically reduced in the proposed scheme. We analyze the proposed protocol significantly to demonstrate its efficiency.


INTRODUCTION
Vehicular Networks (VANETSs) are established to enhance road safety, traffic management and infotainment facilities. In VANET, each vehicle is equipped with an On Board Units (OBUs) to communicate with other vehicles, Road Side Units (RSUs) that are located on the roads and the Trusted Authority (TA) to register RSUs and OBUs. According to (USDT, 2006) OBUs frequently broadcasts routine traffic related messages with information about its position, current time, direction, speed, acceleration/deceleration, traffic events. This helps the vehicle to be warned with critical situations such as accidents, traffic jams.
Though this communication helps the driver community, it has a critical side effect of privacy. Some studies (Raya and Hubaux, 2005;2007) proposed pseudonym based approach to solve this problem. Generation of pseudonyms by the TA or RSUs is not an issue with their high computation and storage capacity. However, the computation cost of OBUs grows linearly with the traffic density. Some studies suggests RSU based authentication to reduce the burden of vehicles, while others propose independent OBU authentication. Both the schemes suffer with scalability and message loss problems, as any one entity (OBU or RSU) is solely responsible for key generation and/or verification. The proposed scheme addresses these issues by allowing both OBUs and RSUs to contribute in authentication process.

RELATED WORKS
Many studies have been reported on the security and privacy-preservation issues for VANETs proposed by several authors (Raya and Hubaux, 2007;Lin et al., 2007;Zhang et al., 2008a;Ren et al., 2006;Lu et al., Science Publications JCS 2008). They can be grouped into three categories. First category is based on a huge number of pseudoanonymous key based (HAB) protocols proposed by several authors (Raya and Hubaux, 2007;Lin et al., 2008;Mak et al., 2005;Xu et al., 2007;Xi et al., 2007;. Though this is a straightforward solution, this method requires each OBU has to take large storage space to store a number of anonymous key pairs. The second category is based on Group Signature (GSB), which was first introduced by Chaum and VenHeyst (1991). This allows a group member to sign messages anonymously on behalf of the group. In case of a dispute, the group manager can reveal the identity of a signer. According to Xiong et al. (2010) although the group signature can achieve anonymity on conditional privacy preservation, the time for message verification grows linearly with the number of revoked vehicles. Lin et al. (2008) propose an efficient security protocol called GSIS. With this protocol, only a private key and group public key are stored in the vehicle and the messages are signed according to the group signature scheme without revealing any identity information to the public. However, the verification of group signature requires at least two pairing operations, which may not be scalable when the density of traffic is increased. Finally, Calandriello et al. (2007) proposed a hybrid approach by combining the pseudonym and the group signature schemes. However, this approach suffers with the same drawbacks.
The third category employs the RSUs to assist message authentication. Lu et al. (2008) proposed a protocol called ECPP, in which the RSU issues only an ephemeral certificate for valid vehicles at the time of authentication to eliminate the certificate requirement and the RL. In RAISE, Zhang et al. (2008a) employed RSUs to authenticating messages. Compared to the solutions previously mentioned, this scheme enables lower computation and communication overheads for each vehicle. Also, Zhang et al. (2008b) introduced IBV scheme, in which multiple signatures can be batch verified instead of one by one. Therefore, the signature verification speed improved significantly and alleviated the computational workload of the RSUs. By generating distinct pseudo identities and the corresponding private keys for signing each message with a tamper-proof device, privacy regarding user identity and location of the vehicles can be protected. However, this scheme requires additional hardware to be installed on OBUs to generate pseudo identities.
However, the verification process of most of the protocols solely depends either on OBUs or on RSUs, which leads to scalability issues when the traffic density goes high. In order to address this downside, we propose this scheme to employ both RSUs and OBUs to work together for the key generation and verification processes, in order to distribute the workload between the two. Thus, this scheme achieves a better performance comparatively to other counterparts even in a high traffic situation.

System Model
VANET architecture consists of three entities as in Fig. 1: (1) the Trusted Authority (TA), who is in-charge for the registration of RSUs and OBUs, (2) the RSUs at the roadside, that act upon the commands of TA and (3) the vehicles equipped with OBUs in order to communicate with other vehicles.

System Requirements
As any other VANET system, we assume that our system fulfills the following requirements: • Anonymous Authentication: From the message senders' perception, leaking their privacy information such as Real ID (RID) of the vehicle is unacceptable • Unlink ability and Traceability: Any recipient cannot link two or more messages sent by a vehicle to other vehicles. On the other hand, the authorities should be able to trace the sender of the message by mapping the message with the real identity of the sender in case of any liability investigation • Scalability and Low overhead: Any application of the vehicular networks must be scalable to a large network. The computation and communication overhead increases linearly with the number of vehicles in the network

Bilinear Pairing
Since bilinear maps are the basis of our scheme, we briefly introduce them here. Let G 1 , G 2 be the cyclic additive and multiplicative groups of same prime order q. Let P be the generator of G 1 . An admissible bilinear map is a map ê: G 1 ×G 1 → G 2 satisfying the following properties: • Bilinearity: ∀ a, b∈G 1 and ∀a, b∈Z q , ê(g a , h b ) = ê(g, h) ab   (Sweeney, 2002) Such bilinear map êcan be constructed by modified Weil (Boneh and Franklin, 2001) or Tate paring (Miyaji et al., 2001) on elliptic curves.

System Initialization
All the OBUs and RSUs must register themselves with the TA before they join in the VANET. The TA is in-charge of checking the vehicle's identity and to provide a long-term public/private key pair for each vehicle and to set up the system parameters {G 1 , G 2 , q, P} for RSUs and OBU. Rests of the notations are listed in Table 1.

Short-Lived Key Pair Generation
Firstly, RSU (hereafter we say R) randomly chooses s ∈Z q as a common secret between the vehicles in its range and computes Q = sP. Also, RSU is responsible to choose a distinct Pseudo-ID (PID) for each vehicle when it comes into its communication range. The detailed working of our protocol is as follows.
At regular intervals, R broadcasts hello messages. When V x enters into R's proximity, it detects the hello message. Immediately, V x sends its Cert TA x v [PK ] , signed by TA and a random number r1∈Zq to R, to initiate the mutual authentication process. After authenticating x V PK , from Cert TA [ x v PK ], R chooses r2 as its share to establish a shared session key between V x and itself. This process can be achieved through Diffie and Hellman (1976) key agreement protocol. Besides, R chooses a unique PID for V x and sends {r2||{ x v PK ||T exp ||s||Q||r2}E Kss }, where E Kss is encryption using K ss .

JCS
With this x v PID , V x can now generate anonymous short-lived key pairs on the fly in order to send traffic related messages to other vehicles. In our scheme, OBU's generate these key pairs (U and v respectively) randomly from the given Pseudo-IDs (PID), based on ID based cryptography (Sha et al., 2006). Each U is composed of U 1 and U 2 . This U 1 and U 2 are the cipher texts of Elgamal (1985) encryption algorithm. Similarly, each private key v consists of v 1 and v 2. Generation of these keys pairs can be detailed in algorithm 1.

Algorithm 1: On-the-fly generation of shortlived public/private keys by the OBUs
Input: x v PID obtained from RSU Output: Short-lived anonymous key pairs x v U and x v v i. Computes the short-lived public key x V U as: where, a is a random nonce, ⊕ is an XOR operation ii. Computes the corresponding public key vas: In order to generate unique key pairs, V x changes the random nonce each time it generates a short-lived public/private key.

Signature Generation
When a vehicle V x wants to send message M, it generates a short-lived key pair as in algorithm1. It then computes a signature ' x v σ ' on M using the short-lived σ } to other vehicles. For sending subsequent messages V x changes its short-lived key pairs by choosing a distinct random nonce 'a'.

Aggregated List of Pseudo-IDs Agree
Meanwhile, R periodically broadcasts an aggregated list of issued pseudo-id hashes h aggr = {h(PID 1 ), h(PID 2 ) …h(PID n )} to the vehicles in its communication range. This list eliminates the certificate overhead. For this purpose, R first hashes the PIDs that are not expired, aggregates them all and signs the aggregated PIDs using sk R and sends out the signed list h aggr ||(h aggr ) sk R . Each time R issues a Pseudo-ID (PID) to a new vehicle, it appends the new PID in its aggregated list. Similarly, when a PID reaches T exp , it will be cut off from the list. In case a vehicle remains in same R even after the T exp of its PID, it can continue participating in the communication by requesting a new PID from R using K ss .

Aggregated Hash Verification
When a vehicle receives messages sent by the other vehicles, the receiver verifies the authenticity of the short-lived public keys from the aggregated pseudo-id hashes published by the RSU's periodically. For this ground, the receiver first computes the pseudo-id hash After extorting the pseudo-id hash ( )

Batch Signature Verification
Once the receiver confirms the genuineness of the pseudo-ids of all received messages through the aggregated list of pseudo-id hashes, it undergoes verification of signatures for the corresponding short-lived public keys. The authentication of a signature in a message can be carried out using the short-lived public key U of the sender attached in the message. With the system public parameters {G 1 , G 2 , q, P} assigned by the TA and the parameters {s, Q} obtained from RSU, the receiving vehicle verifies the signature of the sender V x as below Equation 2: Science Publications

JCS
Since we employ batch verification in our scheme, a receiver can collectively verify n distinct messages from n distinct vehicles once in every 300 ms. If the receiver receives σ 1 , σ 2 …σ n , the signature son the messages M 1 , M 2 …M n with their public keys U 1 ,U 2 ….U n then, those signatures are valid if the following Equation 3 holds:

Additional Storage Requirement
Considering the storage requirement, our protocol requires each OBU to store the aggregated list of pseudoid hashes published by the RSU periodically. However, this may require a small amount of storage capacity, as this list would not grow long, since the expired pseudo-id will be erased incessantly from the list by the RSU.

Claim 1: Privacy Preservation and Anonymous Authentication is Achieved Proof
The RSU can authenticate vehicle V x through its long-term public key x v PK , since it is signed by TA's private key. By this way, the real identity of the vehicle is preserved within TA. The short-lived public keys that are used for sending messages are generated from a pseudo-id given by the RSU, that has no trace of this long-term public key. Even if the RSU is hacked by any high level attacks, the real id of a vehicle cannot be revealed from the RSU. In terms of anonymous authentication, RSUs periodically broadcast the aggregated list of valid pseudo-ids signed by its private key sk R to the vehicles in its range. Therefore, a vehicle can trust a public key if its pseudo-id hash extracted from its public key is present in the aggregated pseudo-id hash of RSU. This shows that, claim 1 is correct.

Claim 2: The Anonymity of the Message Originator and Traceability by the Authorities is Assured Proof
The short-lived anonymous public key U is computed in such a way that U 1 = PIDaP, U 2 = h(PID)⊕H(PIDaQ) where, 'a' is a random number which would be changed by the vehicle for every different messages. This guarantees a unique short-lived public key each time. Moreover, the pseudo-id of a vehicle PID cannot be retrieved from its hash h(PID) because of the irreversible property of one-way hash chain. Therefore, a receiver cannot link any two short-lived public keys that are generated from the same PID. In case of any dispute, the RSU first fetch the pseudo-id hash in the accused message in order to find the real PID value of the message sender. Later, it extracts the long-term public key of the responsible vehicle and submits it to the TA for penalty. Therefore, claim 2 is correct.

Claim 3: Scalability and Low Verification Overhead is Guaranteed Proof
In the proposed protocol, a public key certificate is not required as the public keys can be authenticated form the list of aggregated pseudo-id hashes published by the RSU. Though this requires the RSU's signature in the list to be verified, it is one signature shared for n messages. Therefore, our protocol dramatically reduces verification overhead and improves the scalability of the system. This confirms that claim 3 is correct.

Verification Delay
We evaluated and compared our protocol with the following schemes. ECDSA proposed by  BLS proposed by Boneh et al. (2003) and GSIS proposed by Choi et al. (2011). Here, ECDSA is the traditional PKI based scheme, BLS and GSIS are group based, group and identity based signature schemes respectively. Considering the time to perform one pairing operation T pair , one point multiplication over elliptic curve cryptography T mul ; we used the experiment of Scott (2007) with an MNT curve of embedding degree k = 6 and 160 bit q simulated on an Intel Core 2 Duo @ 3 GHz machine and attained the values for T pair = 4.5 and T mul = 0.6 ms.
As depicted in Table 2, we calculated the time to sign and verify a single message and n messages. ECDSA uses one T mul operations to sign and 4 times T mul operations to verify a single message. During message verification, for n messages, it requires n times operations as that of single message verification. BLS uses one T mtp one T pair per signing and 4 times pairing and 2 times point multiplication operations to verify a single message. While on the other hand, for verifying n messages, it requires (2n+2)T pair +2nT mtp operations. This is because BLS performs aggregated verification. GSIS is closer to BLS but does not use T mtp operation. Rather, 3T pair +9T mul is required during signing a single message and two additional pairing and one reduced multiplication operations are needed for verifying a single message.

JCS Table 2. Comparison of signing and verification speed
Signing 1 message n messages 1 message n messages ECDSA T mul n T mul 4T mul 4nT mul BLS T mul + T mtp n T mul + n T mtp 4T pair + 2T mtp (2n + 2)T pair + 2n T mtp GSIS 3T pair +9T mul 3nT pair +9nT mul 5T pair + 8T mul 5nT pair + 8n T mul Our Protocol T mul n T mul 4T pair + T mul + T mtp 4T pair + n T mul +n T mtp For n messages, signing and verification in GSIS requires an equivalent of n times operations with its single message signing and verification time respectively. Our protocol requires similar time as that of ECDSA in signing messages. For verification, our protocol requires 4T pair , in addition to one T mul and one T mtp operations. This is because, in the total 4T pair operations, 2T pair remains the same for batch verifying n signatures and another 2T pair is for the verification of the ECDSA signature of the RSU that comes along with the list of aggregated pseudo-id hashes, which is one for n messages. Figure 2 illustrates the message verification delay of the various schemes ECDSA, GSIS and BLS compared with our protocol. The verification delay of GSIS and BLS is higher, when compared to the verification time of ECDSA and our protocol. GSIS starts losing the messages, when the number of messages increases over 10 within 300ms. BLS takes a similar time, as GSIS when number of messages are 50 to verify. ECDSA verifies around 125 messages in 300ms. Our protocol verifies closely twice the messages as verified by ECDSA within the same 300ms time interval.

Communication Overhead
To measure the communication overhead of our protocol, we evaluated our protocol using ns-2 the network simulator, simulation with the parameters shown in Table 3.
Our protocol is compared with the ECDSA, BLS and GSIS for the communication overhead occurred due to the cryptographic operations used in the schemes. ECDSA, BLS and GSIS schemes use a certificate of 125 bytes along with their signature costs. 181, 146 and 184 are the additional communication overhead for the above schemes respectively. Since our protocol uses a certificate less communication, it requires an additional overhead of only 42+21+(56/n)bytes, in which 42 bytes are for the short-lived public key and 21 bytes is for its corresponding signature. An additional overhead of 56 bytes is required for the RSU's ECDSA signature in the list of pseudo-id hashes that are periodically by the RSU. However, these 56 bytes would be shared for n messages, as the RSU aggregates all the pseudo-id hashes into one list. Therefore, a total of 63+(56/n) bytes are required as the overall communication overhead in our scheme. Figure 3 explains the communication overhead all protocols when the vehicle density increases. The simulation time is 1 min; with the vehicles range proposed up to 300 and the communication overhead is measured in megabytes. We also assumed that, RSUs broadcasts the list of aggregated pseudo-id hashes periodically with a time interval of 10ms and vehicles with the interval of 300ms. ECDSA and GSIS occupy a similar overhead and bounce 10 MB when the number of vehicles is more than 275.
Communication overhead of BLS is slightly less than ECDSA and GSIS schemes and consumes slightly over 8 MB, when 300 vehicles in range. Our protocol requires less than the half of the overhead of BLS when the communication is between 300 vehicles and a RSU.

Message Loss Ratio
We evaluated the message loss ratio of our protocol using ns-2 with the parameters shown in Table 3 and compared it with the other studied protocols. The average message loss ratio is defined as the average ratio between the number of messages dropped every 300 ms due to cryptographic delays and the total number of messages received in every 300 ms. This can be calculated from the maximum number of signatures and certificates that can be verified by a protocol in 300 ms. The ECDSA, BLS, GSIS and our protocol verify a maximum of 125, 17, 10 and 234 messages respectively. Figure 4 shows the average message loss ratio between the compared schemes with our protocol. We observe that our protocol has the lowest message loss ratio when compared to the other schemes. Since we deploy the batch verification and avoided the certificate verification, our protocol is able to verify more messages than the other compared counterparts.

CONCLUSION
In this study, we propose a novel RSU based on-thefly anonymous short-lived public key generation. With our protocol, RSUs are responsible to provide a pseudoidentity to the OBUs, which come into its proximity. The OBUs can generate on-the-fly short-lived public keys using the pseudo-id. This protocol considerably reduces the verification overhead, as it does not require any public key certificate for the authentication of the shortlive public keys. This is because; the RSUs periodically publish the valid pseudo-id hashes, which would be used by the vehicles to compare the pseudo-id hashes of the received messages for its trustworthiness. Extensive simulation has been conducted to demonstrate the low overhead and high performance our protocol.
For future research, we will contribute to reduce the signature verification cost for vehicle-to-vehicle communication when the fixed infrastructure such as RSUs is absent in the network.