Blockchain-Based Batch Authentication and Symmetric Group Key Agreement in MEC Environments

Abstract

To address the high computational and communication overheads and the limited edge security found in many existing batch verification methods for Mobile Edge Computing (MEC), this paper presents a blockchain-based batch authentication and symmetric group key agreement protocol. A core feature of this protocol is the establishment of a shared symmetric key among all authenticated participants. This symmetry in key distribution is fundamental for enabling secure and efficient broadcast or multicast communication within the MEC group. The protocol introduces a chameleon hash function built on elliptic curves, allowing smart mobile devices (SMDs) to generate lightweight signatures. The edge server (ES) then performs efficient large-scale batch authentication using an aggregate signature technique. Considering the need for secure and independent communication between SMDs and ES, the protocol further establishes a one-to-one session key agreement mechanism and uses a Merkle tree to verify session key correctness. Formal verification with ProVerif2.05 tool confirms the protocol’s security and multiple protection properties. Experimental results show that, compared with the CPPBA, ECCAS, and LBVP schemes, the protocol improves computational efficiency of batch authentication by 0.94%, 67.20%, and 49.53%, respectively. For group key agreement, the protocol achieves a 35.26% improvement in computational efficiency over existing schemes.

1. Introduction

1.1. Background and Motivation

With the dramatic increase in the amount of data, Mobile Edge Computing (MEC) has emerged as a key technology for processing large-scale data by offloading computational tasks to the network edge, thereby significantly reducing data transmission latency [1]. However, the openness and decentralization of MEC introduce new challenges. The inherent asymmetry in computational power between resource-constrained mobile devices and powerful edge servers creates security vulnerabilities, particularly in scenarios involving large-scale concurrent device authentication [2]. Moreover, the issue of semi-trusted edge servers in MEC architectures has attracted increasing attention, as their partially trustworthy nature may lead to data leakage and malicious attacks, thereby posing threats to the overall system security [3]. To mitigate these challenges, blockchain technology [4], with its inherent characteristics of decentralization, immutability, and traceability, has shown strong potential in enhancing data security. Its distributed ledger helps ensure transparency and consistency in data processing, effectively reducing the risk of data tampering [5]. By introducing functions such as smart contracts, blockchain further enhances the security of automated transactions, making it an effective tool for preventing data leakage and ensuring transaction integrity [6].

This hybrid security architecture, which combines decentralized trust based on blockchain with efficient edge processing, has been actively explored in modern industrial scenarios, such as the Industrial Internet of Things. For instance, addressing the uncertainty of attack characteristics in Internet of Things (IoT) networks, Ref. [7] proposed an intelligent framework that combines fuzzy logic with blockchain and improves the reliability of detecting complex threats. In cloud-fog-edge collaborative environments, Ref. [8] designed a collaborative intrusion detection framework based on Deep Blockchain, achieving accurate identification of distributed attacks while preserving data privacy. In addition, facing the increasingly frequent Denial-of-Service attacks, Ref. [9] constructed a blockchain-based distributed defense system, utilizing smart contracts to achieve automated mitigation of Distributed Denial of Service (DDoS) attacks. These examples collectively demonstrate that the integration of blockchain and MEC architectures is important for enhancing data security, improving system transparency, and promoting decentralized management [10]. However, these efforts mainly focus on post-threat detection and defense mechanisms. As the first line of defense for system security, “access authentication” for massive terminals faces significant challenges in both efficiency and trust; yet decentralized architecture designs targeting this specific phase remain relatively underdeveloped. Therefore, designing an efficient authentication protocol that balances blockchain-based trust with the low-latency characteristics of the edge is a necessary component to complete the overall security framework.

Meanwhile, another critical challenge in MEC environments lies in how to efficiently and securely authenticate a large number of terminal devices [11]. With the rapid increase in connected devices and the growing complexity of application scenarios [12], traditional single-device authentication mechanisms can no longer meet the requirements for low latency and high reliability. Therefore, batch identity authentication has become a key technical solution [13]. It enables simultaneous verification of multiple devices, reducing server-side computation and network latency, and improving overall system performance and security. Researchers have conducted in-depth studies on this approach in different application scenarios. For example, Ref. [14] addressed the conflict between large-scale data authentication and limited terminal resources in Industrial Internet of Things (IIoT) by designing a lightweight signature algorithm based on a hash chain. In addition, the chameleon hash function [15] has been widely used in batch authentication scenarios due to its collision controllability, which provides enhanced security and efficiency [16]. By integrating aggregate signature (AS) structures, the chameleon hash function can flexibly adapt to dynamic authentication demands and substantially improve the authentication efficiency of large-scale device requests [17], thereby serving as an important approach to enhance both the security and performance of MEC batch authentication systems. Recent studies, such as Ref. [18] and Ref. [19], further validated the advantages of this technology by integrating it with editable blockchains and Physical Unclonable Functions (PUFs), respectively, to balance security and efficiency.

1.2. Related Work

Batch verification and symmetric group key agreement are two critical procedures for ensuring the security of multi-party communications [20]. In recent years, scholars worldwide have proposed various innovative schemes aimed at improving authentication efficiency, optimizing the use of chameleon hash function applications, enhancing privacy protection, and integrating blockchain architectures.

To address the computational bottlenecks of resource-constrained devices, a mainstream line of work focuses on the lightweight design of cryptographic protocols. Ref. [21] and Ref. [22], respectively, incorporated the Chinese Remainder Theorem and chaotic mapping into the design of efficient intra-group authentication and key agreement protocols. To mitigate high concurrency latency, Ref. [23] employed a distributed collaborative authentication approach to more effectively distribute verification tasks, thereby significantly reducing message-verification delays. To improve efficiency in decentralized key generation, Ref. [24] proposed adaptively secure BLS threshold signature schemes, optimizing both the security and efficiency of key generation. Furthermore, to reduce the high computational overhead caused by bilinear pairing operations, Ref. [25] proposed a pairing-free certificateless aggregate signcryption scheme, which significantly improves communication efficiency in Internet of Medical Things environments. Similar lightweight dynamic key-management schemes have also been applied to unmanned aerial vehicle (UAV) swarms and space information networks [26,27].

The chameleon hash function plays a vital role in constructing redactable and efficient authentication protocols due to its trapdoor property. Beyond traditional applications, the optimization of this technology within blockchain environments is gaining increasing attention. Ref. [18] combined chameleon hashing with aggregate signatures to construct an efficient data transmission protocol. In recent research, Ref. [28] proposed a redactable consortium blockchain scheme based on chameleon hashing and multi-authority attribute-based encryption. This approach further unleashes the potential of chameleon hashing in data correction and privacy management through fine-grained access control, providing new insights for addressing trusted data modification in MEC.

In semi-trusted MEC environments, protecting user identity privacy is a core requirement for authentication protocols. Ref. [29] introduced identity-based anonymous authentication techniques, while Refs. [30,31] utilized zero-knowledge proofs to enhance privacy and post-quantum resistance. Addressing trust and efficiency issues in Internet of Vehicles communications, Ref. [32] designed a blockchain-based lightweight certificateless authenticated key agreement protocol, effectively reducing certificate management overhead while ensuring communication privacy. Additionally, Refs. [33,34] achieved conditional privacy-preserving batch authentication through elliptic-curve cryptography (ECC).

