A Timed Efficient Stream Loss-Tolerant Authentication Protocol for IoV Cybersecurity

The Internet of Things (IoT) is a dynamic network infrastructure that allows physical devices, like sensors, actuators, embedded systems and basic devices, to capture, exchange and act on information about other vehicles and roadside infrastructure (V2I) without human interaction [1]. The Internet of Vehicles (IoV) is a vital part of the IoT that comprises a network of internet-enabled vehicles that can include a range of sensors that share data with other vehicles and roadside infrastructure (V2I) [2]. The IoV is one of the most promising technologies of this fast-paced technology age [3]. It has changed the entire vehicle market, both in terms of vehicle performance and connectivity [4]. Vehicle management and data sharing is leading vehicle communications, but also introduces major vulnerabilities to network and cyber security that could impact data security, privacy, integrity and availability, and then the safety of vehicle occupants [5]. IoV vehicles are exposed to many vulnerabilities associated with the internet. Hazardous and unsafe conditions expose vehicles to significant security risks during their interactions with infrastructure and cloud computing [6]. Verifying the identity and integrity of the broadcast source is a major challenge for networks, requiring assurance that the received data originates from an authorized source and has not been tampered with during transmission [7]. A single security vulnerability in the network can have serious consequences, necessitating the implementation of stringent security measures, such as encryption and regular security audits, to protect against unauthorized access and data breaches. Source verification is a top priority [8]. A range of specialized security protocols are used to enhance mutual authentication and secure data transmission between vehicles and road infrastructure (RSU) within the network. A common mechanism is the Time-Tolerant Effective Data Authentication Protocol (TESLA), an effective authentication protocol used in resource-limited and time-constrained broadcasts, such as the IoV [9].

While TESLA provides strong source authentication and ensures data integrity in broadcast communications, it does not guarantee data confidentiality, as its core design focuses solely on authentication, not encryption. Messages transmitted over these networks are vulnerable to eavesdropping or data leaks, posing a threat to vehicle systems where personal information is exchanged [10]. However, in addition to a lack of confidentiality, TESLA’s current systems in vehicle IoT environments still suffer from several limitations. These include the delay in authentication caused by the key-scan method, the timing and repeated transmission attack, and the lack of adaptability to highly dynamic vehicle scenarios. Additionally, existing solutions tend to focus on authentication, while overlooking the need for integrated encryption mechanisms that are lightweight and suitable for the low-resource environment of vehicles. Although TESLA 's system has many fixes, there is a need for integrated solutions that provide authentication, confidentiality, and efficiency for vehicle IoT systems. The majority of existing studies focus on individual aspects, leading to partial security solutions not fully tailored to real-time Vehicle-to-Infrastructure (V2I) communications. To overcome these issues, we need an efficient secure broadcast system that provides adequate authentication and light encryption to protect Basic Safety Messages (BSM), while maintaining low computational and communication overhead.

The remainder of the research is divided as follows: Section 2 provides a review of related studies. The methodology is presented in Section 3, the design of the proposed system in Section 4, and the analysis and discussion of the results in Section 5; the conclusion of this research is reached in Section 6.

Ascon entered the CAESAR (competition for authenticated encryption: security, applicability, and robustness) competition and was a finalist in that competition due to high efficiency and security capability. It was later chosen as the winner of the NIST Lightweight Cryptography competition. Ascon is a symmetric-key encryption algorithm that offers encryption and authentication to resist numerous cryptographic attacks.

Ascon refers to an authenticated encryption algorithm that is a stream-based algorithm and is used to combine encryption and authentication. Ascon is divided into three primary variants, Ascon-AEAD128, Ascon-AEAD128a, and Ascon-80pq, that vary in some operational specifics but are similar to each other in their structure. An Ascon type design is constructed on a sponge formation and has a permutation core. The input data (key, plaintext, and associated data (AD)) are absorbed by the sponge construction and squeezed out results (ciphertext and authentication tag). Ascon uses a 128-bit state, divided into two main parts: one for the message and one for the AD. Figure 1 represents the inner stages of the encryption and decryption operations of the cipher [32].

