Skip to main content
Scientific Reports logoLink to Scientific Reports
. 2026 Jan 16;16:2212. doi: 10.1038/s41598-025-31123-w

A secure group-based authentication protocol for IoVT in 5G-enabled smart transportation and road safety systems

Garima Singh 1, Shivani Sharma 1, Abdul Khader Jilani Saudagar 2,, Sachin Kumar 3
PMCID: PMC12816698  PMID: 41540082

Abstract

The Internet of Vehicular Things (IoVT) is evolving rapidly, connecting vehicles, infrastructure, and other smart systems via the Internet. This connectivity enhances safety, efficiency, and data-driven services but also introduces significant security and privacy risks. To tackle these challenges, this paper proposes a lightweight, group-based authentication and key agreement (AKA) protocol tailored for 5G-enabled IoVT networks. The protocol achieves essential security goals, including mutual authentication, key confirmation, forward and backward secrecy, subscriber privacy, and session unlinkability. Its security has been formally validated using the AVISPA tool and BAN logic, showing strong resistance against common cryptographic attacks. Performance evaluations indicate that the proposed protocol can reduce signaling overhead by up to 47.3%, lower bandwidth consumption by up to 32.3%, and significantly decrease computational costs compared to the standard EPS-AKA protocol. Overall, these results highlight a secure, efficient, and scalable solution suitable for next-generation 5G-based IoVT systems.

Keywords: Authentication, Key agreement, Security & privacy, 5G and IoVT

Subject terms: Engineering, Mathematics and computing

Introduction

The Internet of Vehicular Things (IoVT) takes the concept of the Internet of Things (IoT) further by highlighting the interconnectedness and communication of vehicles and their associated systems. Integrating sensors, actuators, and intelligent devices within vehicles enables IoVT to exchange data, enables vehicle-to-vehicle communication, and allows for interaction with infrastructure. Its objectives encompass enhancing transportation systems, improving road safety, optimizing traffic flow, facilitating intelligent and autonomous vehicle operations, and providing various services to the drivers and passengers. The advantages of IoVT span multiple aspects of transportation and vehicular systems, including enhanced road safety, efficient traffic management, improved driver experiences, vehicle diagnostics and maintenance, environmental benefits, autonomous and connected vehicle capabilities, and data-driven insights for decision-making. IoVT has the potential to revolutionize transportation systems and deliver a more streamlined and convenient driving experience. IoVT creates a connected and intelligent transportation ecosystem by integrating vehicles, infrastructure, and technology. With the continuous advancement of IoVT technology, its impact on transportation systems and the movement of people and goods is anticipated to experience significant growth. The ongoing evolution of IoVT is poised to introduce transformative changes in how we navigate transportation and utilize vehicles.

Although IoVT systems provide many benefits, they are not immune to security risks13. Like any connected network, IoVT is exposed to threats such as unauthorized access, data breaches, malicious attacks, and tampering. To protect the confidentiality, integrity, and availability of data exchanged between vehicles, strong security measures—particularly authentication and key agreement protocols—are essential. These mechanisms are crucial for verifying identities, establishing secure communication channels, ensuring data integrity, enforcing access control, preventing attacks, and building trust within the IoVT ecosystem. If attackers gain unauthorized access to IoVT devices, they can misuse the data in harmful ways, including vehicle theft, remote manipulation, privacy violations, fraud, cybercrime, traffic disruptions that may cause congestion or accidents, financial losses, unauthorized tracking, operational manipulation, blackmail, or malware distribution. Authentication plays a vital role in ensuring the security of the IoVT landscape, mitigating security risks, and establishing a dependable and resilient IoVT infrastructure. However, the authentication process employed in IoVT faces various challenges, including:

  • Scalability: The authentication mechanism should efficiently handle a large number of simultaneous requests without degrading overall system performance.

  • Resource Constraints: Many IoVT devices have limited computing power, memory, or energy, requiring lightweight authentication solutions.

  • Heterogeneity: IoVT networks consist of diverse devices from multiple manufacturers, highlighting the need for standardized protocols and interoperable authentication frameworks.

  • Privacy Concerns: Authentication processes often involve exchanging sensitive or personal information, making privacy preservation essential.

  • Overhead and Latency: In time-critical applications such as autonomous vehicles, excessive delays during authentication can negatively affect system responsiveness and safety.

  • Security and Key Management: The system must be resilient against attacks while ensuring secure key distribution, refresh, and management.

To tackle these challenges, it is crucial to implement a lightweight and thorough authentication protocol supported by standardized security frameworks. This protocol should ensure secure key management, offer strong protection against attacks, and enable reliable communication in diverse IoVT networks. The introduction of 5G technology presents a promising solution, as it provides ultra-low latency, high bandwidth, support for many devices, network slicing, edge computing, and improved security. By taking advantage of these features, 5G allows for real-time data exchange, seamless connectivity, and better vehicular applications, which enhance road safety, traffic efficiency, and the overall driving experience.

However, the standard 5G-AKA procedure has several security drawbacks. These include the lack of key confirmation, unlinkability, and imperfect forward and backward key secrecy, along with significant bandwidth and computational demands59.

In response, this work suggests an efficient group-based authentication and key agreement (AKA) protocol for 5G-enabled IoVT. Unlike traditional 5G-AKA, this proposed protocol uses cost-effective symmetric key cryptography while achieving equal or stronger security. It includes important features like key confirmation, unlinkability, and forward and backward key secrecy between sessions. Additionally, by using a group-based message aggregation approach, the protocol reduces signaling overhead, bandwidth use, and computational cost, making it very suitable for devices with limited resources in IoVT. This blend of security, efficiency, and scalability sets the proposed method apart from existing solutions and ensures strong protection for next-generation vehicular networks.

System architecture

The system architecture designed for secure IoVT communication is illustrated in Fig. 1. As depicted, the architecture is divided into three primary domains: the Internet of Vehicular Groups (IoVG) and the 5G Network. Each domain plays a specific role in enabling group-based authentication and key agreement (AKA) among IoVT devices.

  • Internet of Vehicular Groups (IoVG): The IoVG domain consists of clusters of IoVT devices (vehicles and RSUs) that form dynamic vehicular groups. These groups facilitate efficient group-based authentication, where an RSU acts as the group head and communicates with the core network on behalf of group members to reduce signaling overhead.

  • 5G Network: The fifth-generation (5G) network serves as the backbone for establishing secure authentication and key agreement between IoVT devices. The 5G network is divided into two main components
    • Radio Access Network (RAN): The 3GPP-compliant RAN comprises the gNodeB (gNB), which manages radio communication with IoVT devices supporting 5G connectivity. The gNB acts as an intermediary, forwarding authentication requests and responses between the IoVG and the core network.
    • Core Network: Within the 5G core network, several key functions collaboratively perform the authentication and key management processes:
      • Inline graphic Security Anchor Function (SEAF): Acts as an intermediary between IoVT devices and the home network during the authentication phase, anchoring the initial security context.
      • Inline graphic Authentication Server Function (AUSF): Located in the home network, the AUSF handles the authentication of IoVT devices and interacts with the UDM to retrieve necessary authentication data.
      • Inline graphic Unified Data Management (UDM): Hosts the Authentication Credential Repository and Processing Function (ARPF), which generates authentication vectors and session keys based on subscriber identity and policy.
      • Inline graphic Subscription Identifier Deconcealing Function (SIDF): Discovers the vehicle’s long-term identity from its temporary identifier to ensure privacy and proper identity mapping during the AKA process.

Fig. 1.

Fig. 1

Proposed system architecture for secure and efficient 5G-enabled Internet of Vehicular Things (IoVT) communication4.

Threat model and assumptions

This section outlines the threat model and the underlying assumptions considered in the design of the proposed authentication and key agreement protocol for IoVT in 5G-enabled smart transportation and road safety systems.

Network entities and trust assumptions

The network architecture consists of the following trusted and semi-trusted entities:

  • IoVT Device (Vehicle): Each vehicle is equipped with an On-Board Unit (OBU) that performs lightweight cryptographic operations and communicates with Road Side Units (RSUs) over wireless channels.

  • Road Side Unit (RSU): Acts as a semi-trusted gateway responsible for relaying authentication requests between IoVT devices and the core 5G network. RSUs are assumed to follow the protocol honestly but may be vulnerable to compromise or message interception.

  • Authentication Server Function (AUSF) and User Data Management (UDM): These are important network entities that are fully trusted. They securely store long-term keys and carry out authentication and key derivation tasks.

  • Key Distribution Function (KDF): This is a trusted module that generates session keys using agreed parameters and random values.

All entities are assumed to have synchronized clocks and secure hardware to store their private credentials. Communication between AUSF and UDM happens over secure and authenticated channels.

Adversary capabilities

The proposed protocol assumes a powerful adversary with the following abilities:

  • The adversary can eavesdrop, intercept, modify, or replay any message sent over public wireless channels.

  • The adversary can impersonate a legitimate IoVT device or RSU if proper protection is not provided.

  • The adversary may try to perform man-in-the-middle, session key compromise, or desynchronization attacks.

  • The adversary cannot compromise the internal operations of fully trusted entities such as AUSF and UDM, nor can they extract long-term secret keys stored in secure hardware.

Security goals

The protocol aims to achieve the following security goals based on the assumptions above:

  • Mutual Authentication: Both IoVT devices and the 5G core entities must confirm each other’s legitimacy.

  • Key Agreement and Freshness: A new session key should be created for every session to ensure confidentiality and integrity.

  • Perfect Forward and Backward Secrecy: Compromising a session key should not impact the secrecy of past or future session keys.

  • Anonymity and Unlinkability: The true identity of the IoVT device must stay hidden from adversaries to prevent session tracking.

  • Resistance to Common Attacks: The protocol should resist replay, impersonation, man-in-the-middle, and key-compromise attacks.

Given these assumptions, the proposed group-based authentication mechanism ensures secure, lightweight, and privacy-preserving communication during all protocol phases in the IoVT ecosystem.