To resolve the single point of failure and lack of trust in centralized architectures, integrating blockchain into authentication protocols has become a research hotspot. For instance, Ref. [35] leveraged blockchain to implement decentralized dynamic node key management, where shared keys were constructed through polynomial operations to resist node mobility. Ref. [36] designed a blockchain-based fast handover authentication scheme for mobile environments, introducing a token mechanism to reduce authentication overhead. Ref. [37] combined blockchain with ECC to propose a lightweight yet resilient batch-verification mechanism, thereby optimizing certificate management. To visually demonstrate the characteristics of existing studies and the motivation for the proposed scheme,

Table A1. Feature Comparison of Authentication and Key Agreement Schemes.

Scheme (Ref.)	Core Technique	Batch Auth	GKA	Decentralized Trust	Anti-Internal Attack	Main Limitations
Refs. [21,22]	CRT/Chaotic Map	√	√	×	×	Relies on centralized trust models; Vulnerable to internal attacks from semi-trusted servers.
Ref. [23]	Distributed Collab.	√	×	×	×	Coordination between nodes adds communication overhead; Lacks blockchain auditing.
Ref. [24]	BLS Threshold Sig	×	×	√	×	Focuses on optimizing threshold signature security; Not specifically optimized for massive batch access in MEC.
Ref. [25]	Pairing-free Signcryption	×	√	×	×	Efficient but lacks a blockchain trust anchor; Does not support batch verification.
Ref. [28]	Chameleon Hash + ABE	×	×	√	√	Focuses on redactable storage and fine-grained access control; Not designed for concurrent authentication.
Ref. [32]	Blockchain + CL-AKA	√	√	√	×	Achieves lightweight privacy protection for V2V, but lacks aggregation optimization for ultra-scale batch verification.
Ref. [37]	Blockchain + ECC	√	×	√	×	Achieves decentralized authentication but lacks a subsequent group key agreement mechanism.
Proposed	Chameleon Hash + Merkle Tree	√	√	√	√	(Advantage) Unifies authentication and negotiation; Effectively resists internal attacks via Merkle Tree.

in Appendix A provides a detailed comparative analysis of the key related works mentioned above.

In summary, although existing studies have made notable progress in specific areas, challenges remain. In MEC environments, how to simultaneously achieve low computational costs, privacy protection under semi-trusted servers, and efficient group key agreement remains an open issue.

1.3. Contributions

To address the limitations of existing studies, this paper proposes a blockchain-based batch authentication and group key agreement protocol. The following innovations in architectural design and security logic have been achieved:

(1)

A unified “Authentication–Negotiation” security architecture is proposed. To overcome the limitations of traditional schemes that isolate authentication from negotiation, a tightly coupled protocol framework is designed. By reusing the parameters from the chameleon-hash authentication phase for the subsequent group key agreement, the protocol achieves joint optimization of communication and computation, reducing overall system overhead.

(2)

A lightweight chameleon-hash primitive tailored for MEC is constructed. A specific chameleon hash function based on elliptic curves is developed. By leveraging its trapdoor collision property for efficient signature aggregation, the computational complexity of batch verification is reduced from linear to near-constant time, thereby addressing efficiency bottlenecks in high-concurrency scenarios.

(3)

A Merkle Tree-based mechanism against internal attacks is designed. Merkle Trees are applied to session key verification in an innovative way. This mechanism enables terminals to independently validate the correctness of keys, thus providing a theoretical guarantee against internal tampering attacks by semi-trusted ES and filling a security gap in existing schemes.

1.4. Organization

The structure of this paper is as follows. Section 2 presents the system model of the proposed scheme and describes the batch authentication protocol in MEC environments. Section 3 presents a rigorous security analysis of the proposed scheme, including both informal reasoning and formal verifications of the authentication and group key agreement phase using ProVerif2.05 and Burrows-Abadi-Needham (BAN) Logic, respectively. Section 4 discusses the experimental results and performance evaluation. Finally, Section 5 concludes the paper.

2. System Model and Protocol

2.1. Blockchain Technology Overview

Blockchain is a decentralized and tamper-resistant distributed ledger maintained by multiple nodes without relying on a central authority, and it provides transparency and traceability. Figure 1 illustrates the structure of the blockchain. Each block contains transaction records, timestamps, and the hash of the previous block, forming an immutable chain structure secured by cryptographic mechanisms. Consensus algorithms, such as Proof of Work and Proof of Stake, ensure that distributed nodes agree on the correctness of newly added blocks. Smart contracts further enable automatic execution of predefined rules, enhancing the trustworthiness and automation of the system. These properties make blockchain suitable for secure authentication and key management in MEC environments, helping reduce data-tampering risks and improving the reliability of the authentication process.

2.2. System Model

The network model for batch authentication is illustrated in Figure 2, consisting of four main entities: Registration Authority (RA), ES, SMD, and Blockchain(BC). Their respective roles are described as follows:

(1)

RA: The RA is a fully trusted entity deployed on the cloud server and trusted by all participants. Its primary responsibilities include registering and updating both SMDs and ESs, as well as maintaining the integrity of the data stored on the blockchain.

(2)

ES: The ES is a semi-trusted entity equipped with moderate storage and computational capabilities. The permissioned blockchain is located at the edge layer. The ES follows an honest-but-curious model, meaning that it correctly executes the key agreement protocol but may attempt to infer or leak user privacy information.

(3)

SMD: The SMD represents the user entities in the MEC system, such as UAVs, smartphones, and smartwatches. An SMD may connect to multiple ESs, but it typically selects the nearest one for authentication.

(4)

BC: The BC operates as a permissioned blockchain, which stores device identity information and key materials. Smart contracts are employed to manage key materials—recording, updating, and revoking them as necessary—thereby serving as a trusted and secure container for key management operations.

Based on the framework depicted in Figure 2, a blockchain-driven protocol combining batch authentication and group key agreement via a chameleon hash function is proposed to enhance reliability and meet the security requirements of MEC environments. The proposed protocol consists of seven phases: system initialization, registration of ES and SMD, data uploading to the blockchain, distributed key generation, batch authentication, group key agreement, and session key agreement. The protocol process is illustrated in Figure 3.

2.3. Batch Authentication Protocol in MEC

The purpose of the protocol is to negotiate an independent session key between the ES and each SMD, as well as a shared group key among SMDs, so as to achieve mutual secure communication between the ES and SMDs, and among the SMDs themselves. It is assumed that SMD_i and the ES are mutually aware of each other’s public keys, PK_i and PK_j, respectively. The key parameters involved in the protocol and their corresponding meanings are listed in

Table 1. Key parameters and their meanings.

Parameter	Meaning
q	Large prime number
s	System private key
PK	System public key
IDi	Identity of the i-th SMD
IDj	Identity of the j-th ES
(xi, PKi)	Private/public key pair of the i-th SMD
(xj, PKj)	Private/public key pair of the j-th ES
HIDi	Signature data of the i-th SMD
mi, ri, mi′	chameleon hash function challenge random value
TSMDi, TESi	Timestamp
GSK	Group session key
SK	Session key shared between SMD and ES
hi(i = 1, 2)	Hash function
⊕	XOR encryption operation
||	Concatenation operator

.

2.3.1. System Initialization Phase

The RA selects an additive cyclic group G of prime order q with generator P over an elliptic curve E(Fp) defined on a finite field Fp. It then chooses two secure one-way hash functions:$h_1:\{0,1{\}}^{*}\to Z_q^{*}$, $h_2:\{0,1{\}}^{*}\to \{0,1{\}}^l$, where l denotes the bit length. A chameleon hash function is defined as ${\mathcal{F}}_C:M\times Z_q^{*}\to Z_q^{*}$,where M represents the message space. The RA generates a random secret ${s\in Z}_q^{*}$ as the master private key and derives the corresponding master public key $PK=s·P$. The finalized system parameters are then released as: params = {G, P, q, PK, h₁, h₂, ${\mathcal{F}}_C$}.

