Sanjeev Kumar Dwivedi,Ruhul Amin,and Satyanarayana Vollala

Abstract—In recent decades,intelligent transportation systems(ITS) have improved drivers’ safety and have shared information(such as traffic congestion and accidents) in a very efficient way.However,the privacy of vehicles and the security of event information is a major concern.The problem of secure sharing of event information without compromising the trusted third party(TTP) and data storage is the main issue in ITS.Blockchain technologies can resolve this problem.A work has been published on blockchain-based protocol for secure sharing of events and authentication of vehicles.This protocol addresses the issue of the safe storing of event information.However,authentication of vehicles solely depends on the cloud server.As a result,their scheme utilizes the notion of partially decentralized architecture.This paper proposes a novel decentralized architecture for the vehicular ad-hoc network (VANET) without the cloud server.This work also presents a protocol for securing event information and vehicle authentication using the blockchain mechanism.In this protocol,the registered user accesses the event information securely from the interplanetary file system (IPFS).We incorporate the IPFS,along with blockchain,to store the information in a fully distributed manner.The proposed protocol is compared with the state-of-the-art.The comparison provides desirable security at a reasonable cost.The evaluation of the proposed smart contract in terms of cost (GAS) is also discussed.

I.INTRODUCTION

THE vision of Industry 4.0 is the digital transformation of industries based on innovative technologies such as cloud and cognitive computing,internet-of-things (IoT),blockchain,machine learning,etc.Industry 4.0 can provide more automation than the previous industrial revolution,and it bridges the gap between the physical and digital world.It helps to develop smart products and create a good ecosystem for them.Presently,various researchers and developers have put their efforts into developing intelligent systems.More smart devices evolve with the introduction of IoT devices,and these smart devices provide a foundation for the smart transportation system (STS).The security and safety of the drivers and efficiency of the transportation system are the main goals behind the STS.An intelligent vehicle equips with devices such as an on-board unit (OBU) and sensors that collect information and sends it to the nearby roadside units(RS Us) and cloud servers in this system.Traditionally,a transportation system employs a centralized architecture where a trusted third party such as a cloud server stores the required information.The single-point-of-failure (SPoF) and the trust issue are the two significant problems associated with this architecture.Moreover,the number of intelligent vehicles and users is increasing.As a result,the present system and the communication protocols cannot provide sufficient response to the system’s requirement [1].

Researchers utilize the distributed network architecture instead of a centralized architecture to provide trust and fairness in the system.Blockchain is a new distributed system,and Satoshi Nakamoto first implemented the underlying concept of blockchain in the famous bitcoin cryptocurrency[2].Blockchain technology combines the ledger and consensus concept with peer-to-peer networking and security properties.Its architecture generally consists of six layers starting from the data layer (block structure),the network layer (block and transaction propagation),the consensus layer(block agreement),the incentive layer (reward),the smart contracts layer (business logic),and the application layer(programmable applications) [3].In this respect,various researchers have attempted to utilize blockchain technology in multiple applications to address current issues.

Blockchain technology is combined with the existing vehicular ad-hoc network (VANET) protocols to solve the problems related to data sharing and vehicle authentication.In the present system,data is shared among the intelligent vehicles and RSUs over non-secure channels.As a result,there is a high probability that data may manipulate while sharing it with others.In its continuation,authors [4]presented a protocol for the secure sharing of event details among the RSU and vehicle authentication.They use the blockchain mechanism for secure storage of the event details.We found that their protocol uses a centralized mechanism(i.e.,cloud server) for vehicle authentication.In this paper,we improve their protocol without involving a trusted cloud server.The proposed solution uses the interplanetary file system (IPFS) and blockchain to store the event details and vehicle authentication.

A.Major Contributions

The main contributions of this work include the following points:

1) This paper presents the weaknesses of the published work on blockchain-based data sharing and authentication scheme[4]and proposes an improved protocol.

2) To provide a secure and reliable sharing of event information in the vehicular network,the decentralized authentication protocol is designed.