Relevant literature

This section presents an overview of the authentication schemes currently used in the Internet of Vehicles Things (IoVT). These schemes use different communication methods and rely on a variety of cryptographic principles. Together, these factors create distinct authentication methods that provide different levels of security and performance. The IoVT is known for supporting a wide range of devices, especially low-power ones that need frequent authentication. However, this can cause signaling congestion, disrupting services. To tackle the issue of excessive signaling traffic, existing research looks into various group authentication and key agreement systems.

In10, Ikram et al. introduced the NAPV protocol for authenticating a group of vehicular devices in 5G networks. The main aim of the study was to reduce signaling overhead when many IoVT devices require authentication. While the proposed approach seeks to meet this objective effectively, it lacks adequate security measures. A significant shortcoming of the protocol is that it sends the vehicle’s permanent identity in plaintext over the Internet. This vulnerability risks privacy breaches, allowing unauthorized access to personal information, location data, and other sensitive information associated with the vehicle. It also increases the risk of eavesdropping, identity theft, and man-in-the-middle (MitM) attacks.

In11, Yang et al. presented a new authentication and key agreement protocol for the Internet of Vehicles. This protocol uses the Elliptic Curve Encryption Algorithm (ECC) as an asymmetric encryption method. To keep communication data confidential, the protocol combines lightweight operations like hash and XOR with the elliptic curve discrete logarithm problem. Although the protocol offers strong security, asymmetric key cryptography is still one of the more complex techniques in cryptography. The scheme differentiates between two types of identity authentication: initial and subsequent, with the latter relying on the former. A challenge in the proposed scheme is that it depends on the session. It also does not address scalability issues as the number of Internet of Vehicles devices grows. Further, the protocol does not explain how the trusted authority will perform real-time data analysis.

In12, Agilandeeswari et al. proposed a new lightweight privacy-preserving authentication and key agreement protocol for vehicle-to-smart grid networks. This protocol aims for fast source transmission and low energy consumption. However, a potential security risk arises from the protocol’s transmission of the vehicle’s permanent identity in plaintext, which threatens privacy and can lead to serious security breaches. In13, Chein et al. suggested a key transfer protocol for the fog-enabled Social Internet of Vehicles, focusing on ensuring proven security in a confidential computing environment. The protocol looks at scenarios where a vehicle moves to a different Road Side Unit (RSU) or fog node, allowing it to transfer the existing session key without needing a new session. However, this method introduces several security risks, including the potential compromise of the session key, vulnerability to man-in-the-middle attacks, unauthorized access, lack of key freshness, and missing forward/backward key secrecy.

In14, Wazid et al. designed an efficient lightweight Authentication and Key Agreement (AKA) protocol for Vehicular Ad Hoc Networks. The proposed approach was evaluated for security and demonstrated resilience against various known attack vectors. It includes features like mutual authentication, efficient dynamic RSU addition, anonymity for vehicles and RSUs, and untraceability. Despite the numerous benefits of the protocol, it requires a secure channel, such as in-person interaction, for exchanging different types of information.

In15, Bagga et al. introduced a blockchain-based Authentication and Key Agreement (AKA) protocol for the Internet of Vehicles. The protocol underwent both formal and informal security assessments to show its resistance to different types of attacks. While using blockchain technology offers some benefits for authentication and key agreement in the IoVT, there are limitations to consider. Scalability is one challenge, as the blockchain may struggle to manage the increased load during simultaneous authentication and key agreement requests from multiple vehicles and devices. Other issues include latency, cost, and energy use associated with applying blockchain technology in this context.

In16, Miao et al. presented a group Authentication and Key Agreement (AKA) protocol aimed at vehicular group authentication in 5G networks. The protocol aims for anonymity, unlinkability, mutual authentication, and resilience against specific cryptographic attacks. However, it overlooks the importance of forward/backward key secrecy and does not address the need for key confirmation. In17, Shang et al. introduced a device-to-device group-oriented AKA protocol using 5G networks. The protocol utilizes ECC and benefits from certificateless public key cryptography (CL-PKC) to enable secure and anonymous interactions among device-to-device groups within 5G networks.

In18, Ouaissa et al. introduced an enhanced group AKA protocol designed for vehicular communications in 5G networks. This protocol offers strength against various security threats. However, it overlooks important security gaps in the 5G AKA protocol, like key confirmation, unlinkability, and forward/backward key separation. Additionally, the protocol depends on the costly ECDH technique. In19, Mei et al. proposed an authentication and key agreement scheme that ensures anonymity, building the scheme on pseudonyms and a nonsingular elliptic curve. In20, Azees et al. suggested a signature-based AKA protocol for vehicular ad-hoc networks. A three-factor authentication mechanism for low-cost IoT devices was presented in21. This addresses risks like device theft and user impersonation while keeping computation and communication overhead low. Complementing these efforts, a detailed review of IoT security in22 looked at key threats across different architectural levels and noted blockchain-based solutions and consensus protocols as promising areas for future research.

Recent studies like the PPRU23 scheme for cloud-assisted vehicular networks and the PPDR24 scheme for vehicle platoons mainly focus on privacy-preserving reputation management and trust evaluation among vehicles. These methods improve feedback privacy and trust accuracy but do not tackle mutual authentication or secure key agreement.Additional recent research has also concentrated on lightweight authentication and key agreement protocols in 6LoWPAN and Industrial IoT environments, which share similar challenges with IoVT networks. For example, Ashrif et al. in25 provided a detailed survey on Authentication and Key Agreement (AKA) mechanisms for 6LoWPAN networks. This analysis examined lightweight cryptographic solutions, security threats, and formal verification methods, and outlined major challenges guiding the design of efficient authentication protocols for resource-limited IoT systems. In another study, Ashrif et al. proposed a Provably Secure Lightweight Authenticated Encryption (PSLAE) protocol for machine-to-machine (M2M) communications in Industry 4.0 in26. This protocol addresses concerns like traceability, denial-of-service, and ephemeral secret leakage while maintaining low computation and communication overhead, validated through SVO logic and Scyther tool analysis. Similarly, in27, Ashrif et al. introduced a Secure and Lightweight Group Mobility Authentication Scheme (SL_GAS) for 6LoWPAN networks, ensuring mutual authentication and user anonymity through one-time alias identities and aggregated MAC techniques. The scheme minimizes signaling and computation costs while maintaining privacy and resistance to common attacks. These recent efforts highlight the growing focus on lightweight, privacy-preserving, and formally verified authentication methods for emerging IoT ecosystems. However, few explicitly address group-based authentication and key agreement tailored for 5G-enabled IoVT settings, where mobility, large connectivity, and ultra-low latency remain key challenges. Our proposed scheme aims to fill this gap by providing a lightweight group-based AKA protocol that offers both efficiency and robust security suitable for extensive vehicular networks. Table 1 demonstrates comparative Analysis of Authentication and Key Agreement Schemes in IoVT/IoT.

Table 1.

Comparative Analysis of Authentication and Key Agreement Schemes in IoVT/IoT.

Author & Year Algorithm/Protocol Achievements Limitations
Ikram et al., 202010 NAPV Protocol Reduces signaling overhead for group authentication in 5G IoVT Transmits vehicle permanent identity in plaintext; privacy risk; vulnerable to eavesdropping and MitM attacks
Yang et al., 202011 ECC-based AKA Strong security using lightweight operations; supports initial and subsequent authentication High computational cost; session dependency; scalability not addressed; real-time data analysis handling unclear
Agilandeeswari et al., 202112 Lightweight Privacy-Preserving AKA Fast source transmission; low energy consumption Transmits permanent identity in plaintext; privacy vulnerabilities
Chein et al., 202113 Key Transfer Protocol for Fog-enabled SIoV Enables session key transfer between RSUs; supports vehicle handover Potential key compromise; no forward/backward key secrecy; vulnerable to MitM attacks
Wazid et al., 202114 Lightweight AKA Mutual authentication; anonymity; dynamic RSU addition; untraceability Requires secure channel for exchanging information (e.g., in-person interaction)
Bagga et al., 202115 Blockchain-based AKA Resilient against attacks; decentralized authentication Scalability, latency, energy consumption, and cost concerns due to blockchain overhead
Miao et al., 202216 Group AKA for 5G Vehicular Networks Achieves anonymity, unlinkability, mutual authentication Lacks forward/backward key secrecy; no key confirmation
Shang et al., 202217 D2D Group-oriented AKA with CL-PKC Supports anonymous, secure D2D group interactions Complexity due to ECC and certificateless PKC; scalability not explicitly addressed
Ouaissa et al., 202218 Enhanced 5G Group AKA Robust against security threats; group authentication Missing key confirmation; unlinkability issues; costly ECDH operations
Mei et al., 202219 Pseudonym-based AKA Provides anonymity using nonsingular elliptic curves Limited scalability analysis; lacks detailed key management for mobility
Azees et al., 202220 Signature-based AKA Lightweight authentication for VANETs Focused on signatures; may not address group mobility or multi-factor attacks
Sharma & Dhiman, 202521 Three-factor User Authentication Addresses device theft & user impersonation; low computation & communication overhead Primarily for low-cost IoT; group authentication not addressed
Sharma & Dhiman, 202522 IoT Security Survey Comprehensive taxonomy of security threats; explores blockchain solutions Review-based; no new protocol proposed; limited focus on group-based AKA
Ashrif et al., 2023–20242527 PSLAE/SL_GAS Lightweight authentication for 6LoWPAN & IIoT; mutual authentication; anonymity; low signaling & computation costs Limited to IIoT & 6LoWPAN; not optimized for 5G IoVT group mobility

Research gaps

