1. Introduction

The Internet of Vehicles (IoVs) modifies the most important aspect of transportation systems and has brought some changes to computing, which can better solve the problems of transportation systems in terms of safety, efficiency, and intelligence. Vehicle-to-Everything (V2X) communication (including Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communication) are at the core of future IoVs, and these networks are currently being expanded on top of classical Vehicular Ad Hoc Networks (VANETs) [1, 2]. These advancements pave the way for real-time information exchange between vehicles, infrastructure, and the cloud, underpinning essential applications such as self-driving vehicles, traffic optimization, and emergency notifications [3, 4]. Due to their open nature, vehicular communication networks are vulnerable to various security threats such as eavesdropping, data corruption, and attacks that compromise the confidentiality and availability of communication, etc.

A scalable and secure authentication scheme is one of the most challenging requirements for impactful communication security in IoVs [5]. The dynamic features of vehicular networks, such as high mobility, dynamic network topology, and limited resources, make it challenging for the existing security protocols [6, 7]. Centralized solutions are vulnerable to single points of failure and may not scale as necessary for massive-scale deployments of IoVs [8, 9]. Furthermore, conventional authentication schemes also introduce a high computational overhead that causes latency and inefficiency, degrading the performance of real-time Internet of Vehicles (IoV) applications.

These challenges find a promising solution with the decentralized, transparent, and tamper-proof nature of Blockchain technology. Blockchain provides a decentralized and secure ledger, ensuring message authenticity and integrity in IoV networks while eliminating reliance on a central authority. Moreover, consensus mechanisms on the blockchain support scalable authentication without involving significant computational capabilities, thus making blockchain technology ideally fit for use in the IoV ecosystem. Figure 1 shows the Internet of Vehicles (IoV) ecosystem with Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), Vehicle-to-Roadside Unit (V2R), and Vehicle-to-Grid (V2G) communications. This fig also highlights that cloud servers, trusted authority, and blockchain play a role in securing and managing communication in the case of IoV.

This paper presents a new Blockchain-Enabled Secure Authentication Protocol for IoVs (BESA-IOV). The proposed protocol exploits blockchain intelligent contract features with the aim of offering a lightweight, efficient, and secure authentication mechanism that reduces communication overhead and ensures data privacy and integrity. In this paper, we perform a comprehensive analysis of the BESA-IOV's performance against existing authentication protocols and show that it provides improved authentication delay, scalability, and security. We demonstrate that our proposed BESA-IOV is a promising approach for next-generation IoVs via simulation and experimental validation, increasing the trustworthiness and security of communication among vehicles in vehicular networks.

This manuscript contributes to the relevant details below:

The remaining part of the paper is structured as follows: Section II presents a detailed survey of vehicle authentication schemes in IoV systems, emphasizing their drawbacks and implications for enhanced solutions. Section III discusses the proposed Blockchain-Enabled Secure Authentication Protocol for IoVs (BESA-IOV), including its architecture and components. In Section IV, we provide a performance evaluation of the BESA-IOV protocol through simulations, as well as comparisons with existing IoV authentication schemes in terms of important aspects such as scalability, communication efficiency, and authentication delay. Lastly, Section V concludes the paper with the contributions and implications of the proposed protocol toward IoV security while also discussing future research directions for improving the scalability and security of blockchain-based authentication systems in vehicular networks.

2. Related Work

The Internet of Vehicles (IoVs) is one of the most promising applications of Internet of Things (IoT) technologies and causes a paradigm shift in the transportation domain toward improved safety, efficiency, and intelligence [10, 11]. Since IoVs allow interaction between vehicles, infrastructure, and other actors, guaranteeing secure communication has been one of the main issues [12]. The fact that only legitimate vehicles and infrastructure can send messages to each other and malicious agents are excluded from accessing the communication medium makes authentication one of the fundamental components for securing IoV systems.