2.3.2. Registration Phase of ES and SMD

This phase is executed over a secure channel. Each SMD or ES submits its identity identifier, ${ID}_i$ or ${ID}_j$, to the RA for registration. The registration process, taking the SMD with identity ${ID}_i$ as an example, is described as follows:

(1)

$RA\to SMD:M1=(x_i,{TP}_i,k)$

-

Upon receiving ${ID}_i$, the RA selects a random number ${tp}_i,{x_i\in Z}_q^{*}$ and computes ${{PK}_i=x}_i·P$, ${{TP}_i=tp}_i·P$, and ${HID}_i=h_2\left({ID}_i\left|\left|{PK}_i\right|\right|x_i\right)$;

-

The RA then computes ${PID}_i=h_2\left({PK}_i\right)$, and ${CP}_i={{ID}_i⨁h}_2\left({HID}_i\left|\left|{PID}_i\right|\right|s\right)$. Then the RA securely stores $({CP}_i,{PID}_i,{HID}_i)$;

-

The RA calculates $k={tp}_i{+s·HID}_i$, and sends the message $M1=(x_i,{TP}_i,k)$ to the SMD.

(2)

$SMD:\left(x_i\right|\left|{PK}_i\right|\left|{ID}_i\right)$

-

Upon receiving M1, the SMD computes ${PK}_i=x_i·P$, ${HID}_i^{\prime }=h_2\left({ID}_i\left|\left|{PK}_i\right|\right|x_i\right)$, then verifies whether $k·P{TP}_i+{HID}_i^{\prime }·PK$. If the verification succeeds, the SMD securely stores $\left(x_i\right|\left|{PK}_i\right|\left|{ID}_i\right)$.

2.3.3. Data On-Chain Phase

The purpose of this phase is to store key information on the blockchain, thereby enhancing the trustworthiness of the edge server. After registration, the RA sends a transaction containing $\left({HID}_i\right|\left|{PK}_i\right|\left|C_i\right)$ to invoke a smart contract, which records the information on the blockchain. The smart contract supports the operations of adding, modifying, and deleting SMD information. If the public information of the SMD, namely the data $\left({HID}_i\right|\left|{PK}_i\right|\left|{CP}_i\right)$, is successfully uploaded to the blockchain, the corresponding SMD will be recognized as a legitimate terminal within the MEC system.

Following this phase, the edge server can readily access the verification key material of the corresponding SMD, while the SMD’s real identity cannot be derived from the blockchain.

2.3.4. Distributed Key Generation Phase

Figure 4 illustrates the chameleon hash-based authentication model of the protocol. The signature phase is initially triggered by the SMD requesting authentication and is completed after two rounds of interaction between the SMD and the ES. This phase is conducted over an open public channel. The detailed procedure is described as follows.

(1)

${SMD}_i\to ES:Q_{i1}=({HID}_i^{\prime },{EID}_i,{TSMD}_i)$

-

The SMD computes ${HID}_i^{\prime }=h_2\left({ID}_i\left|\left|{PK}_i\right|\right|x_i\right)$, then obtains the current timestamp ${TSMD}_i$ and calculates ${EID}_i=h_2\left({HID}_i^{\prime }\right|\left|{TSMD}_i\right)$;

-

Next, the SMD sends $Q_{i1}=({HID}_i^{\prime },{EID}_i,{TSMD}_i)$ to the ES.

(2)

$ES\to {SMD}_i:Q_{i2}=({\sigma }_i,A_i,d_{i1},{kID}_i,{TES}_i)$

-

The ES first verifies the timeliness of the message by checking whether the relation $|T-{TSMD}_i|\le ∆T$ holds, where $∆T$ is the preset time threshold and T is the current timestamp of the ES. All subsequent time verifications are performed in the same manner. The ES then uses ${HID}_i^{\prime }$ to query the blockchain and retrieve the corresponding data tuple (${HID}_i$, ${PK}_i$), after which it computes and verifies ${EID}_i{EID}_i^{\prime }=h2\left({HID}_i\right|\left|{TSMD}_i\right)$. If the verification fails, the ES discards the message and rejects the request. Otherwise, the ES selects four random numbers ${{a_i,m}_i,r_i,m_i^{\prime }\in Z}_q^{*}$, records them as ${\sigma }_i=(m_i,r_i,m_i^{\prime })$, and then computes ${A_i=a}_i·P$;

-

To safeguard data communication across the public channel, the ES must perform encryption on the transmitted data. The ES obtains the current timestamp ${TES}_i$, then computes $d_{i1}={\sigma }_i\oplus h_2\left({TES}_i\right|\left|\right(a_j+x_j)·{PK}_i)$ and the verification value ${kID}_i=h_2\left(A_i\left|\left|{\sigma }_i\right|\right|{PK}_j\right)$;

-

The ES sends message $Q_{i2}=({\sigma }_i,A_i,d_{i1},{kID}_i,{TES}_i)$ to the SMD.

(3)

${SMD}_i\to ES:Q_{i3}=(d_{i2},{TSMD}_i^{\prime })$

-

The SMD first checks the timeliness of the received message. If the time condition is not satisfied, the data is discarded. Otherwise, the SMD decrypts and computes the data ${\sigma }_i=d_{i1}⨁h_2\left({TES}_i\right||x_i·(A_i+{PK}_j\left)\right)$;

-

The SMD computes and verifies whether ${kID}_i^{\prime }=h_2\left(A_i\left|\left|{\sigma }_i\right|\right|{PK}_j\right)$ holds. If the verification succeeds, the SMD proceeds to compute $r_i^{\prime }=(x_i{)}^{-1}·\left(m_i-m_i^{\prime }\right)+r_i$ and $R_i=r_i^{\prime }·P$. Then, the SMD calculates $Y_i=r_i·{PK}_i$;

-

Similarly, the SMD encrypts the data before transmission. The SMD obtains the current timestamp ${TSMD}_i^{\prime }$ and computes $d_{i2}={(Y}_i\left|\right|R_i)⨁h2(A_i\left|\left|{\sigma }_i\right|\right|{TSMD}_i^{\prime })$;

-

The SMD sends the data ${\mathrm{Q}}_{i3}=({\mathrm{d}}_{i2},{TSMD}_i^{\prime })$ to the ES.

2.3.5. Batch Authentication Phase

In the batch verification phase, the ES needs to verify n messages $(d_{12},{TSMD}_1^{\prime })$, $(d_{22},{TSMD}_2^{\prime })$, …, $\left(d_{n2},{TSMD}_n^{\prime }\right)$ simultaneously;

(1)

The ES uses ${TSMD}_i^{\prime }$ to verify the timeliness of the message. If the condition is not satisfied, the message is discarded. Otherwise, the ES decrypts the message ${\left(Y_i\right|\left|R_i\right)=d}_{i2}⨁h_2\left(A_i\left|\left|{\sigma }_i\right|\right|{TSMD}_i^{\prime }\right)$;

(2)

The ES performs batch authentication on the n signatures. It verifies whether the equation $\sum _{i=1}^n{Y}_i=\sum _{i=1}^n(m_i·P+r_i·{PK}_i)-\sum _{i=1}^n{m}_i^{\prime }·P$ holds. If the equation is satisfied, the ES accepts the n signatures; otherwise, it rejects the n;