From the above literature, it is clear that while several authentication and key agreement protocols have been put forward for IoVT and vehicular networks, significant challenges still exist. Many existing schemes depend on asymmetric cryptography, which leads to high computational and communication costs. This makes them unsuitable for IoVT devices with limited resources. Some protocols reveal vehicle identities in plaintext, resulting in serious privacy and traceability problems. Others lack key security features like forward and backward key secrecy, key confirmation, and unlinkability, which are vital for stopping impersonation and replay attacks. Additionally, methods based on blockchain or certificateless cryptography often face issues with latency, scalability, and energy efficiency, particularly in large-scale 5G-enabled IoVT environments. Moreover, very few studies tackle the signaling congestion that occurs when multiple IoVT devices frequently authenticate. Therefore, there is a clear need for a lightweight, group-based authentication and key agreement protocol that provides strong security, protects privacy, and scales well, all while keeping computational costs and communication overhead low in 5G-enabled IoVT systems.

Research contributions

Motivated by the research gaps mentioned in subsection 2.1, this research introduces a lightweight group-based authentication and key agreement (AKA) protocol specifically designed for 5G-enabled IoVT networks. The main contributions of this work are summarized as follows:

  • Lightweight and efficient design: The proposed protocol relies solely on cost-effective symmetric cryptography, using simple operations like XOR and one-way hash functions to enable secure mutual authentication and key agreement among IoVT devices within 5G environments.

  • Optimized performance: The protocol achieves strong security guarantees with minimal impact on signaling, bandwidth, and computational cost, making it highly suitable for low-power and resource-constrained IoVT devices.

  • Comprehensive security coverage: It addresses critical security requirements such as unlinkability, forward/backward secrecy, and key confirmation—features often absent in previous schemes.

  • Heterogeneity support: The design accommodates diverse IoVT devices and communication scenarios, ensuring adaptability within dynamic vehicular environments.

  • Formal validation: The proposed scheme has been rigorously analyzed and verified using the AVISPA tool and BAN logic to confirm its resistance to various known attacks and to validate its formal correctness.

Proposed protocol

Theoretical foundations

The proposed group-based Authentication and Key Agreement (AKA) protocol is based on several fundamental concepts in cryptography and network security.

  • Symmetric Key Cryptography: Ensures secure and efficient communication between IoVT devices and network entities while maintaining low computational cost.

  • Hash Functions and Message Authentication Codes (MACs): Provide data integrity and authenticity, preventing message alteration or forgery.

  • Key Derivation Function (KDF): Generates fresh session keys from long-term shared secrets and random nonces, protecting against replay and key reuse attacks.

  • Mutual Authentication Principle: Requires both communicating entities to verify each other’s identity before establishing a session, preventing impersonation or unauthorized access.

  • Group-Based Authentication Concept: Allows multiple IoVT devices to authenticate collectively through shared messages, thereby reducing signaling overhead and enhancing scalability in 5G networks.

Together, these principles form the theoretical foundation of the proposed scheme, ensuring strong security, high scalability, and computational efficiency suitable for real-time IoVT applications.

Necessary prerequisite

As illustrated in Table 2, each IoVT device and UDM shares some cryptographic information, including a long-term secret key (Inline graphic), permanent identity (P_Inline graphic) of an IoVT device, a provisional identifier (T_Inline graphic) employed to recognize the P_Inline graphic, T_Inline graphic is refreshed after each successful authentication conducted by the UDM and the IoVT device, and a sequence number (Inline graphic) to prevent replay attacks. During the registration process, the RSU shares a secret key, denoted as Inline graphic, with the UDM. All entities have the ability to employ the key derivation function (KDF) along with five different one-way cryptographic functions., Inline graphic, Inline graphic, Inline graphic, Inline graphic, and Inline graphic. It is assumed that the entities within the 5G core network maintain secure communication by establishing TLS or IPSec sessions over the designated channels within the network.

Table 2.

Set of parameters exchanged between the IoVT device and the UDM during registration.

Permanent identity Temporary identifier Secret key Sequence number
P_Inline graphic T_Inline graphic Inline graphic Inline graphic
P_Inline graphic T_Inline graphic Inline graphic Inline graphic
P_Inline graphic T_Inline graphic Inline graphic Inline graphic

Formation of vehicular groups under RSU

The Road Side Unit (RSU) uses its abilities to find and organize vehicular devices in its coverage area. Based on criteria like proximity, direction, destination, or specific application needs, the RSU creates groups of vehicles. These groups work together in the authentication process. The proposed protocol supports group formation based on the RSU’s computing power and the current network load. The RSU manages group activities while performing these key functions:

  1. Combining multiple attach requests from vehicles into a single attach request to reduce signaling overhead.

  2. Acting as a middleman between IoVT devices and the 5G network, handling secure two-way data transmission.

  3. Carrying out resource-heavy security tasks to ensure strong authentication and protection within the group.

RSU resilience and dynamic group management

To improve RSU resilience and ensure the system keeps running, several mechanisms are included. Traffic filtering reduces malicious or excessive requests, keeping availability high even during potential DoS attacks. Load balancing among multiple RSUs in an area spreads traffic evenly, avoiding single points of failure and minimizing targeted attacks. If an RSU fails, redundancy is provided by nearby backup RSUs that take over ongoing authentication requests without interruption. RSUs are chosen based on factors like load and geographic closeness, improving overall strength. For vehicles that often leave and re-enter the RSU’s coverage area, the protocol requires fresh authentication each time they re-enter. This stateless approach avoids keeping sensitive information about previously authenticated vehicles, protecting privacy and ensuring consistency in changing vehicular environments. The protocol operates in three sequential phases: Phase 1: Attach Request Initialization, Phase 2: Mutual Authentication and Key Agreement within the IoVT Network, and Phase 3: Key Agreement within IoVT Network. Each phase is carefully structured to ensure confidentiality, integrity, and resistance against common network attacks while maintaining lightweight computational overhead.

Phase1: attach request initialization

  • IoVT Device Inline graphic RSU: When an IoVT device requires services, it has to compute Inline graphic = f1(Inline graphic Inline graphic P_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID) and sends a Vehicular_NAS_Attach_Request M1: Inline graphic = (Inline graphic Inline graphic T_Inline graphic Inline graphic Inline graphic) to the RSU.

  • RSU Inline graphicSEAF: The RSU gathers Inline graphic requests from all vehicles within the group and retains the Inline graphic locally. The RSU commences the network attachment procedure by aggregating all requests into a single Vehicular_Aggregat-ed_NAS_Attach_Request (VANAR): (T_Inline graphic Inline graphic Inline graphic Inline graphic T_Inline graphic Inline graphic Inline graphic........ T_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID). The aggregated VANAR (M2) is transmitted by the RSU to the SEAF.

  • SEAFInline graphicAUSF: In order to request authentication for a vehicular devices under RSU, the SEAF dispatches Vehicular_Nausf_IoVTG_Authentication_Request M3: VNIAR = (VANAR Inline graphic SNN) to the AUSF. The message comprises two components: the VANAR and the SNN (Serving Network Name). The VANAR contains details about the vehicular devices and their access requests, while the SNN specifies the network responsible for serving the vehicle.

  • AUSFInline graphicUDM/ARPF/: Upon receiving the VNIAR, the AUSF evaluates whether the SEAF is authorized to securely access the home control services through the provided SNN. If authorization is denied, a response may be sent to the requesting device, indicating that “the serving network is not permitted to provide the service”. Following that, the AUSF proceeds to verify the RSU by obtaining the RSU_ID for the requested services. Subsequently, the AUSF sends a Vehicular_Nudm_IoVTG_Authentication_Get_Request M4: VNIAGR a modified version of VNIAR to the UDM.

Phase2: mutual authentication

After receiving the VNIAGR message from the AUSF, the UDM identifies the permanent identity Inline graphic for each vehicular device that requests authentication. This permanent identity matches the temporary identity Inline graphic found in the VNIAGR message. Using Inline graphic, the UDM retrieves the appropriate secret key Inline graphic from its database. The UDM then extracts the timestamp Inline graphic and the RSU identifier (Inline graphic) from the VNIAGR and determines the relevant RSU key Inline graphic. The UDM/ARPF then generates the 5G home network authentication vectors following the procedure outlined below:

Fig. 2.

Fig. 2

Proposed authentication and key agreement protocol.