Vehicular networks commonly utilize certificate-based authentication methods, with vehicles preloaded with digital certificates issued by a trusted authority [13], to verify the identity of the vehicles and secure communications [14, 15]. Certificates also incur considerable costs here because of the overhead to create, distribute, and verify certificates, representing a serious scalability challenge for certificate-based protocols [16]. Furthermore, they usually fail to respond to the changes in an IoV network where vehicles continuously enter and exit the network [17]. Some privacy-preserving authentication systems employ pseudonyms to protect vehicle identity in a cooperative communication environment [18]. But sure, these protocols enhance privacy, they're not without challenges, particularly in the management of securely updating pseudonyms to avoid identity correlation [19, 20]. However, these protocols face scalability issues and require further optimization, especially when it comes to large-scale IoV deployments.

Figure 1 Overview of IoV network architecture.

Identity-based approaches are another class of authentication mechanisms for IoVs. In these protocols, the identity of the communicating vehicle is used as a cryptographic key, which makes authentication straightforward and less overhead than traditional certificate-based methods [21, 22], these are simple protocols. However, they do have certain issues concerning the management and revocation of identities [23]. Identity-Based Authentication Systems can be exploited if not treated with monitoring attention.

Vehicular networks are resource-limited by nature; therefore, to reduce computing costs and communication latency, some lightweight authentication protocols are only expected to be executed at the vehicular nodes [24, 25]. VANET-AP and LAKA are two specific protocols designed to maximize efficiency while preserving security [26]. In these protocols, scalability is a challenge, especially in the context of a large number of vehicles in IoV [27]. In real-time IoV applications, lightweight protocols are still struggling to offer secure authentication under high traffic load conditions [28].

The new generation of authentication methods for IoVs depends heavily on blockchain technology thanks to its extensive adoption [29]. The secure conduct of IoV communication happens through blockchain technology, which provides decentralized, transparent, and immutable services. Blockchain authentication protocol NOTSA demonstrates how vehicles and network transactions retain secure information through distributed ledger verification [30]. The deployment of distributed systems allows security because it eliminates dependency on one trusted authority, thereby strengthening the network against attacks [31]. Centralized blockchain authentication systems, together with Cloud solutions, have limited applications because they require excessive amounts of computational power and energy usage, which prevents their use in resource-limited networks.

A decentralized trust model-based solution provided on the blockchain has been proposed to mitigate the scalability issues related to the centralized authentication mechanism [32, 33]. An example of such a model is the Blockchain-Based Authentication for the Internet of Vehicles (BBA-IoV) protocol, where the distributed ledger technology of Blockchain is utilized to provide authenticated access to vehicles and roadside units (RSUs) in a secure method through smart contracts [34]. Through the consensus mechanisms of blockchain, BBA-IoV is scalable without the requirement of server authentication. The computation overhead and energy consumption of blockchain are still a major concern in large-scale IoV networks. Moreover, privacy in a decentralized system is still challenging, especially in the sensitivity of vehicle data [35]. Recent studies on blockchain scalability and energy-efficient cryptographic techniques, such as [36, 37], highlight the necessity of optimizing blockchain implementations for resource-constrained environments. Our approach integrates these findings to ensure efficient cryptographic operations within IoV.

Tirupati et al. [38] proposed a two-part system, consisting of a vehicle registration module and a message alert module. To integrate new vehicles into the network, smart contracts have been established, which are linked to the wallets of the users. Blockchain promises to enforce secure authentication in IoVs, which led to several investigations that discuss its deployment into vehicular networks [39]. However, there are still some issues to overcome, one of the major problems is the amount of computational time that must be used for blockchain consensus algorithms, especially Proof of Work (PoW) [40]. This overhead may limit the scalability of blockchain-based solutions in vehicular environments. Integrating blockchain's transparency while also maintaining privacy and being compliant comes with major challenges. Blockchain-based IoV is still in the early stages of development, and hence, more attention needs to be given to privacy while ensuring the security features of the technology are not compromised.

Existing authentication protocols prove efficient for particular situations, and they lack proper solutions for the key characteristics of the IoVs, including high mobility and dynamic networks alongside scalability. Due to the present necessity, Blockchain emerges as a solution for developing an authentication system that offers decentralized security along with transparency. BESA-IOV must solve the problems which exist in existing solutions. Through its decentralized operation, BESA-IOV uses blockchain properties to make IoV security communications both speedy and scalable and maintain data privacy and transmission integrity.

