SLEVA-AV: An Edge-Centric IoT Security Architecture Using Multi-Stage Lightweight Encryption for Autonomous Vehicle Applications

Abstract

Autonomous vehicle (AV) networks require secure and efficient data processing under strict latency and resource constraints. This paper proposes a secure, lightweight edge-centric framework, SLEVA-AV, for Internet of Things (IoT)-enabled autonomous vehicle communication. The framework integrates multi-modal sensor data processing, lightweight key management, multi-stage encryption, and integrity verification within a unified pipeline. A key derivation function (KDF) is employed to generate session keys using contextual parameters, enabling efficient re-keying during vehicular mobility without repeated handshake overhead. The encryption process combines PRESENT, SPECK, and lightweight encryption algorithm (LEA) ciphers to enhance cryptographic strength, while SHA-256 ensures data integrity. The proposed system is implemented using a CARLA-based simulation environment and validated through CrypTool 2-based cryptographic analysis. Performance evaluation over 10,000 samples demonstrates low latency (0.039–0.794 s), reduced energy consumption (0.0196–0.0589 J), and negligible key management overhead. Comparative analysis with recent state-of-the-art approaches shows improved scalability and efficiency. Security validation through attack simulations demonstrates resistance against brute-force ($2^{336}$ key space), differential ($2^{-185}$), replay, and tampering attacks, achieving 100% detection accuracy. The results indicate that the proposed framework strikes a balanced trade-off among security strength, computational efficiency, and real-time performance, and it is suitable for deployment in IoT environments with high mobility and dynamic edge connectivity.

1. Introduction and Background Research

AVs are transforming modern transportation by improving road safety, reducing traffic congestion, and enabling efficient mobility services. They support smart cities through intelligent traffic management and reduced human error in driving. AVs are also expected to lower accident rates and improve fuel efficiency, contributing to sustainable transportation systems. However, the deployment of AVs introduces several technical challenges. These include real-time processing of large volumes of multi-modal sensor data, reliable communication in dynamic environments, and strict latency constraints for safety-critical decisions. The integration of IoT and Internet of Vehicles (IoV) technologies further increases system complexity due to heterogeneous devices and distributed architectures [1,2].

Security is a critical requirement in such systems. AVs continuously exchange sensitive data, including location, sensor readings, and control signals. Any compromise can lead to severe consequences, such as incorrect decision-making or system failures. Threats such as data tampering, spoofing, and man-in-the-middle attacks can directly impact vehicle safety and reliability [3]. Therefore, ensuring secure, efficient, and scalable communication is essential for practical deployment [4]. Globally, the adoption of AVs is still in the early stages. It is estimated that fully AVs account for less than 1% of total vehicles worldwide, although advanced driver assistance systems (ADASs) are more widely deployed. This limited adoption is largely due to challenges in safety validation, infrastructure readiness, and secure communication. These factors highlight the need for robust and lightweight security frameworks tailored for real-time AV environments [5].

1.1. Related Work

AVs rely on continuous multi-modal sensor data such as LiDAR, RADAR, GPS, IMU, ultrasonic sensors, and cameras for safe operation in dynamic environments. The integration of the IoT with AV systems enables intelligent transportation services, including cooperative perception, distributed decision-making, and vehicle-to-everything communication [5]. However, this IoT–IoV convergence introduces significant security challenges under strict latency and resource constraints. Edge computing has emerged as a key solution for secure and low-latency vehicular communication. Muthanna et al. [6] proposed a multilevel edge computing architecture for AVs, highlighting improvements in scalability and response time. Similarly, He et al. [5] provided a comprehensive survey of IoV security challenges across multiple layers, while Le et al. [7] introduced a dynamic risk assessment framework for connected vehicles. These studies emphasize the importance of secure communication but focus primarily on system-level analysis rather than lightweight data protection mechanisms.

Lightweight cryptographic techniques are widely used in IoT systems to address resource constraints. Singh et al. [8] analyzed lightweight encryption algorithms and their applicability in IoT environments. Suresh et al. [9] conducted a comparative analysis of encryption approaches, highlighting trade-offs between performance and security. In intelligent transportation systems, Kwon et al. [10] proposed a secure broadcast authentication protocol to improve communication reliability. While these approaches enhance security, they often introduce additional computational or communication overhead. Recent research also focuses on sensing and data-driven applications. D’Alfonso et al. [11] developed cooperative localization techniques for vehicular positioning, while Wang et al. [12] explored LiDAR-based vehicle emission evaluation. Although these works improve sensing accuracy and environmental awareness, they do not address secure data transmission in vehicular networks.

Advanced security mechanisms such as blockchain-based and post-quantum cryptographic frameworks have also been investigated. For example, Lakhan et al. [13] proposed a blockchain-assisted homomorphic encryption scheme, and Rahmati et al. [14] introduced lightweight post-quantum cryptographic methods for edge networks. However, these approaches often incur higher computational costs, limiting their applicability in real-time AV systems. Despite these advances, most existing works focus on isolated aspects such as encryption, authentication, or sensing. However, integrated secure frameworks addressing both efficiency and scalability in IoV environments remain limited.