Production of authentication vectors

  • The UDM calculates the Inline graphic = f1(Inline graphic Inline graphic P_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID), Inline graphic = f1(Inline graphic Inline graphic P_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID)........... Inline graphic = f1(Inline graphic Inline graphic P_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID) for each Inline graphic device requesting authentication in a similar manner how Inline graphic is computed. Following that, the UDM calculates Inline graphic = Inline graphic Inline graphic Inline graphic Inline graphic...... Inline graphic Inline graphic and generates a random number RAND. Subsequently, it calculates AUTN = f2(Inline graphic Inline graphic RAND Inline graphic Inline graphic Inline graphic SNN) and Inline graphic = KDF(Inline graphic Inline graphic Inline graphic Inline graphic RAND), Inline graphic = KDF(Inline graphic Inline graphic Inline graphic Inline graphic RAND)..... Inline graphic = KDF(Inline graphic Inline graphic Inline graphic Inline graphic RAND).

  • The UDM produces the expected response Inline graphic = Inline graphic Inline graphic Inline graphic Inline graphic...... Inline graphic Inline graphic and generates intermediate keys Inline graphic = f3(Inline graphic Inline graphic RAND Inline graphic Inline graphic), Inline graphic = f4(Inline graphic Inline graphic RAND Inline graphic Inline graphic)

  • Furthermore, the UDM generates an anchor key Inline graphic = KDF(Inline graphic || Inline graphic || RAND) for each device that requests authentication.

  • UDMInline graphicAUSF: After the authentication vectors are computed, the UDM generates the resulting vectors. These vectors are then provided to the AUSF in the form of the Vehicular_Nudm_IoVTAuthentication_Get_Response M5: VNUIAGR = RAND Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic T_Inline graphic Inline graphic...... Inline graphic Inline graphic Inline graphic T_Inline graphic Inline graphic AUTN.

  • AUSFInline graphicSEAF: Upon receiving M5, the AUSF performs calculations for Inline graphic = KDF(Inline graphic Inline graphic RSU_ID Inline graphic SNN), Inline graphic = KDF(Inline graphic Inline graphic RSU_ID Inline graphic SNN),......, Inline graphic = KDF(Inline graphic Inline graphic RSU_ID Inline graphic SNN), It stores Inline graphic, Inline graphic........ Inline graphic locally and subsequently provides the Vehicular_Nausf_IoVTauthentication_Response M6: VNIRE = AUTN Inline graphic RAND Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic T_Inline graphic...... Inline graphic Inline graphic T_Inline graphic to the SEAF.

  • SEAFInline graphicRSU: SEAF transmits a Vehicular_Authentication_Request M7: VAR = AUTN Inline graphic RAND to the RSU, the RSU calculates MAC’Inline graphic = Inline graphic Inline graphic Inline graphic Inline graphic............... Inline graphic Inline graphic in a similar manner as the UDM computed Inline graphic. Subsequently, the RSU proceeds to compute AUTN’= f2(Inline graphic Inline graphic RAND Inline graphic Inline graphic Inline graphic SNN). Subsequently, it verifies whether the computed Authentication Token (AUTN’) matches the received AUTN, thereby confirming the authentication of the home network as a trusted entity. If the verification is successful, the RSU sends a Vehicular_Device_Authentication_ Request M8: VDAR = RAND to each device within the group.

  • After receiving VDAR from the RSU, each IoV device computes CK’Inline graphic and IK’Inline graphic by using the device secret key KInline graphic in similar way as UDM computes CKInline graphic and IKInline graphic. Subsequently each IoV device computes anchor key Inline graphic = KDF(CK’Inline graphic Inline graphic IK’Inline graphic Inline graphic RAND) and K’Inline graphic = KDF(K’Inline graphic Inline graphic RSU_ID Inline graphic SNN). Moreover, as part of the key confirmation process, each device calculates the MACInline graphic = f1(K’Inline graphic Inline graphic RAND) and sends an Vehicular_Auth-entication_Response M9: VARe = MACInline graphic to the RSU.

  • RSUInline graphicSEAF: After receiving VARe from each device, the RSU computes XRES’= Inline graphic Inline graphic Inline graphic Inline graphic...... Inline graphic Inline graphic, where Inline graphic = KDF(Inline graphic Inline graphic Inline graphic Inline graphic RAND) and Inline graphic = Inline graphic Inline graphic Inline graphic.....Inline graphic...... Inline graphic. Further, the RSU generates a collective expected response XRES = SHA256(XRES’Inline graphic Inline graphic). The RSU sends Vehicular_Aggregated_Authentication_Response M10: VAAR = XRES to the SEAF.

  • SEAFInline graphicAUSF: Upon receiving XRES, the SEAF calculates MAC’Inline graphic = f1(Inline graphic Inline graphic RAND) for each device requesting authentication. Subsequently, the SEAF computes MAC’Inline graphic = MAC’Inline graphic Inline graphic MAC’Inline graphic.....Inline graphic...... MAC’Inline graphic (in similar way how the RSU computed Inline graphic). Furthermore, the SEAF computes XRES’= SHA256 (Inline graphic Inline graphic MAC’Inline graphic). At this stage, the SEAF verifies the authenticity of the vehicular devices and performs key confirmation by comparing XRES’and XRES (XRES’= XRES). If both values are equal, it indicates that all devices are genuine and using the same anchor key as the SEAF. Finally, the SEAF sends a Vehicular_Nausf_IoVT_Authnetication_authenticate response M11: VNIAAR to the AUSF, stating “Vehicular authentication successful”.

Following this successful authentication, the IoVT device updates T_Inline graphic and Inline graphic with the value obtained from KDF(Inline graphic Inline graphic Inline graphic Inline graphic RAND) in its database. This updated value will be utilized during the next authentication request.

Phase 3: key agreement within the IoVT network

  • Key agreement at AMF: The SEAF performs key computation to derive key Inline graphic = KDF(P_Inline graphic Inline graphic Inline graphic Inline graphic RAND) and transmits it to the AMF. The AMF then computes Inline graphic = KDF(N-NAS-enc-alg Inline graphic Alg-ID Inline graphic Inline graphic) and Inline graphic = KDF(N-NAS-int-alg Inline graphic Alg-ID Inline graphic Inline graphic) to ensure the confidentiality and integrity of the NAS (Non-Access Stratum) messages. Moreover, the AMF calculates Inline graphic = KDF(NAS UPLINK COUNT Inline graphic Inline graphic) using the Key Derivation Function (KDF), taking the NAS UPLINK COUNT and Inline graphic as inputs. This computation generates the access stratum (AS) keys. Subsequently, the AMF transfers Inline graphic to the gNB for further processing.

  • Key agreement at gNB: Upon receiving Inline graphic, the gNB performs key computations for UP (User Plane) traffic. It calculates Inline graphic = = KDF(N-UP-enc-alg Inline graphic Alg-ID Inline graphic Inline graphic) and Inline graphic = KDF(N-UP-int-alg Inline graphic Alg-ID Inline graphic Inline graphic) using the Key Derivation Function (KDF). These keys ensure the secrecy and integrity of the user plane traffic. Additionally, the gNB generates Inline graphic = KDF(N-RRC-enc-alg Inline graphic Alg-ID Inline graphic Inline graphic) Inline graphic Inline graphic = KDF(N-RRC-int-alg Inline graphic Alg-ID Inline graphic Inline graphic) using KDF, taking into account the N-RRC-enc-alg, Alg-ID, and Inline graphic parameters. These keys are responsible for ensuring the confidentiality and integrity of the RRC (Radio Resource Control) data exchanged between the IoVT devices and the gNB.

  • Key agreement at IoVT Device: After receiving confirmation of successful authentication, each IoVT device performs a key computation step. It calculates Inline graphic using the Key Derivation Function (KDF), taking P_ID, Inline graphic and RAND as inputs. Moreover, in order to guarantee the secrecy and integrity of the user plane and RRC data keys Inline graphic, Inline graphic, Inline graphic, Inline graphic, Inline graphic, and Inline graphic get calculated by the each IoVT device using identical parameters utilized by the AMF and gNB.

The proposed protocol is fully compliant with the 3GPP 5G-AKA framework and does not require any structural modifications to the existing SEAF, AUSF, or UDM procedures. Instead, it extends the 5G-AKA standard by introducing a group-based authentication mechanism managed through the RSU, which aggregates multiple device authentication requests to minimize signaling and computational overhead. The core authentication flow, key derivation functions (KDFs), and message formats remain consistent with 3GPP specifications, ensuring interoperability with existing 5G network components.

Handling group dynamics and malicious nodes

In practical vehicular networks, group composition is always changing as vehicles join and leave the communication range. The proposed protocol effectively handles these changes with a fresh authentication and key management mechanism managed by the Road Side Unit (RSU). When a new vehicle joins the group, the RSU starts authentication process and creates a new session key for secure communication. This method ensures forward secrecy and blocks the reuse of old keys. On the other hand, when a vehicle leaves or is removed due to misbehavior, the RSU quickly updates the group membership table, cancels the node’s credentials, and sends a key update message to all remaining authenticated members. This setup stops compromised or revoked nodes from regaining access and makes sure that one vehicle leaving does not impact the security or connectivity of others. Each IoVT device keeps its own session key, which allows the network to maintain secure and uninterrupted communication even with frequent membership changes or the presence of malicious entities.

Security verification by using BAN logic

BAN Logic2832 is a formal logic used for the verification of security protocols. It stands for “Believes, Assumes, and Knows” logic and widely used in the field of computer security to analyze and verify security protocols, such as authentication protocols, key exchange protocols, and secure communication protocols. It is particularly useful in identifying potential vulnerabilities and attacks that might compromise the security of a protocol. BAN logic includes multiple modal operators to study various security protocols like: A and B function as network agents, M denotes a message, and K represents an encryption key.”

  • #(A): (A is fresh) A has not been transmitted in any previous instances of the protocol.

  • Inline graphicX: (A sees X) A has received X in message M with the purpose of reading and repeating it.

  • Inline graphic: (A once said M) At one point, agent A sends message M and has believe on it.

  • Inline graphic: The key K is exclusively known to A and B, allowing them to communicate securely using it, while preventing anyone else from accessing it.

  • Inline graphic: (A believes M) Agent A has the right to hold the belief that M is true.

  • {M}Inline graphic: The key K was used to encrypt M.

  • Inline graphic: Expresses that the statement Z is a logical consequence of a conjunction of statements X and Y.

In order to provide the security proofs, let D refer to the IoVT device, R refer to the RSU and S refer to the 5G home network.

Mutual authentication

To achieve robust mutual authentication, the protocol being proposed utilizes two pre-shared secret keys, namely Inline graphic and Inline graphic. These keys are utilized in generating the challenge (AUTN) and response (XRES) parameters. Importantly, the key Inline graphic is exclusively accessible to the IoVT device (Inline graphic) and the 5G home network, while the key Inline graphic is exclusively accessible to the 5G home network and RSU. It should be emphasized that these keys are never transmitted over the network and remain undisclosed to any unauthorized entities within the network. To validate the legitimacy of the entities within the core network, the UDM employs the secrets Inline graphic and Inline graphic to generate a challenge AUTN, which is subsequently transmitted to the RSU. In turn, the RSU utilizes the same secrets as the UDM to generate its own AUTN’. The RSU then compares its AUTN’with the received AUTN to determine whether they correspond. If a match is found, the RSU can conclude that the home network is a legitimate entity. Additionally, for the authentication of IoVT devices, the RSU generates a collective expected response XRES and transmits it to the SEAF as a Vehicular_Aggregated_Authentication_Response (VAAR). The SEAF then calculates XRES’= SHA256(Inline graphic Inline graphic MAC’Inline graphic). Subsequently, the SEAF compares the computed XRES’ with the received XRES. If both values are identical, the SEAF confirms the authentication of each IoVT device.

