Blockchain-Based Collaborative Certificate Revocation Systems Using Clustering

Despite the decisive contribution of intelligent transport systems in road safety, they also open new vulnerabilities to cyber-attacks, particularly vehicle position-linked attacks. For that reason, centralized systems are becoming increasingly vulnerable to the growth of the connected-vehicle fleets as it becomes more challenging to revoke certificates in real-time. We have proposed a new method that integrates a decentralized, collaborative system to meet these challenges. This method efficiently allows Blockchain integration for vehicular network’s cyber security by dynamically creating communities to revoke malicious vehicles in real-time. This article presents analytical models of the system of real-time revoking certificates and examines our solution’s impact on two important types of attacks in V2X communications, Sybil and the faking position attacks. Our experiments using real V2X hardware demonstrated the feasibility and benefits of real-time revocation via vehicle communities. The results were obtained from consensus implementation in a vehicular network comprising three communicating vehicles and a single roadside unit. In parallel, simulations showed feasibility in large-scale communications. As a result, the exposure and detection times of our solution meet real-time requirements.


I. INTRODUCTION
I N vehicular communications (V2X), there are promising technologies for solving intelligent transport system (ITS) problems such as accident prevention, traffic monitoring, and transport efficiency. V2X communications rely on types of communicating equipment [14]: on-board units (OBUs), installed in the vehicles, and the road side units (RSUs), deployed alongside the road. Safety-related messages are periodically broadcast over the control channel (CCH) by the OBUs with information on the status of the vehicle. ITS communication contains a vulnerability that makes it possible to track drivers' identities even over more extended periods. Thus, it tracks and creates vehicle movement profiles, representing privacy breaches for vehicle users. Complete anonymity of all network participants is not a viable countermeasure, because critical security systems require data authenticity and participant responsibility. Security authorities must ensure the OBUs' confidentiality, registration, and authorization. The responsibility for verifying the validity of their canonical identifiers is entrusted to an enrollment authority (EA), whereas an authorization authority (AA) distributes access to services. These two authorities are part of the necessary Public Key Infrastructure (PKI) and must be operated in different control domains to achieve additional privacy. Vehicle request-response message schemes require at least short-term message binding capability to establish a joint session. For example, authentication is needed to request data from the infrastructure or manage automatic payment on car chargers. A widely chosen approach to restoring user privacy is to use temporary pseudonyms for identification in the network. This poses a major problem with Certificate Revocation (CR). Since temporary certificates are designed for non-traceability, it becomes almost impossible for vehicles to identify malicious pseudonyms or for the certificate authority (CA) to identify malicious behaviors. This vulnerability could cause two major types of cyberattacks linked to vehicles' position: position-spoofing and the Sybil attacks.
In this article, we propose a new scheme of consortium blockchain for cybersecurity purposes. Our system is based on a Smart Contract and consensus that allows vehicles to detect and revoke malicious vehicles in real time. First, our framework is designed to integrate blockchain technology for cybersecurity purposes against fake position-based attacks. Second, it aims to create dynamic blockchain networks for decentralized trust management in-vehicle networks. Furthermore, it cooperatively enables revocation between vehicles, taking pseudonym changes into account.
This article is organized as follows: The II section gives an overview about clustering, certificate change strategies, and their revocation, and finally, we talk about common cyberattacks in V2X communications. Then, in section III, we detail our proposed solution and revocation algorithm. After that, we present our experimental results using real V2X equipment and we validate the effectiveness of our consensus by means of simulations, see section IV. Next, the results are discussed in section V. Finally, section VI concludes our article, presenting valuable information about our work and prospects.

