# Light security scheme for Cooperative, Connected and Automated Mobility (CCAM)

Ramzi Boutahala, Hacène Fouchal, Marwane Ayaida

► To cite this version:

Ramzi Boutahala, Hacène Fouchal, Marwane Ayaida. Light security scheme for Cooperative, Connected and Automated Mobility (CCAM). Vehicular Communications, 2025, 53, pp.100892. 10.1016/j.vehcom.2025.100892. hal-04961355

HAL Id: hal-04961355

https://hal.science/hal-04961355v1

Submitted on 11 Mar 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Light security scheme for Cooperative, Connected and Automated Mobility (CCAM)

Ramzi Boutahala<sup>a, ID</sup>, Hacène Fouchal<sup>a, ID,*</sup>, Marwane Ayaida<sup>b, ID</sup>

## ARTICLE INFO

**Keywords:**

Authentication

Pseudonym certificate

Security

Clustering

Signature

C-ITS

CCAM

## ABSTRACT

Cooperative, Connected and Automated Mobility (CCAM) is a new paradigm adopted by academia and industry in order to provide safe, secure and sustainable mobility on all kinds of roads (highways, urban and rural roads). CCAM takes advantage of Cooperative Intelligent Transport Systems (C-ITS) to improve safety and to reduce traffic congestion thanks to communication and cooperation among all relevant actors (vehicle, road infrastructure, pedestrians, etc.). In Europe and the USA, adapted communication protocols have been proposed to ensure cooperation through the exchange of specific messages. In this study, we focus on the European protocols, particularly the Cooperative Awareness Messages (CAMs) as defined by the European Telecommunications Standards Institute (ETSI). CAMs are composed of a payload containing information about the vehicle status (speed, location, heading, etc.) and additional security information. This information includes a Pseudonym Certificate (PC) and a signature to guarantee the sender's authentication. However, since CAMs are sent periodically by vehicles at frequencies from 1 to 10 Hz, this addition of security data to the payload significantly increases the load and bandwidth of the communication channel. Instead of exhaustive authentication, we propose a new approach that allows vehicles to authenticate each other for the first time when they meet. Once this level of trust is reached, vehicles stop sending authenticated messages during a variable period of time (called a trust period). In addition, we propose a trust verification process to avoid malicious activities during this trust period. Our approach significantly reduces the number of signed sent CAMs, the verification and signature computations, leading to reduce communication overhead. Simulation tests conducted over the OMNET++ platform demonstrate that our approach leads to a significant decrease in communication overhead, reducing the volume of CAMs exchanged by 56%.

## 1. Introduction

The increasing number of vehicles on the world's roads, with 92 million vehicles manufactured in 2019 [1], contributes significantly to traffic congestion and environmental pollution. The World Health Organization (WHO) reports that the total number of deaths due to road accidents remains unacceptably high at approximately 1.24 million per year [2]. Many measures are being taken to reduce these problems. Indeed, the scientific community, the automotive industry, and road operators work on cooperative intelligent transport systems (C-ITS). C-ITS ensure communication between vehicles and infrastructure to alert drivers about disruptive events and provide new services that improve driving by collaborating with road infrastructure, drivers, and vehicles [8]. However, these services depend on the dissemination of specific

messages to relay information, which makes them vulnerable to cyberattacks. Thus, ensuring the integrity of these communications and authenticating the origins of the exchanged messages are essential steps for securing the system.

Relevant protocols in Europe and the United States have been proposed to ensure the exchange of specific messages. The European Telecommunications Standards Institute (ETSI) developed various standards. These include ETSI EN 302 637-2 [3,17], which defines the structure and attributes of secure Cooperative Awareness Messages (CAMs). These CAMs contain payload data for sharing vehicle status information to increase environmental awareness and also include signature hash and pseudonym certificates (PCs). Additionally, the ETSI TS 103 097 [4], [5] standards, provide the framework for security by specifying certification policies, signature procedures, and verification mecha-

<footnote><sup>a</sup> Université de Reims Champagne Ardenne, Lab-1*, Reims, 51097, France</footnote>

<footnote><sup>b</sup> Univ. Polytechnique Hauts-de-France, CNRS, Univ. Lille, UMR 8520 - IEMN, Valenciennes, F-59313, France</footnote>

<footnote>* Corresponding author.</footnote>

<footnote>E-mail addresses: ramzi.boutahala@univ-reims.fr (R. Boutahala), hacene.fouchal@univ-reims.fr (H. Fouchal), marwane.ayaida@uphf.fr (M. Ayaida).</footnote>

<footnote>https://doi.org/10.1016/j.vehcom.2025.100892</footnote>

<footnote>Received 5 May 2024; Received in revised form 23 December 2024; Accepted 1 February 2025</footnote>
nisms to ensure privacy and authentication. Each vehicle signs its CAMs using certificate [9] obtained from a Public Key Infrastructure (PKI). These CAMs are then sent periodically at frequencies from 1 to 10 Hz to ensure road safety. In the United States, Basic Safety Messages (BSMs), defined by the SAE J2735 standard for Dedicated Short-Range Communications (DSRC) and regulated under the IEEE 1609.2 standard, serve a similar purpose [6,7]. Like CAMs, BSMs are also signed with PKI-obtained certificates and are transmitted at the same frequencies.

In this study, we focus on the European standards, particularly in the CAM messages. The addition of security information, which is three times the size of the main message (payload), significantly increases the load on communication channels and bandwidth, especially when transmitted at high frequencies. To address this issue, we propose a new lightweight authentication protocol. Our approach aims to reduce Signed CAMs sent between vehicles by removing certificate and signature for all CAMs for a predefined period.

To achieve this, our approach allows vehicles to authenticate each other once to reach mutual trust, and form a cluster. Then, during a pre-defined trust period, vehicles in the cluster send only unsigned CAMs, without certificates and signatures, which leads to smoother message transmission. In addition, we have developed a mechanism for periodically checking the consistency of each vehicle's behavior based on path prediction, thus maintaining trust during the cluster period. Our approach has been implemented on the Artery framework using the OMNET++ network simulator and the SUMO road traffic simulator, demonstrating its efficiency in conditions designed to mirror real-world settings.

As a summary, our proposed lightweight authentication protocol addresses the challenges of traditional C-ITS systems by significantly reducing signed CAM messages and replacing them with unsigned CAMs, which are only sent if trust between vehicles is established, thus minimizing network overhead while maintaining security. The rest of this paper is structured as follows. Section 2 introduces related work in the field; Section 3 describes our Lightweight Authentication Mechanism in detail; Section 4 outlines the Environment Background and Application Scenarios; Section 5 discusses our simulation results; and Section 6 concludes this work and discusses potential future developments.

## 2. Related work

This section presents some important works about security for connected vehicles.