graphic file with name d33e2251.gif

Replay attack

The proposed approach utilizes a Timestamp (Inline graphic) and Inline graphic as a preventive measure against replay attacks. In particular, when an IoVT device sends an attachment request to the HN, it includes Timestamp Inline graphic. Subsequently, the HN validates the accuracy of the Inline graphic and grants or rejects the request based on the verification result. Furthermore, the HN generates authentication vectors for the home environment by utilizing the received Inline graphic and Inline graphic, and then transmits them to the IoVT devices. Subsequently, the devices employ the same Inline graphic and Inline graphic to authenticate the vectors they receive. If the authentication vectors are determined to be valid, the IoVT device accepts the response. Conversely, if the authentication vectors fail the validation process, the IoVT device rejects the response and informs the HN about the authentication failure.

graphic file with name d33e2291.gif

Injective agreement: (key confirmation)

To prevent the establishment of a secure connection between the device and serving network using a previously used key and to avoid the replication of user data, it is crucial to reach a unanimous consensus on the unique key Inline graphic. The proposed approach, which incorporates the SNN and Inline graphic into the calculation of AUTN parameter, ensures a strong injective agreement on Inline graphic. By doing so, the device can independently verify the commitment of the Home Network to the serving network. Following that, for the purpose of key confirmation, each device computes Inline graphic and sends VARe to the RSU. The RSU then calculates Inline graphic and generates a collective expected response (XRES) using Inline graphic. The RSU sends XRES to the SEAF, upon receiving XRES, SEAF computes MAC’Inline graphic in similar way as RSU computed Inline graphic. Afterwards, the SEAF proceeds to compute XRES’and verifies the authenticity of the vehicular devices. It performs key confirmation by checking whether XRES’is equivalent to XRES (XRES’=? XRES). If both values are equal, it indicates that all devices are genuine and are using the same key as the SEAF. It’s important to note that our protocol ensures that the session key Inline graphic is never established more than once. To guarantee the uniqueness and freshness of the key Inline graphic, its computation incorporates fresh parameters such as the Timestamp (Inline graphic) and Inline graphic.

graphic file with name d33e2348.gif

Subscriber’s privacy

Preserving the confidentiality of the permanent identity P_Inline graphic of an IoVT device is of utmost importance due to its sensitive nature. This research introduces a novel method to protect the privacy of subscribers, which incorporates the utilization of a dynamically changing temporary identity identifier T_Inline graphic. Within the home network, T_Inline graphic serves as an identifier for P_Inline graphic and facilitates the generation of authentication vectors using respective Inline graphic. Furthermore, after each successful authentication the IoVT device and the home network both update to the T_Inline graphic. Through the preservation of P_Inline graphic secrecy and the freshness of T_Inline graphic, this research achieves user untraceability, device location confidentiality, and identification confidentiality. Consequently, the confidentiality of P_Inline graphic and the freshness of T_Inline graphic are effectively maintained.

graphic file with name d33e2396.gif

Anonymity and unlinkability

This research paper presents the development of an effective and reliable technique for achieving unlinkability. Each VNAR: Inline graphic Inline graphic T_Inline graphic Inline graphic Inline graphic is composed of a unique combination of a distinct Inline graphic, a freshly generated T_Inline graphic and a newly created Timestamp Inline graphic. Every VNAR request is unique and will never be identical to any previously generated request. Additionally, the process of initiating the network connection is initiated by the RSU through the transmission of a VANAR: T_Inline graphic Inline graphic Inline graphic Inline graphic T_Inline graphic Inline graphic Inline graphic........ T_Inline graphic Inline graphic Inline graphic Inline graphic RSU_ID. The VANAR is also always novel and distinctive, as it never repeats, due to the inclusion of dynamic T_Inline graphic and freshly generated Inline graphic identifiers. By implementing this approach, a significant level of unlinkability is effectively achieved, preventing any unauthorized entity from linking multiple sessions to a single IoVT device. This ensures the essential attributes of anonymity and unlinkability necessary for the Authentication and Key Agreement (AKA) procedure.

graphic file with name d33e2490.gif

Perfect forward security

Perfect forward secrecy (PFS) is a fundamental aspect of cryptographic protocols, ensuring that the compromise of a long-term private key (Inline graphic) does not compromise past or future session keys (Inline graphic). PFS holds significant importance, particularly in scenarios where the long-term private key may become compromised, such as device loss, theft, or security breaches resulting in key leakage. In the proposed protocol, the computation of the session key Inline graphic depends on multiple parameters, including Inline graphic, P_Inline graphic, Inline graphic, Inline graphic, RAND and RSU_ID. To compromise the session key Inline graphic, an attacker would require all six parameters. However, it should be noted that three of these parameters (Inline graphic, Inline graphic and RAND) are unique and generated only once for each authentication request. Furthermore, Inline graphic is never transmitted over the air interface without appropriate protection. Consequently, the compromise of Inline graphic is highly improbable.

graphic file with name d33e2547.gif

Perfect backward security

Perfect backward secrecy (PBS) is a characteristic found in cryptographic protocols, ensuring that compromising a session key (Inline graphic) does not jeopardize past or future session keys. In the proposed protocol, the computation of the session key Inline graphic relies on several parameters, including Inline graphic, P_Inline graphic, Inline graphic, Inline graphic, RAND and RSU_ID. Notably, there are certain parameters (Inline graphic, P_Inline graphic and Inline graphic) that are pre-shared exclusively between the IoVT device and the home network. These parameters are never transmitted over the air interface without adequate protection. Consequently, it is infeasible for attackers to compromise Inline graphic, P_Inline graphic during communication. In other words, even if an attacker manages to acquire a session key (Inline graphic) employed to establish a secure communication channel between two parties, they cannot exploit it to decrypt prior or subsequent communication sessions. This is because each session key is generated independently of previous session keys, ensuring perfect backward secrecy.

graphic file with name d33e2604.gif

Confidentiality & integrity protection

The implementation of the proposed methodology establishes a strong foundation for secure key agreement, ensuring the preservation of data confidentiality and integrity in both NAS (Non-Access Stratum) and AS (Access Stratum). To maintain the confidentiality and integrity of NAS data, user plane data, and RRC (Radio Resource Control) signaling, keys such as Inline graphic, Inline graphic, Inline graphic, Inline graphic, Inline graphic, and Inline graphic are generated. These keys are derived using shared secrets including Inline graphic, Inline graphic, Inline graphic and P_Inline graphic, which are exclusively shared between the IoVT device and the Home Network. Furthermore, Inline graphic and Inline graphic are pre-shared between the device and the HN and are never transmitted over the air interface in plain text. Consequently, the session keys remain resilient against attacks, and the protocol operates with utmost confidentiality and integrity.

graphic file with name d33e2661.gif

Impersonation attack

By securely transmitting the permanent identification P_Inline graphic, over the wireless link, the proposed approach effectively ensures the protection of user privacy. This ensures that even if an adversary attempts to intercept the transmission, they will be unable to access P_Inline graphic, thus preventing any possibility of impersonating a legitimate user.

Security implications of key compromise

The security of the proposed scheme depends on keeping the long-term pre-shared key Inline graphic secret between each IoVT device and the home network. Although the key is never sent and is stored safely within the device, a physical breach or side-channel extraction could reveal it. If that happens, an attacker could pretend to be the legitimate device and create valid session keys. Our protocol aims to reduce this risk by ensuring that the long-term secret is never sent or exposed during any communication phase, and all session keys are created using fresh random nonces through a secure Key Derivation Function (KDF). Therefore, even if a session key is compromised, it cannot be used to recreate the pre-shared key or affect other sessions. To lower this risk, we recommend using tamper-resistant hardware, secure key storage, and regularly updating or re-registering devices.

Table 3 presents a comparison of the objectives achieved by different Authentication and Key Agreement (AKA) protocols within the context of Internet of Vehicles (IoVT).

Table 3.

An evaluative examination of the proposed protocol in relation to different group AKA protocols within the Internet of Vehicles (IoVT) framework.

Target achieved Proposed protocol 5G-AKA33 Liu’s AKA34 Braeken AKA35 Shang’s AKA17 NAPV10 Ouaissa’s AKA18 Miao’s AKA16
Inline graphic: Mutual authentication Yes Yes Yes Yes Yes Yes Yes Yes
Inline graphic: Third party involvement No No No No No No No Yes
Inline graphic: Resistance to impersonation Yes Yes Yes Yes Yes No Yes Yes
Inline graphic: Resistance to MitM attack Yes Yes Yes Yes Yes No Yes No
Inline graphic: Subscriber privacy Yes Yes Yes Yes Yes No Yes Yes
Inline graphic: Support group authentication Yes No No No Yes Yes Yes Yes
Inline graphic: Unlinkability Yes No Yes Yes Yes No No Yes
Inline graphic: Presence of user traceability No Yes No No No Yes Yes No
Inline graphic: Forward/Backward key secrecy Yes No Yes Yes Yes No No No
Inline graphic: Resistance to billing attack Yes No Yes No No No No Yes
Inline graphic: Confidentiality & integrity Yes Yes Yes Yes Yes No Yes Yes
Inline graphic: Presence of weak binding No Yes No Yes No Yes Yes Yes
Inline graphic: Follow the standard Yes Yes Yes Yes No No Yes No
Inline graphic: Key confirmation Yes No Yes No No No No No
Inline graphic: Prevention of replay attacks Yes No No No Yes No No Yes
Inline graphic: Cryptosystem Sym Hybrid Hybrid Hybrid Hybrid Sym Sym & ECDH Hybrid

Security verification by AVISPA tool

