Vehicular Ad hoc Network (VANET) is a temporary wireless network that can be formed in order to exchange important information between vehicles. To become a part of VANET, vehicles need to be equipped with necessary hardware for information exchange, for example, On Board Unit (OBU), sensors, GPS, and, most importantly, high speed internet connection. IEEE 802.11-2016 [1
] provides standards for VANET communication and the recent improvement of internet speed because of 5G technology the opportunities and application of VANETs are in acceleration.
VANET provides an opportunity to create Vehicular Social Networking (VSN) between vehicles. Generally, the transmitted messages can be categorized into two categories: those are safety messages (SM) and general purpose or non-safety messages (NSM). In Table 1
, examples of safety and non-safety messages are cited. In order to inform about any emergency situation, vehicles could transmit or broadcast SMs. Because of the high importance of SMs, it is required to provide high priority during safety message transmission (SMT). In [2
], it is mentioned that Strict Delay Requirement (SDR) of 100 ms is required for maintaining SMT to ensure real time availability. On the other hand, there are some information that do not have any impact on the safety or security, but are beneficial, called NSMs. The NSM transmission (NSMT) does not require maintaining SDR, like SMT protocol.
Several protocols are proposed to ensure better management and performance efficiency of VANET systems. Among them cluster based systems are performing better than others [2
]. In a typical cluster based (CB) system, vehicles from nearby areas can form a cluster, and one of the vehicles is selected as Cluster Head (CH) to manage internal and external communication. Typical CB systems suffer from traffic overloading, packet dropping, and hidden node problem. However, by minimizing or removing shortcomings, it is possible to increase their efficiency. In [2
], Shah et al. proposed a cluster based method, where they made some changes in the Medium Access Control (MAC) protocol and packet structures to remove hidden node problem and increase the efficiency by minimizing delay and Packet Dropping Rate (PDR). Moreover, the proposed method handles SMs and NSMs separately and ensures an SDR of 100 ms for SMs. Thus, it can be considered to be a pretty successful protocol for VSN. For the communication purpose, we are going to use the proposed ACB-MAC protocol for internal communications.
With the increment of Intelligent Transport System (ITS), the importance and application of related systems, like VANETs, are also increasing. A number of researches have been found, which are targeted for increasing the performance of the VANETs. Because vehicles are moving at high speed, it is challenging to maintain good communication speed, high throughput, low PDR, etc. However, ensuring security and privacy of the vehicles were less important issues. Though, VANETs have to face authentication, identification, confidentiality, integrity, and availability related threads and attacks [3
]. Vehicle authentication is the most important security feature that a VANET system must ensure. In spite of high mobility and low configured computation support real time, authentication is required to maintain VANETs.
Typically a secure authentication system is based on Public Key Infrastructure (PKI), where a vehicle can prove its identity by sending an encrypted identification to the Local Authentication Center (LAC). LAC will decrypt the information and match it with the authorized vehicles list i.e., database and take a decision (accepts or rejects). Although the PKI based systems provide effective security, it is time consuming and mostly stored in the centralized server that has single point-of-failure problem. The time consumption of encryption and decryption increases with the level of security. Moreover, because of high mobility, each time that the vehicles move from one cluster to another one, the encryption overhead increases. Frequent encryption/decryption will increase the traffic overhead, which decreases efficiency. Additionally, vehicles with lower computational support require more time for authentication and, thus, face more difficulties during authentication. If any critical traffic information is missed by any vehicle because of authentication delay, then it may result in fatal accidents. Thus, a lightweight authentication mechanism is still a big challenge for VANET security.
Blockchain is a distributed storage platform that provides additional security, immutability, temper-resistance, traceability, transparency, robustness, etc. Although blockchain was invented to store public ledger related information, because of its varieties of security and other features, it has become popular to store different types of information in various applications [5
]. Blockchain stores information as blocks that are chained together and it is not possible to update or delete any information from the blocks; thus, it is called temper-resistance storage. Moreover, new blocks can only be added at the end of the chain, which makes the blockchain immutable and robust. However, the most important feature of blockchain is that it does not require any third party involvement to verify transactions, as all the members store a copy of the whole blockchain and, after a new block is added, every member updates their database. This ensures the transparency, third-party independence, and traceability of the blockchain. In this paper, we are going to use blockchain to store authentication related information of the vehicles, which helps us during registration and inter-cluster handover.
In this paper, we have proposed a blockchain based authentication schema for cluster-based VANET system. LACs are responsible for registering vehicles inside an area (for example, state) and generating PKI keys for them. LACs maintain a local blockchain (LABC), where all of the locally registered vehicles’ public keys are stored, and all of the CHs are the member of that blockchain. Inside a state, whenever a vehicle moves from one cluster to another one, rather than traditional encryption/decryption or sign/verification the CH will search the list of public keys and verify the vehicles. Additionally, all of the LACs are the members of a Global Authentication Blockchain (GABC), where all of the registered vehicles of a larger area (for example, country) are stored with their LAC name. If any vehicle moves from one state to another one, it has to apply to the destination LAC for temporary registration with an expected time period. LAC will verify the identity of the requested vehicle from GABC and added in the local tree, so that all of the local CHs can give easy access to the visiting vehicles. By this way, a simple and quick handover method is implemented with the help of multi-level blockchains. The proposed system removes the dependency of expensive infrastructures (for example, roadside units) for VANET by utilizing high speed 5G internet. In order to ensure faster authentication services to the emergency service provider vehicles, vehicles are divided into two categories: general vehicles (GVs) and Emergency Vehicles (EVs). Vehicles, like ambulance, emergency medical services, fire service and civil defence, etc., are registered as EVs. Whenever an EV is authenticated in a cluster, the corresponding CH will immediately broadcast an SM by informing the existence of an EV, so that all of the vehicles can provide a free passage for the EV. As a Proof of Concept (PoC), we implement a multi-level blockchain by using virtual machines (VMs) to simulate both inter-cluster and inter-LAC authentication. Computational and storage overheads are presented in order to prove that the proposed authentication protocol can perform faster than some of the previously proposed methods. Numerical analysis is also presented to demonstrate the throughput, PDR, and transmission delay for the proposed VSN protocol, which show that ACB-MAC outperforms the traditional MAC and some of the other previously proposed protocols.
The contributions of the paper can be summarized, as follows:
We propose a blockchain-based secured, decentralized, and distributed authentication protocol for cluster-based MAC (ACB-MAC) for VANETs. Inside this paper, the formation of the authentication centers, vehicles registration, and key generation processes are explained with the secure and faster authenticating methods.
We propose a multi-level blockchain to increase the scalability, faster authentication service with decentralized and distributed storage support. In the top level, a global authentication center (GAC) is responsible for store all of the vehicle information in a blockchain, where all of the LACs are the members. However, to manage the vehicles internally, LACs also manage a blockchain called LABC, which enable the quick handover between internal clusters. All of the CHs are the members of the LABC.
To remove the shortcomings, like hidden node problem, packet overloading, packet dropping, etc., of the traditional MAC protocols, we propose a modified control packet format of IEEE 802.11 standards. Cluster formation, membership details, CH election, cluster merging, and leaving processes are discussed with the safety and non-safety message transmission proposed to increase the performance of the ACB-MAC system.
In order to preserve the privacy of the vehicles, the original identity of them are securely stored in the LAC and only the public keys are shared between the CHs. Vehicles have to register to LAC in order to obtain physical verification. Moreover, RSA-1024 PKI is used by the LAC to generate public-private key pairs for the vehicles during registration and to ensure the security, integrity, and confidentiality of the transmitted messages.
In Section 2
, we discuss some of the previously proposed cluster based systems as well as some blockchain-based authentication protocols. The complete cluster structure, authentication details, and the message transmission protocols are demonstrated in Section 3
. Section 4
describes the express services proposed for the EVs. Section 5
presents the implementation tools with the experiment details. Performance analysis of the authentication protocol and the VSN protocols are available in Section 6
. Section 7
presents the security analysis of the proposed method. Finally, in Section 8
, we conclude the paper with potential future works.
2. Related Works
2.1. Cluster Based VANET Systems
The advantages of cluster based systems in terms of performance and management is available in [8
]. A cooperative Clustering-based Medium Access Control (CCB-MAC) protocol is proposed by Yang et al. to increase the reception rate and ensure the trustworthiness of the broadcasted message [9
]. In another paper, Yang et al. proposed a multi-channel cluster based method that is targeted at ensuring the reliability of the transmitted message with additional QoS support [10
]. Su et al. [11
] presented a multi-channel MAC protocol to improve the delivery rate by decreasing the delay. Gao et al. presented a hybrid cluster based system, where the mobility factor is considered to elect the cluster head [12
]. Their proposed method performs well in increasing network stability and channel utilization. All of the above mentioned are based on Time Division Multiple Access (TDMA), but TDMA-based protocols suffer from the hidden node terminal problem. For a hidden node, the system requires multiple retransmission, which increases the traffic and results to delay, as well as the decrement of throughput. TDMA protocols are not able to utilize all of the time slots of a frame due to a lack of neighbouring node. Thus, we can say that, the above mentioned [9
] TDMA based protocols do not have efficient resource utilization capability. In [13
], Hafeez et al. proposed a distributed multichannel and mobility-aware cluster-based protocol in short DMMAC, which utilizes the Fuzzy-logic Inference System for safety message transmission. Another safety message transmission method was proposed by Ucar et al. that was targeted to minimize the packet dropping rate and connection overheads, but only for safety messages transmissions [14
]. In [15
], Zhang et al. proposed a method for highway VANET by combining the cluster with carry-and-forward schemes. Although their proposed method improves throughput and data download speed, the network delay and PDR information are not provided.
In the IEEE 802.11 and the cluster-based system, Clear to Send (CTS) transmission from each of the member node is required after each broadcast. This is one of the main reason for packet drooping and, therefore, throughput reduction. Accordingly, the above-mentioned methods are not free from these problems. However, for safety message transmission, it is required to maintain the SDR of 100 ms, which did not satisfy the above mentioned papers. However, some of them (for example, [9
]) only provide solutions for emergency message transmission and others do not differentiate between messages, which reduces the importance of the emergency messages.
2.2. Blockchain Based Authentication
The authentication of vehicles are the primary requirement for VANET. Blockchain is utilized in order to store the registration information of the vehicles by Javaid et al. in their proposed method, called DrivMan [16
]. Li et al. proposed a method, called SEBGMM, in order to ensure fast authentication and handover [17
]. In SEBGMM, three blockchains are used by three components of VANET (Vehicles, Routers, and control mobility database), and they share information for authentication during handover. In [18
], Malik et al. also used blockchain to store the authentication information and ensure the privacy of the vehicles. In order to minimize the cost of signature generation and verification, Ali et al. presented a certificate-less signature schema in [19
]. It ensures the integrity and trust of vehicles, where a blockchain is used to store the identity of the authorized vehicles and another to store the unauthorized or revoked vehicles. In [20
], Kulathunge et al. presented an automated cashless Intelligent Payment System (ITP). Blockchain is used to store authentication and trust information of drivers and infrastructures, i.e., RSU. Blockchain will share the trustworthiness of drivers and RSU between each other before the transaction. Moreover, blockchain also stores the details of each transaction. In [21
], the researchers proposed a privacy-preserving trust model to provide security features, including transparency, conditional anonymity, efficiency, and robustness. They used two blockchains to store the identity of the certified vehicles, revoked vehicles. Another blockchain is also used to store the messages that are transferred between vehicles. A consortium blockchain was proposed by Zhang et al. in [23
], where they store the authentication information with location, position, direction, and rule violation information of vehicles in order to ensure the security and temper-resistance of those information.
The previously proposed methods utilize blockchain for different purposes, including authentication. Most of them use a complex authentication method, which consumes much time. In [16
], Javaid et al. used a certificate based method to allow or reject a vehicle’s permission, but did not mention the computational overheads that were generated by the signature and the verification method. The proposed method proposed by Malik et al. used encryption, decryption, signature, and verification together, which generates high computational overhead [18
]. The proposed method by Zhang et al. is also a signature based schema, where computational overhead is high [23
]. Additionally, some previously proposed authentication protocols for VANET, like [24
], also suffer from high computational overhead.
Moreover, all of the methods are dependent on Road Side Unites (RSUs), where the infrastructure costs are high [30
]. On the other hand, some other methods, like [31
], suffer from high storage overhead. Additionally, all of the vehicles, including emergency vehicles, considered to be similar, which means that the emergency service provider vehicles will not obtain any extra facilities from the proposed methods. Thus, in this paper, we proposed a lightweight and faster authentication protocol by utilizing a cluster based system that is free from extra infrastructural costs. Moreover, special services are provided to the emergency vehicles during authentication and priority passage allocation in the proposed method.
Firstly, it requires expensive infrastructures to implement RSU based VANETs and remove the extra expanses CB systems are the best solution. Thus, we introduce a CB system by modifying IEEE 802.11 packet structures.
Secondly, several types of messages are transmitted between vehicles and, in most of the cases, all of them are treated equally. In that case, sometimes, the flow of unwanted, irrelevant, and less important messages become a barrier to the emergency information transmission. In order to ensure priorities to the emergency, i.e., safety messages we divide the messages to safety and non-safety messages and proposed two different transmission protocol for them. We also ensure the SDR of 100 ms for safety message transmissions. Together with this, the proposed method is targeted to increase system throughput and minimize the delay and PDR.
Thirdly, in the previously proposed VANET protocols, all of the vehicles are considered to be equal, which means that there are no particular facility for the emergency vehicles. In order to ensure priority to the EVs, like ambulance, emergency medical services, fire service, and civil defence, etc., we categorized vehicles into GVs and EVs. In the proposed method, EVs get faster authentication services and a free lane while passing through inside clusters.
Fourthly, some of the previously CB methods are based on TDMA, which is time-consuming and suffers from hidden node problems. We introduce RTS/CTS handshaking in the proposed method to remove these shortcomings.
Fifth, privacy-preserving authentication is a principal requirement for VANETs in order to ensure security, confidentiality, trustability, etc. However, to ensure high performance, i.e., increased throughput, lower PDR, and delay, sometimes the security is compromised in the previously proposed VANET systems. The lack of proper authentication protocols may allow for malicious entities to enter and cause severe accidents inside a VANET. Moreover, a lack of security, confidentiality, and encrypted communication may offer attackers to perform different types of attack like information theft, Sybil attack, fabrication, modification, man-in-the-middle, DDoS, etc. In order to ensure security requirements, like authenticity, non-repudiation, privacy preservation, confidentiality, integrity, and attack prevention, we propose a PKI digital signature algorithm, which is RSA-1024.
Sixth, to ensure flexible, immutable, transparent, and robust authentication in a decentralized environment, q blockchain-based light-weight authentication system for vehicles is introduced. Typical certificate oriented authentication protocols are not capable of providinng all of these facilities, as well as signature generation and verification have higher computational overhead, which is described in the previous sub-section (see Section 2.2
). Additionally, the proposed method is also targeted to minimize the transmission delay as well as computational and storage overhead for authentication.
3. System Structure
In this paper, we proposed a tree structure, where a GAC is considered to be the root of the tree (see Figure 1
). All of the LACs are in the second level, where all of them are connected to a blockchain, called GABC. GABC stores all of the information regarding the vehicles of a large area. LAC consists of several numbers of clusters that come in the third level of the tree. Each of the clusters is maintained by a CH and all the CHs under the same LAC are the members of another blockchain, called LABC, which stores all of the local vehicles’ public keys. Whenever a vehicle comes to join in a cluster, the corresponding CH check its the entry in the LABC to authenticate. In the fourth level, there are vehicles that are connected to their corresponding clusters. All of the communications between vehicles are handled by the CH under the cluster.
3.1. Cluster Formation
All of the vehicles moving through same direction will form a cluster. All of the vehicles are equipped with On Board Unit (OBU), Global Positioning System (GPS), etc., with high speed 5G internet connection and communication capability. Figure 2
a illustrates the 0 finite state machine (FSM), which is the cluster formation for (English edited, Please confirm) GV. A GV is selected as CH and others become CMs. EVs will not participate in the process of becoming a CH, but rather wait to join in a cluster as CM. CH is responsible for managing all of the communication between the vehicles, i.e., the CH acts as the center of VSN. CH is also responsible for communicating with the LABC and the neighbour CHs. In order to support cluster based system and increase the efficiency of the message transmission, especially to ensure SDR for the SMs, we have proposed some changes in the IEEE 802.11 standard packet format and added some new packets. New Packets are: Registration To Cluster (ReTCl), Request To Cluster Formation (RTCF), and Request To Cluster Merging (RClM). Figure 2
b presents the changes.
3.2. Cluster Membership
All of the inactive, i.e., parked vehicles, are the members of the inactive cluster. Whenever a vehicle becomes active, it broadcasts RTCF by including cluster information, public key, type, etc. in the network. The nearby CH(s) will check the authenticity of the vehicle with the help of LABC and, after obtaining positive feedback from the database, send(s) ReTCl back with the cluster-ID (Cl-ID), Cluster Head Address (CHA), and the assigned cluster member ID (CM-ID). Multiple CHs may return with ReTCl. In that case, the vehicle will join to the cluster, whose response came first. After joining the cluster, the corresponding CH will update the cluster list and the newly joined member will move from inactive cluster to the new cluster as a child or CM. If a GV will not find any cluster to join after short inter-frame space (SIFS) timeout, it will create a new cluster and become CH of the cluster. However, the EVs will not form a cluster or become a CH, but rather continue moving until receiving any ReTCl.
3.3. Authentication Center
The proposed blockchain-based authentication system can be represented as a tree. In the top-level, GAC is there to store all of the vehicles’ information in a blockchain, called GABC. GABC stores the real identity, driver information, vehicle type, public and private key, etc. information of the vehicles. All of the vehicles have to register to the LAC before obtaining a road permit. LAC is responsible for physically verifying and generating a public-private key pair for each of the vehicles. Subsequently, it creates a transaction in the GABC by entering the required information. By this way, all of the LACs obtain the information regarding a new vehicle’s entry. GABC usually stores vehicles of a large area and it is time consuming to retrieve information of a particular vehicle. Thus, in order to increase the scalability, all of the LACs maintain a blockchain, called LABC, by storing the information of the locally registered vehicles only. This is the second level of the tree structure, where, not all, but only the public key and the vehicles’ types are stored during registration.
All of the CHs under same state are the members of the LABC (as the third level of the tree) and, thus, obtained the list of all the locally registered vehicles. Hence, whenever a new vehicle comes nearby and requests to join into the cluster, CH can verify the authenticity of the vehicle. By this way, secure authentication is performed by the CHs with the help of LABC. LAC maintains a tree, where all of the CHs are the child nodes and vehicles are children of the CHs. Similarly, visiting vehicles from another LAC can be verified by the destination LAC with the help of GABC. The application scenario is demonstrated in Figure 3
3.4. Blockchain Based Authentication
For vehicles authentication during cluster joining, we have changed a control packet, named RTCF. Two fields named Member’s Public Key (MPK) and type (T) is added in the RTCF in order to send the public key and the type of the requested vehicle within the control packet. The type field is used, which only requires 1 bit, where 0 and 1 represent GV and EV, respectively. Rather than searching for all of the vehicles from the blockchain, the system will search according to the category, which increases the efficiency of searching. If 10% of the vehicles are EV, then it is possible to get 10 times faster authentication than a system, where all of the vehicles are considered as the same. After receiving the RTCF, CH will generate a transaction in the LABC in order to search for the received MPK. Reply will come in form of 0 and 1 to represent valid and invalid, respectively. The computational time required for the whole process is discussed in the performance analysis section.
Whenever an EV become a member of a cluster, the CH immediately broadcasts a safety message by informing that an EV is there, so that the vehicles can clear the left lane (or the right lane for right hand driving countries) and give free passage to the EV. By this way, the cluster based system provides a clear channel to the EVs. The flow chart presented in Figure 4
a shows the inter cluster authentication method.
Similarly, for inter LAC authentication, whenever a vehicle requires temporary access to another LAC, it has to register to that destination LAC. For the vehicle’s point-of-view, the process is not time consuming at all, because it is required to apply to its own LAC. Local LAC will send a request to the destination LAC with the vehicle type and required time period, i.e., a timestamp. Destination LAC will check the existence of the requested vehicle’s public key in the GABC blockchain by performing a search operation. If the existence of the requested vehicle is found, then the public key of that vehicle will be added temporarily to the LABC with its type. After the requested time period, LAC will automatically disable the entity from the LABC by using smart contract. Because all of the CHs store the LABC, disabling temporary public keys will reduce the storage requirements and also reduce the download time for the new CH while copying the LABC’s transactions. The flow chart (see Figure 4
b) describes the authentication details.
3.5. CH Election and Cluster Merging
A cluster is formed by the isolated vehicle if any of the following conditions are satisfied: (i) if ReTCl is not received by any of the isolated vehicle or (ii) after the broadcasting of the RTCF messages, the SIFS interval timeout occurs. In such scenarios, the vehicles will be attributed as CH by itself. For the scenario where the isolated vehicles receive ReTCI and there exists a cluster, the role of the vehicle will be CM due to the presence of the CH for a pre-existing cluster.
The question may arise what will happen when two or more CHs joins the same network? In such cases, the CHs will merge if they join the same network coverage. A step-by-step procedure is outlined below:
The existence of multiple CH is often realized when any individual CH receives control messages from another peer CH.
The CH that realized the existence of multiple CHs will broadcast RCIM. The structure of the RCIM control packet includes critical information, like cluster member information (CMI).
CMI includes the list of CMs for that particular cluster.
Once the RCIM from the first CH is received by other existing CHs, they will broadcast their own RCIM.
At this point, it will be accounted for the number of CMs for each CH. The merging of CH happens based on the maximum number of CMs. The CH who owns the highest number of CMs gets the priority to be selected as CH. During this transformation, the remaining CHs then join as CMs and the existing role of CMs remain the same.
Once the process is finalized, the merging updates are broadcasted to all CMs by the new CH.
3.6. Leaving a Cluster
In this section, we discuss the procedure of leaving a cluster. To this end, the process is observed by maintaining the list of CMs. This list is dynamically updated when a new vehicle joins or leaves. Both types of vehicles, i.e., CH and CMs, can leave the cluster if they need to. Figure 5
presents the detailed process. The figure has four parts: (i) Figure 5
a shows the process, where any vehicle leaves the cluster. In this case, at first, CH communicates with CM through RTS. The process continues until CH receives CTS and it stops upon SIFS timeout. During this waiting period, until SIFS timeout happens, a new RTS is transmitted if no CTS is received by that time. In a case when CM is out of the transmission range, it is obvious that the CTS will not be received within the allocated SIFS time interval. Hence, the CM list is updated by removing that CM.
In the second part of the figure, a broadcasting based cluster leaving process is explained. Here, in the initial step, the CH broadcasts messages within the cluster, so that it is available to all CMs. Upon the successful receiving of the messages, the acknowledgement (ACK) message is sent to the CH by all existing CMs. The success of the ACK message receipt will validate the existence of any CM for that particular cluster. For those cases where ACK is not received by the CH, the CH will consider that the CM is not within the transmission range and the list is updated. Please note, for information integrity and availability, the message is retransmitted after a failed transmission and, at the same time, the SIFS timeout is also monitored. Figure 5
b summarizes the whole process.
In the last two parts of Figure 4
c,d, we have adopted the notion S and D, which denote the sender and destination, respectively. In those figures, during the cluster leaving process, a CM transmits data as a sender (S
) to all D (that includes both CH and CM). After sending the RTS, the sender will be waiting for CTS. This waiting time is related to the SIFS time out. In our modelling, if S sends RTS to CH, then the timeout happens after SIFS interval. However, if S sends RTS to another CM, then the timeout happens for 2SIFS interval. Within the waiting time, if no CTS is received by the CM, then the RTS message is retransmitted. Figure 5
c shows the case when CM retransmits the RTS, while Figure 5
d shows the case when CH retransmits the RTS.
3.7. Safety Message Transmission (SMT)
Safety message transmission is one of the critical aspects of the proposed model. Safety related messages include accident prevention information, emergency brake signalling, emergency cautionary, etc. These messages are critical and need to be satisfy strict time requirements. These safety messages are reliably transmitted from CMs to CH using the RTS or CTS mechanism. The usage of RTS and CTS help to reduce the packet collisions during a large scale broadcasting of the safety messages among CMs and CH. The safety message broadcasting procedure is summarized, as below:
At the first step, CH broadcasts the safety related messages.
Upon successful receiving of the messages, the CMs follow up ACK messages.
The process is considered to be successful if ACK messages are received from all CMs.
For those scenarios where ACK message is not received, the possibility of transmission failure is evaluated by checking whether the number of retransmission (Rt) is less than or equal to the maximum retransmission limit for safety messages (Mrsm) [2
]. In those cases, the safety messages are retransmitted for the missing ACK cases.
The ACK of the safety messages plays an important role in reliable message transfer. Figure 6
a illustrates the complete process of the proposed safety message transfer protocol and the handshaking between the vehicles during SMT are shown in Figure 6
3.8. Non-Safety Message Transmission (NSMT)
Similar to the safety message transmission that was discussed in the previous section, our proposed VANET model also proposes non-safety message transmission protocol in order to exchange general purpose messages. The non-safety messages include map download and updates, audio and media file transfer, web browsing, etc. The process of non-safety message transmission is supported by the unicast message broadcasting. In this setup, the sender (S
) sends messages to the destination (D
). CH and CM both act like a S or D. Based on the roles, one CH can send messages to a single CM. In this scenario, the effectiveness of the successful message transmission is observed by realizing the message acknowledgement (ACK). In another setup, one CH can send messages to another CH. In the last option, CMs can communicate among themselves via CH. In this setup, the communication happened between CMs and CH while using the RTS or CTS mechanism. Once the receiver CM receives the messages, then it sends an ACK message to the intermediate CH, and then CH forwards it to the sender CM. Throughout the process, the RTS/CTS ensures reliable message communication that avoids packet collisions. Those cases where ACKs are not received are considered to be unsuccessful message transmission. The retransmission of the non-safety messages happens if the number of retransmission (Rt) for the failure transmission is less than or equal to the maximum retransmission limit for the non-safety message (Mrnsm) [2
]. Figure 7
a summarizes the whole concept of non-safety message transmission and Figure 7
b–d illustrate the handshake between the vehicles during NSMT.
We present a PoC implementation of the proposed ACB-MAC using the ethereum blockchain. Multiple VMs are used in order to represent a random GABC, an LABC that is also a member of the GABC, and a CH, which is a member of the LABC. The inter-cluster and inter-LAC authentication are both simulated with the setup. Implementation details with the tools used are described in this section.
5.1.1. Truffle Framework
Truffle framework is a well-known framework to test transaction and other functions of ethereum blockchain. It is possible to deploy and test codes that are written in smart contract by using this framework. Additionally, it provides network management, scripting, and client-side development services [33
5.1.2. Ganache Emulator
Ganache is a virtual ethereum blockchain emulator [34
]. It can be used as real blockchain, as it provides all of the facilities to develop and test Decentralized Application (DApp). Moreover, it supports blocks and transactions detail examination, log analysis, and debugging. It is possible to create users and customize the attributes of the users and other configurations of blockchain. Ganache is platformed independently and two variants (UI and CLI) are available. UI version is used for this implementation.
5.1.3. Metamask Ethereum Wallet
In this implementation, metamask wallet [35
] is presented for currency management in the ethereum blockchain. All of the members will use metamask to connect and perform transactions in the blockchain. It can be used from both computer or mobile devices. It is possible to connect with custom Remote Procedure Call (RPCs) by using metamask. We utilized this facility to connect it with the local blockchain.
5.1.4. Node Packet Manager (NPM)
Both of the blockchains are hosted on the web for easy access. NPM [36
] is used in order to develop the client-side in HTML.
To present the tree structured authenticating system, we use a VM by using Oracle VM VirtualBox 6.1
to host the GABC, named GABC-VM. After installing the truffle framework, we install ganache, which will act as the GABC. NPM with other dependencies is also installed in order to provide web based services. All of the LABC are members of this blockchain. All of the machines are using Ubuntu-18.04.4-desktop-amd64 operating system and are connected to each other by using internet connections. The parameters are available in Table 2
Another VM is configured with the same programs and is considered to be an LABC-VM. The LABC-VM is a member node of the GABC, and it is able to perform transactions on the GABC by using metamask wallet that is installed in the Firefox web browser. By using RPC, a metamask is connected to the virtual private blockchain hosted in the VM. During a new vehicle’s registration, two transactions are generated by LAC for two different blockchain, one to store the details of the vehicle in the GABC and another to store public keys and types of the vehicle in the LABC.
All of the local CHs are the members of the LABC. Two more VMs with two different OSs are configured in order to represent the CHs, as a member CH will download all of the contents of the LABC. During vehicle registration in the cluster, these CH-VMs use a metamask wallet to perform search operations in the LABC. Whenever a vehicle becomes CH, it becomes a member of the LABC and it will download all of the transactions, i.e., local vehicles’ public keys and types.
All of the necessary programmings for vehicle authentication during cluster joining and temporary access permission are written using solidity, which is a popular language for writing smart contracts. The program for the GABC consists of two functions, the first one to add a new vehicle in the blockchain and the second to view or search the existing public keys from the database. All of the LACs are connected to the servers through high speed 5G internet connection.
For LABC, three functions are used by the LAC, one to store the public key and type information of vehicles (during registration), the second one to add vehicles from another LAC (temporarily), and the third one to view or search for the public keys. CHs are the members of the LABC with view permission only. CHs also use the search function in order to check the authentication of the vehicles during cluster joining process. There is another function that performs automatically when a timeout occurs. Whenever a visitor vehicle joins another LAC, it requests a required time period. After the timeout, the disabling function runs automatically, which generates a transaction for disabling the entry of the visitor vehicle. This one is used to reduce the storage requirement and all the members (LAC and all of the CHs) updated their storage accordingly.
During cluster joining, after receiving the public key and the type of the requested vehicle, the CH generates a transaction to search for the public key in the LABC. The LABC is hosted in the LABC-VM, which performs the searching and provides the result. If the public key is found, then the CH will store the key in the CM list and start communicating as a member.
For temporary access permission, a vehicle’s own LAC sends a request with the vehicles public key, type, and requested time period. After receiving the request, the destination LAC will generate a search transaction in the GABC and temporarily register the public key in the LABC. The smart contract is written in such a way that, after the requested time period, a transaction will automatically be generated, which disables the entity from the LABC.
A cluster based method is presented in this paper in order to manage VSN, where one of the vehicle become CH to manage the communication as well to check the authenticity of the vehicles during the cluster joining process. For VSN, the transmitted messages are divided into two categories; important information is considered as SM that must be delivered within SDR of 100 ms, where other general information messages, i.e., the NSM, get less priority than SM. To manage these types of messages, two different transmission protocol are presented, named SMT and NSMT protocols. Additionally, a multi-level vehicle authentication model is also proposed by using two blockchains. One of the blockchains is used in order to store the detailed information regarding the vehicles during registration, called GABC, and another to store minimum information to check the authenticity of the vehicles, called LABC. Vehicles of a state are registered to their local authentication centers and a public-private key pair is assigned to them. During cluster joining and visiting outside the local area, the public key will be used as their identity. All of the LACs are the members of the GABC and all of the CHs under an LAC are the members of the LABC. Thus, CHs are able to store the authenticated vehicles’ information in their local storage in order to ensure faster member authentication. In the proposed method, in order to provide priority services to the EVs, like ambulances, fire trucks, emergency medicine, etc., the vehicles are divided into two types, which are general (GV) and emergency (EV). This will help to increase the authentication speed by 10 times for EV and two times for GV than the method, where all of the vehicles are together and 10% among them are EV. In addition, whenever an EV joins a cluster immediately, the corresponding CH generates an SM in order to inform all of the members to clear the left lane and give free passage to the EV. This way, the EVs get faster treatment during authentication and movement. The communication between the blockchains and their members are encrypted by utilizing RSA-1024 digital signature algorithm in order to ensure the safety, security, integrity, confidentiality, etc. of the communication between vehicles and blockchains. Additionally, blockchain provides robust, decentralized, and distributed database services, including security, flexibility, temper-resistance, immutability, transparency, etc. We have tested the proposed authentication protocols by implementing them in VMs as a proof-of-concept and showed the computational, storage, and propagation overhead by the authentication process. The results show that it requires 3.10 ms time for the authentication process, which is better than [23
]. However, to store one-million vehicles’ authentication information, it requires 606 MB, which is minimum and less than the proposed method, like [31
]. Because of high speed 5G internet, the proposed method requires ignorable propagation time. Moreover, internet based communication removes the high infrastructures expense. Mathematical and numerical analysis of the proposed message transmission protocols were also presented, which shows that the proposed method provides better throughput, lower delay, and lower PDR from the traditional MAC protocols and other previously proposed method, like [8
]. In the future, we are planning to implement a consensus protocol with the blockchain in order to collect abnormal behaviours of the vehicles from their neighbour vehicles for behavioural analysis or reputation management. It will add some more security features, for example, removing the possibility of compromised attacks and also helping to take actions against malicious or abnormal behaviours.