3) A long with the blockchain,the proposed mechanism also leveragesIPFSfor storing event information in a distributed manner.

4) This paper provides the data accessing policies for the user based on the Ethereum smart contract so that only the legitimate user can access the event details fromIPFS.

5) The consensus procedure for the common key is also presented in the paper.

6) Our security analysis confirms that the proposed protocol is free from relevant attacks such as sybil attack,man-in-themiddle attack,etc.,and achieves all the required security aspects.

7) The various overheads (computation,communication,and storage cost) incurred while proposing the protocol iscomputed,and compared with the state-of-the-art research.

B.Organization of the Papers

The rest of the paper is organized as follows: The literature review of this work is in Section II.In Section III,we describe the loopholes of the Dwivediet al.scheme and provide solutions for overcoming the loopholes.The proposed architecture,decentralized authentication procedure,the user accessing policy,and consensus for the common key are discussed in Section IV.Section V presents the major security requirements and informal analysis of the proposed protocol.The performance analysis and comparisons with the existing scheme are discussed in Section VI followed by concluding remarks and the future scope of the paper in Section VII.

II.RELATED WORKS

This section introduces existing research that utilizes the blockchain mechanism and its features (such as immutability,decentralization,etc.) to provide secure data sharing and improve the privacy and security in communication protocols.Zhanget al.[5]proposed a data-sharing framework on the top of blockchain to tackle the announcing messages in internetof-vehicles (IoV).Their validation is based on the proof-ofwork and further uses a punish-reward mechanism to incentivize the vehicles.Authors in [6]discussed the messagedissemination problem and proposed a blockchain-based solution for the same.Kanget al.[7]proposed a delegated proof-of-stake consensus mechanism and reputation-based algorithm for the selection of miners.They use the multiweight subjective logic model for the computation of the vehicle’s reputation.Yanget al.[8]presented a decentralized trust management scheme to achieve the vehicle’s credibility.The proof-of-work and proof-of-stake approach with the Bayesian inference mathematical model is used to validate the vehicle’s message.The vehicle’s identity and message reliability play a crucial role in exchanging messages with other vehicles and RSU in the IoV.To solve this,the authors proposed a consortium blockchain-based data sharing and storage system [9].

Further,the correctness and validation of traffic events is a tedious task in the current intelligent traffic management system.Yanget al.[10]presented the proof of event-based traffic event validation model.The events are collected by the RSU and submitted to the vehicles for validation purposes.To achieve trust,the authors proposed the authentication and entity-centric trust-building framework based on the blockchain [11].In this model,the selection of the miner node is based on the trust value.Kanget al.[12]proposed mobile edge computing and smart contract enabled blockchain to share the vehicular data.Furthermore,the three-weight subjective logic model is utilized for the vehicle’s reputation.Liet al.[13]presented the privacy-preserving incentive model for vehicles.Authors use the byzantine fault tolerance consensus mechanism,which requires both vehicle and RSU to agree on a block’s validity.Authors in [4]proposed the secure event information sharing protocol based on the blockchain for the vehicular network.Their protocol uses the cloud server for vehicle authentication and blockchain for storing the event information among all RSUs.Luet al.[14]proposed the directed acyclic graph and permissioned blockchain-based asynchronous federated learning system for safe data exchange in IoV.Furthermore,for the selection of nodes and their optimization,they employ a deep reinforcement learning technique.

Authors in [15]utilized the proof-of-work consensus and vehicle’s trust for solving the message dissemination problem in the VANET.Similarly,the reputation algorithm was used in [16]for solving the distribution of forged messages.Luet al.[17]utilized the proof-of-absence and proof-ofpresence-based consensus protocol for solving the trust issues in VANET.On the other hand,Zhenget al.[18]implemented the paillier cryptosystem for safe data exchange.Huanget al.[19]proposed a blockchain and smart contracts (Stackelberg game) enabled framework to achieve the parked vehicleassisted fog computing services in a decentralized manner.Table I shows the research gap and blockchain-specific challenge addressed by the existing solutions.