The AVISPA software tool utilizes the Dolev-Yao Intruder model, which is a well-known framework for formally verifying security protocols3637. AVISPA, short for “Automated Validation of Internet Security Protocols and Applications,” offers a comprehensive set of formal techniques, including model checking and theorem proving, to assess and validate the security properties of protocols. By employing these methods, AVISPA helps in detecting potential vulnerabilities and weaknesses in the design and implementation of the protocols. It supports the High-Level Protocol Specification Language (HLPSL) to describe the behavior and security properties of the protocols. Additionally, it employs techniques such as On-the-Fly Model Checker (OFMC) and Constraint Logic-based Attack Searcher (CL-AtSe) to analyze and verify the correctness of security protocols. The OFMC is capable of effectively identifying security vulnerabilities like reachability and deadlock errors. On the other hand, the CL-AtSe is adept at recognizing different forms of security attacks, including authentication failures, unauthorized disclosures, and replay attacks. The primary objectives of the proposed solution are twofold: first, to establish mutual authentication between IoVT devices using the 5G network, and second, to ensure robust protection against various security attacks such as Man-in-the-Middle (MitM) attack and Denial of Service (DoS) attack. Moreover, ensuring the confidentiality and privacy of sensitive data (P_ID, Inline graphic) during transmission over wireless interfaces is of utmost importance for the protocol. Specifically, the emphasis is placed on securing the communications that transpire between IoVT devices and the base stations (gNBs), as the communications within the core 5G network are already assumed to be secure. To provide security proof, three roles, namely IoVT device, RSU, and IoVT server (representing the 5G core network), are defined as illustrated in Listings 1, 2, and 3, respectively. Li

sting 4 outlines the protocol’s desired objectives. To assess the protocol’s ability to fulfill these goals, it is evaluated using the OFMC and the CL-AtSe back-ends. Figure 3 illustrates the schema of message exchanges in the proposed protocol, while Fig. 4 provides a visual representation of the corresponding trace. In presence of an intruder, the simulation and intruder knowledge are depicted in Figs. 5 and 6, respectively. The results obtained from the evaluations, depicted in Figs. 7 and 8, illustrate that the proposed technique effectively mitigates the mentioned attacks and guarantees the confidentiality of sensitive data.

Fig. 3.

Fig. 3

Schema of message exchanges carried out in the proposed protocol.

Fig. 4.

Fig. 4

Trace of message exchanges carried out in the proposed protocol.

Fig. 5.

Fig. 5

Proposed protocol simulation in presence of the intruder.

Fig. 6.

Fig. 6

Trace of intruder knowledge during the execution of the proposed protocol.

Fig. 7.

Fig. 7

Verification results on OFMC.

Fig. 8.

Fig. 8

Verification results on CLATSE.

Listing 1.

Listing 1

Role IoVT device.

Listing 2.

Listing 2

Role RSU.

Listing 3.

Listing 3

Role IoVT server.

Listing 4.

Listing 4

Focused objectives.

Performance evaluation

This section demonstrates the effectiveness of the proposed protocol by evaluating three main metrics: 1. Signaling overhead, 2. Bandwidth use, and 3. Computational cost/transmission delay. Analyzing these metrics provides valuable insights into the protocol’s performance.

Signaling overhead

To evaluate the signaling overhead of the proposed protocol, we examine a scenario with n IoVT devices forming m IoVT groups, where Inline graphic. We measured the signaling overhead by counting the total number of control and authentication messages exchanged among the IoVT device, RSU, and the 5G core network during the authentication and key agreement phases. The total signaling cost is the sum of all transmitted and received control messages per authentication session. Next, we compare the proposed strategy with other methods found in relevant literature. Table 4 provides a detailed analysis of the signaling overhead from different approaches. It shows that the proposed protocol has a lower signaling overhead compared to the other protocols reviewed in existing literature. Figure 9 visually demonstrates the signaling overhead of recent techniques across different group sizes. Figure 9(a) shows the signaling overhead for a scenario with 1000 IoVT devices. Figure 9(b) highlights the signaling overhead generated for a situation where 10,000 IoVT devices are grouped in various sizes. The graphs illustrate that the proposed protocol outperforms other methods by generating significantly lower signaling overhead. The effectiveness of the proposed protocol becomes clearer as the number of IoVT devices and groups increases. The improvement in signaling overhead of the proposed protocol over Ouaissa’s AKA is 24.1%, 48.6% over Braeken’s AKA, 23.9% over NAPV protocol, 48.9% over Choi’s AKA, 38.6% over Fu’s AKA, 48.8% over SEGB-AKA, 23.5% over LGTH protocol, 23.3% over MTC-AKA, 65.7% over Inline graphicSEC, and 47.3% over 5G-AKA. Table 5 shows the ratio of signaling overhead generated by different protocols compared to the proposed protocol, considering a scenario with 10,000 IoVT devices.

Table 4.

Signaling Overhead Generated by Various AKA protocols, n is representing to the total IoVT devices and m is representing to the n number of groups.

Protocols Signaling overhead Protocols Signaling overhead
P1: Proposed Protocol 3n+8m P10: MTC-AKA38 4n+2m
P2: EG-AKA39 5n+2m P11: 5G-AKA33 6n
P3: Ouaissa’s AKA18 4n+6m P12: NAPV10 4n+5m
P4: Braeken’s AKA35 6n P13: SEGB-AKA40 6n+2m
P5: GBS-AKA41 6n+2m P14: Li’s AKA42 6n+2m
P6: GLARM43 6n+2m P15: LGTH44 4n+3m
P7: GBAAM45 7n P16: Liu’s AKA34 5n
P8: Choi’s AKA46 6n+3m P17: EMTC-AKA47 3n+6m
P9: Fu’s AKA48 5n+2m P18: Inline graphicSEC49 9n-2m+1

Fig. 9.

Fig. 9

An assessment of the signaling overhead of the proposed protocol in comparison to several contemporary group AKA protocols found in the existing literature, n is representing to the total IoVT devices and m is representing to the n number of groups.

Table 5.

The ratios of signaling overhead produced by different AKA protocols, in comparison to the proposed protocol, when the number of Internet of Vehicles (IoVT) devices is 10,000.

Number of groups Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic
100 1.318 1.948 1.314 1.957 1.629 1.954 1.308 1.305 2.915 1.948
200 1.303 1.898 1.297 1.917 1.594 1.911 1.284 1.278 2.835 1.898
300 1.290 1.851 1.280 1.879 1.561 1.870 1.262 1.253 2.759 1.851
400 1.277 1.807 1.265 1.843 1.530 1.831 1.240 1.228 2.686 1.807
500 1.264 1.764 1.25 1.808 1.5 1.794 1.220 1.205 2.617 1.764

Bandwidth consumption

This section evaluates the bandwidth use of the proposed protocol and compares it to other protocols mentioned in earlier studies. We looked at bandwidth consumption by measuring the total amount of communication data, in bits per second, needed for message exchanges, including authentication requests and responses. The evaluation considers different numbers of IoVT devices. Table 6 shows detailed information about the various parameters involved. Table 7 presents the bandwidth use for authentication using different existing methods within the network. In addition, Fig. 10 visually illustrates the bandwidth usage evaluation. It clearly shows that the proposed protocol uses less bandwidth than the others. As the number of devices increases, the proposed protocol also performs better. It consumes 9.4%, 32.3%, 56.3%, 20.04%, 52.01%, 51.9%, 58.2%, 63%, and 36.0% less bandwidth compared to Gharsallah’s, EPS-AKA, Miao’s, Ouaissa’s, SEGB-AKA, EG-AKA, GLARAM, Fu’s, and Choi’s Protocol, respectively. Table 8 shows the ratios of bandwidth consumption in relation to the proposed protocol.

Table 6.

The dimensions of different cryptographic parameters.

Parameter Size (Bits) Parameter Size (Bits)
F1: AUTN 128 F2: CK/IK/AK 128
F3: SUPI 128 F4: XRES 32
F5: F11: MAC 64 F6: RAND 128
F7: PI_ID 32 F8: Inline graphic 256
F9: Timestamp 32 f10: SN-ID 48
F11: Inline graphic 256 F12: Inline graphic 256

Table 7.

An examination of the bandwidth utilization of the proposed protocol, in contrast to multiple AKA protocols discussed in the literature, n represents to the number of IoVT devices and a represents to the number of authentication parameters sent to MME by UDM.

Protocol Bandwidth consumption (Bits)
P1: 5G-AKA33 1920n
P2: Gharsallah rq s AKA10 848n + 656
P3: EPS-AKA50 n(592 + 544a)
P4: Miao’s AKA16 1760n + 1472
P5: Ouaissa’s AKA18 960n + 1344
P6: SEGB-AKA40 1600n + 1912
P7: EG-AKA39 1600n + 1088
P8: GLARAM43 1840n + 1860
P9: Choi’s AKA46 1200n + 1408
P10: Fu’s AKA48 2112n
P11: Proposed Protocol 768n + 672

Fig. 10.

Fig. 10

An analysis of the bandwidth utilization of our suggested protocol in comparison to various existing group AKA protocols found in the literature.

Table 8.

The presented data illustrates the ratios of bandwidth consumption for different AKA protocols relative to the bandwidth consumed by the proposed protocol.

Number of devices Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic
2000 1.1041 1.4785 2.2916 1.2503 2.0837 2.0831 2.3960 2.7488 1.5627
4000 1.1041 1.4788 2.2916 1.2502 2.0835 2.0832 2.3959 2.7494 1.5626
6000 1.1041 1.4790 2.2917 1.2501 2.0834 2.0833 2.3959 2.7496 1.5626
8000 1.1042 1.4790 2.2917 1.2501 2.0834 2.0833 2.3959 2.7497 1.5626
10000 1.1042 1.4790 2.2917 1.2501 2.0834 2.0833 2.3959 2.7498 1.5625

Computational cost