(3)

At this point, the ES completes the batch authentication of the SMDs.

As illustrated in Figure 5, the message Q_i3 encapsulates specific hash commitments and encryption parameters. The aggregate signature verification equation $\sum _{i=1}^n{Y}_i=\sum _{i=1}^n(m_i·P+r_i·{PK}_i)-\sum _{i=1}^n{m}_i^{\prime }·P$, executed by the ES, is explicitly detailed within the figure, demonstrating the core logic of the batch verification process. Next, we provide the proof of correctness for the batch authentication process:

(1)

First, according to the computation of the challenge value $r_i^{\prime }$, it can be derived:

$$r_i^{\prime }={\displaystyle \frac{m_i-m_i^{\prime }}{x_i}}+r_i$$

(1)

$$\left(m_i+r_i\cdot x_i\right)\cdot P=\left(m_i^{\prime }+r_i^{\prime }\cdot x_i\right)\cdot P$$

(2)

(2)

Then, the following equation can be derived:

$$\begin{array}{l}\hspace{1em}{m}_i^{\prime }\cdot P+x_i\cdot R_i\\ =m_i^{\prime }\cdot P+r_i^{\prime }\cdot x_i\cdot P\\ =(m_i^{\prime }+r_i^{\prime }\cdot x_i)\cdot P\\ =(m_i+r_i\cdot x_i)\cdot P\\ =m_i\cdot P+r_i\cdot x_i\cdot P\\ =m_i\cdot P+r_i\cdot P{K}_i\end{array}$$

(3)

(3)

So:

$$\begin{array}{l}\hspace{1em}{\displaystyle \sum _{i=1}^n(m_i\cdot P+r_i\cdot P{K}_i)}-{\displaystyle \sum _{i=1}^n{m}_i^{\prime }\cdot P}\\ ={\displaystyle \sum _{i=1}^n{m}_i^{\prime }\cdot P+{\displaystyle \sum _{i=1}^n{x}_i\cdot R_i}}-{\displaystyle \sum _{i=1}^n{m}_i^{\prime }\cdot P}\\ ={\displaystyle \sum _{i=1}^n{x}_i\cdot R_i}\\ ={\displaystyle \sum _{i=1}^n{Y}_i}\end{array}$$

(4)

Therefore, the correctness of the batch authentication process is verified.

2.3.6. Group Key Agreement Phase

For the SMDs that have successfully passed authentication and initiated a session request, the ES is responsible for managing the group key agreement process within its domain. The negotiated group key functions as the shared session key among all authenticated SMDs and the ES.

(1)

Negotiation Process for a New Terminal Joining the Session Group

In the scenario where v new SMDs join the session group for group key agreement:

(1)

$ES\to {SMD}_i:Q_{i4}=\left(E_{SK},T_{SK},\Omega \right)$

-

Assume there are k SMDs currently in the group (if no existing SMDs are in the group, then k = 0), and n SMDs want to join the group. The ES selects a random number $b_i\in \{0,1{\}}^q$ for each $i\in [k+1,k+n]$, computes $B_i=h_2(b_i⨁{{\mathrm{h}}_2(Y}_i|\left|{\sigma }_i\right))$, and the group key ${GSK}_b^Y=h_2(B_1\left|\left|B_2\right|\right|\dots |\left|B_{k+n}\right)$;

-

Subsequently, the ES obtains the timestamp $T_{SK}$, encrypts ${GSK}_b^Y$, and computes $E_{SK}={GSK}_b^Y⨁h_2\left({\mathrm{T}}_{SK}\right||{\mathrm{a}}_i·R_i+x_j·{PK}_i)$, where i = 1, 2, …, k + n;

-

The ES computes the signature $\mathsf{\Omega }=h_2\left({\mathrm{T}}_{SK}\right|\left|E_{SK}\right|\left|{GSK}_b^Y\right||{\mathrm{a}}_i·R_i+x_j·{PK}_i)$ on the message and broadcasts message ${\mathrm{Q}}_{i4}=\left(E_{SK},{\mathrm{T}}_{SK},\mathsf{\Omega }\right)$ to nearby SMDs.

(2)

${SMD}_i:G{SK}_b^Y$

-

${\mathrm{S}\mathrm{M}\mathrm{D}}_i(i=1,2,\dots ,k+n)$ verifies the timeliness of the message, if it is not satisfied, the message is discarded. Otherwise, the SMD decrypts and computes ${GSKSK}_b^Y=E_{SK}⨁h_2\left(T_{SK}\right||r_i·A_i+x_i·{PK}_i)$;

-

The SMD verifies the signature, computes ${\Omega }^{\prime }=h2\left(T_{SK}\right|\left|E_{SK}\right|\left|{GSK}_b^Y\right||r_i·A_i+x_i·{PK}_i)$, and if equation ${\Omega \Omega }^{\prime }$ holds, accepts ${GSK}_b^Y$ as the group key.

(2)

The negotiation process for existing terminals leaving the session group

Assume that from a session group containing k SMDs, u members are preparing to leave. The process of updating the group key is similar to the key agreement process when new members join the session group; therefore, the description here will be simplified accordingly:

(1)

$\mathrm{E}\mathrm{S}\to {\mathrm{S}\mathrm{M}\mathrm{D}}_i:Q_{i4}^{\prime }=\left(E_{SK}^{\prime },T_{SK}^{\prime },\mathsf{\omega }\right)$

-

Each remaining $\mathrm{i}\in [1,\mathrm{k}-\mathrm{u}]$ selects a random number $e_i\in \{0,1{\}}^q$, computes $E_i=h2(e_i⨁{{\mathrm{h}}_2(Y}_i|\left|{\sigma }_i\right))$, and the group key ${GSK}_e^Y=h2(E_1\left|\left|E_2\right|\right|\dots |\left|E_{k-u}\right)$;

-

The ES obtains timestamp $T_{ES}^{\prime }$, computes $E_{SK}^{\prime }={GSK}_e^Y⨁h2\left(T_{SK}^{\prime }\right||{\mathrm{a}}_i·R_i+x_j·{PK}_i)$, and signs $\mathsf{\omega }=\mathrm{h}2\left(T_{ES}^{\prime }\right|\left|E_{SK}^{\prime }\right||{{GSK}_e^Y\left|\right|\mathrm{a}}_i·R_i+x_j·{PK}_i)$;

-

The ES broadcasts message $Q_{i4}^{\prime }=\left(E_{SK}^{\prime },T_{SK}^{\prime },\mathsf{\omega }\right)$ to nearby SMDs.

(2)

${\mathrm{S}\mathrm{M}\mathrm{D}}_i:{GSK}_e^Y$

-

Similarly, the SMD verifies the message timeliness. If valid, it decrypts the newly received group key ${GSK}_e^Y$ and verifies the correctness of the group key using the signature. If the verification succeeds, it sets ${GSK}_e^Y$ as the new group key.

2.3.7. Session Key Agreement Phase

The Group Session Key (GSK) is a shared key among group members, including the ES and ${SMD}_i$ (i ∈ [1, n]). However, when a specific SMD needs to upload its independent data to the ES, the group shared session key cannot meet this requirement. Therefore, the protocol uses Ri as the negotiation public key for ${SMD}_i$ and $A_i$ as the negotiation public key for the ES. Then, ${SMD}_i$ sets ${SK}_{SMD}^i=r_i·A_i$ as the shared session key, and the ES ${SK}_{ES}^i=a_i·R_i$ as the shared session key.