1.2. Motivation

Vehicular environments are highly dynamic. Vehicles frequently move across edge nodes, leading to short-lived communication sessions and frequent handovers. Traditional cloud-centric security mechanisms introduce high latency and scalability limitations [15,16]. Similarly, conventional public key-based key management schemes incur significant computational overhead, making them unsuitable for real-time applications. Another challenge lies in sensor data [17,18]. Raw multi-modal data are often heterogeneous and redundant. Direct encryption of such data increases computational and communication costs. Although preprocessing improves efficiency, its integration with security mechanisms remains underexplored. Most existing approaches evaluate individual cryptographic algorithms in isolation [19,20]. The combined use of multiple ciphers to enhance security through structural diversity is not sufficiently explored. In addition, scalable key management during vehicular mobility remains a critical challenge. These limitations motivate the development of a unified, efficient, and scalable security framework for IoT-enabled AV systems [21].

1.3. Contribution of This Work

This work proposes SLEVA-AV, a secure and lightweight edge-centric framework for autonomous vehicle networks. The main contributions are as follows:

• Edge-Centric Secure Framework: A unified architecture for secure acquisition, preprocessing, and transmission of multi-modal sensor data in IoT–IoV environments.
• Lightweight Multi-Stage Encryption: A cascaded PRESENT–SPECK–LEA scheme that improves diffusion and enhances resistance to cryptanalytic attacks.
• Scalable Key Management: A KDF-based session key mechanism enabling efficient re-keying during vehicular mobility with minimal overhead.
• Comprehensive Evaluation: Validation using CARLA and CrypTool 2, including comparative analysis and attack simulations under realistic conditions.

The remainder of this paper is organized as follows. Section 2 presents the system architecture and encryption model. Section 3 explains the implementation details. Section 4 discusses the experimental results and performance evaluation. Finally, Section 5 concludes the paper and outlines future work.

2. Architecture of the Secure Data Processing and Transmission Framework for Avs

The proposed SLEVA-AV framework follows an edge-centric IoT architecture. In this model, the AV acts as a secure computational edge node. The vehicle performs real-time sensing, preprocessing, encryption, and integrity verification locally. The architecture is designed to meet the strict latency, energy, and security requirements of safety-critical vehicular environments (Figure 1). A heterogeneous perception stack is used in the vehicle. It includes LiDAR, RGB cameras, RADAR, GPS, IMU, and ultrasonic sensors [22,23,24]. These sensors continuously generate multi-modal data streams. Such data must be protected before storage or transmission [25]. The aggregated raw sensory data can be expressed as $D_{raw}={\left\{d_i\right\}}_{i=1}^N=\left\{d_{LIDAR},d_{RADAR},d_{GPS},d_{IMU},d_{Cam}\right\}.$ Here, N represents the number of sensing modalities. Raw vehicular data usually contains noise and sampling inconsistencies. Heterogeneous sensor sampling also causes temporal skew. Therefore, an edge preprocessing operator $\wp \left(·\right)$ is applied first. This produces the normalized dataset $D_{pre}=\wp \left(D_{raw}\right)$. Here, $\wp \left(·\right)$ performs Kalman filtering, normalization, and timestamp alignment [15]. This improves statistical consistency. It also prepares the data for lightweight cryptographic processing (Algorithm 1).

The proposed framework uses an edge-assisted Hash-based Message Authentication Code (HMAC)-based KDF (HKDF) to generate secure session keys, as shown in Figure 2. A master key $K_M$ is stored in the vehicle. Context parameters include nonce N, timestamp t, and edge node identity $I{D}_{edge}$. These ensure dynamic and context-aware key generation [26]. In the extract phase, a pseudo-random key is computed as $PRK=HMA{C}_s\left(K_M\right)$. In the expand phase, the session key is derived iteratively as T(0) = ∅ and $T\left(i\right)=HMA{C}_{PRK}.$ The final key is $K_{session}=T\left(1\right) \parallel T\left(2\right) \parallel \cdots T\left(i\right) .$ This key is split into $K_s, and K_i$ for PRESENT, SPECK, and LEA. The total key length is 336 bits. HMAC is defined as $HMA{C}_k\left(M\right)=H\left(\left(K\oplus \mathrm{opad}\right) \parallel H\right)$. The scheme produces context-bound and non-reusable keys. It has low computational overhead [27].

Algorithm 1: Secure lightweight encryption and verification algorithm for autonomous vehicles (SLEVA-AV)—encryption and verification.