Figure 1. Ascon-AEAD128 encryption stages [31]

The proposed system was evaluated through three important axes: formal analysis using the Scyther formal protocol testing tool, informal analysis, and evaluation of the system's performance in vehicle networks using the NS-3.35 simulator.

5.1 Formal analysis of the proposed protocol security

The proposed MA_ETESLA protocol was formally analyzed using the Scyther verification tool. Two communicating entities were modeled: the vehicle as the sender and the Roadside Unit (RSU) as the receiver. The protocol execution consists of three main steps: transmission of the TESLA commitment value K0, transmission of the encrypted authenticated message, and delayed disclosure of the TESLA key K1.

The verification was conducted under the standard Dolev–Yao attacker model, where the adversary has full control over the public communication channel and may intercept, replay, modify, or inject messages. However, secure cryptographic primitives such as hash functions, MAC generation, and Ascon authenticated encryption are assumed to be computationally secure.

The analysis focused on verifying message confidentiality, agreement between communicating parties, synchronization freshness, and mutual authentication using the claims Secret, Alive, Weakagree, Niagree, and Nisynch. As shown in in Table 1, all specified claims were successfully verified, and no attacks were found within the explored state space.

Table 1. Results of SCYTHER testing for modified TESLA protocol

The results of the verification using Scyther are shown in Table 1. All claims were verified and no attacks were reported, suggesting that no potential vulnerabilities exist in the considered threat model.

The confidentiality claims ensure that secret values, such as the message (M), the commitment value (K0) and the delayed key (K1), are not disclosed to untrusted parties. Moreover, the Nisynch claims confirm synchronization between the vehicle and Roadside Unit (RSU) in the protocol. The Niagree claims also confirm agreement between the parties on the data and the protocol session. From these results, the proposed MA_ETESLA protocol ensures formal confidentiality, authentication, synchronization, and agreement properties, and is shown to be resistant to replay, impersonation and message modification attacks in the threat model.

5.1.1 MA_ETESLA protocol template in Security Protocol Description Language

Scyther uses a dedicated protocol specification language known as the Security Protocol Description Language (SPDL) to model security protocols. SPDL defines protocol roles, parameters, message exchanges, and security claims, enabling formal verification of protocol correctness and security properties. The MA_ETESLA protocol is simulated as a communication process between two entities: the vehicle and the Roadside Unit (RSU). The communication protocol involves exchanging a commit, a secure message, and the subsequent issuance of a TESLA key, as described below.

1 hashfunction H;

2 hashfunction MAC;

3 secretaeadk:Function;

4 inversekeys(aeadk,aeadk);

5 usertypeMessage;

6 protocolTeslaAscon(Sender,Receiver)

7 {

8   role Sender

9   {

10     freshM:Message;

11     freshK1:Nonce;

12     var K0:Nonce;

13     send_1(Sender,Receiver,K0);

14     send_2(Sender,Receiver,{M,           

15 MAC(M,K1)}

16        aeadk(Sender,Receiver));

17     send_3(Sender,Receiver,K1);

18     match(K0, H(K1));

19     claim(Sender,Secret,M);

20     claim(Sender,Nisynch);

21     claim(Sender,Niagree);

22   }

23   Role Receiver

24   {

25     var K0:Nonce;

26     var K1:Nonce;

27     var M:Message;

28     recv_1(Sender, Receiver, K0);

29     recv_2(Sender,Receiver,{M,

30 MAC(M,K1)}

31        aeadk(Sender,Receiver));

32     recv_3(Sender,Receiver,K1);

33     match(K0, H(K1));

34     claim(Receiver,Secret,M);

35     claim(Receiver,Nisynch);

36     claim(Receiver,Niagree);

37   }

38 }