III.LOOPHOLES IN Dw IVEDI ET AL.’S SCHEME

This section describes the various drawbacks that areassociated with existing work blockchain-based data sharing and authentication scheme [4],which are listed below:

1) Partially Decentralized System:In the Dwivediet al.scheme,roadside unitRS Usubmits the vehicleVEHregistration details to the cloud serverCS,andCSmaintains the ledger,which stores the registration details forRS UandVEH.As a consequence,CSpossesses all of theRS UandVEHdetails,resulting in a partially decentralized network where all the sensitive information of the system is stored in a single place.

2) Single-Point-of-Failure (SPoF) Problem:The entire functioning of the Dwivediet al.scheme is dependent on the availability of the information provided by theCS.Ifsomehow,theCSis offline (or crashed),their system will not work.As a result,we infer that the SPoF issue still exists in their approach.

TABLE IRESEARCH GAP AND BLOCKCHAIN SPECIFIC CHALLENGE ADDRESSED IN THE EXISTING BLOCKCHAIN-BASED SCHEME FOR VANET

3) Centralized Authentication Mechanism:In the Dwivediet al.scheme,CSperforms authentication ofVEH.To accomplish this,VEHsends the event informationEmwith the necessary parameters (such as 〈IDVEH,IDRS U,Em〉) toRS U.RS Usecurely forwards these details to theCS.TheCSdoes the computation and informs the appropriateRS Uas to whether or not theVEHauthentication was successful.Hence,we conclude that they use a centralized authentication mechanism.

4) Storage Capability Constraint:In the Dwivediet al.scheme,they assume that theRS U shave enough storage space.Therefore,it can store the event-information (both data and hash) of any length,which is further based on the blockchain mechanism.

A.Solutions for Overcoming the Loopholes of Dwivedi et.al.’s Scheme

This section briefly discusses how the proposed methodology overcomes the loopholes of the Dwivediet al.scheme.Each point is discussed below:

1) Fully Decentralized System:The blockchain-based solution provided by Dwivediet al.utilizes a third party as a cloud serverCSwhich stores the crucial information ofVEHandRS U.We further improve their scheme and propose a new system that is completely free from theCS.In our approach,both theVEHand event information are stored in a decentralized manner.As a result,our plan offers a completely decentralized structure.

2) No SPoF Problem:Furthermore,the Dwivediet al.scheme suffers from the SPoF problem because essentialVEHinformation is available in a single place.Our method makes use of blockchain to storeVEHinformation in a fully decentralized manner.As a result,our system never has a SPoF problem.

3) Decentralized Authentication Mechanism:TheCSconductsVEHauthentication in the Dwivediet al.system.However,we suggest a novel method for disseminating VEH information across all of the system’s accessibleRS U.As a result,anyRS Umay use the blockchain to conductVEHauthentication.

4) No Storage Capability Constraint:To overcome the storage capability constraint of the Dwivediet al.scheme,our suggested protocol combinesIPFSwith a blockchain method to tackle theRS Ustorage problem.IPFSis a distributed file system that stores data across the globe.To further retrieve the data fromIPFS,we also give users access rules based on the smart contract.

IV.PROPOSED SYSTEM

A.System Overview

This section tries to improve existing blockchain-based data sharing and authentication scheme [4]without including the cloud server as a trusted third party (TTP).As shown in Fig 1,the proposed blockchain-enabled protocol consists of network administratorNA,roadside unitRS U,vehicleVEH,and blockchain network with theIPFS.A ll the notations that are used throughout the paper are illustrated in Table II.A brief description of the entities are given below.

Network Administrator〈NA〉:In the proposed protocol,NAperforms the registration ofRS U.Before deployingRS Uin the network,NAdoes the off-line registration and stores the common keyKin allRS U s.The keyKis used by theRS Uto exchange the hash that it receives fromIPFS.The key is valid only for the fixed duration ofT.After the timeThas passed,anyRS Umust execute the common key generation and consensus procedure and distribute the new keyK1to allRS Us.

