A Blockchain-Assisted Security Protocol for Group Handover of MTC Devices in 5G Wireless Networks

In the realm of the fifth-generation (5G) wireless cellular networks, renowned for their dense connectivity, there lies a substantial facilitation of a myriad of Internet of Things (IoT) applications, which can be supported by the massive machine-type communication (MTC) technique, a fundamental communication framework. In some scenarios, a large number of machine-type communication devices (MTCD) may simultaneously enter the communication coverage of a target base station. However, the current handover mechanism specified by the 3rd Generation Partnership Project (3GPP) Release 16 incurs high signaling overhead within the access and core networks, which may have negative impacts on network efficiency. Additionally, other existing solutions are vulnerable to malicious attacks such as Denial of Service (DoS), Distributed Denial of Service (DDoS) attacks, and the failure of Key Forward Secrecy (KFS). To address this challenge, this paper proposes an efficient and secure handover authentication protocol for a group of MTCDs supported by blockchain technology. This protocol leverages the decentralized nature of blockchain technology and combines it with certificateless aggregate signatures to mutually authenticate the identity of a base station and a group of MTCDs. This approach can reduce signaling overhead and avoid key escrow while significantly lowering the risk associated with single points of failure. Additionally, the protocol protects device anonymity by encrypting device identities with temporary anonymous identity markers with the Elliptic Curve Diffie–Hellman (ECDH) to abandon serial numbers to prevent linkage attacks. The resilience of the proposed protocol against predominant malicious attacks has been rigorously validated through the application of the BAN logic and Scyther tool, underscoring its robust security attributes. Furthermore, compared to the existing solutions, the proposed protocol significantly reduces the authentication cost for a group of MTCDs during handover, while ensuring security, demonstrating commendable efficiency.


Introduction
Machine-type communication (MTC), also known as machine-to-machine (M2M) communication, has been obtaining increasing attention for the widespread adoption of the fifth generation (5G) wireless cellular networks.With potential to revolutionize a broad spectrum of sectors like healthcare, logistics, manufacturing, process automation, energy, and utilities, MTC stands at the forefront of technological advancement.In certain communication scenarios, such as high-speed trains, convoys, and buses, multiple MTC devices (MTCDs) may move from the coverage area of one base station to another.This occurrence is labeled as a "group handover", necessitating each MTCD to authenticate during the transition [1].
The 5G wireless network employs a multitude of miniature millimeter-wave cellular base stations, aiming at serving a large number of users.This approach allows for the efficient reuse of limited spectrum resources and supports the access of large-scale MTC the target access relay node.However, it is only applicable to fixed trajectory communication in high-speed rail contexts.Ref. [16] produces a group MTCD handover authentication using base stations installed on drones.It applies to extremely specific scenarios and is not suitable for general use.At the same time, there is also the issue of drones used as base stations being unable to sustain long-term energy consumption.The solutions in [5,6,8,10,13,16] are all susceptible to the risk of DoS attacks.During the aggregation of information, the aggregated information can only be successfully verified if all members are legitimate.Attackers can send false aggregate information and intentionally cause the entire group's verification to fail.Ref. [17] presents a secure and privacy-preserving handover scheme for 5G networks, but it comes with higher computational costs due to the use of multiple modular exponentiation algorithms.
The development of 5G networks has facilitated the support for large-scale connections of MTC devices, offering higher data rates, lower latency, greater connection capacity, and higher energy efficiency.The introduction of large-scale MTC devices enables tens of thousands of devices to be interconnected, which is crucial for applications such as smart cities, smart homes, and industrial automation that require many sensors and actuators to seamlessly connect and communicate.Existing solutions for large-scale MTCD handover authentication in 5G networks have certain security flaws and are almost ineffective in mitigating DoS or DDoS attacks.Moreover, secure functions like bilinear mapping can lead to high computational overheads.All the abovementioned facts motivate us to design a blockchain-assisted group handover authentication protocol to provide sufficient attack prevention, energy efficiency, and fast computation, making it a piece of significant research work.By the BSPGH scheme, the distributed nature of blockchain is utilized to directly achieve mutual authentication between large-scale MTC devices and the target base station, effectively alleviating DoS or DDoS attacks, while also solving the key escrow problem.In terms of resource consumption, the proposed group handover authentication scheme can reduce signaling costs and authentication costs.Our future research will integrate blockchain technology with future communication network standards and protocols to design lightweight protocols.

Preliminaries
In this section, we introduce some of the technical concepts and cryptographic techniques that will be used in this paper.

RelCLAS
Aggregated signatures are a digital signature technique that efficiently combines n independent signatures from n users into a single compact signature.This approach allows verifiers to ensure that these n users have indeed signed their respective n messages, effectively reducing the computational and communication burden during the verification process.In this way, aggregated signatures not only improve data processing efficiency but also optimize resource consumption during storage and transmission.The RelCLAS scheme proposed in [18] is employed in this paper.The RelCLAS scheme typically consists of the following steps: Setup: The AMF and AUSF receive security parameters to generate the system master keys P pub and T pub , and the system parameters list params is published by the AMF.
Secret Value Generation: Users randomly select msk i ∈ Z * q as the secret value and compute the user's partial public key mpk i .
Pseudonym Generation: After receiving the user's identity identifier ID, AUSF performs an XOR operation on the ID to obtain the anonymous identity TID.
Partial Secret Key Generation: AMF randomly selects r i ∈ Z * q as the secret value and generates the user's partial public key R i and partial private key psk i .
User Key Generation: After receiving the partial key from AMF, the user generates the key pairs {mpk i , R i } and {msk i , psk i }.
Signature Generation: Each user selects n i ∈ Z * q to generate the secret value N i .Using the parameter list param, some state information, message M i ∈ M (where M is the message space), their anonymous identity TID i , and their private key pair {msk i , psk i }, they compute the signature σ i .
Aggregate: The aggregate signature generator is the first user entering a new coverage area.It receives signatures from other users and aggregates these signatures to produce the aggregate signature σ.
Aggregate Verify: The aggregate signature verifier, i.e., t-gNB, uses the anonymous identities TID i of n users, their corresponding public keys pk i , secret values N i , the system master key Ppub, and the aggregate signature σ on messages M i , . . ., M n as input.If the aggregate signature is valid, it outputs true, otherwise, it outputs false.