The authors of [10] presented an authentication protocol for connected vehicles that uses signature messages, eliminating the need for a central authority. This approach improves the efficiency of the authentication process by reducing the time and overhead required. However, it will rapidly increase the size of the revocation list in case of an attack since each vehicle uses multiple pseudonyms that need to be revoked if the vehicle is corrupted.

The work in [11] proposed an authentication technique called Trust-Based Authentication Technique (TBAT). This technique uses trust degrees in order to select the more convenient cluster heads. All the messages are digitally signed and encrypted by the sender using public-private key cryptography. While this technique reduces authentication time, it also significantly increases latency, which is not compatible with C-ITS.

In [12], authors propose a privacy-preserving group signature-based authentication mechanism for VANETs. To achieve this, the authors suggest dividing the network into different domains to ease certificate management. They also propose the use of Hash Message Authentication Code (HMAC) as an alternative to the traditional certificate revocation list, which can be time-consuming. Doing such, they reduce, in one hand, the time to verify the message integrity, and in the other hand the number of invalid messages. As a consequence, this reduces authentication overhead and cost.

[13] proposes a scheme to enhance the security between vehicles in such a way that when they meet, they will use for a very short time the same pseudonym certificate in order to introduce confusion for tracking. In [14], the idea of optimizing the routing of messages in urban areas, mainly junctions in cities has been proposed with less security handling.

The authors of [15] proposed an authentication mechanism that uses clustering to address the challenges of using cryptography in VANETs, where vehicle positions change frequently. The aim is to create stable and trustworthy clusters throughout the network. The mechanism also detects malicious vehicles, and cluster leaders are selected from the most trusted ones. This improves routing efficiency by using network stability and trusted cluster heads. To further increase the network security, few vehicles are selected to monitor their neighbors. In this work, asymmetric cryptography is also used. Thus, it presents the same drawbacks as the work in [11].

In the work [18], the authors presented two proposals that use cryptography to maintain privacy. The first proposal aims to prevent eavesdropping by using zone-encryption, combined with a scheme for anonymous authentication to permit only non-malicious vehicles to send messages. The main drawback of this approach is the added overhead of 224 bytes for cryptography within each message, which limits bandwidth and increases latency. The second proposal is more suitable for the vehicular environment, allowing vehicles to distribute keys among themselves. It allows vehicles, themselves, to distribute the keys. This proposal is using compact group signatures and allows to reduce the security overhead in the bandwidth with a limited impact on the cost of storage, while ensuring a high level of privacy. However, in case of malicious activity, the system is unable to perform effective traceability and revocation processes.

The authors of [19], propose a new authentication mechanism called Certificate Less Aggregate scheme based Traceable Ring Signature (CLATRS). This mechanism uses a combination of ring signature and bi-linear matching on elliptic curves, enabling it to maintain privacy and reduce the computational load considerably.

In order to reduce verification time and improve efficiency, the authors in [20] propose a new distributed collaborative authentication method. This solution reduces the burden on the RSU message verification process by leveraging the significant computational power of selected assistance verification terminals (AVTs). These AVTs participate in message verification by handling verification procedures for selected nodes within their communication range. The scheme seems to be ten times more efficient than other schemes.

Similarly, the authors in [21] proposed an efficient batch verification scheme for VANETs and compare it to other schemes described in [20], [23] and [24]. The scheme in [21] was found to be the most efficient, able to check more messages in the same amount of time and avoid overloading. However, like other batch verification schemes, it still faces the challenge of distinguishing legitimate messages from illicit ones. The verification will fail if one or more illegal messages are present in the batch of validated messages. As a result, separating illegal messages from all received messages is a critical task for the validityor and remains a significant issue in this field of research. [16] has tackled general mechanisms to make Cyber-Systems much more reliable.

In [25], the authors propose an authentication message approach that combines identity-based signature with ring signature. However, this approach has the drawback of consuming a significant amount of time for both message signing and verification. The authors of [26] also employ the use of ring signature and bi-linear pairing. They add the use of batch signature to reduce verification overhead. However, it still falls short in terms of single signature and verification efficiency. [27] focuses on designing a privacy-preserving certificateless aggregation signature scheme to reduce communication overhead by reducing the signature size. However, this scheme does not consider V2V communication, which is an important part considering the fact that vehicles have
<figure><img src="image_2.png" /><figcaption>Fig. 1. Cluster construction steps.</figcaption></figure>

less processing performance than RSUs. In [28], a hierarchical method to search for a relevant solution in a wireless sensor networks, the idea behind could be used in order to ensure the security network of vehicles. In [29], the authors present a signature scheme using an attribute-based signature system. The vehicles check that the signer's attributes satisfy complex policy conditions to verify signatures. However, this method results in a significant computational cost. The authors of [30] propose a CL-CPPA scheme for VANETs with improved signature/verification times and bandwidth. The central unit generates anonymous identifiers and partial private keys to be uploaded to the vehicles' OBUs. If the original IDs/keys are consumed, the vehicles must contact the central unit again. However, there is a negative impact on the storage of the vehicles by pre-loading anonymous identifiers and partial private keys into the OBUs.

In [31], the authors propose a scheme including the Group Key Generation Procedure and Set-up (GGPS) protocol, which allows vehicles to verify the integrity of the group key via bi-linear matching. However, this method can be complex and slow in real-world scenarios. In [32], the authors propose a signature scheme for conditional identity-based privacy-preserving authentication in V2I communications. However, the use of some mathematics tools (bi-linear maps) in this scheme involves high computational costs. In [33], the authors presented a privacy-preserving message and node authentication method that uses fog servers to improve latency and throughput. Although this approach provides better security, it has the disadvantage of high computational costs.

Finally, the authors of [34] propose a Certificateless aggregate signature (CLAS) for VANETs to minimize transmission bandwidth and signature verification costs. The proposed mechanism employs pseudonyms allocated to vehicles by the Road Side Unit (RSU) each time a vehicle enters its coverage. However, the frequent updating of pseudonyms under each RSU may result in network bandwidth consumption and signaling overhead issues. Where [22] proposes a method to change the device ID in a regular way in order to be tracked.

All the proposed approaches try to reduce the security fingerprint by proposing lightweight securing mechanisms. However, any one of them could propose to alternatively activate or switch off the signing process of messages to save the bandwidth.

<table><caption>**Table 1**
Summary of notations.</caption><tr><td>Sv</td><td>Set of neighboring vehicles</td></tr><tr><td>TVC</td><td>Table of trusted CAM vehicles</td></tr><tr><td>ASpeed</td><td>AverageSpeed</td></tr><tr><td>AHeading</td><td>AverageHeading</td></tr><tr><td>DSpeed</td><td>difference in speed</td></tr><tr><td>DHeading</td><td>difference in Heading</td></tr><tr><td>DDistance</td><td>difference in Distance</td></tr><tr><td>EDistance</td><td>Estimated Distance</td></tr></table>

### 3. Lightweight authentication mechanism