Fig.1.Proposed architecture1No.1 indicates the vehicles and RS U registration performed by the RS Uand network administrator,respectively.No.2 indicates that the vehicle collects the event information using its sensing units and sends it to the nearest RS U for further processing.No.3 indicates RS Uvalidates the event information and executes the smart contracts for creating the new block.No.4 and No.5 indicate that verified event information is published on IPFS,and in return,IPFSprovides the hash of that event to RS U.No.6 indicates the user registration and authentication procedure.No.7 indicates that after the user’s successful authentication,RS Uprovides the hash of the event to the user.No.8 and No.9 indicate the user request for event details from IPFS,and in return,IPFSprovides the event detail to the user..

Roadside Unit〈RS U〉:RS Usperform the registration of vehicleVEH.In our considered model,RS Uis located in different places geographically,but the distance between twoRS U sis three or four kilometres.It is essential that oneVEHhas to register with oneRS U.After the successful registration ofVEH,RS Uselects a few registration parameters,creates a block 〈B1〉,and executes the block-validation procedure.Once block validation is successful,theRS Uhands over the index of block 〈B1〉(i.e.,IB1)toVEH.Now for further authentication ofVEH,itmust provideIB1along with the registration parameters.

Vehicle〈VEH〉:TheVEHhas anOBU,Wi-Fi,a global positioning system (GPS),etc.It has limited computational and storage capabilities and stores only a few sensitive parameters such as an identity ofRS U IDRS U,the identity ofVEH TIDVEH,A,B,etc.TheVEHgathersEmand forwardsit to the nearbyRS Ufor further processing.

TABLE IIDESCRIPTIONS OF VARIOUS NOTATIONS USED IN PROPOSED SCHEME

Blockchain and〈IPFS〉:The proposed work mainly focuses on decentralized authentication and distributed data storage(events) based onIPFSand blockchain.IPFSemploys the content addressable methodology that can resolve the issue of blockchain storage.The main idea behindIPFSis to store the encrypted data or files in decentralized nodes,and on behalf of this,IPFSprovides the hash of encrypted data as a service.The encrypted data fromIPFSis retrieved using this hash.

Smart Contracts:Unlike traditional contracts,smart contracts are computerized programs,which execute automatically once the conditions of the contracts among the peers (nodes) are satisfied.It operates on a decentralized platform such as an Ethereum-based blockchain network.As a result,a third party does not require to execute the transactions (or assets) and their validation.Smart contracts are immutable and cryptographically secure.Our proposed methodology utilizes the Ethereum-enabled smart contracts to securely store the event details in theIPFSand retrieve event details fromIPFSvia theRS U(see A lgorithm 1).By doing so,the immutable event details are present in theIPFS.Therefore,in the future,if any authentic user wants to access event details from blockchain-enabledIPFSservers,they can access it once the smart contract conditions are satisfied.

Algorithm 1 Smart Contract Algorithm for Accessing Emfrom IPFSThrough RS Ua

Our proposed scheme is divided into several phases,beginning with the registration phase in which vehicle andRS Uregistration are done by theRS UandNA,respectively.The event collectionEmandVEH’sauthentication is the second phase in which theRS UperformsVEH’sauthentication using the blockchain.A detailed description of all the phases provided in the Sections IV-B–IV-E.

B.Registration Phase

1) Roadside Unit(RS U)Registration

2) Vehicle(VEH)Registration

The following steps are executed by theVEH.

C.Transaction-Generation (Event Detection) Phase

During this phase,one of the vehicleVEHcollects the critical events (e.g.,accident on the road,traffic congestion,etc.) through its OBU and Wi-Fi units,and sends it (along withTIDVEHb,IDRS Ua) to the nearestRS U.ThatRS Uchecks the integrity of the event and confirms the necessary action accordingly.We consider that the eventEmis collected by theVEHb,and it forwardsEmto theRS Ua.

D.Block Creation Phase