II. REVIEW OF RELATED WORK A. CLUSTERING
The existing clustering protocols in V2X communications are broadly divided into five sub-categories: position-based protocols [39], [27], route discovery protocols [29], [46], broadcast protocols [45], infrastructure-based protocols [30], and cluster-based protocols [19], [24], [33], [42]. El Houda et al. [2] used a Smart Contract to design a blockchain-based solution (Cochain-SC) to guard against the DDoS collaboration attack. In Cochain-SC, blockchain enables low-cost decentralized security and collaboration between multiple SDN domains to mitigate attacks using clustering techniques. In addition, the authors of [21] consider the reliability of links for clustering. However, this scheme takes fixed arrival rates for nodes on the highway, which remains unrealistic. Based on V2X communications, in recent years some authors [7] have proposed using a heterogeneous network, using IEEE 802.11p and cellular communication. Next, Liu et al. [26] proposed a reliable and stable communication scheme using clustering and probabilistic diffusion. This scheme was based on vehicles communications. With this method, a vehicle could broadcast data to other vehicles within connection time. In addition, this system could also improve the coverage rate. However, during vehicle-to-vehicle communications, this system could not detect malicious vehicles, leading to data insecurity.

B. CERTIFICATE CHANGE STRATEGIES
Privacy is considered one of the most critical issues in V2X communications. While vehicles exchange their locations and identities, malicious nodes can track their information and threaten their privacy. PKI authorities use pseudonyms as a solution to protect vehicles from trackingattacks. Standards proposed several pseudonym schemes to keep the vehicles' identities secure [31]. Contributions argue for occasional pseudonym reloads to intermittent connectivity with pseudonym issuing authorities; these are changed periodically to prevent the tracking of pseudonyms. The confidentiality of users in relation to authorities can be protected by dividing responsibilities between the pseudonym CA (PCA) and the long-term CA (LTCA) as suggested by the CAR 2 CAR Communication Consortium [6]. In addition, data transferred in the V2X network can be modified by an attacker to mislead vehicles, which can lead to traffic accidents. Appropriate security schemes can be adopted, but this could cause additional latency [32]. This is of utmost importance in emerging intelligent connectivity networks, leveraging cloud-based capabilities to support critical security services with stringent security, trust, and privacy requirements [17]. Yang et al. [48] proposed two lightweight anonymous authentication schemes for the V2X network. One scheme is applicable for V2V communication, while the other is suitable for V2I communication. Both schemes considered limitations of V2X, such as OBU resource constraints and latency. He et al. [3] introduced the preservation of confidentiality based on a security scheme for V2V and V2I communications in VANETs. This scheme uses elliptical curve cryptography (ECC) rather than bilinear pair operation during the diffusion procedure. This scheme supports a batch verification process to authenticate all messages related to the V2X environment state. A random oracle model related to a message's authentication provides authentication between the signer and the receiver. Nowadays, certificates changes strategies remain a challenge for the cybersecurity of V2X communications.

1) Pseudonyms Management
To ensure vehicles' confidentiality, the standard [10] mentions the objective of pseudonymity and the dissociation of ITS nodes' identities from their messages. This privacy objective is subdivided into two dimensions: authorities must ensure vehicle registration and authorization confidentiality by limiting knowledge of a node's canonical (fixed) identifier to a limited number of authorities. The enrollment certificate (EC) contains an alias ID signed with a certificate chain that refers back to the originating EA. This EC can then be used to obtain authorization tickets (ATs) from an AA. These ATs are also certificates indicating the authorizations of a node. Authorization ticket certificates can be stored in a hardware security module (HSM) to prevent unregulated direct access to cryptographic keys; the security service specification provides such an option. All authority responses are encrypted and verifiably signed for the node. Certificate requests include a start time and an end time, as well as challenge [11], a random string encrypted with the receiver's public key. Both of these measures prevent replay attacks. Credentials and ATs can also be updated as needed through similar mechanisms. The ETSI survey [9] also gives an overview of strategies used in existing projects standards. In recent years, few studies have been proposed on certificate revocation list (CRL) distribution methods [23]. The revocation of pseudonym certificates is generally limited to revoking the vehicle ID for scalability reasons. If the long-term identity is revoked, the OBU cannot get new pseudonyms (PC). Additionally, letting OBUs check other vehicles' PCs against Certificate Revocation Lists (CRLs) would be impractical due to the high message frequency and potentially voluminous CRLs, especially in heavy traffic scenarios. In [22], the authors proposed an approach for revoking certificates based on the region of operation.
Only a few trust models have recently been proposed to enhance honest information-sharing in-vehicle networks. In terms of security and confidentiality by establishing trust in VANETs, which are based on security infrastructure, most models often use certificates.
Almulla et al. [4] proposed a k-means clustering approach for validating certificate revocation in VANETs in which detailed system security analysis has been provided. The scheme improves certificate validation and thus enhances the security of communications within the scheme.
Malik et al. [28] propose a framework for authenticating and revoking transactions. It authenticates vehicles with mitigating reliance on a trusted authority and quickly updates the status of revoked vehicles in the blockchain ledger shared with the PoA mechanism. In [49], the authors present a blockchain-based event validation scheme to verify every event that occurs on the road. However, there is a need for an incentive mechanism to encourage vehicles to participate in the event validation process.

