In this section, solutions that have been proposed to preserve privacy by the usage of blockchain in different aspects of IoV are presented organised by their service area (RQ1).
There have been several works published in the area of blockchain-based pseudonym management and authentication in vehicular networks and they are presented below.
Liu et al. [28
] introduced DAIA, a system that can ensure identity authentication and privacy. DAIA is based on a permissioned blockchain and provides a dynamic pseudonym using a tamper proof device. The main participants in this system are a Certification Authority (CA), Roadside Units (RSUs) and vehicles. CA as master node manages the blockchain network and the new block generation and is responsible for the secure parameters’ selection. Moreover, it acts as the primary node in the consortium, records all the information and publishes the public information of RSU and tracks malicious vehicles and keeps a list of them. It is assumed that it is a trusted entity and can backtrack the identity of a malicious vehicle. RSUs are spread across the road and can manage the vehicle in their range. They are wired connected with the CA and wireless with the vehicles. They can download the malicious vehicle list from CA and it is considered as semi-trusted. Vehicles are equipped with OBU and realistic TPD (Tamper-proof device). The OBU is responsible for the wireless communications and the TPD for the storage and management of the private parameters, pseudonyms and keys. Due to attacks the TDP must frequently change the key. The dynamic anonymous identity authentication consists of five phases: (1) Registration: CA sets the parameters, RSU and Vehicles are registered to the networks and their ids are published in the blockchain. (2) Anonymous identity generation: when a vehicle enters in RSU range the TPD creates the random pseudonym. (3) Communication: vehicle communicates with the RSU exchanging time stamped messages. (4) Tracking: when a RSU wants to trace a vehicle it sends a message to CA. Then, CA writes the vehicle in the malicious list. (5) Update system keys: when system keys expire it drops them and creates new ones.
The overall DAIA system is built up to be resistant to the following attacks: (i) Unlinkability: the true identity of the vehicle is stored to CA so an attacker cannot obtain the keys; an RSU does not carry any sensitive vehicle information. (ii) Non-repudiation: the vehicles cannot deny the message they send. (iii) Strong privacy protection: even if all the RSUs are compromised, the identities of the vehicles are stored with hash functions. (iv) Realistic TPD assumption: the TPD changes the keys frequently, so it is difficult to be compromised by side-channel attacks. (v) Man in the middle attack resistance: any attack of this type can be detected by the RSU. (vi) Efficiency analysis: the efficiency of the system is ensured by the ECDLP. Security analysis and simulation have shown that the proposed scheme is slower that others but achieves better security and strong privacy-preservation which make it suitable for practical VANET environments.
Sharma et al. [29
] suggested a scheme for vehicle authentication and privacy preservation called BlockaAPP. Based on private blockchain technology, this system consists of four entities. The first entity is the vehicles. The second entity is a registration server, which is responsible for managing and validating vehicle’s ID. The verification of the vehicles is carried out by the third entity, called Service Provider. Moreover, there are multiple service providers in order to supply different services to vehicles simultaneously. The last entity is the blockchain. A trusted authority gives access to the blockchain, where service providers can read and write, in contrary of the registration server which can only write to the blockchain. The trusted authority is the only one that has the ability to read the blocks and transaction timestamps in order to trace any malicious activities back to the real ID. The proposed system works in three phases. The first one is the registration phase. In this phase, to avoid identity spoofing and to preserve its privacy, every vehicle sends an encrypted message to the registration server and a trusted authority checks and exchanges their real ID with a pseudonym. This pseudo-id will be used for any future communications for one session. After a successful exchange, the registration server adds the necessary details of the transaction in a block and dumps all the other so that real ID cannot be retrieved. During the second phase which is called authentication phase, the vehicles send their pseudo ID and the requested services to the service providers. The service providers accept or decline the requests. Then, they add any valid or not request to the blockchain. The third and last phase is the authorisation phase. For every offered service, the service providers maintain a pair of private and public keys, in order to identify the service and the transactions. The vehicle sends a request message and its digital signature that is created using its private key. The service providers check the request message and add the transaction to the blockchain, whether it comes from a valid vehicle or not. For the exchange of keys, the proposed system has considered an asymmetric key cipher and the validity of the transaction is ensured using a consensus protocol. During registration phase, RSU, vehicles and cloud server act as intermediate access point to the registration server and to the service providers during authentication and authorisation phases. The authors built their system on a permissioned Ethereum platform and the smart contracts are implemented in Solidity language using the Remix development platform. The results demonstrate that by using the permissioned blockchain, privacy can be preserved.
Another pseudonym management system for IoV is VCS proposed by Bao et al. [30
]. In this scheme, the authors use a four-layer type of nodes. The first three layers for the service providers consist of RSUs covering geographically all the roads, PMs (Private Manager) both with wireless communication devices, plus the RSU act as access point and Public key Infrastructure (PKI), containing Certificate Authority (CA), Anonymity Server (AS) and any other third party infrastructure, where all the pseudonym and cryptographic materials are created. The fourth layer called service user consists of the vehicles equipped with computerised device known as On-Board Unit (OBU). The PKI is isolated and generates all the cryptographic material to link the real identity to the pseudonym of the vehicle. The pseudonyms are not permanent, but they change after a period of time. Moreover, all these cryptographical materials must be kept in a secured facility to ensure the privacy and security requirements. The central managers can be accessed only for the initial registration of the vehicle and for revocation of a certificate, in case of malicious behaviour or identity compromise. In this proposed system, the PM are shuffling the pseudonyms and the PKI can keep track of the pseudonyms related to original identity, by keeping the transaction in a disturbed ledger, making the revocation of a certificate in the shortest possible time. The new revocation list will be broadcasted to the vehicle nodes. For the blockchain network to work properly, some assumptions are made: (1) Role of the miners: PM take the role of the service user and miner as they have powerful computation power to maintain the blockchain and do the block mining since there is not any reward, featuring in classic blockchain networks. (2) Approximate Mining Synchrony: to limit the deadline for each transaction collection interval, all the PMs start the mining at the same time, using a synchronised clock. (3) Consensus: the adapted consensus is Proof-of-Work, since it is the only one efficiently tested against security manners.
The function of the VCS is described below: (i) System initialisation: the cryptographic material is generated by the PKI and transmitted through highly secured connection to the vehicle and equipment manufacturers, who install it to the vehicles. (ii) Pseudonym Shuffle: the vehicle marks the pseudonym as used and when the expiration conditions are met, the vehicle can change it, only when it enters on an agreed place named mixed zone, where all vehicles are mixed in order to minimise the ability to be tracked. The expired pseudonyms are kept for a certain period in single package, and afterwards they are shuffled and disturbed back to the PMs for reuse. (iii) Certificate revocation: the proposed system has a malicious behaviour detector; PM collects all the activity and while communicating with the network, it broadcasts all the malicious reports. Even if a PM is compromised, the blockchain network is secured, as it needs 51% of them to work properly. The proposed system is built in permissioned blockchain and has been tested in simulation, using OMNET++ with dedicated simulation packages Veins and PREXT; the simulation results find the proposed system more effective than the traditional pseudonym solutions and more resilient to privacy and security attacks.
Guehguih et al. [31
] presented an authentication and message dissemination scheme for vehicular systems which contains two different blockchains, a permissioned geographical blockchain and a permissionless blockchain. The permissioned blockchain is used for authentication of vehicles within the boundary of a country. In this blockchain a trusted authority (TA) is responsible for generating new blocks which represent pseudonyms of users in a chronological order. During the registration process, a secure channel is established between the vehicle and the TA, and then the vehicle sends to TA its real identity, obtained by Motor Vehicle’s Division (MVD). Afterwards, TA cooperates with MVD to check the vehicles real identity and then produce a pseudonym for that vehicle. After the successful vehicle’s authentication, TA appends a new transaction to blockchain. Vehicles can only read this blockchain to check the authenticity of other vehicles. In addition, special vehicles have the role of miners while other On-Board Units have only read rights, thus malicious behaviour is prevented. The public blockchain, named RSU-BC because it acts as an RSU, is used for event messages dissemination. RSUs are replaced by blockchain, in order to achieve decentralisation of the system and avoid a leakage of private information in case an RSU is attacked. In RSU-BC every entity can generate new blocks representing event messages. Vehicles can act either as miners in this blockchain or as light nodes which are only responsible for generating messages. After a new block is generated, all cars in the system update their blockchain and can be informed for information such as road conditions and safety. In the case of a vehicle travelling in another region, the miners of the new RSU-BC check its authenticity in authentication blockchain in order to participate in the message dissemination procedure.
By using geographical blockchain, consensus convergence time is reduced. In addition, because pseudonyms are stored in a blockchain, they cannot be modified by third parties. Moreover, because only trusted authority knows the association between pseudonyms and real identities and no other information is issued in transactions, privacy is prevented. During experiments’ performance and security analysis, the proposed scheme was compared with previous models and proved that it requires the lowest computation and communication cost, according to the authors.
A privacy preserved framework in VANET is proposed by Zheng et al. [32
]. The proposed system is based on blockchain and pseudonymity. The vehicle obtains its real identity from Motor Vehicle’s Division and communicated with a trust Certificate Authority (CA) via a secure channel. CA verifies the real ID and issues a pseudonym (PID) with a pair of public and private ECC keys. Two hash functions are calculated by the CA. The
is the vehicle pseudonym and public key and
is the relationship between the vehicle’s real identity and pseudonym. The
function is stored in a Cloud server and the
function is stored inside the vehicle’s OBU and on the permissionless blockchain at the stage of authentication. As the authors mention, there are multiple cloud servers where the data are stored divided for decentralised reasons, and a Proof-of-Work consensus is used. When a Vehicle enters RSU range and sends its PID and public key, the RSU authenticates it calculating the
, querying the cloud server for trueness. The result is recorded on blockchain. To verify the secure communication, RSU sends a random integer encrypted with the vehicle’s public key. Upon reception, the vehicle chooses another random integer and calculates the hash of both, sending it back. Finally, RSU verifies the hash function with vehicle’s public key and packs it up as a transaction on the blockchain. When a Vehicle needs to announce a traffic condition, an accident for example, it is called event D
. The event D
can be a text, a photo or video. When an event D
occurs, the vehicle utilises the random number previously exchanged with RSU; that way the RSU authenticates the event and packs it on the blockchain as a transaction and broadcasts it to the network. Simultaneously, the transaction details are divided on random cloud servers. If in any way, the RSU cannot validate the vehicles ID or event truthiness, it requests the true identity of the vehicle from the CA and broadcasts the malicious vehicle into the blockchain. The scheme has been simulated in GoLang to analyse and evaluate the security and performance.
Benarous et al. [33
] focus on preserving a decentralised solution for the pseudonym management which ensures the privacy and security of involved participants. The supposed framework is a blockchain consisting of two blockchains: a certifying blockchain managed by registered vehicles and a revocation blockchain maintained by the Roadside Units (RSUs). Both blockchains are public and permissionless. Additionally, there is another one chain, the offline chain, which is permissioned and maintained and accessed only by the RSUs. The certifying blockchain is used by vehicles for saving the certified pseudonyms. RSUs have access to this blockchain only with read rights. In contrast, in revocation blockchain, RSUs have write access rights, while vehicles have only read rights. The offline chain is used to link the revoked the temporal pseudonyms with their users. The all framework is seen as one blockchain by the end user regardless of his role. The blockchain framework enables vehicles to generate, validate and handle their own pseudonyms without any authority’s intervention. While registered, a vehicle creates a transaction that acts as a certificate for its pseudonym and appends it to the certifying blockchain, executing the Proof-of-Elapsed-Time consensus model to publish blocks. To eliminate central’s authority usage, vehicles sign their transactions using ring signature. In revocation process, misbehaving nodes are detected by vehicles which inform RSUs. Then, RSUs revoke the pseudonyms of malicious nodes and after recomputing the one-time address to find their public key and all their unused pseudonyms, they append all malicious user’s information (the revoked pseudonym, the public key and all unused pseudonyms) to the revocation blockchain which is then distributed to the network. RSUs execute round robin consensus model, in order to publish blocks. During the authentication phase, vehicles firstly check that the used pseudonym belongs to the certifying blockchain and not at revocation blockchain and afterwards they check the validity time and beacon’s signature.
The users’ identity privacy is protected, as blockchain prevents their identity and their car’s identifier of being exposed. Furthermore, vehicles can check a pseudonym’s or signature’s validity, without being able to link it with the real singer, by using one-time addresses. In addition, blockchain does not record private keys, thus anonymity is ensured because identities are not exposed. Lastly, because all used pseudonyms are recorded in blockchain, malicious nodes cannot deny their committed actions. In addition, in case of misbehaving, all unused pseudonyms and their public key are revoked. Thus, the system is secure from attackers and malicious users. Lastly, through security analysis, by using attack tree method, the authors have shown that their model is more resistant to attacks than the conventional vehicular public key infrastructure (PKI).
Yao et al. [34
] proposed a privacy preserving scheme with trust management. Their system considers responsible the Law Enforcement Agencies (LEA) to register a vehicle to network. The RSUs are responsible to distribute pseudonyms to the vehicles, as well as to maintain a two layer permissined blockchain. On the blockchain’s consortium layer are stored the pseudonyms, to preserve privacy, and the messages of the vehicles. On the vehicular layer, the vehicle’s authentication is stored, as well as the trust evaluation of the vehicles. The system has the ability to change a vehicle pseudonym if requested. To prevent any data tamper, trust calculation is secured by homomorphic encryption. A performance implementation has been employed using the Performance Evaluation Process Algebra (PEPA) model showing that homomorphic encryption and pseudonymity can protect the vehicles’ privacy.
Su et al. [35
] proposed a system based on permissioned blockchain for IoV with privacy protection. The system has three entities: LEA, RSU and Vehicles (users). The Law Enforcement Agency (LEA) is responsible for the registration of the vehicles. The owner of the vehicle must send the real information of the vehicle (like license plate number, name and type) and the LEA determines if it is legit to participate in the network in order to generate a username (pseudonym) and a pair of public-private keys and the validity period of the keys, as it must change on a regular basis to preserve the vehicle’s privacy. RSUs are responsible for the communication between the vehicles and maintains the blockchain network, registering network’s data. For that reason, RSUs should have powerful computation power and sufficient storage capabilities. Moreover, RSUs are responsible to detect distorted broadcasts and evaluate the vehicles, forming a reputation system. If any of the vehicles are flagged as malicious, its key is revoked and the process packed as a transaction registered into the ledger. Based on experiments, the location privacy is preserved by pseudonyms and by using encryption on the public keys.
Moussaoui et al. [36
] proposed a scheme for VANET based on blockchain that uses PKI to preserve privacy called BCPKI. The scheme consists of Vehicles (users) and RSUs. The vehicle must register to the network via RSU. The vehicle requests to join the network and the RSU issues a pseudonym using PKI certificates and stores it to permissionless blockchain. Authors use pseudonyms as a primary privacy preserved technique for their proposed scheme.
A light-weight authentication scheme based on permissioned blockchain for VANET is proposed by George et al. [37
]. The architecture includes Authentication Parties (AP) that are responsible for ledger maintenance and registration of the vehicles. The vehicles are the users and RSUs which have a read-only access to the ledger. Upon registration AP disturbs a set of public-private key set to the vehicles, as well as a pseudo ID, called PID, to preserve the vehicle’s privacy. Moreover, AP is the only participant that can trigger transactions and write on the blockchain. Vehicles are equipped with OBU and can transmit Basic Safety Messages (BSM) to other vehicles or to the RSUs. The privacy, during the exchange, is preserved by the pseudo ID. The BSM have attached the private key of the sender that key can be used to authenticate the BSM without the intermediate use of RSU. The system is based on Hyperledger Fabric using a Solo ordering service and has been simulated on OMNET++ and SUMO, indicating that the system can reduce RSU computation power.
], a blockchain-based decentralised reward solution is described. The suggested model is based on a permissioned blockchain which is distributed among multiple RSUs in a vehicular system. Every vehicle in the network is equipped with a tamper-resistant black box which uses smart cards to store credentials in order to ensure safety of transferred data. During registration phase, vehicle’s black box (VBB) generates vehicle’s keys and then shares the public key and vehicle’s identifier to the service provider (SP). The connection between the SP and VBB is performed through a secure channel by using SSL and TLS protocols. Vehicles use pseudo-identities that are produced by their public key and random numbers, to communicate with RSUs and send data to them. Only SP knows the real identity of vehicles in order to reward them from sharing data. When vehicles travel in a vehicular system, their VBB send data to nearby RSUs which pack those data into blocks. Afterwards, the blocks are sent to the RSU with the smaller workload to upload them to the ledger. A copy of the blockchain is then stored in every RSU, and all copies are synchronised with each other, avoiding central vulnerabilities to attackers and location compromise. Because vehicles use pseudo-identities, RSUs cannot figure out which vehicle transmitted the shared data, but they can authenticate it.
Changing pseudonyms are used instead of a unique identifier, so they cannot be linked with their real identities. Furthermore, when a pseudonym is changed to a new one, network identifiers (IP, Mac addresses) change simultaneously to protect linking between those pseudonyms. Only service provider (SP) and no one else can trace the real identity of vehicles in order to reward them for sharing data. In addition, RSUs authenticate messages, without knowing or guessing which vehicle transmit them, but the signature verification of the proposed protocol ensures that only legal vehicles transmit data. Therefore, anonymity and privacy of transactions are ensured. Lastly, through experiments on open SSL and performance analysis, the authors support that anonymity is provided in authentication services.
Gabay et al. [39
] proposed two different approaches for privacy preserving authentication of Electrical Vehicles (EVs) throughout charging process. Firstly, they implemented a framework which combines Ethereum blockchain technology with zero-knowledge proofs and more specific with Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zkSNARKs). In this model, EV Charging Service provider (EVSP) acts as the Trusted Third Party (TTP) which is responsible for user registration by producing a secret function and for generating, proving and verifying keys. Then, EVSP sends the function and proving key to the users and verifying key to smart contract of blockchain. The user (or prover) is the EV, which must solve the above function in order to generate a witness and then integrate this with proving key in order to generate a proof with a public timestamp, while the blockchain is in charge of verifying the prover’s proof without knowing any details. A pseudonym address is used by EV to communicate with the blockchain smart contract, with the peculiarity to use a different pseudonym address whenever it desires to use charging service. Since the proof is verified and authentication is completed, a service token is created by the smart contract, which EV can use to plan its charging without having to confirm its identity. Then, this information is encrypted with EVSP’s public key. EVSP uses encrypted information in order to schedule charging of an EV and a charging-token is returned to the EV which sends a cryptocurrency deposit as a warranty; this is the same for every EV to prevent fake charging schedules. During charging procedure, the charging station receives the EV’s charging-token to confirm that it is the scheduled one.
Moreover, they improved their approach by using a Pederson Commitment rather than the token mechanism, in order to improve the efficiency and reduce the cost of provided services. The basic changes in this approach are that the EVs do not only receive from EVSPs the proving key and function that they have to solve but also the Pederson Commitment parameters. The function is also more difficult than the previous case in order to be more cryptographically secure. If the EV can open Pederson Commitment, it can schedule charging. With the given elements, EV creates its own commitment. Furthermore, the EV is aware of its preferred scheduled charging slot, as it is contained it the commitment, so it encrypts a message that EVSP can later decrypt to book the charging station. The EV verification during charging procedure is done through a comparison of EV’s and EVSP’s commitment. This comparison is accomplished by EVSP while the equality of those two commitments proves that the EV is the scheduled one. Like their first approach, EV use pseudonym addresses and a deposit in the form of cryptocurrency to pay for charging. Furthermore, in both approaches, a single smart contract is responsible for all EVs to improve the performance and efficiency of those models. Through security and privacy analysis, the authors have proved that their two approaches ensure that personal information of vehicles, like their ID or location, can be securely protected by using zkSNARKs, because EVSP can authenticate EVs without knowing any other information. Additionally, charging stations also cannot access any personal data, as they are only aware of the anonymous identities of EVs, and malicious users cannot match the Ids to their real users or obtain another information from the blockchain. Regarding the payment method, as it can by accomplished through cryptocurrency and blockchain, anonymous payment is permitted without using a credit card, thus protecting the privacy of users. Both proposed models were evaluated by using Zokrates, a toolbox for zkSNARKs on Ethereum, and results have shown that they are both feasible for real life, with the second approach prevailing first in time and money cost.
Akhter et al. [40
] proposed VANET, a privacy-preserving system that uses multi-level blockchain-based on clustering. Their proposal consists of vehicles and Authentication Centres. Moreover, the system is based on 5G wireless networks so the use of RSU is not needed. The Authentication Centres are divided geographically; there are the locals (LAC) and a global (GAC) consists of all the LACs. The LACs keep a blockchain ledger with the registered vehicles in their region and the GAC maintains a blockchain ledger with all the registered vehicles. The system, to preserve the privacy of the vehicles, firstly needs to physically verify the vehicle by LAC and impute it with a private key. This private key is used as a pseudonym for information exchange on VANET. Moreover, the vehicles are divided into two categories, the General Vehicles (GVs) and Emergency Vehicles (EVs) such as ambulances. In order to preserve location privacy the vehicles moving at the same direction form a cluster. When an EV enters the cluster it can use the system to transmit an emergency signal and notify the other vehicles in order to provide it with safe passage. The network is based on Ethereum and simulation experiments that have been contacted on the Truffle suite, showing the proposed system is feasible.
6.2. Traffic Conditions
Another important service of VANET is the monitoring of traffic or road conditions in order to improve the performance of the road circulation and avoid accidents. The following papers suggest several systems which purpose is to upgrade road conditions while protecting privacy.
Li et al. [41
] suggested CreditCoin, a system for announcement exchange in VANET. It develops a custom announcement protocol by the name “echo-announcement” and a permissioned blockchain network based on coin-exchange system for reliability and privacy. The key entities of CreditCoin are a Trusted authority (TA), which is responsible for managing the cryptography keys and user identity, the Trace manager (TM) to trace malicious users, users which are vehicles and On-Board Units (OBUs), Roadside Units (RSU), which are distributed alongside the roads and are responsible for the users inside their communication range and lastly, a cloud application server for non-cryptographic data exchange. The main idea of the system is that a user can broadcast in the network via the “echo-announcement” protocol, reliable information about the traffic and the receivers are able to take advantage of these information in order to make route changes. The blockchain network is based on coin-exchange logic for every valid announcement. Every user starts with a few coins in order to broadcast an announcement and a threshold ring signature of this announcement, for example a car accident, which nearby users must confirm and then RSU with official public vehicles take the role of the consensus server which creates the coins. Thus, there is not a need for a work-of-proof, instead a byzantine fault tolerance consensus algorithm is used and by taking advantage of combined-public keys (CPK) for reducing cryptographic time consumption, the transactions are fast. The confirmed announcement is signed by the nearby users and broadcasted in the whole network. As a result, the user is earning coins and reputation. A false announcement costs coins and for that reason, the network can be protected from malicious users. Moreover, to avoid attacks to user’s wallet, the coins and the reputation have time limitation for their use. If any misconduct was found, the trace authority Pseudonym Management sends the information to the cloud application to take actions. The proposed system had been tested thoroughly in PolarSSL simulation environment and the results have shown that privacy can be sufficiently preserved.
Bai et al. [42
] suggested a blockchain-based warning scheme which aimed to solve traffic problems. This system is using a group signature-based authentication protocol in combination with blockchain technology, to guarantee privacy and security and parallel to ensure identity traceability. In contrast to traditional methods, where the status information of vehicles is acquired by the on-board diagnostics and the position data through the GPS sensors, the proposed system is using a smart terminal (for example a smartphone) to collect those data, through some adjustments and assumptions. Such assumptions are that a normal turn takes 5 s and a sharp turn takes 3 s. Furthermore, x and y axis of the terminal simulate the acceleration and angular velocity respectively. The irregular noise that may occur can be eliminated using a weighted moving average filter. The collected data is sent to the feature recognition module for driving behaviour identification. Detecting irregular driving can warn the driver early for possible accident. An edge node within the group is served to Group Managers which create a pair of public and private keys and broadcast the public and parameters to in range vehicles. The vehicle applies a blind signature and submits its authentication information back to the manager. Finally, the vehicle communicates with nearby vehicles through the edge node, having signed the status information through certificate and group public key. In case of an accident or a malicious behaviour, the manager can track back the vehicle through the public key in the group signature.
The edge nodes maintain the permissionless blockchain and also collect data from vehicles and put them into blocks. As a consensus protocol, the authors proposed a hybrid one based on PoS and DAG, as the popular Proof-of-Work consuming a lot of processing power. Because of the continuous change of the data that the road conditions impose and until the wide use of 5G, a Time Sensitive network is the best solution at present as the authors mentioned. Security tests have been made by collecting real life data, by using iPhone 7 as smart terminal and computer with Ubuntu OS for the data processing. The data had been collected by taxis and family cars, and then the evens were edited by hand. The authentication protocol and blockchain have been tested in simulation on IBM-Watson platform, which proved than they can be used for quickly obtaining warnings and in parallel protecting a user’s privacy.
Cheng et al. [43
] proposed a semi-decentralised scheme called SCTSC for privacy preservation in identity, location and data. The scheme uses a permissioned attribute-based blockchain to control traffic lights. In this scheme, in order to reduce traffic, signals of traffic lights are controlled by vehicles. Vehicles are divided into groups according to their dynamic attributes such as their location or direction. In these groups, every vehicle votes for the time of signal change and their agreement along with other related messages are encrypted and then recorded to blockchain. The procedure to reach an agreement is divided into four phases: (1) The setup phase
, where public parameters are generated using ciphertext policy attribute-based encryption (CP-ABE) and also verification of users’ identity is done. (2) The drafting phase
, where a proposer chooses a voting group according to vehicles’ attributes and poses a suggestion for signal control. A fixed number of voters is needed to reach an agreement. The threshold value is decided and stays unchangeable in next phases. (3) The reply phase
where a number of voters reply in order to reach an agreement. The voters verify signatures and send their replies to a recorder who appends those as records into blockchain. (4) The decision phase
, the proposer collects all replies, decrypts their ciphertext and after checking the pseudonyms and signatures or double entries, if the number of voters is the expected, he sends the decision record to the recorder; otherwise, he continues collecting votes. Consequently, the recorder, which does not know the real identities of proposers and voters, records the agreement to blockchain by performing a cooperation consensus algorithm.
In SCTSC, vehicles communicate with each other through blockchain and not directly. Other groups or traffic signal controllers can receive this final agreement without breach of users’ privacy. This is achieved due to the anonymity of users who use pseudonyms during communication process. Authentication centre is responsible for verifying users’ actual identities and distributing keys and pseudonyms but cannot decline any user. Trace manager is responsible for detecting malicious users by querying their pseudonyms in authentication centre. In addition, intermediate messages and other contents cannot be read by third parties outside those groups, thus privacy is also preserved inside the groups. Through extensive experiments and security analysis, the authors proved that SCTSC is feasible and effective.
Wang et al. [44
] suggested a framework, called CFTM, which describes the monitoring of road conditions by using cloud-fog computing for location and data privacy. In this scheme, vehicles signcrypt messages by using certificateless aggregation singcryption (CLAS) technology and then send them to RSUs which act as fog servers and also verify if the vehicle user is legal or malicious. Single verification is performed in the case of one sent message and aggregation of signatures parts of multiple ciphertexts in the case of multiple messages. Afterwards, the aggregated signature is sent to a cloud server for verification and then transmitted in ciphertext format to the blockchain. A root authority decrypts and verifies the ciphertext on the blockchain in order to respond in situations of emergency.
In CFTM, The privacy and anonymity of vehicles are ensured as they are using pseudonyms during communication procedure. Only the traceability authority, which is responsible for generating pseudonyms for vehicles, knows their real identity. Thus, the identity of vehicles is protected. In addition, while communicating, signcryption is used, so the transferred data is in a ciphertext format and cannot be decrypted by fog server, nor cloud server or malicious users. Furthermore, the cloud server carries on the ciphertext equivalent test process and sends the ciphertext, which exceeds the threshold to the blockchain. The ciphertext cannot be modified or deleted after being added to the blockchain; therefore, road condition information and sensitive information of users remain immutable and are secured from malicious behaviours. Moreover, as traceability authority can trace the real vehicles’ identity, it is easy to find malicious users. Formal security analysis of the proposed model and extensive comparisons with other existing models have shown that it satisfies the security requirements and works efficiently.
Wanxin Li et al. [45
] addressed the problem of traversing between different blockchain networks, preserving the privacy of the vehicles. To achieve the above, they propose a gateway system with non-interactive zero knowledge range proof scheme (ZKRP). When a vehicle wants to leave a network and enter another’s territory, it encrypts its information with the proposed ZKRP and broadcasts the request to the nearby gateway. Upon request receipt, the gateway validates the request and the vehicle connects to the new permissioned blockchain network based on Hyperledger Fabric, with the ability to start sharing data. The authors have built and tested a prototype, which shows data integrity and vehicle privacy can be maintained while switching networks.
Bohan Li et al. [46
] proposed a location cloaking system in VANET based on a dual-layer permissionless blockchain. Their system consists of vehicles which are the users, RAs, which are responsible to register, update or revoke the vehicle’s certification and store the certifications on blockchain layer named CerBC. The certificate acts as a pseudonym for the vehicles. RSUs are responsible to manage vehicle’s requests and form the clocking region with k-anonymity algorithm. Moreover, they are responsible to forward the requests to LSP. In addition, they maintain the requests of another layer blockchain named ReqBC. The LSPs are responsible to process the query requests using the query algorithm and return the queries to RSUs. LSPs do not interact directly with the users and users do not interact directly with each other. The system uses a trust reputation system based on vehicle’s Querying reasonability, from space and from frequency, plus, rationally and authenticity of location information. In summary, the privacy preserved with no direct communication between entities, certifications which act as pseudonyms and cloaking location with clustering
vehicles. Experiments were made in Hyperledger Fabric using PBFT consensus protocol and ECC for the cryptographic algorithm. The results show that the system can preserve privacy.
Feng et al. [47
] proposed an identity and location privacy scheme called Trusted Cloaking Area Construction (TCAC). Using k-anonymity [63
], a well-known privacy technique and a trusted third-party entity, called anonymiser, can expand the precise location area of one vehicle to a circle location, with addition of
vehicles as cooperative vehicles, concealing the actual location of the vehicle. The designed architecture is composed by three layers. The first layer is the permissioned blockchain architecture where a set of anonymisers take the place of the miners and maintain a blockchain consortium. On the second layer, between blockchain and Vehicles, are deployed the RSUs, to serve as intermediate nodes, to help collect data and for trusting evaluation. Finally, in the third layer, we found the users (vehicles) where they can broadcast or receive location relative information, within a small area. To achieve the data immutability and trust, only anonymiser can propose a block. The anonymiser sends his proposal to anonymiser president, who is being elected by timestamp voting and who is in charge of validating a block. If the president validated a block, then he added it to the chain, based on the timestamp, and broadcasted it to the network. The difference between the traditional blocks is that the TCAC block header includes more information, such as the ID of the anonymiser that proposed the block, the signature of Merkle tree root added by anonymiser, the ID of a vehicle that sends request based on its current location, the ID of cooperative vehicles set, the number of the location information, marked as true, false or rejected, of the particular vehicle and the block ID with the most recent change in location information status. Moreover, the authors to avoid chain load have created a redundant block deletion strategy, where blocks, based on the number of the recorded data, are considered to be deleted.
In TCAC, when a vehicle inserts the anonymiser’s area, it gets a pseudonym and when a vehicle broadcasts location related data, the anonymiser choose more nearby vehicles, based on the vehicle’s reputation, to perform the location cloak and preserve the privacy of the broadcaster. If the anonymiser finds that the broadcast is made outside of his area, it flags the transmission as false and lowers the vehicle’s reputation; in contrast, when the transmission is legit it increases the reputation of the vehicle. Additionally, if a region is populated by one anonymiser, it can be easy for an attacker to find the vehicle’s location; for that reason more than two anonymisers must overlap each other’s region in order to form a region-cross cloaking area. Finally, the authors have contacted a python simulation between their scheme and a traditional cloaking area construction system and their proposal performed better in detection of dishonest vehicles and false alarms.
Chaudhary and Singh [48
] proposed a location and identity privacy scheme for VANET called BELP. The proposed system consists of a Registered Authority (RA), the users (vehicles) and RSUs. When a vehicle enters an RSU territory, it sends a join request to the nearest RA and RSU. RA is responsible to determine if the vehicle is eligible to join the network, using smart contract pre-made rules. If the vehicle is qualified by the rules, RA index the vehicle with a pseudonym. All the data will be registered into the federated blockchain by all RAs. Vehicles that participate in the network can exchange information using their pseudonyms. To preserve the location privacy and to avoid traceability, at any time a vehicle can change its pseudonym using random encryption period. When a pseudonym change occurs, it is mandatory that the vehicles are not less that two and the vehicle should change its speed and direction. Simulation in OPNET indicates that the proposed system preserves the identity and location privacy efficiently.
6.3. Data Exchange
There have been several research works which aimed to provide efficient data exchange, while ensuring privacy between users and between users and infrastructure in IoV, and they are presented below.
Shi et al. [49
] proposed a scheme that focused in multimedia data sharing and threat management in vehicular system using blockchain. In this model, the participants involved are electric vehicles (EV) and their users, Roadside Units (RSUs), Trust Authority (TA) and a permisionless blockchain based on Ethereum. At the time of system initialisation, the Trust Authority identifies the entities involved and distributes their keys. The registration takes place as described: Vehicles’ users or RSUs send their personal identities to the TA which generates a unique identity for each of them by performing a pseudo-random function and also a key pair by using a key generation algorithm. Furthermore, a hash chain is generated for each participant in order to be used in multimedia sharing authentication phase. Afterwards, the association relationship between each participant’s (users and RSUs) identity and his public key is published to blockchain by the TA which also saves the connection between the users and their vehicles locally. Afterwards, TA stays offline, thus it does not have any influence to the decentralisation of blockchain. RSUs are considered as the full nodes which record on the blockchain registration and communication data among the vehicular system. Each entity that wants to share data firstly connects with the nearest RSU through his hash chain and afterwards calculates the hash value of the multimedia data, records the timestamp and signs those data which are then sent to the RSU. The RSU is responsible for verifying those data and updating the blockchain with the new transactions. Finally, a connection between the RSU and the receiver of the data is established, in order to send the shared data to him.
During multimedia data sharing, users use pseudonyms to communicate with each other. The association between each entity’s pseudonym (ID) and its personal data is known only by TA. The real identity of the participants and their sharing information is hidden through cryptographical primitives, so attackers cannot gain personal information and communication data. Furthermore, because every entity must be registered by the TA, unauthorised users who do not own keys and pseudonyms cannot communicate with others. In addition, malicious users trying to share illegal data are tracked and punished by TA. Therefore, the anonymous environment prevents the privacy of involved users, helps tracing malicious behaviour and also ensures the integrity and reliability of shared data. The blockchain adopted to test system’s performance is Ethereum and according to the evaluation results the integrity of data is efficiently ensured while also protecting the privacy of the users involved.
A cognitive engine can be added to improve the intelligence of traditional IoV. In addition, technologies like artificial intelligence and cloud/edge computing can be used to create an intelligent vehicular system. Therefore, Cognitive Internet of Vehicles (CIoV) have been developed to upgrade intelligence, security and safety of vehicular system by mining significant information from the network and from the environment [51
]. Experiments have been conducted on Ethereum chain to evaluate the system’s performance and prove that the proposed scheme achieves privacy protection.
Lu et al. [50
] proposed a scenario of using a hybrid blockchain architecture named PermiDAG, which is based on federated learning, in order to ensure data transmission in IoV. In the asynchronous learning proposed, the aggregation slot is divided into local and global aggregations. Vehicles run the local Directed Acyclic Graph (DAG) for local training and shared update models in federated learning while RSUs maintain the main permissioned blockchain for global aggregation. DAG is updated asynchronously by vehicles and is periodically synchronised to the main blockchain. Two types of transactions are recorded to the main blockchain: data sharing between vehicles and the summary of transactions in DAG. In order to ensure the quality and integrity of shared information, verification is carried out in two stages, firstly by vehicles involved in local DAG and afterwards by RSUs in the main blockchain. Deep Reinforcement Learning (DRL) and Deep Deterministic Policy Gradient (DDPG) algorithms are used to select vehicles with most resources, which act as verifiers in blockchain network. The consensus algorithm used in blockchain is Delegated-Proof-of-Stake (DPoS). Blockchain and federated learning are used to protect the vehicles’ privacy and to utilise the limited resources. Through evaluation of the model’s performance and comparison with other two baseline methods, the authors have proved that the proposed model is accurate and efficient.
Qian et al. [51
] proposed a privacy-aware content caching architecture in CIoV based on blockchain technology. This model is separated into three layers: the first one is the vehicles, which have several sensors to collect data and upload them to the cloud. The second layer is the RSUs, which cover different geographical areas and provide data to nearby vehicles. The third layer is remote-cloud-based providers and cognitive engines which can perceive and analyse vehicles’ needs so that content is provided according to vehicles’ needs. Deep learning and machine learning algorithms are used to improve the procedures of analysing and perceiving the vehicles’ needs. The vehicles and RSUs willing to provide contents cache the contents and then broadcast them along with the specific download time according to the needs of other vehicles. Surrounding vehicles download those contents that match to their needs via V2V or V2R communication. Thus, vehicles do not submit their content requirements when they need information, but they download the content most suitable to their needs. Therefore, no personal information is uploaded and thus the privacy of vehicles is protected. Vehicles can serve as a content provider or content receiver and can also change their role at any time. As content receivers they must pay a fee to receive contents. Experimental results have shown that the proposed scheme has high cache rate and robustness but the type of blockchain is not mentioned.
Vehicles’ privacy is protected, because they do not need to submit requests with their own privacy information and content requirements to RSUs when willing to receive data. In addition, because vehicles and RSUs do not trust each other, blockchain technology is used in order to protect the security and privacy of involved vehicles. Completed contents sharing are recorded as transactions by RSU and cognitive engine. RSU generates the new block which records the latest content transactions and then broadcasts those transactions to other RSUs which confirm the transactions ensuring their safety and immutability. The main characteristics of this architecture are more intelligent content requirement analysis and secure and flexible content access in shorter response time.
Zhaofeg et al. [52
] proposed a data sharing scheme in IoV driven by blockchain technology called IoVChain. The system consists of two entities: the RSUs and the vehicles. The RSUs maintain a consortium blockchain and can host public or private data exchanged between the vehicles. Public data can be the weather or road conditions and private data could be vehicle’s speed or location. The vehicles can register to the network by the RSUs, invoking a smart contract and checking the vehicles key card that holds its real information, acting as a pseudo ID. IoVChain is based on permissioned Hyperledger Fabric and take advantage of Fabric’s technology called channels. Only members of a channel can read and write on the channel’s ledger. Users can join multiple channels. Simulating the system points out that zero knowledge protocol and homomorphic encryption combined with Fabric’s channels can preserve user’s privacy.
Joshi et al. [13
] proposed a data transmission system for VANET called ROAC-B, with all data registered on a permissionless blockchain and the vehicles forming clusters. The proposal is using clustering to protect the privacy of the vehicle’s data transmission. The cluster is formed using the rainfall optimisation algorithm (ROA) and based on various characteristics such as the vehicle’s speed and position. The proposed scheme has been simulated in NS-2 and SUMO proving that the ROAC-B technique is better that others.
Liu et al. [53
] proposed CPHAS, a heterogeneous aggregate signcryption between Certificateless Cryptosystem (CLC) and Public Key Infrastructure (PKI), and based on that, a protocol for traffic data sharing that uses cloud storage. During system initialisation, Transportation Management Centre (TMC) generates real identity RID and password PWD of each vehicle and store RID and PWD in vehicle’s On-Board Unit (OBU). A tamper-resistant device is responsible for checking if a vehicle’s RID and PWD are valid in order to generate a pseudonym for that with limited validity time. Afterwards, the vehicle validates its pseudonym and calculates its public and private keys. Likewise, RSUs generate their public and private keys which are sent to TMC for validation. A vehicle can upload data, only after a cloud server confirm its validity. After the verification, a signcryption ciphertext is created by the vehicle and then is sent to the nearest RSU which collects all ciphertexts, verifies their validity and transmit them to the cloud server, which saves those data in the database, in case of a valid signature. Then, the storage address of data is encrypted by the cloud server and is sent to the vehicle through the RSU. Furthermore, a metadata index created by the vehicle is sent to the nearest RSU which accumulates all messages in a set and transmits it into the network, where a block is generated and added to the permissionless blockchain. During data sharing, if the requester belongs to the access control list of the vehicle, he sends a request to the blockchain and then, the data storage address is encrypted and returned by the smart contract. Afterwards, this address is sent to the cloud server which returns the ciphertext, if all the required conditions are met, to the requester who can decrypt it. Meanwhile, a block representing the data sharing process is generated and added to the blockchain. On the other hand, if the requester does not belong to vehicle’s access control list, he must pay an amount of money as reward to the vehicle. After a period of time, if the identity of the applicant is recorded in the list, the money is transferred to the owner’s account; otherwise, it is returned to the original account. If the vehicle is willing to share data for a long period of time, the ciphertext is updated by cloud server and a new smart contract is applied. After receiving traffic data, the money is transferred to the appropriate vehicle’s account. Whether a vehicle no longer wishes to share information, a transaction is written in blockchain and vehicle can redeem its money. Two lists of malicious vehicles are maintained by RSUs: a warning list holding information for illegal vehicles and revocation list for vehicles that have violated the law several times which are excluded from any transaction. The authors claim that vehicle’s privacy is protected because pseudonyms are used in all procedures of data sharing and communication with blockchain, thus the true identity of vehicles is kept hidden from third parties. Simulation confirmed that their proposed protocol can reduce time and computational consumption by simulating it in Linux.
BEIoV-EC, proposed by Mei et al. [54
], is a blockchain enabled IoV system divided into three layers and it consists of four entities. A Trust Authority (TA) is responsible to register Vehicles (users) with a unique VIN code. This code is the vehicle’s one-time multiple pseudonym to protect its real identity, allowing it to participate in the network and enjoy its benefits. Moreover, to boost privacy, nearby vehicles will form a cluster and a cluster leader will be selected dynamically by smart contract and identity-based aggregate signature. The cluster leader will take the role of proxy between the cluster and the RSUs scattered across the road. Similar, to vehicle clusters, RSUs will form their cluster named Edge Services Cluster (ESC) where the permissioned blockchains are deployed; these clusters are providing computing power and temporary storage capabilities to vehicles. The ESCs are manageable by TA via a cloud server in the cloud layer. In the vehicular layer, vehicles will exchange information between them and the RSUs; all transmissions will be stored in RSU blockchain in the edge layer. Finally, TA will keep a reputation system of the vehicles and has the ability to track the real identity of malicious vehicles. Based on simulation experiments, the authors simulate their proposal on OMNet++ and prove that it meets security requirements and is a feasible solution in IoV.
6.4. Dynamic Navigation
The following research works aim to provide dynamic navigation services in IoV and also to ensure the privacy of participants.
Decoster et al. [55
] presented HACIT, a system for traffic avoidance and dynamic navigation in VANET, which also can securely store data from vehicles and traffic. The proposed system uses permissioned Hyperledger Fabric as the blockchain technology and takes advantage of the chaincode (Hyperledger Fabric’s smart contract) used as pseudonym in combination with blockchain cryptomaterial, to preserve user’s and data privacy. HACIT is using a well-known technology to achieve all of the above. Firstly, a Raspberry Pi 3 model B is installed in each vehicle. The bipolar antennas of Raspberry Pi enable ad-hoc network capabilities and vehicles can communicate with each other or can be connected to the Internet. Raspberry Pi uses the GRCBox framework for the wireless communications. Every vehicle calculates the shortest path of a weighted graph, using the Dijkstra algorithm and stores it in a database alongside with other useful data such as the average speed, the road ID and timestamp. The concept is that, when a vehicle joins a network, it transmits the database to any other node. The information that is stored in the database can help other vehicles to determine traffic and reroute course to avoid a dense one. All the above data for security and privacy are stored in a blockchain network which uses asymmetric encryption. Especially, HACIT is using the Hyperledger Fabric framework as blockchain technology, taking advantage of the unique techniques, such as chaincode (smart contract), and no use of Proof-of-Work, which make the transactions fast and secure. Vehicles are using two Wi-Fi interfaces for network and internet communication. They store a weight graph which represents the roads and calculates the shortest path by using the Dijkstra algorithm. The graph is also used for rerouting process. All data are stored in local database and transmitted to all nodes when the vehicle connects to the network. To avoid network overload during dense traffic the system uses the 1-hop broadcasting scheme. Authors did not provide any evaluation methods and supported their privacy preserving methods in python simulation.
] is an improved version of HACIT [55
]. It keeps the same basic infrastructure with some differences. As its predecessor, it uses a Raspberry Pi for the communication and the Hyperledger Fabric as the blockchain technology to maintain the privacy. The basic difference from the prototype is the distinction of the traffic congestion detector client and dynamic navigation rerouting server. The first module is in charge of detecting traffic jam and logs the speed changes to the distributed ledger. The second module listens to the ledger changers and takes advantage of the information to recalculate the route based on the given data. The vehicle needs an android device and app in order to run and maintain the Hyperledger Fabric network. Moreover, a connection to the internet is a prerequisite. Through the app, the nodes exchange traffic messages and every vehicle reroutes based on shared information. The authors did not refer to any evaluation method but they supported their privacy-preserving aspect to Hyperledger Fabric’s Zero Knowledge technology.
Mapping plays a significant role in many vehicular services such as location, navigation and transportation. Digital maps designed for that purpose are mainly based on satellite images and do not represent latest map information. In contrast, vehicle maps must be continually updated so that they effectively represent the traffic situation and navigation on vehicular networks which are constantly changing. Lai et al. [57
] proposed a scheme, called SPIR, which was designed to solve this problem. The authors tried to figure out a secure and privacy-preserving solution for real-time maps updates by using permissioned blockchain. The proposed scheme achieves payment control for map service platform (MPS) and also assures completion quality for vehicle users so that benefits of MPS can be maximised. The main entities of SPIR are the certification authority (CA), the pseudonym CA (PCA), the map service platform (MPS), the trace manager (TM) and vehicle users. In this suggested model, when MSP is interested in information relevant to road conditions, it publishes the type of needed data. Then, vehicle users bid to provide the required data that fulfils MPS’s requirements. Afterwards, the MSP defines a winner according to its budget and vehicle user’s quotation and this winner provides the exchange data with a reward. Blockchain technology is used to support the payment system so that it is safe and secure.
In SPIR, the privacy of vehicle users is protected, as pseudonyms are used to provide anonymity and to protect the identity of users while communicating with MSP. CAs verify users’ identities and sign pseudonyms submitted by them, while not knowing the content of signed pseudonyms due to adoption of the randomised RSA-based partially blind signature technique. In addition, PCA is not aware of the real identity of vehicle users but verifies the validity of the signature of their pseudonyms. Furthermore, TM which does not participate in the processes of signature publication and verification, can trace malicious users, find the real identity from their pseudonyms and inform CA which sustain a credit account for each user to record his real identity and credit value. The use of blockchain prevents malicious behaviours, as it assists in subtracting credits from malicious vehicles and informing CA via blockchain for recent changes. In their next attempt to register, CA after checking their account refuses their registration, and thus, the system is safe. Moreover, fake pseudonyms and certificates, not related to any vehicle user’s identity, cannot tamper with the real users’ identity if CA is attacked. Lastly, vehicle users can change their pseudonyms whenever they want, without making it easy for others to predict the next pseudonym change. Results of theoretical analysis and simulations in Matlab and PEPA have shown that SPIR guarantees the security and reliability of data in real-time map updates without leaking of private information and also that vehicles and MSPs will effectively receive fair rewards or budgets.
6.5. Vehicle Reputation Services
The following research works aim to provide trust and reputation in vehicular networks and at the same time to maintain privacy.
The Blockchain-based anonymous reputation system (BARS) [58
], as the name implies, is a proposed message broadcast system for VANET. The main entities of the system are the vehicles which basically are the users, the Law Enforcement Authority (LEA), which is in charge of the vehicle registration, the behaviour and evaluation of the scores and the RSU, which are responsible for message transmission and for blockchain records too. There are three prerequisites for BARS to work efficiently. Firstly, the cryptographic material must be secure as public keys act as a pseudonym. Secondly, LEA can securely keep the dataset. Thirdly, the authority and RSU have all the appropriate computer power and there is no possibility of half of the users being compromised. BARS consists of three permissionless blockchains, blockchain for messages (MesBC) where the messages are stored, blockchain for certificate (CerBC) where all the certificates are stored and blockchain for revoked public keys (RevBC) where all the revoked public keys are stored, and it acts and as Proof-of-Absence too. The basic idea of BARS is that every vehicle/user can transmit three types of messages: (1) when it loses control, (2) when it alerts nearby vehicles before changing its driving status and (3) when poor road conditions are detected. When a message is broadcasted, LEA is responsible to evaluate the message. If the message is authentic the reputation score of the user transmitted increases and when a false message is detected, the reputation score of the user decreases. The messages have weights, thus more important messages give more reputation score and in contrary messages with very negative effect decrease reputation score. Finally, an informal security analysis is provided and the proposed system was tested in a Python environment to evaluate its performance.
Ma et al. [1
] proposed a privacy-preserving reputation-based blockchain system in VANETs. This solution uses two-layer blockchain, permissioned intrachain and permissionless interchain. Intrachain is installed inside the vehicle including sensors, actuators, smartphones, etc. This private blockchain network, due to the sensitive data that it includes, must use cryptographic algorithms for the communications. For that reason, the central manager of the vehicle will store the data into the blockchain according to vehicle owner. Interchain is a public ledger that includes the vehicle and the RSU for their communication between each other and between infrastructure. Every vehicle can request or provide data to the ledger in order to prevent accidents or to inform for traffic jams. Additionally, it adopts a hierarchical structure in order to provide flexible control and to optimise resource consumption. The network consists of RSUs, where the blockchain is stored. They act as full nodes and they are responsible for block generation and reputation consensus. Moreover, they monitor the traffic conditions and supervise the vehicles. The vehicles are basically the users, which are responsible to interact with RSUs and other vehicles, exchanging messages relative to road conditions. Based on these messages they gain or lose reputation. Sensors and actuators gather all the necessary information for the vehicles. Lastly, Cloud server also participates in the network, whose main purpose is to backup the blockchain data.
To ensure the stability and availability of the system, a novel consensus protocol is proposed based on Delegated-Proof-of-Stake (DPoS), for better management of the reputation and the avoidance of malicious vehicles. Finally, the evaluation of the system proves the security of the framework. Evaluation has been made by observing malicious nodes in three scenarios. The observations of results of no reputation system, random rating reputation system and the proposed system using Matlab simulation show that the proposed system can guarantee the accuracy, security and privacy preservation of the framework.
Malik et al. [59
] proposed a reputation system that uses permissioned blockchain technology. It consists of three phases: (1) Registration of the vehicle: uses Proof-of-Authority consensus algorithm to add the vehicle into the blockchain with pseudonym. (2) Reputation evaluation: where the reputed nodes verify the vehicle’s messages and store a local copy of them. (3) Reputation update and query: the reputation algorithm is used to choose the nearest most reputed nodes in order to validate the requested vehicle. The entities that participate in the network are motor vehicle division (MVD), Law enforcement authority (LEA), light IPFS vehicles (LIV), Reputable IPFS vehicles (RIV) and edge nodes (RSU). MVD is a vehicle with valid Electronic license plate number (ELP), while Law enforcement authority provides the blockchain platform and the reputation management and runs the smart contracts to ensure traceability and avoid malicious nodes. Light IPFS vehicles are regular vehicles with the difference that they do not have accessibility to the ledger but they can query other nodes. Reputable IPFS vehicles have verified and proven functionality through honest message delivery and gain reputation as being trusted across the network. RSUs act as miners as they have the computation power, they mine and they validate transactions.
The data structure of the network consists of: (i) Registration smart contract: it is triggered in order to add validated and authorised users to the registration and authentication ledger. That includes adding new users or update old entries. The transactions are verified by the MVD and LEA. (ii) Reputation smart contract: LIVs can run these contracts to put their reputation scores in their respective IPFS objects. (iii) The Repuchain: a private ledger for vehicle management, running Proof-of-Authority and Proof-of-Reputations consensus algorithms. (iv) Off-chain event information storage: it stores details of informing and emergency event information about the vehicles. (v) Reputation review storage: it stores the reviews of vehicles in order to use them as evaluation of the final rating. (vi) RepuWallet: it represents the users’ wallet, where the public/private key, reputation scores and reward points are stored.
Running the network, there are two assumptions. Firstly, The LEA and MVD are trusted parties and RSUs are the demarcation point for different networks. Secondly, RIVs are vehicles with high reputation score, so the can ensure the trust and transparency among the other vehicles. In the Repuchain, there are two types of messages that are broadcasted, (1) regular messages, such as a bad driving behaviour, and (2) emergency messages, such as messages that warn other vehicles for a possible accident. The messages are collected by the nearby vehicles and transmitted over the network for evaluation. The evaluation criteria are the vehicle’s location details retrieved from RSU and querying nearby vehicles for reputation and if similar message has been transmitted. As the evaluation is successful, reputation points are gained and stored in user’s wallet. Security evaluation, made by theoretical proofs and testing on four vehicles, for over 90 h, using Matlab simulation have shown that the reputation increased for trust entities and decreased reputation for entities broadcasting fake messages, but it does not enhance privacy in any aspect.
6.6. General Services
Here are two general solutions that promise to provide privacy protection in blockchain-enabled IoV.
Hui Li et al. [3
] proposed a general decentralised architecture for VANET aiming to protect identity and location privacy. The system is starting with the initialisation of the blockchain network, where the edge nodes, which are the nodes that run the smart contracts and participate in the consensus, are equal and enjoy the same rights and obligations. Then, the registration process occurs where a Certification Authority server, through smart contracts, validates a vehicle into the blockchain network. If the validation fails, the details are recorded in a block and broadcasted to the network, so that all participants are warned.
To protect the identity and the location of vehicles during message broadcasting, the proposed system adopts the k-anonymity unity. When a vehicle is ready to transmit a message, with the help of an RSU it forms a group with the nearby vehicles, then selects other sub-identities including his own and all the messages are uploaded together, so the server of the core network cannot identify the location and the identity of the vehicle. Every message is considered as a transaction and recorded in the blockchain network. After the transmission of the message, the agent broadcasts the block to all nodes and using practical byzantine fault tolerance as consensus algorithm, the transactions are validated. The validated blocks are stored on every node. To be protected against any thread, this system uses undirected graph generation algorithm for privacy protection of the vehicles, a way of dynamic threshold encryption to protect the vehicular identity and the k-anonymity unity to protect location privacy. The security evaluation performed in simulation environment using OPNET and Ethereum. As a result of the evaluation, the proposed system seems to be faster than the commodity blockchain solutions and the location privacy greatly improved.
Yuhong Li et al. [60
] proposed an intelligent transportation system, called Ba-ITS, based on permissioned Blockchain technology that aims to provide different vehicular services. The proposed structure consists of three layers called ITS network infrastructure layer, cloud computing and service provisioning layer and blockchain overlay layer. Aiming to concentrate only in data of a certain area, three layers of private hierarchical blockchains are used, called vehicle-chain (V-chain), RSU-chain (R-chain) and gateway-chain.
Vehicle-chain consists of vehicles and RSUs in order to upload or obtain data and services. RSU-chain consists of RSUs and the gateway in which they are connected and its purpose is to synchronise data from different vehicle-chains. The gateway-chain aims to ensure data exchange among different gateways and has the highest priority in the network as it maintains all data. The main components of gateway-chain are a gateway, server nodes and a router. Some nodes participate in several chains in order to synchronise data between them. When exchanging data, vehicles collect data using sensors and upload them to the system in order to inform other vehicles for road conditions, and as a reward they gain some points which they can use in the future to request data or services. In services such as route planning, in contrast with traditional navigation services where location information of vehicles are collected and stored, in this proposed model, root is performed by a smart contract. Therefore, private information of users are protected. In addition, data exchanges involve only blockchain address of vehicles, thus no personal data is provided. Moreover, smart contract and transactions support data exchanging and other services, ensuring that privacy is better protected. Furthermore, the privacy is implemented by using private chains with access control and by encrypting the data stored in V-chain. The authors implemented their model using Ethereum Blockchain. They also used Ganache to generate participants’ accounts, Truffle to develop the application which connects drivers with blockchain, Solidity to implement the smart contracts and JSON-RPC API and Web3 library to interact with blockchain. OSM and SUMO have also been used to simulate data transmission and route planning in the proposed system. From the simulation results, the authors ensure the feasibility of the proposed model claiming that the estimated response time is satisfying and that the most time is spent to add data to the ledger.
Wang et al. [61
] proposed an IoV block-streaming service awareness and trusted verification scheme in 6G. As wireless technology advances and offers high bandwidth and low latency with the forthcoming 6G [65
], it opens up opportunities for more services to be available in IoV, such as short videos and online games. Despite this, there are devices that have limited storage capability. To this end, the authors proposed a scheme where the offered services are divided into microservices (or blocks) [66
] and only the requested block will be streamed to users, thus saving storage space and bandwidth, as it does not require downloading the entire service. The proposed scheme is divided into three layers: the central cloud layer, the edge layer and the terminal layer. In the central cloud layer, there are high-performance, super storage-capable servers that are responsible for large-scale computing and mass data storage. In the edge layer, there are roadside units and base stations that are scattered in various locations. At this layer the blockchain is deployed and is the interface between the cloud servers and the users, where the users form the terminal layer. The proposed scheme is based on Hyperledger Fabric with Proof-of-Authority (PoA) consensus. Each edge server has to submit a registration request for authorisation in order to join the network. To protect the privacy of the participants, the proposed scheme uses a suite of encryption protocols in Hyperledger Fabric, called Identity Mixer, which provides anonymity and unlinkability using zero-knowledge proofs. Additionally, the divided service function blocks as well as the service call graphs are stored in the blockchain by the service provider. All interaction between edge servers and users is recorded in the blockchain utilising its non-tampering and traceability characteristics. Users do not reveal their identity by requesting a service from providers applying the technique of blind signatures. After the request, the edger server verifies the rationality of the microservice using the blockchain network. Moreover, users can verify that the requested microservice is legitimate by comparing the service hash with the hash stored in the blockchain. In addition, to improve the cache hit rate, the proposed scheme uses an edge cache replacement mechanism (ECRM). The proposed scheme is theoretically analysed using an informal security analysis and tested in Hyperledger Fabric; the data traffic performance has been simulated in Matlab.