The proposed MA_ETESLA protocol was formally modeled in SPDL and analyzed using the Scyther validator. Lines 1-4 define the main cryptographic primitives, including the hash function H, the MAC function, and the shared AsconAEAD key. Lines 8-22 define the sender role (vehicle). The sender generates a fresh message $m$ and a delayed disclosure key $K_1$, then transmits the commitment value $K_0$, followed by the encrypted authenticated message containing $m$ and $M A c\left(m, K_1\right)$. Finally, the sender reveals $K_1$, enabling delayed authentication. The relationship between the commitment value and the disclosed key is verified through the one-way hash condition $k_0=H\left(K_1\right)$.

The sender specifies security claims related to confidentiality, synchronization, and agreement through the Secret, Nisynch, and Niagree claims. Lines 23-38 define the receiver role (RSU). The receiver first obtains the commitment value K 0 , then receives the encrypted protected message, and finally receives the disclosed key $K_1$. After verifying the condition $K_0=H\left(K_1\right)$. The receiver accepts the message as authentic and validates the same security properties, including confidentiality, synchronization, and agreement.

5.2 Informal security analysis of the MA_ETESLA protocol

This section provides an informal security analysis of the proposed protocol and explains how it meets the key security requirements for V2I communication environments.

(1) Confidentiality

In the proposed protocol, each transmitted security message (M) is encrypted before transmission using the Ascon-AEAD128 algorithm. Therefore, even if an attacker intercepts, the channel, the original text cannot be recovered without the shared secret key between the vehicle and the Roadside Unit (RSU). This overcomes the shortcomings of the traditional TESLA protocol, where messages are typically transmitted as plain text.

(2) Message Integrity

Message integrity is ensured through two layers of protection. First, the Ascon-AEAD algorithm generates an authentication tag for the encrypted payload. Second, the TESLA protocol uses a Message Authentication Token (MAC) generated with a K1 deferred detection key. Any modification to the ciphertext or authentication data results in verification failure and message rejection.

(3) Source Verification

Source verification is performed using a one-way TESLA hash and a delayed key disclosure mechanism. The sender first broadcasts the commit value K0, then later reveals the authentication key K1. The receiver verifies that K0 = H(K1). Since only the legitimate sender knows the correct key at the time of transmission, unauthorized parties cannot generate a valid Message Authentication Token (MAC).

(4) Rebroadcast Resistance

Rebroadcast resistance is achieved by binding each message to a specific time slot in TESLA. Messages received outside of this slot are rejected. Additionally, Ascon uses random values (nonces) and associated data to maintain message freshness. Therefore, packets that have been successfully intercepted cannot be reused.

(5) Protection Against Broker Attacks

Although an attacker can intercept or alter messages on the communication channel, successful forgery remains impossible. Before the key is revealed, the attacker does not know the TESLA authentication key. Furthermore, any alteration invalidates the Ascon authentication token. Therefore, altered messages are detected and discarded.

(6) Key Security

TESLA authentication keys are generated using a one-way hash chain, meaning that previously compromised keys cannot be used to extract subsequent keys. Therefore, compromising an old key does not reveal subsequent keys. Furthermore, the contents of messages remain protected by Ascon encryption.

5.3 Performance evaluation

This section evaluates the efficiency of the proposed (MA_ETESLA) system when applied to BSMs in V2I communication environments using the NS-3.35 network simulator. The main simulation parameters are summarized in Table 2.

Table 2. Simulation parameters

The simulation scenario represents an urban V2I environment. In the baseline setup, 45 vehicles were deployed, while additional scalability experiments increased the number of vehicles up to 80 in order to examine the impact of network density. Vehicle speeds ranged from 50 to 100 km/h under a dynamic mobility pattern.

Each vehicle generated one protected message during every TESLA interval (Tint = 0.2 s), corresponding to 5 messages per second. The TESLA disclosure delay was configured as d = 2. The wireless channel was configured using IEEE 802.11p with a data rate of 6 Mbps, channel bandwidth of 10 MHz, transmission power of 23 dBm, and a range. propagation loss model with an effective communication range of 500 m.

