Lightweight Dual Blockchain Authentication for 6G-Enabled IoT Environments

Abstract

The emergence of 6G heterogeneous networks integrating unmanned aerial vehicles (UAVs), intelligent reflecting surfaces (IRSs), Internet of Things (IoT) devices, and fog/edge nodes creates new opportunities for intelligent and latency-sensitive applications while introducing significant security challenges. Traditional authentication mechanisms are inadequate for such dynamic, distributed, and heterogeneous environments that require secure collaborative communications. This paper proposes an authentication scheme based on Fog-RAN (Fog Radio Access Network) and a dual-blockchain architecture with smart contracts and elliptic curve cryptography (ECC). The proposed scheme provides secure network access, mutual authentication, traceability, auditability, and zero-trust enforcement. Formal verification using the ROR model, AVISPA and performance evaluation through smart-contract simulations indicate resilience to common network and cryptographic attacks and improved efficiency. Compared with existing schemes, the proposed approach reduces computation cost, bandwidth, and energy consumption by 64.2%, 59.6%, and 31.4%, respectively. These results support the suitability of the scheme for secure, scalable, and energy-efficient authentication in next-generation 6G networks.

1. Introduction

Wireless networks have evolved from first-generation (1G) to fifth-generation (5G) to meet demands for higher data rates, ultra-low latency, and massive connectivity. Surpassing these capabilities, 6G is expected to enable ubiquitous wireless intelligence for critical applications such as smart cities, autonomous vehicles, and remote healthcare. Achieving these goals requires integrating key technologies such as unmanned aerial vehicles (UAVs), Intelligent Reflecting Surfaces (IRSs), and Edge/Fog computing, which together form the backbone for future intelligent, latency-sensitive services [1].

In 6G networks, UAVs can function as aerial base stations (ABS), relays, or mobile edge/fog nodes, offering on-demand and flexible coverage in urban, rural, and disaster-stricken areas [2]. Their high mobility and line-of-sight (LoS) communication capability allow them to overcome the limitations of fixed terrestrial infrastructures, enabling rapid deployment in scenarios such as post-disaster communications and environmental monitoring [3]. Yet, UAV communications face challenges including limited energy resources, channel instability, and susceptibility to adverse environmental conditions. In parallel, programmable metasurfaces (IRS), which can manipulate electromagnetic wave propagation, have emerged as a transformative solution to improve coverage, energy efficiency, and signal robustness. The synergy of UAV mobility and IRS adaptability creates reconfigurable, intelligent wireless environments capable of addressing the constraints of conventional UAV networks [4,5].

To exploit the full potential of this IRS–UAV synergy, processing and intelligence must be deployed at the network edge, where real-time offloading and contextual decisions can occur. This requirement naturally aligns with edge and fog computing paradigms, particularly within Fog Radio Access Networks (F-RANs), which decentralize storage and computation at the network edge, thereby reducing latency, relieving fronthaul congestion, and supporting real-time applications [6,7].

Despite significant advances in these performance metrics, the security dimension of these hybrid and heterogeneous systems (IRS, UAV, F-RAN, IoT devices) remains critically underexplored [8]. Current research largely emphasizes intelligent resource allocation, AI-driven orchestration, and energy-efficient designs [3] while treating security as a secondary concern.

These 6G heterogeneous architectures inherently amplify security vulnerabilities. UAVs, with their mobility and limited energy resources, are prone to hijacking, spoofing, and denial-of-service attacks [9]. IRSs, due to their reconfigurable properties, can be maliciously exploited to manipulate wireless channels and facilitate eavesdropping [10]. Similarly, fog nodes, operating in distributed and often untrusted environments, expand the attack surface by exposing sensitive data and services to potential adversaries [7]. Furthermore, heterogeneous 6G elements must exchange information among themselves and with IoT devices to coordinate resources and optimize signal propagation. This dense coupling, combined with UAV and IoT mobility, leads to frequent handovers and inter-node interactions. Consequently, these communication patterns require continuous mutual authentication among heterogeneous nodes under varying network conditions [11].

1.1. Motivations and Contributions

Existing authentication mechanisms in 5G and early 6G architectures primarily address network access authentication between a device and the core or access network, yet they remain inadequate for heterogeneous 6G deployments characterized by mobility, distributed edge/fog control, and resource-constrained nodes. Traditional cloud or core-centric authentication further suffers from increased latency, limited scalability, and weak adaptability to dynamic, decentralized settings. Consequently, there is a clear need for a lightweight, scalable, and zero-trust-oriented access authentication mechanism that can securely onboard heterogeneous 6G entities to the Fog-RAN with low overhead [12]. Therefore, addressing this gap through the design of a lightweight, decentralized, session-aware, and zero-trust access authentication framework is crucial to ensuring the scalability, security, and trustworthiness of next-generation networks and 6G-enabled IoT environments.

The main contributions of this paper are summarized as follows:

• Lightweight authentication protocol for 6G IoT: A secure mutual authentication protocol is proposed for 6G-enabled IoT and Fog-RAN environments, enabling efficient authentication between end devices and fog nodes while supporting large-scale heterogeneous networks.
• Scalable blockchain framework: A lightweight dual-blockchain model with sidechains is designed to reduce storage and computation overhead, enhancing scalability and lowering latency in distributed fog and edge environments.
• Decentralized and auditable authentication: Smart contracts automate the verification of authentication operations while sidechains preserve authentication traces, ensuring traceability, auditability, and non-repudiation across all participating nodes.
• Efficient cryptographic design: The protocol integrates elliptic curve cryptography (ECC) to achieve strong security guarantees with reduced key sizes and low computational overhead, making the scheme suitable for resource-constrained IoT devices.
• Zero-trust enforcement: The proposed framework adopts a zero-trust security paradigm in which no entity, device, or network component is inherently trusted. Authentication and access are continuously verified through decentralized consensus and smart contracts.
• Validation and performance analysis: Formal verification and performance evaluation demonstrate the protocol’s resilience against common network and cryptographic attacks while maintaining low latency and scalability.

1.2. Organization

The remainder of this paper is organized as follows: Section 2 reviews related work on authentication and security in heterogeneous 6G environments; Section 3 presents the system model and adversary models; Section 4 the proposed dual-blockchain framework; Section 5 details the security analysis and formal verification; Section 6 reports the performance evaluation results; Section 7 presents the smart contract implementation and gas profiling; and Section 8 concludes the paper and outlines future research directions.

2. Literature Survey

Advances in 6G networks have accelerated research into secure and scalable authentication for heterogeneous environments. Recent works converge lightweight cryptography, blockchain-based decentralization, and emerging paradigms such as physical layer security, artificial intelligence, and quantum resilience. This section reviews key authentication solutions for 6G-Enabled Environments, structured by lightweight, blockchain-based, and advanced models, highlighting core technologies, validation strategies, strengths, and main limitations across distributed settings.

2.1. Lightweight Authentication Schemes

Several studies have addressed security and key management in wireless communication environments. For instance, Yadav et al. proposed a secure communication framework based on key distribution mechanisms to enhance data protection in wireless networks. However, such approaches are primarily designed for conventional wireless infrastructures and do not explicitly address the requirements of heterogeneous 6G environments, which involve highly dynamic networks, massive IoT connectivity, and integration with emerging technologies such as fog computing and blockchain [13].

Lightweight authentication protocols are engineered to minimize computational and communication overhead, enabling secure identity management on resource-constrained devices typical in IoT and 6G applications. These methods predominantly leverage compact cryptographic primitives—such as ECC, PUFs, and hash chains—to deliver mutual authentication, perfect forward secrecy (PFS), and resistance to impersonation and man-in-the-middle (MITM) attacks. Notably, Xia Feng et al. [14] propose a dual authentication scheme for 6G V2V communications integrating PUFs, zero-knowledge proofs, and MASK operations, achieving handshake latencies suitable for real-time vehicular networks, validated in NS-3 simulations. Khan et al. [15] and Manasha Saqib et al. [16] extend mutual authentication to maritime and IoT-critical applications, utilizing ECC and hash functions with formal verification via Scyther and ROM, but acknowledge increased communication cost and scalability limitations. Asif et al. [17] introduce ECDH with AES-GCM for IoMT, focusing on threat mitigation and computational efficiency, though highlighting the need for energy optimization and post-quantum integration in future deployments. Wu et al. [18] contribute hash and biometric-based protocols formally proven in the ROR and ProVerif models, yet report higher computational and communication costs compared to other lightweight approaches. Collectively, these protocols show advances in attack resilience and efficiency but often lack support for decentralized trust and full real-world deployment metrics.