In this phase,RS Uacreates blocks 〈B1,B2〉,which are based on the proof-of-work consensus mechanism2Proof-of-work is the mechanism that provides the consensus (common agreement) among the decentralized network nodes.Its principle is based on a solution (the current hash of a block) that is difficult to find,but at the same time,verification is easy for that solution.Here,the nodes of the decentralized network are continuously engaged in finding a nonce value which,when hashed with the previous block hash with necessary parameters,produces a resultant lesser than the predefined threshold..The parameters〈AVEHb,IDRS Ua,CVEHb,RVEHb〉 are used for the computation of merkle rootrootmerofB1,and forB2,parameters〈TIDVEHb,Em〉 are used.Therootmeris stored in the block header for the computation of current block hashhashcuras shown in

where for blockB1,(rootmer) is computed as

and for blockB2,(rootmer)is computed as

3H1is a hash value,which is computed by hashing pairs ofAVEHband IDRSUa.

4H2is a hash value,which is computed by hashing pairs ofCVEHbandRRSUa.

5H3is a hash value,which is computed by hashing ofTIDVEHb.

6H4is a hash value,which is computedby hashing of Em,where ash(·)is one wa y hash function (e.g.,SHA-2 5 6).

hashpre= Hash of previous block

Initially,Nis set to zero,and at each iteration,it is incremented by one.The block values (hashpre),(rootmer),and (TSi) are repeatedly hashed with different values ofNfor the computation of current hash index (hashcur).A fter the block creation is successful,RS Uahands over the index of blockB1(i.e.,IB1)to the respective vehicleVEHb.As a result,IB1is used by the otherRS U sof the system to accomplish the decentralized vehicle’s authentication.The blockB2is securely stored in the blockchain,which is maintained by theRS Uof the system.

E.Vehicle Authentication and Event Storage Procedure

In Section IV-C,we consider that theVEHbcollectsEmand sends parameters 〈TIDVEHb,IDRS Ua,AVEHb,CVEHb,RVEHb,B,Em,IB1〉 toRS Ua.The procedure for vehicle authentication is illustrated below:

F.Accessing Stored Event Em From IPFS

This section presents the smart contract algorithm,which is developed and implemented as a solution to retrieve the stored eventEmfromIPFSthrough theRS U.

The smart contract is developed in solidity programming language and tested with Remix IDE.TheRS Uand UserUS Riare the two main actors of our proposed contract,and each is identified via an Ethereum address (EA).The user registers in the system through the smart contract,and everyUS Riis associated with a unique Ethereum address (EA).After the successful registration of theUS Ri,the contract creates a unique tokenTKN.TheTKNis computed based on the user Ethereum address (EA(US R)) and identity of RSU(ID(RS U)).ThisTKNis used in the later stages for interacting with the contract.

If the end-userUS Ri(e.g.,police: verifying suspicious activity) wants to access the data (or eventEm),theUS Riprovides the essential parameters (such as the identity of a vehicle,timestamp of event,Ethereum address ofUS Ri,andRS U) required for the authentication of the smart contract.To authenticate theUS Ri,the following conditions must be satisfied: 1)EA(RS U) exists in the contract,2)EA(US R)exists in the contract,and 3) there exists a validTKNin the contract.If the aforementioned requirements are met,then the contract confirms that theUS Riis authenticated successfully.After the successful registration and authentication ofUS Ri,RS Uprovides thehashof the desired eventEmto theUS Ri.TheUS Riinvokes a query (it seeks to obtain the original eventEmthat corresponds to thishash) fromIPFS,and in return,IPFSprovides the desired eventEmto the concerned user.The procedure for accessing policy ofEmthroughIPFSforUS Riis illustrated in A lgorithm 1,and smart contract evaluation for the same algorithm is presented in Section VI-A.

G.Consensus Procedure for Common KeyK

TheRS Usshould agree on the keyK,as indicated in Section IV-B.This agreement is ideal for our system becauseIPFSgives hash to the initiatorRS Uon behalf of the stored event.For better accessing of events fromIPFS,allRS U smust exchange it.The authentication method for theRS Uis also shown in this Section to allow secure communication betweenRS U sand improve system security.

