Secure V2V Communication in IOV using IBE and PKI based Hybrid Approach

We live in the world of “Internet of Everything”, which lead to advent of different applications and Internet of vehicles (IOV) of one among them, which is a major step forward for the future of transportation system. Vehicle to vehicle (V2V) communication plays a major role in which a vehicle may send sensitive, non-sensitive messages and these messages are encrypted with public keys, which makes distribution of public keys is a major problem due to the vehicle need to be anonymous having pseudonyms which changes more frequently and makes it more complicated. Here we proposed a hybrid approach, which uses existing Public key certificate for authorization of the vehicle and Identity Based Encryption to generate public keys from the pseudonyms and use it in secure V2V communication without compromising anonymity of the vehicle. Keywords—Privacy; internet of vehicles; hashing; IBE; public key certificate


I. INTRODUCTION
Due to advent of wireless communication and internet there are many things that are connected and communicate with each other with out the intervision of human and many applications are derived in which Internet of vehicles (IOV) stands tall as its is big thing which enables autonomous driving which changes the future of transportation [1] [3].
IOV [17] [18] is derived from age old VANETS in which the vehicles and its infrastructure are interconnected using internet technologies like 4G and 5G, but the most of the arcitecture remains the same as the treditional VANETs, which inherets some of the challenges like security and privicy of the vehicle and comminication as well.
Thre are different types of communication players Like Vehicle, RSU, CA etc and they can enable different types of communication like V2V, V2R etc and can also extand as V2X which enables the communication between the vehicle and pedestrian, smart objects etc. out of which V2V communication playes amajor role through the vehicle exchanges different types of messages like safety and non safety messages [15]. V2V communication playes amajor role in the whole IOV communication, through the vehicle exchanges different types of messages like safety and non safety messages, when it comes to sefity messages time is very critical and for non safety message time may not be critical [21].
V2V messages should be secured and yet not compramising the privicy of the vehicle, as vehicles uses masking identites called Pseudonyms. A vehicle communicates 100's of messages every ms and they are different forms of attacks an attacker may plan like attacks [10] on privacy compromising the location and the real identity of the vehicle of the vehicle, attacks on integrity of the message in which the attacker may modify the message, eavesdropping through which the attacker tries to read the communication, different solutions are been proposed to combat security problems in V2V communication, which are broadly classified in to three types. a) Hardware based solutions in which the attacks are identified at the physical level [25][26] by utilizing channelization and using provability distribution functions in which these solutions only work with the attacks on physical layer and completely ignore the attacks on higher layers b) IBE based solutions in which different solutions utilizes a trusted authority [8] [9], which distributes the keys to the vehicles and some of the solutions utilizes certificates and some may not very time the trusted authority [16] must act as a middle man which incurs delay and bottle neck in the network. Some completely ignore the usage of pseudonyms, which compromises the privacy of vehicle.
c) The other solutions are based on trust-based mechanisms [22][23] [24], in which every vehicle is associated with a trust value and may vary depending on vehicle behavior [19] and there also exist a trusted third party (TTP) or mutual group trust management, which evaluates and isolates the attacker depending on its trust value [27]. These solutions may not work all the time as the attacker may act normal to improve its trust value and the TTP may compromise.
In this paper we address the problem using a hybrid mechanism which utilizes the existing public key certificate and Identity Based Encryption (IBE) by which the vehicle can use pseudonyms and hide its identity and yet traceable by the Transport Authorities which can revoke the certificate in case of suspicious vehicle [28]. www.ijacsa.thesai.org The rest of the paper organized as follows; in Section II we briefly discuss the existing approaches along with its drawbacks, in Section III we have presented the System Architecture we followed, in Section IV we thoroughly discussed our hybrid approach and also we presented the proof of work for IBE, in Section V we presented the threat model with the adversary and its different forms of attacks, in Section VI shows our simulation results, in Section VII presents conclusion and future work.