Input:   Sensor data streams:     D_raw = {LIDAR, RADAR, GPS, IMU, Camera, Ultrasonic}   Master Key: K_M   Edge Node ID: ID_edge   Nonce: N   Timestamp: t Output:   Encrypted data: D_final   Integrity hash: H Begin 1.   // Sensor Data Acquisition: D_raw ← {d_i}, for i = 1 to N 2.   // Data Size Estimation: For each sensor i:        S_i ← N_i × P_i      End For      S_total ← Σ S_i 3.   // Preprocessing (Filtering, Normalization, and Synchronization): D_pre ← P(D_raw)        // Compression: S_LIDAR ← 0.5 × S_LIDAR; S_Camera ← 0.7 × S_Camera 4.   // Session Key Generation (Scalable)           K_session ← KDF(K_M || N || t || ID_edge) 5.   // Multi-Stage Encryption              // Stage 1: PRESENT:       D1 ← PRESENT_Encrypt(D_pre, K_p);              // Stage 2: SPECK:         D2 ← SPECK_Encrypt(D1, K_s);              // Stage 3: LEA:           D_final ← LEA_Encrypt(D2, K_l); 6.   // Integrity Verification:          H ← SHA256(D_final); 7.   // Transmission: Send (D_final, H); 8.   // Receiver-Side Verification      H_star ← SHA256(D_final);      If H_star == H then        Accept data      Else        Reject data (Tampering detected)      End If 9.   // Performance Evaluation: Throughput ← S_total / T_enc; Latency ← T_enc; Energy ← Power × T_enc; Key_Overhead ← T_KDF / T_total; Hash_Overhead ← (32 / S_total) × 100 End

The selected configurations are lightweight and practical. PRESENT uses a 64-bit block size and an 80-bit key. SPECK uses a 128-bit block size with a 128-bit key (Speck128). LEA uses a 128-bit block size and a 128-bit key. SHA-256 produces a 256-bit hash output. These parameters provide a balance between security and efficiency. To ensure confidentiality under resource constraints, a cascaded lightweight encryption scheme is used. The first security layer applies the PRESENT block cipher. The encrypted output is given by $D_p=E_{PRESENT }\left(D_{pre},K_p\right)$, where $K_p$ represents the secret encryption key. PRESENT provides efficient substitution–permutation diffusion. It is suitable for embedded vehicular electronic control units (ECUs). However, stronger adversarial resistance is required. Therefore, a hybrid second encryption stage is introduced. The PRESENT output is processed in parallel by SPECK and LEA ciphers. This produces $D_s=E_{SPECK }\left(D_p,K_s\right)$ and $D_L=E_{LEA }\left(D_p,K_L\right)$, where $K_s$ and $K_L$ represent independent session keys.

SPECK provides fast Addition–Rotation–XOR (ARX)-based diffusion with very low latency. LEA provides strong word-oriented confusion. It is efficient for software implementations [17]. The final ciphertext is obtained through secure concatenation, $D_{Final}=D_s\parallel D_L$. This hybrid construction enhances structural diversity and resistance to cryptanalysis. To guarantee data integrity and authenticity, the SHA-256 hash function is applied. The integrity tag is generated as $HA-256 \left(D_{Final}\right)$. During verification, the receiver recomputes the hash value. The condition $H^{*}\doteq H$ is checked. If a mismatch occurs, tampering or transmission corruption is detected. It also benefits from an expanded effective key space. The composite key space is expressed as ℚfinal = $2^{\left|K_p\right|+\left|K_s\right|+\left|K_L\right|}$. Under typical lightweight configurations, this exceeds $2^{336}$. This significantly increases resistance to brute-force attacks.

The diffusion strength of the cascaded design can be measured using the avalanche effect: $AE={\displaystyle \frac{1}{n}}.$ This value approaches the ideal value of 0.5 due to combined Substitution-Permutation Network (SPN)–ARX transformations. The overall differential probability can be approximated as $P_{diff}^{total}\approx P_{diff}^{PRESENT},P_{diff}^{SPECK},P_{diff}^{LEA}$. This indicates multiplicative suppression of exploitable cryptographic characteristics. SHA-256 ensures data integrity and tamper detection. It provides collision resistance of approximately $2^{-128}$ and second-preimage resistance of approximately $2^{-256}$. Therefore, the probability of undetected data manipulation in vehicular IoT channels becomes extremely small [18].

This mechanism also provisions fast re-keying during edge handovers, avoiding costly key renegotiation. The re-keying overhead $T_{key}$ is maintained significantly lower than encryption latency, i.e., $T_{key}\ll T_{enc}$. The system scalability under vehicular mobility can be expressed as $T_{total}=T_{enc}+ f_h+ T_{key},$ where $f_h={\displaystyle \frac{v}{R}}$. Here, $v$ represents vehicle speed and $R$ denotes edge coverage radius, indicating that the overall overhead remains bounded in practical deployments. From a system security perspective, the framework mitigates several vehicular threats. Hash verification detects man-in-the-middle attacks. Timestamp-based preprocessing reduces replay attacks. The overall computational complexity of the encryption pipeline remains linear: ${\mathcal{O}}_{enc}=\mathcal{O}\left(n\right)$. This ensures real-time feasibility for embedded edge platforms. The complete processing pipeline can be expressed as $D_{raw}\to D_P\to \left(D_s,D_L\right)\to D_{Final}\to \left(D_{Final},H\right)$. This pipeline integrates sensing, preprocessing, encryption, and integrity verification within the vehicular edge node [28].