Step 1:At the time of deployment to theRS Uin the system,NAstores random lyNnumber of hashes in oneRS U.We believe thatNAshould keep it onRS Ua.

Step 2: RS Uacreates a merkle tree from the storedNnumber of hashes and securely stores the root value of merkle treerootmer.In addition,theRS Uaalso creates a genesis block (first block of a blockchain) from the computedrootmeras in (3),wherehashpreis all zero values for the genesis block.

Step 3:Now,RS Uarandom ly choosesMnumber of hashes from the storedNnumber of hashes (whereM≤N).After the selection procedure is completed,RS UaconcatenatesMnumber of hashes and sends it to the otherRS U s,which is encryptedE(·) using the public key ofRS U(PURS U).

Step 4:OtherRS U sin the system decryptD(·) it using their private keyPRRS U,and compute the common keyKincluding theRS Uaas in

where hashH1andHMhave selected fromNnumber of hashes,andTis the current time-stamp.

Step 5:A fter computingK,the initiatorRS Uacomputes the new parametersS1andS2and sendsS2to the otherRS U sof the system.

wherePRRSUais the private key ofRS Ua(which enables digitalsignature),andKis the computed common key.

Step 6:Once otherRS Usreceive the parameterS2,they use the keyKto decryptD(·)S2.It is noted that they have computedKin Step 4.

Step 7:After thatRS UsdecryptD(·)S1by using public key ofPURS Ua,and verify whether the receivedKis the same as the computedKor not.

Step 8:Steps 1 through 7 ensure that allRS U sagree on the common keyK,which is further used to exchangehashesprovided byIPFS.Moreover,the identity ofRS Ua(i.e.,IDRS Ua) is also present in the encrypted messageS1.Therefore,it confirms thatRS Uais an authenticRS U.

H.Procedure for Generating the New KeyK1

RS U sagree on the keyKfor exchanging thehashas stated in Section IV-G.The key was exchanged among theRS Ususing theNA-generated public and private keys 〈PURS U,PRRS U〉.As a result,there may be a chance thatNAmay reveal thePRRS Uto a third party,allowing the third party to keep track of the hash supplied by thehash.To fix this problem,the key must be changed after a certain period.Here,we assume that theRS Uawishes to create a new common keyK1.RS Uadoes this by adding the prior key into the pool of the existingNnumber of hashes,and randomly selectsMnumber of hashes (whereM≤N+1).A fter that,for creating the new common key,the same procedure is repeated as discussed in Section IV-G (from Step 3 to Step 8).The only difference is that this time,instead of utilizing keyK,keyK1is used to compute parametersS1andS2,andE(·) andD(·)operations are conducted using theK1.Once consensus is achieved forK1,RS Ususe it to exchange the hash given by t heIPFS.

V.SECURITY REQUIREMENTS AND INFORMAL ANALYSIS

In order to meet the effective operations ofVEHandRS U,the necessary security requirement such as authentication,integrity,and availability must be achieved by the system.This section first discusses how the proposed scheme achieves these security requirements and then discusses the relevant security attacks.

Authentication,Integrity,& Availability:The parameters for creating a block for authentication ofVEHb〈AVEHb,IDRS Ua,CVEHb,RVEHb〉 (i.e.,rootmer) are permanently recorded in the blockchain,as mentioned in Section IV-D.Therefore,anyRS Uof the system may conduct the authentication ofVEHb.Moreover,VEHbcomputesB=H(Em‖RVEHb) and sends parameters 〈TIDVEHb,IDRS Ua,AVEHb,CVEHb,RVEHb,B,Em,IB1〉toRS Ua.In order to ensure the integrity ofEm,RS UarecomputesB′=H(Em‖RVEHb) and verifies the condition(B′==B).In addition to this,events are stored in the blockchain,and it is always available inIPFS.