Blockchain
Blockchain is a collaborative distributed ledger that utilizes multiple computer hosts/nodes in a network to store and manage transaction data.Each host maintains a complete copy of the ledger, eliminating the necessity for a single central authority.Transaction data are organized in chronological order into blocks, with each block containing a certain number of transaction records, typically linked to the previous block utilizing a hash value, forming a chain.It ensures the immutability of transaction data.To ensure the ledger remains consistent across all hosts, the blockchain network uses a consensus algorithm to determine which hosts have the authority to add new blocks.This prevents malicious hosts from tampering with ledger data.Blockchain employs encryption technology to safeguard the confidentiality and integrity of transaction data.Each transaction undergoes a digital signature.
Blockchains are categorized into three types [19].Public blockchains are open allowing any user to join the blockchain network, view the ledger, and participate in the consensus process.Private blockchains are usually controlled by specific entities or organizations, and only invited participants can join the blockchain network.Consortium blockchains are managed collaboratively by multiple entities or organizations, allowing these participants to share data and jointly manage the blockchain network.
In the system under the study, in normal circumstances, around a small cell controlled by a base station, there are six adjacent cells designated as neighbors.The base station of this cell and those of the adjacent cells are used as nodes in a blockchain network.Each 5G base station in the network serves as a private blockchain node, responsible for storing the public key information of MTCDs.Each base station maintains a complete copy of the blockchain.After an MTCD completes initial registration at a nearby base station, the source base station adds the MTCD's public key information to the blockchain by creating a new transaction.To reduce storage overhead, each block contains multiple transaction records.These transactions are verified by nodes in the blockchain network and consensus can be achieved with other nodes using the Practical Byzantine Fault Tolerance (PBFT) consensus algorithm.Once a new block is accepted by the other blockchain nodes and added to the blockchain, it is distributed to all nodes, including the target base station, thereby updating their blockchain copies.When an MTCD moves from a location controlled by the source base station to the location controlled by the target base station, during the handover preparation phase, the target base station will search for the MTCD's public key information on the entire blockchain.
This blockchain consists of numerous blocks, each with a size of 1MB.Each block is stored as a file containing multiple transaction records, each of which includes the public key information of an MTCD.Given that we use public keys based on the elliptic curve secp256k1 with public keys of 256 bits in length according to [20].Together with other transaction information including transaction inputs, outputs, version, and other fields, and transaction fees, the total comes to approximately 180 Bytes per transaction.Therefore, using Equation (1), we can calculate how many transactions can be stored in a block.Since the size of a block is primarily composed of transaction data, for simplicity, we omit other block information in this calculation.
where N represents the number of users that the base station can serve, M is the block size, and P is the size of the transaction data; the number of transactions that can be stored reaches into the thousands.Considering that the number of MTCDs under a single base station's coverage is only in the dozens, the capacity of the blockchain to store MTCD public key information far exceeds the needs of a group of MTCDs.

System Background 4.1. System Model
The system under study follows the structure of the 5G wireless cellular network specified in the 3GPP TS 23.501 R16 [21].As depicted in Figure 1, the 5G wireless network consists of a core network (CN) and radio access networks (RANs).The devices involved in the CN mainly include the Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), and Unified Data Management (UDM), while Next Generation Node B (gNB) and user equipment or MTCDs exist in the RANs.The entities primarily involved in the handover process are MTCDs, gNB, AMF, AUSF, and UDM.
key information of an MTCD.Given that we use public keys based on the elliptic curve secp256k1 with public keys of 256 bits in length according to [20].Together with other transaction information including transaction inputs, outputs, version, and other fields, and transaction fees, the total comes to approximately 180 Bytes per transaction.Therefore, using Equation (1), we can calculate how many transactions can be stored in a block.Since the size of a block is primarily composed of transaction data, for simplicity, we omit other block information in this calculation.
where N represents the number of users that the base station can serve, M is the block size, and P is the size of the transaction data; the number of transactions that can be stored reaches into the thousands.Considering that the number of MTCDs under a single base station's coverage is only in the dozens, the capacity of the blockchain to store MTCD public key information far exceeds the needs of a group of MTCDs.

System Model
The system under study follows the structure of the 5G wireless cellular network specified in the 3GPP TS 23.501 R16 [21].As depicted in Figure 1, the 5G wireless network consists of a core network (CN) and radio access networks (RANs).The devices involved in the CN mainly include the Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), and Unified Data Management (UDM), while Next Generation Node B (gNB) and user equipment or MTCDs exist in the RANs.The entities primarily involved in the handover process are MTCDs, gNB, AMF, AUSF, and UDM.

AMF:
AMF is responsible for managing access and mobility-related tasks of user devices, ensuring network efficiency, security, and reliability.In the system, in our group handover authentication phase, the AMF does not need to forward authentication information anymore.

AMF:
AMF is responsible for managing access and mobility-related tasks of user devices, ensuring network efficiency, security, and reliability.In the system, in our group handover authentication phase, the AMF does not need to forward authentication information anymore.
AUSF: AUSF is responsible for handling authentication and security-related tasks for MTCDs.It verifies the identity of MTCDs and the security credentials they provide.In our system, the AUSF primarily generates anonymous identities for both MTCDs and gNBs.
UDM: UDM is responsible for managing and accessing user data.In our system, the UDM stores the permanent identity identifiers of MTCDs and gNBs.
MTCD: In our system, an MTCD, which is a user in the 5G network, initially needs to send a request for registering its identity to the AMF.The MTCD undergoes identity authentication with the gNB upon accessing the network.
gNB: gNB is the base station in the 5G wireless network.It is responsible for MTCD's access and connection, as well as reasonably allocating wireless communication resources.
Blockchain: Blockchain is a distributed database that ensures secure storage and sharing of data by creating a continuously growing and tamper-resistant chain of data records.In our system, a private blockchain is utilized as the secure data structure consisting of registered MTCDs.Each gNB maintains a backup copy of the blockchain.
In the 5G wireless networks specified by the 3GPP standards, when an MTCD enters the signal range of a gNB, it sends an authentication request to the gNB.This request is then forwarded by the gNB to the AMF, which is in turn forwarded to the AUSF.After the AUSF retrieves the necessary key information from the UDM, it executes the authentication process and returns the authentication response to the MTCD through the AMF and the gNB, completing further authentication procedures.In a typical 5G core network, one AUSF typically serves multiple AMFs, and each AMF manages connections with multiple gNBs.By the proposed scheme, decentralization of the authentication entities is achieved by integrating blockchain technology with the 5G system model specified by the 3GPP standard.In this system, each gNB is part of a private blockchain network and holds a copy of the entire blockchain.Once an MTCD completes the initial registration, there is no need to forward the authentication requests to the AUSF and UDM again.When an MTCD needs to undergo a handover authentication, the AMF only needs to forward the information of the service-gNB (s-gNB) to the target-gNB (t-gNB).At this point, the gNB can directly verify the identity of the MTCD using the information stored on the blockchain, without further forwarding to the AMF, AUSF, or UDM.To simplify the design, the proposed scheme focuses on the most common scenario, where all MTCDs connect to the gNB in their home network via 3GPP standard access technologies.Moreover, the connection between the gNB and the 5G core network is provided by a wired connection that is safeguarded by an Internet Protocol Security (IPSec) tunnel.If the MTCD and the gNB successfully achieve mutual authentication, the MTCD can be considered to have secure access to the legitimate 5G network.
In a cellular network architecture, to effectively reuse frequency resources, the entire service area is divided into numerous cells shaped as regular polygons, such as hexagons.Consequently, around a cell controlled by a gNB, typically six adjacent cells are designated as neighbors.During a handover, an MTCD can only hand over to one of these six neighboring cells, which is the cell controlled by the t-gNB associated with the current cell controlled by the s-gNB [22].