D. POSITION-RELATED ATTACK DETECTION
In V2X communications, vehicles and infrastructure continuously exchange traffic safety and navigation messages. As a result, these messages are exposed to various attacks such as denial-of-service (DoS), Sybil, and false alert attacks, which may disrupt the traffic flow and cause accidents. We cite Bin Xiao et al. [47] reserved for the detection and localization of Sybil attack in VANET nodes. Authors in [51] have proposed a Sybil detection method based on received signal strength indicator (RSSI) named Voiceprint. It relies on RSSI time series as vehicular speech.
Ruj et al. [38] propose using a data-centric misbehavior detection system in order to detect false location information. It works by classifying data instead of classifying vehicles. Each vehicle can verify the location information independently by using the proposed technique. This leads to fines imposed on attackers instead of isolating them from the network. Yang et al. [50] proposed a Sybil detection scheme based on motion similarities among vehicles by using three ML classification models.
In the Table.I we compare our solution and the other papers cited above.

III. PROPOSED REAL TIME REVOCATION FRAMEWORK
In this paper, our work focuses on proposing a real time cooperative revocation system using a clustering algorithm. We propose a distributed algorithm in which each communication node initiates its own process by executing a Smart Contract. It creates a cooperative communities that contain sets of vehicles that participate in their local blockchain and agree on each vehicle behavior.

A. SYSTEM MODEL
All vehicles are assumed to be equipped with a GPS system that provides the vehicle's basic information and an ITS-G5 system communicating based on the IEEE802.11p standard. The broadcasted information includes the vehicle's current location, velocity, and direction. Moreover, each vehicle can calculate speed and detect the RSSI rate of received messages using its communicating module. Periodic status information, such as beacons or CAM messages, is broadcasted by each vehicle to its neighbors every 0.1 seconds. The traffic management center (TMC) plays a significant role in disseminating messages, as it can reach every vehicle using cellular technology. Our Blockchain consensus model is based on proving each vehicle's position in the clusters and sharing decisions about vehicles' behavior among all participants. The position-proving process is in peer-to-peer VOLUME 4, 2016 mode. The witness provides proof-of-location (PoL) to the prover.
There are N vehicles in the vehicular network, and we assume N to be fixed in time. For i = 1, ..., N, the i − th node, N i is associated with a position, represented, as P i(t) = (x i (t), y i (t)) at time t. The nodes are users of a PKI. We define a communication range, also called coverage area, for each node, as a circle of radius R having the node as its center. If V is the set of all vehicular network nodes, i.e., V = N i : i = 1, ..., N then we define the neighbor set of a node N i at time t, as the set of nodes V which are in i's communication range at time t; more formally defined as Each communicating vehicle is assumed to have its own credentials, corresponding to the IDs it uses in community communication. The asynchronous accumulator acts as the initial accumulator for the CRL. Each user registers with the credential issuance authority.
The authority checks the validity of the user by consulting the dynamic asynchronous accumulator within the blockchain.  Since vehicles are resource-limited devices, the problems of building a distributed network structure have been examined in [16]. In this work, we propose to use a chain made up of only limited communities. Each vehicle contributes to the community according to the parameters and capabilities used in the vehicle subnet. Below we take a more detailed look at the proposed version of the block structure.