All simulations were executed on a laptop running Ubuntu 22.04 LTS, equipped with a 13th Generation Intel® Core™ i7-13620H processor and 16 GB RAM. For comparative evaluation purposes, the reference protocols were selected from published studies that used identical vehicle scenarios in terms of vehicle speeds, network size, and evaluation criteria. However, some studies used different simulation platforms and varying implementation assumptions, which may lead to slight differences in the reported results. Therefore, the comparisons presented should be interpreted as relative performance indicators under identical conditions.

5.3.1 Communication overhead

Figure 4 illustrates the additional communication overhead for transmitting a single BSM message, measuring the number of extra bytes required to secure the transmitted messages. In a scenario of 45 vehicles traveling at 50 km/h, the MA_ETESLA achieved an additional communication overhead of 99.75 bytes, comprising: the message authentication code/algorithm (HMAC-SHA256) = 32 bytes, a random value (Nonce) = 16 bytes, a TESLA key = 32 bytes, an authentication flag (ASCON) = 16 bytes, and the key index (i) = 4 bytes. Therefore, the additional security cost per message can be expressed as: 32 + 16 + 16 + 32 + 4 = 100 bytes. The average communication cost is calculated as follows: = (Total security bytes) / (Number of messages) = 99.75 bytes, compared to 294 bytes [11], 396 bytes [17], 204 bytes [24], 264 bytes [22], and 172 bytes [23]. The results indicate that the proposed system requires fewer additional bytes than the compared systems. This improvement is primarily attributed to the use of lightweight encryption processes and integrated authentication mechanisms. Reducing the additional communication burden contributes to better bandwidth utilization and less channel congestion.

Figure 4. Communication overhead of Basic Safety Messages (BSM)

5.3.2 Computational cost of signing and verifying basic safety messages

The average time taken to compute MAC signatures and MAC verifications for BSM messages in the systems under consideration, in milliseconds, is shown in Table 3. This is the time required to compute the security measures in each system.

Table 3. Signing and verifying cost of Basic Safety Messages (BSM) in milliseconds

We observe that the time required is dependent on the security method used in different systems. For instance, system [12] takes 0.18128 milliseconds for signature and 0.03691 milliseconds for verification, since it involves several MAC operations. On the other hand, system [11] only requires 0.02 milliseconds for verification due to the use of a single MAC process. In contrast, system [24] has the highest processing cost of 0.365 milliseconds for signing and 0.7106 milliseconds for verification. Among the systems, the proposed MA_ETESLA scheme has a comparatively low processing cost, at 0.017800 milliseconds for signature and 0.017500 milliseconds for verification. This is due to the low-cost MAC.

5.3.3 Performance evaluation under varying vehicle speeds

This section evaluates how well the proposed system performs for different speed ranges (50 km/h to 100 km/h). Tables 4, 5, and 6 provide results for 3 main performance metrics: PDR; Data Transfer Rates; and Transmission Delay, showing each of these metrics for the proposed system against other protocols.

PDR is used to evaluate the reliability of message delivery in a vehicle internet network. This metric represents the percentage of packets successfully received compared to the total number of packets sent during the simulation time.

$(P D R \%)=\frac{g_{-r x}}{g_{-t x}} * 100$           (22)

where, $g_{-r x}=$ Number of packages successfully consumed, $g_{-t x}=$ Total number of packets sent.

Table 4 and Figure 5 illustrate a comparison of PDR values between MA_ETESLA protocol and other systems at various vehicle speeds ranging from 50 to 100 km/h. The results show that the MA_ETESLA protocol achieved high PDR values at low and medium speeds, reaching 99.89% at 50 km/h and 99.31% at 70 km/h. The value gradually decreased with increasing speed, reaching 91.64% at 100 km/h.

Table 4. Analysis of packet delivery ratio (PDR) results for the proposed system with other protocols