Cooperative Intelligent Transport Systems (C-ITS) allow vehicles to periodically broadcast CAM messages, which contain information about the vehicle's status, including time, position, and activated systems [35]. These CAM messages are broadcasted at an adjustable frequency between 1 and 10 Hz using the CCH channel and the IEEE 802.11p protocol, as described in [9]. It is important to notice that the size of the security overhead is three times larger than the data payload. Given the frequency with which these Signed CAMs are transmitted, this aspect has a considerable impact on the overloading of communication channels and bandwidth. In this paper, we propose a new lightweight authentication mechanism, which is illustrated in Fig. 1. The main idea is to form a cluster between authenticated neighboring vehicles. All cluster members will then communicate in a trusted environment. Instead of sending only signed CAMs, this trust will allow signed CAMs to be replaced by unsigned CAMs throughout the lifetime of the cluster. In addition, we propose a trust verification process that checks the trust established between cluster members to avoid inconsistencies or malicious activities. Each vehicle periodically monitors the behavior of its neighbors by checking the received messages. This process uses mathematical calculations that continuously measure the variation in neighbor behavior. When this variation reaches an unacceptable threshold, the vehicles stop trusting each other and switch to regular signed CAMs.

Overall, our approach reduces the number of signed CAMs exchanged while maintaining security by monitoring the behavior of all vehicles to ensure that they are not compromised. We have previously introduced this methodology with some variants in [36] and [37]. We extend them in this study. In Table 1, we show a summary of the main
<figure><img src="image_3.png" /><figcaption>Fig. 2. Diagram of the proposed lightweight authentication mechanism.</figcaption></figure>

notations used in this proposal. The main steps of the whole authenti-
cation phase including cluster creation, cluster update, and consistency
check of vehicles in the cluster, can be illustrated as follows:

3.1. Cluster construction

To form a trusted cluster, vehicles engage in a protocol at frequencies ranging from 1 to 10 Hz as they interact with each other. The procedures for these interactions, particularly for transmitting and receiving CAMs among neighboring vehicles, are visualized in Fig. 2. The core concept of our approach is to first enable vehicles to authenticate each other by verifying the validity of certificate pseudonyms and signatures associated with the CAMs received from neighboring vehicles. In the beginning, a vehicle randomly selects itself from a set of vehicles just to initiate the authentication process and build a cluster. The mechanism is based on a temporal principle. When it selects itself, it stars by sending a certification request with a specific GlobalID to start the authentication process. At that moment, all other vehicles assume that this vehicle is the one that has selected itself to start the process and follow it. Even if multiple vehicles select themselves at the same time, the first vehicle to send the certification request takes precedence as the initiator of the process. All other vehicles cancel their selection and follow the process initiated by this first vehicle. Upon successful authentication, each vehicle registers the authenticated vehicle in a Trusted Vehicles Cluster (TVC) table. Each vehicle now maintains a local view of its surroundings in the TVC table and shares a trust relationship with all neighboring vehicles that have been authenticated. This trust allows vehicles to cease transmitting their certificates and signatures, instead sending Unsigned CAMs for a specified period. Given that each vehicle maintains a local view, it's important to note that cluster memberships can vary from one vehicle to another. Every vehicle not only manages its own cluster but also participates as a member in other clusters. This flexibility in cluster formation and reconfiguration is crucial for adapting to the dynamic conditions of the road environment. The rules for the authentication process are as follows:

• All vehicles check if they have at least *s* vehicles in their SV.

* A random vehicle initiates the authentication process with the neighboring vehicles by sending an unrecognized certificate request to all its neighbors.

* When a vehicle receives the certificate request from the sender, it sends a signed CAM and registers the vehicle's sender in its TVC.

* If a vehicle receives a signed CAM, it will record the vehicle ID of the CAM in its TVC.

* When a vehicle has more than half of the vehicles in its Sv authen-
ticated, it continues the authentication process with the remaining
vehicles that are not yet included in its TVC.

**Algorithm 1 Authentication process.**

Require: CAM message

Ensure: UnsignedCAM message, SignedCAM message

1: Initialize: TVC ← ∅, Sv ← ∅, Self Chosen ← False, GlobalID ← 111111

2:

3: PeriodicProcedure()

4: if Size(Sv) ≥ N and IsEmpty(TVC) then

5: if RandomlyDecidedToStartAuthentication() then

6: SendRequestCertificate(GlobalID)

7: Self Chosen ← True

8: end if

9: else

10: Send(UnsignedCAM)

11: end if

12: if not Self Chosen and Size(TVC) > Size(Sv)/2 then

13: for all Vi in Sv and not in TVC do

14: SendRequestCertificate(Vi)

15: end for

16: end if

17:

18: Upon receive(CAM)

19: if SignedCam then

20: if CheckValidity(CAM) and CAM-stationID $\notin$ TVC then

21: TVC $\leftarrow$ TVC $\cup$ {CAM-stationID}

22: end if

23: end if

24: if SignedCAM-with-request then

25: if CheckValidity(CAM) and self.StationID = CAM.requestID then

26: Send(SignedCAM)

27: end if

28: end if

29: if CAM-stationID $\notin$ Sv then

30: Sv $\leftarrow$ Sv $\cup$ {CAM-stationID}

31: end if

**Algorithm 2 Initiating trusted environment.**

Require: Sv, TVC, TrustEnvPeriod (Trust Environment Period)

1:

2: PeriodicInitiateTrustedEnvironment()

3: if Sv == TVC then

4: StartPeriod(TrustEnvPeriod)

5: while WithinPeriod(TrustEnvPeriod) do

6: PeriodicallySendUnsignedCAM()

7: end while

8: end if

Algorithms 1 and 2 detail the steps vehicles follow in the authen-
tication process. Initially, we have several key variables: TVC which
is a set of trusted vehicles in a cluster, Sv which is a Set of Vehi-
<figure><img src="image_4.png" /><figcaption>Fig. 3. Construction of the TVCs.</figcaption></figure>

cles, *Self Chosen*, which indicates whether the vehicle has chosen itself to initiate the authentication process, and the global vehicle identifier *GlobalID*. During this trust cluster-building stage, each vehicle periodically checks whether the number of neighboring vehicles in *Sv* is sufficient to create a trusted cluster with them. Then, it may randomly decide to initiate the authentication process by sending a global certificate request using a six-digit *GlobalID*. When they receive this request in *Upon Recieve*, the vehicles respond with their signed CAMs. Upon receipt of CAMs, vehicles update their *TVC* and *Sv*. If a valid signed CAM is received from a vehicle not already in the *TVC*, the vehicle is added to the *TVC*. For reasons of high mobility, our algorithm ensures that if a vehicle is not self-selected, it continues the authentication process if the size of its *TVC* exceeds half the total number of *Sv*, so our algorithm guarantees that all vehicles participate in the authentication process. All vehicles run Algorithm 2 when the authentication process is complete. Each vehicle first checks whether the list of *Sv* is equal to the list of *TVC*. If the two lists are identical, the period defined by *Trust Env Period* begins. During this period, the vehicle periodically sends unsigned CAM messages.