Attack Model
The attack model for the network under study is the Dolev-Yao model [23], by which attackers are assumed to be rational, powerful, and fully controlled entities capable of intercepting, tampering with, and sending messages.They can also attempt to break the security function of the protocol by analyzing communication content.In the RAN domain of the 5G network, there are security vulnerabilities in the wireless communication between MTCDs and gNBs, making them prone to malicious attacks such as information interception and tampering.According to the specification [21], the N2 interface employs IPsec and IKEv2 certificates to protect communications, ensuring their integrity and confidentiality, and preventing replay attacks.Therefore, the connection between the 5G core network and the gNB is considered secure.However, the connection between MTCDs and gNBs is weaker and potentially insecure.It is assumed that the interior of the 5G core network and its network functions are secure, ensuring the safety of connections between network functions.In contrast, other entities in the RAN are not completely trusted.
Given these considerations, an ideal 5G identity handover authentication protocol should support security features including device anonymity, bidirectional identity verifi-cation, secure data transmission, and perfect forward secrecy.Additionally, it should be capable of defending against active attacks, including impersonation, linkability attacks, replay attacks, man-in-the-middle attacks, and DoS attacks, as well as passive attacks like eavesdropping and location tracking.

The Proposed BSPGH
The details of the BSPGH protocol are presented in this section.By combining group authentication with blockchain technology, the BSPGH scheme demonstrates various security attributes.The BSPGH scheme operates in five distinct phases including system initialization and registration, handover preparation, first MTCD handover authentication, group handover authentication, and connection establishment.The notations used are shown in Table 1.