The scalability of the system can be quantified in terms of the maximum number of vehicles supported within an edge coverage region. Let $C_e$ denote the processing capacity of an edge node (in operations per second) and $C_v$ denote the average computational requirement per vehicle. The maximum number of vehicles supported is given by $N_{max}={\displaystyle \frac{C_e}{C_v}}$. Under high traffic conditions, the system load can be expressed as $L={\displaystyle \frac{N_v}{N_{max}}},$ where $N_v$ is the number of active vehicles. When $L$ → 1, the system approaches saturation, and latency increases. However, due to lightweight encryption and KDF-based re-keying, the computational complexity remains linear O(n), ensuring graceful degradation rather than abrupt performance loss. This makes the proposed framework scalable under dense vehicular scenarios. From a practical deployment perspective, the master key $K_M$ is provisioned during the vehicle registration phase through a trusted authority (TA), such as a vehicle manufacturer or certified infrastructure provider. This provisioning can be securely implemented using hardware security modules (HSMs) or trusted platform modules (TPMs) embedded within the vehicle. During operation, edge nodes are authenticated through a trust hierarchy managed by the TA. The dissemination of keys does not require continuous transmission of $K_M$; instead, only lightweight parameters such as nonce, timestamp, and edge identity are exchanged. This reduces communication overhead and prevents key exposure. The trust assumption in this model relies on secure initialization and tamper-resistant storage within the vehicle, while edge nodes are assumed to be semi-trusted and authenticated entities.

3. Integrated Simulation and Security Algorithm Implementation

The implementation is executed on an Intel i5 system with 816 GB RAM running the Ubuntu Operating System (OS). Python 3.13 is used for orchestration and analysis. Vehicular data streams are generated using the CARLA Simulator. The simulation time step is fixed at Δt = 0.1 s. Sensor sampling rates are maintained in the range $f_s=10-20$. Input data sizes are varied as n ∈ [64,100] kB to evaluate scalability.

As shown in Figure 3, the simulation environment provides multi-modal data, including vehicle telemetry, spatial mapping, and sensor fusion outputs. This ensures realistic and heterogeneous input conditions. The diversity of sensor modalities improves the robustness of preprocessing and directly impacts the encryption workload. High-density, mixed-traffic scenarios resembling Chennai conditions are considered, as illustrated in Figure 3. The road network is generated from OpenStreetMap data and converted into OpenDRIVE format for CARLA integration. Each vehicle is equipped with LiDAR, RGB cameras, RADAR, GPS, IMU, and ultrasonic sensors, enabling heterogeneous multi-modal data generationRaw sensor outputs are treated as vehicular IoT data and processed at the vehicle edge using Python scripts. Data preprocessing is carried out using NumPy, Pandas, and SciPy libraries, including noise filtering, normalization, and timestamp synchronization to ensure consistency across sensor modalities. The security pipeline is implemented using the CrypTool cryptographic platform [29]. PRESENT operates with $b_1=64 bits$ and $K_1=80 bits$. SPECK and LEA operate with $b_2=b_3=128 bits$ and $k_2=k_3=128 bits$. SHA-256 produces a 256-bit output. Session keys are derived using contextual inputs $\left(N,t,I{D}_{edge},i\right)$. The derived key length is L = 336 bits. It is partitioned into $K_p, K_{s,}$ and $K_L$. As illustrated in Figure 4, the multi-stage encryption pipeline transforms $D_{pre}\to D_p\to \left(D_s,D_l\right)\to D_{final}$. Intermediate outputs are explicitly observed, confirming the correctness of each stage. The parallel execution of SPECK and LEA reduces processing delay and enhances diffusion.

Execution time is measured using time.perf_counter(). The encryption latency is defined as $T_{enc}$. The observed range is $T_{enc}$ ∈ [0.29,0.79] s. Throughput is computed as ${\displaystyle \frac{n}{T_{enc}}}$, with an average of ≈100 MB/s. The results show near-linear scaling with respect to n. Figure 3 contributes to validating realistic data generation, while Figure 4 demonstrates the correctness and efficiency of the encryption pipeline. The combined impact confirms that both data diversity and pipeline structure influence performance. The implementation shows stable execution, low latency, and consistent throughput.

4. Results and Discussion

This section presents the experimental validation of the proposed SLEVA-AV framework using a CARLA-based autonomous vehicle simulation integrated with CrypTool 2 for cryptographic analysis. The evaluation focuses on both performance efficiency and security robustness under realistic vehicular IoT conditions. Multi-modal sensor data generated from the simulation are processed at the edge using the proposed pipeline, and results are obtained over large-scale samples to ensure statistical reliability.