Fig. 3 demonstrates the process of authenticating three vehicles, A, B, and C, upon their initial encounter on the road. To begin, they exchange unsigned CAMs and register their neighbors in their *SV* table. Then, vehicle B randomly selects itself to initiate the authentication process by sending signed CAMs with a request for a certificate from its neighbors. Vehicles A and C receive the request from B and, as a first step, register B as an authenticated, trusted vehicle in their *TVC*. They then broadcast their own signed CAMs with their certificates to complete the authentication process. At this point, all vehicles have authenticated their neighbors and their *SV* and *TVC* tables are identical. From this point forward, they can trust each other to exchange unsigned CAMs. This scenario demonstrates how our architecture ensures that all members of a cluster are authenticated and trusted before they can participate in the exchange of unsigned CAMs.

## 3.2. Cluster update

Our architecture takes into account the high mobility of vehicles and the limited range of communication, which can cause frequent changes in cluster membership. After completing the initial trust-building authentication, vehicles switch to sending unsigned CAMs for a specific period. During this trust period, vehicles are alert to any changes in the cluster, such as vehicles leaving or joining it. To handle these changes, the algorithm monitors the communication range of each vehicle and adjusts the cluster membership accordingly. When a vehicle A moves out of range of a trust cluster of another vehicle B, it will be removed from the group of vehicle B. Similarly, when a new vehicle enters into the range of an existing cluster, it will be added as a member into the trust cluster. The *SV* and *TVC* tables then reflect these membership changes, ensuring that each vehicle has current information about its neighbors. Our architecture updates the *SV* and *TVC* tables in response to two conditions:

* If a vehicle fails to send a CAM within a specified time *K seconds*, all vehicles delete it from their *TVC*.

* When a new vehicle joins an existing trusted cluster, the members of this cluster start a new authentication process to ensure that all cluster members are authenticated and trusted:

- The first vehicle that detects the presence of a new vehicle, it immediately sends to it a signed CAM with a certificate request.

- The new vehicle responds by sending its own signed CAM and records the Sender ID in its *TVC*.

- If a vehicle receives a signed CAM during this process, it registers the Sender ID in its *TVC*.

- If a vehicle encounters neighbors which do not form a trusted cluster, it will execute the authentication process.

* In the trusted cluster period, each vehicle periodically checks the behavior of its trusted neighbors. If it detects suspicious behavior, it stops trusting and requests its certificate.
**Algorithm 3** Update of the TVCs.

**Require:** Sv, TVC, Last-receive-CAM-time, Threshold Tn

**Ensure:** Updated Sv, TVC

1: if Sv ≠ TVC then

2: for all $Vi \in Sv$ and $Vi \notin TVC$ do

3: SendRequestCertificate($Vi$)

4: end for

5: end if

6: for all $Vi \in Sv$ and $Vi \notin TVC$ do

7: if Last-receive-CAM-time($Vi$) > Tn then

8: $Sv \leftarrow Sv \setminus \{Vi\}$

9: TVC $\leftarrow$ TVC $\setminus \{Vi\}$

10: end if

11: end for

The dynamics of the trust environment in our approach are detailed in Algorithm 3, which takes the TVC and SV lists as parameters. Each vehicle checks that all its neighbors are authenticated by reviewing its SV list. If it encounters any new vehicles that have not been authenticated, it requests their certificates. Additionally, the algorithm assesses whether vehicles in the SV and TVC lists have not sent CAMs within a specified time slot, exceeding a threshold Tn. Vehicles surpassing this threshold are removed from both the SV and TVC lists.

Fig. 4 illustrates a sequence diagram of a cluster update scenario in which vehicle D joins a cluster containing vehicles A, B, and C. Upon detecting the presence of vehicle D, the other vehicles initiate the authentication process by sending signed CAMs containing a request for a certificate. Vehicle D responds by verifying the validity of its certificate and broadcasting its own signed CAM. Upon receiving the signed CAMs, all vehicles authenticate their new neighbor and update their TVC tables to include vehicle D. This scenario shows how our architecture ensures that all cluster members continually update the SV and TVC tables to reflect changes in cluster membership.

### 3.3. Trust management

Our authentication mechanism allows vehicles to send unsigned CAMs within a trust cluster to reduce security information. To do that each vehicle has to trust its neighbors, in this section, we propose a process to evaluate this trust periodically and to maintain the security of our system. This involves a continuous analysis to monitor the behavior of vehicles in their trust environment. Periodically, each vehicle evaluates the data received from its neighbors, such as speed, heading, and position, to predict their trajectories and compare them with actual data. By constantly checking the consistency of this information, the vehicle can detect any anomalies or malicious activity. The main idea behind this process is to check whether the vehicle has been compromised in this trust cluster or not. This process, integrated into each vehicle, prevents malicious actors from infiltrating the trust cluster and guarantees the security of the information exchange. By constantly checking the trust of its neighbors, our approach enables efficient and secure information exchange. Fig. 5 outline this process, which enables each vehicle to verify the trust established during the authentication phase.

Algorithm 4 details the steps vehicles follow during the consistency check process. Initially, several key variables are defined: TVC, which is a table of trusted vehicles in a cluster; N, a factor indicating the time interval between each check; and ε and δ, thresholds that determine whether the estimated data are close to the actual data. Following the creation of the trust cluster, each vehicle initializes its parameters. Throughout its operational period, it executes the ConsistencyCheck() function every N seconds. For each Vi vehicle in the TVC, it estimates the distance EDistance to be covered by the vehicle in period N, using the vehicle's current speed CurrentSpeed. It then records the vehicle's current heading AHeading. During the consistency check, each vehicle calculates, for all its neighbors in the TVC, the difference in heading DHeading between the estimated heading AHeading and the actual heading RealHeading of the vehicle; in addition, it calculates the difference in distance DDistance between the estimated distance EDistance and the actual distance RealDistance traveled by the vehicle. Then, they update its two parameters EDistance and AHeading. If the values calculated for each vehicle DDistance and DHeading exceed a defined threshold, the vehicle data will be considered inconsistent, and they will request their certificate.

**Algorithm 4** Vehicle consistency check.

**Require:** Nodes Vi in TVC, N, ε, δ

**Ensure:** Updated TVC, Vehicles requiring certificates

1: initialization()

2: for each $Vi \in TVC$ do

3: EDistance[$Vi$] ← CurrentSpeed() * N

4: AHeading[$Vi$] ← CurrentHeading()

5: end for

6: ConsistencyCheck()

7: for each $Vi$ in TVC do

8: DHeading ← | AHeading[$Vi$] - RealHeading[$Vi$] |