Sybil Attack:Under the sybil attack,an adversary creates multiple fraudulent identities and controls them over a decentralized peer-to-peer network.The objective is to segregate the target node from the rest of the honest nodes to gain a major influence in the network,carry out illegal activities,launch different attacks such as double-spending,refuse the transactions and blocks,etc.In the proposed protocol,VEHbhas a unique identity 〈IIDVEHb,TIDVEHb〉,and its identities are not shared with otherVEHsof the system.Before the sharing of event details withRS Ua,VEHbis first authenticated using the blockchain (i.e.,IB1).TheVEHbis not allowed to acquire multiple identities,and anyhow,ifVEHbgets the more than one identity,the required condition for authenticationis not satisfied.Therefore,launching the sybil attack from an adversary perspective is almost impossible.

Message Substitution Attack:In the proposed protocol,VEHbsends the event details toRS Ua,which mainly uses the hashing and encryption operations.The event detailEmis hashed with the parameterRVEHb,which is subsequently encrypted usingPURS Ua,and then sends the encrypted parameter toRS Ua.Therefore,if an adversary somehow getsRVEHb,the adversary can not get the original transaction due to the pre-image resistance property of hash functions,and the required condition (B′==B) is also checked during the transaction (or message) generation and authentication phase.As a result,a message substitution attack is not possible in the proposed protocol.

Man-in-the-Middle Attack:Assume that an adversary intercepts an authentication message which is sent fromVEHbtoRS Uain the message generation and authentication phase and that it uses a third party to perform this attack.Since the proposed protocol uses the blockchain for authentication ofVEHb,and the sensitive identity information 〈AVEHb,IDRS Ua〉is permanently stored in the blockchain,and it is distributedover severalRS U s,which are linked to the previous block.Therefore,if the third party publishes the fake keys,it has to change the entire chain,which is computationally not feasible,and easily traceable by otherRS U s.Thus,this scheme can resist man-in-the-middle attacks.

TABLE IIICOMPUTATION, COMMUNICATION AND STORAGE COST OF PROPOSED PROTOCOL AND COMPARED WITH REFERENCE [4] PROTOCOL7P-I : Registration of vehicle and RSU; P-II : Event generation and authentication; Tpg: Time required by PKG function; Tp f: Time required by PUF; Te : Time required to encrypt parameters; Td: Time required to decrypt parameters;Th:Time required by One-way hash function;Tδ1:Time required for searching the parameters in ledger;Tδ2 :Time required for matching the required conditions;

Blockify Attack:Under the blockify attack,an adversary intentionally steals the other’s block information from the public (or) private blockchain and tries to include it into their own blockchain.The adversary’s objective is to create the identical replica of blockchain so that it can carry out illegal activities.Assume that the third partyTPsomehow gets the new blockBi,and it wants to add this block into its blockchain network.SinceTPknows only the partial information from the public channel,it cannot recompute thehashcurbecauseTPdoes not know the value ofhashpre.Moreover,ifTPwillfully wants to knowhashpre,it must change the entire chain of blocks,which is computationally infeasible.As a result,the suggested technique is resistant to t he blockify attack.

VI.PERFORMANCE ANALYSIS AND COMPARISON

In this section,we present the performance of the proposed scheme and compare it with the state-of-the-art research.The security properties such as computation and storage cost of the node,communication cost between two nodes are used for measuring the performance of both the schemes.For measuring and comparing this cost,we considered only one vehicleVEHband one roadside unitRS Ua.The proposed approach mainly uses the encryptionE(·) and decryptionD(·) operations along with the lightweight hash functionh(·).256-bit hash function is used for the computation ofTh.PKGis used(the first time only) for the generation of keys ofRS U.For the comparison with the existing scheme,we consider that the length of vehicle and RSU identity (i.e.,IDRS Ua,IDVEHb),and parameters 〈TIDVEHb,AVEHb,CVEHb〉 each takes 128 bits.Table III provides the computation,communication,and storage cost comparison between the proposed scheme and the state-of-the-art research [4].