2.2. Decentralized and Blockchain-Based Approaches

Blockchain-based authentication protocols remove centralized trust anchors, providing tamper-evident auditability and programmable, cross-domain access control, features essential for heterogeneous, low-trust IoT and 6G environments where operators and devices interoperate at scale [19,20,21]. Kumar & Ali [21] demonstrate a PBFT-based blockchain framework for maritime 6G-IoT, integrating ECC and hash functions with formal security proofs under the ROR and Scyther models, yielding robust resistance to replay, impersonation, and insider threats at reduced computational cost. Xiaoyu Du et al. [20] and Rahul Singh [22] address fog node-assisted blockchain for UAV swarms and lightweight consortium chain frameworks for IoV, respectively, validated through security theorems, attack model analysis, and pseudonymization, but note the need for operational blockchain testbeds and fog node capacity evaluations. SON et al. [23] pioneered zero-trust models over consortium blockchains using ECC and attribute-based encryption (ABE), validated in BAN Logic, RoR, and AVISPA, offering dynamic access control and anonymity with higher computational cost. Zhang et al. [24] and Mukesh Soni [25] propose dual-chain and group authentication designs for satellite and heterogeneous 6G scenarios, leveraging anonymous credentials and batch verification for stateful, efficient handover; however, they highlight the necessity for improved scalability and batch protocol evaluations in varied real-world network conditions. Overall, while blockchain-assisted schemes advance auditability and cross-domain trust, they introduce latency, consensus, privacy, and cost concerns, underscoring the need for hybrid off-chain designs and standardized benchmarking on cost, performance, and scalability.

2.3. Advanced Mechanisms: AI and Quantum-Resistant Authentication

Recent protocols incorporate artificial intelligence and quantum-resistant cryptography to address dynamic, heterogeneous threats and future-proof authentication. AI-driven approaches in 6G HetNets enable adaptive, context-aware, and real-time security decisions by learning traffic patterns and user behaviors, thereby improving anomaly detection and lowering false authentication rates. He Fang [26] exemplifies this with distributed edge learning for VANET and UAV authentication, achieving low-latency and spoofer localization, but requiring trade-offs between peer cooperation and communication cost. Sakraouia et al. [19] present a blockchain-integrated AI scheme for massive IoT in healthcare, combining real-time risk detection and dynamic multi-factor authentication, verified in BAN Logic, yet reliant on the robustness of the underlying blockchain and AI data quality.

Quantum and post-quantum cryptography form the next defensive frontier as classical schemes (RSA, ECC) face obsolescence from quantum attacks and “harvest-now, decrypt-later” risks. Recent proposals, such as Rohini Poolat Parameswarath [27], integrate NIST-standardized CRYSTALS-Kyber PQKEM and AES for IoT/6G transport, formally verified in the RoR model, providing semantic and quantum-safe authentication but at a higher computational cost than legacy approaches. Quantum Key Distribution (QKD), implemented where network conditions permit, supplies information-theoretic security based on quantum physics, while PQC broadens cryptographic resilience via robust computational assumptions.

Together, these evolving mechanisms signal a shift toward intelligent, fully decentralized, and quantum-resistant authentication frameworks that advance the integrity and scalability necessary for next-generation 6G network deployments.

Table 1 presents a comparative summary of recent authentication protocols for 6G-enabled environments, highlighting that despite significant progress in authentication and key management mechanisms for wireless and IoT environments, several limitations remain. Many existing solutions focus either on blockchain-based authentication mechanisms or on lightweight cryptographic protocols, but rarely address both aspects simultaneously in the context of 6G-enabled heterogeneous networks.

Table 1. Comparative Analysis of Recent Authentication Protocols for 6G-Enabled Environments (2022–2025).

Category	Authors (Year)	Domain/Application	Core Mechanism/Validation	Key Strengths	Limitations
Lightweight	[14] (2024)	V2V (6G)	PUF + ZKP + MASK/ROM, NS-3 simulation	Dual authentication, computation cost	Simulated; lacks real-world testing
Lightweight	[15] (2022)	Maritime Comm. Network	ECC/ROM	PFS, MiTM/impersonation resistance	Higher communication cost
Blockchain	[21] (2024)	6G-IoT, Maritime	PBFT + ECC + Hash/Scyther, ROR	Decentralization, efficiency, anonymity	No real blockchain test
Blockchain	[23] (2024)	6G-enabled IoT	Consortium Blockchain + ECC + Zero Trust/AVISPA, BAN Logic	Zero-trust, dynamic access, anonymity	Higher computational cost
Blockchain	[25] (2023)	6G HetNets	Blockchain + ECC + Batch verification/AVISPA	Mutual authentication, low delay	Mainly group scenario tested
Advanced (AI)	[26] (2023)	VANETs & UAVs	Edge intelligence + Distributed learning	Low latency, spoofer localization	Accuracy vs. overhead trade-off
Advanced (AI + BC)	[19] (2025)	Massive IoT, Healthcare	Blockchain + Risk Detection + MFA/BAN Logic	Lightweight, adaptivity, privacy	Depends on secure BC & AI accuracy
Advanced (Quantum)	[27] (2024)	6G Transport Systems	PQC (Kyber) + AES/RoR (formal)	Quantum-safe & threat resilience	Higher computation cost

Moreover, several existing approaches rely on single-chain blockchain architectures, which may lead to scalability limitations and increased latency when supporting a large number of IoT devices. In addition, the potential role of fog nodes as intermediate authentication entities is often overlooked, despite their importance in enabling low-latency processing and distributed security management in future 6G architectures.

Consequently, there is a need for a lightweight, scalable, and secure authentication framework capable of supporting large-scale IoT deployments while leveraging the advantages of fog computing and blockchain technologies. To address this research gap, this paper proposes a lightweight dual-blockchain authentication scheme for 6G-enabled IoT environments, where identity management and authentication operations are separated between a mainchain and a sidechain, thereby improving scalability, security, and computational efficiency.

3. System and Adversary Models

3.1. System Model

Figure 1 illustrates the envisioned architecture of a heterogeneous 6G network ecosystem integrating space, air, ground, and underwater communication domains. The system combines LEO satellites, high-altitude platform stations (HAPS), UAV-assisted aerial networks, terrestrial infrastructure, and maritime communication systems to provide seamless global connectivity. High-capacity terahertz (THz) links enable ultra-high-speed data transmission across different network segments, while reconfigurable intelligent surface (RIS)-assisted communication enhances signal propagation and coverage in complex environments. In the terrestrial domain, V2X-enabled transportation systems and IoT devices interact with the network through Fog-RAN and edge intelligence, supporting low-latency services and distributed processing. The overall architecture is coordinated by an AI-native core network, which manages network slicing, resource orchestration, and intelligent service delivery, ensuring scalable, adaptive, and secure communication for next-generation 6G applications.

Figure 1. Architecture of the considered heterogeneous 6G-enabled IoT environment.

3.2. Adversary Model

This work adopts an extended Dolev–Yao threat model to rigorously evaluate the security of authentication protocols in the proposed 6G fog-enabled system architecture (Figure 1). We assume a powerful adversary capable of controlling all communication channels, including space, air, ground, and underwater networks, as well as fog and core backhaul links. The adversary can eavesdrop on, replay, modify, inject, and block messages at any point in the network. Additionally, device-level threats are considered, such as physical compromise of smart terminals and fog nodes through sensor cloning and rogue fog server deployment.

4. The Proposed Approach

In this section, we describe the proposed authentication scheme. Figure 2 illustrates the overall system model, while Table 2 summarizes the notations and their corresponding descriptions.

Figure 2. Proposed dual chain-based authentication model.

Table 2. Parameter notations.