Figure 5. Packet delivery ratio (PDR) analysis of proposed system model

Compared to studies [14, 18, 19], the MA_ETESLA protocol demonstrated higher PDR values at most of the tested speeds. At 50 km/h, the MA_ETESLA protocol recorded 99.89%, compared to 97.56% [14], 93.53% [18], and 90.56% [19]. At 70 km/h, the MA_ETESLA protocol achieved 99.31%, compared to 92.26% [14], and 84.84% [18], and 82.08% [19], respectively. At 100 km/h, the MA_ETESLA protocol maintained a relatively high performance of 91.64%, close to 91.20% [14], and higher than 82.93% [18] and 78.69% [19].

These results indicate that the proposed system maintained a relatively high delivery rate across various speeds, with the difference compared to some comparable methods becoming smaller at higher speeds. The gradual decrease in PDR with increasing speed can be explained by the increased topological variations and shorter contact time between vehicles and infrastructure.

Throughput is a metric used to evaluate data transmission efficiency in a vehicle network, representing the amount of data successfully received per unit time. In this work, throughput is expressed in kilobytes per second (KB/s).

Throughput $=\frac{\text { Total Successfully Received Data }(\mathrm{KB})}{\text { Simulation Time }(\mathrm{s})}$              (23)

Total successfully received data (KB) represents the amount of data that was successfully delivered to the recipient. Where the simulation time (s) is the total simulation time.

Table 5 and Figure 6 illustrate the throughput comparison between the proposed system and other systems at various vehicle speeds ranging from 50 to 100 km/h.

Table 5. Analysis of throughput results for the proposed system with other protocols (KB/S)

Figure 6. Throughput analysis of proposed system model

The results showed that the proposed MA_ETESLA system achieved throughput values ranging from (96,040.00 KB/s to 109,800.00 KB/s) across all tested speeds, generally higher than the comparable systems. At 50 km/h, the proposed system recorded 109,800.00 KB/s, compared to 90,956.06 KB/s in [14], 90,563.60 KB/s in [18], and 86,344.75 KB/s in [19]. At 100 km/h, the proposed system maintained a value of 106,800.00 KB/s. While other systems recorded lower values, these results indicate slight fluctuations in data transmission rates across speeds in vehicle communication environments due to variations in link duration, channel conflicts, and packet retransmission behavior. However, the proposed system maintained good data transmission efficiency under different traffic conditions, which is attributed to the low communication load and the use of lightweight security processes that helped reduce packet loss

Table 6 and Figure 7 compare the average transmission delay of the proposed system with other protocols under different vehicle speeds (50 km/h to 100 km/h). The delay metric was calculated as the average time difference between packet transmission and successful reception.

Table 6. Analysis of transmission delay for the proposed system with other protocols

Figure 7. Transmission delay analysis of proposed system model

$D_{\text {avg }}=\frac{\sum_{i=1}^N\left(t r_i-t s_i\right)}{N} * 1000$                   (24)

where, $D_{\text {avg }}=$ average transmission delay, $N=$ number of successfully delivered packets, $t r_i=$ packet reception time after verification, $t s_i=$ packet transmission time.

The results indicate that the proposed MA_ETESLA protocol outperformed the other protocols in terms of delay for all speed ranges. At 50 km/h, the proposed system recorded an average delay of 61.16 ms, compared to 161.38 ms for method [14], 205.80 ms for method [18], and 283.53 ms for method [19]. At 70 km/h, the delay was reduced to 54.15 ms, compared to 216.90 ms, 266.87 ms, and 347.38 ms for the other protocols.

At higher speeds, the proposed method showed a consistent performance, with 53.74 ms delay at 80 km/h, 60.59 ms at 90 km/h and 61.01 ms at 100 km/h. By contrast, the other protocols exhibited much higher delays that increased as the speed increased. These findings suggest that MA_ETESLA enables faster and secure message delivery and lower delay under the dynamic vehicle network environment, and is thus suitable for vehicle safety applications that require low delay.

