# Blockchain-Based Authentication in Internet of Vehicles: A Survey
## 4 Blockchain-Based Authentication Schemes in Vehicular Networks
### Private Blockchain-Based Authentication Protocols
The use of pseudo ids for authentication instead of original ids while restricting their validity to only one session, not only protects the privacy of vehicles but also prevents the system from identity spoofing attacks. The authors in [117] suggested a secure mutual authentication scheme with reduced dependency on certification authority (CA) by introducing a private blockchain framework. In addition to vehicles, the physical entities involved in their model are the CA and the revocation authority (RA) which both have complete control over the blockchain. The RSUs, on the other hand, have only read permission over the blockchain. The scheme is composed of three phases, namely, system initialization, registration of the vehicles, and mutual identity authentication and revocation. In the first phase, the CA initializes the system parameters including the elliptic curve parameters and hashing functions. Moreover, the public key pairs are generated and transferred to the blockchainnetwork entities, i.e., CA, RA, and RSUs. When a vehicle first registers with the CA, it submits its original vehicle id obtained from the motor vehicle's division. The CA verifies the vehicle's original id and assigns for it a Pseudo Id (PID) along with the Elliptic Curve Cryptography (ECC) public-private key pair. The PID is then signed digitally by the CA using the Elliptic Curve Digital Signature Algorithm (ECDSA) [118], forming a new transaction which is added to the blockchain under the proof-of-authority consensus mechanism among the multiple CAs. When the vehicle's registration information, i.e., PID and the digital certificate, is added successfully to the blockchain, a pointer referring to its storage location in the blockchain along with a unique transaction id are sent back to the CA. At this point, the CA transfers the pointer, the PID, the certificate along with the ECC key pair to the vehicle's OBU. The CA also stores a record mapping the real identity of the vehicle to the Pseudo identity in the hash table in its local database which helps facilitate the lookup in the case of traceability and revocation of malicious vehicles. When the vehicle becomes active on the road, it initiates an authentication request containing its PID, hash pointer, and transaction id to the nearest RSU. The RSU then uses the received PID as an index to query the blockchain for the vehicle's respective transaction, if verified, the RSU sends a challenge message to the vehicle encrypted with its public key and waits for the reply. If the vehicle successfully decrypts the challenge message and sends the correct response, it is authenticated successfully by the RSU. Extensive simulation using Vein's framework and OMNeT++ network simulator proves the efficiency of this scheme in terms of authentication delay, transaction throughput, and packet-delivery ratio. The authors in [119] proposed a distributed message authentication scheme using a private blockchain, where vehicles can authenticate the messages broadcasted in the network in a distributed manner. The system model is composed of a single Root Trusted Authority (RTA), multiple Local Trusted Authorities (LTAs), RSUs, and vehicles. The RTA is a fully trusted authority that is responsible for managing the entire system and performing the registration process whereas the individual LTAs are responsible for authenticating the vehicles in their local areas. The authors define two types of nodes based on the task they perform on the blockchain, namely, block generation nodes and block verification nodes. The generation of blocks is performed through the proof-of-work consensus mechanism and is assigned to the infrastructure nodes, i.e., LTAs due to their high computing capability, while the verification of the blocks is the responsibility of the vehicles. Since the vehicles are highly mobile and have a relatively low computing power, the consensus during block verification must be completed quickly, and thus the use of the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism.