# Blockchain-Based Authentication in Internet of Vehicles: A Survey
## 4 Blockchain-Based Authentication Schemes in Vehicular Networks
### Private Blockchain-Based Authentication Protocols
The pointer P is then broadcasted to all TAs which jointly pack it into a new block and link it to the previous block in the chain. The authentication phase has five steps. In the first step, the VN enters the RSU communication range and issues an authentication request to the RSU. Then, the RSU forwards a part of the request message to the TA in the second step asking for the VNrelated authentication parameters. In the third step, the TA executes the smart contract in the blockchain. It checks first whether P exists in the blockchain, then retrieves the VN-related authentication parameters from the DC according to P, and then sends these parameters to the RSU. Once the RSU successfully authenticates the TA and the VN, it sends the updated parameters to the VN and the TA in the fourth step. In the final step, after the TA successfully authenticates the RSU, it sends the updated parameters to the DC via the secure channel. Once the DC has updated the parameters, the TA sends acknowledgment message to the RSU. After the VN successfully authenticates the TA, it updates the authentication parameters in its memory. After the VN and the TA negotiate a session key, it remains valid as long as the VN lies within the communication range of the RSU. Once the VN leaves the communication range of the RSU, the session key will be revoked. A detailed security analysis is performed on the proposed scheme using ProVerif tool [114] to check its robustness against different security attacks. The results prove that the scheme can resist eavesdropping attack, replay attack, VN impersonation and VN capture attacks, TA and RSU spoofing attacks, and jamming attack. It also guarantees backward/forward secrecy and VN anonymity. The authors in [115] proposed a protocol termed as \"BlockAPP\" which serves for both authentication and privacy preservation of vehicles identities. The system architecture contains a registration server and multiple service providers. The registration server is responsible for validating and managing vehicles identities whereas the service providers perform the authentication process. The registration server can only write to the blockchain whereas the service providers have both read and write permissions on the blockchain. Further, two types of blocks are defined within their blockchain, i.e., one is created by the registration server to keep a log of the registered vehicles and the other is added by the service providers to keep track of the access history. The proposed scheme has three phases: the registration phase where the vehicles interact with the registration server, the authentication phase and the authorization phase which are handled by the different service providers. The registration phase starts when the vehicle sends a registration request message containing its original id (i.e., driver's license or vehicle registration number) to the registration center and then a key exchange process takes place using the Elliptic Curve Diffie Hellman (ECDH) key exchange protocol [116] to exchange their public keys. After which the registration server generates a pseudo id by encrypting the vehicle's original id with its session public key and sends it to the vehicle. Upon receiving an acknowledgement from the vehicle, the registration server adds a transaction with the vehicle-related information to the blockchain after validation. A vehicle then sends a message containing its pseudo id and the session parameters obtained from the previous phase to a service provider which authenticates the vehicle's identity by comparing the received data against the vehicle's information kept in the blockchain. If matched, the vehicle is successfully authenticated, and an access log transaction is added to the blockchain by the service provider. The vehicles can then apply for various services during the authorization phase by sending a service request message with the digital signature of the service.