# Privacy-Preserving Solutions in Blockchain-Enabled Internet of Vehicles
## 6 Privacy-Preserving Blockchain-Based Solutions
### Authentication
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 \(H_{0}\) is the vehicle pseudonym and public key and \(H_{1}\) is the relationship between the vehicle's real identity and pseudonym. The \(H_{0}\) function is stored in a Cloud server and the \(H_{1}\) 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 \(H_{0}\), 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. [PERSON] 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.