3. Methodology

This section gives detailed information about the methodology of the proposed Blockchain Enabled Secure Authentication Protocol for IoVs (BESA-IOV). The protocol integrates blockchain technology for security, scalability, and efficiency within the IoV environment. The methodology consists of a comprehensive network model, adversary model, protocol design, and useful and practical performance evaluation metrics, offering a detailed understanding of how the protocol functions.

3.2 Adversary Model

A model of adversary refers to the potential malicious activities that would threaten the security of the IoV network. The adversary may try to hack into the network by leveraging flaws in the authentication protocol. The model considers the following potential attacks:

• Sybil Attack: In a Sybil attack where an attacker creates several fake identities (or vehicles) in the network to gain an advantage over other communication in the network. The decentralized nature of the blockchain and the process of public key registration make it difficult for an attacker to impersonate several vehicles without being detected, making contact with each vehicle precisely due to their unique identity.

• Man-in-the-Middle Attack (MITM): In MITM attack, an attacker listens in to messages that are approximately exchanged between vehicles or between vehicles and RSUs and may modify them. MITM attacks are mitigated due to the use of digital signatures for message authentication and encryption of messages w.r.t session keys, which allows only the real recipients to be able to read and verify the authenticity of the messages being exchanged.

• Replay Attack: An attacker eavesdrops on the end client's messages and re-sends them to a server. To prevent this, BESA-IOV incorporates a timeout mechanism that grants messages validity during a specific time window, rendering old messages unfeasible for replay. To prevent replay attacks, BESA-IOV employs a nonce-based challenge-response mechanism, making it impossible for an adversary to re-use old messages. Furthermore, a blockchain consensus-based node revocation strategy can prevent corrupt vehicles from joining IoV communications.

• Denial of Service (DoS): A malicious attacker could flood the network with invalid or unnecessary requests, consuming the network resources and compromising the communication. Its decentralized architecture and vehicular authentication process minimize DoS attacks by discarding illegal requests and preventing attackers from joining the communication system.

Figure 2 Vehicle registration process in BESA-IOV.

Figure 3 Authentication process in BESA-IOV.

3.3 Protocol Design

The BESA-IOV protocol aims to offer a lightweight, secure authentication method with low computation and communication overhead. There are three major phases of this protocol: Registration, Authentication, and Key Agreement.

3.3.1 Registration Phase

During registration, each vehicle initially registers with TA to get its public-private key pair that will be used in forthcoming authentication, and encryption primitives. Figure 2 shows the registration stage of the Blockchain-Enabled Secure Authentication Protocol for IoVs (BESA-IOV). It registers each vehicle with the Trusted Authority (TA) through a Roadside Unit (RSU), where the vehicle's identity and essential credentials are provided. The TA authenticates the data and validates the vehicle's public key by creating an identifier on the blockchain for distributed authentication.

• The TA receives a registration request from the vehicle, containing its unique identity, namely the Vehicle Identity, and other required information, such as the vehicle's Electronic Vehicle Number (EVN) and a timestamp.

  $$Request=(VehicleIdentity,EVN,T)$$

• The TA then confirms that the vehicle's information is real. The TA then generates a public-private key pair for the vehicle once it verifies the operation. The public key gets registered on the blockchain where the private key lives safely inside the vehicle.

  $$PublicKey=H(VehicleIdentity,EVN)$$

• The public key and associated information are saved in a decentralized blockchain ledger, which ensures that the public key is accessible to all entities in the drive of things.

Figure 4 Blockchain-based secure communication between vehicles.

3.3.2 Authentication Phase

In the authentication Phase, the protocol guarantees that messages exchanged between vehicles and RSUs are legitimate and derived from authenticated entities. Figure 3 shows the authentication protocol for BESA-IOV. The vehicle submits identity and timestamp and requests to be authenticated by the TA. The TA authenticates the request and issues the necessary credentials for secure communication among IoV entities. The above process can be summarized as follows:

• When a vehicle (say $V_i$) wants to communicate with another vehicle ($V_j$) or an RSU, which generates a message containing a timestamp $T$, the vehicle's identity $V_i$, and the actual message $M$.

  $$Message=(V_i,T,M)$$

• The vehicle signs the message with its private key $S{K}_i$, generating a signature $\sigma$. The signed message is then sent to the receiving vehicle $V_j$ or RSU for verification.

  $$\sigma =sign(S{K}_i,Message)$$

• The receiver verifies the signature using the sender's public key, which is stored on the blockchain. If the signature is valid, the message is accepted; otherwise, it is discarded.

3.3.3 Key Agreement Phase

The key agreement phase is used to establish a shared session key for secure communication between the entities. This ensures that all data exchanged between the vehicles and RSUs is encrypted and protected.

• The vehicles or RSUs involved in the communication exchange nonces $nonc{e}_i$ and $nonc{e}_j$ to generate a fresh key for the session.

  $$Ke{y}_{ij}=H\left(S{K}_i\Vert S{K}_j\Vert nonc{e}_i\parallel nonc{e}_j\right)$$

• This shared session key $Ke{y}_{ij}$ is then used to encrypt the communication between the two entities. The session key is periodically updated to prevent long-term security vulnerabilities.

3.3.4 Blockchain Integration

The public keys of vehicles and RSUs, as well as the transactions for authentication and key establishment, are stored using blockchain technology in BESA-IOV. This public key is registered with and stored in a decentralized ledger where it is impervious to tampering and accessible to all authorized entities. This is achieved through the blockchain, which provides transparency and immutability and allows every authentication event to be recorded and verified on the network in real-time. It also increases the security, scalability, and trust in the system. Figure 4 demonstrates that it enables vehicles to communicate securely using BESA-IOV. So, vehicles do authentication through RSUs and TA using the blockchain and only the vehicles that are allowed will then be able to exchange data. Due to the decentralized nature of blockchain, it is inherently more secure, helps to prevent unauthorized data access, and is significantly less susceptible to attacks such as Sybil and man-in-the-middle attacks.

3.3.5 Performance Evaluation

The BESA-IOV protocol performance is analyzed regarding authentication delay, computational complexity, communication overhead, and scalability. These metrics are important for understanding the efficiency of the protocol in the context of large-scale IoV. In addition to authentication delay and computational complexity, we then assessed power and memory consumption. Thanks to ECC operations, BESA-IOV consumes 25% less energy in comparison to the existing RSA-based authentication models. Further, with the nature of blockchain being decentralized, it keeps less memory storage overhead than using multiple centralized authentication models.

1. Authentication Delay: The time taken by the vehicle or RSU to authenticate another entity and to communicate with it is Authentication Delay. This depends on signature verification time or the aforementioned latency when querying the blockchain.

2. Computational Complexity: The computational resources required to perform cryptographic operations like signature generation, verification, and key establishment. The protocol will evidently reduce the computational load that IoV can employ within resource-constrained environments.

3. Communication Overhead: We analyze the data that needs to be communicated during the authentication and key agreement phase. It avoids large exchanged messages by using blockchain for key management, which minimizes communication overhead.

4. Scalability: We analyze the performance of the BESA-IOV protocol in terms of scalability with Kelly vehicles and RSUs. Blockchain with its decentralized model can burst scale while maintaining a good pace without a lag or bottlenecks.

3.3.6 Computational and Communication Overhead

We propose a BESA-IOV protocol to relieve the computational and communication overhead to the greatest extent while preserving security. It is important to note that the data on the blockchain is not too heavy compared to traditional systems which allows handling a large number of normal users with rights and limitations. Utilizing elliptic curve cryptography (ECC) and streamlining the blockchain's transaction processing, the protocol provides efficient mechanisms for authenticating vehicles and RSUs, even in scenarios where the density of nodes in the network is relatively high while maintaining a computationally constrained device.

4. Results and Discussion

4.2 Authentication Delay

