## 3 Methodology
### Diving into Pairing Approach
#### 3.2.2 Vehicle Pairing and Data Validation  
In this section, we present a vehicle pairing model aimed at identifying security attacks on ECUs through inter-vehicle pairing, ensuring no extra memory or network load on the vehicles. Central to this security model is a centralized database integrated into the infrastructure, utilizing advanced machine learning methods to accurately detect and pinpoint attacks. Figure 4 shows the flow of our vehicle pairing model. We have paired vehicles of different types that engage in V2V communication, exchanging identical information such as road conditions. Each vehicle collects event data from its sensor network and sends it to a centralized database specialized in identifying potential attacks. Throughout these data exchanges, vehicles utilize vehicle-to-infrastructure communication protocols to interact with the central database. In V2V, vehicles have the capability to exchange crucial information to enhance security. Should Vehicle A and Vehicle B be connected, for instance, they can share real-time traffic updates. Each vehicle's data are forwarded to an RSU for confirmation. The RSU verifies its correctness and legitimacy by means of information analysis from both cars, therefore facilitating traffic condition monitoring, risk detection, and the prevention of fake data injection attacks.  
Deciding Factors: Choosing Vehicle for Pairing  
Confirming their involvement in V2V communication and providing suitable data, including road conditions, would help establish the related vehicle selection criteria. Every car has to be unique; self-pairing is unacceptable. Moreover, both vehicles have to be easily accessible for pairing purposes; consequently, they are not already paired. To allow exact validation and comparison of event data acquired from the matched vehicles, the central database generates unique pair IDs. This method ensures data confidentiality and integrity without incurring higher overheads on cars.  
Each vehicle has a different pair ID and vehicle ID to help identify possible targets of security attacks. Carefully entered in the central database, these pair IDs enable a thorough comparison of event information gathered from every vehicle pair. By verifying the data integrity of every vehicle's information with its matching counterpart, this verification system guarantees that every vehicle runs autonomously and acts as a verifying agent for its matched vehicle, therefore guaranteeing the validity of sensed data without adding additional memory or communication overhead. While Algorithm 2 defines the procedures involved in vehicle pairing and supporting data validation, Figure 5 provides a conceptual overview of our vehicle pairing method.  
Algorithm 2 provides secure communication and shows our way of pairing the vehicles in a network. The approach begins with an empty list called _pairedVs_ to document the vehicles that have been successfully paired and an empty dictionary called _pairIDs_ to retain distinct pair IDs for every vehicle. Every vehicle (\(V_{i}\)) in the network starts with a false boolean variable known as isPaired. The machine then goes on to compare \(V_{i}\) with every single other vehicle (\(V_{j}\)). \(V_{i}\) and \(V_{j}\) are designated as paired if they engage in vehicle-to-vehicle communication (V2V), are different vehicles, and both have unique pair IDs for possible pairing. Each of the vehicles in the _pairedVs_ collection has a unique pair ID; this ID is kept in the _pairIDs_ collection. If an attack is detected, the pair is removed from the list of paired vehicles, and the pair IDs are updated accordingly. This procedure ensures that only legitimate and secure vehicle pairings remain within the network.  
Figure 4: Flow of the proposed vehicle pairing model.