Symbol	Definition
E	Elliptic curve
P	Base point of curve E
N	A prime number
x, y	Random numbers ∈ $Z_P^{*}$
F-RAN	Fog Radio Access Network
${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$	End device number i
${\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$	Identity of end device ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$
${\mathrm{I}\mathrm{D}}_{\mathrm{F}}$	Identity of F-RAN
${\mathrm{S}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$	The RS’s signature assigned to ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$
${\mathrm{c}\mathrm{e}\mathrm{r}\mathrm{t}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$	Lightweight authentication credential issued by RS
TS	Timestamp
${\mathrm{P}\mathrm{K}}_{\mathrm{F}},$ ${\mathrm{K}}_{\mathrm{F}}$	the public and secret keys of F-RAN
${\mathrm{P}\mathrm{K}}_{\mathrm{E}\mathrm{D}},$ ${\mathrm{K}}_{\mathrm{E}\mathrm{D}}$	the public and secret keys of ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$
$\mathrm{S}\mathrm{k}$	Session key
${\mathrm{T}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$	Token prepared by ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ for F-RAN
${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$	A value used by F-RAN to authenticate ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$
${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$	A value used by ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ to authenticate F-RAN
${\mathrm{E}\mathrm{M}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$	The encrypted message generated by F-RAN for ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$
${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$	The encrypted message generated by ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ for F-RAN
ENC[M]PK	Encrypts message M with a public key
DEC[EM]K	Decrypts an encrypted message EM with a private key
H()	One-way hash function
(∙)	Ecc Multiplication
⊕	XOR operation

The proposed scheme adopts a dual private blockchain architecture comprising a mainchain and a sidechain. Blockchain is used in this work for three reasons: (i) decentralizing trust in Fog-RAN deployments where infrastructure may be distributed and partially untrusted; (ii) ensuring traceability and auditability through immutable authentication records; and (iii) enabling automated and verifiable enforcement of access policies via smart contracts. To avoid excessive latency and overhead, frequent access-authentication operations are executed on the sidechain, while long-term identity anchoring and integrity guarantees are maintained on the mainchain.

To manage consensus, Practical Byzantine Fault Tolerance (PBFT) is deployed, providing a lightweight yet robust mechanism well-suited for private blockchains. PBFT guarantees data integrity and reliability even if up to (N/3 − 1) of the N nodes are compromised, requiring at least (2N/3 + 1) nodes to validate and append a new block.

For cryptographic security, the protocol utilizes the Elliptic Curve Integrated Encryption Scheme (ECIES) with a 160-bit key, ensuring a security level equivalent to that of a 1024-bit RSA key, thus achieving strong protection against adversarial threats while maintaining low-latency authentication.

The authentication procedure in the proposed protocol is systematically divided into three fundamental phases: Initialization, Registration, and Authentication.

4.1. Setup Phase (Initialization)

The setup phase constitutes the initial stage of the system’s development process. During this phase, the Registration Server (RS) selects the system’s common public parameters and publishes them globally to establish the operational environment for the subsequent phases of the proposed scheme. During this phase, RS:

• Generates the elliptical curve E and sets its public parameters n and P.
• Selects its public and secret keys (${\mathrm{P}\mathrm{K}}_{\mathrm{C}}$ and ${\mathrm{K}}_{\mathrm{c}}$), where ${\mathrm{K}}_{\mathrm{C}}\in {\mathrm{Z}}_{\mathrm{p}}^{*}$ and ${\mathrm{P}\mathrm{K}}_{\mathrm{C}}={\mathrm{K}}_{\mathrm{c}}·\mathrm{P}.$
• Defines a unidirectional hash function H: {0, 1}* → {0, 1}^L; where L is the length of the output or hash.
• Publishes the public parameters: <E, P, n, H(), ${\mathrm{P}\mathrm{K}}_{\mathrm{C}}$>.

Upon completion of the system initialization, the procedure advances to the registration phase. This phase commences with the registration of the F-RAN nodes, as the blockchain infrastructure is deployed over these nodes to enable decentralized management and secure data exchange.

4.2. Registration Phase

During the registration phase, RS records all entities participating in the network, including the F-RAN nodes, UAV, IRS, smart end terminals ${ED}_i$. All registration operations are conducted through a secure communication channel, ensuring that no data can be intercepted, altered, or accessed by unauthorized parties.

The establishment of this secure channel depends on the deployment context. For example, the registration of an ${ED}_i$ may be performed through a direct or physical setup, while the registration of F-RAN nodes can be executed by network operators during the system installation process.

Figure 3 depicts the registration phase. The registration procedure for each ${ED}_i$ is carried out through the following steps:

Figure 3. Registration phase.

${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ initiates the registration process by sending its identity ${\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$ to the RS within a registration request transmitted through a secure channel. Upon receiving the registration request, the RS generates, for the ${ED}_i$, a secret key ${\mathrm{K}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$. It then computes the corresponding public key, ${\mathrm{P}\mathrm{K}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$, the credential, ${\mathrm{c}\mathrm{e}\mathrm{r}\mathrm{t}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$ and the RS-generated signature, ${\mathrm{S}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$ as follows:

• $K_{EDi}\in Z_p^{*}$
• ${PK}_{EDi}=K_{EDi}·P$
• ${cert}_{EDi}=H\left({ID}_{EDi} \parallel K_{EDi}\right)\oplus H\left({ID}_{EDi} \parallel K_C\right)$
• $S_{EDi}$ = $H({ID}_{EDi} \parallel K_C)$.

It is important to note that ${cert}_{EDi}$ does not represent a conventional X.509 certificate. Instead, it denotes a lightweight authentication credential generated by the RS for resource-constrained IoT devices. The value $S_{EDi}$ acts as a verification token created using the RS secret key $K_C$, which binds the device identity to the authority of the RS. The XOR operation is used to combine the hashed values while minimizing storage and communication overhead. This lightweight design is well-suited for 6G-enabled IoT environments, where devices often have limited computational and memory resources.

Afterward, the RS records the tuple (${ID}_{EDi}, {PK}_{EDi}, {cert}_{EDi}$) for each ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ on the mainchain using the AddDev() function from the smart contracts deployed on the mainchain. It then sends (${PK}_{EDi}, K_{EDi},$ $S_{EDi}$) to ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ through the secure channel. The ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ subsequently stores these parameters in its local repository and keeps them confidential.

4.3. Mutual Authentication Phase

Figure 4 depicts the mutual authentication phase, which proceeds through the following steps:

Figure 4. Authentication phase.

Step 1: ${ED}_i\to {FRAN}_j:$ M1= {${EM}_{ED-F}$}

Initially, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ generates a random value x and a timestamp ${TS}_i$. Subsequently, it applies the hash function H(), and XOR operation, to derive a token ${\mathrm{T}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$ and an authentication ${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$ for the corresponding ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$, as follows:

• $T_{ED-F}=$ $H\left({ID}_{EDi} \parallel K_{EDi}\right)\oplus S_{EDi}$
• ${Auth}_{ED-F}=$ $H\left(T_{ED-F}{ \parallel ID}_{EDi} \parallel x·P·K_{EDi}{ \parallel TS}_i\right)$

Next, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ encrypts (${\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}},{\mathrm{T}\mathrm{S}}_{\mathrm{i}} \mathrm{a}\mathrm{n}\mathrm{d} x$) using the public key of the corresponding ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}},{\mathrm{P}\mathrm{K}}_{\mathrm{F}}$ to compute ${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$, where:

• ${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}=\mathrm{E}\mathrm{N}\mathrm{C}{[{\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}},{\mathrm{T}\mathrm{S}}_{\mathrm{i}},x]}_{{\mathrm{P}\mathrm{K}}_{\mathrm{F}}}$

Finally, the encrypted message ${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$ is transmitted to the ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ for subsequent processing.

Step 2: ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}\to {\mathrm{E}\mathrm{D}}_{\mathrm{i}}:$ M2 = {${\mathrm{E}\mathrm{M}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$}

Upon receiving M1, the ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ first decrypts the message using its private key, ${\mathrm{K}}_{\mathrm{F}}$, and it verifies the validity of the timestamp, ${\mathrm{T}\mathrm{S}}_{\mathrm{i}}$. If the timestamp validation succeeds, ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ retrieves the corresponding ${\mathrm{c}\mathrm{e}\mathrm{r}\mathrm{t}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$ and ${PK}_{EDi}$ associated with ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ from the blockchain by invoking the MainChain smart contract, through the GetInfo (${\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$) function. Using these retrieved parameters, ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ computes the authentication value ${Auth}_{ED-F}^{\prime }$ necessary to verify the authenticity of ${Auth}_{ED-F}$, as follows:

• ${Auth}_{ED-F}^{\prime }=H({cert}_{EDi}{ \parallel ID}_{EDi} \parallel x·{PK}_{EDi}{ \parallel TS}_i)$

If ${Auth}_{ED-F}^{\prime }$ matches ${Auth}_{ED-F}$, ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ confirms the integrity of message M1 and successfully authenticates ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$. This result demonstrates that ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ holds valid secret credentials, which were generated during the registration phase and subsequently employed in the derivation of authentication parameters in step 1. If a discrepancy is detected, authentication fails and the connection is immediately terminated.

Now ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ chooses a random number y, and it generates a timestamp ${\mathrm{T}\mathrm{S}}_{\mathrm{j}}$. Then, it calculates for ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ an authentication value ${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$ and encrypted messages as follows:

• ${Auth}_{F-ED}=$ $H\left({cert}_{EDi}{ \parallel ID}_F \parallel y·P·K_F{ \parallel TS}_J\right)$
• ${EM}_{F-ED}=ENC{[{ID}_F,{Auth}_{F-ED},{TS}_j,y]}_{{PK}_{ED}}$

After that, ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ transmits ${EM}_{F-ED}$ and computes the session key $Sk$ as follows:

• $Sk=H({cert}_{EDi}{ \parallel ID}_{EDi}{ \parallel ID}_F \parallel x·y)$

Finally, ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ authenticates ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ on the sidechain by invoking the smart contract AuthDev( ) function, supplying ${ID}_{EDi}$, ${ID}_F$, ${TS}_j$, and $isAuth$ as input parameters, where $isAuth$ is a Boolean variable indicating whether ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ is successfully authenticated to ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$.

Step 3:

Once M2 is received, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ decrypts the message using its private key ${\mathrm{K}}_{\mathrm{E}\mathrm{D}}$ and verifies the validity of the timestamp ${TS}_j$. If the timestamp validation is successful, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ computes the authentication value ${Auth}_{F-ED}^{\prime }$, which is required to ${Auth}_{F-ED}$, as follows:

• ${Auth}_{F-ED}^{\prime }=H(T_{ED-F}{ \parallel ID}_F \parallel y·P{K}_F{ \parallel TS}_J)$

If ${Auth}_{F-ED}$ equals ${Auth}_{F-ED}$, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ confirms the integrity of message M2 and successfully authenticates ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$. This verification also confirms that ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ has legitimate secret credentials retrieved from the private mainchain, to which access is restricted exclusively to authorized nodes. Any detected mismatch results in authentication failure and instant connection termination. After the successful authentication of ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$, ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ proceeds to compute the session key for subsequent secure communications, as follows:

• $Sk=H(T_{ED-F}{ \parallel ID}_{EDi}{ \parallel ID}_F \parallel x·y)$

5. Security Analysis

5.1. Informal Analysis

In this section, informal security analysis is conducted through Propositions 1–7, each demonstrating the proposed scheme’s resilience against a broad spectrum of potential attacks.

Proposition 1.

The proposed scheme is resilient against replay attacks.

Proof. 

In the proposed protocol, every message exchanged between the End Device and the F-RAN incorporates both a current timestamp and a fresh random nonce. These values are unique to each communication instance. As a result, even if an adversary intercepts and attempts to replay a previously transmitted message, the outdated timestamp and nonce will be detected during the verification process, causing the message to be rejected by the intended receiver. Therefore, an adversary cannot successfully replay old authentication or key management messages, demonstrating that the scheme is secure against replay attacks. □

Proposition 2.

The proposed scheme is resilient against man-in-the-middle (MitM) attacks.

Proof. 

The proposed scheme is resilient against MitM attacks. In this attack, an adversary intercepts and alters the communication between legitimate parties. In the proposed scheme, all exchanged messages include random session parameters (${TS}_i$, ${TS}_j$ $x, y$), identities (${ID}_{EDi}, {ID}_F$), and secret credentials ($S_{EDi} {, cert}_{EDi}$), authentication codes (${Auth}_{ED-F}, {Auth}_{F-ED}$) and encrypted messages (${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}},{\mathrm{E}\mathrm{M}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$) are computed using cryptographic hash and encryption functions bound to each session’s unique parameters and private keys. An adversary intercepting or injecting messages cannot generate valid authentication codes or session keys without access to the secret keys (${\mathrm{K}}_{\mathrm{E}\mathrm{D}}{,\mathrm{K}}_{\mathrm{F}}$) and fresh random values. Any modification will be detected during the session verification phase since the computed and received values will differ. Moreover, blockchain-based smart contract checks ensure message integrity and prevent unauthorized modification. Hence, the proposed scheme ensures complete resilience against MitM attacks. □

Proposition 3.

The proposed scheme is resilient against impersonation attacks.

Proof. 

The proposed protocol is resistant to impersonation attacks, where an adversary attempts to pose as a legitimate entity. Each authentication code (${Auth}_{ED-F}, {Auth}_{F-ED}$) is generated using fresh random values (x, y), timestamps, and secret credentials ($S_{EDi}{, cert}_{EDi}, {\mathrm{K}}_{\mathrm{E}\mathrm{D}}{,\mathrm{K}}_{\mathrm{F}}$), which are exclusively known to legitimate devices. Without these dynamic parameters and confidential keys, an attacker cannot construct valid authentication data or derive the correct session key. Any replay or forged credentials will fail mutual verification and key derivation. Therefore, even if an adversary attempts to masquerade as a valid node, it will be detected and rejected, proving strong resistance to impersonation. □

Proposition 4.

The proposed scheme ensures perfect forward secrecy.

Proof. 

Forward secrecy is ensured because the session key $Sk$ is derived from fresh random values ($x,y)$, and exchanged data $\left({ID}_{EDi}{,ID}_F\right)$ between ${ED}_i$ and ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$ during each authentication session. Even if an adversary later compromises the long-term secret credentials $\left({\mathrm{K}}_{\mathrm{E}\mathrm{D}}{,\mathrm{K}}_{\mathrm{F}}\right)$ they cannot retroactively compute past session keys without knowledge of the ephemeral values and session parameters, which are securely transmitted using ECIES. Therefore, compromise of long-term keys does not allow decryption of previous communications, guaranteeing the protocol’s perfect forward secrecy. □

Proposition 5.

The proposed scheme is resilient against privileged-insider attack.

Proof. 

A privileged-insider attack occurs when a trusted network entity, such as an ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{k}}$ node, abuses its authorized access to system records or blockchain data to compromise security by reconstructing session keys, impersonating users, or extracting confidential information. □

The proposed protocol mitigates these threats because the session key $Sk= H\left(T_{ED-F}{ \parallel ID}_{EDi}{ \parallel ID}_F \parallel x· y\right)$ is derived from ephemeral, and session-specific nonces that are exclusively generated and known by the legitimate communicating parties (${{ED}_i, \mathrm{a}\mathrm{n}\mathrm{d} FRAN}_j$) during each session. These values are securely transmitted via ECIES encryption and are never stored after session completion, preventing persistent insider access. Consequently, even with main chain records or side chain audit trail access, a privileged insider cannot reconstruct session keys or impersonate any party, ensuring strong resilience against privileged-insider attacks.

Proposition 6.

The proposed scheme preserves anonymity and untraceability.

Proof. 

The proposed protocol employs cryptographically protected, session-specific random values and conceals real identities during each authentication session. The actual devices identities $\left({ID}_{EDi}\right)$ are never transmitted in plaintext; instead, they are embedded within hashed or ECIES-encrypted structures (${{Auth}_{ED-F},\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$). This prevents any external observer or network insider from linking authentication messages to specific devices. Moreover, each session is uniquely characterized by fresh ($x,y)$, and (${TS}_i$, ${TS}_j)$, ensuring that protocol transcripts cannot be correlated across different sessions for tracking purposes. The integration of ECIES guarantees the confidentiality of exchanged parameters, while blockchain-based smart contracts reinforce unlinkability and verifiable anonymity. Consequently, adversaries cannot deduce real identities or establish traceable communication patterns, thereby ensuring both anonymity and untraceability within the proposed system. □

Proposition 7.

The proposed scheme ensures compliance with the Zero Trust security model.

Proof. 

In the proposed authentication protocol, Zero Trust is achieved by enforcing continuous verification, decentralization, and the elimination of implicit trust among entities. Unlike traditional hierarchical trust architectures, the scheme employs a blockchain-based authentication layer, where every transaction and verification step is validated through smart contracts, ensuring integrity and accountability without reliance on any centralized authority. Each authentication session uses fresh random nonces, timestamps, and session-specific keys, meaning trust is never preserved between sessions. Furthermore, mutual authentication between the End Device and F-RAN guarantees that both entities prove their legitimacy cryptographically before communication begins. All exchanged parameters are protected using ECIES encryption, and the distributed ledger prevents credential reuse or manipulation. Therefore, since trust is continuously verified, dynamically established, and never assumed, the proposed scheme fully adheres to the principles of the Zero Trust model. □

The Table 3 demonstrates that the proposed scheme achieves comprehensive coverage of all evaluated security properties, outperforming existing approaches in perfect forward secrecy, privileged-insider resistance, anonymity and untraceability, as well as Zero Trust compliance. These strengths highlight its robustness and privacy-preserving design, positioning it as a highly reliable framework for next-generation network authentication. The organized comparison provides a clear rationale for adopting the proposed protocol over state-of-the-art alternatives.

Table 3. Security features comparison.

	[14] (2024)	[21] (2024)	[20] (2024)	[25] (2023)	[19] (2025)	[27] (2024)	Proposal
Replay attack	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Mitm Attack	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Impersonation	Yes	Yes	Yes	Yes	Yes	Yes	Yes
PFS	No	Yes	No	Partial	Yes	No	Yes
Privileged-insider	Yes	Yes	Partial	Yes	Yes	No	Yes
Anonymity and Untraceability	Yes	Yes	Yes	Partial	Yes	No	Yes
Zero trust	No	No	No	Partial	Partial	No	Yes
Mutual authentication	Yes	Yes	Yes	Yes	Yes	Yes	Yes

5.2. Formal Proof Under RoR Model

To formally demonstrate the security of the proposed authentication protocol, we analyze the confidentiality of the established session key under the Real-Or-Random (ROR) model [28]. The goal is to prove that any probabilistic polynomial-time adversary cannot distinguish the real session key from a random value with non-negligible advantage.

5.2.1. Adversarial Model

A probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ operating under the extended Dolev–Yao model, defined in Section 3.2, can control the communication channel and interact with protocol participants through the following queries:

• Execute(${{\mathrm{E}\mathrm{D}}_{\mathrm{i}},\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$): This query models a passive observation of a complete protocol execution. The adversary obtains transmitted messages $M_1$ and $M_2$.
• Send(${\mathsf{\Pi }}^{\mathit{s}}$, $\mathit{m}$): This query models active attacks, allowing the adversary to send a forged message $m$ to a protocol instance ${\mathsf{\Pi }}^s$.
• Reveal(${\mathsf{\Pi }}^{\mathit{s}}$): This query allows the adversary to obtain the session key established during a completed session $s$.
• Corrupt(${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$): This query reveals the long-term secret credentials of the device.
• Test(${\mathsf{\Pi }}^{\mathit{s}}$): This query evaluates the indistinguishability of the session key.

The challenger chooses a random bit: $b\in \left\{0,1\right\}$

If $b=1$, the challenger returns the real session key $Sk$.

If $b=0$, the challenger returns a random string $R$ of equal length $l$.

The adversary outputs a guess $b^{\prime }$. The advantage of adversary $\mathcal{A}$ in the RoR experiment is defined as:

$${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathcal{A}}^{ROR}=|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}|$$

(1)

5.2.2. Session Key Derivation

During mutual authentication, the session key is computed as:

$Sk=H({cert}_{EDi}{ \parallel ID}_{EDi}{ \parallel ID}_F \parallel x· y)$, where $x$ and $y$ are random nonces generated by ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ and ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$, and $H(\cdot )$ denotes a secure one-way hash function.

The nonces $x$ and $y$ are transmitted only within encrypted messages:

• ${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}=\mathrm{E}\mathrm{N}\mathrm{C}{\left[{\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}},{\mathrm{T}\mathrm{S}}_{\mathrm{i}},x\right]}_{{\mathrm{P}\mathrm{K}}_{\mathrm{F}}}$
• ${EM}_{F-ED}=ENC{[{ID}_F,{Auth}_{F-ED},{TS}_j,y]}_{{PK}_{ED}}$

Therefore, the secrecy of $x$ and $y$ relies on the Indistinguishability under Chosen Plaintext Attack (IND-CPA) security [29] of the ECIES encryption scheme.

5.2.3. Game-Based Security Proof

The security proof proceeds via a sequence of games:

• Game 0 (${\mathrm{G}}_0)$: Real Protocol Execution

${\mathrm{G}}_0$ corresponds to the real execution of the proposed authentication protocol. The adversary observes all exchanged messages and interacts through Execute, Send, Reveal, Corrupt, and Test queries. The adversary advantage in this game is:

$${\mathrm{A}\mathrm{d}\mathrm{v}}_0{=\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathcal{A}}^{\mathrm{R}\mathrm{O}\mathrm{R}}$$

(2)

• Game 1 (${\mathrm{G}}_1)$: Replay Attack Resistance

The protocol embeds timestamps ${\mathrm{T}\mathrm{S}}_{\mathrm{i}}$ and ${\mathrm{T}\mathrm{S}}_{\mathrm{j}}$. Since timestamps are validated within a freshness window, replayed messages are rejected with overwhelming probability. Hence:

$$\mid {\mathrm{A}\mathrm{d}\mathrm{v}}_1-{\mathrm{A}\mathrm{d}\mathrm{v}}_0\mid \le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{s}}}{2^{\mathrm{l}}}}$$

(3)

where ${\mathrm{q}}_{\mathrm{s}}$ denotes the number of Send queries, and $\mathrm{l}$ denotes the hash output length.

• Game 2 (${\mathrm{G}}_2)$: ECIES Encryption Attack

The adversary may attempt to extract $\mathrm{x}$ or $\mathrm{y}$ from ${\mathrm{E}\mathrm{M}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$ or ${\mathrm{E}\mathrm{M}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$. Success would require breaking IND-CPA security of ECIES. Hence:

$$\mid {\mathrm{A}\mathrm{d}\mathrm{v}}_2-{\mathrm{A}\mathrm{d}\mathrm{v}}_1\mid \le {\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{E}\mathrm{C}\mathrm{I}\mathrm{E}\mathrm{S}}$$

(4)

• Game 3 (${\mathrm{G}}_3)$: Blockchain Integrity Attack

The adversary may attempt to modify or read blockchain records (${\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{P}\mathrm{K}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{c}\mathrm{e}\mathrm{r}\mathrm{t}}_{\mathrm{E}\mathrm{D}\mathrm{i}}$); however, blockchain uses PBFT consensus, which requires control of at least (2N/3 + 1) nodes to alter records. Since the blockchain is managed exclusively by authorized FRAN nodes, and private blockchain data is not accessible to external entities, external adversaries cannot read or tamper with these records under the assumed security model. Hence:

$$\mid {\mathrm{A}\mathrm{d}\mathrm{v}}_3-{\mathrm{A}\mathrm{d}\mathrm{v}}_2\mid \le {\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{B}\mathrm{C}}$$

(5)

And ${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{B}\mathrm{C}}\approx 0$.

• Game 4 (${\mathrm{G}}_4)$:Hash Function Attack

Forging authentication values ${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}}$ or ${\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{F}-\mathrm{E}\mathrm{D}}$ without secret parameters requires breaking the hash function’s collision or preimage resistance. Hence:

$$\mid {\mathrm{A}\mathrm{d}\mathrm{v}}_4-{\mathrm{A}\mathrm{d}\mathrm{v}}_3\mid \le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}}^2}{2^{\mathrm{l}}}}$$

(6)

where ${\mathrm{q}}_{\mathrm{h}}$ denotes the number of Hash queries, and $\mathrm{l}$ denotes the hash output length.

• Game 5 (${\mathrm{G}}_5)$: ECDH Hardness

The security of the session key also relies on the hardness of the Elliptic Curve Diffie–Hellman (ECDH) problem. Given $\mathrm{x}· \mathrm{P}$ and $\mathrm{y}· \mathrm{P}$, computing $\mathrm{x}· \mathrm{y}· \mathrm{P}$ is computationally infeasible for a polynomial-time adversary. Hence:

$$\mid {\mathrm{A}\mathrm{d}\mathrm{v}}_5-{\mathrm{A}\mathrm{d}\mathrm{v}}_4\mid \le {\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{E}\mathrm{C}\mathrm{D}\mathrm{H}}$$

(7)

And ${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{E}\mathrm{C}\mathrm{D}\mathrm{H}}\approx 0$.

• Game 6 (${\mathrm{G}}_6)$: Final Game

In the final game, the challenger replaces the session key $\mathrm{S}\mathrm{K}$ with a uniform random value $\mathrm{R}$. Since this value is independent of the adversary’s view, the adversary cannot distinguish real from random, so:

$${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{f}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l}}=0$$

(8)

5.2.4. Overall Advantage

Combining Equations (3)–(7):

$${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathcal{A}}^{\mathrm{R}\mathrm{O}\mathrm{R}} \le {\displaystyle \frac{{\mathrm{q}}_{\mathrm{s}}}{2^{\mathrm{l}}}}+{\displaystyle \frac{{\mathrm{q}}_{\mathrm{h}}^2}{2^{\mathrm{l}}}}+{\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{E}\mathrm{C}\mathrm{I}\mathrm{E}\mathrm{S}}+{\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{E}\mathrm{C}\mathrm{D}\mathrm{H}}+{\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathrm{B}\mathrm{C}}$$

(9)

Since ECIES is IND-CPA secure, the hash behaves as a random oracle, ECDH is computationally hard, and PBFT ensures blockchain integrity, all terms are negligible. Therefore:

$${\mathrm{A}\mathrm{d}\mathrm{v}}_{\mathcal{A}}^{\mathrm{R}\mathrm{O}\mathrm{R}}\approx 0$$

Any adversary able to distinguish the session key could be used to break one of the underlying primitives, which is computationally infeasible. Hence, the proposed protocol achieves secure authenticated key exchange under the ROR model.

5.3. Formal Proof Under AVISPA Simulation

We evaluate the security of the proposed protocol using the Automated Validation of Internet Security Protocols and Applications (AVISPA) tool [30], a formal verification framework widely adopted to detect active threats such as replay and man-in-the-middle (MitM) attacks. The protocol is modeled using the High-Level Protocol Specification Language (HLPSL), which is subsequently translated into the Intermediate Format (IF) and analyzed through four back-ends: the On-the-Fly Model Checker (OFMC), the Constraint Logic-based Attack Searcher (CL-AtSe), the SAT-based Model Checker (SATMC), and the Tree Automata-based on Automatic Approximations for the Analysis of Security Protocols (TA4SP). Because the proposed scheme includes exclusive-OR operations, the OFMC and CL-AtSe back-ends are primarily employed.

The HLPSL-based specification, illustrated in Figure 5, defines key security objectives, including the confidentiality of the ${ED}_i$’s credential (sec_cert), the confidentiality of the session key (sec_sk), and the mutual authentication between ${ED}_i$ and ${FRAN}_j$ (ed_fran_auth, fran_ed_auth). To assess resistance against replay and MitM attacks, several scenarios were implemented within the environment role of the HLPSL specification. For replay attack evaluation, two identical sessions were configured between ${ED}_i$ and ${FRAN}_j$ (as shown in Table 4) to test whether an intruder could impersonate a legitimate party and reuse previously exchanged messages.

Figure 5. Objectives and security properties.

Table 4. Specifications.

	Scenario: Baseline Dolev–Yao	Scenario: Key Substitution	Scenario: Key Compromise
Intruder knowledge	{pke, pkf}	{pke, pkf, intr_pkf, intr_skf}	{pke, pkf, skf}
Instantiations	ed1: ed (e, f, pkf, pke, cert, s1snd, s1rcv)	ed1: ed (e, f, intr_pkf, pke, cert, s1snd, s1rcv)	ed1: ed (e, f, pkf, pke, cert, s1snd, s1rcv)
	fran1: fran (f, e, pkf, pke, cert, s1snd, s1rcv)	fran1: fran (f, e, pkf, pke, cert, s1snd, s1rcv)	fran1: fran (f, e, pkf, pke, cert, s1snd, s1rcv)
	ed2: ed (e, f, pkf, pke, cert, s2snd, s2rcv)	ed2: ed (e, f, intr_pkf, pke, cert, s2snd, s2rcv)	ed2: ed (e, f, pkf, pke, cert, s2snd, s2rcv)
	fran2: fran (f, e, pkf, pke, cert, s2snd, s2rcv)	fran2: fran (f, e, pkf, pke, cert, s2snd, s2rcv)	fran2: fran (f, e, pkf, pke, cert, s2snd, s2rcv)

For the MitM scenario, an additional configuration was introduced to examine the protocol’s ability to prevent an adversary from intercepting or altering communication between legitimate entities. Specifically, three attack cases were modeled and analyzed: (1) Key compromise, where the intruder possesses knowledge of ${FRAN}_j$’s secret key ($K_F$); (2) Key substitution, in which ${ED}_i$ mistakenly accepts the intruder’s public key (${PK}_{\mathrm{I}}$) as that of the legitimate ${FRAN}_j$ ($\mathrm{P}{\mathrm{K}}_{\mathrm{F}}$); and (3) the baseline Dolev–Yao scenario, representing a powerful adversary capable of intercepting, modifying, and injecting messages at will.

The simulation results, summarized in Figure 6, indicate that our proposed protocol achieves all specified security goals. The AVISPA output reports a “SAFE” status under both OFMC and CL-AtSe back-ends, confirming that the protocol is robust against replay and man-in-the-middle attacks, while guaranteeing mutual authentication, as well as the confidentiality of both the session key and the end device’s credential.

Figure 6. AVISPA simulation results.

6. Performance Analysis

To assess the performance of the proposed scheme, the computational cost estimation is derived from the experimental results reported in [22]. In this study, the authors evaluated cryptographic operations on a server equipped with Ubuntu 18.04.4 LTS, 7.7 GiB of memory, an Intel Core™ i7-8565U CPU (1.80 GHz × 8), a 64-bit operating system, and a 966.1 GB disk, where each cryptographic operation was executed 100 times and the average runtime (in milliseconds) was recorded, as summarized in Table 5. For IoT devices, the experiments were conducted using a Raspberry Pi 3 Model B Rev 1.3 with a 64-bit CPU, 1.4 GHz quad-core processor, 1 GB RAM, and Ubuntu 20.04 LTS (64-bit); similarly, 70 experimental runs were performed for each cryptographic primitive, and the corresponding average execution times were documented, with the results also presented in Table 5.

Table 5. The execution time of cryptographic primitives using MIRACL [22].

Notation	Meaning	Average Time on AP (ms)	Average Time on ${\mathit{E}\mathit{D}}_{\mathit{i}}$ (ms)
TH	one-way hash function using the SHA-256 algorithm	0.058	0.311
TECA	elliptic curve point addition	0.0017	0.015
TECM	elliptic curve point multiplication	0.677	2.292
TENC/DEC	AES-128 encryption/decryption	0.0013	0.017

We compared the performance of the proposed protocol with existing authentication schemes leveraging Zero-Trust principles, smart contracts, blockchain frameworks, and lightweight cryptographic mechanisms. Despite their contributions, these prior works exhibit notable limitations in terms of scalability and overall performance efficiency, including computational, energy, and bandwidth costs. The benchmarked protocols originate from diverse 6G application domains, such as general IoT, UAV networks, Internet of Vehicles (IoV), healthcare, and industrial systems, implemented either with or without fog or edge computing architectures.

6.1. Computation Cost and Execution Time

To evaluate computational efficiency, the proposed scheme is compared with contemporary protocols based on the cumulative execution time of all cryptographic and mathematic operations required during authentication. Based on the results presented in Table 5, the comparative computational costs of the proposed and existing authentication schemes are summarized in Table 6.

Table 6. Computational cost comparison.

Protocol	${\mathit{E}\mathit{D}}_{\mathit{i}}$	AP
Singh & Das (2025) [22]	6 Th + 4 Tecm +2 Teca	7 Th + 4 Tecm + 3 Teca
Soni et al. (2024) [31]	6 Th + 3 Tecm	18 Th + 16 Tecm + 4 Teca
Saqib et al. (2022) [16]	3 Tecm + 1 Th + 2 Teca	7 Tecm + 6 Th + 2 Teca
Son et al. (2024) [23]	4 Tecm + 4 Th	4 Tecm + 3 Th
Ma et al. (2024) [32]	4 Tecm + 7 Th + 2 Tenc/dec	4 Tecm + 7 Th + 2 Tenc/dec
Proposed	4 Th + 2 Tenc/dec + 2 Tecm	2 Tenc/dec + 3 Th + 2 Tecm

Table 6 and Figure 7 clearly demonstrate that the proposed protocol achieves the lowest computation cost among all evaluated schemes, with a total of 7.39 ms, representing over 57% reduction compared to the baseline at 20.62 ms. This performance gain, enabled by the dual-blockchain architecture and ECC integration, translates into superior scalability and efficiency for large-scale 6G-enabled IoT environments, while maintaining robust security.

Figure 7. Computation costs comparison with existing schemes [16,22,23,31,32].

6.2. Communication Cost

The proposed authentication framework reduces computational and communication overhead while maintaining strong security. It employs ECC, which provides high security with smaller key sizes, making it suitable for resource-constrained IoT devices. The authentication process requires only a two-message exchange between the device and the fog node, minimizing latency and signaling overhead. In addition, the dual-blockchain architecture separates identity management (mainchain) from authentication operations (sidechain), improving scalability and reducing processing load. Finally, the use of lightweight authentication credentials instead of full X.509 certificates decrease storage and transmission costs, enabling efficient and scalable authentication for large-scale 6G-enabled IoT environments.

To assess communication overhead, we compare the proposed scheme with existing protocols by analyzing the total size of messages exchanged during the authentication process.

To evaluate the communication overhead of the proposed protocol, Table 7 summarizes the bit lengths of the main parameters involved in the authentication process. As described in Section 4, the proposed scheme employs ECC with 160-bit keys, providing a security level comparable to 1024-bit RSA while significantly reducing computational and communication costs. Device and fog node identities are represented using 128-bit identifiers, while timestamps are encoded using 32 bits to ensure the freshness of authentication messages. Random numbers $x$ and $y$ are generated with a 256-bit length to guarantee sufficient entropy against replay and prediction attacks.

Table 7. Parameters lengths.

Parameters	${\mathbf{I}\mathbf{D}}_{\mathbf{E}\mathbf{D}\mathbf{i}},{\mathbf{I}\mathbf{D}}_{\mathbf{F}}$	$\mathbf{P}\mathbf{K},\mathbf{S}\mathbf{K}$	${\mathit{S}}_{\mathit{E}\mathit{D}\mathit{i}}$	$\mathbf{T}\mathbf{S}$	$\mathit{x},\mathit{y}$
Length (bits)	128	160	64	32	160

During the authentication phase, two encrypted messages are between ${\mathrm{E}\mathrm{D}}_{\mathrm{i}}$ and ${\mathrm{F}\mathrm{R}\mathrm{A}\mathrm{N}}_{\mathrm{j}}$, $\mathrm{M}1=\mathrm{E}\mathrm{N}\mathrm{C}{[{\mathrm{I}\mathrm{D}}_{\mathrm{E}\mathrm{D}\mathrm{i}},{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{E}\mathrm{D}-\mathrm{F}},{\mathrm{T}\mathrm{S}}_{\mathrm{i}},\mathrm{x}]}_{{\mathrm{P}\mathrm{K}}_{\mathrm{F}}}$, and $M2= \mathrm{E}\mathrm{N}\mathrm{C}{[{\mathrm{I}\mathrm{D}}_{\mathrm{F}},{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}}_{\mathrm{F}-\mathrm{E}\mathrm{D}},{\mathrm{T}\mathrm{S}}_{\mathrm{j}},y]}_{{\mathrm{P}\mathrm{K}}_{\mathrm{E}\mathrm{D}}}$. Based on the parameter sizes defined above, each message has a size of approximately 640 bits, resulting in a total communication cost of 1280 bits for mutual authentication.

Table 8 provides a comparative summary of the communication costs for all schemes, reporting both the number of exchanged messages and the cumulative number of bits required throughout the authentication phase.

Table 8. Communication costs.

Protocol	Messages	Bandwidth (Bits)
Soni et al. (2024) [31]	4	3168
Saqib et al. (2022) [16]	5	2560
Son et al. (2024) [23]	2	1920
Singh & Das (2025) [22]	2	1600
Proposed	2	1280

As depicted in Figure 8, the proposed scheme achieves the lowest communication overhead among all benchmark protocols.

Figure 8. Comparison of communication overhead with existing schemes [16,22,23,31].

The bar chart illustrates that only 1280 bits are required per authentication session, marking a bandwidth reduction of nearly 60% compared to [31] and substantial gains over all other recent methods. The line plots further emphasize that our protocol maintains the lowest slope for bandwidth increase as the number of authentications grows, consistently minimizing total communication cost even under scaling workloads. This efficiency, requiring only 2 messages per session, underscores the practicality of our scheme for deployment in bandwidth-constrained and large-scale IoT environments.

6.3. Energy Consumption

In this section, we evaluate the energy consumption of the proposed scheme in comparison with contemporary protocols, emphasizing its effect on the overall energy usage of IoT devices.

As noted in sources [33], the total energy consumption of the proposed authentication scheme is estimated as:

• $E_{Total}=E_{Communication}+E_{Computation}$

Where $E_{Communication}$ accounts for transmission and reception energy, and $E_{Computation}$ represents the energy consumed during cryptographic and logical operations. The communication energy is defined by:

• $E_{Communication}=n_s\ast E_s+n_r\ast E_r$

Where $n_s$ and $n_r$ denote the number of bytes sent and received, respectively.

The energy consumed to transmit or receive a single byte is computed using the standard electrical model [34,35],$E=V\ast I\ast t$ where V is the supply voltage, $\mathit{I}$ is the operating current for either transmission or reception, and t is the time to process a byte. Following the widely adopted MICAz testbed configuration for low-power IoT and WSN devices [33], the calculations are based on V = 3 V, a transmission current $I_s=17.4 \mathrm{m}\mathrm{A}$, a reception current $I_r=19.7 \mathrm{m}\mathrm{A}$, and a transmission rate R = 250 kbps. This yields per-byte transmission and reception energy values of approximately $E_s= 1.6704\times {(10}^{-6}) \mathrm{J}$, and $E_r= 1.8912\times {(10}^{-6}) \mathrm{J}$, respectively.

Computation energy, $E_{Computation}$, is evaluated as the sum of the energy required by each cryptographic primitive involved, using the same electrical model. Specifically, $E_{Computation}= {\displaystyle {\sum }_{i=1}^N}V\ast I_i\ast t_i$, where for each operation, $t_i$ represents the measured execution time, obtained from the previous section, and $I_i$ the processor’s active current, which is typically 8 mA for the MICAz CPU. Applying this framework, the energy costs for the principal cryptographic operations in the proposed protocol are:

$$E_h=7.464\times {(10}^{-6}) \mathrm{J},E_{ecm}=55.008\times {(10}^{-6}) \mathrm{J},E_{eca}=0.36\times {(10}^{-6}) \mathrm{J},E_{enc}=0.408\times {(10}^{-6}) \mathrm{J}$$

These values are combined proportionally according to the specific sequence of operations for each evaluated protocol, as defined in Table 9.

Table 9. Energy consumption.

Protocol	${\mathit{E}}_{\mathit{C}\mathit{o}\mathit{m}\mathit{p}\mathit{u}\mathit{t}\mathit{a}\mathit{t}\mathit{i}\mathit{o}\mathit{n}}$	${\mathit{E}}_{\mathit{C}\mathit{o}\mathit{m}\mathit{m}\mathit{u}\mathit{n}\mathit{i}\mathit{c}\mathit{a}\mathit{t}\mathit{i}\mathit{o}\mathit{n}}$	${\mathbf{E}}_{\mathbf{T}\mathbf{o}\mathbf{t}\mathbf{a}\mathbf{l}}$
Singh & Das (2025) [22]	$6\ast E_h+4\ast E_{ecm}+2\ast E_{eca}$	$832\ast E_s+768\ast E_r$	620.8128 $\times {(10}^{-6}) \mathrm{J}$
Saqib et al. (2022) [16]	$E_h+3\ast E_{ecm}+2\ast E_{eca}$	$640\ast E_s+800\ast E_r$	495.96 $\times {(10}^{-6}) \mathrm{J}$
Son et al. (2024) [23]	$4\ast E_h+4\ast E_{ecm}$	$640\ast E_s+480\ast E_r$	496.992 $\times {(10}^{-6}) \mathrm{J}$
Proposed	$4\ast E_h+2\ast E_{ecm}+2\ast E_{enc}$	$640\ast E_s+640\ast E_r$	425.616 $\times {(10}^{-6}) \mathrm{J}$

A visual comparison of energy consumption for 100 devices is presented in Figure 9, which highlights the superior efficiency of the proposed scheme relative to recent benchmark protocols. As shown by the curve, the proposed mechanism achieves a total energy use of 42,561.6 × 10⁻⁶ J, representing reductions of 31.4% compared to [22], 14.2% versus [16], and 14.4% against [23]. These improvements stem from the integration of a dual-blockchain architecture, lightweight ECC cryptography, and an optimized smart contract-driven message flow, confirming the proposed protocol’s suitability for energy-constrained IoT systems in advanced 6G scenarios.

Figure 9. Energy Consumption of 100 devices comparison with existing schemes [16,22,23].

7. Smart Contract Implementation and Gas Profiling

The smart contracts of the proposed scheme in Figure 10 were implemented in Solidity [36] using the Remix Integrated Development Environment (IDE) [37]. The contracts were executed using the Remix Virtual Machine (Remix VM), a local Ethereum VM-based execution environment provided by Remix, to enable controlled and reproducible functional testing and gas-consumption measurement without the cost and variability of public on-chain deployment. This experimental setup does not benchmark blockchain consensus behavior or network-induced transaction latency. Although the proposed architecture is designed around a PBFT-based consensus, the experiments reported here do not involve a native PBFT implementation.

Figure 10. Smart Contracts of the Proposed Scheme.

The simulation results obtained in Remix show that the addDev() function consumes around 51,617 gas units, the getInfo() function requires 4406 gas units, and the authDev() function consumes 68,939 gas units. These empirical measurements serve as the foundation for analyzing the scalability and performance of the proposed blockchain-based authentication framework (Figure 11).

Figure 11. Transaction cost of different functions.

To model the cumulative gas consumption, consider a network consisting of N devices, where each device performs a one-time registration operation (addDev()) on the mainchain and executes $M_i$ authentication sessions. Each session involves one getInfo() call on the mainchain and one authDev() call on the sidechain. Accordingly, the total gas consumption can be expressed as:

• ${\mathrm{G}}_{\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n}}=\mathrm{N} \times {\mathrm{G}}_{\mathrm{A}\mathrm{d}\mathrm{d}\mathrm{D}\mathrm{e}\mathrm{v}}+{\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{N}}}{\mathrm{M}}_{\mathrm{i}} \times {\mathrm{G}}_{\mathrm{G}\mathrm{e}\mathrm{t}\mathrm{I}\mathrm{n}\mathrm{f}\mathrm{o}}$
• ${\mathrm{G}}_{\mathrm{s}\mathrm{i}\mathrm{d}\mathrm{e}}={\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{N}}}{\mathrm{M}}_{\mathrm{i}} \times {\mathrm{G}}_{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}\mathrm{D}\mathrm{e}\mathrm{v}}$
• ${\mathrm{G}}_{\mathrm{t}\mathrm{o}\mathrm{t}\mathrm{a}\mathrm{l}}={\mathrm{G}}_{\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n}}+{\mathrm{G}}_{\mathrm{s}\mathrm{i}\mathrm{d}\mathrm{e}}=\mathrm{N} \times {\mathrm{G}}_{\mathrm{A}\mathrm{d}\mathrm{d}\mathrm{D}\mathrm{e}\mathrm{v}}+{\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{N}}}{\mathrm{M}}_{\mathrm{i}} \times ({\mathrm{G}}_{\mathrm{G}\mathrm{e}\mathrm{t}\mathrm{I}\mathrm{n}\mathrm{f}\mathrm{o}}+{\mathrm{G}}_{\mathrm{A}\mathrm{u}\mathrm{t}\mathrm{h}\mathrm{D}\mathrm{e}\mathrm{v}})$

Using the measured gas values from the Remix simulation, the total gas cost was estimated for varying network sizes N and authentication frequencies $M_i$. This analysis provides a quantitative assessment of the blockchain overhead introduced by the proposed authentication protocol, demonstrating its scalability and cost-efficiency in resource-constrained environments.

In this evaluation, $M_i=5$ was fixed while N varied to analyze scalability behavior. The resulting curves in Figure 12 show a linear increase in gas consumption with respect to N, confirming that the computational and storage costs of the proposed blockchain framework scale predictably with network size. The MainchainGas curve exhibits the steepest slope, indicating that the one-time registration operation addDev() on the mainchain consumes the largest portion of gas. In contrast, the SidechainGas curve grows more gradually, as authDev() operations executed on the sidechain are less expensive and optimized for repeated interactions. The TotalGas curve, representing the aggregate cost, follows a balanced linear trend, remaining well below what would be expected if all operations were executed on a single blockchain.

Figure 12. Gas consumption versus number of devices (M = 5).

This behavior validates the design rationale of adopting a dual-blockchain architecture, where the mainchain is reserved for critical identity anchoring and infrequent state commitments, while the sidechain manages high-frequency authentication exchanges. If the same operations were executed solely on the mainchain, the gas cost would scale much faster, leading to higher transaction fees and lower throughput. By offloading repetitive authentication tasks to the sidechain, the system achieves significant reductions in overall gas expenditure and enhances scalability. Therefore, the linear yet moderate slope of the TotalGas curve empirically demonstrates that the proposed dual-chain design provides a more efficient and cost-effective solution for large-scale authentication scenarios compared to a single-chain deployment.

8. Conclusions and Future Work

The integration of UAVs, IRSs, IoT devices, and fog nodes into heterogeneous 6G networks raises security and reliability challenges due to mobility, distributed trust, and resource constraints.

This paper proposes a dual-blockchain Fog-RAN Access Authentication scheme based on a mainchain–sidechain structure, smart contracts, and ECC to provide secure and auditable access control. The proposed scheme is formally verified using the ROR model and AVISPA, and further evaluated through smart-contract simulations, where it demonstrates lower computational cost, reduced communication overhead, and improved energy efficiency compared with existing approaches.

In future work, we plan to further extend the proposed authentication framework through large-scale experimental evaluation in realistic 6G-enabled IoT environments. In particular, we intend to investigate the scalability of the dual-blockchain architecture under high device density and to quantify its impact on authentication latency, blockchain transaction throughput, communication overhead, energy consumption, and gas consumption. We also plan to conduct experiments involving a large number of IoT devices, fog nodes, UAV-assisted components, and heterogeneous 6G entities to assess authentication response time and overall system efficiency under dynamic network conditions. In addition, the framework will also be extended to support secure device-to-device (D2D) authentication under mobility, which is particularly important for highly dynamic 6G-enabled environments. These quantitative evaluations and functional extensions will provide deeper insight into the practical deployment, scalability, and adaptability of the proposed framework in future 6G networks.