9: DDistance ← | EDistance[$Vi$] - RealDistance[$Vi$] |

10: EDistance[$Vi$] ← CurrentSpeed() * N

11: AHeading[$Vi$] ← RealHeading[$Vi$]

12: if DHeading > δ or DDistance > ε then

13: SendRequestCertificate($Vi$)

14: Delete $Vi$ from TVC

15: end if

16: end for

Our rules for trust management are as follows:

$$|ED - CD| < d \qquad (1)$$

* Each vehicle compares the estimated heading for a future time t+N (called AHeading) with the actual heading at that time for each trusted neighbor in its TVC.

$$|AHeading - RealHeading| < \epsilon \qquad (2)$$

* Each vehicle compares the estimated distance (ED) using the speed at the moment t = k with the average distance calculated at the instant t = k + n of all its neighbors.

$$ED = V_k * (k + n) \qquad (3)$$

The calculated distance CD between two points A and B:

$$CD = \arccos[\sin(\delta A) * \sin(\delta B) + \cos(\delta A) * \cos(\delta B) * \cos(d\gamma)] * 6374, \qquad (4)$$

where, δ is the vehicle's latitude and γ is the vehicle's longitude and dγ is defined as:

$$d\gamma = \gamma B - \gamma A \qquad (5)$$

from (2) and (3), one can obtain:

Our trust management process is periodically executed at intervals of N time units. During these intervals, each vehicle compares the heading of its trusted neighbors (RealHeading) to the estimated heading (AHeading) of all the neighbors in its TVC. The vehicle also estimates the distance it will travel over the next N time units using its current speed (ED) and compares this to the average distance traveled by its neighbors over the same period of time. If the difference between these values is less than a predefined threshold value d, the data is considered consistent. If any of the data is found to be inconsistent, a certificate request is sent to the inconsistent vehicles.

One advantage of this approach is that each vehicle checks the CAMs of a group of neighboring vehicles that may not be identical to the groups checked by other vehicles. This allows each vehicle to be checked multiple times with different parameters, increasing the security of the system. Fig. 6 illustrates a scenario where the consistency of a vehi-
TVC update

<figure><img src="image_5.png" /><figcaption>Fig. 4. Updating tables.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 5. Diagram of the inconsistency detection process for the proposed architecture.</figcaption></figure>
The consistency verification process

<figure><img src="image_7.png" /><figcaption>Fig. 6. Checking the consistency of neighbors.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 7. A4 highway Paris Reims simulation.</figcaption></figure>

cle's neighbors is being checked. Vehicle *D* has taken a different route than vehicles *A*, *B*, and *C*. An attacker notices that vehicle *D* is about to leave the trusted cluster and decides to steal its identity by sending unsigned CAMs with the *stationID* of vehicle *D*. Upon receiving these CAMs, vehicles *A*, *B*, and *C* realize that the attacker's data is inconsistent with the previous data generated by vehicle *D*. They therefore send a certificate request to the attacker, which is unable to complete the authentication process.

In another scenario, vehicles *A* and *B* notice that the data from vehicle *C* is inconsistent with previous data due to suspicious movement. They send an unrecognized certificate request to vehicle *C*, which initiates the authentication process and sends its signed CAM. This reestablishes trust between the vehicles. It is worth noting that our trust management process is periodic, occurring at intervals of *n* time units. This allows each vehicle to be checked multiple times with different parameters, enhancing the overall security of the system.
<figure><img src="image_9.png" /><figcaption>Fig. 8. Inconsistencies detected for Configuration 1, 2, and 3.</figcaption></figure>

## 4. Environment background and application scenarios

Our proposed architecture was successfully demonstrated using Artery [38], an open-source simulation framework for the Omnet++ simulator [39]. By integrating it with the Simulation of Urban Mobility (SUMO) [40], Artery allows for real-time communication of road traffic data throughout the simulation process. The Omnet++ Traci Manager module continuously retrieves information about vehicles, such as location and speed, through a TCP connection, enabling Artery to update and adjust the current conditions of each vehicle.

A middleware module utilizes this data to provide advanced ITS G5 services, such as CAM and decentralized notifications (DENM), which are then transmitted to lower layers. Artery employs ETSI ITS-G5 protocols from the VANETZA framework, including GeoNetworking, Transport, and Security. Each vehicle is provided with an ITS-G5 instance, which allows for the selection of a routing algorithm, the encapsulation, signing, and signature integration to packets prior to their transmission to the IEEE 802.11 physical and link layers of the VEINS or INET frameworks. Additionally, this instance enables vehicles to validate the signatures of incoming packets, and to decapsulate them prior to their transmission to the upper layers of Artery.

In summary, our proposed architecture is tested and evaluated using the open-source Artery simulation framework, integrated with SUMO, to simulate realistic traffic scenarios and provide real-time data for ITS-G5 services. The architecture also includes a routing algorithm selection mechanism and security features to ensure secure communication. This combination of simulation allows for a comprehensive evaluation of the performance and effectiveness of our approach.

To evaluate our approach, several scenarios and datasets were used to determine the effectiveness of our approach in reducing the overhead of vehicle-to-vehicle communication. First, we selected the A4 Reims-Paris Highway in France as our test highway. Using OpenStreetMap, we retrieved real-world data that accurately represented the road infrastructure of the A4 highway, as shown in Fig. 7. After integrating the Highway into SUMO, we generated the flow of vehicles on this highway. In order to offer more possibilities and get closer to real-life conditions, we prepared five possible flows of 50 vehicles in one direction from Reims to Paris. Please note that we have configured the SUMO module to make vehicles moving using a sigma value of 0.5, which indicates a moderate level of random variation in each vehicle's speed. Table 2,

<table><caption>Table 2
Vehicle flow configuration for scenarios.</caption><thead><tr><td>Flux</td><td>No. of vehicles per group</td><td>Separation (km)</td></tr></thead><tbody><tr><td>Flow 1</td><td>5</td><td>5</td></tr><tr><td>Flow 2</td><td>10</td><td>10</td></tr><tr><td>Flow 3</td><td>10</td><td>5</td></tr><tr><td>Flow 4</td><td>10</td><td>10</td></tr><tr><td>Flow 5</td><td>5-10</td><td>5-10</td></tr></tbody></table>

<table><caption>Table 3
Table of configurations with Heading and Distance.</caption><thead><tr><td>Configuration</td><td>Heading</td><td>Distance</td></tr></thead><tbody><tr><td>Configuration 1</td><td>1°</td><td>1 m</td></tr><tr><td>Configuration 2</td><td>1°</td><td>5 m</td></tr><tr><td>Configuration 3</td><td>1°</td><td>10 m</td></tr><tr><td>Configuration 4</td><td>5°</td><td>1 m</td></tr><tr><td>Configuration 5</td><td>5°</td><td>5 m</td></tr><tr><td>Configuration 6</td><td>5°</td><td>10 m</td></tr><tr><td>Configuration 7</td><td>10°</td><td>1 m</td></tr><tr><td>Configuration 8</td><td>10°</td><td>5 m</td></tr><tr><td>Configuration 9</td><td>10°</td><td>10 m</td></tr></tbody></table>