The proposed scheme utilizes the keyKfor the exchange ofhash(provided by theIPFS) among allRS Us.The various costs such as computation,communication,and storage involved in the consensus procedure of key is [(2N?1)Th+(2M?1)Th+ 2Te+ 2Td],[(M×256) + 128]bits,and[(N×256)+ 128]bits,respectively.HereNindicates the total number of hashes stored inRS UaandMindicates the number of hashes picks in the current iteration for generating theK,andM≤N.Fig.2 presents the storage cost (in bytes) of the proposed protocol and the state-of-the-art [4],[20],[21].It is noted that the proposed protocol achieves better performance than the existing protocols.

Fig.2.Comparison of vehicle’s storage cost with existing scheme8In Javed et al.and Shi et al.approach,nand tis the cryptoid of vehicles,and time-stamp,respectively.For comparison,we consider nand tis length of 32 bytes and 4 bytes..

A.Remix IDE and Solidity-Based Evaluation of Smart Contract

The proposed smart contract illustrated in A lgorithm 1 for accessing theEmfrom IPFS throughRS Uis validated and evaluated with the solidity language.The identity ofRS Ua,Ethereum address ofUS Ri,and Ethereum address ofRS Uaare inputs for the Algorithm 1.The output of the Algorithm 1 iseventmand hash of that event.Symbolically inputs and outputs are represented by 〈IDRS Ua,EA(US Ri),EA(RS Ua)〉and 〈Em,hash〉,respectively.The REM IX IDE and Solidity version 0.5.10 with a specification of Win 10,8 GB of RAM,Intel (R) Core (TM) i5-8250U CPU @1:60 GHz,64-bit OS is used for the validation and evaluation.

1) Deploying Cost:

The proposed smart contract presented in the Algorithm 1 is deployed in the JavaScript VM environment.0xddaad340b0 f1ef65169ae5e41a8b10776a75482dis the smart contract address,and0x5B38Da6a701c568545dCfcB03FcB875f56 beddC4is the account address.The same account address is used for deploying the smart contract under different intervals.In solidity,every execution step has a cost (transaction and execution cost) associated in terms of GAS.Fig.3 shows the analogy of the cost of deploying the proposed smart contracts in JavaScript VM and publish the same to theIPFS.Interestingly,the same cost is consumed by the contract inboth environments.

Fig.3.Deploying cost of smart contract.

2) Transaction Cost vs Execution Cost:

Users first do the registration in our system through smart contracts if they want to access the stored data fromIPFS.The smart contract should design in such a way that we can analyze the transaction and execution cost to understand how our system behaves with an increasing amount of data stored in theIPFS.User registration and its authentication and fetching the stored data fromIPFSall are variable and independent processes.Variable by means that the size of event information varies and independent indicates that the fetching the stored data fromIPFSare not dependent on each other.Fig.4 shows the analysis of execution cost and transaction cost (in terms of GAS) of proposed smart contracts.The cost required for sending the program to a blockchain is known as transaction cost.In contrast,the cost required to execute the computational operations is known as execution cost.For the accurate analysis of transaction and execution cost,the variable number of users is registered using smart contracts.It is observed that every time the rate of grow th of the curve is the same,and the transaction costs are much higher than the execution costs.

Fig.4.Transaction cost and execution cost of smart contract.

VII.CONCLUDING REMARKS & FUTURE SCOPE

This work presents the blockchain-based decentralized architecture for secure sharing of event information among RSUs without considering trusted third parties like a cloud server.This paper examined existing blockchain-based protocol and illustrated the weaknesses ofthe same protocol.Further,to address the security weaknesses,this article provides the improved event sharing and vehicle authentication protocol based on theIPFSand blockchain.The proposed protocol utilizes theIPFSfor storing the information in a distributed manner and authenticate the vehicle using the blockchain.The consensus mechanism for the common key is also presented in the paper.The security analysis of the protocol confirms that the protocol is free from all possible attacks and achieves security requirements.We also computed the computation,communication,and storage cost of the proposed protocol and compared it with state-ofthe-art research.The performance section confirms that the proposed protocol is competent enough than the existing protocols.In future research,we will work more on the smart contracts mechanism and enhance our proposed scheme’s security.