B. COMMUNITY CONSTRUCTION
This part is the first step of our framework process for determining how vehicle clusters, called communities, (local blockchain networks) are constituted. We attempt to construct communities and to enable a cooperative process to transmit periodical CAM messages. When initialized, the vehicle does not yet have any knowledge of its neighborhood. When the vehicle is switched on, its wireless communication module starts to transmit periodical CAM messages. When initialized, the vehicle does not yet have any knowledge of its neighborhood. to detect and revoke malicious vehicles. The community construction process is triggered when the vehi-cle receives multiple CAM messages, also called beacons, with different pseudonyms.
Vehicles are aware of their surroundings via the CAM messages. Once a vehicle receives the CAM messages, it records the vehicles' IDs in a time T har . and sends the list to the TMC. Thus, the TMC, therefore, receives several lists after the time T har . After concatenating the lists, the TMC obtains a graph. Then, based on the graph rules specified in subsections bellow, the TMC issues the community's start list with a cluster ID (ID clus ). The vehicles in the community will use their pseudonyms as tokens to sign transactions in order to avoid any risk of tracking.

1) One-hop neighbor table
At the beginning of the clustering procedure, each node is in an initial state. Then, the system starts a timer, called T har , during which vehicles exchange and collect Beacons to discover their one-hop neighbor table (N S). For example, a CAM message received by a node V i from a neighbor node V j triggers a routing table. Then the neighbor sampling process selects a set of stable neighbors, denoted as Graph G where G ⊂ N S.

2) Cluster Processing
The T M C is responsible for this step. First, the T M C must processes the vehicles' conditions in order to identify the best OBU candidates for the community. Then, it selects the cluster head (CH) which maintains the cluster.
The N S represents a neighboring vehicle list that presents a similar mobility pattern, moving in the same direction. Hd V i = Hd V j these are the driving headings of V i and V j . The T M C decides then if the vehicle can be a candidate for the community. For that, the link time (T link ) must be smaller than the predetermined threshold T th : Where QT max is the maximum value of the density of vehicles (vehicle per Kilometer −V h/Km−) the T M C had on its road network for the same period, the 5 or 10 past years, V T is the estimated value of the vehicles' speed (Km/h) in the T M C network. All T M Cs have easy access to these values since they represent important parameters for traffic management.
The community should have a lifetime, T lif e , to avoid a hacker having a monopoly on it. This is calculated based on the average life of the link, T link , between vehicles.
where ∆D ij = (P i (t), P j (t)) and ∆v ij = v i − v j are respectively the average distance between V i and V j and the average of their relative velocities.
The selection of the cluster head will be based on the metric T lif e in Eq(2). The vehicle having the longer link time is the most likely to take the cluster head. In our proposition, the CH receives the list (List com )of vehicles that may likely contribute to the community.

3) Cluster formation
When a vehicle V j receives a cluster formation message from T M C Eq (3), it immediately sends a ReqJoin = Sig Vj ( Clus f or ) message to CH i . After CH i receives the ReqJoin message, it first checks whether this ID is available in List com . If so, CH adds V j to its cluster member list G com and sends back a ACKJoin message; otherwise, it ignores the request to join.