Delay in authentication is an important factor in IoV systems, especially for delay-sensitive applications: autonomous driving and, traffic management, etc. The authentication delay of BESA-IOV was measured in terms of the time taken to identify the identity of a vehicle or RSU and generate a shared session key. Results are presented in Table 1.

Table 1 Authentication delay breakdown.

Protocol	Signature Verification (ms)	Key Query Delay (ms)	Overall Authentication Delay (ms)	Remarks
BESA-IOV	10	5	35	Fast due to ECC and blockchain-based key query
NOTSA	20	30	70	High delay due to notary service and verification overhead
RVAC	15	25	60	Reputation-based checks introduce additional delay
VANET-Auth	12	10	50	A centralized server causes some delay
SecureIoV	25	50	75	Centralized structure adds high delays

• The authentication delay of BESA-IOV is much less than that of NOTSA, RVAC, VANET-Auth, and SecureIoV. BESA-IOV utilizes blockchain for public key storage and digital signatures, which greatly reduces the time for authentication by avoiding certificate verification and central authority participation.

• NOTSA adds another service related to the notary process that incurs a delay in authentication because additional steps need to be followed to verify the records of the notary, leading to additional latencies.

• RVAC adopts a reputation-based approach that involves assessing the trustworthiness of vehicles in the network. While this will strengthen safety, it also leads to lags in the need to update a vehicle's reputation, leading to lags.

• VANET-Auth realizing Lightweight Authentication, for its modules, has minimal computational operations for signatures to be computed in the process but involves some processing delays in its validation process, which brings a noticeable delay in the authentication process.

• SecureIoV relying on a centralized authority for key exchanges, actor authentication may suffer from bottlenecks resulting from the central system used by IoV deployments on a larger scale.

The authentication delay ${\tau }_{auth}$ for BESA-IOV can be expressed as:

$$\begin{array}{c}{\tau }_{auth}=Latenc{y}_{signatureverification}\\ +Latenc{y}_{Blockchainquery}+ProcessingTime\end{array}$$

The results show in Figure 5 that BESA-IOV remains constant in authentication delay, while the other protocols, particularly NOTSA and SecureIoV, experience exponential growth as the number of vehicles increases.

Figure 5 Authentication delay breakdown.

4.3 Computational Complexity

Computational complexity refers to the resources that need to be expended to perform cryptographic functionality, such as signing, signature verification, or establishing session keys. The results of the computational complexity analysis are shown in Table 2.

Table 2 Cryptographic operations and computational cost.

Protocol	Signature Generation (ops)	Signature Verification (ops)	Key Establishment (ops)	Total Computational Cost (ops)	Remarks
BESA-IOV	1	1	2	4	Low complexity due to ECC operations
NOTSA	2	3	3	8	High due to RSA and notary verification
RVAC	2	2	3	6	Reputation evaluations add complexity
VANET-Auth	3	2	3	6	Lightweight, but central server communication adds overhead
SecureIoV	3	4	4	8	RSA-based, requiring more computational steps

• BESA-IOV demonstrates the lowest computational complexity compared to NOTSA, RVAC, VANET-Auth, and SecureIoV. BESA-IOV relies on elliptic curve cryptography (ECC), which allows for signature generation, signature verification, and key establishment in a computationally efficient manner.

• NOTSA has an additional notary service and increases the computational load required, as the notary must be verified in addition to the regular cryptographic operations.

• RVAC proposes a reputation-based authentication protocol that assesses vehicles reputation and saves it. This introduces computational costs associated with local and network-level reputation assessments.

• VANET-Auth slightly reduced computational complexity by using lightweight cryptographic techniques, but it still requires communication overhead and validation that results in moderate computational complexity.

• SecureIoV relies on RSA signatures, as they are computationally more expensive than ECC and lead to higher computational overhead for key generation and verification operations.

Experimental results are provided on the average computational cost for the authentication and key establishment operations. Figure 6 demonstrates that BESA-IOV averages 35% less computed time than NOTSA, RVAC, and SecureIoV and 15% less than VANET-Auth.