Furthermore, to ensure the independence of the shared session key relative to the group shared key and to enhance its security, the ES employs a chameleon hash function to construct a Merkle tree:

(1)

The ES computes $C_i=h_2(m_i·P+r_i·{PK}_i)$ using the random numbers $m_i$ and $r_i$ selected during the key setup phase, sets $C_i$ as the leaf nodes, and constructs the Merkle tree upwards to generate a Merkle root hash.

(2)

The ES broadcasts the root hash value and securely sends the hash values of the sibling nodes along the Merkle path to ${\mathrm{S}\mathrm{M}\mathrm{D}}_i$.

(3)

${\mathrm{S}\mathrm{M}\mathrm{D}}_i$ computes $C_i^{\prime }=h_2(m_i^{\prime }·P+r_i^{\prime }·{PK}_i)$ using ($m_i$, $r_i$, $m_i^{\prime }$) received during the setup phase, and uses this to verify the correctness of the Merkle root and the hash values of the sibling nodes at each level.

(4)

If the verification is correct, ${SMD}_i$ stores the received Merkle root and the hash values of the sibling nodes at each level.

The Merkle tree constructed by the ES allows ${SMD}_i$ to verify the correctness of $R_i$ at any time. Meanwhile, the redactable Merkle tree using the chameleon hash function allows ciphertext to be modified without changing the hash value, all without exposing the private key. Therefore, even if ${SMD}_i$’s negotiation public key $R_i$ is compromised, updating $R_i$ will not affect the group shared key. The Merkle proof process is illustrated in Figure 6.

3. Security Analysis

3.1. Informal Security Analysis

MEC requires that the designed authentication and key agreement protocol satisfies certain basic security requirements of the system and can resist common malicious attacks. The security of the proposed protocol is analyzed below.

(1)

Mutual Authentication. Mutual authentication indicates that the SMD and the ES achieve mutual, bidirectional authentication. During the authentication process between the SMD and the ES, the SMD can authenticate the identity of the ES via the RA. Conversely, the ES authenticates the members within the group and those wishing to join by performing aggregate signature verification using the chameleon Hash algorithm, thereby authenticating the SMDs.

(2)

Conditional Anonymous Traceability. Conditional anonymity indicates that throughout the authentication and key agreement process, the SMD sends data anonymously, and only the RA has the authority to trace its real identity. The SMD uses the pseudonym ${HID}_i$ to send messages, which are stored on the blockchain and protected by the user’s private key and a secure hash function. An adversary can only analyze the user’s real identity by solving the one-way hash function problem and breaking the user’s private key; however, the success probability of this assumption is negligible. When tracing the message source is required, the RA can decrypt ${CP}_i$ and compute the SMD’s real identity ${ID}_i={CP}_i⨁h_2\left({HID}_i\right|\left|{PID}_i\right|\left|s\right)$. Therefore, the protocol provides conditional anonymous traceability.

(3)

Forward and Backward Secrecy. In the protocol proposed in this paper, the group key agreement phase only allows authenticated SMDs to participate and successfully generate the group’s public session key. Unauthenticated SMDs or adversaries cannot obtain this session key. Furthermore, the group key (${GSK}_b^Y=h2(B_1\left|\left|B_2\right|\right|\dots ||B_{n+v})$) generation method involves each SMD and the challenge value provided by the ES jointly participating in the computation. Whenever a new vehicle joins or an old SMD leaves, the ES issues a new challenge value and updates the group key. Any newly joined SMD, departed SMD, or adversary cannot deduce the previous key (${GSK}_{b-1}^Y$) or the subsequent key (${GSK}_{b+1}^Y$) from the current session key (${GSK}_b^Y$). Therefore, the protocol ensures both forward and backward secrecy.

(4)

Resistance to Sybil Attacks. A Sybil attack refers to an adversary attempting to disrupt the normal operation of the network by creating bogus SMDs to send forged messages. In the proposed protocol, the identity of each SMD is authenticated by the ES upon completion of registration; any non-legitimized SMD will not be recognized. Furthermore, an adversary might cause a batch verification containing forged signatures to pass incorrectly by selecting specific messages and forging opposing signatures. However, in the proposed protocol, the ES provides a unique challenge value ${\sigma }_i$ to each legitimate SMD, which prevents adversaries from forging signatures and breaks the linear relationship in the aggregate signature.

(5)

Resistance to Replay Attacks. A replay attack is an act where an attacker intercepts and re-sends data packets to deceive the system. The proposed protocol effectively resists replay attacks by utilizing a timestamp and hash-signature mechanism. It ensures communication freshness by checking the message timestamp for a reasonable time difference $\mathsf{\Delta }T$, and ensures the timestamp has not been tampered with via its inclusion in the hash. This prevents both conventional replay attacks and replay attacks where the attacker modifies the timestamp.

(6)

Resistance to Man-in-the-Middle (MitM) Attacks. A MitM attack is a network security threat where an attacker intercepts and potentially modifies the communication between two parties. In this protocol, the Elliptic Curve Diffie–Hellman key exchange between the SMD and the ES, combined with the use of cryptographic hash functions, ensures the authenticity of both parties. To forge a message, an adversary would need the private key of either the SMD or the ES, which remains confidential and is not exposed to the attacker. Therefore, the protocol can effectively resist MitM attacks.

(7)

Resistance to Denial-of-Service (DoS) Attacks and Scalability. The proposed protocol employs a multi-layered defense strategy to mitigate DoS threats and ensure high scalability. Firstly, the ES performs lightweight pre-filtering by verifying the freshness of timestamps T_SMD and the validity of identities ID_i before executing computationally intensive cryptographic operations, effectively discarding replayed or illegitimate requests at negligible cost. Secondly, the core aggregate signature mechanism establishes a significant computational asymmetry: the cost for an adversary to generate massive valid signatures is significantly higher than the ES’s cost to verify them in a batch, thereby inherently suppressing computational DoS attacks. Finally, for practical deployment, we recommend incorporating rate-limiting mechanisms (e.g., Token Bucket algorithm) based on IP or ID at the ES side to further block malicious high-frequency triggers from specific sources, ensuring system availability.

(8)

Resistance to Internal Server Attacks. Although our system model assumes an “honest-but-curious” semi-trusted ES, we also address the scenario where an ES becomes malicious or colludes with other entities. Firstly, the protocol adheres to the principle of data minimization; the ES acts solely as an authentication executor and does not store any long-term private keys or sensitive identity information of the SMDs. Therefore, even if an ES is compromised or colludes, it cannot leak critical credentials to compromise an SMD’s security. Secondly, relying on the permissioned blockchain architecture, only authorized ESs are registered. During authentication, the SMD strictly verifies the ES’s legitimacy using its public key ${\mathrm{P}\mathrm{K}}_j$. If the ES fails verification or is determined to be unreliable, the SMD will immediately abort the connection and refuse access through that ES, effectively isolating the threat from malicious servers.

(9)

Resistance to Blockchain-Specific Attacks and Side-Channel Threats. Addressing blockchain-specific vectors, our scheme is deployed on a permissioned consortium blockchain utilizing the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm. PBFT provides deterministic finality, inherently preventing forking issues common in public chains, and effectively resists consensus manipulation as long as malicious nodes do not exceed one-third of the total network. Regarding smart contract vulnerabilities, the contract logic in our protocol is restricted to simple key-value lookups and hash verifications without complex asset transfers, and has undergone rigorous logic testing to minimize the attack surface. Furthermore, regarding side-channel threats, our protocol design avoids conditional branching based on secret values. In the implementation, we adopt constant-time cryptographic primitives (leveraging standard configurations of the Multiprecision Integer and Rational Arithmetic C Library (MIRACL)) to eliminate timing leakages.