The computational cost of different group-based AKA protocols was assessed by looking at the cryptographic operations in each scheme. The assessment used the Java Pairing-Based Cryptography (JPBC) and Bouncy Castle libraries on an Intel Core i5 processor with a 3.1 GHz clock speed, 4 GB of RAM, and a 64-bit Windows 7 operating system. The average computation times for various cryptographic operations were taken from17 and are summarized in Table 9. Here, Inline graphic shows the time for a symmetric key operation, Inline graphic indicates the cost for signature verification, Inline graphic represents the time for hash computation, and Inline graphic and Inline graphic refer to encryption and decryption operations, respectively. Likewise, Inline graphic and Inline graphic indicate the times needed for bitwise XOR and random number generation operations. Table 10 details the computed cost expressions for various existing group-based AKA protocols compared to the suggested scheme. Each expression comes from the number and type of cryptographic operations, including hash, XOR, encryption, and random number generation, used in the authentication and key agreement phases. The proposed protocol (P14) only uses lightweight symmetric operations, focusing mainly on hash and XOR functions. This leads to a total computational cost of Inline graphic. This low complexity shows the protocol’s efficiency and fits well for resource-limited IoVT devices operating in 5G networks. Table 11 further details this comparison by showing the ratio of computational costs between existing schemes and the proposed protocol for different network sizes. The results reveal that as the number of IoVT devices rises from 200 to 1000, the proposed protocol consistently outshines others, maintaining the lowest computation ratio in every scenario. This supports its better scalability and energy efficiency. The efficiency gain comes from the fact that both Phase 1 and Phase 2 of the proposed protocol rely only on lightweight operations, avoiding heavy asymmetric functions. Therefore, the protocol has minimal processing overhead while keeping all critical security features. Figure 11 provides a visual comparison of the computational costs for the eight most recent methods, further illustrating that the proposed protocol has the lowest overhead by using cost-effective symmetric key cryptography. The analysis shows that the hash and XOR operations dominate the computation with constant-time complexity and little execution delay (O(1)). Thus, the overall cost of the protocol increases linearly with the group size (O(n)), confirming its scalability for large-scale IoVT environments. Overall, these results confirm that the proposed scheme significantly cuts down on computational overhead, offers excellent scalability, and improves energy efficiency. This makes it a great fit for real-time 5G-enabled IoVT environments that require low latency and high throughput.

Table 9.

The Computational complexity associated with different cryptographic operations.

Functions Computation cost (ms)
O1: Inline graphic .0030
O2: Inline graphic .1610
O3: Inline graphic .1670
O4: Inline graphic .1600
O5: Inline graphic .1070
O6: Inline graphic .0209
O7: Inline graphic 6.147
O8: Inline graphic .0064
O9: Inline graphic .0020
O10: Inline graphic .0200

Table 10.

Computed costs of various group AKA protocols with respect to the applied cryptographic operations, n is representing to the number of IoVT devices requesting AKA.

Protocol Computation cost (ms)
P1: GBAAM45 Inline graphic + n(4*Inline graphic + Inline graphic + 2*Inline graphic) + K*(6*Inline graphic + Inline graphic)
P2: EMTC-AKA47 n(7Inline graphic + 4Inline graphic + 2Inline graphic) + 2Inline graphic + Inline graphic
P3: Ouaissa’s AKA18 n(2Inline graphic + Inline graphic) + (12n + 6)Inline graphic + 2Inline graphic
P4: Braeken’s AKA35 n(2Inline graphic + 11Inline graphic + 2Inline graphic + 2Inline graphic)
P5: NAPV10 (n + 2)Inline graphic + n(2Inline graphic + 15Inline graphic + 2Inline graphic)
P6: Choi’s AKA46 Inline graphic + 4*Inline graphic + n(Inline graphic + 2*Inline graphic + 6Inline graphic + 2Inline graphic) + Inline graphic
P7: Shang’s AKA17 (n - 1)(Inline graphic + Inline graphic) + n(2Inline graphic + 5Inline graphic + 2Inline graphic) + (n + 3)Inline graphic + (3n + 6)Inline graphic
P8: Miao’s AKA16 n(7Inline graphic + 13Inline graphic + 6Inline graphic) + 8Inline graphic + 4Inline graphic + 2Inline graphic
P9: Liu’s AKA34 n(4Inline graphic + 3Inline graphic + 2Inline graphic + 6Inline graphic + 11Inline graphic + 2Inline graphic)
P10: Fu’s AKA48 n(6Inline graphic + 3Inline graphic + 11Inline graphic + 4Inline graphic) + (Inline graphic + 2Inline graphic + 4Inline graphic + 2Inline graphic)
P11: Inline graphicsec49 n(2Inline graphic + 10Inline graphic + Inline graphic) + 2Inline graphic + 2Inline graphic + 2Inline graphic
P12: EG-AKA39 2Inline graphic + 3Inline graphic + 2Inline graphic + 8Inline graphic + n(2Inline graphic + 10Inline graphic + 2Inline graphic + 3Inline graphic)
P13: 5G-AKA33 n(17Inline graphic + 2Inline graphic)
P14: Proposed Protocol 16Inline graphic + 5(n - 1)Inline graphic + Inline graphic + 2Inline graphic

Table 11.

Ratios of computational cost incurred by various AKA protocols with the computational cost generated by the proposed protocol.

Number of devices Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic Inline graphic
200 1.036 218.475 1.412 6.112 19.806 3.081 2.254 1.192 11.521 214.275
400 1.035 218.625 1.411 6.114 19.827 3.079 2.253 1.165 11.528 213.889
600 1.035 218.675 1.411 6.115 19.834 3.078 2.253 1.156 11.530 213.761
800 1.035 218.700 1.411 6.116 19.838 3.077 2.252 1.152 11.531 213.697
1000 1.035 218.716 1.411 6.116 19.840 3.077 2.252 1.149 11.532 213.658

Fig. 11.

Fig. 11

Comparison of our suggested Protocol’s computational cost use with different current Group AKA protocols in the literature.

Energy consumption analysis

Although the proposed protocol mainly aims to reduce signaling, bandwidth, and computation overhead, it also includes a rough estimate of energy consumption to evaluate its fit for resource-limited IoVT devices. The total energy consumption (Inline graphic) is the sum of computation and communication energies, expressed as Inline graphic. Here, Inline graphic and Inline graphic. In this context, Inline graphic, Inline graphic, and Inline graphic refer to the power consumed for computation, transmission, and reception, respectively. Inline graphic is the total computation time from the analytical model, while B is the total number of transmitted bits. The computation time is given by Inline graphic and the bandwidth consumption is Inline graphic. The estimated energy usage was calculated for two typical device profiles. For a low-power IoVT device (Inline graphic W, Inline graphic W, Inline graphic W, Inline graphic Mbps), the total energy consumption per protocol execution is about 6.4 mJ. For a vehicular-grade device (Inline graphic W, Inline graphic W, Inline graphic W, Inline graphic Mbps), the estimated consumption drops to approximately 1.6 mJ. These results show that communication energy makes up the majority of the total consumption, while the lightweight computation design of the proposed protocol has a minimal impact on overall energy usage. This indicates that the protocol is energy-efficient and suitable for large-scale deployment in 5G-enabled IoVT environments.

Conclusion

In this study, we propose a lightweight group-based authentication and key agreement protocol for the Internet of Vehicular Things (IoVT). The scheme follows 3GPP standards and uses only symmetric key operations, ensuring efficiency for resource-constrained IoVT devices. The main contributions are summarized as follows. First, we introduce a group authentication method that allows multiple IoVT devices to be authenticated at the same time, which reduces signaling overhead and latency. Second, we use lightweight cryptographic techniques, such as hash and XOR operations, to lower computational costs while ensuring strong security. Third, the protocol meets key security objectives, including mutual authentication, forward secrecy, backward secrecy, key confirmation, and unlinkability without depending on third-party entities. We validate the proposed design with formal verification tools (AVISPA and BAN logic) and performance tests, showing a reduction of up to 65.7% in signaling overhead and over 50% savings in bandwidth compared to various existing methods. Overall, the protocol provides a secure, scalable, and privacy-preserving group authentication framework that suits dense vehicular networks. It also lays the groundwork for future 6G vehicular systems that need massive connectivity, ultra-low latency, and AI-assisted management. Future work will aim to improve scalability in dynamic 6G environments through AI-driven key management, intelligent authentication at the edge, and seamless integration with ultra-reliable low-latency communication (URLLC) features.

Acknowledgements

The authors extend their appreciation to the Deanship of Scientific Research at Imam Mohammad Ibn Saud Islamic University (IMSIU) for funding this work through (grant number IMSIU-DDRSP2604). 

Author contributions

All authors contributed equally.

Funding

This work was supported and funded by the Deanship of Scientific Research at Imam Mohammad Ibn Saud Islamic University (IMSIU) (grant number IMSIU-DDRSP2604).

Data availability

The data will be made available on request to the first author Garima Singh (garima.singh@thapar.edu).

Declarations

Competing interests

The authors declare no competing interests.

Footnotes

Publisher’s note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