4) Pseudonym changing
The Pseudonym Certificates (PCs) are stored and managed in pseudonym pools, with their corresponding private keys kept in the Hardware Security Modules (HSMs). To keep the privacy of vehicles and avoid tracking or linking their real identities to the used pseudonym certificates, the PCs are changed frequently according to various rules [10]. This ensures that each vehicle has precisely one key pair (own pseudonym and private key) active during each period. Vehicles cannot reuse the pseudonym once it has been changed, even if the certificate has not yet expired. Due to the highly dynamic nature of VANETs, vehicles keep joining and leaving clusters frequently. Vehicles that apply for the strategies of changing pseudonyms are considered new. Once the vehicles change their PCs, by giving a new identity to the cluster with a new pair of keys, the network assumes them new, in which case they must seek to join the cluster; therefore, they must proceed to re-clustering. The process of re-clustering guarantees that a vehicle could find a proper cluster to follow as long as it foregoes contact with its current G com . However, a long delay in the re-clustering process may lead to severe consequences, primarily when implemented delay-sensitive applications. This is why we propose that the best link-time be calculated in real-time so that the cluster header can be changed. Other solutions are proposed by [34] to solve the problem of re-clustering delay.
In order to maintain the privacy of the vehicles that join the blockchain and also to ensure the stability of the clus-ter, we propose to use the community changing strategy described by [41], which aims to make all vehicles change their pseudonyms at the same time with a period of silence afterward. Therefore, this makes tracking one of the community vehicles a challenging task for hackers.

5) Isolated Vehicles
In our system of real-time revoking certificates, vehicles could be isolated for two reasons: -Pseudonym changing, -Revoked certificates.
Despite the insulation of these vehicles, they remain open to receiving messages. However, these could no longer contribute to the revocation process or the declaration of messages relating to road safety. The change of pseudonyms is always followed by a period of silence as indicated in [15], this could harm the vehicles in critical situations, such as the vehicle will no longer be known to its neighbors. In this case, the vehicle must keep the same PC during the critical period called Time-To-Crash (TTC) [13]. Therefore, the vehicles subscribed in the clusters will fulfill their communication role in critical situations as they must keep the same PC and will not be isolated as long as they "good behave."

C. COMMUNITY DETECTION 1) Proof-of-Location Consensus
Misbehavior detection in V2X communication has been well studied (see Section II-D). To evaluate our solution, we have used the detection model developed in our previous work, based on the proof-of-location (PoL) process. It aims to detect any attack from Sybil to position-faking attacks.
In our previous work [8], we proposed a new security architecture based on consortium blockchain cryptography which is built upon consensus-based PoL. In this work, our algorithm aims to give an accurate decision based on fluctuating RSSI values. The communication between the prover and the witness should be estimated based on N number of beacons received from the prover as shown in Fig.2, the N value should be estimated based on their relative velocity. the PoL process is detailed in [8].
The PoL algorithm has an output of three major indicators that permit to identify position-faking attacks, I 1 , I 2 , I 3 VOLUME 4, 2016 • Indicator 1 (I 1 ): Indicates average speed and calculates distance traveled by using the prover's traces. • Indicator 2 (I 2 ): Using RSSI, we estimate the distance FIGURE 2. The Proof-of-Location process between the prover and its witness between the witness and the prover using the Friis equation and the budget-link formula. Then, based on the prover's declared position, we compare the declared distance between them. • Indicator 3 (I 3 ): This indicator represents the communication quality conditions between the witness and the prover. It takes into account the information of the two vehicles to evaluate the accuracy of the witness's detection (i.e., how well it can verify signal strength and distance from the prover). We calculate it based on vehicles' velocities, headings, and yaw rates (and weather can also be considered). Relative velocity greatly impacts the accuracy of RSSI measurements due to the Doppler effect, and heading and yaw rate provide information concerning the line of sight.
P oL = (P oL Acc , P oL rate , P os p , t w , Cer w , S w [P oLreq, t w , Kp p ]) where P oL Rate = I1+I2 2 is the indicator rating the probability of detecting a Sybil attack, and P oL Acc = I 3 gives detection accuracy based on the measuring conditions.    TABLE III the velocity, as shown in Fig. 3 and Fig. 4, the high velocity significantly impacts the distance estimation based on the RSSI. Therefore, the fluctuation rate of the RSSI-based estimation error depends only on the velocity between the two communicating devices. We have dressed a table to compare the fluctuation between and relative velocity in the V2V communication mode (OBU1 and OBU2) and I2V mode (RSU and OBU). We have demonstrated the importance of integrating vehicles in the detection process. The V2V communication mode can also resist the RSSI fluctuation problem as in the highway, the relative velocity between two vehicles in the PoL is mainly reduced as they drive nearly at the same speed. Nevertheless, the V2V communication mode could not solve the fluctuation problem entirely. Therefore, our Proof of Location consensus algorithm has proposed an additional mechanism to guard against the Sybil attack and consolidate the vehicles' detection accuracy. Our solution allows an average on the N report of the level of RSSI, which leads to better accuracy, as it is based on the collection of multiple consecutive RSSI reports, of in the worst case, the vehicles with which there will be a high velocity will eventually disappear since it will no longer be within the range of the broadcast.