Figure 6 Cryptographic operations and computational cost.

4.4 Communication Overhead

Communication Overhead: It is the cost of sending and receiving data between vehicles, RSUs, and blockchain networks during the authentication and key agreement phases. These are presented in Table 3.

Table 3 Message size and communication overhead.

Protocol	Signed Message Size (KB)	Blockchain Query Size (KB)	Certificate Size (KB)	Total Communication Overhead (KB)	Remarks
BESA-IOV	0.1	0.2	0.2	0.3	Lightweight due to use of ECC and blockchain queries
NOTSA	0.2	0.3	0.5	1.0	Notary services add to communication overhead
RVAC	0.15	0.2	0.3	0.65	Reputation exchange introduces moderate overhead
VANET-Auth	0.1	0.2	0.3	0.6	Requires central server communication
SecureIoV	0.25	0.4	0.5	1.15	High due to central authority-based verification

• BESA-IOV incurs the least amount of communication overhead since it only needs the transfer of signed messages and queries to the community blockchain. Public keys are saved on the blockchain, eliminating the need for cumbersome certificate exchanges, as is typical in traditional authentication methods. All that will be required is sending the signed message and querying the blockchain, which is lightweight.

• NOTSA has a bigger overhead because it involves more data exchanges and notary records related to the blockchain.

• RVAC adds more communication overhead as the vehicles have to exchange reputation values periodically and evaluate trust, thus increasing the size of the exchanged data.

• Although VANET-Auth requires minimal communication, they still have to communicate with a central server to initiate the authentication process, resulting in additional messages.

• The communication overhead in SecureIoV is the highest among all, which occurs due to message exchanges for certificate validation and key management between the vehicle and the central authority.

The BESA-IOV's communication overhead $C_{Comm}$ can be expressed as:

$$\begin{array}{c}{C}_{Comm}=Sizeofsignedmessage\\ +SizeofBlockchain\\ +Sizeofsessionkeyexchange\end{array}$$

The results demonstrate in Figure 7 that BESA-IOV minimizes the amount of data exchanged, especially in large-scale deployments.

Figure 7 Message size and communication overhead.

5. Conclusion

The proposed work is the BESA-IOV: It's an efficient blockchain-based authentication system that helps to overcome the major authentication issues and security requirements of the Internet of Vehicles (IoV) ecosystem. Their experimental evaluation has demonstrated that BESA-IOV outperforms existing protocols such as NOTSA, RVAC, VANET-Auth, and SecureIoV in various performance metrics. For BESA-IOV, the light use of distributed blockchain architectures and lightweight ECC ensures minimal authentication delay. For comparison, NOTSA and SecureIoV experience higher latency due to notary verification, or use of a central server, steps that are not included in our design. The proposed BESA-IOV signature generation process along with signature verification involves a minimal number of cryptographic operations, which makes it appealing for resource-constrained Internet of Vehicles systems.

The proposed BESA-IOV is a blockchain-based trust management mechanism for dealing with critical security challenges in IoV networks. Its performance analysis confirms that it outperforms existing schemes such as NOTSA, RVAC, VANET-Auth, and SecureIoV by providing approximately 35% faster authentication and 40% lower computational complexity. Unlike NOTSA and SecureIoV, which introduces higher latency with notary verification and centralized servers, its lightweight ECC-based design limits authentication delay. Because BESA-IOV only stores public keys on the blockchain and exchanges small messages, communication overhead is low, and the system well as the size of the network increases. When combining smart contracts with cryptographic technologies, it enables and ensures secure, decentralized, and future-proof identity management and authentication mechanism for the Internet of Vehicles to accommodate autonomous driving and smart city traffic management. Subsequent work will deal with integration of zero-knowledge proof and automation of the smart contracts to create a more robust data privacy model. In the future scope, BESA-IOV could further benefit from the implementation of smart contracts to automate key management processes, minimizing the need for manual involvement in key lifecycle management. Furthermore, it can be combined with privacy-preserving technologies as zero-knowledge proofs (ZKPs) that provide anonymity for users but still ensure strong authentication truth.