4.1. Data Reduction and Encryption Efficiency from Preprocessing to Integrity Assurance

The dataset evaluates the effect of preprocessing and encryption on data size across 20 test cases. The analysis focuses on reducing data size while maintaining security. Four parameters are considered in the evaluation. The first parameter is the total original data, which represents the raw sensor data before any processing. The second parameter is preprocessed data, which indicates the data size after structural refinement and removal of redundant information. The third parameter is the initial encrypted data, which represents the data size after the first encryption stage. The fourth parameter is the final encrypted data, which shows the data size after applying the complete encryption pipeline. As illustrated in Figure 5, preprocessing consistently reduces data size across all test cases. The reduction is more noticeable in cases with larger datasets. For example, in Test Case 722, the original data size is 117.84 kB. After preprocessing, it decreases to 99.31 kB. This corresponds to a reduction of approximately 15.7%.

The encryption process introduces only a very small overhead. This can be observed when comparing the preprocessed data size with the encrypted data size. For instance, in Test Case 509, the preprocessed data size is 99.37 kB. After encryption, the size increases slightly to 99.40 kB. This shows that the encryption algorithm is computationally efficient and introduces negligible data expansion. Across all test cases, the difference between the initial encrypted data and the final encrypted data remains very small. This indicates stable and predictable encryption behavior. Test cases with larger original datasets, such as Test Case 134 (96.41 kB) and Test Case 698 (114.48 kB), show noticeable reductions during preprocessing. At the same time, the encryption overhead remains minimal.

Similarly, test cases with smaller datasets behave differently. Examples include Test Case 21 (39.16 kB) and Test Case 1000 (62.37 kB). In these cases, preprocessing results in smaller reductions. This is expected because smaller datasets generally contain less redundant information. Data compression reduces storage requirements and transmission delays. This is particularly important for secure communication systems. The encryption process provides strong security while maintaining minimal data size inflation. Therefore, system performance is not affected.

4.2. Evaluation of the Key Management Scheme

The evaluation is conducted using 10,000 simulated vehicular communication instances generated within CARLA under varying mobility conditions. The performance is analyzed using latency, computational cost, communication overhead, and storage overhead (

Table 1. Comparative analysis of key management performance.

Metric	Proposed System	[5]
Key Establishment Latency	0.10–0.50 ms	99–169 s
Key Retrieval Time	~Instant	10–20 s
Key Return Time	Not required (automatic)	2.35–4.14 min
Total Latency	0.039–0.794 s	Very high (seconds to minutes)
Communication Overhead	48–80 bytes	High
Storage Overhead	~42 bytes	High
Re-keying Method	KDF-based (lightweight)	Manual/handshake-based
Scalability	High	Limited

). The results show that the key generation latency lies in the range of 0.10–0.50 ms, which is negligible compared to the overall system latency of 0.039–0.794 s. This confirms that $T_{key}\ll T_{enc}$, and the overhead introduced by re-keying remains minimal, even under frequent vehicular handovers.

To validate the effectiveness of the proposed approach, a comparison is performed with real-world operational data from conventional key management systems. The observed verification time ranges from 99 s to 169 s, while key retrieval and return times range from 10–20 s and 2.35–4.14 min, respectively. These delays arise due to manual handling, repeated authentication, and communication overhead in traditional systems. In contrast, the proposed CARLA-based implementation eliminates manual key handling and replaces it with automated KDF-based re-keying. The computational cost is significantly reduced due to lightweight operations. The energy consumption is observed in the range of 0.0196–0.0589 J, which is lower than conventional approaches. The communication overhead is minimal, as only nonce, timestamp, and edge identity are transmitted, resulting in an overhead of 48–80 bytes. The storage overhead is approximately 42 bytes, as only session keys and minimal metadata are maintained. The results demonstrate that the proposed key management scheme achieves substantial improvement in efficiency and scalability. While conventional systems exhibit delays in seconds and minutes, the proposed approach achieves key generation in milliseconds. This represents a significant reduction in overhead. The scalability analysis confirms that the re-keying cost remains negligible under high mobility conditions.

4.3. Data Integrity Using 256-Bit Cryptographic Hashes

Table 2. Integrity verification performance over 10,000 samples.

Metric	Value
Number of Samples	10,000
Hash Size	256 bits (32 bytes)
Avg Hash Time	0.89 ms
Min Hash Time	0.72 ms
Max Hash Time	1.05 ms
Detection Accuracy	100%
Tampered Samples Tested	10,000
Overhead	0.125% (avg)
Min Overhead	0.016%
Max Overhead	0.32%
Throughput Impact	<1% reduction