2) Community Processing
Before starting to prove other vehicles' positions, vehicles look for affinities with neighbors in order to establish bilateral communication with the "best" partner.
Let G(V, E, r) be a vehicular topology, where V is the number of vehicles, E is the ordered pair of links among vehicles and r represents link reliability. The representation of a given vehicle's graph topology G(V, E, r) is traced by vector A and matrix B of dimension V × V . Once the community is constituted (Section III-B), each vehicle has to calculate the vector of link reliability with all surrounding vehicles using Eq (5). The reliability level of N surrounding vehicles will be included in vector A: For total detection, the vehicles transmit the P oL to one vehicle at a time, in order of preference in terms of the reliability of the link. After sending the vector A, one vehicle proposes a handshake process to another, and it sends its PoL to others down its list. Each pair of vehicles must agree to send each other a P oL. The prover must then go down the entire list of IDs in its vector A before starting peer-to-peer proving with vehicles for the second time.

D. COMMUNITY REVOCATION
In this section, the community must make a joint decision to revoke a given vehicle. The result of the detection is made based on the smart contract. After choosing a prover, the witness must process the smart contract in order to provide detection Matrix B, which contains the information concerning N vehicles of community G based on Eq(4) as given below: P ol 11 P ol 12 P ol 13 · · · P ol 1n P ol 21 P ol 22 P ol 23 · · · P ol 2n . . . . . . . . . . . . . . . P ol m1 P ol m2 P ol m3 · · · P ol mn      In order to detect malicious vehicles, we use a spectral clustering tool in Laplacian graph matrix. Once the detection matrix B is computed, the Laplacian graph L is computed as Eigen decomposition involves the factoring of a matrix in terms of its eigenvalues and eigenvectors [21]. In the literature [5], in fast-evolving networks with high dimensionality of data, spectral clustering becomes the only option. Eigen decomposition can be used to reduce dimensionality of mobile vehicles. Suppose that J has non-degenerate eigenvalues λ 1 , λ 2 , λ 3 · · · λ n and corresponding independent eigenvectors X 1 , X 2 , X 3 · · · X n . Then matrix Z, composed of eigenvectors, is: By the end of the detection, matrices are supposed to be given simultaneously in peer-to-peer communications. Each vehicle identifies suspected IDs by means of mean eigenvalue and the smart contract. The community processes each VOLUME 4, 2016 vehicle decision and uses a consensus mechanism to reach agreement.
To feed the real-time CRL of revoked credentials, we use the asynchronous accumulator (explained in more detail in [35]), generating an extra secret for each certificate.

E. BLOCKCHAIN STRUCTURE
After forming the chain, the nodes produce an item-by-item check of the final community. The blockchain must contain all the information of each community steps?. Our proposed blockchain is constructed as follows: In Fig.5, we present the structure of each community structure, where N is the number of the community's vehicles.
Part 1: All nodes record the genesis block 0, which must contain the vector A provided by all the community vehicles. The miner in this first step is the T M C that supervises the community construction, making sure that only selected vehicles can communicate in the community.