3.2. Formal Analysis Using the ProVerif Tool

ProVerif is a widely recognized automatic protocol verification tool in the field of cryptography. It is based on the applied pi-calculus and operates under the classic Dolev-Yao (DY) attacker model, specifically designed for analyzing and verifying the security of cryptographic protocols. The complete ProVerif verification code used in this article can be found in Appendix B. To construct a feasible formal model in ProVerif, this study adopts the following abstraction strategies based on applied pi-calculus: First, we employ the DY attacker model, assuming perfect cryptographic primitives (e.g., hashing, encryption) where the adversary fully controls the public channel but lacks computational breaking capabilities. Second, for ECC we utilize equation theories in ProVerif to symbolically model the commutativity and associativity of group operations, ensuring the correctness of the Diffie-Hellman key agreement logic. Finally, participating entities are modeled as unbounded concurrent processes to verify security properties under multi-session parallel environments.

Since the batch authentication part operates over an open communication channel, facing dual threats from external attackers and the “honest-but-curious” ES, this chapter primarily focuses on proving the security of identity authentication and the keys during the distributed key generation phase. As shown in

Table 2. Principal Event Definitions.

Key Principal Events
event receivedMessage (bitstring, bool).
event receivedKey (point).
event sentMessage (bitstring, bool).
event sentKey (point).

, receivedMessage indicates that the SMD’s identity is authenticated by the ES and it receives the batch authentication challenge value from the ES; receivedKey indicates that the ES has authenticated the SMD’s identity and received the SMD’s batch authentication key material; sentMessage indicates that the ES has completed the authentication of the SMD’s identity and sent the challenge value; and sentKey indicates that the batch authentication protocol has been executed by the SMD.

Based on the definitions of the key principals above, the protocol in this chapter is proven to satisfy basic security properties using the specialized typed process language. As shown in

Table 3. Protocol Security Property Objectives.

Description of Security Objectives
query m: bitstring, Time: timestamp; inj-event (sentMessage(m,false)) ==> inj- event (receivedMessage (m, false)).
query Yi: point; event (sentKey (Yi)) ==> event (receivedKey (Yi)).
query attacker (m).
query attacker (Yi).

, the first and second queries are used to verify whether a legitimate SMD and ES can execute the scheme normally; the third query is used to verify the confidentiality of the challenge value exchanged between the SMD and the ES; the fourth query is used to verify the confidentiality of the batch authentication material sent by the SMD.

To verify the security of the key and the authentication of identity during the distributed key generation phase, as shown in

Table 4. Main Protocol Process.

Main Verification Process
process
new IDi: bitstring;
new xi: bignum;
new xj: bignum;
(!SMD(IDi, xi | !ES(xj)))

, a legitimate SMD that has completed registration initiates an authentication request, and the ES responds with a message and interacts with the SMD to complete the protocol. Based on this, two principals are defined: ES (x_j: bignum) and SMD (ID_i: bitstring, x_i: bignum). The execution of the protocol is modeled as these two principals, based on their identities and keys, engaging in a series of message exchanges under the DY attacker model.

The security verification results are illustrated in Figure 7. The first and second “Query” statements indicate that the scheme for the distributed key generation phase can be executed normally and possesses authentication capabilities; the third “Query” indicates that the challenge value of the scheme is confidential and can provide secure and reliable key material for group key agreement; the fourth “Query” indicates that the batch authentication key material is confidential and can be securely sent to the ES to reliably proceed with the next step of the group key agreement operation.

3.3. Formal Analysis of GKA Phase Using BAN Logic

Given the limitations of the ProVerif tool in simulating dynamic group membership changes and potential state space explosion, we employ BAN Logic to formally prove the security of the Group Key Agreement (GKA) phase, specifically focusing on the confidentiality and authentication of the group key.

In the GKA phase, the ES generates the group key GSK and utilizes the shared secret $K_{seed}=a_i{R}_i+x_{j}P{K}_i$ to encrypt and broadcast it to ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$. The idealized protocol is described as follows:

Message 1: $ES\to {SMD}_i:\{GSK,T_{SK},\Omega \}{K}_{seed}$

To proceed with the logical derivation, we establish the following Initial Assumptions:

A1: ES | ≡ #($T_{SK}$) (ES believes the timestamp is fresh)

A2: ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$ | ≡ # ($T_{SK}$) (SMD believes the timestamp is fresh)