summarizes the performance of the SHA-256-based integrity verification mechanism evaluated over 10,000 simulated vehicular data samples. The hash size remains fixed at 256 bits (32 bytes), independent of input size, ensuring predictable overhead. For each encrypted data block $D_{final}$, the integrity hash is computed as $H=SHA-256 \left(D_{final}\right)$. The average hash computation time is calculated as $T_{avg}= {\displaystyle \frac{1}{n}} \sum _{i=1}^n{T}_{hash}^i$, where n = 10,000. The observed value is 0.89 ms, with a minimum of 0.72 ms and a maximum of 1.05 ms, indicating stable execution. Detection accuracy is evaluated as $Accuracy= {\displaystyle \frac{N_{detected}}{N_{tampered}}}\times 100\%$. In this study, $N_{detected}$ = $N_{tampered}$, resulting in 100% accuracy, confirming reliable tamper detection.

The communication overhead introduced by hashing is computed as $Overhead= {\displaystyle \frac{Hash Size}{Data Size}}\times 100\%$. For example, for a 25 KB data block, $Overhead= {\displaystyle \frac{Hash Size}{Data Size}}\times 100\%$ ≈ 0.125%, which matches the observed average of 0.125%, with a range of 0.016% to 0.32%. The impact on throughput is evaluated by comparing system performance with and without hashing, expressed as ΔT = ${\displaystyle \frac{T_{with}- T_{without}}{T_{without}}}$ × 100%, which remains below 1%, indicating negligible degradation. Overall, the results confirm that SHA-256 provides robust integrity verification with minimal computational and communication overhead, making it suitable for real-time AV systems.

4.4. Performance Analysis of Data Encryption Schemes

The performance of the encryption system was analyzed using 10 randomly selected test cases from a dataset of 10,000 samples. The results are presented in

Table 3. Data encryption performance metrics for randomly selected test cases.

Test Case No.	Total Original Data (in kB)	Final Encrypted Data (in kB)	Throughput (KB/s)	Latency (ms)	Energy Consumption (J)	Encryption Speed (KB/s)	Encryption Time (s)
21	39.16481	36.35829	100	0.039165	0.019582	125	0.29061
123	60.96545	47.42759	100	0.060965	0.030483	125	0.379165
134	47.0318	41.04802	100	0.047032	0.023516	125	0.328128
269	96.41094	77.556	100	0.096411	0.048205	125	0.620192
377	61.22522	57.80328	100	0.061225	0.030613	125	0.46217
398	92.04861	81.1182	100	0.092049	0.046024	125	0.64869
637	92.53704	85.971	100	0.092537	0.046269	125	0.687512
722	96.34688	86.05127	100	0.096347	0.048173	125	0.688154
817	84.42015	75.71979	100	0.08442	0.04221	125	0.605502
913	85.47154	70.87936	100	0.085472	0.042736	125	0.566779

. Several performance metrics were evaluated. These include total original data size, final encrypted data size, throughput, latency, energy consumption, encryption speed, and encryption time. The total original data size varies between 39.1648 kB (Test Case 21) and 117.8369 kB (Test Case 722). The corresponding preprocessed data sizes are slightly smaller, as they remove redundant information and perform normalization. The initial encrypted data size remains almost equal to the preprocessed data size. This shows that the encryption algorithm introduces minimal overhead at this stage. The final encrypted data size shows a small increase. This increase is usually limited to a few kilobytes. It mainly results from encryption metadata and padding operations. Across all 20 test cases, the system maintains a consistent throughput of 100 KB/s. This indicates that the system can process the entire dataset efficiently within the specified time. The consistent throughput also demonstrates good scalability. The encryption framework can, therefore, handle datasets of different sizes without performance degradation. This characteristic is important for applications such as IoT systems and real-time secure communication platforms. Latency represents the time delay between the start and completion of the encryption process. The results show that latency increases with data size. For smaller datasets, such as Test Case 21 (39.1648 kB), the latency is approximately 0.039 s. Larger datasets require slightly more processing time. However, the observed latency values remain within acceptable limits for real-time systems.

The energy consumption of the encryption process was also analyzed. Energy values range between 0.0196 J for smaller datasets and 0.0589 J for larger datasets. This increase is expected because larger datasets require more computational operations. Despite this increase, the overall energy consumption remains low. This indicates that the system is optimized for energy-efficient operation, which is important for battery-powered IoT devices. The encryption speed remains constant across all test cases. The measured value is 125 KB/s. This consistency demonstrates the ability of the system to process data efficiently regardless of dataset size. High encryption speed is particularly important for real-time encryption applications, where large volumes of data must be secured quickly. The encryption time represents the total time required to encrypt the dataset. The measured values range between 0.2906 s and 0.7945 s. Encryption time increases linearly with data size. This behavior confirms that the system scales efficiently for larger datasets. Even for the largest dataset, the encryption time remains suitable for real-time applications.

The radar (spider) chart illustrates the normalized performance characteristics of the proposed SLEVA-AV edge-centric lightweight encryption framework. The chart includes key operational metrics such as throughput, latency, energy consumption, encryption speed, and encryption time (Figure 6). Each axis represents a specific performance indicator. The values are averaged across multiple test cases and normalized for visual comparison. The chart shows that the framework maintains high throughput and high encryption speed. At the same time, latency and energy consumption remain low. The balanced shape of the radar chart indicates that the system achieves a good trade-off between computational efficiency and security overhead. This confirms that the proposed multi-stage lightweight encryption design is suitable for real-time IoT-enabled AV environments.