References

  • 1.Sharma, N. & Dhiman, P. Lightweight privacy preserving scheme for iot based smart home. Recent Adv. Electr. & Electron. Eng. (Formerly Recent Patents on Electr. & Electron. Eng.17, 763–777 (2024). [Google Scholar]
  • 2.Sharma, N. & Dhiman, P. A secure addressing mutual authentication scheme for smart iot home network. Multimed. Tools Appl.84, 25111–25143 (2025). [Google Scholar]
  • 3.Sharma, N. & Dhiman, P. Design of secure and unique addressing with mutual authentication scheme in iot networks. Peer-to-Peer Netw. Appl.18, 50 (2025). [Google Scholar]
  • 4.Developers, T. D. Dia Diagram Editor. DiaDiagramEditor (2004).[Online; accessed 19-0ct-2024].
  • 5.Basin, D. et al. A formal analysis of 5G authentication. In Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, 1383–1396 (2018).
  • 6.Sodhro, A. H., Awad, A. I., van de Beek, J. & Nikolakopoulos, G. Intelligent authentication of 5G healthcare devices: A survey. Internet of Things 1–25 (2022).
  • 7.Singh, G. Gbeaka: Group-based efficient authentication and key agreement protocol for lpiomt using 5g. Internet of Things22, 100688 (2023). [Google Scholar]
  • 8.Singh, G. & Shrimankar, D. A privacy-preserving authentication protocol with secure handovers for the LTE/LTE-A networks. Sādhanā43, 1–18 (2018). [Google Scholar]
  • 9.Singh, G. & Shrimankar, D. Security analysis of lte/sae networks with the possibilities of tampering e-utran on ns3. In 2017 8th International Conference on Computing, Communication and Networking Technologies (ICCCNT), 1–7 (IEEE, 2017).
  • 10.Gharsallah, I., Smaoui, S. & Zarai, F. An efficient authentication and key agreement protocol for a group of vehicles devices in 5G cellular networks. IET Information Security14, 21–29 (2020). [Google Scholar]
  • 11.Yang, Q. et al. A novel authentication and key agreement scheme for internet of vehicles. Futur. Gener. Comput. Syst.145, 415–428 (2023). [Google Scholar]
  • 12.Agilandeeswari, L., Paliwal, S., Chandrakar, A. & Prabukumar, M. A new lightweight conditional privacy preserving authentication and key-agreement protocol in social internet of things for vehicle to smart grid networks. Multimed. Tools Appl.81, 27683–27710 (2022). [Google Scholar]
  • 13.Chen, C.-M. et al. A provably secure key transfer protocol for the fog-enabled social internet of vehicles based on a confidential computing environment. Veh. Commun.39, 100567 (2023). [Google Scholar]
  • 14.Wazid, M. et al. Design of lightweight authentication and key agreement protocol for vehicular ad hoc networks. IEEE Access5, 14966–14980 (2017). [Google Scholar]
  • 15.Bagga, P., Sutrala, A. K., Das, A. K. & Vijayakumar, P. Blockchain-based batch authentication protocol for internet of vehicles. J. Syst. Archit.113, 101877 (2021). [Google Scholar]
  • 16.Miao, J., Wang, Z., Miao, X. & Xing, L. A secure and efficient lightweight vehicle group Authentication protocol in 5G networks. Wireless Communications and Mobile Computing2021, 1–12 (2021).35573891 [Google Scholar]
  • 17.Shang, Z., Ma, M. & Li, X. A secure group-oriented device-to-device authentication protocol for 5G wireless networks. IEEE Transactions on Wirel. Commun.19, 7021–7032 (2020). [Google Scholar]
  • 18.Ouaissa, M., Houmer, M. & Ouaissa, M. An enhanced authentication protocol based group for vehicular communications over 5G networks. In 3rd International Conference on Advanced Communication Technologies and Networking (CommNet), 1–8 (IEEE, 2020).
  • 19.Sun, M., Guo, Y., Zhang, D. & Jiang, M. Anonymous authentication and key agreement scheme combining the group key for vehicular ad hoc networks. Complexity2021, 1–13 (2021). [Google Scholar]
  • 20.Rajasekaran, A. S., et al. An anonymous signature-based authentication and key agreement scheme for vehicular ad hoc networks. Secur. Commun. Networks. 2022 (2022).
  • 21.Sharma, N. & Dhiman, P. Design of a multifactor unidentified remote end user authentication mechanism for iot network. Informatica49 (2025).
  • 22.Sharma, N. & Dhiman, P. A survey on iot security: challenges and their solutions using machine learning and blockchain technology. Clust. Comput.28, 313 (2025). [Google Scholar]
  • 23.Liu, Z. et al. Ppru: A privacy-preserving reputation updating scheme for cloud-assisted vehicular networks. IEEE Transactions on Vehicular Technology (2023).
  • 24.Sun, Y. et al. Ppdr: A privacy-preserving dual reputation management scheme in vehicle platoon. IEEE Transactions on Dependable Secur. Comput. (2025).
  • 25.Ashrif, F. F., Sundararajan, E. A., Ahmad, R., Hasan, M. K. & Yadegaridehkordi, E. Survey on the authentication and key agreement of 6lowpan: Open issues and future direction. J. Netw. Comput. Appl.221, 103759 (2024). [Google Scholar]
  • 26.Ashrif, F. F. et al. Provably secured and lightweight authenticated encryption protocol in machine-to-machine communication in industry 4.0. Comput. Commun. 218, 263–275 (2024).
  • 27.Ashrif, F. F., Sundararajan, E. A., Hasan, M. K. & Ahmad, R. A secure and lightweight group mobility authentication scheme for 6lowpan networks. Sensors25, 1458 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
  • 28.Singh, G. & Shrimankar, D. Secure & efficient intra-MME handovers via mobile relays within the LTE-A and future 5G high-speed train networks. Peer-to-Peer Netw. Appl.13, 762–779 (2020). [Google Scholar]
  • 29.Kanchan, S., Singh, G. & Chaudhari, N. S. EASPSC: Efficient authentication of SignRecryption protocol using shareable clouds in VANET groups. Peer-to-Peer Netw. Appl.13, 388–411 (2020). [Google Scholar]
  • 30.Kanchan, S., Singh, G. & Chaudhari, N. S. SAPSC: SignRecrypting authentication protocol using shareable clouds in VANET groups. IET Intell. Transp. Syst.13, 1447–1460 (2019). [Google Scholar]
  • 31.Kanchan, S., Singh, G. & Chaudhari, N. S. SPSR-VCP: secure and privacy preserving SignRecryption in vehicular cyber physical systems. J. Ambient Intell. Humaniz. Comput.13, 1–20 (2022). [Google Scholar]
  • 32.Kanchan, S., Singh, G. & Chaudhari, N. S. Re-encrypting secure and efficient routing in VANET groups using sharable clouds. In 2018 4th International Conference on Recent Advances in Information Technology (RAIT), 1–6 (IEEE, 2018).
  • 33.15, G. T. . V. . R. 5G, Security architecture and procedures for 5G System. 1–251 (3GPP, 2019).
  • 34.Liu, T., Wu, F., Li, X. & Chen, C. A new authentication and key agreement protocol for 5G wireless networks. Telecommun. Syst.78, 317–329 (2021). [Google Scholar]
  • 35.Braeken, A., Liyanage, M., Kumar, P. & Murphy, J. Novel 5G authentication protocol to improve the resistance against active attacks and malicious serving networks. IEEE Access7, 64040–64052 (2019). [Google Scholar]
  • 36.Dolev, D. & Yao, A. On the security of public key protocols. IEEE Transactions on information theory29, 198–208 (1983). [Google Scholar]
  • 37.Vigano, L. Automated security protocol analysis with the AVISPA tool. Electron. Notes Theor. Comput. Sci.155, 61–86 (2006). [Google Scholar]
  • 38.Lai, C., Li, H., Li, X. & Cao, J. A novel group access authentication and key agreement protocol for machine-type communication. Transactions on emerging telecommunications technologies26, 414–431 (2015). [Google Scholar]
  • 39.Jiang, R., Lai, C., Luo, J., Wang, X. & Wang, H. EAP-based group authentication and key agreement protocol for machine-type communications. Int. J. Distributed Sens. Networks9, 1–15 (2013). [Google Scholar]
  • 40.Parne, B. L., Gupta, S. & Chaudhari, N. S. Segb: Security enhanced group based aka protocol for m2m communication in an iot enabled lte/lte-a network. IEEE Access6, 3668–3684 (2018). [Google Scholar]
  • 41.Yao, J., Wang, T., Chen, M., Wang, L. & Chen, G. GBS-AKA: Group-based secure authentication and key agreement for M2M in 4G network. In 2016 International Conference on Cloud Computing Research and Innovations (ICCCRI), 42–48 (IEEE, 2016).
  • 42.Li, J., Wen, M. & Zhang, T. Group-based authentication and key agreement with dynamic policy updating for MTC in LTE-A networks. IEEE Internet of Things J.3, 408–417 (2015). [Google Scholar]
  • 43.Lai, C., Lu, R., Zheng, D., Li, H. & Shen, X. S. GLARM: Group-based lightweight authentication scheme for resource-constrained machine to machine communications. Comput. Networks99, 66–81 (2016). [Google Scholar]
  • 44.Lai, C., Li, H., Lu, R., Jiang, R. & Shen, X. LGTH: A lightweight group authentication protocol for machine-type communication in LTE networks. In 2013 IEEE Global Communications Conference (GLOBECOM), 832–837 (IEEE, 2013).
  • 45.Cao, J., Ma, M. & Li, H. GBAAM: group-based access authentication for MTC in LTE networks. Secur. communication networks8, 3282–3299 (2015). [Google Scholar]
  • 46.Choi, D., Choi, H.-K. & Lee, S.-Y. A group-based security protocol for machine-type communications in LTE-advanced. Wirel. networks21, 405–419 (2015). [Google Scholar]
  • 47.Singh, G. & Shrimankar, D. D. Dynamic group based efficient access authentication and key agreement protocol for MTC in LTE-A networks. Wirel. Pers. Commun.101, 829–856 (2018). [Google Scholar]
  • 48.Fu, A., Song, J., Li, S., Zhang, G. & Zhang, Y. A privacy-preserving group authentication protocol for machine-type communication in LTE/LTE-A networks. Secur. Commun. Networks9, 2002–2014 (2016). [Google Scholar]
  • 49.Lai, C., Lu, R., Li, H., Zheng, D. & Shen, X. Secure machine-type communications in LTE networks. Wirel. Commun. Mob. Comput.16, 1495–1509 (2016). [Google Scholar]
  • 50.0.2.0, G. T. . V. Technical Specification Group Radio Access Network, Evolved Universal Terrestrial Radio Access (E-UTRA), Relay architectures for E-UTRA (LTE-Advanced) . 1–25 (3GPP, 2011).

Associated Data

This section collects any data citations, data availability statements, or supplementary materials included in this article.

Data Availability Statement

The data will be made available on request to the first author Garima Singh (garima.singh@thapar.edu).


Articles from Scientific Reports are provided here courtesy of Nature Publishing Group

RESOURCES