describe the 5 different flows used in our test simulations. In the context of our use of artery, We implemented our approach, to create the trust cluster between vehicles, and set up the process to detect inconsistencies in CAM messages. In order to evaluate this process and see how effective it is at detecting inconsistencies in vehicle behavior, we used several configurations as shown in Table 3. In summary, in this work we have 9 scenarios to evaluate in our simulation environment. Each scenario represents a configuration of our process in the 5 data flows on the A4 Highway from Reims to Paris. In our proposal, we have not investigated the minimum required number of vehicles in a cluster. However, in the simulation, we have considered three vehicles to be sufficient to initiate the authentication process.
<figure><img src="image_10.png" /><figcaption>Fig. 9. Inconsistencies detected for Configuration 4, 5, and 6.</figcaption></figure>

<figure><img src="image_11.png" /><figcaption>Fig. 10. Inconsistencies detected for Configuration 7, 8, and 9.</figcaption></figure>

<table><caption>**Table 4**
Simulation parameters.</caption><thead><tr><td>Parameter</td><td>Value</td></tr></thead><tbody><tr><td>Network simulator</td><td>OMNET++</td></tr><tr><td>Road traffic simulator</td><td>SUMO</td></tr><tr><td>Framework</td><td>Artery (Vanetza, INET, Veins)</td></tr><tr><td>Number of nodes</td><td>500</td></tr><tr><td>CAM message interval</td><td>0.1 s</td></tr><tr><td>Carrier Frequency</td><td>5.9 GHz</td></tr><tr><td>Number of channels</td><td>180</td></tr><tr><td>Transmitter power</td><td>20 mW</td></tr><tr><td>Simulation time</td><td>1000 s</td></tr><tr><td>Highway length</td><td>150 km</td></tr><tr><td>Speed of vehicles</td><td>120 KM/H</td></tr><tr><td>Flow of vehicles</td><td>5</td></tr><tr><td>scenario configuration</td><td>9</td></tr></tbody></table>

## 5. Evaluation and results

To fully understand the effectiveness of our approach, we ran 45 separate simulations using the simulation parameters summarized in Table 4. Each scenario in Table 3 was applied to the five possible traffic flows. Then, for each scenario, we calculate the average result obtained in the 5 traffic flows used. Then, we applied the current ETSI standard protocols in a scenario with the 5 traffic flows. We calculated the size of CAM messages exchanged between vehicles. We then compared the results obtained in our 9 scenarios with the C-ITS standard.

In order to compare these configurations, we have collected and calculated the results, so as to compare all the possibilities between them. In this context, we analyzed configurations 1, 2 and 3 in parallel. Similarly, configurations 4, 5 and 6 were analyzed together, as
<figure><img src="image_12.png" /><figcaption>Fig. 11. Inconsistencies detected for Configuration 3, 6, and 9.</figcaption></figure>

<figure><img src="image_13.png" /><figcaption>Fig. 12. Comparison between C-ITS and Configuration 1, 2, and 3.</figcaption></figure>

were configurations 7, 8 and 9. In addition, we explored cross-sectional comparisons involving configurations 3, 6 and 9.

These parameters are used as thresholds to detect inconsistencies. We changed the frequency of consistency checks and the thresholds in all scenarios to understand the impact of our consistency check process on the overall effectiveness of our approach and to better understand how the consistency check process can be optimized. The frequency of consistency checks for vehicles was set to 1 second in all scenarios.

Our proposed architecture was evaluated by calculating the average number of inconsistent CAMs for different traffic flows for each scenario; the results show the evolution of CAM messages that were considered inconsistent among vehicles every second. These results do not represent the number of inconsistencies that happen but the number of inconsistencies detected by all vehicles.

Fig. 8, associated with configurations 1, 2, and 3, demonstrates a fixed heading of 1° with varying distances of 1 m, 5 m, and 10 m. Fig. 9, corresponding to configurations 4, 5, and 6, features a fixed heading of 5° and varying distances of 1 m, 5 m, and 10 m. Fig. 10, related to configurations 7, 8, and 9, presents a fixed heading of 10° with distances of 1 m, 5 m, and 10 m varied. Lastly, Fig. 11 focuses on configurations 3, 6, and 9, where the distance is consistently set at 10 meters, and the heading thresholds are adjusted to 1°, 5°, and 10°.

These figures highlight the inconsistencies observed in different configurations. Firstly, the number of detections decreases over time in all figures, as vehicles move further apart, reducing the number of vehicles per cluster. As a result, one inconsistency is detected by fewer vehicles. This explains why the number of inconsistencies detected decreases over
<figure><img src="image_14.png" /><figcaption>Fig. 13. Comparison between C-ITS and Configuration 4, 5, and 6.</figcaption></figure>

<figure><img src="image_15.png" /><figcaption>Fig. 14. Comparison between C-ITS and Configuration 7, 8, and 9.</figcaption></figure>

time: with fewer vehicles in each cluster, the opportunities for an inconsistency to be observed by several vehicles are reduced.

From these figures, we observe that an increase in both heading and distance thresholds results in fewer detected inconsistencies. Notably, when the distance threshold is set at 10 m in Fig. 11, we observe that the number of inconsistencies is relatively low compared to scenarios where the distance is varied. The impact of adjusting distance thresholds is more significant than that of changing the heading alone, which suggests that modifications in distance substantially affect the frequency of inconsistencies.

In the context of studying the effectiveness of our approach in reducing the volume of data exchanged between vehicles compared with the architecture used in the C-ITS standard. We show here the results of our simulation. First, we collected for each scenario, the signed and

unsigned messages exchanged every second between vehicles. Then we calculated the size of these CAMs. In accordance with the C-ITS standard, we considered the size of a signed CAMs to be 300 bytes and that of an unsigned CAM to be 100 bytes.

Fig. 12 to 15, show the differences in the cumulative sizes of messages exchanged every second between the C-ITS architecture and our approach. Then, the figures Fig. 16 to 19 represent the size reduction of messages exchanged that our approach has achieved every second during the simulations. These figures represent all the configurations used in the simulation, where the heading and distance parameters are modified.

We observe for all configurations a variation in message size between two intervals: from 30 s to 400 s and from 400 s to 1000 s. This can be explained by the fact that vehicles are moving further apart and adopt-
<figure><img src="image_16.png" /><figcaption>Fig. 15. Comparison between C-ITS and Configuration 3, 6, and 9.</figcaption></figure>

<figure><img src="image_17.png" /><figcaption>Fig. 16. Size difference to C-ITS for Configuration 1, 2, and 3.</figcaption></figure>