Figure 8 compares the computational cost of the proposed MA_ETESLA system with several authentication protocols. Computational cost is defined as the total time required to execute the encryption $\left(t_{\text {enc}}\right)$, MAC $\left(t_{\text {mac}}\right)$, decryption $\left(t_{\text {dec}}\right)$, and MAC verification operations ($t_{\text {ver-mac}}$) associated with message protection. This metric reflects the computational load resulting from the implementation of security mechanisms, with lower values indicating faster execution and lower resource consumption. In the proposed system, the computational cost was calculated as the following:

$T_{\text {total}}=t_{\text {enc}}+t_{\text {mac}}+t_{\text {dec}}+t_{\text {ver-mac}}$           (25)

Figure 8. Computation cost analysis of proposed system model

The proposed system has a response time of 0.0426 ms, which is a lower value that suggests fast processing and is suitable for real-time communication and vehicle-based IoT systems. As shown in Figure 9, protocol [15] had the highest response time of 21.436 ms, followed by protocol [23] with 12.59 ms and then protocol [17] with 7.289 ms. Such values can be justified by the use of complex security techniques by these systems, like public-key encryption, digital signature, blockchain, or multiple authentication factors. The response time of protocol [22] was 2.11 ms, which is lower than some of the other systems but still higher than the proposed system. The lowest value of 0.013 ms was recorded for protocol [20], which uses a simple authentication mechanism with only a few encryption processes. Overall, the proposed MA_ETESLA system was able to record one of the lowest computational costs, while offering security and authentication features by combining the Ascon-AEAD algorithm and TESLA mechanism. These findings suggest that the proposed system strikes a good trade-off between security and efficiency, and is therefore a suitable choice for highly dynamic networks.

Figure 9. Impact of vehicles’ speed on average packet loss ratio

Figure 9 compares the average packet loss in the proposed system with that of protocol [12] at different vehicle speeds. The packet loss was calculated from the delivery ratio as follows:

$\mathrm{PLR}=\frac{100-P D R_{ {delivery }}}{100}$          (26)

where, $P D R_{ {delivery}}$ = Number of packages received successfully.

Results from Figure 10 shows that the average packet loss ratio increases progressively with increasing vehicle speed for both the proposed system and the reference system [12] within the speed range of 0 to 25 km/h. This increase is attributed to the fact that higher speeds lead to faster changes in network architecture and reduced communication time between vehicles, which increases the likelihood of link breaks and packet loss during transmission. The results also show that the proposed system achieves similar performance to protocol [12] at low speeds, while a slight difference is observed at high speeds. At 25 km/h, the proposed system recorded a value of approximately 0.13, compared to a value of approximately 0.12 for protocol [12]. These results indicate that the proposed system maintains an acceptable level of reliability with increasing mobility in all cases. Overall, the figure shows that both systems are affected by the increase in speed, and that the packet loss ratio gradually increases as the network dynamics increase.

Figure 10. End-to-end authentication in milliseconds (ms)

5.3.4 End-to-end authentication delay

The total authentication time delay is used to measure the total time required from the moment a message is created by the sender until it is verified and accepted by the receiver. This is measured at varying vehicle densities ranging from 20 to 80 vehicles. Figure 10 compares the overall authentication time of the proposed system with the two reference systems [16, 33]. The results show that authentication time gradually increases with the number of vehicles in all systems due to increased competition for the wireless channel and higher network load. However, the proposed system maintained the lowest authentication time across all tested scenarios.

At a density of 20 vehicles, the proposed system recorded a time of 100.26 ms, compared to 200 ms and 400 ms for systems, respectively. At a density of 80 vehicles, the time was 295.61 ms, compared to 450 ms and 1700 ms for systems, respectively [16, 33].

These results indicate that the proposed system offers better scalability and higher efficiency in dense vehicle environments, thanks to lightweight authentication mechanisms that reduce computational load and response time.