Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Sep 25, 2023
Content may be subject to copyright.
A Secure Blockchain-based Authentication and Key
Agreement Protocol for 5G Roaming
Awaneesh Kumar Yadav∗, Manoj Misra†, An Braeken‡, Madhusanka Liyanage§
∗† Dept. of Computer Science and Engineering, Indian Institute of Technology Roorkee, Uttarakhand, India.
‡Department of engineering, technology (INDI), Vrije Universiteit Brussel, Belgium.
§School of Computer Science, University College Dublin, Ireland
Email:∗akumaryadav@cs.iitr.ac.in, †manoj.misra@cs.iitr.ac.in, ‡an.braeken@vub.be, §madhusanka@ucd.ie
Abstract—The fifth generation (5G) is now widely used to access
network services due to the emergence of the Internet of Things
(IoT) and mobile devices. To secure 5G communication, the Third
Generation Partnership Project (3GPP) organization created the
5G-Authentication and Key Agreement (AKA) protocol. Security
evaluations have found a number of problems in the 5G-AKA,
including a violation of perfect forward secrecy, a traceability
attack, and denial of service (DoS) attacks. To address the
shortcomings of 5G-AKA, several enhanced versions have been
developed. However, it has been shown that either these versions
are expensive or do not address security issues. Additionally, less
effort is put into providing security when a user utilizes roaming
mobile services while a malicious Serving Network (SN) is present.
This paper introduces an authentication mechanism to handle the
above issues. In addition to this, a handover mechanism is also
designed for re-connection. The authentication and handover phase
security assessment uses the mathematical model Real-Or-Random
(ROR), AVISPA, and Scyther tool. Furthermore, the performance
comparison depicts that the authentication and handover phase is
more efficient than existing protocols. An assessment of the smart
contract function’s cost and effectiveness is also provided.
Keywords—Authentication, AVISPA tool, Blockchain, Elliptic
Curve-Cryptography (ECC), Internet of Things (IoT), Scyther tool,
ROR logic.
I. INTRODUCTION
The Internet of Things (IoT) is the integration of many
physical items, including sensors, mobile phones, cars, RFID
tags, and other electronic-integrated gadgets, as well as the
network connectivity that enables these objects to communicate
and exchange data [1]. It offers a wide range of applications
in a number of areas, including smart cities, smart healthcare,
intelligent transportation, industrial automation, and disaster
response. According to the predictions shown in [2], there
will be 30.9 billion linked devices worldwide by 2025. It is
noticed that some IoT application areas, such as automotive
networks, smart environments, e-health care systems, etc., call
for more significant data rates, wide bandwidths, increased
capacities, low latency, high mobility, and higher throughput. As
a result, the 5G cellular network, the fifth generation of wireless
technology with increased capacity, lower latency, and wider
connection, is expected to become the dominant communication
platform for IoT deployments in the future. Additionally, the
5G technology has a number of IoT use significantly beneficial
cases. It is seen that millions of IoT devices are anticipated to
be connected to the 5G cellular network per square kilometer in
the near future [4]. The 3GPP committee has given a standard
for the 5G technology named 5G-AKA that addresses the issues
of 4G technology. Compared to 4G, 5G-design AKA’s is more
sophisticated because of massive Machine type communication
(mMTC), which is made by entities, namely Narrowband IoT
and Long term progression Cat-M1 [3]. However, it is shown
by some recent studies that 5G-AKA has several weaknesses
[1], [2], [4]–[6]. To cater to these weaknesses, various security
protocols are designed. It has been noted that a secure channel
is considered between the Serving Network (SN) and Home
Network (HN) during the authentication requests. As a result,
the authentication mechanism that is based on this premise
cannot supply the services in roaming scenarios. The current
status of 5G authentication demonstrates that protocols [6],
[7] are only applicable when an insecure channel is con-
sidered during the communication between the SN and HN.
The protocols use blockchain technology to solve this issue.
However, in [8], the authors demonstrated that the protocol of
[6] is vulnerable to several severe attacks and that the protocol
of [7] is very expensive. Therefore, developing an adequate
authentication method that provides authentication services in
roaming scenarios is imperative.
A. Motivation & Contributions
In the literature review, we found various articles [1]–[7],
[9]–[12] discussing the 5G-AKA authentication mechanism.
However, few studies concentrate on IoT devices that enter
a cell outside of the HN coverage region and engage in
roaming scenarios. According to the most recent study on
5G authentication, only the protocols of [6], [7] are suitable
in an environment where an insecure channel is required for
SN and HN authentication. To address this issue and to offer
protection against a malicious SN and the DoS attack, [6],
[7] use blockchain technology. However, [6] is vulnerable to
the impersonation attack and incapable of providing perfect
forward secrecy, according to security checks of [8]. On the
other side, [7] is very expensive and inefficient for resource-
constrained IoT devices since it relies on RSA encryption. In
addition to this, [1]–[7], [9], [10], [12] do not provide any
mechanism for re-connection (i.e., when UE is detached from
the SN during the authentication and wants to reconnect again,
SN will connect them directly based on re-connection secrets
without the involvement of HN.), except [11]. However, in [13],
it is demonstrated that [11] is vulnerable to various attacks.
Handover authentication is needed because it is less expensive
compared to authentication since HN is not involved in the
process.
In order to overcome the security issues raised above while
still accounting for an insecure route between the SN and
HN, this study tries to create an authentication and handover
mechanism.
Our contributions are as follows:
•This paper offers an ECC-based authentication solution for
5G communication using blockchain technology to address
the aforementioned issues.
•A handover mechanism is created to reduce the connection
cost.
•The security of the authentication and handover mecha-
nism is validated through AVISPA, the Scyther validation
tool, and the ROR logic.
•It is demonstrated through comparative research and com-
parison that authentication and handover mechanisms are
more effective than current ones.
•The evaluation of transaction and execution costs shows
that new authentication mechanisms outperform existing
ones.
II. PRELIMINARIES AND BACKGROUNDS
The system model for the 5G network, the threat model, and
an overview of the Blockchain technology used in the proposed
work are described in this section.
A. System model for the 5G
The proposed protocol defines a 5G network model with four
participants. For the proposed model, we use a setup that is
similar to that of [6], [7]. The involved parties are described in
the following manner.
•User Equipment (UE): UE denotes the smartphone or any
other IoT gadgets that the user utilizes for the 5G services.
The Universal-Subscriber Identity Module (USIM) is on a
Universal-Integrated circuit card (UICC) attached to each
UE. The pre-saved secrets and authentication keys are kept
in the USIM.
•Serving Network (SN): There are two entities involved
in the SN: 1) gNB, used to facilitate the coverage
through the radio-access-network, and 2) Security-Anchor-
Function (SEAF), utilized as a bridge between the UE and
HN.
•Blockchain: All the home networks update their informa-
tion into the blockchain. When UE requests SN for the
connection, SEAF communicates with the blockchain to
get the information. On the other side, the smart contract
is called to verify the freshness of the requests. If it is
fresh/new, then it provides the information. The same thing
is performed when HN sends the response to the SN.
•Home Network (HN): The four components of HN are
as follows: 1) Authentication Secure Function (AUSF):
for facilitating the authentication services to the UE, 2)
Unified Data Management (UDM): to store the data re-
lated to the authentication, 3) Authentication-Credentials
and Repository-Processing Function (ARPF): for choosing
the authentication method based on UE’s policy, and 4)
Subscription Identity De-concealing Function (SIDF): in
order to decrypt the SUCI.
AUSF ARPF
UDM SIDF
Home Network (HN1)
gNB SEAF+AMF
Serving Network (SN)
(gNB+AMF+SEAF)
User Equipment (UEj)
(ME+USIM)
AUSF ARPF
UDM SIDF
Home Network (HN2)
AUSF ARPF
UDM SIDF
Home Network (HN3)
AUSF ARPF
UDM SIDF
Home Network (HNj)
AUSF ARPF
UDM SIDF
Home Network (HNn)
1
2
3
4
5
6
5G-Core Network
Blockchain- Smart contract (SC)
Fig. 1: System model for the 5G.
The insecure channel is utilized during the authentication and
handover phase between the 5G model participants.
B. Threat Model
The prominent Dolev-Yao (DY) [14], and Canetti–Krawczyk
(CK) and extended CK (eCK) adversary [15] threat models are
adopted during the design of the authentication and handover
mechanisms. According to the assumptions of these threat
models, the attacker can intercept the exchange of messages,
actively alter, delete, insert (certain sections), and learn the long-
term private key of the UE, SN, and HN to launch the attacks.
C. Blockchain Technology
It is considered the base for an unalterable distributed ledger.
It is seen that the second version of this technology facili-
tates the execution of smart contracts that are pre-programmed
transactions [16]. It is seen that blockchain can work as a
barrier in 5G communication where the SN and HN require an
insecure channel during the message exchange. This can help
to mitigate the DoS attack possibility on the HN and protect the
UE’s identity by preventing access from malicious SNs that the
active attackers execute. Additionally, it keeps a tamper-proof,
auditable record of the authentication processes. To prevent the
DoS attack, we employ the additional blockchain layer between
the SN and HN, where HN updates all the information and uses
the blockchain-based smart card function, which is computer
code that launches itself when specific criteria are met during
the authentication. This is based on simple ”if/when...then”
clauses recorded in code on a blockchain that makes up smart
contracts. This task is performed by the network of computers
when the specified conditions are examined and verified [6].
III. PROP OS ED PROTOCOL
This section describes the authentication and key agreement
protocol for the scenario where UE enters a different cell and
wants to communicate (i.e., roaming scenario). In addition, a
handover phase is also proposed so that UE can reconnect with
the SN if he gets disconnected from the SN. The proposed
authentication and key agreement protocol uses the combination
of ECC and hash function so that UE can prove its authenticity
and securely generate the session key with the SN. Conversely,
the handover phase uses the symmetric encryption mechanism
for secure communication. We also use the blockchain, where
all the HNs enter their subscription information, through which
SN can get the information and connect to the respective HN
for authentication.
A. Initialization
Our proposed protocol follows the blockchain approach as
used in [6], [7], where each HN develops its own smart contract
and places it on a public blockchain that is publicly available,
allowing any SN to use the services and offers roaming services
to a new HN subscriber. Because a public blockchain is being
used, there is no need to build any infrastructure, allowing
the HN to operate on a pay-per-service model. Additionally,
it functions as an integration platform for mobile network
operators (MNOs) that want to offer other roaming services.
B. Registration phase
During this step, the UE and HN exchange secret credentials
via a secure connection comparable to [1], [2], [4]–[6]. When
UE wants to use the 5G services, it forwards the connection
establishment request to the HN. After getting the request from
UE, it chooses the SU P I , counter-value Ctr, a large random
number K, elliptic curve (EC) Fover the field Ea, point Q
of order y, and a random number Kpto derive its public
key S=KpQby means of EC multiplication. After deriv-
ing these credentials, HN shares (SU P I , H NID, C tr, Q, K, S)
with the UE that stores them into the USIM and also stores
(SU P I, C tr, Q, K, S, Kp)into his database. Table I demon-
strates the meaning of symbols and Fig 2 shows the proposed
protocol step by step.
TABLE I: Notations and meanings
Notations Meanings
SU P I & K& Ctr Identity of UE, secret key and Counter shared with HN
F&QElliptic curve over Ea& a point of E of order a
Kp&SPrivate key & Public key of HN
N1, N2, N3, r1&SK Random numbers & Session key
C. Authentication & key agreement phase
This section explains the authentication and key agreement
mechanism that is used when UE, SN, and HN communicate
with each other via an insecure channel for authentication. The
steps for key agreements and authentication are as follows:
•When UE wants to connect, it generates a random number
N1in order to compute G1=N1Q,G2=N1S,R1=
(SU P I , Ctr )⊕H(G2),R2=H(SU P I, Ctr, K, G2).
Next it increments Ctr to C tr+and forwards RES1=
{R1, G1, R2, HNID }to the SN.
•Upon getting RES1from UE, SN also generates a random
number N2in order to compute G3=N2Q,IDr=
H(KSN −HN , S NID , HNI D , R1, G1, R2, G3), and trans-
mits RES2={I Dr, S NID, RE S1, G3}to the smart
contract for the roaming subscriber.
•When the SC is received, the validity is verified. If it is new
and the identity of the requestor exists, then it contacts the
respective HN of the UE for the authentication function;
otherwise, it terminates the process.
•When HN receives RES2, it selects N3in order to
compute F1←N3.G1,F2←G1.Kp,F3←N3.G3,
F4←N3.Q, and (SU P I , Ctr )∗=R1⊕H(F2). After
getting SU P I , it extracts the secrets of the respective
UE and computes R∗
2=H(SU P I, C tr, F2, K)and
ID∗
r=H(KSN −HN , S NID , HNI D , R1, G1, R2, G3).
Then it verifies if {R2== R∗
2, IDr== ID∗
r, Ctr ≥
Ctr∗}. If it matches, then it believes that UE is
authentic and computes R4=H(F1, Ctr, S NID),
SK =H(F1, C tr, F2, K),R5=H(R4, SK ),R6=
H(F1, K), selects handover secrets KT, I DT, T, I =
EKL (IDT, T, r1),R7=ER6(R5, KT, I DT, T, I ),
R8=EH(F3,KSN −HN )(SU P I ,SK,R7,F3,KT,IDT,T ,KL),
IDs=H(R8, R7, F4, KSN −HN )and RES3=
{R8, IDr, IDs, F4}. This last parameter represents the
response for SN, which is forwarded to the SC.
•When SC receives this, it examines IDs. If it is fresh, it
forwards the message to SN .
•After receiving RES3, SN computes G4←
N2.F4, decrypts D(G4,KS N−H N )(R8) =
{SU P I, S K, R7, F3, KT, IDT, T , KL}, compares
{G4== F3}, stores KT, IDT, T, KLand sends
< R7, F4>to the UE.
•UE obtains {R7, F4}, then computes G5←N1.F4and
R4∗=H(G5, Ctr, S NID),S K =H(G5, Ctr, G2, K),
R5=H(R∗
4, SK )and decrypts D(G5,K)(R7) =
(R5, KT, IDT, T, I ), compares {R5== R∗
5}and stores
handover secrets KT, IDT, T , I.
Generate a random number N1,
Compute G1<- N1Q, G2<- N1S
Compute R1=(SUPI, Ctr)
⊕
H(G2)
Compute R2=H(SUPI, Ctr, K, G2)
RES1={R1, G1, R2, HNID}
Then Ctr+=Ctr+1 <RES1>
Generate random number N3,
Compute F1=N3.G1, F2=G1. Kp, F3=N3.G3, F4=N3.Q
Extract (SUPI, Ctr)*=R1
⊕
H(F2)
Compute R2*=H(SUPI, Ctr, K, F2)
Compute IDr*=(H(KSN-HN, SNID, HNID, R1, G1, R2 , G3)
Compare (IDr==IDr*, R2==R2*, Ctr>=Ctr*)
Then Ctr+=Ctr+1
Compute R4=H(F1, Ctr, SNID)
Compute SK=H(F1, Ctr, F2, K)
Compute R5=H(R4, SK)
Compute R6=H(F1, K)
Selects KT, IDT, T, I=EKL(IDT, T, r1)
Compute R7=ER6(R5, KT, IDT, T, I)
Compute R8<-EH(F3, KSN_HN)(SUPI, SK, R7, F3, KT, IDT, T, KL)
Compute IDs<-H( R8, R7, F4, KSN-HN)
RES3={R8, F4, IDr, IDs}
Compute G5<-N1.F4
Compute R4*=H(G5, Ctr, SNID)
Compute SK=H(G5, Ctr, G2, K)
Compute R5=(R4*, SK)
Decrypt D(G5, K)(R7)={R5, KT, IDT, T, I}
Compare {R5==R5*}
Stores KT, IDT, T, I
<R7, F4>
Generate a random number N2
Compute G3<- N2Q
Compute IDr=H(KSN-HN,SNID, HNID, R1, G1, R2 , G3)
RES2={IDr, SNID, RES1, G3}
<RES2>
If IDr exist in BC : abort
<RES2>
<RES3>
<RES3>If IDs exist in BC : abort
Blockchain
Smart contract (SC)
Home Network (HN)
( SUPI, Ctr, Q, K, S, Kp)
User Equipment (UE)
(SUPI, HNID, Q, K, S, Ctr)
Serving Network (SN)
(Q, KSN-HN)
Compute G4<-N2.F4
Decrypt D(G4, KSN_HN)(R8)={SUPI, SK, R7, F3, KT, IDT, T, KL}
Compare {G4==F3}
Stores KT, IDT, T, KL
Fig. 2: Proposed Protocol for mutual authentication
D. Handover Phase
The user uses this phase if the connection is lost during
authentication. So the user can reconnect to the SN and the SN
will not need another authentication with the HN by utilizing
the handover secrets, which significantly cuts down on the
time. However, users can only use these secrets briefly, not
continuously. Fig 3 depicts the handover phase and the detailed
description of the handover phase is as follows
Generate a random number R1,
Compute H1=H(KT)
⊕
(IDT, T, R1)
Compute H(KT, R1, I)={h0, h1, h2, h3}
<H1, h0, I>
Extract R2=R2'
⊕
h2
Extract I'=I'T
⊕
h1
Compute SK=h3
Compute H2*=H(SK, R2, IDT, I'T)
Compare H2==H2*
Stores I'T<--I'
Decrypts DKL(I)={IDT, T, r1}
Verifies the T and extracts the KT
Extract (IDT, T, R1)=H1
⊕
H(KT)
Compute H(KT, R1, I)={h0*, h1*, h2*, h3*}
Compares {h0==h0*, IDT==IDT*}
Generate a random number r2, R2
Compute SK=h3
Compute I'=EKL(IDT, T, r2)
Compute I'T=I'
⊕
h1
Compute R2'=R2
⊕
h2
Compute H2=H(SK, R2, IDT, I'T)
<I'T, R2', H2>
User Equipment (UE)
(KT, IDT, T, I)
Serving Network (SN)
(KT, IDT, T, KL)
Fig. 3: Proposed Protocol for Handover Phase
•When UE is disconnected from the SN, it uses the
handover secrets to reconnect. UE generates a random
number R1, computes H1=H(KT)⊕(IDT, T, R1),
H(KT, R1, I) = {h0, h1, h2, h3}, forwards < H1, h0, I >
to the SN.
•When SN receives the message from the UE, it decrypts
the Ito get the secrets {IDT, T, r1}. It then verifies
whether the secrets are valid or not based on the expiration
time T. If the time is expired, then it aborts the process.
Otherwise, it extracts the UE information based on the
temporary identity IDT, extracts (IDT, T , R1) = H1⊕
H(KT), computes H(KT, R1, I) = {h0∗, h1∗, h2∗, h3∗}
and then compares {h0== h0∗, IDT== IDT}.
If it matches, then it computes the response by gen-
erating the random numbers R2, r2,SK =h3,I′=
EKL (IDT, T, r2),I′
T=I′⊕h1,R′
2=R2⊕h2,
H2=H(SK, R2, I DT, I′
T), and sends < I′
T, R′
2, H2>
to the UE.
•When UE receives the message from SN, it extracts
R2=R′
2⊕h2,I′=I′
T⊕h1,SK =h3,H2∗=
H(SK, R2, I DT, I′
T)and compares {H2== H∗
2}. If it
matches, the UE updates I′
T←I′.
IV. FOR MA L VE RI FIC ATIO N OF T HE P ROPOSED PROT OC OL
In order to show that the authentication and the handover
phase provide strong security, the formal validity is established
utilizing the prominent mathematical model ROR logic, put out
by Abdalla et al. [17], AVISPA, and the Scyther validation tool.
A. Formal Security Analysis using ROR logic
The Real-Or-Random logic (ROR) is used to verify the
session key security of the mutual authentication and handover
phase protocols. It is very well known and vastly used by
security researchers [18], [19], [20] to demonstrate that an
attacker can not obtain the session key within polynomial time.
Our proposed work has two phases (i.e., the authentication and
key agreement phase and the handover phase). The proposed
authentication and key agreement phase uses the ECC and
hash function to secure the communication, while the handover
phase relies on symmetric encryption. The authentication phase
involves three participants, UE, SN, and HN, while the handover
occurs between the UE and SN. The instances k,k′, and lare
represented by UEk,S N k′and HN l, respectively, and some
predefined queries are adopted by the attacker (ψ) to carry out
the real-time attack. In the following discussion, there is another
instance mof Zm. The specified queries are as follows.
•Execute (UEk, HNl): This query is run by the ψto
intercept the exchanged messages between the UEk, SNk′,
and HNlduring the authentication and key agreement
phase and between the UEk, and SNk′during the handover
phase.
•Reveal (Zm): This query has been run by the ψto acquire
the session key generated between the UEk, SNk′and
HNlduring the authentication key agreement phase and
between UEk, and SNk′during handover phase.
•Test (Zm): This query has been run by the ψto make sure
the secrecy of the session key between UEk, SNk′and HNl
during the authentication and key agreement and between
UEk, and SNk′during handover phase. To confirm this, ψ
tossed a coin to predict the result of the Test query.
Theorem 1: Let us assume that ψattempts to determine the
session key (SK) between the UE, SN, and HN in polynomial
time. Then for the authentication Adψ≤Q2
Hash
|D|+ 2AdEC DDH
ψ
and for the handover phase Adψ≤Q2
Hash
|D|.
The description of the terms used in the ROR verification is
as QHash ,|D|and AdEC DDH denoting the hash query, range
space for hash function H(.) and ψ′sadvantage to obtain the
EC DDH problem [18], respectively.
Proof: Under this theorem proof, we demonstrate that ψ
can not determine the session of the authentication phase and
the handover phase. The proof of the theorem is carried out
similarly to the [18] using the games and the random Oracle.
We use the three games named as GMEwhere E∈[0, 2] (i..e,
used by the ψduring the ROR logic proof to get the session
key ) and the event SψGMEused in the proof defined as ψcan
guess the value of the cand P[SφGME]defines the competitive
advantage of winning the game during the ROR logic.”
Game (GM0): This is the first game played by the ψto
launch the real-time attack on the authentication and handover
phase based on the randomly tossed coin at the start of the
Game. After launching the real-time attack, we can conclude
from the semantic analysis.
Adψ= [2P[SψGM0]−1] (1)
Game (GM1):As from the first game, we can ob-
serve that ψdid not get any meaningful information. Now
the Execute query is executed by the ψto acquire the
exchanged messages {((RES1),(RE S2),(RES3),(R7, F4))}
between the UE, SN, and HN during the authentication and
{(H1, h0, I),(I′
T, R′
2, H2)}during the handover phase. After
getting the exchanged message, Reveal and Test are executed by
the ψto determine the secret session key of the authentication
and the handover phase, but he/she will fail to get the session
key. Since every message contains a fresh random number, these
random numbers are exchanged in the hashed form. So, due to
the hash property, ψcan not determine the random numbers
and other secrets such as {Ctr, K, Kp, SU P I }which are used
in the authentication and for the handover phase, secrets will
be used for a very short period of times and after that they will
be deleted from the database. We can conclude that ψwill fail
to get meaningful information from the first and second games.
So, GM0will be the same as GM1
P[SψGM1] = P[SψGM0](2)
Game(GM2):The execution of the first two games shows that
ψfails to determine the secrets used in the session key. So
during this game, ψwill make the final attempt by running the
HASH to get the random numbers {N1, N2, N3}used in the
authentication and {R1, R2}used in the handover phase, since
in the authentication, random numbers are generated through
the ECC and due to the discrete logarithmic problem [18] it is
hard to get the random number used in the authentication and
key generation session. Same for the handover phase, generated
random numbers are exchanged in hashed form. So, it shows
that by executing the final game, the attacker fails to determine
the session key since it is hard to get the random that is covered
with hash and ECC. So the winning probability of the final
game will be similar to the second game. Therefore, it can be
concluded from the birthday paradox and the intractability of
EC DDH
P[SψGM1]−P[SψGM2]≤AdE CDDH
ψ+(Q2
HAS H )
2D(3)
Now all the games have been played by the ψ, and it is expected
that ψshould have guessed the exact precise value. Considering
this, we conclude
P[SψGM2] = 1
2(4)
from Equation( 1) ( 2), and ( 4), we can obtain
Adψ=|2P[SψGM0]−1|
=P[SψGM1]−P[SψGM2](5)
We get the following result from Equation( 3) and ( 5) .
Adψ≤Q2
HAS H
D+ 2AdEC DDH
ψ
The execution of the games shows that under the ROR model
assumption, ψfails to determine the session key of the authenti-
cation and key generation phase as well as the handover phase.
So, both the authentication and the handover phase are secure
and impossible to get the session key within polynomial time.
B. Formal Security verification using Scyther tool
The validation Scyther tool [21] is used to check the security
of the planned authentication and handover phase. This tool uses
the Security Protocol Description Language (.spdl) language
as a modeling language for protocols. The tool defines four
distinct types of propositions (specifically, Alive, Weakagree,
Niagree, and Nisynch) that can be used to investigate security
propositions, [9], [22]. To evaluate the security prepositions
[23], [24], the tool considers the threat hypotheses outlined
by Yao Dolev, CK adversary, and eCK threat model. During
the simulation of the authentication and the handover phase,
we consider the following setting: the attacker can get a short-
term or long-term key as well, as the random number can also
be revealed, and that simulation offers perfect forward secrecy
(PFS). In addition to this, other parameters are also set to be
the maximum and tested in different settings. The simulation
result is displayed in Fig. 4 and Fig. 5, demonstrating that the
proposed work passes all prepositions, demonstrating that the
proposed protocol has no attacks within the limitations.
Fig. 4: Scyther result for Authentication & key agreement phase
Fig. 5: Scyther tool result for Handover phase
C. Formal Verification using AVISPA tool
The Automatic Validation of Internet Security Protocols
and Applications (AVISPA) tool is used to formally simulate
the planned authentication and handover processes [25]. The
AVISPA tool presents the authentication methods in a formal,
expressive, modular language. Additionally, several backend
server types are used to mimic authentication protocols by
employing a variety of automatic analysis approaches, including
protocol falsification and abstraction-based verification methods
for both finite and infinite numbers of sessions. After being
implemented based on the roles, the authentication protocols are
then specified in High-Level Protocols Specification Language
(HLPSL) for the simulation. The tool identifies four categories
of backend servers:(1) On-the-fly Model-Checker (OFMC); (2)
Constraint Logic-based Attack Searcher (CL-AtSe); (3) SAT-
based Model-Checker (SATMC); and (4) Tree Automata based
on Automatic Approximations for the Analysis of Security
Protocols (TA4SP). We use the OFMC and CL-Atse backend
servers to verify the proposed protocols similar to [26], [27].
The authentication protocol has four roles: UE, SN, Blockchain,
and HN, while the handover phase has two roles: UE and
SN. Each role is described based on the exchanged messages.
In addition to this, the environment is set, which defines the
attacker’s capabilities. After these settings, we do the simulation
and found that authentication and handover of both phases are
safe. The safe indicates, as shown in Fig. 6 and Fig. 7, that the
authentication and the handover phase have no attacks.
Fig. 6: AVISPA result for Authentication & key agreement
Fig. 7: AVISPA tool results for Handover Phase
V. PERFORMANCE MEASUREMENT
The proposed protocol’s efficiency in terms of computational,
communication, storage, and energy consumption is measured
in this section, along with the security comparison. In addi-
tion, the smart contract’s cost is computed to demonstrate its
effectiveness in terms of transaction and execution costs.
A. Security analysis
This subsection outlines the security comparison of the
proposed authentication phase with [1], [3], [5]–[7], [9]–[12].
The comparative results shown in Table II reveal that the
authentication phase delivers all the security characteristics
while failing to provide others. This is due to the protocol’s
use of a combination of long-term secrets {K, Ctr}and random
numbers that are altered after each authentication session and
transferred using hash and ECC cryptographic processes. As a
result, the attacker cannot obtain any knowledge from which he
might be able to deduce the earlier secrets and keys. In addition
to this, most of the authentication protocols do not offer the
handover phase. However, [11] offers the handover but is prone
to various attacks [13].
B. Test-bed implementation using MIRACL
This subsection outlines the experimental analysis carried out
to evaluate the cost of the cryptographic operations using the
MIRACLE library [28]. This is a programming-based library
used by researchers to evaluate the cost of cryptographic oper-
ations [19]. The cost of cryptographic operations is determined
using the two scenarios, namely Raspberry PI 4 as UE and
desktop as HN. The specifications used for Raspberry Pi as
UE are Raspberry Pi (Model: 4B, CPU: ARM® Cortex®-A7,
Cores: 4, and RAM: 8GB), while the specifications used for HN
as the desktop are Intel-(R) Core(TM) i7-3770 with 3.40-GHz
clock, 32 GB-RAM, and Linux Ubuntu-18.04.6 LTS. In order to
get the average run time, each cryptographic operation is carried
out 100 times. The cryptographic operations TH,TP M ,TAES ,
TRSA stand for the amount of time needed to perform a “one-
way hash function (SHA-256), elliptic curve multiplications
(PM-256), (AES-128) encryption/decryption, and (RSA-2048)
encryption/decryption,” respectively.
C. Computation & Communication cost analysis
We determine the computational and communication cost to
demonstrate the efficiency of the authentication and the han-
dover phase. When calculating the cost of communication, we
compute the transmitted cost during the exchange of messages,
and when calculating the computational cost, we compute the
cost of cryptographic operations performed in the protocol.
The cost of cryptographic procedures is taken into account
while estimating the computing cost as obtained by the test-
bed implementation illustrated in Table III. In the proposed
protocol, (4TH+ 3TP M )and (2TAES + 9TH+ 6TP M )have
been used as UE and SN, HN side, respectively which is
≈5.6 ms. For the handover phase, UE side requires (3TH)
and SN side (1TAES + 3TH)which is ≈0.1 ms. The
amount of bits needed for cryptographic operations is taken
from the NIST [29] to compute the number of transmitted
bits during the authentication session. There are six message
exchanges taking place in the successful authentication ses-
TABLE II: Comparison of Security characteristics of 5G-AKA protocols/
P 1 2 3 4 5 6 7 8 9 10 11 12 13 14
[3] T F F F F F T F F T F F F F
[1] T T F T T T F T F T F F T F
[5] T T T F T T T F F T F F T F
[6] T T F F T T T T F F F T T T
[9] T T T T T T F T F T F F T F
[10] T T T T T T F T T T F F T F
[7] T T T T T T T T T T F T T T
[11] T T F F F T T T F T T F F F
[12] T T T T T T T T F T F F T F
Ours T T T T T T T T T T T T T T
Notes: mutual authentication (1), resistant against privacy attack (2), perfect forward secrecy (3), resistant against device-stolen-attack (4), resistant against traceable-attack
(5), resistant against de-synchronization attack (6), resistant against malicious-SN problem (7), resistant against replay-attack (8), DoS-attack prevention (9), resistant-against
impersonation attack (10), Supports Handover (11), Applicable in roaming scenarios (12), Formal verification (13), Illuminates the secure-channel assumption between the SN and
HN (14), Yes-T, No-F.
TABLE III: Test-bed implementation results
Cryptographic operations THTPM TRS A TAES
Using Desktop (ms) 0.0032 0.295 4.69 .0036
using Raspberry PI 4 (ms) 0.0315 1.23 8.14 0.041
sion {(RES1),(RE S2),(RES2),(RES3),(RE S3),(R7, F4)}
which takes 6176 bits for communication and the handover
phase takes {(H1, h0, I),(I′
T, R′
2, H2)}which takes 1280 bits.
We took the protocol that uses the blockchain [6], [7], and
the protocol [11] supports the handover but does not use the
blockchain and is unsuitable for the roaming scenarios (see
Table II) for the comparison. In addition to this, we also
included the protocol [12] that follow the same architecture
but is unsuitable for the roaming scenarios. The comparison
result indicated in Table. IV and Table. V depicts that the
proposed work is lightweight as compared to the protocol that
can apply in roaming scenarios [6], [7]. On the other side,
our authentication and key agreement protocol takes a slightly
higher cost than [11], [12], but they are not suitable for roaming
as well as vulnerable to attacks. The reason for the proposed
protocol’s minimal than [6], [7] is ECC, which provides the
same amount of secrecy as the RSA 2048 bit. However, the
proposed one is higher because [11], [12] do not use the
blockchain, resulting in less computational and communication.
D. Storage & Energy consumption
This subsection estimates the storage required for the IoT
device and the energy consumption during the authentica-
tion and handover phase. The storage cost of the IoT de-
vice is computed, and the size of cryptographic operations
is utilized, as NIST mentioned. The IoT device requires the
{SU P I , H NID, Q, S, C tr, K}= 992 bits during the authen-
tication and {KT, IDT, T, I , Ctr}= 416 bits for the han-
dover phase. The energy consumption of the authentication
and the handover phase is estimated similarly to the [20].
The energy consumed during the successful authentication is
(6176×0.00066+ 13×0.000108+2 ×0.000207+9×9.8)=92.2
mj and the handover phase (1280×0.00066+6×0.000108+1×
0.000207)=0.8 mj. The comparison outcome of storage cost and
the energy consumption is illustrated in Table. IV, and Table. V
demonstrates that the authentication and handover phase takes
less storage and consumes less energy compared to [6], [7].
E. Performance measurements for smart contract functions
This subsection depicts the cost required for smart contract
execution. The cost of the smart contract is estimated based
on transaction and execution time. The exchange messages
{IDr, SNI D, RE S1, G3}and {R8, F4, IDr, I Ds}are exe-
cuted in order to check the validity. We compute the transaction
and execution cost of the proposed protocol and the existing
protocol [6], [7], which is based on blockchain and follows
the same system model. In order to evaluate the cost, we use
the online compiler remix.etherum.org on a desktop having
the configuration as mentioned in SectionV-B. We consider the
size of cryptographic operations similar to [6], [7]. The cost is
computed for the two messages (request (IDr), response (I Ds)
in gas. The comparison’s results, which are shown in Fig 8a and
Fig 8b, demonstrate that the proposed approach is cost-effective
as compared to [6], [7]. This is because the proposed approach
uses the ECC, which is more efficient than the RSA utilized
in [6], [7]. Also, our authentication and key agreement requires
only six message exchanges while [6], [7] takes eight.
Transaction Cost Execution Cost
0
0.5
1
1.5
2
2.5
3
3.5
Cost for Request
104
[6] [7] Ours
(a)
Transaction Cost Execution Cost
0
1
2
3
4
5
6
7
Cost for Response
104
[6] [7] Ours
(b)
Fig. 8: Comparison of the transaction and execution costs for
the (a) request and (b) response.
VI. CONCLUSION
This paper proposes an ECC-based authentication mechanism
using the blockchain to address the authentication issue in roam-
ing situations. By offering a safe path, blockchain technology
aids the SN in obtaining subscription information, preventing
malicious SN and DoS attacks. A handover phase is also
proposed to reestablish communication between the UE and
SN if it was lost during authentication. The mathematical model
ROR and the validation tool Scyther and AVISPA are used to
TABLE IV: Comparison of computation, communication, storage costs, energy consumption for authentication protocols
P Computational cost (ms) Communication cost Storage Cost Energy Consumption (mj) Message Exchanges
UE Total operations Total
time
Total
bits
Total
bits
[6] 2TRSA + 2TAES + 12TH13.2 14496 2336 110.9 8
[7] 1TAES + 12TH+ 7TP M + 1TRS A 12.20 11552 2456 1251.9 8
[11]
6TH+ 9TAES + 2TP M 3.6 1312 1154 21.2 6
[12]
1TAES + 12TH+ 9TP M 7.8 3520 864 1251.9 6
Our 2TAES + 13TH+ 9TP M 5.6 6176 992 92.2 6
TABLE V: Comparison of computation, communication, storage cost, and energy consumption for Handover phase
Protocols Computation cost (ms) Communication cost Storage Cost Energy Consumption (mj) Message Exchanges
User side slice side Total time Total bits Total bits
[11] 2TAES + 2THTAES + 3TH0.16 768 256 0.51 3
Ours 3TH3TH+ 1TAES 0.1 1280 416 0.84 2
analyze the security of the authentication and handover phase to
show that it offers robust security. Furthermore, the efficiency
of the proposed protocol is shown in terms of computation,
communication, storage, and energy consumption, indicating
that it is efficient in all regards. Additionally, an assessment
of the cost of executing a smart contract in terms of transaction
and execution demonstrates that it is less expensive than the
existing protocol.
REFERENCES
[1] A. Braeken, M. Liyanage, P. Kumar, and J. Murphy, “Novel 5g authentica-
tion protocol to improve the resistance against active attacks and malicious
serving networks,” IEEE Access, vol. 7, pp. 64 040–64 052, 2019.
[2] Y. Xiao and Y. Wu, “5g-ipaka: An improved primary authentication and
key agreement protocol for 5g networks,” Information, vol. 13, no. 3, p.
125, 2022.
[3] “ 3GPP, Security architecture and procedures for 5G system, (3GPP), TS
33.501, 2020, Available Online:,” https://www.3gpp.org/ftp/Specs/archive/
33 series/33.501/.
[4] Y. Wang, Z. Zhang, and Y. Xie, “Privacy-preserving and standard-
compatible {AKA}protocol for 5g,” in 30th {USENIX}Security Sympo-
sium ({USENIX}Security 21), 2021.
[5] T. Liu, F. Wu, X. Li, and C. Chen, “A new authentication and key agree-
ment protocol for 5g wireless networks,” Telecommunication Systems, pp.
1–13, 2021.
[6] M. Hojjati, A. Shafieinejad, and H. Yanikomeroglu, “A blockchain-based
authentication and key agreement (aka) protocol for 5g networks,” IEEE
Access, vol. 8, pp. 216 461–216 476, 2020.
[7] A. K. Yadav, A. Braeken, M. Misra, and M. Liyange, “A provably
secure and efficient 5g-aka authentication protocol using blockchain,” in
2023 IEEE 20th Consumer Communications and Networking Conference
(CCNC), 2023, pp. 1110–1115.
[8] Z. Gao, D. Zhang, J. Zhang, Z. Liu, H. Liu, and M. Zhao, “Bc-aka:
Blockchain based asymmetric authentication and key agreement protocol
for distributed 5g core network,” China Communications, vol. 19, no. 6,
pp. 66–76, 2022.
[9] M. C. Chow and M. Ma, “A secure blockchain-based authentication and
key agreement scheme for 3gpp 5g networks,” Sensors, vol. 22, no. 12,
p. 4525, 2022.
[10] A. K. Yadav, M. Misra, P. K. Pandey, K. Kaur, S. Garg, and X. Chen, “A
provably secure ecc-based multi-factor 5g-aka authentication protocol,”
in GLOBECOM 2022 - 2022 IEEE Global Communications Conference,
2022, pp. 516–521.
[11] C.-I. Fan, Y.-T. Shih, J.-J. Huang, and W.-R. Chiu, “Cross-network-slice
authentication scheme for the 5 th generation mobile communication
system,” IEEE Transactions on Network and Service Management, vol. 18,
no. 1, pp. 701–712, 2021.
[12] A. Yadav, P. Pandey, K. Kaur, S. Singh, and A. Bradai, “Pslp-5g: A
provably secure and lightweight protocol for 5g communication,” in ICC
2023 - IEEE International Conference on Communications, 06 2023.
[13] Z. Ren, X. Li, Q. Jiang, Y. Wang, J. Ma, and C. Miao, “Network slicing
in 6g: An authentication framework for unattended terminals,” IEEE
Network, 2022.
[14] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE
Transactions on information theory, vol. 29, no. 2, pp. 198–208, 1983.
[15] R. Canetti and H. Krawczyk, “Universally composable notions of key
exchange and secure channels,” in International Conference on the Theory
and Applications of Cryptographic Techniques. Springer, 2002, pp. 337–
351.
[16] P. Heged˝
us, “Towards analyzing the complexity landscape of solidity
based ethereum smart contracts,” Technologies, vol. 7, no. 1, p. 6, 2019.
[17] M. Abdalla, P.-A. Fouque, and D. Pointcheval, “Password-based authenti-
cated key exchange in the three-party setting,” in International Workshop
on Public Key Cryptography. Springer, 2005, pp. 65–84.
[18] A. K. Das, M. Wazid, A. R. Yannam, J. J. Rodrigues, and Y. Park,
“Provably secure ecc-based device access control and key agreement
protocol for iot environment,” IEEE Access, vol. 7, pp. 55 382–55 397,
2019.
[19] A. K. Yadav, M. Misra, P. K. Pandey, and M. Liyanage, “An eap-based
mutual authentication protocol for wlan connected iot devices,” IEEE
Transactions on Industrial Informatics, pp. 1–12, 2022.
[20] Z. Xu, X. Li, J. Xu, W. Liang, and K.-K. R. Choo, “A secure and
computationally efficient authentication and key agreement scheme for
internet of vehicles,” Computers & Electrical Engineering, vol. 95, p.
107409, 2021.
[21] C. J. F. Cremers, Scyther: Semantics and verification of security protocols.
Eindhoven university of Technology Eindhoven, Netherlands, 2006.
[22] S. Shunmuganathan, “A reliable lightweight two factor mutual authen-
ticated session key agreement protocol for multi-server environment,”
Wireless Personal Communications, vol. 121, no. 4, pp. 2789–2822, 2021.
[23] A. K. Yadav, M. Misra, P. K. Pandey, K. Kaur, S. Garg, and M. Liyanage,
“Lemap: A lightweight eap based mutual authentication protocol for
ieee 802.11 wlan,” in ICC 2022 - IEEE International Conference on
Communications, 2022, pp. 692–697.
[24] M. Liyanage, A. Braeken, A. D. Jurcut, M. Ylianttila, and A. Gurtov,
“Secure communication channel architecture for software defined mobile
networks,” Computer Networks, vol. 114, pp. 32–50, 2017.
[25] A. Armando, D. Basin, Y. Boichut, Y. Chevalier, L. Compagna, J. Cu ´
ellar,
P. H. Drielsma, P.-C. H´
eam, O. Kouchnarenko, J. Mantovani et al., “The
avispa tool for the automated validation of internet security protocols and
applications,” in International conference on computer aided verification.
Springer, 2005, pp. 281–285.
[26] Y. Zhang, R. H. Deng, E. Bertino, and D. Zheng, “Robust and universal
seamless handover authentication in 5g hetnets,” IEEE Transactions on
Dependable and Secure Computing, vol. 18, no. 2, pp. 858–874, 2019.
[27] M. Seifelnasr, R. AlTawy, and A. Youssef, “Skafs: Symmetric key
authentication protocol with forward secrecy for edge computing,” IEEE
Internet of Things Journal, 2023.
[28] “ MIRACL Cryptographic SDK: Multiprecision Integer and Rational
Arithmetic Cryptographic Library. (2022). Accessed: March 2022. [On-
line]. Available:,” https://github.com/miracl/MIRACL.
[29] L. D. Tsobdjou, S. Pierre, and A. Quintero, “A new mutual authentication
and key agreement protocol for mobile client—server environment,” IEEE
Transactions on Network and Service Management, vol. 18, no. 2, pp.
1275–1286, 2021.