# Blockchain-Based Authentication in Internet of Vehicles: A Survey
## 4 Blockchain-Based Authentication Schemes in Vehicular Networks
### Public Blockchain-Based Authentication Protocols
Using the Automated Validation of Internet Security Protocols and Applications (AVISPA) simulation tool, the proposed BCAS-VADN proves to be secure against multiple attacks including replay, man-in-the-middle attacks, impersonation and privileged-insider attacks, physical vehicle capture attack, and ephemeral secret leakage attack. The authors in [125] introduced a scheme for securely authenticating the vehicles and the messages exchanged in the network using a public blockchain, called BCPPA. The scheme employs the Elliptic Curve Digital Signature Algorithm (ECDSA) but supports replacing it by an improved signature scheme to enable batch authentication. The BCPPA protocol consists of three phases: system initialization, message signing, and message verification. For improved security, the system initialization is performed by both the vehicles and the certificate authorities via the private-type derivation and the public-type derivation processes. The private-type derivation is performed by the vehicles to generate a root private key which is kept at the vehicle's OBU to be used later to derive a fresh private key for each future communication. A corresponding public key is also generated by the vehicle and sent to the certificate authority which uses it to generate the new public key and certificate in the public-type derivation process. The public blockchain is used in this scheme to store the public certificates which are embedded into the transactions so that the vehicles can obtain the certificates from the blockchain instead of preloading all of them in the OBUs, which helps mitigate the storage burden of the vehicles. In the message signing phase, a vehicle that needs to broadcast a message to other vehicles in the network must sign the message by first executing the private-type derivation to obtain the current private key and then triggering the smart contract to obtain the transaction id that keeps the public certificate corresponding to the generated private key. The receiver then verifies whether the received message/signature pair is valid or not, if valid, the received traffic is accepted, and decisions can be made based on it. Extensive simulation using Vanet-MobiSim and NS2 demonstrates that the proposed BCPPA can resist several attacks such as replay attack, impersonation attack, DDoS attack, man-in-the-middle attack, stolen verifier attack, side-channel attack, message modification attack, birthday collision attack, and hijacking attack. The authors claim good efficiency in terms of communication cost, time cost, average packet delay, and packet loss ratio. The authors in [126] proposed a lightweight Decentralized Key Management Mechanism with Blockchain (DB-KMM) and bivariate polynomial. The network model involves three types of entities: Vehicle Service Provider (VSP), Blockchain Network (BN), and the vehicles. The VSP is responsible for deploying the BN and the smart contract, issuing the transaction data, registering, updating, and invalidating the vehicles' public keys. The BN is constructed by the RSUs which are responsible for creating and mining the new blocks through the PoW consensus mechanism while providing public keys and services to the vehicles. The proposed DB-KMM is composed of six phases, namely, system setup, registration, authentication, key agreement, public key update, and public key revocation. In the system setup phase, the VSP derives the system parameters such as the ECDSA and the Elliptic Curve Integrated Encryption Scheme (ECIES) parameters, the bivariate function parameters as well as initializing the smart contract. Each vehicle that aims to join the VANETS network must register itself through the VSP which generates for it a pair of public and private keys while registering the public key in the smart contract. When a vehicle needs to communicate with other VANETS entities, it first mutually authenticates with the nearest RSU.