II. RELATED WORK
Works related to physical layer security focus on physical aspects. Hanet al. [1],based on securing sub carrier allocation where the eavesdropper may intercept the communication, so the sub carrier allocation, joint rally selection is done by using the provability calculated by forming RGB, Random by parity Graph which given a good results as the work is based on physical layer security, where most of the attacks are undertaken on higher layers. Jinyuan Sun et al. [20] Based on IBE which uses threshold based secret sharing and using pseudonyms for preserving privacy here RTA acts as middle man which generates the keys and it is susceptible to sing point of failure which make the whole system prone to DOS attack.
Liu, Yanbing et al. [3] have proposed an authentication and key agreement scheme for safeguarding V2V communication which involves third party Trusted authority in the communication which incurs delay as every time TA is also a part of authentication.
Debiao He et al. [4] proposed a scheme based on IBE which does not use Bilinear pairings, called CCPA conditional Privacy Preserving Authentication scheme which is better proved to reduce the computational cost which again shows the trusted authority plays a key role which ultimately be a single point of failure and the communication is made through internet which can be a bottle neck in the communication.
Song, Jun et al. [5] have proposed a IBE scheme, which is light weight and doesn't use certificates for authentication and RTA generates the master key and it also manages the communication without RSU, without public key certificates after fraud detection revocation is an issue.
T.W. Chim et al. [6] have proposed a privacy preservation schemes for unicast and group communication in which RSU stands as a middle man, which verifies the signatures which shows the reduction of message overhead, but it incurs load on RSU, and it may prone to Sybil attack.
Lee et al. [7] have proposed a batch message verification scheme based on bilinear pairing, message singing and verification process, is a bit complicated which incurs overhead in communication.

III. SYSTEM ARCHITECTURE
IOV has no standardized architecture defined, different types of architecture's proposed cloud based, fog and cloud hybrid architecture and these derived from basic VANET architecture.
Here we follow very basic IOV architecture shown in Fig.  1, which consists of vehicles V, equipped with Dedicated Short range communication DSRC [11]boards, these boards are fixed as a Tamper proof Device TPD [12], and these are called on board units OBU. DSRC is the modified form of standardWi-Fi called 802.11p [29], which uses 5.9 GHz band and the layers of 1609, which together called WAVE.
Roads, parking lots and other places in which a car can move are covered by Road Side Units (RSU), generally these are equipped with high computational power processors and wired and wireless technologies [30] like 4G, 5G, WAVE etc. RSUs are aligned in such a way that they are in a line of site to one another,for local and global handover management, and they are interconnected with RSU controller RSUC which acts as switching station and it also moves the data from TA and CA back and fourth.
As shown in Fig. 1 Transport Authority TA is the root of the system, which registers the vehicles soon after it is been purchased from the show room and it creates an entry in its database, which contains all the vehicle information, as well as driver information and other license data. Certification Authority CA Creates a Public key certificate for every vehicle after registration with TA, which contains public key information [31] along with the expiry and this information, can be accessible to RAUs as well and CA has a database CRL certificate revocation list [32] which can be used by RSU to send revocation request for vehicles found to be attackers [33].

IV. PROPOSED IBE-PKI BASED HYBRID APPROACH
The proposed system is based on bilinear maps on abelian groups based on [2] [21], which maps the elements from two Additive groups G1, G2 to a target group GT, here we follow a hybrid approach rather than pure IBE in which every vehicle should process the public key certificate issued by CA and on the top of it uses IBE to avoid the delay caused by certificate verification every time. The terminologies used in the manuscript are represented in Table I. www.ijacsa.thesai.org The proposed method can be viewed in five stages: i) Vehicle registration with Certification Authority is, ii) RSU Setup, iii) Vehicle registration with RSU, iv) Encryption by vehicle V2, v) Decryption by Vehicle V1 and some of these steps are carried only once in the communication scenario.

1) Vehicle registration with certification authority:
Vehicle V soon after its onboard unit (OBU) is configured, public, private key pairs PUV, PRV are generated and sent along with its vehicle details, and unique identifier to Certification Authority (CA) for its public key certificate, CA verifies the details as shown in Fig. 2, store them to its database and issues the vehicle with its public key certificate CV. This step is carried only once in the vehicles lifetime unless the hardware gets changed or the Certificate is expired.
2) RSU setup: RSU are assumed to be with in the line of sight to one another and every time a vehicle moves from one RSU to another RSU, every RSU configures itself and generates master secret on hourly or daily basis. 3) Vehicle registration with RSU: Vehicle holds the public key certificate, as it should not disclose its identity to the other vehicles it should not publically announce its certificate instead it gains pseudonyms by showing certificate to RSU as shown in Fig. 3. These pseudonyms can be changed when required or following pattern or randomly making the vehicle anonymous. a) Vehicle V1 when it enters new RSU region, sends its public key certificate to RSU, RSU verifies the certificate and its period of validity and issues a set of pseudonyms (Pid1, Pid2, …Pidn)V1 which can be utilized for communication.
b) Vehicle V1 when it intends to change its pseudonym, it sends its new Pid to RSU, RSU generates secret key SKid by applying H1 as follows and its master secret key α. SKid = (H1(Pid)) α  The above step maps the pseudonym which is string of [0,1] l to element in G α 4) Encryption by vehicle V2: When a vehicle tries to send a message may be Basic safety or emergency Broad Cast messages some of the messages needs encryption in certain cases and these messages must be confidential and as well as the system must preserve integrity so encryption is the only means.
a) If a vehicle V2 wants to send a confidential message to vehicle V1, V2 prepares the message Mv2 which is also a string of [0,1] l .

V. THREAT MODEL
Here we assume a Adversary which is planted at every RSU and it is having all the computation and communication technology, which also act as any other vehicle but the main job is to intercept the traffic, modify the messages, track the vehicles to map the original identities. a) Attacks on confidentiality: When vehicle V2 wants to send a message M to V1, it encrypts the message and sends CTV2 = [C1 || C2] to V1 and the adversary VA tries to decrypt the message and to extract r out of C1 is a complex and computing SKid from the known Pid is a discrete logarithmic problem which VA is incapable of computing.
b) Attacks on integrity: Vehicle V2 sends cipher text in the form [C1 || C2] to V1 and before it reaches V1, Adversary VA captures the message and tries to modify the message by preparing Mv2 and prepare C2^= Mv2⊕ H2(e(H1(Pid), Q) r ) by choosing a random r^ and precomputing C1^ = g r^a nd sends [C1^|| C2^] to V1,. V1 computes Mv2^= C2^⊕ H2(e(SKid, C1^)) Decryption was a success and V1takes the message as granted, to overcome this problem V2 must also concatenate an encrypted hash along with the cipher text.

CTV2 = [C1 || C2 || EH(MV2)]
EH(MV2) is the encrypted hash of MV2 with Pid of V1 so that only V1 can decrypt the hash and can check for integrity. As VA can only tamper Message but not hash integrity of the message is preserved. c) Attacks on anonymity: Anonymity should be preserved in IOV as the adversary can track the vehicle and understand its driving pattern, behavioral patterns, and may employee some physical attacks like kidnap, Murder, extortion, etc. For the adversary VA to get the real identity of the vehicle Vid it must get the certificate CV1 knowing Pid, only RSU is having the data associated with CV1 and we assume RSU to be a tamper proof device. It is impossible to the adversary.
As the pseudonyms keeps changing very time and the vehicle acquires new pseudonyms under new RSU and it is computationally infeasible to track the original identity of the vehicle from Pseudonyms.

A. Simulation Setup
For Simulation we make use of of a highway Junction road map at Guntur using open street map (OSM) and imported the map to SUMO [13] traffic simulator. We have created traffic nodes and other boundaries using polyconvert and netconvert commands contained in the SUMO 0.25.0, we have used randomTrips.py to create random trips for the vehicles with different intervals with variable arrival rates say www.ijacsa.thesai.org 1, 1.2, 2, 2.5 vehicles every second each vehicle arrive into the map and depart at variable rates and we setup the speed range to a max of 60 kmph.
For network simulation, we use OMNET++ 5 [14], having Venius Package, which enables the network simulation for SUMO traffic having RSU and the nodes enabled with DSRC stacks, and we have created different communication scenarios with incremental number of vehicles and variable no of attackers, the attackers as discussed in the threat model have the same capabilities as the Vehicle node. These attackers are intentionally implanted in to the network at different points, and have two basic functionalities. Some of them defined to be in the radio coverage of a vehicle and listen to the traffic between RSU and Vehicle node, store the pseudonyms and try to track the vehicle even pseudonym keeps changing and the other are defined to eavesdropping the communication between the vehicles and try to decrypt the messages.