System Initialization and Registration
(1) System initialization: Given security parameter 1 K , AMF selects a large prime number q and E F q as the elliptic curve over a finite field F q .Let G be a cyclic additive group generated by generator P with order q.H 0 = Z q × {0, are hash functions.AUSF chooses a random element α ∈ Z q and calculates the corresponding public key P pub = α•P.AMF chooses a random element β ∈ Z q and calculates the corresponding public key T pub = β•P.Finally, the AMF publishes the system parameter (2) Initial registration: To protect identity privacy, each MTCD and gNB should first register with the AUSF to obtain their own pseudonyms.Below, we use the MTCD with the real identity ID i as an example to explain the specific registration process, which is shown in Figure 2.
Step-1 (2) Initial registration: To protect identity privacy, each MTCD and gNB should first register with the AUSF to obtain their own pseudonyms.Below, we use the MTCD with the real identity  i as an example to explain the specific registration process, which is shown in Figure 2.
The MTCD generates a secret value and a corresponding partial public key.It randomly selects a random number  ∈  as its secret value and calculates the partial public key   ⋅ .Then, it computes    ⋅  as the symmetric encryption key and sends its identity  i in a message to AMF.
2:  → /:  ,  AMF checks the identity of  and forwards that identity and the public key to AUSF.The anonymous identity  is generated by the AUSF, while the UDM stores the permanent identity . 3: / → :  Upon receiving  i , AUSF calculates the temporary anonymous identity   ⊕   ⋅  .AUSF then forwards  to AMF.Simultaneously, AUSF also forwards the identity  i to UDM, which is responsible for storing  i .(3) Initial authentication: All MTCDs, the AUSF, and the UDM perform the initial authentication following the 5G-AKA scheme.The gNB and AMF monitor the movement trajectory of each MTCD to determine if some MTCDs could form a group based on the grouping algorithm described in [24] that supports the mathematical correlation required to form an MTCD group.If such a correlation is found, these MTCDs will be considered as a group.The MTCD generates a secret value and a corresponding partial public key.It randomly selects a random number msk i ∈ Z q as its secret value and calculates the partial public key mpk i = msk i •P.Then, it computes δ = H 0 msk i •T pub as the symmetric encryption key and sends its identity ID i in a message to AMF.
Step-2 : AMF → AUSF/UDM : {ID i , mpk i } AMF checks the identity of MTCD and forwards that identity and the public key to AUSF.The anonymous identity ID is generated by the AUSF, while the UDM stores the permanent identity ID.
Step-3 : AUSF/UDM → AMF : {TID i } Upon receiving ID i , AUSF calculates the temporary anonymous identity TID = ID ⊕ H 1 (α•mpk i ).AUSF then forwards TID i to AMF.Simultaneously, AUSF also forwards the identity ID i to UDM, which is responsible for storing ID i .
Step-4 : AMF → MTCD : {TID i , mpk i , psk i , R i } δ AMF generates the secret value and a corresponding partial public key for MTCD.It randomly selects a random number After forwarding the message to MTCD i , MTCD i stores TID i , calculates h i1 , and verifies that psk i •p = R i + h i1 •T pub .It then sets PK i = {mpk i , R i } and SK i = {msk i , psk i } as the public-private key pair.The AMF sends the public key to the gNB, and the gNB uploads the public key pair to the blockchain.
(3) Initial authentication: All MTCDs, the AUSF, and the UDM perform the initial authentication following the 5G-AKA scheme.The gNB and AMF monitor the movement trajectory of each MTCD to determine if some MTCDs could form a group based on the grouping algorithm described in [24] that supports the mathematical correlation required to form an MTCD group.If such a correlation is found, these MTCDs will be considered as a group.

Handover Preparation
This phase occurs before the handover, preparing the necessary key materials for the first MTCD handover authentication and group handover authentication.This phase is shown in Figure 3. Step-

Handover Preparation
This phase occurs before the handover, preparing the necessary key materials for the first MTCD handover authentication and group handover authentication.This phase is shown in Figure 3.After receiving all TIDs from the group members, the AMF computes the group key   ∑  .The AMF encrypts the timestamp  f and generates the MAC as    | .This message is then broadcasted to the base stations.Upon receiving the message, the t-gNB queries the public key information of MTCDs stored in the blockchain within the group and stores the queried information locally. 3:   → MTCD: ,  ,  s-gNB broadcasts the message to all MTCDs within the group.Each MTCD decrypts the message to obtain the  and verifies the received message's timestamps and  to determine its authenticity.The s-gNB sends a handover request to the AMF containing the neighboring gNB list and the temporary identity identifiers TIDs of all group members.
Step-2 : After receiving all TIDs from the group members, the AMF computes the group key GID = H(∑ n i=1 TID).The AMF encrypts the timestamp TS f and generates the MAC as MAC = H GID |TS f .This message is then broadcasted to the base stations.Upon receiving the message, the t-gNB queries the public key information of MTCDs stored in the blockchain within the group and stores the queried information locally.
Step-3 : s-gNB → MTCD : GID, TS f δ , MAC s-gNB broadcasts the message to all MTCDs within the group.Each MTCD decrypts the message to obtain the GID and verifies the received message's timestamps and MAC to determine its authenticity.

First MTCD Handover Authentication
This phase involves one handover authentication that occurs when the first MTCD enters the range of the t-gNB.After the handover authentication of the first MTCD is successful, subsequent group handover authentication processes will be carried out.This phase is shown in Figure 4.
Step-3 : s-AMF → t-gNB : {GID, TS   When the handover authentication occurs within the same AMF, after receiving the handover request, s-AMF responds by sending the temporary identity identifiers TID 1 . . .TID i of all group members, along with the GID as the group key material, and forwards n 1 •P and Sig 1 to t-gNB.And after receiving the handover response from s-AMF, t-gNB queries the public key of MTCD 1 on the blockchain and calculates and if the equation holds, MTCD 1 's signature is successfully verified.t-gNB then selects a random number n t ∈ Z q and generates the session key K 1t = n 1 •n t •P.It also creates the signature Sig t = H 0 (GID, TID t , TS t , n t •P) and computes GID 1 = ∑ n i=2 H(TID i ) as the group key material to authenticate MTCD 1 .It then sends a message to MTCD 1 .
Step-5 : t-AMF → t-gNB : {GID, TS 1 , (TID 1 || . . .||TID i , n 1 •P, Sig 1 } Similarly, upon receiving the forwarded handover request, the t-AMF sends the temporary identity identifiers TID 1 . . .TID i of all group members, along with the GID as group key material, in response.It then forwards n 1 •P and Sig 1 to t-gNB.Upon receiving the message, the t-gNB proceeds with the verification. Step-6 : t-gNB → MTCD : {TID t , GID 1 , TS t , n t •P, Sig t } After receiving the message from t-gNB, MTCD 1 generates the signature Sig ′ t = H 0 (GID, TID t , TS t , n t •P).If Sig ′ t = Sig t , the identity verification of t-gNB is successful.Then, MTCD 1 generates the session key K 1t = n 1 •n t •P.At this point, the mutual authentication and key negotiation between MTCD 1 and t-gNB are complete.

Group Handover Authentication
MTCD 1 initiates an aggregated signature request to other group members in the group, broadcasting the temporary identity TID t of the t-gNB.MTCD 1 also sends its temporary identity TID 1 and the group key material GID 1 .Other members within the group verify the identity of MTCD 1 by validating GID = GID 1 + H(TID 1 ).
Step-1 : The group member MTCD i receives the aggregated signature request, verifies the identity of MTCD 1 , selects a random number n i ∈ Z q , generates its respective signatures, and sends its signature Sig i = h i3 msk i + n i + h i2 psk i .
Step-3 : After receiving the signatures from all group members, MTCD 1 calculates the aggregated signature Sig = ∑ n i=2 Sig i for the group and sends the aggregated signature to the t-gNB for performing group signature verification using the equation •T pub to pre-authenticate all group members.If the equation holds, the t-gNB verifies all MTCDs.Subsequently, t-gNB generates the session key K it = n i •n t •P between MTCD i and the t-gNB.
Step-4 : t-gNB → MTCD 1 : {TID t , TS t , n t •P, Sig t } The t-gNB verifies the signatures of the group members to authenticate their identities.If the identity authentication is successful, the t-gNB sends the timestamp TS t , random number n t •P, and its own signature Sig t = H 0 (GID, TID t , TS t , n t •P) to the MTCD 1 , because it has passed the first MTCD handover authentication already.
Step-5 : MTCD 1 → MTCD i : {TID t , TS 1 , TS t , n t •P, Sig t } After receiving the message from MTCD 1 , MTCD i generates the signature Sig ′ t = H 0 (GID, TID t , TS t , n t •P).If Sig ′ t = Sig t , the identity verification of t-gNB is successful.If the verification is successful, MTCD i generates the session key K it = n i •n t •P between MTCD i and the t-gNB.At this point, mutual authentication and key negotiation between MTCD i and t-gNB are complete.This phase is shown in Figure 5.

Group Handover Authentication
1 initiates an aggregated signature request to other group members in the group, broadcasting the temporary identity  t of the t-gNB. 1 also sends its temporary identity  1 and the group key material  1 .Other members within the group verify the identity of  1 by validating   1   1 .

Security Evaluation
In this section, we first prove the logic correctness of the proposed BSPGH scheme by using BAN logic and perform a formal verification of the security functionality of the BSPGH protocol by using the Scyther.Furthermore, a security analysis is conducted to identify security properties held by the BSPGH protocol and its robustness against various malicious attacks is described.The results can provide insights into the protocol's effectiveness and capacity to resist various threats.

Formal Proof by BAN Logic
BAN logic is an important method for the formal analysis of security protocols [25], aiming to verify their security and correctness.The fundamental principle of BAN logic is to establish a set of rigorous logical rules to describe the semantics of entities, message exchange, and information states involved in the protocol.To apply BAN logic to prove the BSPGH protocol, we formalize the protocol into an idealized form.We then propose assumptions and objectives and use BAN logic symbols and rules for derivation, such as message meaning rules, temporary value validation rules, arbitration rules, belief rules, and reception rules.By manually applying the derivation rules, we aim to achieve the objectives and verify the security properties of the protocol.
The rules of BAN logic for derivation can be described as follows: (R1) The Message Meaning Rule: . The first means that if party P trusts that K is a shared key between P and Q, and if P has received a message X encrypted with K before, then P believes that Q has sent the message X.The second means that if P believes that user Q's public key is K, and P sees that the message X, which is signed with Q's private key, is K −1 , then P believes that the message X was sent by Q.The third means describes the shared secret.
(R2) The Freshness Rule: P|≡#(X,Y) .This rule means that if one part of the message is fresh, then the entire message is fresh.
(R3) The Nonce Verification Rule: P|≡#(X),P|≡Q|∼X P|≡Q|≡X . This rule means that if P believes that message X is fresh and believes that Q has sent X before, then P believes that Q believes X.
(R4) The Belief Conjunction Rule: P|≡X .This rule means that if P believes that party Q believes messages X and Y, then P believes that Q believes X.
(R5) The Jurisdiction Rule: Using the rules, assumptions, and messages, the detailed proof is as follows: According to R1 and considering A12 and M6, we can deduce According to R2 and considering A6, we can deduce According to R3 and considering ( 2) and ( 3), we can deduce According to R4 and considering (4), we can deduce According to R5, along with A8 and (5), we can deduce According to the R1 and considering A11 and M7, we can deduce According to R2 and considering A5, we can deduce According to R3 and considering ( 7) and ( 8), we can deduce According to R4 and considering (9), we can deduce According to R5 and considering (10) and A7, we can deduce According to R4 and considering (6) and A3, we can deduce Since n 1 •n t •p is the shared key K 1t , between MTCD 1 and t-gNB; therefore, according to Equation (12), we can deduce: According to R4 and considering (11) and A1, we can deduce As mentioned above, according to (14), we can deduce Furthermore, to complete the process, t-gNB receives M6 and verifies it.It must trust M6 to proceed with the protocol and send M7.Therefore, if MTCD 1 has already received M7, MTCD 1 can infer that t-gNB already trusts M6. n 1 •p is included in M6.Therefore, we can deduce According to R4 and considering ( 16) and A9, we can deduce As mentioned above, according to M7 and M8, we can deduce According to R4 and considering (18) and A10, we can deduce According to R1 and considering M10 and A12, we can deduce According to R4 and considering (22), we can deduce According to R5 and considering (23) and A8, we can deduce According to R1 and considering M12 and A11, we can deduce According to R2 and considering A5, we can deduce According to R3 and considering ( 25) and ( 26), we can deduce According to R4 and considering (27), we can deduce According to R5 and considering (28) and A7, we can deduce According to R4 and considering (29) and A1, we can deduce As mentioned above, according to (30), we can deduce According to R4 and considering (31) and A3, we can deduce As mentioned above, according to (32), we can deduce Similar to MTCD 1 , t-gNB also receives M10 first, and it must trust M10 in order to proceed with the protocol and send M12.If MTCD i has already received M12, then MTCD i can conclude that t-gNB now trusts M10.According to M10 and M12, we can deduce According to R4 and considering (34) and A9, we can deduce Likewise, based on M12, after MTCD i verifies the identity of t-gNB without errors, it generates a session key for subsequent communication.From this, we can deduce According to R4 and considering (36) and A10, we can deduce In summary, we have achieved all the security objectives, ensuring key negotiation and mutual authentication in the protocol.Our protocol has been logically validated.

Formal Verification
Scyther Tool is a formal verification tool commonly used for validating security protocols [26].Scyther offers four security statements to ensure protocol consistency and detect various attacks like message forgery, replay, and man-in-the-middle (MITM).These include "Aliveness" for completing protocol steps with active responders, "Niagree" for the correct variable receipt without one-to-one communication, "Nisynch" for the expected protocol operation without one-to-one synchronization, and "Weakagree" for one-to-one communication within the same group of initiators or responders.
The verification results are shown in Figure 6, where Figure 6a demonstrates the first MTCD handover authentication phase, and Figure 6b demonstrates the group handover authentication phase.Specifically, the model is created with three roles: t-gNB, MTCD i , and MTCD 1 .Initially, the BSPGH scheme achieves mutual key agreement using the Elliptic Curve Diffie-Hellman (ECDH).To simulate the ECDH key exchange between two parties, two functions are defined as g1 and g2.Then, n 1 •P is set to g1(n1), n i •P is set to g1(ni), and n t •P is set to g1(nt).The confidentiality of the ECDH private keys is first verified using the declarations of Secret n1, Secret ni, and Secret nt.Next, the derivation of ECDH public keys is performed using K1t (i.e., g2(nt, g1(n1))) and Kit (i.e., g2(nt, g1(ni))).The confidentiality of the ECDH private keys is ensured by declaring Secret ni, Secret nt, and Secret n1.Additionally, the confidentiality of the ECDH public key is validated by the SKR declaration.Our protocol assumes that MTCD i needs to use the group key GID to verify the identity of MTCD 1 .To ensure that adversaries cannot obtain the group key GID in any way, its secrecy is checked using the Secret GID declaration.Finally, the verification results reveal that all participants in the system satisfy the properties of synchronous (Nisynch), consistent (Niagree), active (Alive), and weak consistency (Weakagree).All the keys meet the security requirements.Therefore, our protocol is deemed secure by the verification using Scyther.

Security Analysis 
Mutual Authentication: By the BSPGH scheme, a gNB verifies the authenticity of the MTCD's signature  by retrieving the public key stored on the blockchain, thereby confirming the identity of the MTCD.Since digital signatures are generated by encrypting messages with a private key and it is computationally infeasible to deduce the private key from the public key, this way allows the MTCD to effectively prove the legitimacy of its authentication request to the gNB.Furthermore, the gNB employs hash-based message authentication code (HMAC) scheme and uses the group key  as the key for the HMAC to generate a signature  .The MTCD, possessing a legitimate , verifies  to prove the legitimacy of the response.In this way, the MTCD and the gNB are able to achieve mutual authentication, ensuring the security of the communication between them. Privacy protection: The temporary identity identifier  is transmitted to each

Security Analysis
• Mutual Authentication: By the BSPGH scheme, a gNB verifies the authenticity of the MTCD's signature Sig by retrieving the public key stored on the blockchain, thereby confirming the identity of the MTCD.Since digital signatures are generated by encrypting messages with a private key and it is computationally infeasible to deduce the private key from the public key, this way allows the MTCD to effectively prove the legitimacy of its authentication request to the gNB.Furthermore, the gNB employs hash-based message authentication code (HMAC) scheme and uses the group key GID as the key for the HMAC to generate a signature Sig t .The MTCD, possessing a legitimate GID, verifies Sig t to prove the legitimacy of the response.In this way, the MTCD and the gNB are able to achieve mutual authentication, ensuring the security of the communication between them.

•
Privacy protection: The temporary identity identifier TID i is transmitted to each participant over the wireless channel, ensuring that the real identity is only disclosed to legitimate gNBs and the core network.It satisfies anonymity requirements.

•
Perfect forward secrecy and backward secrecy: By the proposed protocol, the generation of the session key K it relies on randomly generated ECDH parameters.Without the session key, attackers cannot recover the contents of a specific session.Moreover, since a session key is generated for each session and the ECDH parameters for each session key are independent of those from previous or future sessions, the leakage of a session key would only affect the current session.The confidentiality of previous or future sessions would remain unaffected.

•
Replay and impersonation attacks resistance: By the proposed protocol, authentication requests and responses are both marked with a timestamp TS.The TS constraint ensures that messages are received within a specified time window, allowing easy identification.The replayed messages will be discarded, thus, countering replay attacks.The use of a key system based on discrete logarithms makes deriving private keys from the public keys challenging, preventing attackers from forging signatures and thus impersonating legitimate identities.It can effectively strengthen the ability of the protocol to resist impersonation attacks.

• DoS/DDoS attacks resistance:
The receiving gNB first verifies the timestamp's validity and then compares the signature with records in the blockchain for authentication.If they do not match, the session is immediately terminated, preventing attackers from consuming gNB's computational resources through replay attacks.The failure of one gNB or one AMF will not affect the entire 5G wireless network.Therefore, it can prevent DDoS attacks in 5G authentication.

•
Session key leakage: Attackers may attempt to compute the session key to steal messages transmitted over the wireless channel.However, the session key is formed based on ECDH by the proposed scheme, which relies on the difficulty of the elliptic curve discrete logarithm problem.Attackers cannot obtain n i and n t from n i •p and n t •p, and thus cannot compute the session key n i •n t •p.It effectively prevents session key leakage.

•
Sybil attack: By the proposed protocol, a private blockchain is utilized.Within a private blockchain, access and participation in the network are restricted, allowing only MTCDs that have been registered by core network entities to join and interact.Furthermore, the identities of MTCDs must be verified subsequently, which limits the ability of attackers to forge numerous identities to conduct attacks.Therefore, this approach is capable of resisting Sybil attacks, where an attacker creates a large number of pseudonymous identities to compromise the network.

•
Man-in-the-middle attack: By the BSPGH scheme, an adversary cannot impersonate a legitimate t-gNB to deceive an MTCD because a temporary session key K it is established between them using the ECDH.The adversary cannot obtain or modify the temporary session key; thus, it is unable to establish communication with the MTCD.

•
Linkability attack prevention: In the BSPGH authentication process, the PK and TID are periodically updated, while the elements in other messages are random numbers.BSPGH employs ECDH for session key generation instead of using serial numbers, which prevents the common MAC failures or synchronization issues found in symmetric key-based AKA protocols.This approach makes it difficult for attackers to analyze the correlation between different messages or to exploit erroneous messages as vulnerabilities to track a specific device.Consequently, BSPGH effectively safeguards against linkability attacks, enhancing privacy and security in the communication process.

Performance Evaluation
In this section, we evaluated the performance of the BSPGH scheme in terms of computational cost and communication cost during the first handover authentication and group handover authentication phases and compare its performance with those of three other protocols, namely, 5G standard specified by 3GPP TS 23.501 R16 [21], a privacypreserving handover authentication protocol for a group of MTC devices in 5G networks (PPHAP) [1], and a novel authentication scheme supporting multiple user access for 5G and beyond (NASS) [7].In the analysis, it is assumed that all symmetric encryption keys are 256 bits, MACs are 160 bits, and elements in the Hash functions, TID, GID, Sig, n•P, and Z * q are 128 bits.The timestamp is represented by 32 bits, and elements in group G have sizes of 320 bits.

Blockchain Operation Cost
To evaluate the data access latency in the blockchain, we followed the evaluation methodology outlined in [27].Initially, a blockchain prototype was created.This blockchain comprised numerous blocks, each being 1 MB in size.Every block, stored as a file, contained multiple transaction records, with each transaction being a subscription record of a device.To reduce the storage overhead of the blockchain, this size should be adjusted according to the preferences of the network operators.By default, we followed the Bitcoin model with a block size of 1 MB.All transactions in the blockchain were indexed using Python dictionaries.To compare the performance differences between the blockchain and traditional databases, another centralized database was also constructed using MariaDB v10.4.14 [28].The read operation T BC.read is 0.2914 ms and the write operation T BC.write is 0.0434 ms, while for the centralized database, both of the read and write operations T DB are 0.4956 ms.
By the proposed scheme, since the writing and querying operations of the blockchain information occur prior to the two phases of handover authentication, specifically during the registration phase and the handover preparation phase, the time taken for blockchain operations has not been included in the computational costs of the first handover authentication and group handover authentication phases.

Computational Cost
We utilize a device equipped with an Intel(R) Core (TM) i7-12700H processor running at 3.50 GHz and 16 GB of RAMs for the evaluation of the computational cost of the two phases of handover authentication.The cryptographic library employed to perform the required cryptographic operations of the proposed scheme was C/C++ OPENSSL.For the selected protocols, each protocol uses different encryption functions with unique key size requirements.To assess their performance comprehensively and fairly at the same security level, we follow the recommendation of NIST in [28] and use a 256-bit equivalent key strength throughout the entire simulation process.Therefore, for all operations based on ECC, secp256k1 is selected as the default elliptic curve.We run each encryption function 10,000 times to measure its average execution time.The measurement results obtained follow.The point multiplication T PM is 0.201 ms.The point addition T PA is 0.001 ms.The modular exponentiation T E is 0.665 ms.The Rivest-Shamir-Adleman (RSA) signature and verification T RV is 1.445 ms.The hash operation T H is 0.021 ms.The symmetric encryption/decryption operation T A is 0.02 ms.XOR, multiplication, and arithmetic operations have been neglected.The results are presented in Table 2, where T MTCD and T gNB represent the computation time for the MTCD and the gNB, respectively.We have only accounted for the operations during the first MTCD handover authentication and the group handover authentication of the BSPGH scheme.In Table 2, "n" represents the number of MTCD to substitute specific numerical values.For the 5G-AKA scheme, the computation costs are 0.126n ms.For the PPHAP scheme, the computation costs are 0.205n-0.063ms.For the NASS scheme, the computation costs are 1.466n + 2.775 ms.For the BSPGH scheme, the computation costs are 1.155n + 1.068 ms.The NASS scheme involves complete RSA verification for handover authentication, which increases the overhead.The PPHAP scheme primarily uses symmetric encryption and hash operations for authentication, resulting in lower computational overhead but posing a risk of DDoS attacks.The 5G-AKA scheme has the lowest computational overhead but has serious security vulnerabilities.In contrast, the proposed BSPGH scheme is the most secure in terms of security functionality and has lower overhead compared to the NASS scheme.Overall, the BSPGH scheme has been proven to be the most effective.

Communication Cost
The communication costs for n MTCDs to perform handover authentication by the BSPGH scheme are evaluated and compared with the other three protocols.The communication costs include propagation time and transmission time.The propagation time is determined by the distance between the transmitter and the receiver and the propagation speed over the wireless communication channel, which is approximately 3 × 10 8 m/s.It is assumed that the radius of a cell is 200 m, and the data packets sent by an MTCD would take 200 m to propagate to the gNB at a speed of 3 × 10 8 m/s.According to the 3GPP standard on 5G communication, the downlink data rate for the urban general area scenario is 50 Mbps, and the uplink data rate is 25 Mbps [29].In Table 3, "Amount of Information" refers to the total amount of data transmitted during the communication process.T t and T p represent transmission delay and propagation delay, respectively."Up" and "Down" denote uplink and downlink data transmission.Therefore, we compare them separately.When calculating communication costs, we consider only the authentication phases during the handover, including the first MTCD handover authentication, group handover authentication.Figure 7 demonstrates that when there is a large number of group MTCDs, the proposed BSPGH scheme exhibits superior performance in terms of communication overhead compared to the PPHAP and the NASS scheme.This advantage is attributed to the reduced information exchanged between MTCDs and gNBs in our protocol, leading to enhanced efficiency.In contrast, the communication overhead of the 5G-AKA scheme is lower, but it suffers from a lot of security vulnerabilities.Overall, the results indicate the better performance achieved by the BSPGH scheme.

Authentication Cost
Figure 8 shows the total time cost of the handover authentications for n MTCDs within a group.The comparison of four handover authentication schemes is as follows.The NASS scheme needs a far higher handover authentication cost compared to the BSPGH scheme, due to the involvement of complete RSA signature verification and modular exponentiation for computation and a higher communication cost during the authentication process; thus, it increases the overall latency.The PPHAP scheme has a lower handover authentication time cost, while the BSPGH scheme provides enhanced security features in mitigating DDoS attacks.The 5G-AKA scheme has a lower latency but suffers from serious security vulnerabilities.Therefore, although the BSPGH protocol inevitably introduces a minor computational overhead, it remains the most effective protocol in balancing the security functionality and system performance.

Authentication Cost
Figure 8 shows the total time cost of the handover authentications for n MTCDs within a group.The comparison of four handover authentication schemes is as follows.The NASS scheme needs a far higher handover authentication cost compared to the BSPGH scheme, due to the involvement of complete RSA signature verification and modular exponentiation for computation and a higher communication cost during the authentication process; thus, it increases the overall latency.The PPHAP scheme has a lower handover authentication time cost, while the BSPGH scheme provides enhanced security features in mitigating DDoS attacks.The 5G-AKA scheme has a lower latency but suffers from serious security vulnerabilities.Therefore, although the BSPGH protocol inevitably introduces a minor computational overhead, it remains the most effective protocol in balancing the security functionality and system performance.

Authentication Cost
Figure 8 shows the total time cost of the handover authentications for n MTCDs within a group.The comparison of four handover authentication schemes is as follows.The NASS scheme needs a far higher handover authentication cost compared to the BSPGH scheme, due to the involvement of complete RSA signature verification and modular exponentiation for computation and a higher communication cost during the authentication process; thus, it increases the overall latency.The PPHAP scheme has a lower handover authentication time cost, while the BSPGH scheme provides enhanced security features in mitigating DDoS attacks.The 5G-AKA scheme has a lower latency but suffers from serious security vulnerabilities.Therefore, although the BSPGH protocol inevitably introduces a minor computational overhead, it remains the most effective protocol in balancing the security functionality and system performance.We assess the robustness of the protocol for estimating the robustness of handover authentication.In the system, handover authentication may be forced to stop and restart when facing unknown attacks.We assume that unknown attacks can occur at each step of the handover authentication, and the probability of unknown attacks is uniform [1].The average time of successful handover authentication is calculated as follows: where T, T success , and T f ailed are the average time taken for a successful handover authentication, the total time of successful handover authentications, and the total time for failed handover authentications, respectively, N success is the number of successful handover authentications, p is the percentage of unknown attacks, n is the number of steps in the protocol, t fail represents the total time cost before the attack happens in the i-th step, and t success represents the time elapsed for one successful handover authentication before an attack occurs.
The simulation results of comparison with a group size of 30 MTCDs are shown as in Figure 9, when the percentage of unknown attacks increases.It is evident that the BSPGH protocol has a lower total time cost compared to NASS, indicating a better performance.However, it has a higher time cost compared to the solutions of the 5G standard and the PPHAP scheme.This is because that the 5G standard and the PPHAP scheme use a symmetric cryptographic system and have suffered security vulnerabilities.As shown in Figure 6, our proposed protocol can resist most major malicious attacks, albeit with a slightly higher total time cost.Overall, the proposed BSPGH scheme demonstrates a better performance in terms of security functionality and system efficiency.We assess the robustness of the protocol for estimating the robustness of handover authentication.In the system, handover authentication may be forced to stop and restart when facing unknown attacks.We assume that unknown attacks can occur at each step of the handover authentication, and the probability of unknown attacks is uniform [1].The average time of successful handover authentication is calculated as follows: where ,  success , and  failed are the average time taken for a successful handover authentication, the total time of successful handover authentications, and the total time for failed handover authentications, respectively,  is the number of successful handover authentications,  is the percentage of unknown attacks,  is the number of steps in the protocol,  fail represents the total time cost before the attack happens in the i-th step, and  success represents the time elapsed for one successful handover authentication before an attack occurs.
The simulation results of comparison with a group size of 30 MTCDs are shown as in Figure 9, when the percentage of unknown attacks increases.It is evident that the BSPGH protocol has a lower total time cost compared to NASS, indicating a better performance.However, it has a higher time cost compared to the solutions of the 5G standard and the PPHAP scheme.This is because that the 5G standard and the PPHAP scheme use a symmetric cryptographic system and have suffered security vulnerabilities.As shown in Figure 6, our proposed protocol can resist most major malicious attacks, albeit with a slightly higher total time cost.Overall, the proposed BSPGH scheme demonstrates a better performance in terms of security functionality and system efficiency.

Energy Consumption
The security protocols that offer the highest level of security functionality while consuming the least amount of energy are always the preferred choice due to the limited battery life of mobile devices like MTCDs.To evaluate the energy consumption of MTCDs, two factors should be considered including the energy required for data transmission and the energy consumed for the execution of the cryptographic functions.For the energy used for data transmission, the evaluation of energy consumption follows the data

Energy Consumption
The security protocols that offer the highest level of security functionality while consuming the least amount of energy are always the preferred choice due to the limited battery life of mobile devices like MTCDs.To evaluate the energy consumption of MTCDs, two factors should be considered including the energy required for data transmission and the energy consumed for the execution of the cryptographic functions.For the energy used for data transmission, the evaluation of energy consumption follows the data transmission power model described in [28].The calculation of the transmission energy cost for the uplink and downlink is as follows: For the energy used for performing cryptographic functions, the way of approximation of energy cost in [30] is adopted.All experiments were conducted using a battery-powered Compaq iPAQ H3670 PDA, which is equipped with an Intel SA-1110 StrongARM processor running at 206 MHz, 64 MB RAM, and 16 MB FlashROM for evaluation.The energy cost of a single AES encryption or decryption operation is 7.87 + 1.21b µJ, where b is the number of bytes in the plaintext.The energy cost per byte for a SHA-1 hash operation E H is 0.76 µJ.Considering that the energy cost for generating an ECDH public key is 276.7 mJ and for deriving an ECDH public key is 163.5 mJ, the energy consumption for a single scalar multiplication operation E PM is approximately estimated to be 220.1 mJ, and the energy cost for a single RSA operation E RV is 832.6 mJ.The energy consumption of using cryptographic primitives is derived based on the cryptographic operations used in the protocol, leading to a theoretical energy cost.
Figure 10 illustrates the relationship between the energy consumption during handover authentication and the number of MTCDs in a group.It is clearly visible from the figure that, compared to the NASS protocol, the energy consumption of BSPGH is lower and more efficient as the number of MTCDs increases.Additionally, the energy consumption of the 5G and PPHAP protocols is lower than our protocol.However, the 5G standard protocol has security issues and is susceptible to different malicious attacks, while the PPHAP protocol is also vulnerable to security threats like DDoS attacks.On the other hand, the BSPGH protocol can significantly enhance network security, albeit at a slightly higher cost compared to other protocols.It can also facilitate group handover authentication for a large number of users simultaneously.Therefore, the BSPGH protocol exhibits a better performance in terms of both security and efficiency.
Sensors 2024, 24, x FOR PEER REVIEW 24 of 27 transmission power model described in [28].The calculation of the transmission energy cost for the uplink and downlink is as follows: For the energy used for performing cryptographic functions, the way of approximation of energy cost in [30] is adopted.All experiments were conducted using a batterypowered Compaq iPAQ H3670 PDA, which is equipped with an Intel SA-1110 Stron-gARM processor running at 206 MHz, 64 MB RAM, and 16 MB FlashROM for evaluation.The energy cost of a single AES encryption or decryption operation is 7.87 1.21 µJ, where  is the number of bytes in the plaintext.The energy cost per byte for a SHA-1 hash operation  is 0.76 µJ.Considering that the energy cost for generating an ECDH public key is 276.7 mJ and for deriving an ECDH public key is 163.5 mJ, the energy consumption for a single scalar multiplication operation  is approximately estimated to be 220.1 mJ, and the energy cost for a single RSA operation  is 832.6 mJ.The energy consumption of using cryptographic primitives is derived based on the cryptographic operations used in the protocol, leading to a theoretical energy cost.
Figure 10 illustrates the relationship between the energy consumption during handover authentication and the number of MTCDs in a group.It is clearly visible from the figure that, compared to the NASS protocol, the energy consumption of BSPGH is lower and more efficient as the number of MTCDs increases.Additionally, the energy consumption of the 5G and PPHAP protocols is lower than our protocol.However, the 5G standard protocol has security issues and is susceptible to different malicious attacks, while the PPHAP protocol is also vulnerable to security threats like DDoS attacks.On the other hand, the BSPGH protocol can significantly enhance network security, albeit at a slightly higher cost compared to other protocols.It can also facilitate group handover authentication for a large number of users simultaneously.Therefore, the BSPGH protocol exhibits a better performance in terms of both security and efficiency.aims to reduce the authentication time when multiple MTCDs undergo frequent handovers between gNBs by adopting group handover authentication.The proposed BSPGH scheme requires no modification to the existing 5G network architecture specified by the 3GPP standard, making it easy to deploy.By formal verification using Scyther Tool and BAN-logic, we have analyzed the protocol's security properties, demonstrating that it can provide perfect forward secrecy and resist impersonation attacks, DoS/DDoS attacks, and some other attacks.It also ensures the anonymity of the MTCDs.Moreover, the performance analysis has shown that the BSPGH scheme can meet the requirements of various application scenarios to confirm its efficiency.

𝑆𝑡𝑒𝑝 4 :
→ M:  ,  ,  ,  AMF generates the secret value and a corresponding partial public key for MTCD.It randomly selects a random number  ∈  , calculates   ⋅  , ℎ   ,  ,  ,  , and    ⋅ ℎ , then computes    ⋅  .After forwarding the message to  ,  stores  , calculates ℎ , and verifies that  ⋅   ℎ ⋅  .It then sets   ,  and   ,  as the public-private key pair.The AMF sends the public key to the gNB, and the gNB uploads the public key pair to the blockchain.

Sensors 2024 ,
24, x FOR PEER REVIEW 18 of 27(a) The first MTCD handover authentication (b) The group handover authentication

Figure 8 .
Figure 8.Comparison of the authentication cost.

Figure 7 .
Figure 7.Comparison of communication cost.

Figure 8 .
Figure 8.Comparison of the authentication cost.

Figure 8 .
Figure 8.Comparison of the authentication cost.

Figure 9 .
Figure 9.Comparison of the authentication cost for 30 MTCDs with unknown attacks.

Figure 9 .
Figure 9.Comparison of the authentication cost for 30 MTCDs with unknown attacks.
mW/Mbps , α 51.97 mW/Mbps , β 1288.04 mW ,  25 Mbps , and  50 Mbps . represents the uplink throughput,  represents the downlink throughput,  is the transmission time for uplink, and  is the transmission time for downlink.

Figure 10 .
Figure 10.Comparison of the energy consumption.Figure 10.Comparison of the energy consumption.

Figure 10 .
Figure 10.Comparison of the energy consumption.Figure 10.Comparison of the energy consumption.

Table 1 .
Notations and definition of the proposed protocol.
it /K 1t The session key of MTCD and gNB G Cyclic additive group P/q Generator of the group/prime order of group PK/SK Public key/private key {x} k Encrypted x with key k

Registration Request 2.Anonymous Identity Generation Request TID i 3.Anonymous Identity Generation Response Calculate TID i Store ID i 4.Registration Response {mpk i ,{ID i ,mpk i } δ } ID i, mpk i {TID i ,mpk i ,psk i ,R i } δ Figure
2. Initial registration.

Table 2 .
Computational costs of different protocols.

Table 3 .
Communication costs of different protocols.