ing different behaviors. This means that the further apart the vehicles are, the fewer messages they exchange. This leads to a reduction in the volume of data exchanged, both in the C-ITS standard and in our approach. Furthermore, our method has effectively reduced the size of the messages exchanged. This difference is particularly noticeable in the first phase, which is reduced from 30 s to 400 s. This difference is smaller compared to the second phase, from 400 s to 1000 s. This is due to the fact that when vehicles are close to each other, the inconsistency detected by our model is observed by many vehicles. This means that the same inconsistency is detected by different vehicles. For example, a single vehicle among them sends a signed message request, and a single response is then transmitted to all of them. However, when vehicles are far apart, the inconsistencies detected are between different distant vehicles. This can lead to multiple certificate requests.

The figures also show that the inconsistency detection process affects the reduction in signed messages exchanged between vehicles. The best

results were obtained for configuration 9, as fewer messages were detected due to its filter thresholds: 10 m for distance and 10° for heading. We note that the more we increase these parameters, the fewer inconsistencies are identified by the detection process. This means that the estimations made by each vehicle, concerning the heading and distance of all its neighbors, lie within the range determined by these thresholds. Our approach notably reduced the size of the exchanged messages by 56.89% in configuration 9. This significant reduction plays a crucial role in minimizing the risk of communication channel overload.

Fig. 20 and Table 5 show the percentage reduction in the volume of data exchanged between vehicles throughout the simulation, achieved by our architecture in different configurations compared with standard C-ITS. On average, our architecture reduced the volume of data exchanged by 56%, which can be explained by the fact that vehicles send fewer signed CAMs, which are replaced by unsigned messages.
<figure><img src="image_18.png" /><figcaption>Fig. 17. Size difference to CITS for Configuration 4, 5, and 6.</figcaption></figure>

<figure><img src="image_19.png" /><figcaption>Fig. 18. Size difference to C-ITS for Configuration 7, 8, and 9.</figcaption></figure>

<table><caption>**Table 5**
Reduction percentage for different configurations.</caption><thead><tr><th rowspan="2">H Value</th><th colspan="3">D Value</th></tr><tr><th>1</th><th>5</th><th>10</th></tr></thead><tbody><tr><td>1</td><td>48.08%</td><td>45.81%</td><td>52.68%</td></tr><tr><td>5</td><td>47.66%</td><td>45.74%</td><td>53.64%</td></tr><tr><td>10</td><td>47.15%</td><td>45.36%</td><td>56.89%</td></tr></tbody></table>

## 6. Conclusion

In this work, we proposed a solution to avoid the risk of communication channel overload in C-ITS. Contrary to the ETSI protocols, which define the security standards for C-ITS, and consider a exhaustive strategy. Our approach exploits the intelligent potential that arises when vehicles collaborate as a group rather than as a pair of individuals to leverage these standards in a selective protocol. We show that

using this strategy, it is possible to significantly reduce the number of authentications required while ensuring security with real-time consistency checking. We evaluated and compared our approach using several settings with the C-ITS architecture. For this purpose, we performed simulations with high-density highway conditions using the C-ITS standard, which includes ETSI ITS-G5. Our approach effectively reduces network overhead, which does not explode in dense networks as was the case with the exhaustive approach. The results show that the resource utilization of our approach is better optimized, reducing the size of message exchanges between vehicles by more than half. In addition, our method is more efficient in terms of processing time, resulting in lower latency compared to the current exhaustive approach. Our approach is a robust solution that provides a high level of security through a real-time consistency checking process. There is a lot of knowledge in our process analysis that could be studied, which is another avenue to explore. Moreover, we intend to strengthen the authentication and consistency checking processes of our system, as well as evaluate its resilience to various types of cyber attacks.
Size Difference to CITS for Configuration 9, Configuration 6, Configuration 3 from Time 30 to 1000

<figure><img src="image_20.png" /><figcaption>Fig. 19. Size difference to CITS for Configuration 3, 6, and 9.</figcaption></figure>

<figure><img src="image_21.png" /><figcaption>Fig. 20. Percentage reduction in the volume of data exchanged between vehicles.</figcaption></figure>

CRediT authorship contribution statement

**Ramzi Boutahala:** Writing – original draft, Validation, Software.
**Hacène Fouchal:** Writing – review & editing, Validation, Methodology, Conceptualization.
**Marwane Ayaida:** Writing – review & editing, Validation, Formal analysis.

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Acknowledgement

This work was made possible by EC Grant No 2018-FR-TM-0097-S from the INEA Agency for the InDiD project. The statements made herein are solely the responsibility of the authors.

Data availability

Data will be made available on request.

References

[1] Car production: number of cars produced worldwide 2018 – statista, https://www.statista.com/statistics/262747/worldwide-automobile-production-since-2000/. (Accessed 24 January 2021).

[2] World Health Organization (WHO), Global Status Report on Road Safety 2013, Technical Report, World Health Organization (WHO), Geneva, Switzerland, 2013.

[3] ETSI, TCITS, Intelligent transport systems (its); vehicular communications; basic set of applications; part 2: Specification of cooperative awareness basic service, Draft ETSI TS, 2011, vol. 20, no. 2011, pp. 448–451.

[4] ETSI, T. S. 103 097: Intelligent Transport Systems (ITS); Security; Security header and certificate formats. Technical specification, European Telecommunications Standards Institute, 2013.

[5] ETSI, T. S. 103 097 v1. 3.1-Intelligent Transport Systems (ITS); Security; Security header and certificate formats. Technical specification, European Telecommunications Standards Institute, 2017.
[6] Dedicated Short Range Communications (DSRC) Message Set Dictionary: J2735, Society of Automotive Engineers International, Warrendale, Pa, 2009.

[7] IEEE 1609 WORKING GROUP, et al., IEEE standard for wireless access in vehicular environments-security services for applications and management messages, IEEE Std. 1609 (2) (2016).

[8] A. Alnasser, H. Sun, J. Jiang, Cyber security challenges and solutions for v2x communications: a survey, Comput. Netw. 151 (2019) 52-67.

[9] B. Lonc, P. Cincilla, Cooperative its security framework: standards and implementations progress in Europe, in: 2016 IEEE 17th International Symposium on A World of Wireless, Mobile and Multimedia Networks (WoWMoM), IEEE, 2016, June, pp. 1-6.

[10] Xiaodong Lin, Xu Li, Achieving efficient cooperative message authentication in vehicular ad hoc networks, IEEE Trans. Veh. Technol. 62 (7) (2013) 3339-3348.

[11] R. Sugumar, A. Rengarajan, C. Jayakumar, Trust based authentication technique for cluster based vehicular ad hoc networks (VANET), WIREL. NETW. 24 (2018) 373-382, https://doi.org/10.1007/s11276-016-1336-6.

[12] Xiaoyan Zhu, Shunrong Jiang, Liangmin Wang, et al., Efficient privacy-preserving authentication for vehicular ad hoc networks, IEEE Trans. Veh. Technol. 63 (2) (2013) 907-919.

[13] Boubakeur Moussaoui, Noureddine Chikouche, Hacène Fouchal, An efficient privacy scheme for C-ITS stations, Comput. Electr. Eng. 107 (2023) 108613.

[14] Tawfik Nebbou, Mohammed Lehsaini, Hacène Fouchal, Partial backwards routing protocol for VANETs, Veh. Commun. 18 (2019) 100162.

[15] Fatemehsadat Mirsadeghi, Marjan Kuchaki Rafsanjani, Brij B. Gupta, A trust infrastructure based authentication method for clustered vehicular ad hoc networks, Peer-to-Peer Netw. Appl. 14 (4) (2021) 2537-2553.

[16] T. Sanislav, S. Zeadally, G. Mois, H. Fouchal, Multi-agent architecture for reliable Cyber-Physical Systems (CPS), in: 2017 IEEE Symposium on Computers and Communications (ISCC), 2017, pp. 170-175.

[17] ETSI, E. N. 302 637-2 v1. 3.1-intelligent transport systems (its); vehicular communications; basic set of applications; part 2: Specification of cooperative awareness basic service. ETSI, Sept, 2014.

[18] J. Camenisch, M. Drijvers, A. Lehmann, G. Neven, P. Towa, Zone encryption with anonymous authentication for V2V communication, in: 2020 IEEE European Symposium on Security and Privacy (EuroS&P), 2020, pp. 405-424.

[19] Samra Bouakkaz, Fouzi Semchedine, New efficient certificateless scheme-based conditional privacy preservation authentication for applications in VANET, Veh. Commun. (ISSN 2214-2096) (2021) 100414.

[20] F. Wu, X. Zhang, C. Zhang, X. Chen, W. Fan, Y. Liu, Batch-assisted verification scheme for reducing message verification delay of the vehicular ad hoc networks, IEEE Internet Things J. 7 (9) (Sep. 2020) 8144-8156.

[21] Y.M. Lai, P.J. Cheng, An Efficient Pairing-free Batch Verification Scheme for VANET, 2021.

[22] H. Fouchal, J. Biesa, E. Romero, A. Araujo, Octavio Taladrez, A security scheme for wireless sensor networks, in: 2016 IEEE Global Communications Conference (GLOBECOM), 2016, pp. 1-5.

[23] A.K. Sutraла, P. Bagga, A.K. Das, N. Kumar, J.J. Rodrigues, P. Lorenz, On the design of conditional privacy preserving batch verification-based authentication scheme for Internet of vehicles deployment, IEEE Trans. Veh. Technol. 69 (5) (2020) 5535-5548.

[24] N.B. Gayathri, G. Thumbur, P.V. Reddy, M.Z.U. Rahman, Efficient pairing-free certificateless authentication scheme with batch verification for vehicular ad-hoc networks, IEEE Access 6 (2018) 31808-31819.

[25] J. Li, Y. Liu, Z. Zhang, B. Li, H. Liu, J. Cheng, Efficient ID-based message authentication with enhanced privacy in wireless ad-hoc networks, in: 2018 International Conference on Computing, Networking and Communications (ICNC), IEEE, 2018, March, pp. 322-326.

[26] F. Liu, Q. Wang, IBRS: an efficient identity-based batch verification scheme for VANETs based on ring signature, in: 2019 IEEE Vehicular Networking Conference (VNC), IEEE, 2019, December, pp. 1-8.

[27] J. Cui, J. Zhang, H. Zhong, R. Shi, Y. Xu, An efficient certificateless aggregate signature without pairings for vehicular ad hoc networks, Inf. Sci. 451 (2018) 1-15.

[28] H. Fouchal, Z. Habbas, Distributed backtracking algorithm based on tree decomposition over wireless sensor networks, Concurr. Comput. Pract. Exp. 25 (5) (2013) 728-742.

[29] Q. Huang, Y. Yang, Y. Shi, SmartVeh: secure and efficient message access control and authentication for vehicular cloud computing, Sensors 18 (2) (2018) 666.

[30] X. Zhou, M. Luo, P. Vijayakumar, C. Peng, D. He, Efficient certificateless conditional privacy-preserving authentication for VANETs, IEEE Trans. Veh. Technol. 71 (7) (2022) 7863-7875.

[31] B. Palaniswamy, S. Camtepe, E. Foo, L. Simpson, M.A.R. Baee, J. Pieprzyk, Continuous authentication for VANET, Veh. Commun. 25 (2020) 100255.

[32] I. Ali, F. Li, An efficient conditional privacy-preserving authentication scheme for Vehicle-To-Infrastructure communication in VANETs, Veh. Commun. 22 (2020) 100228.

[33] S.A. Soleymani, S. Goudarzi, M.H. Anisi, M. Zareei, A.H. Abdullah, N. Kama, A security and privacy scheme based on node and message authentication and trust in fog-enabled VANET, Veh. Commun. 29 (2021) 100335.

[34] X. Yang, C. Chen, T. Ma, Y. Li, C. Wang, An improved certificateless aggregate signature scheme for vehicular ad-hoc networks, in: 2018 IEEE 3rd Advanced Information Technology, Electronic and Automation Control Conference (IAEAC), IEEE, 2018, October, pp. 2334-2338.

[35] A. Alnasser, H. Sun, J. Jiang, Cyber security challenges and solutions for V2X communications: a survey, Comput. Netw. 151 (2019) 52-67.

[36] R. Boutahala, H. Fouchal, M. Ayaida, An efficient approach to reduce the security messages overload on C-ITS, in: ICC 2022-IEEE International Conference on Communications, IEEE, 2022, May, pp. 1500-1505.

[37] R. Boutahala, M. Ayaida, H. Fouchal, Reducing security overhead in the context of connected vehicles, in: GLOBECOM 2022-2022 IEEE Global Communications Conference, IEEE, 2022, December, pp. 4304-4309.

[38] R. Riebl, H. Günther, C. Facchi, L. Wolf, Artery: extending veins for VANET applications, in: 2015 International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS), 2015, pp. 450-456.

[39] A. Varga, The omnet++ discrete event simulation system, in: Proceedings of the European Simulation Multiconference, June 2001, 2001, pp. 319-324 [Online]. Available: https://ci.nii.ac.jp/naid/20001036826/en/.

[40] D. Krajzewicz, G. Hertkorn, C. Rössel, P. Wagner, Sumo(simulation of urban mobility) - an open-source traffic simulation, in: A. Al-Akaidi (Ed.), 4th Middle East Symposium on Simulation and Modelling, 2002, pp. 183-187, LIDO-Berichtsjahr = 2004 [Online]. Available: https://elib.dlr.de/6661/.