FIGURE 5. Blockchain's global parts
Part 2: Lasts from Block 1 to Block n 2 . These blocks are created to register the peer-to-peer combinations of the PoL process between each pair of vehicles in the community. In each round of proving, a block is created to describe the combination of provers. The miner of all these blocks is chosen based on the minimum average of vector A, which indicates that it is the vehicle that is the closest to all other community vehicles.
Part 3: Marked by the block n 2 + 1, which must contain all the B matrices generated by the community vehicles.
Part 4: The Block n 2 + 2 is characterized by the final decision concerning suspected malicious vehicles that should be aggregated into the asynchronous accumulator.
Each community's node should keep track of all transactions it has learned about waiting pool, partitioned into mutu-ally. The waiting pool can be considered a dynamic memory in which transactions that have not yet been published are waiting to be transcribed into a block. Every transaction should include the blockchain part number and should be broadcast among vehicles for global dissemination. Table.IV shows the composition of transactions.

F. SMART CONTRACT
Once the vehicle get into the community it should get the genesis Block that contains the Smart Contract. As shown in Fig.6 our smart contract is considered as a finit state machine, where every part is a vehicle state. Once the vehicle get access into the community, the transmitted transactions indicate the state of the blockchain to the vehicle. Part 1: the T M C is responsible for generating the genesis block with the smart contracts.
Part 2: The consensus in this part is based on the results of the genesis block, in that the miner of the blocks is selected based on the minimum of the sum of the vector's A values.
Part 3: This part is the most important for our consensus process, in which the vehicles must reach consensus to produce block n 2 + 1, which contains the B matrices for all vehicles. For that, we use the Paxos consensus algorithm [25] Part 4: The consensus is held on the last block (Block n 2 + 2) of the blockchain in order to declare vehicles malicious. The decision is based on the agreement of more than 50% of the vehicles in the community. The trust authority is responsible for aggregating agreement and constructing the block.

IV. PERFORMANCE EVALUATION
To evaluate performance, we have examined metrics using results captured from real-life experiments. These experiments tend to demonstrate the effectiveness of our proposed method using real vehicular communications. Simulations indicate that our solution will perform well in large-scale implementation.

A. EXPERIMENTS 1) Experiments setup
We used three vehicles equipped with 3 OBUs, 1 RSU, and 2 USRP (Universal Software Radio Peripheral) cards. Fig.7 shows the campus, the road tests, and the material we used to test four different scenarios. To obtain detailed results in terms of communication conditions, we experimented with four different scenarios. Fig.7 shows the campus and the road tests we point to the material used.

FIGURE 8. Setup for campus scenarios
We experimented with the community revocation process by creating/simulating a Sybil attack and a position-faking attack. We evaluated to fake the community decision by sending faked messages using USRPs.
where T N represents true-negative decisions; F N represents false-negative decisions; T P represents true-positive decisions; F P represents false-positive decisions.
To calculate the variation of witness proofs, we have estimated σ, which is the variation of P oL reports sent during communication.