A3: ES | ≡ ($\mathrm{E}\mathrm{S}$$\stackrel{K_{seed}}{\leftrightarrow }$${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$) (ES believes it shares the seed key with SMD)

A4: ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$| ≡ ($\mathrm{E}\mathrm{S}$$\stackrel{K_{seed}}{\leftrightarrow }$${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$) (SMD believes it shares the seed key with ES)

A5: ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$| ≡ $\mathrm{E}\mathrm{S}⟹$($\mathrm{E}\mathrm{S}{\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$) (SMD believes ES has jurisdiction over the group key)

Our goal is to prove that ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$ believes that GSK is a valid group key generated by ES and is fresh. The specific proof steps are as follows:

Step 1: Based on Message 1 and Assumption A4, applying the Message Meaning Rule:

$${\displaystyle \frac{SM{D}_i⊲{\{GSK,T_{SK}\}}_{K_{seed}},SM{D}_i|\equiv (ES\stackrel{K_{seed}}{\leftrightarrow }SM{D}_i)}{SM{D}_i|\equiv ES|~(GSK,T_{SK})}}$$

(5)

This indicates that ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$ believes ES sent the message containing GSK.

Step 2: Based on Assumption A2 (freshness of the timestamp) and the Nonce Verification Rule:

$${\displaystyle \frac{SM{D}_i|\equiv \#(T_{SK}),SM{D}_i|\equiv ES|~(GSK,T_{SK})}{SM{D}_i|\equiv ES|\equiv (GSK,T_{SK})}}$$

(6)

This indicates that ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$ believes that ES is confident in the validity of GSK.

Step 3: Based on Assumption A5$ (jurisdiction) and the Jurisdiction Rule:

$${\displaystyle \frac{SM{D}_i|\equiv ES\Rightarrow \#(GSK),SM{D}_i|\equiv ES|\equiv GSK}{SM{D}_i|\equiv GSK}}$$

(7)

We finally derive that ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$ believes GSK is a valid group key. Furthermore, since ${\mathrm{K}}_{\mathrm{s}\mathrm{e}\mathrm{e}\mathrm{d}}$ is possessed only by ES and legitimate ${\mathrm{S}\mathrm{M}\mathrm{D}}_{\mathrm{i}}$, and the GSK is transmitted in encrypted form, the confidentiality requirement is satisfied.

4. Results and Discussion

To comprehensively evaluate the proposed scheme, this study adopts a “Construction-Verification-Simulation” hybrid research methodology. The research process is structured into three phases: first, constructing the protocol logic based on ECC and Chameleon Hash primitives; second, employing the ProVerif tool to formally verify security properties under the Dolev-Yao attacker model; and third, conducting a two-layer empirical simulation to evaluate performance. Unlike data mining studies that rely on static public datasets, this work focuses on cryptographic protocol design; therefore, our experimental artefacts consist of dynamic execution logs. These include: (1) the precise execution times of fundamental operations (e.g., Scalar Multiplication T_Gm) measured via the MIRACL, which serves as the baseline for computational cost analysis; and (2) synthetic transaction logs (latency and throughput) generated by the Hyperledger Caliper tool under a stress test rate of 1050 TPS. To ensure reproducibility and fairness, the experimental environment was configured as follows: Server-side cryptographic operations were benchmarked on a workstation running Ubuntu 16.04 (64-bit) equipped with an Intel Core i3 processor. To establish a consistent baseline, comparative analysis aligns with the experimental parameters of the ECCAS scheme [38]. Furthermore, to address performance concerns regarding heterogeneous devices in real-world MEC environments, we constructed a mobile testbed using a legacy Google Nexus One smartphone (1 GHz ARM CPU, 512 MB RAM) to verify the scheme’s feasibility on strictly resource-constrained low-power devices. All underlying cryptographic computations were implemented using the standard MIRACL.

As shown in

Table 5. Experimental Results.

Definitions	Description	Operation Costs (ES/Server)	Operation Costs (SMD/Mobile)
Curve	Elliptic Curve Type (E/Fp)	Type-1 Pairing (p = 512 bits)	-
TGm	Scalar multiplication on G	0.4420 ms	19.9190 ms
TGa	Scalar addition on G	0.0180 ms	0.1180 ms
Th	Hash function	0.0001 ms	0.0890 ms
|G|	Bit length of an element in G	1024 bits	1024 bits
|GT|	Bit length of an element in GT	1024 bits	1024 bits
logq	Private Key Length (Size of Zq)	160 bits	160 bits
|T|	Timestamp length	32 bits	32 bits
|ID|	Identity length	256 bits	256 bits

, the mobile-side data (SMD/Mobile) is based on actual measurements from a Google Nexus One. The millisecond-level execution time demonstrates the feasibility of the proposed scheme on resource-constrained devices, satisfying the real-time requirements of MEC. It is important to note that in the subsequent cross-scheme comparisons, since the comparative schemes in Refs. [39,40,41] lack standardized mobile-side data, the analysis will be uniformly based on the benchmark data from the ES (Server) side to ensure the fairness of the comparison. Additionally, the execution times of some lightweight operations and the performance evaluation of the registration phase are omitted, as their impact on the overall system performance is negligible.

4.1. Comparative Analysis of the Computational Cost of Batch Authentication

This paper compares the computational efficiency of the proposed scheme with that of the CPPBA [39], ECCAS, LBVP [40], and Ref. [41] schemes.

Table 6. Batch Authentication Operations of Each Scheme.

Definitions	Single Request	Batch Processing	Operation Length
LBVP	11TGm + 4TGa + 8Th	2nTGm + 2nTGa + nTh	4|G| + 4logq + 2|T|
ECCAS	6TGm + 10TGa + 2Th	3nTGm + 5nTGa + nTh	3|G| + 5logq + |T|
CPPBA	4TGm + 2TGa	(n + 2)TGm + nTGa	3|G| + 2logq + 2|T|
PS 1	4TGm + 6Th	(n + 1)TGm + nTGa	|G| + 10logq + 3|T|

¹ Proposed Scheme (PS).

provides a detailed comparison of the computational costs incurred when processing a single request and when performing batch processing of n requests.

First, the efficiency of authenticating a single SMD is analyzed. In the CPPBA scheme, four scalar multiplication operations and two scalar addition operations are required, resulting in a computational cost of 4T_Gm + 2T_Ga ≈ 1.8040 ms; In the ECCAS scheme, six scalar multiplications, ten scalar additions, and two hash operations are required, leading to a total computational cost of 6T_Gm + 10T_Ga + 2Th ≈ 2.8322 ms; The LBVP scheme requires eleven scalar multiplications, four scalar additions, and eight hash operations, resulting in a cost of 11T_Gm + 4T_Ga + 8T_h ≈ 4.9348 ms. In contrast, the proposed scheme only requires four scalar multiplications and six hash operations, with a total computational cost of 4T_Gm + 6T_h ≈ 1.7686 ms. To provide a more intuitive comparison among these schemes, Figure 8 illustrates the computational cost of authenticating a single SMD request.

In all the compared schemes, only scalar multiplication, scalar addition, and hash functions are employed. The proposed scheme exhibits the lowest computational cost, achieving computational efficiency improvements of 1.96%, 37.55%, and 64.16% over the CPPBA, ECCAS, and LBVP schemes, respectively.

To evaluate the efficiency of batch verification, the proposed scheme is compared with the CPPBA, ECCAS, and LBVP schemes. The summarized analysis results are illustrated in Figure 8. In the CPPBA scheme, for batch authentication involving n user terminals, the receiver needs to perform (n + 2) scalar multiplications and n scalar additions. Therefore, its execution time can be expressed as (n + 2)T_Gm + nT_Ga ≈ (0.46n + 0.884) ms. In the ECCAS scheme, the receiver must perform 3n scalar multiplications, 5n scalar additions, and n hash operations, leading to an execution time of 3nT_Gm + 5nT_Ga + nT_h ≈ (1.4161n) ms; In the LBVP scheme, 2n scalar multiplications, 2n scalar additions, and n hash operations are required, resulting in an execution time of 2nT_Gm + 2nT_Ga + nT_h ≈ (0.9201n) ms. In contrast, the proposed protocol only requires (n + 1) scalar multiplications and n scalar additions, with an execution time of (n + 1)T_Gm + nT_Ga ≈ (0.46n + 0.442) ms.

As shown in Figure 9, during batch authentication, the compared schemes all exhibit the characteristic that their time overhead increases linearly with the number of authenticated SMDs. In contrast, the scheme proposed in this paper demonstrates optimal performance in batch authentication efficiency. Compared to the CPPBA scheme, our scheme maintains a consistent efficiency advantage regardless of the number of SMDs. However, the CPPBA scheme is vulnerable to MitM attacks during its vehicle key generation phase, and its security properties are weaker compared to our scheme. As for the ECCAS and LBVP schemes, their time overhead growth rates are faster, which implies that as the number of authenticated SMDs increases, the performance gap compared to our scheme will further widen. When processing 100 authentication messages, compared to the CPPBA, ECCAS, and LBVP schemes, our scheme’s computational efficiency is improved by 0.94%, 67.20%, and 49.53%, respectively.

4.2. Batch Authentication Communication Cost Comparative Analysis

In the MEC environment, SMDs are typically resource-constrained, and their battery life and network bandwidth are precious resources. Therefore, the communication cost of the authentication protocol is an essential indicator of its efficiency and applicability.

Given that the communication cost of batch authentication scales linearly with the cost of a single authentication message, analyzing the communication overhead of a single message provides an effective method for evaluating the overall communication overhead. The overhead required for communication operations is listed in Table 6, and a comparison of the schemes’ communication costs is presented in Figure 10. As shown in Figure 10, the protocol proposed in this study has the lowest communication cost. Compared to the CPPBA, ECCAS, and Zhang et al.’s schemes, the communication overhead is reduced by 23.15%, 31.97%, and 44.67%, respectively. Lower communication costs imply lower energy consumption. Our scheme, through its innovative protocol design, effectively addresses the communication bottleneck issue during large-scale device access. This holds critical practical significance for the long-term, high-density operation of resource-constrained devices in the MEC environment.

4.3. Comparative Analysis of Group Key Agreement

Next, the computational cost of group key agreement when new devices join the session group will be comparatively analyzed. Since the CPPBA, ECCAS, and LBVP schemes only involve batch authentication, this protocol is compared with the group key agreement in the scheme by Ref. [42]. The experimental data is referenced from Ref. [42], and the relevant cryptographic operations and their costs are shown in

Table 7. The Relevant Cryptographic Operations and Their Costs.

Cryptographic Operation	Operation Description	Execution Time/ms
Th	Hash Operation	0.008
Tse	Symmetric Encryption	0.0183
Tsd	Symmetric Decryption	0.0182
Tecc	Elliptic Curve Scalar Multiplication	0.0514
Tcm	Chebyshev Map	0.0336

.

To simulate and analyze the scenario of new devices joining the session group in greater detail, this experiment designed a simulation process starting with 10 SMDs and incrementally adding 10 devices at a time, until the total number of members in the session group reached 100. This incremental approach is intended to provide a more practical evaluation of the computational cost as the number of session group members increases. Furthermore, to enhance the performance comparison,

Table 8. Group Key Agreement Operation ¹.

	New Device Join	New Group Key Establishment
Proposed Scheme	nTh	(2k + 2n)Tecc + (4k + 4n + 1)Th
Ref. [42]	4nTcm + 6nTh	4(k + n)Tcm + (4k + 4n + 1)Th + (k + n)Tse + (k + n)Tsd

¹ Assume there are k SMDs in the original session group, and n SMDs join.

details the specific computational operations of the group key agreement process as described in our proposed scheme and in Ref. [42]. This allows for an intuitive comparison and analysis of the efficiency of the two methods at different session group scales.

The computational cost of group key agreement is summarized in Figure 11. Although Ref. [42] adopts the more efficient Chebyshev map technique, its authentication ring construction process requires performing two computation operations (on the left and right sides of the ring, respectively), thereby introducing redundant resource consumption. In contrast, our scheme utilizes the Elliptic Curve Diffie-Hellman key exchange, requiring fewer operations when updating the group key, which effectively reduces the computational cost.

From the analysis of the results, it is evident that as the number of group members increases, the computational cost growth rate of the scheme by Ref. [42]. is significantly higher than that of our proposed scheme. When the number of session group members reaches 100, the computational cost of the scheme by Ref. [42]. reaches 24.1510 ms, whereas our scheme is only 15.6360 ms, achieving an efficiency improvement of 35.26%.

To further evaluate the scalability of the protocol in large-scale group scenarios, we performed a linear regression analysis based on the empirical data for n = 10 to 100 (as shown in Figure 11). The results indicate that the computational overhead T (ms) exhibits a high linear correlation with the number of group members n, with a coefficient of determination R² > 0.99, verifying that the algorithmic time complexity is strictly O(n). Based on this fitted model, we extrapolated the performance for larger scales: for group sizes of n = 500, 1000, and 5000, the projected group key update overheads are approximately 78 ms, 156 ms, and 780 ms, respectively. These projections demonstrate that even under extreme hyperscale concurrency (n = 5000) within an edge server’s coverage, the key update latency remains under 1 s, fully satisfying the real-time requirements for asynchronous group communication in MEC environments.

4.4. Blockchain Performance Evaluation

To comprehensively evaluate the practical feasibility of the proposed scheme in the MEC environment, this section presents a rigorous empirical performance test of the smart contracts within the proposed scheme, focusing on analyzing the additional overhead (latency) introduced by the permissioned blockchain and the system’s throughput performance.

This study established a consortium blockchain runtime environment based on the FiscoBcos blockchain platform. The nodes were set up using a multi-virtual machine deployment method, and the simulation experiments were conducted on an Ubuntu virtual machine configured with an 8-core CPU and 16GB RAM. To accurately quantify blockchain performance, the Hyperledger Caliper stress testing tool was deployed, focusing on stress testing the core smart contract algorithms (such as key material query and verification).

Figure 12 presents the stress test report of the smart contract under different loads. The target send rate was set to 1050 TPS. As can be seen from the empirical data: the average execution latency of the smart contract is only 0.05 s, with the maximum latency controlled within 0.82 s. This millisecond-level response speed fully satisfies the requirements for quasi-real-time authentication in MEC scenarios. Under high concurrent requests, the transaction success rate remained at 100% (Fail = 0), demonstrating the robustness of the system.

To further evaluate the scalability of the system, we tested the system throughput (Z-axis) under different numbers of nodes (X-axis) and different numbers of concurrent clients (Y-axis). The results are shown in Figure 13. When the number of users is constant, as the number of consensus nodes increases, the system throughput changes smoothly without significant decline, indicating that the PBFT consensus algorithm has good scalability under the consortium chain configuration. When the number of nodes is constant, as the number of concurrent users increases, the throughput shows a trend of first rising and then stabilizing, with the peak throughput stabilizing above 1000 TPS.

The above empirical data indicate that although the introduction of a permissioned blockchain adds a certain amount of computational overhead, the resulting latency (average 0.05 s) is acceptable for most MEC applications. In particular, maintaining a throughput of thousands of TPS at a scale of 50 nodes is sufficient to support large-scale device access management in regional MEC networks. Therefore, the proposed scheme achieves a good balance between security enhancement and performance cost.

4.5. Discussion

The experimental findings presented above provide important insights into the balance between efficiency and security in MEC environments. Notably, the performance advantage of the protocol is structural rather than solely numerical. By leveraging the chameleon hash-based aggregate signature, the verification overhead is decoupled from the number of accessing devices, reducing the batch verification complexity from linear growth to a near-constant-time operation. This architectural shift is crucial for mitigating congestion bottlenecks that commonly arise during large-scale device access.

Although the use of a Merkle Tree for session key verification incurs a marginal computational cost, the analysis indicates that this overhead represents a worthwhile trade-off for strengthening protection against internal threats from semi-trusted servers, a security gap often overlooked in prior efficiency-oriented schemes. The linear regression projections (R² > 0.99) indicate that the system maintains stable responsiveness even in hyperscale scenarios (n = 5000), confirming its suitability for city-scale IoT deployments. These results indicate that the proposed unified architecture achieves an effective balance between high-performance batch authentication and enhanced resistance to semi-trusted-server attacks, although deployment in public blockchain environments may require additional optimization of consensus latency.

5. Conclusions

To address the challenges of high computational and communication costs and the limited trustworthiness of edge servers in existing batch authentication schemes, this paper proposes a blockchain-based batch authentication and group key agreement protocol that incorporates chameleon hashing. The main contributions are summarized as follows: First, to mitigate efficiency bottlenecks in massive device access, a unified “Authentication–Negotiation” architecture is constructed through an elliptic-curve-based chameleon hash function. This allows the ES to perform aggregate signature authentication on batch messages and efficiently negotiate group keys by reusing authentication parameters, successfully reducing the verification complexity to near-constant time. Second, compared with existing technologies, the proposed approach improves key-management efficiency through smart contracts and enhances the intrinsic security of the edge. For semi-trusted environments, a Merkle-Tree-based verification mechanism is introduced to enable terminals to independently validate key correctness, thereby providing protection against internal tampering attacks. Finally, ProVerif formal analysis and multi-dimensional simulation experiments demonstrate that the proposed method significantly reduces communication and computational costs. In particular, stress tests under hyperscale concurrent scenarios (n = 5000) show that the scheme provides clear performance advantages and strong robustness, making it suitable for latency-sensitive and low-power edge-computing environments.