B. Performance Evaluation
Here we consider three scenarios in which we evaluate the performance of the system one is the 'idle-IOV' which evaluates the idle condition with no attackers and no security mechanism implemented, one called 'attack-IOV' in which we implant attackers and with no security mechanism implemented and the other is our proposed IBE-PKI based Hybrid approach called 'IPH-IOV', in which we implement our defense mechanism along with the attackers implanted.

C. Computational Overhead
It is the extra work done by the CPU to execute the whole scenario and it is calculated by summing up the CPU cycles consumed by all the nodes in the network.
Here on the x-axis, we plot the No. of vehicles varies from 0 to 250 and on Y-axis we took computational overhead % varies from 0 to 1 and Fig. 4 shows computational overhead in Idle-IOV is very low as there is no much additional computation done by the vehicles or by the system, In our proposed IBE-PKI the computational overhead is initially not much high but as the number of vehicles increases in the system, the number of computations also increases due to the key computations and exchanges in the system and the Attack-IOV is between Idle-IOV and IBE-PKI as the computation is not much needed and the attackers computation makes it deviated from the Idle-IOV.

D. End to End Delay
It is the total delay imposed on the packet from sender to the receiver and End-to-End delay is given as follows.
End to End Delay = Σ (packet arrival time -Packet send time) / Σ (No. of connections).
On x-axis, we plot the simulation time that varies from 10 to 50 sec and on y-axis, we plot End to End Delay in mille seconds, varying from 0 to 700 ms. Fig. 5 shows End to End delay of the Idle-IOV is very low compared to other two as there are no attackers in the system no packets are delayed and it increases with simulation time, on the other hand Attack-IOV have high End to End delay in the system due to the attackers delay or drop the packets.
Our IBE-PKI have shown some delay compared to Idle-IOV due to key generation, encryption and decryption, it lies very close to Idle-IOV and it gave a good result compared to Attack-IOV which is much higher.

E. Packet Delivery Ratio
It is the ratio of the packets sent and received Packet Delivery ratio = Σ No. of packets send / Σ No. of packets received On x-axis, we plot the No. of vehicles that varies from 40 to 200 and on y-axis we plot End to End Delay % that varies from 0 to 2. Fig. 6 shows Packet Delivery Ratio of the Idle-IOV is very high compared to other two as there are no attackers in the system no packets are delayed or dropped and it increases with the increase in number of vehicles, on the other hand Attack-IOV have low Packet Delivery Ratio in the system due to the attackers delay or drop the packets which ultimately decreases Packet Delivery Ratio.  Idle IOV Attack IOV IBE+PKI www.ijacsa.thesai.org Our IBE-PKI have shown a very good result compared to Attack-IOV as it reduces the delay or drop of packets caused by the attackers and the results are very close to Idle-IOV.

F. Network Throughput
It is the sum of the packets delivered to the receivers successfully. Throughput is depicted in Fig. 7.

Throughput = Σ No. of packets received
On x-axis we plot the number of vehicle that varies from 40 to 200 and on y-axis, we plot Throughput in Megabits/ sec, varying from 0 to 1400 Mbps. Fig. 6 shows Network Throughput of the Idle-IOV is very high compared to other two as there are no attackers in the system no packets are delayed or dropped and it increases with the increase in number of vehicles, on the other hand Attack-IOV have low Network Throughput in the system due to the attackers delay or drop the packets which ultimately effects the Network Throughput value. Our IBE-PKI have shown a very good result compared to Attack-IOV as it reduces the delay or drop of packets caused by the attackers which increases the Network Throughput and the results are very close to Idle-IOV.

VII. CONCLUSION AND FUTURE WORK
Our Hybrid framework have safeguarded the system from the attackers yet not compromising the privacy of the vehicles and having significantly less computational delay and gave a good results compared to the other systems and the results obtained are close to the idle scenario. As a future work we try to still reduce the computational delay and also test the proposed mechanism in the real-world.