3) Detecting a false position attack
In this part, we compare detection accuracy, based on our P oL algorithm applied by each vehicle, to the accuracy of our revocation framework.
In Fig. 10, we show the profile perceived by the witnesses (OBU 1, 2, and 3). We have concatenated the time series of all scenarios tested for each vehicle in each scenario in Appendices .  Fig.12, shows each vehicle's profile. We have reported the different indicators from each witness in each scenario. Based on the mean and the variance of P oL indicators, each vehicle decides whether or not to trust another vehicle. Table.V shows the results obtained from the peer-to-peer PoL process. We did not register a high accuracy rate in scenarios 1 and 2 because of the high relative velocity because the hacker is static. However, scenarios 3 and 4, in which the hacker was mobile, present a better accuracy rate.  Fig. 11a. We have applied our algorithm to each of the OBUs as shown in figures 11a, 11b and 11c the accuracy rate of the peer-to-peer PoL process of each OBU.
In the first subplot of each figure, we show the evolution of the accuracy of the OBU over time. The communication range and velocity are shown in the second and third subplots. False/True Negative decisions represent witness reports against "Trusted" OBUs. In contrast, False/True Positive decisions are evidence against the Hacker. We notice that the two indicators, communication range, and velocity, significantly impact the witness's accuracy.
These indicators impact is reflected in the following examples: Case 1: A receiver/transmitter (witness/Prover) with a long communication range (200 to 500 meters) static. According to the figures, these scenarios are often endowed with reasonable accuracy.
Case 2: A receiver/transmitter at a short communication range (0 to 100 meters) but a high relative velocity. According to the figure, these cases are often with poor precision. Therefore, we distinguish from the two cases that False or True decisions depend considerably on the velocity since the communication range can be an additional indicator but does not significantly impact.
Whereas Fig.16 compares the average of all OBU accuracy rates (ACC Sig ) and the rate of community accuracy (ACC Com ).
Even with three vehicles in a single community, the accuracy rate in detecting position-faking attacks can be considerably enhanced. Furthermore, comparing individual decision making with the community decision in Fig.16 shows clearly that community decision is more efficient than individual ones.

4) Sybil Attack
For the Sybil attack, only messages received simultaneously were considered in order to compare messages received in the same conditions. This resulted in a reduced number of messages considered. We plotted the number of messages received by each OBU from faked ID to establish the relationship between messages treated and accuracy. Using our algorithm, we observed that OBUs could individually detect Sybil attacks.

1) Simulation Setup
For our simulations, we used SUMO for vehicular traffic and OMNE++ for vehicular communications. Using real CAM messages with the Artery with the parameters in Table.VI Framework, we used our revocation framework to evaluate its performances.  The purpose of these simulations was to evaluate the applicability of our solution to large-scale networks. In addition, we analyze the solution's performance in terms of cybersecurity using many communication vehicles. Fig.15 shows the route reliability of our simulation configuration, reporting the number of vehicles in each stable, reliable community in our simulations. In order to better illustrate the accuracy rate of all vehicles used in our simulation, we have plotted all their accuracy rates. The Fig.16 shows all vehicles' report rates. The accuracy rate of each vehicle varies so much that it is difficult to assess the accuracy of a node. FIGURE 16. All vehicles accuracy rates evolution Fig.17, in presenting the average of all accuracy reports of individual vehicles, shows that accuracy is neither constant nor stable.
The Fig.18 shows the accuracy of our algorithm.

V. DISCUSSION
The range of communication is linked to detection accuracy. The Indicator 3 -I3-of our algorithm in section III-C could be based on several parameters: Velocity, distance, direction, yaw-rate, and weather conditions. It turned out from our previous work [8] that the most impacting parameter is velocity. Indeed, this parameter impacts the other parameters in a big way.
We have evaluated one of the most widely used datasets in V2X communication simulations, VeRiMi [1]. Although  Consequently, because hackers are always at a distance from receivers, a machine-learning model could easily make the right decision. Our dataset is more realistic and closer to reality as distance varies and RSSI levels fluctuate.
Whereas reports from individual vehicles may be unstable and vary considerably, reports using the community algorithm improve the accuracy rate.

VI. CONCLUSION AND PERSPECTIVES
This contribution corresponds to the definition of an algorithm capable of building autonomous blockchain communities to evaluate their "goodness" and thus revoking malicious vehicles in real-time. The proposed solution allows a collaborative system between individual vehicles and the structure since we cannot rely on only one in the revocation process. Although evaluated in real experimentation, the defined approach could meet the real-time requirements. We can conclude that our algorithm is more accurate than other frameworks simulated through VeriMi dataset as we have used V2X equipment in real-world conditions. Thus, our community algorithm permits using blockchain technology in vehicular communication and adds value to cyber-physical security.
Our perspective is to make a proof-of-concept by turning our algorithm into a real traffic management server and hosting a real-time blockchain to use it in our circuit. Moreover, to enhance the VeRiMi data set with more realistic data. .