4.5. Security Evaluation Under Multiple Attack Scenarios

The security of the framework is evaluated against multiple attack scenarios, including brute-force, differential, known-plaintext, replay, man-in-the-middle (MITM), and data tampering attacks, as shown in Figure 7. The brute-force resistance is derived from the combined key space, $\left|K_{total}\right|= 2^{80+128+128}= 2^{336}.$ Assuming an attacker’s capability of ${10}^{12}$ key trials per second, the expected time to exhaustively search the key space is $T_{bf}= {\displaystyle \frac{2^{336}}{{10}^{12}}}$ ≈ 4.1 $\times {10}^{81} years,$ which confirms practical infeasibility. Differential cryptanalysis is mitigated through cascading of SPN and ARX structures. The overall differential probability is approximated as $P_{diff}^{total}= P_{diff}^{PRESENT}·P_{diff}^{SPECK}·P_{diff}^{LEA}\approx 2^{-185}$. The experimental results show an avalanche effect of approximately 49.6–50.3%, indicating near-ideal diffusion. Replay attacks are prevented using a context-aware key derivation mechanism, $K_{session}=KDF \left(K_M\parallel \mathrm{N} \parallel \mathrm{t} \parallel \mathrm{I}\right).$ Any reuse of old parameters results in a key mismatch and rejection.

Similarly, MITM and tampering attacks are detected through hash verification. The probability of undetected tampering is bounded by the collision resistance of SHA-256, $P_{collision}\approx 2^{-128}$. The experimental results obtained from CrypTool 2 simulations confirm that all attack attempts fail, and they are tabulated in

Table 4. Security evaluation results.

Metric	Value	Interpretation
Key Space	$2^{336}$	Extremely large, brute-force infeasible
Brute-force Time	$4.1\times {10}^{81}$ years	Not practically breakable
Differential Probability	$2^{-185}$	Strong resistance to differential attacks
Avalanche Effect	49.6–50.3%	Near-ideal diffusion
Known-Plaintext Success	0/10,000	No key recovery
Replay Detection	100%	All attempts rejected
MITM Detection	100%	All modifications detected
Tampering Detection	100%	Hash mismatch always detected
Collision Probability	$2^{-128}$	Negligible
Avg Hash Time	0.89 ms	Low computational cost
Overhead	0.125%	Minimal communication cost

. The system achieves 100% detection accuracy for replay, MITM, and tampering attacks.

The average hash computation time is 0.89 ms, and the communication overhead is limited to 0.125%, indicating minimal impact on performance. Multi-stage encryption significantly increases cryptographic complexity, while KDF-based key management ensures scalability in dynamic vehicular environments. The SHA-256 integrity mechanism guarantees reliable tamper detection with negligible overhead. Therefore, the system is robust against practical attack scenarios and suitable for real-time IoT-enabled AV applications.

4.6. Comparative Analysis with Recent State-of-the-Art Methods

The proposed SLEVA-AV framework is compared with recent state-of-the-art studies, namely, He et al. (IoV security architecture) [15], Boubaker et al. (lightweight cryptographic performance) [5], and Rahmati et al. (energy-aware cryptographic frameworks) [27] (

Table 5. Comparative analysis with limitations.

Aspect	[5]	[16]	[14]	Proposed SLEVA-AV
Focus	IoV security layers	Lightweight cipher speed	Energy-efficient cryptography	Integrated edge security
Security Approach	Detection and mitigation	Single cipher	Key exchange optimization	Multi-stage encryption + hash
Key Management	Not detailed	Not emphasized	Public key (high cost)	KDF-based (lightweight)
Encryption Time	Not specified	~ns (hardware)	Moderate	0.29–0.79 s
Energy Efficiency	Moderate	Very high	Key exchange heavy	Low (0.0196–0.0589 J)
Scalability	High (system-level)	Limited	Moderate	High
Integrity Verification	Partial	Not included	Limited	SHA-256 (100%)
Limitations	No lightweight encryption	Hardware-dependent	High key overhead	Limited system-level defense, no post-quantum cryptographic (PQC), needs hardware optimization

). The comparison considers key aspects such as security coverage, computational efficiency, energy consumption, key management overhead, scalability, and practical deployment constraints. To ensure a fair comparison, all performance metrics are evaluated under comparable conditions. The results for the proposed system are obtained through CARLA-based simulation and CrypTool implementation. The results for He et al., Boubaker et al., and Rahmati et al. are reported based on their published literature. It should be noted that some results, particularly for Boubaker et al., are obtained using hardware-optimized implementations, which may achieve significantly lower latency compared to software-based evaluation. Therefore, differences in experimental settings, including hardware platforms and dataset configurations, are explicitly acknowledged when interpreting the results.

From a security architecture perspective, He et al. provide a comprehensive multi-layer analysis of IoV threats across physical, network, application, and system layers. Their work highlights critical vulnerabilities, such as V2X interruption (>200 ms), false message injection, and data tampering, with mitigation strategies including blockchain authentication and reinforcement learning-based detection. However, their approach is primarily defensive and detection-oriented, focusing on system-level protection rather than lightweight real-time encryption. In contrast, the proposed SLEVA-AV framework introduces proactive data-level security using a multi-stage encryption pipeline combined with integrity verification. The overall security strength ensures strong resistance against brute-force attacks. The SHA-256 mechanism provides 100% tamper detection accuracy. Despite these advantages, the proposed framework does not explicitly incorporate cross-layer defense mechanisms, such as intrusion detection systems, blockchain-based authentication, or reinforcement learning-based anomaly detection, which are addressed in He et al. Therefore, while the proposed work strengthens data confidentiality and integrity, it offers limited coverage at the broader system-level.

From a computational performance perspective, Boubaker et al. report extremely low execution times in the nanosecond range (e.g., encryption ≈ 8.728 ns) using optimized hardware implementations of lightweight ciphers. These results demonstrate exceptional efficiency but are achieved under specialized hardware conditions and typically involve single-algorithm encryption. In contrast, the proposed framework employs a multi-stage encryption design (PRESENT → SPECK → LEA) to enhance cryptographic strength. This introduces additional computational overhead, with encryption time ranging from 0.2906 s to 0.7945 s. Although this is higher than hardware-optimized implementations, it remains acceptable for real-time vehicular applications. A limitation of the proposed approach is that it has not yet been fully optimized for dedicated hardware acceleration (e.g., Field-Programmable Gate Array (FPGA) or Application-Specific IC (ASIC)), which could further reduce latency and improve throughput.

From an energy and key management perspective, Rahmati et al. show that key exchange operations consume the highest energy (~0.82 mJ), followed by key generation (~0.45 mJ), due to computationally intensive public key mechanisms, such as Diffie–Hellman. In contrast, the proposed framework adopts a lightweight KDF-based key management scheme that eliminates the need for expensive key exchange procedures. The total energy consumption of the proposed system ranges from 0.0196 J to 0.0589 J, and the key generation overhead is negligible compared to encryption time. This supports real-time deployment in edge environments. However, a limitation is that the proposed scheme relies on pre-shared master keys and synchronized parameters, which may introduce challenges in large-scale heterogeneous deployments. Additionally, the framework does not yet consider PQC mechanisms, which are explored in Rahmati et al.

Overall, the comparative analysis shows that existing works focus on isolated aspects, such as system-level threat modeling [5], ultra-fast hardware encryption [16], or energy-aware cryptographic design [14]. In contrast, the proposed SLEVA-AV framework provides a holistic and integrated solution, combining lightweight multi-stage encryption, efficient key management, and integrity verification within an edge-centric architecture. The framework achieves a balance between security, latency, and energy efficiency. However, limitations remain in terms of system-level defense integration, hardware acceleration, large-scale key distribution, and future-proof cryptographic resilience. These limitations provide directions for future work, including integration with intrusion detection systems, FPGA-based optimization, and adoption of post-quantum security mechanisms.

5. Conclusions

This paper presents SLEVA-AV, a secure and lightweight edge-centric framework for autonomous vehicle communication in IoT-enabled environments. The framework integrates preprocessing, multi-stage encryption, efficient key management, and integrity verification into a unified architecture. The use of KDF-based session key generation eliminates repeated handshake overhead and enables scalable operation under frequent vehicular handovers. The proposed encryption design enhances cryptographic strength. The proposed system is implemented using CARLA-based simulation and CrypTool 2-based validation. The experimental results demonstrate low latency, reduced energy consumption, and minimal communication overhead. Despite these advantages, certain limitations remain. The framework focuses primarily on data-level security and does not fully integrate system-level defense mechanisms, such as intrusion detection or blockchain-based authentication. The current implementation is software-oriented and requires further optimization for hardware platforms, such as an FPGA. In addition, large-scale deployment may require advanced key distribution strategies and synchronization mechanisms. The framework also does not address PQC threats, which are increasingly relevant for future secure communication systems.

Future work will focus on hardware-oriented optimization of the proposed framework. The multi-stage encryption pipeline will be mapped to FPGA and ASIC platforms to reduce latency and improve throughput. Pipeline parallelism and hardware-level optimization of PRESENT, SPECK, and LEA will be explored to achieve real-time performance under high vehicular loads. In addition, the integration of PQC primitives is planned to ensure long-term security against quantum adversaries. Lightweight lattice-based key exchange mechanisms, such as Kyber, can replace or complement the current KDF-based scheme. This will enhance resilience while maintaining computational efficiency in edge-constrained environments.