Received October 19, 2020, accepted November 20, 2020, date of publication December 2, 2020,

date of current version December 14, 2020.

Digital Object Identifier 10.1109/ACCESS.2020.3041710

A Blockchain-Based Authentication and Key

Agreement (AKA) Protocol for 5G Networks
MAEDE HOJJATI1 , ALIREZA SHAFIEINEJAD 1 ,
AND HALIM YANIKOMEROGLU2 , (Fellow, IEEE)
1 Department of Electrical and Computer Engineering, Tarbiat Modares University, Tehran 14117-13116, Iran
2 Department of System and Computer Engineering, Carleton University, Ottawa, ON K1S 5B6, Canada
Corresponding author: Alireza Shafieinejad ([email protected])

ABSTRACT Subscriber authentication is a primitive operation in mobile networks required by each operator
prior to offering any service to end users. In this paper, we propose a novel blockchain-based Authentication
and Key Agreement (AKA) protocol for roaming services in 5G networks. Each Home Network (HN) creates
its own smart contract and publishes its address to inform other operators who want to offer roaming services
to HN subscribers. All subsequent communication between the HN and Serving Network (SN) is done by
calling the function of this smart contract. The proposed protocol eliminates the need for a secure channel
between the HN and SN, which is a primary requirement of current 5G AKA protocols. In practice, a secure
channel requires the HN and SN to establish a secure session before running the AKA protocol. Further,
the proposed protocol leverages the benefits of blockchain, such as auditable log, decentralized architecture,
and the prevention of Denial of Service (DoS) attacks. Furthermore, we provide a security proof of the
protocol through formal verification using ProVerif. The results show that our scheme tends to preserve user
privacy and at the same time provides mutual authentication of the participants. Finally, our evaluation of the
Ethereum blockchain shows that the protocol is efficient in terms of both transaction and execution costs.

INDEX TERMS 5G networks, authentication and key agreement protocol, blockchain system, formal
verification.

I. INTRODUCTION Broadcasting, which is a distinct feature of wireless trans-

Recent developments in the mobile network industry provide missions, is a major source of threats. Some security vul-
new services and applications. More specifically, develop- nerabilities include eavesdropping, traffic analysis, jamming,
ments in 5G networks present a set of new services, includ- Man In The Middle (MITM), Denial of Service (DoS) and
ing Ultra-Reliable Low Latency Communications (URLLC), Distributed Denial of Service (DDoS) [1].
Massive Machine-Type Communications (MMTC), and The 3rd Generation Partnership Project (3GPP) group,
Enhanced Mobile Broadband (EMB). Regarding these new as the developer of the standards for 3G, 4G, and 5G,
services, several challenges like decentralization, trans- has paid particular attention to security issues, such as
parency, interoperability, privacy, and security have emerged subscriber privacy and the protection of sensitive data. The
in the process of their implementation. 3GPP has published a series of documents on security archi-
Among these challenges, security is one of the most impor- tecture and procedures of 5G systems. The latest version,
tant issues, and it imposes specific constraints on develop- v15.4.0 of Release 15 of the Technical Specifications (TS),
ers of 5G networks to make designs compatible with new was published in May 2019 (TS 33.501) [2]. The issues
technologies. Security issues originate with data sensitive discussed included security requirements and features for
applications, such as banking, healthcare, mobile cloud, etc. User Equipment (UE), Home Networks (HNs) and Serving
In these scenarios, it is critical for the services to authenticate Networks (SNs) for authentication, information leakage,
each customer correctly as well as to preserve their privacy. user localization, privacy protection and effects of the
active/passive attackers.
The associate editor coordinating the review of this manuscript and Further, TS 33.501 drew attention to a case of a malicious
approving it for publication was Xiaodong Xu . SN while the user gets roaming service. Roaming is an

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
VOLUME 8, 2020 216461
 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

important service in mobile communication, when the UE A. RELATED WORK

enters into a cell out of the HN coverage area. Roaming is The introduction of AKA by 3GPP triggered enough motiva-
expected to become more prominent in 5G networks due to tion for researchers to improve the proposed authentication
the popularity of both local 5G networks and micro 5G oper- protocols [2]. The authors in [7], revealed a new privacy
ators [3], [4]. Since both have lightweight implementation, attack against all variants of the AKA protocol, including
they are more vulnerable to threats from active attackers and 5G AKA. This attack compromised subscriber privacy more
thereby can act as malicious serving networks. severely than any known location privacy attacks. Further,
Further, a large section of TS 33.501 focused on the the authors in [7] conducted a security analysis of the cor-
authentication of participants, including UE, HNs, and SNs. responding vulnerability. Liyanage et al. identified the most
The goal was to establish a secure channel between the UE important privacy issues caused by the new technologies,
and SN and authenticate them with the HN. The 3GPP has which are expected to be utilized in 5G [8].
specified three authentication methods: 5G AKA, EAP-AKA Basin et al. followed the research on AKA by providing
and EAP-TLS. A suitable option is picked up by the HN a formal analysis of the protocol in order to identify the
whenever it has correctly identified the subscriber with an missing security goals [9]. They used Tamarin [10], a security
Initialization Protocol. The 5G AKA protocol is the improved protocol verification tool for formal verification. In addition
version of the AKA protocol currently used in 4G (identified to detecting security goals missed in the primary design, they
as EPS-AKA) which is assumed to provide required secu- made recommendations to fix the corresponding flaws and
rity guarantees. The introduction of AKA by the 3GPP has weaknesses.
motivated researchers to improve the proposed authentication More recently, Braeken et al. proposed a new version of
protocols. In this paper, we discuss the following set of the 5G AKA to overcome the identified weaknesses in the
issues: protocol [11]. The main idea was to replace the sequence
Deploying blockchain for 5G authentication processes: number with random numbers and thereby reduce the number
Blockchain technology provides a platform for an immutable of required communication phases in the protocol. Further,
distributed ledger. The second generation of this technology they claimed that the proposed protocol achieved two extra
enables the execution of programmable transactions in the security goals that were missed in 5G AKA, namely post
form of smart contracts [5]. Blockchain for 5G authentication compromise security and forward security.
can serve as a barrier between the SN and HN. In so doing, From architecture point of view, blockchain-based solu-
blockchain can provide a secure channel for exchanging tions in 5G networks are in the initial state-of-the-art.
messages. This promotes user anonymity and protects the Recently, several technologies, such as Software-Defined
HN from DoS attacks by making it unreachable by mali- Networking (SDN), Network Function Virtualization (NFV),
cious SNs, which can act as active attackers. It also pro- machine learning, and cloud computing are used in 5G net-
vides a tamper-proof and auditable log of the authentication works to improve the quality of services. But this leads to
processes. several challenges, like decentralization, transparency, inter-
The vulnerabilities of the current 5G AKA variants: We operability, privacy, and security. Blockchain is capable of
discuss the vulnerabilities of the basic 5G AKA protocol and addressing these issues since it has inherent features such
the improved state-of-the-art versions. as transparency, data encryption, auditability, immutability
Eliminating the need for a secure channel in 5G AKA: and distributed architecture [12]. From a security point of
A common requirement of the current 5G AKA protocol, and view, blockchain has the potential to provide solutions for
its preceding variants, is that of needing a secure channel data privacy, authentication, integrity protection, and access
between the HN and SN. In fact, this is a vital condition for the control.
security proof of current protocols. However, this condition Refaey et al. studied the benefits and drawbacks of
is restrictive because it requires the channel to be private and blockchain in roaming systems [13]. They proposed a
thus inaccessible to any passive or active attacker. In practice, high-level architecture for a roaming model and discussed
a secure channel imposes another authentication and key potential issues and challenges. The model was evaluated
exchange protocol to the mobile networks. This protocol is using the case of roaming in the EU.
run between the HN and SN which communicate with each The authors in [14] proposed a blockchain framework for
other through an IP network. This is achieved by the Internet trusted task sharing in Multi-access Edge Computing (MEC)
Key Exchange (IKE) and IPSec protocols which are based environments. The framework was deployed on the Hyper-
on either pre-shared keys or digital certificates [6]. In this ledger blockchain and its performance was evaluated from
paper, we present a method of eliminating this requirement the point of view of latency.
and providing a strong security proof as well as simplifying The authors in [15] proposed a blockchain-based secu-
the deployment of 5G AKA protocol. rity authentication scheme for 5G Ultra-Dense Networks
Security evaluation of 5G AKA. We carry out a formal (UDNs). UDNs are a technology meant to address the issue of
security evaluation of the proposed authentication protocol network system capacity in 5G networks. They are composed
and provide a comprehensive analysis. of a set of access points (APs) with a smaller coverage

216462 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

area than a base station, which is primarily characterized by The main contributions of this paper can be summarized as
being autonomous, temporary, and dynamic. The scheme is follows:
mainly focused on the interaction between the UE and APs by • We propose a blockchain-based authentication protocol
defining a trusted APs group (APG). The work proposed an in 5G networks. The framework provides more secu-
APG-PBFT algorithm based on blockchain with a Byzantine rity controls including protection against malicious HN,
fault tolerance (PBFT) consensus algorithm. The trusted APG replay attacks and DoS attacks than previous AKA
was generated using this algorithm and the authentication schemes.
results could be shared in the APG with the propagation • The proposed protocol eliminates a common limitation
mechanism. of previous protocols, which require a secure channel
From an experimental point of view, Morozo et al. between the HN and SN. This feature makes the HN
designed and implemented an intra-operator charging frame- free to establish secure sessions with other operators.
work model for roaming based on blockchain [16]. The Thus, MNOs do away with conventional peer-to-peer
MNOs were integrated into a blockchain consortium as full authentication and key exchange protocol in order to
nodes. The proposed model allows for the verification of create a secure channel.
transactions by the miners while processing smart contracts. • We provide the security proof of the proposed protocol
by formal verification.
Blockchains have inherent benefits, such as auditability
B. CONTRIBUTIONS OF THE WORK and undeniable logs. The proposed protocol can be imple-
In this paper, we propose an authentication protocol for 5G mented on any distributed blockchain platform, and it par-
networks based on blockchain. Blockchain can serve as a takes of blockchain’s benefits. DoS prevention is another
barrier between the HN and SN and can provide a public important issue provided by blockchain. In our scheme,
channel for message exchanging. This model is appropriate the HN is protected against DoS attacks originating from
for roaming, where UE uses a different network than its home malicious SNs. Moreover, the secrecy of sensitive data is
network. Given the significant number of customers, mobile protected by encrypting all of the exchanged messages, and
operators will lose many of their original customers within consequently user privacy is maintained. Message encryp-
few years if they do not understand the reasons for customer tion prevents a blockchain node from transaction tracing
churn over time [17]. Accepting new subscribers from other aimed at extracting user information. Thus, the participant
operators will also be costly for both parties. Thus, it is better MNOs are the only nodes able to decrypt the authentica-
for an operator to retain their customers and take on the tion request/response messages, which are embedded in the
roaming service [18]. metadata of the transactions.
In addition to the heavy costs for both operators, subscriber Further, smart contract can verify the freshness of authen-
migration causes customer dissatisfaction [19]. Providing ser- tication request by means of a unique identifier derived from
vices to subscribers of other operators in such a way that each random numbers of UE and SN and accordingly preventing
operator retains its subscribers will provide satisfaction for all replay attacks. In addition to the above features, the proposed
parties. protocol is capable of employing digital currency, which
Operators have always tried to satisfy their customers facilitates the charging system by eliminating the dependency
through mutual agreements and by cooperating with each on national currencies. This leads to an ‘‘anytime-anywhere’’
other. They also provide many services to each other’s sub- service and creates a new evolution in billing systems.
scribers according to pre-defined agreements. Prior to using The requirement of a secure channel between the HN
any service offered by the visited network, the subscriber and SN is vital for the security proof of previous proto-
must be authenticated by the HN. The authentication not cols. In practice, this condition is very restrictive since it
only guarantees the registration of the subscriber to the HN, assumes that the channel is private and not accessible to any
but also allows the visited network to retrieve the required passive or active attacker. By using a pubic blockchain as
information in order to create a session for the subscriber. a communication channel between operators, the attacker is
In the proposed protocol, each HN creates its own smart always able to scan the blockchain transactions and retrieve
contract and publishes the address of this smart contract in the authentication messages. However, we prove that the
order to inform the other operators who want to provide attacker is not capable of decrypting the messages and thus
roaming service to the HN’s subscribers. All subsequent is unable to implement a successful attack.
communications between the HN and SN are done by calling Compared with [2], our protocol design is based on the
the function of this smart contract. The proposed protocol latest version of 5G AKA, in which security holes have been
tends to preserve user privacy while at the same time pre- fixed during various releases. Further, we verify the proposed
venting the HN from DoS attacks by keeping it unreachable to model with formal methods in order to provide proof of the
attackers or malicious SNs. It also provides non-tampered and required security features. Compared to [9] and [11], our
auditable logs of the authentication process. This paper is the work is based on blockchain.
first work of 5G AKA with blockchain and can beconsidered The rest of this paper is outlined as follows. Section II
as a basis for future works and new ideas in this field. provides a brief background of current protocols for

VOLUME 8, 2020 216463

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

5G authentication. Section III presents our proposed protocol

and explains its phases. Section IV offers proof of the security
of the proposed protocol using ProVerif, and an evaluation of
the protocol’s performance is provided in Section V. We dis-
cuss the application of this scheme in aerial networks. Finally, FIGURE 1. The 5G AKA architecture.
Section VII concludes the paper.

II. PRELIMINARIES By UE, we mean smart phones and IoT devices, which are
A. NOTATIONS carried by a subscriber. Each UE has a universal integrated
Table 1 summarizes the definitions and symbols used circuit card (UICC). This card can host a universal subscriber
throughout the paper. Note that f1 , Keyseed, and challenge are identity module (USIM) application, which securely stores
the primitive one-way keyed cryptographic functions which a pre-shared key with the subscriber’s HN. For each USIM,
are embedded in the USIM1 card [20]. the UE has a unique identifier known as a Subscription Per-
manent Identifier (SUPI), which is stored in the Universal
TABLE 1. Notations used in protocol modeling.
Subscriber Identity Module (USIM). SUPI in 5G corresponds
to the International Mobile Subscriber Identity (IMSI) in ear-
lier protocol standards, like 4G-LTE (Long Term Evolution).
The HN is the Mobile Network Operator (MNO) who
registered the UE subscriber. The SN refers to the MNO
where the UE enters into its cell area to get roaming service.
Fig. 2 shows the details of the architecture according to
5G standards. Since a 5G core network has a service-based
architecture (SBA), new entities have been defined. Some
of the new entities relevant to 5G authentication are the
following:
• SEAF
• AUSF
• UDM
• ARPF
• SIDF

It is important to note that f1 is used as message authen- FIGURE 2. The 5G entities involved in the authentication process.
tication function while the others are used as key generating
function. The key is the USIM internal key which is shared by We can see that the SN is composed of two elements: gNB
the HN. To our best knowledge, the inner structure of these and SEAF. The former, Next Generation NodeB (gNB), is a
functions is not publicly known. Further, they are operator- base station that provides radio access network for the UE.
dependent, whereby each operator creates and customizes its The latter, Security Anchor Function (SEAF), is an element
own primitive functions. which acts as a mediator between the UE and its HN during
the authentication process. It mainly relies on the UE’s HN to
B. 5G AKA PROTOCOL accept or reject the authentication.
In this section, we provide a brief description of the latest ver- The other entities are located on the HN side. The Authen-
sion of AKA protocol, i.e., 15.4.0 [2]. We ignore the details tication Server Function (AUSF) authenticates a subscriber
about message encryption/decryption and mainly focus on and makes decisions regarding UE authentication based on
the message sequences. The participants of the protocol, the backend service for computing the authentication data
which are shown in Fig. 1, are composed of the following and key code materials. Unified data management (UDM)
entities: is an entity that supplies the main functions corresponding to
• The User Equipment (UE) data management, such as ARPF and SIDF. The Authentica-
• The Home Network (HN) tion Credential Repository and Processing Function (ARPF)
• The Serving Network (SN) choses an authentication method among the three avail-
able options: 5G AKA, EAP-AKA, and EAP-TLS. The
1 Subscriber Identity Module option is selected on the basis of the subscriber identity and

216464 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

configured policy. The Subscription Identifier De-concealing • Impersonation of a legitimate SN by a malicious SN,
Function (SIDF) is responsible for the decryption of the if the authentication is not fully verified by the UE.
Subscription Concealed Identifier (SUCI) to obtain the SUPI. Basically, this originates from the fact that the standard
The main assumptions about the communication channels does not specify additional key confirmation rounds, nor
of the protocol are that the UE communicates with a SN does it specify that the subscribers have to wait for this.
through a radio interface, and that the radio interface is This vulnerability has two situations specified in the
assumed to be an insecure channel. Against, communication standard. First, SNs are able to initiate key changes on
between SNs and a HN is based on Internet Protocol (IP), the fly. Second, they are able to switch security contexts,
and this is supposed to be a secure channel. This means that including keys and parameters [9].
the secure channel provides confidentiality, integrity, mutual • An attack compromising an SN can lead to a complete
authenticity, and replay protection, as explicitly mentioned in breach of user privacy. This enables the malicious SN
the standard [2]-[TS33.501,Sec. 5.9.3]. to collect SUCI authentication requests from the UE and
It is worth noting that deployments prior to 5G, such as then capture the Res parameter sent by the UE over an
4G-LTE, had also assumed secure communication channels, insecure channel at a later stage. Combining the data
such as IPSec between HN and SNs [21]. (SUCI, Res) and sending it to the HN results in the
Fig. 3 shows the overall description of the different phases retrieval of the SUPI.
in the basic AKA protocol. The secure channel between the
HN and SN allows credential parameters, such as SUCI, C. BRAEKEN‘S PROTOCOL
KSEAF , hxRes, to securely transmit over this channel. The Fig. 4 shows a high-level description of the Braeken’s proto-
security goals of AKA can be summarized as follows: col. Much like the basic AKA protocol, the secure channel
• Authentication between subscribers and HNs is assumed between the HN and SN to allow the sensitive
• Authentication between subscribers and SNs parameters, such as SUCI, KSEAF , hxRes, to securely transmit
• Authentication between a HN and SN over this interface. The improvements of Braeken’s protocol
• Confidentiality on KSEAF in case of passive attack over basic 5G-AKA are the following:
• Confidentiality on SUPI in case of passive attack
• The SQNs are replaced by random numbers, and the
• Confidentiality on SQN in case of passive attack
USIM is required to generate strong random numbers.
• Protection against anonymity and unlinkability in case
• A mechanism allowing the UE to verify the validity of
of passive attacks the authentication response that comes from both the SN
and the HN (not only the HN, as in basic AKA protocol).

FIGURE 4. Message sequences in Braeken’s protocol.

FIGURE 3. Message sequences in the 5G AKA protocol. The former addresses the first two weaknesses of the AKA
protocol, while the latter eliminates the last two weaknesses.
The main weaknesses of the current 5G AKA can be Further, another contribution of the Braeken’s protocol is the
summarized as follows [11]: reduction of the required communication phases from 8 to 6.
• Tracking of targeted subscribers, which violates
user privacy due to inadequacies, such as MAC or III. PROPOSED PROTOCOL FOR 5G NETWORKS
Synchronization. In this section we first describe the issues regarding our
• Information leakage from a SQN parameter, resulting in design. Then we will go into further details of the proposed
the possibility of activity monitoring attacks [7]. protocol.

VOLUME 8, 2020 216465

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

A. DESIGN CONSIDERATIONS • The user who wants authentication (denoted by UE)

The main ideas that have informed the design of our protocol • The serving network (denoted by SN)
are the following: • The home network (denoted by HN)
• The smart contract of the HN (denoted by SC)
• We consider blockchain as an interface between HNs
and other operators who want to provide roaming ser- Fig. 6 shows the details of the architecture according to
vices to HN subscribers. Since the registration of a 5G elements. In our architecture, the SEAF is responsible
transaction requires the digital signature of the agent for communicating with the blockchain in order to send the
who requests the transaction, all of the authentication authentication request to the HN. The main functionality of
requests coming onto the blockchain have data origin the proposed protocol on the SN side is implemented in the
authentication. It is important to note that both the HN SEAF unit. Thus, this module must be customized to support
and SN must have valid certificates. the blockchain-based authentication. Meanwhile, the gNB
• Since we assume there is an insecure channel between only forwards the UE messages to the SEAF unit and is not
the HN and SN, all messages between these participants directly involved in the authentication process.
are encrypted by suitable asymmetric and symmetric
encryption algorithms. In other words, the transaction
metadata containing the authentication message is
always encrypted. Therefore, anyone who scans the
blocks of a blockchain is incapable of providing any
FIGURE 6. The 5G entities involved in the proposed authentication
information about user sensitive data. protocol.
• We can set up a rigid access control mechanism for
calling the smart contract functions. More specifically, Further, on the HN side, the AUSF module must be cus-
as the owner of the smart contract, the HN is the only tomized to enable blockchain-based authentication. AUSF is
node capable of registering a response transaction to responsible for communicating with the blockchain to get the
authentication requests. authentication request from SEAF and provide the response.
• We allow the HN to be involved in the key derivation The authentication process is done by the UDM, and the final
algorithm by incorporating its random number in session decision is redirected to AUSF.
key generation. In previous 5G AKA protocols, the ses-
sion key was dependent only on the random numbers C. INITIALIZATION
generated by the UE and the SN.
In our proposed model, each HN creates its own smart con-
• The smart contract function responsible for the authen-
tract on a public blockchain. The operator publicly publishes
tication request can verify the freshness of the request.
the address of the smart contract (e.g., through its official
In our protocol, each authentication request has a unique
website). Each SN who wants to offer roaming service to an
identifier, namely req_id, which allows the smart con-
incoming HN’s subscriber communicates via this smart con-
tract to abort repetitive requests and thereby preventing
tract. The use of a public blockchain frees the HN from build-
replay attacks.
ing any infrastructure, thereby following the pay-per-service
• We employ a message sequence consisting of six rounds
business model. Further, it provides an integration platform
of message exchanges similar to Braeken’s protocol in
for the MNOs who want to offer roaming service to each
order to achieve a higher performance.
other.

B. OVERVIEW OF THE PROTOCOL D. MESSAGE SEQUENCES OF THE PROTOCOL

The participants of the protocol are shown in Fig. 5. They The overall design of the protocol is depicted in the schematic
consist of the following: diagram in Fig. 7. It consists of eight messages exchanged
between participants of the protocol. Each message labeled
by a number which identifies a phase of the protocol. In the
following subsections, each phase is described in more
details.

1) PHASE 1: INITIAL REQUEST BY THE SN

The user enters into a foreign network cell and receives an
authentication request to join the SN. This step is triggered
after the UE completes the Radio Resource Control (RRC)
procedure with gNB and sends an Attach Request message to
the Mobility Management Entities (MME). The SN generates
a random number (R1 ) and sends it to the user as well as to
FIGURE 5. Overall architecture of the proposed protocol. its identifier (IDSN ).

216466 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

FIGURE 7. The flow of protocol messages.

2) PHASE 2: INITIAL USER RESPONSE Finally, the SN sends the authentication request, composed
In this phase, the user takes the following steps to compute of req_id, IDSN , and SUCI to the HN by registering a trans-
the SUCI according to Algorithm 1: action request to the smart contract of the HN.
• Generates R2 randomly;
• Encrypts the message composed of SUPI, R1 , R2 , and Algorithm 2 Registering Request of the SN to the Smart
IDSN and, using public key encryption with the public Contract
key of the HN, puts the encrypted result into UIC ; Input: SUCI
• Creates the SUCI response message containing both UIC 1.req_id ← h(IDSN , R1 , IDHN , SUCI)
and its HN identifier (IDHN ). 2. The SN registers the transaction (req_id, IDSN , SUCI)
Then, the user sends the SUCI to the SN.

Algorithm 1 The User Response to the Challenge of the SN 4) PHASE 4: FORWARDING REQUEST TO THE HN
Input: IDSN , R1 Upon receiving the request, the smart contract first checks
the freshness of the request by seeking an authentication
1. Generate random number R2 record with req_id in order to prevent duplicate requests.
2. UIC ← EPKHN (SUPI , R1 , R2 , IDSN ) If the incoming request is determined to be a fresh request,
3. SUCI ← (UIC , IDHN ) it is redirected to the HN agent. Otherwise, the request is
4. Send (SUCI) to the SN rejected and the transaction will be reverted. In summary,
the smart contract function is responsible for prevention of
replay attacks originated from malicious SNs.
3) PHASE 3: REGISTERING REQUEST BY THE SN
Upon receiving the user response, the SN computes the hash 5) PHASE 5: REGISTERING RESPONSE BY THE HN
value of IDSN , R1 , IDHN , and SUCI to obtain a unique iden- Upon receiving the request from the smart contract, the HN
tifier for the authentication request denoted by req id. takes the following actions:

VOLUME 8, 2020 216467

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

• Checks its identifier with the IDHN located in SUCI; Algorithm 3 The HN Response to Authentication Request
• Decrypts UIC with its private key to obtain SUPI, R1 , Input: req_id, IDSN , SUCI
R2 , and IDSN ;
1. Decode SUCI to obtain UIc and IDHN
• Verifies the equality of req_id with the hash result of
2. (SUPI , R1 , R2 , IDSN ) ← DSKHN (UI C )
IDSN , R1 , IDHN , and SUCI.
3. if (req_id 6= h(IDHN , IDSN , R1 , SUCI)) then abort
The authentication process is stopped if any of the above 4. Generate R3
conditions are not satisfied. Otherwise, the SN continues the 5. O ← f1 (K , R1 , (R2 ,R3 ))
with following actions: 6. xMac← f1 (K, (O,IDSN ))
• Generates a random number R3 ; 7. xRes← challengeK (O, IDSN )
• Produces O by feeding R1 , R2 and R3 into f1 ; 8. hxRes← h(R1 , xRes)
• Calculates the xMac of the message by feeding O and 9. KSEAF ← keyseedK (O, IDSN )
IDSN into keyed f1 ; 10. EK← EPKSN (ExRes (KSEAF , SUPI))
• Calculates the xRes using the keyed challenge function 11. HN_R← ER2 (R3 )
with O and IDSN as inputs; 12. res_id ← h(hxRes, xMac, EKC )
• hxRes is generated as the hash result of R1 and xRes; 13. HN registers the transaction (EKC , xMac, hxRes, req_id,
• Computes KSEAF by feeding O and IDSN into the res_id, HN_R)
keyseed function;
• Produces EK with double encryption. First, through
symmetric encryption of the session key and SUPI with • Computing O by feeding the parameters R1 , R2 , and R3
xRes; second, through asymmetric encryption of the into f1 ;
result with a public key of the SN; • Creating Mac using keyed f1 with the inputs O and IDSN .
• Generates HN_R by symmetric encryption of R3 with
Then, the user checks the above Mac with the xMac
key R2 ; received from the SN. The authentication fails if the Mac
• Creates a unique identifier for the response message,
does not match with xMac. Otherwise, the response is
known as a res_id, by getting the hash result of hxRes, non-tampered and the authentication is accepted. Then the
xMac and EK values. user continues with the following steps:
Note that f1 , challenge, and keyseed are the primitive cryp- • Calculates the Res using the challenge function with
tographic functions defined on the HN and they are embedded inputs O and IDSN ;
in the USIM card. • Obtains the session key using the keyseed function with
It is worth noting that since EK is obtained through the inputs O and IDSN ;
encryption of user information with key xRes, user-related
information is accessible to the SN only after successful Finally, the Res is sent back to the SN.
authentication. Note that R3 is encrypted by using R2 as an
encryption key because it is the only way that a subscriber Algorithm 4 User Response to the SN
can easily obtain R3 . Input: xMac, HN_R
Finally, the HN registers a transaction on the blockchain 1. R3 ← DR2 (HN _R)
containing EK, xMac, hxRes, req_id, res_id, and HN_R using 2. O ← f1 (K, R1 , (R2 ,R3 ))
the corresponding smart contract function. 3. if (xMac 6= f1 (K , O,IDSN )) then abort
4. Res← challengeK (O, IDSN )
6) PHASE 6: REDIRECTING THE RESPONSE TO THE SN 5. KSEAF ← keyseedK (O, IDSN )
In this step, the smart contract can check whether the message 6. Send Res to the SN
sender is the owner of the smart contract. We can put a
condition that only the HN is allowed to register a response Upon receiving the user response, the SN computes the
transaction to the smart contract. hash of Res and compares it with hxRes. If the check is true,
the user is authenticated by the SN. Now, the SN is able to
7) PHASE 7: RESPONSE OF THE SN TO THE UE decrypt EK, first by symmetric decryption using Res and then
The SN receives the HN response via the corresponding smart by asymmetric decryption of the result using its private key
contract function. It then redirects xMac and HN_R parts to to obtain KSEAF and SUPI, respectively. From now, the user
the user. The SN saves the other parts to use them after it can communicate with the SN using the established session
receives a response from the user. key KSEAF .

8) PHASE 8: FINAL RESPONSE OF THE USER TO THE SN IV. SECURITY PROOF

The user takes the following action when receiving the SN A. PROVERIF
response: We use a formal method to prove the security of the pro-
• Decrypting HN_R using R2 as key to obtain R3 ; posed protocol. The message exchanging is modeled by

216468 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

ProVerif [22], a well-known cryptographic protocol verifier. access the messages exchanged over this channel. Further,
ProVerif is designed for the analysis of secrecy and authenti- the attacker is assumed to be passive in many threat models.
cation properties. This is particularly beneficial in the domain This means the attacker is unable either to edit an existing
of computer security. Additional properties, such as privacy, message or to inject a new message into the channel.
traceability, and verifiability, can also be verified using
ProVerif.
C. PROTOCOL MODELING
The modeling consists of three main parts: declarations, pro-
B. THREAT MODEL AND SECURITY REQUIREMENTS
cess macros, and the main process, which will be described
The security goals of the proposed protocol consist of two
in more detail below. For the HN and SN, we consider the
parts: authentication of the participants and secrecy of sen-
generation of a public and private key pair. To begin with,
sitive data. As in 5G-AKA, in the authentication of the
the key pair is used for the encryption and decryption of the
participants we seek to provide the following:
message. Second, we use the key pair for message signing and
• Authentication between subscribers and HNs verification. Note that the proposed protocol does not directly
• Authentication between subscribers and SNs use the digital signature in its message sequences. This is
• Authentication between HNs and SNs implicitly done by the participants when the transaction is
As for the secrecy of sensitive data, we investigate the registered in the blockchain. More specifically, it is done
following properties: either when the SN registers the authentication request or
• Confidentiality of KSEAF in case of active/passive when the HN registers the authentication response.
attacks
• Confidentiality of SUPI in case of active/passive attacks
1) DECLARATIONS
• Confidentiality of R2 and R3 in case of active/passive
The declaration part includes three sections: the section for
attacks
user-defined types, the section for the definition of objects,
• Confidentiality of USIM pre-shared key
and the section where constructors are defined. In the first
• Protection against unlinkability in case of active/passive
part, privateKey and publicKey indicate the private and pub-
attacks
lic key pair used for the asymmetric encryption and digital
The confidentiality of KSEAF and SUPI are the same as signature. While Key and UEKey are the types used for the
5G-AKA except that we consider both passive and active symmetric encryption key.
attacks. The third item considers the confidentiality of ran- In the second part, the first two statements declare a cou-
dom numbers generated by the UE and the HN. Actually, ple of communication channels: airChannel and bcChannel,
these numbers replace the simple incremental counter, which are used for modeling the channel between the UE and
namely SQN, in 5G-AKA which is generated by the HN. The SN and the channel between the SN and HN, respectively.
secrecy of SUPI and USIM Internal key aims to preserve the The concept of a free statement in ProVerif is the same
privacy of the end user. as that of global scope in programming languages; that is,
As for the features related to ability of the attacker, these free names are known globally to all processes. The object
can be summarized as follows: definition is terminated with an access method identified by
• The interface between the SN and HN are considered either [public] or [private] keywords. The objects that are
as a public channel in addition to the radio interface not known by the attacker must be declared private, while
between the UE and SN. This means that an attacker the ones that are known by the attacker are declared public.
can eavesdrop on all messages exchanged over these By default, the access method is public (i.e., when it is not
channels. explicitly declared, the tool considers it as public).
• We consider an active attacker model, that is the attacker The presence of free statements with a public access
can inject a new message into a public channel or can method in the definition of airChannel and bcChannel indi-
save a message for future use. Since both the channels cates that both the channels are known by the attacker as
used in the protocol are public, the attacker can act as well as he/she can eavesdrop any message exchanged over
the HN, the SN or the UE. In practice, an active attacker them. This definition reflects the realistic assumption about
could set up a fake base station to send and receive the communication channel between HN and SN which is
signaling messages and thereby impersonating SNs. provided by the public blockchain. Since in public blockchain
• The attacker can request to run many instances of the each desired node can join to the blockchain network and acts
protocol to investigate the interleaving attacks. as a full node and accordingly has access to transaction data
The only limitation of the attacker is in accessing key as well as smart contract functions.
materials. That is, the attacker has no access to the pre-shared The objects SUPI, K , KSEAF , R3 , and R2 respectively
key in USIM, the private key of the HN, or the private key of denote the USIM unique identifier, the USIM internal key,
the SN. It is worth noting that in current 5G AKA modeling the session key, the HN, and the SN random numbers. The
(like in [9] and [11]) the channel between the SN and HN keyword [private] in their definition implies that each one is
is assumed to be secure, and accordingly the attacker cannot private and thus cannot be accessed by the attacker.

VOLUME 8, 2020 216469

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

Algorithm 5 Type, Object and Function Definitions In our model, these processes correspond exactly to the pro-
type UEKey. posed protocol given in Fig. 7 with the slight difference that
type Key. some unnecessary details are omitted. Note that instead of
type publicKey. modeling the blockchain or smart contract as a process macro,
type privateKey. they are modeled by the communication channel bcChannel.

free bcChannel:channel. (∗ Public∗ ) Algorithm 6 The SN Process

free airChannel:channel. (∗ Public∗ ) let SN(IDSN :bitstring, IDHN :bitstring, pkHN : publicKey,
free SUPI:bitstring [private]. pkSN : publicKey, skSN : privateKey) =
free K :UEKey [private]. new R1 :bitstring;
free KSEAF :bitstring [private]. event SNSendReqToUE;
free R3 :bitstring [private]. out(airChannel, (R1 ,IDSN ));
free R2 :bitstring [private]. in(airChannel, SUCI:bitstring);
let recv_idHN = decode(SUCI) in
fun hash(bitstring):bitstring. if recv_idHN = IDHN then event SNRecvUERes(SUCI);
fun mKey (bitstring): Key. let req_id = hash((IDHN , R1 , IDSN , SUCI)) in
fun pk (privateKey): publicKey. let SignSN = sign(req_id, skSN ) in
fun pkiEnc (bitstring, publicKey): bitstring. event SNSendReqToHN(req_id);
reduc forall m: bitstring, k: privateKey; pkiDec (pkiEnc out(bcChannel, (req_id, SignSN, SUCI));
(m, pk (k)), k) = m. in(bcChannel, (EKC :bitstring, xMac:bitstring,
fun symEnc (bitstring, Key): bitstring. hxRes:bitstring, SignHN : bitstring, res_id: bitstring,
reduc forall m: bitstring, k: Key; symDec (symEnc (m, k), HN_R:bitstring));
k) = m. let (=pkHN , veri_req_id:bitstring, veri_res_id:bitstring) =
fun sign (bitstring, privateKey): bitstring. checksign(SignHN , pkHN ) in
reduc forall m:bitstring, k: privateKey; checksign(sign(m, k),
pk (k)) = m. if (veri_res_id = res_id) then if (veri_req_id = req_id)
fun decode(bitstring): bitstring. then event SNRecvHNRes(SignHN );
fun f1 (UEKey, bitstring, bitstring): bitstring. event SNSendReq2ToUE(xMac);
fun challenge(UEKey, bitstring, bitstring): bitstring. out(airChannel, (xMac, HN_R));
fun keyseed(UEKey, bitstring, bitstring): bitstring. in(airChannel, Res:bitstring);
if hxRes = Res then event SNRecvUERes2;
let EK = pkiDec (EKC , skSN ) in
let session_info = symDec (EK, mKey (Res)) in
The third portion defines function symbols including both let sn_KSEAF = decode(session_info) in
constructors and destructors. In ProVerif, each constructor let sn_SUPI = decode(session_info).
builds required terms for modeling a particular primitive
of cryptographic protocols. In our protocol, hash, symEnc, The SN process is explained in Algorithm 6. The SN starts
symDec, pkiEnc, pkiDec, sign and getPK are the constructors, the protocol by selecting a random number R1 and puts the
which respectively model cryptographic hash functions, sym- pair (R1 , IDSN ) igon the interface airChannel, waiting for a
metric encryption, symmetric decryption, public-key encryp- user response. Upon receiving a response from the UE, the SN
tion, digital signature, and returning the public key of a secret computes req_id using hash function and SignSN by digital
key. signature. Then, the SN puts req_id, SignSN and SUPI on the
The relationship between cryptographic primitives are cap- interface bcChannel and waits for the HN response.
tured by destructors which manipulate terms formed by con- Upon receiving the HN response, the SN picks (xMac,
structors. In our protocol, pkiDec, symDec and check_sign are HN_R) from the message and puts them on the interface
the destructors which respectively model public-key decryp- airChannel, waiting for user response. In receiving the user
tion, symmetric key decryption, and signature verification response Res, the SN compares the Res with the hxRes
algorithms. received from the HN. In the case of a match, the authenti-
cation is accepted, and accordingly the SN is able to retrieve
2) PROCESS MACROS KSEAF and SUPI from the HN response.
Instead of encoding the protocol in a single main process, Similarly, the UE and HN processes, which are explained
we use sub-processes to declare interactions between each in Algorithm 7 and Algorithm 8, respectively, act and interact
participant. Since the protocol has three participants as active with the other processes. The main process is the starting
players, in addition to the main process, three macros are point of the protocol. It initializes the protocol by setting up
defined: SN, UE and HN process. Each process identifies the the key material, communication channels, and then invoking
act of the corresponding participant to the events occurred. the participant process.

216470 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

Algorithm 7 The User Process Algorithm 8 The HN Process

let UE(IDHN :bitstring, pkHN : publicKey, K : UEKey, let HN(IDHN :bitstring, IDSN :bitstring, pkHN : publicKey,
SUPI:bitstring)= skHN : privateKey, pkSN :publicKey,K: UEKey)=
in(airChannel,(R1 :bitstring, IDSN :bitstring)); in (bcChannel, (req_id: bitstring, signSN : bitstring,
event UERecvSNReq(IDSN ); SUCI:bitstring));
(∗ new R2 : bitstring;∗ ) let (=pkSN , veri_req_id:bitstring) = checksign(signSN , pkSN )
let UI = pkiEnc ((SUPI,R1 ,R2 ,IDSN ), pkHN ) in in
let SUCI = (UI, IDHN ) in
event UESendResToSN(SUCI); if veri_req_id = req_id then event
out(airChannel, SUCI); HNRecvSNReq(req_id,signSN );
in(airChannel,(xMac:bitstring, HN_R:bitstring)); let UI = decode(SUCI) in
let ue_R3 = symDec (HN_R, mKey (R2 )) in let dec_UI = pkiDec (UI, skHN ) in
let O = f1 (K , R1 ,(R2 , R3 )) in let HN_R2 = decode(dec_UI) in
let Mac = f1 (K , O, IDSN ) in let R1 = decode(dec_UI) in
if Mac = xMac then event UERecvSNReq2(xMac); let HN_SUPI = decode(dec_UI) in
let Res = challenge(K,O,IDSN ) in (∗ new R3 :bitstring; ∗ )
let ue_KSEAF = keyseed(K,O,IDSN ) in let O = f1 (K, R1 , (HN_R2 , R3 )) in
event UESendRes2ToSN(Res); let xMac = f1 (K, O, IDSN ) in
out(airChannel,Res). let xRes = challenge(K, O, IDSN ) in
let hxRes = hash((R1 ,xRes)) in
let HN_KSEAF = keyseed(K, O, IDSN ) in
As shown in Algorithm 9, the main process, which begins let EK = symEnc ((HN_KSEAF , HN_SUPI), mKey(xRes)) in
by the keyword process, generates the private asymmetric let EKC = pkiEnc(EK, pkSN ) in
keys skSN and skHN for the principal SN and HN, respec- let HN_R = symEnc (R3 , mKey (R2 )) in
tively. The corresponding public keys are derived by invoking let res_id = hash((hxRes, xMac, EKC )) in
getPK(skSN ) and getPK(skHN ). Then, the results are revealed let SignHN = sign((req_id, res_id), skHN ) in
on the public interfaces bcChannel and airChannel, ensuring event HNSendResToSN(req_id,res_id);
that the public keys are accessible by any attacker. Further, out(bcChannel, (EKC , xMac, hxRes, SignHN , req_id, res_id,
it generates the identifiers IDHN and IDSN respectively for HN_R)).
the principals SN and HN.
Finally, the main process instantiates multiple copies of the
HN, SN, and UE macros with the corresponding parameters privacy of the end user. Further, the secrecy of KSEAF , R3 ,
serving as multiple sessions for each principal. It provides R2 , and K presupposes the confidentiality of either pre-shared
the benefits of multiple concurrent sessions for the attacker key (USIM internal key) or credential information.
to investigate the possibility of interleaving attacks. In addition to secrecy, ProVerif can check authentication
properties. Authentication can be captured by corresponding
3) SECURITY PROPERTIES assertions which are used to capture relationships between
ProVerif attempts to prove that a state in which a secu- events. This is expressed in the form of ‘‘if an event e
rity property is violated is unreachable. Indeed, ProVerif has been executed, then event e0 has been previously exe-
can prove reachability properties, correspondence assertions, cuted’’. Annotating the process with events marks important
and observational equivalence. It also facilitates checking stages reached by the protocol but which do not affect other
whether a specific term is available to an attacker; and accord- behavior. In our protocol, we have six pairs of events:
ingly, the secrecy of terms can be evaluated with respect to a • (SNSendReqToUE, UERecvSNReq)
model. • (UESendResToSN, SNRecvUERes)
A security property is defined by the statement ‘‘query • (SNSendReqToHN, HNRecvSNReq)
attacker(M)’’ to test the secrecy of term M in the model. • (HNSendResToSN, SNRecvHNRes)
Note that M is a ground term, which is likely private and • (SNSendReq2ToUE, UERecvSNReq2)
not initially known to the attacker. We consider the following • (UESendRes2ToSN, SNRecvUERes2)
attacks: The events in first pair indicate the sending of the request
• Attack on SUPI to the UE by the SN and the reception of this request by
• Attack on session key the UE. These events can be bound together by an inj-event
• Attack on the random number of UE and HN statements. This is done by the first query statement in main
• Attack on USIM internal key process. This means that before event UERecvSNReq, event
• Attack on subscriber information SNSendReqToUE must be raised. This binding imposes an
We define six security properties: secrecy of SUPI, KSEAF , order on the sequence of message exchanged by the SN and
R2 , R3 , and K . The secrecy of SUPI aims to preserve the the UE.

VOLUME 8, 2020 216471

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

Algorithm 9 Security Properties and the Main Process • RESULT not attacker (R3 []) is true.
query attacker (SUPI). • RESULT not attacker (R2 []) is true.
query attacker (KSEAF ). • RESULT not attacker (K []) is true.
query attacker (R3 ). The above results show that the secrecy of SUPI, KSEAF ,
query attacker (R2 ). R3 , R2 , and K are preserved by the protocol and there is no
query attacker (K ). information leakage for these sensitive data.
Further, for the authentication properties of the proposed
query x:bitstring; event(UERecvSNReq(x)) ==> protocol, the verification results are as follows:
event(SNSendReqToUE).
query x:bitstring, y:bitstring; event(SNRecvUERes(x)) • RESULT event (UERecvSNReq(x)) ==> event
==> event(UESendResToSN(y)). (SNSendReqToUE) is false.
query x:bitstring, y:bitstring, z:bitstring; • RESULT event (SNRecvUERes(x)) ==> event
event(HNRecvSNReq(x,y)) ==> (UESendResToSN(y)) is true.
event(SNSendReqToHN(z)). • RESULT event (HNRecvSNReq(x,y)) ==> event
query x:bitstring, y:bitstring, z:bitstring; (SNSendReqToHN(z)) is true.
event(SNRecvHNRes(x)) ==> • RESULT event (SNRecvHNRes(x)) ==> event
event(HNSendResToSN(y,z)). (HNSendResToSN(y,z)) is true.
query x:bitstring, y:bitstring; event(UERecvSNReq2(x)) • RESULT event (UERecvSNReq2(x)) ==> event
==> event(SNSendReq2ToUE(y)). (SNSendReq2ToUE(y)) is true.
query x:bitstring; event(SNRecvUERes2) ==> • RESULT event (SNRecvUERes2) ==> event
event(UESendRes2ToSN(x)). (UESendRes2ToSN(x)) is true.
process This indicates that all of the authentication properties,
new skHN : privateKey; except the first one, are satisfied by the protocol.
new skSN :privateKey; By tracing the verification result of the first message,
new IDHN :bitstring; we can see that any attacker can act as a SN by generating
new IDSN :bitstring; a correct message for the first phase of the protocol. This
let pkHN = pk(skHN ) in out (airChannel, pkHN ); is because the attacker can pick up a random R1 and send
let pkSN = pk(skSN ) in out (bcChannel, pkSN ); it along with the IDSN to the subscriber. It should be noted
(!SN(IDSN , IDHN , pkHN , pkSN , skSN )| that there are no shared secrets between the subscriber and the
!HN(IDHN , IDSN , pkHN , skHN , pkSN , K )| SN to enable the integrity of the first message of the protocol.
!UE(IDHN , pkHN , K, SUPI)) The only option for enabling the authentication of the SN in
the first message is that the SN adds its digital signature to the
request. This solution, which requires a signature verification
In a similar way, the other pairs of events are bound from the subscriber, is still vulnerable to a replay attack, since
together with a query statement in the main process. ProVerif the attacker can eavesdrop on the radio interface and collect
can check whether the bindings are satisfied during the exe- SN authentication requests sent to subscriber. The attacker
cution of the protocol. Thus, reaching the state of the protocol can pick up one of these requests and send it to the intended
to the point of SNRecvUERes2 means that the required mes- subscriber. Thus, as in 5G AKA, we ignore this security
sages are exchanged by the participants. Further, the authen- property in our protocol.
tication is hold if the last message is successfully verified by Note that except for the first phase of the protocol,
the user. the attacker cannot violate the authentication properties of
the other phases. The message between the SN and HN are
D. VERIFICATION RESULTS protected by the digital signature of the sender as well as the
The results of each ProVerif query statement is presented by public key encryption. Further, the integrity of the messages
one of these arguments: between the UE and HN is protected by the pre-shared key K
• RESULT [Query] is true: It means that the query is and public key encryption.
proved, and there is no attack.
• RESULT [Query] is false: It means that the query is V. EVALUATIONS
false, and that ProVerif has discovered an attack against In this section, we evaluate the performance of the pro-
the specified security property. posed protocol. We begin by explaining the implementation
• RESULT [Query] cannot be proved: This is a ‘‘don’t of smart contract functions. Next, to provide experimental
know’’ answer. results, we use the Ethereum blockchain [23], where the
The verification results of the secrecy properties of the pro- block generation time is approximately 12 seconds. We then
posed protocol are summarized as follows: present an analysis of the smart contract functions in terms
• RESULT not attacker (SUPI[]) is true. of execution and transaction costs. Finally, we compare the
• RESULT not attacker (KSEAF []) is true. proposed protocol with well-known prior work.

216472 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

A. SMART CONTRACT FUNCTIONS Algorithm 10 Solidity Code for Smart Contract Functions
Since, the smart contract acts as an interface between SN and pragma solidity ^0.5.1;
HN, it has two functions that facilitate a bidirectional channel contract AuthenticationContract
for exchanging messages between SN and HN. The opera- {
tions of these functions are respectively corresponding to the address owner;
phase 4 and phase 6 of the protocol. Algorithm 10 shows constructor() public
the implementation of these functions in Solidity, an object- { owner = msg.sender; }
oriented, high-level language for implementing smart con- struct AuthToken{
string res_id;
tracts [24]. Further, there is a data structure, namely
string EK;
AuthToken, for storing the information of authentication
string xMac;
requests and responses. The function SetSNRequest is respon-
string hxRes;
sible for processing authentication request while SetHN- string signHN ;
Response handles the authentication response. The former string HN_R;
receives the SN request, including req_id, signSN , IDSN , and string signSN ;
SUCI as inputs, creates an AuthToken object and initializes string IDSN ;
it by the input parameters. Then it puts the new object into string SUCI;
a data map structure where the req_id acts as the key of the bool active;
map. Finally, it receives the access fee in GAS. }
The latter is invoked by the HN to register the response of mapping(string => AuthToken) private MAP;
the authentication request. It searches the map for an AuthTo- function SetSNRequest (
ken object whose key is equal to the input parameter req_id. string memory req_id,
It sets the value of corresponding fields if the target object string mqemory signSN ,
is found. Otherwise, it returns an error and the transaction is string memory IDSN ,
aborted. string memory SUCI)
Note that the first line in SetHNResponse implies that public payable returns (string memory)
the sender of the transaction can only be the owner of the {
smart contract. That is, anyone other than the HN is unable if (MAP[req_id].active)
to register a transaction whose destination is the address return ‘‘Error!’’;
of SetHNResponse. This restriction is another security fea- MAP[req_id] = AuthToken ({signSN , IDSN , SUCI,
ture which prohibits an attacker from acting as the HN and true, EK:‘‘’’, xMac:‘‘’’, hxRes:‘‘’’, signHN:‘‘’’, res_id:‘‘’’,
registering a response transaction. HN_R:‘‘’’});
return ‘‘Done’’;
}
function SetHNResponse (
B. PERFORMANCE ANALYSIS
string memory EK,
string memory xMac,
The computing energy required to process and validate trans-
string memory hxRes,
actions on the Ethereum blockchain is measured by means of string memory signHN,
gas. A higher gas limit means more work to execute a trans- string memory req_id,
action or a smart contract. The gas is paid by the end user who string memory res_id,
registers the transaction to allocate resources of the Ethereum string memory HN_R)
virtual machine in order that decentralized applications such public returns(string memory)
as smart contracts can self-execute in a secured manner. Gas {
prices are denoted in small fractions of ether called gwei. One require (msg.sender==owner);
ether is equal to 109 gwei. AuthToken memory Tok = MAP[req_id];
Table 2 shows the results of the smart contract implementa- if (Tok == NULL)
tion on the Ethereum blockchain. Here, we focus on both Set- return ‘‘Error’’;
SNRequest and SetHNResponse functions. The cost of each Tok.EK = EK;
function depends on both the message size and instructions Tok.xMac = xMac;
executed. As shown in Table 2, the cost is paid for both Tok.hxRes = hxRes;
transaction registration and function execution. Tok.signHN = signHN;
To evaluate different security levels, we consider two spe- Tok.res_id = res_id;
cific hash functions: SHA-1 with 20-byte output and SHA-2 Tok.HN_R = HN_R;
with 32-byte output. For symmetric encryption, we use AES Tok.active = false;
with a 128-bit key. The output of each encryption block is return ‘‘Done’’;
16 bytes. For identifiers such as IDSN and SUCI, we assume }
a binary string of 16 bytes in length. }

VOLUME 8, 2020 216473

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

TABLE 2. Transaction and execution costs of smart contract functions encrypts the permanent identifier before it is sent over the
(1 gas =10−9 ETH).
radio interface. Second, the HN (i.e., the AUSF) makes the
final decision on the UE authentication. Finally, results of
authentication are sent to the UDM to be logged.
However, 5G-AKA, as currently stated in Sec. II, has the
following vulnerabilities:
• Information leakage from SQN parameter;
• Tracking of targeted subscribers due to different failure
in MAC or Synchronization;
• Impersonation of a malicious SN as a legitimate SN;
• Compromising of an SN by an attacker can lead to a
We can see that the hash algorithm does not have a sig-
nificant impact on the cost paid for SetHNResponse function. complete breach of user privacy.
But, in the SetSNRequest function, the transaction and exe- The SQN mechanism was mainly designed for replay pro-
cution costs of SHA-2 is about 10% higher than the costs for tection in 3G when the USIM is too limited to produce good
SHA-1. pseudo random numbers. Nowadays, this is no longer true
in 5G, since USIMs can generate good pseudo random num-
C. COMPARISON TO PRIOR WORK bers in addition to handling asymmetric encryption. Thus, our
protocol, similar to [11], uses a standard challenge-response
Table 3 presents a brief comparison of our proposed protocol
mechanism to replace the SQN counters. More specifically,
to well-known previous protocols for authentication, includ-
all participants, namely the SN, UE and HN, generate the
ing 4G-AKA, 5G-AKA, and Braeken’s protocol [11]. The
random numbers R1 , R2 , and R3 , respectively, which involve
4G-AKA (also referred as EPS-AKA2 ) has two weaknesses:
a challenge-response mechanism as well as a derivation of
• The UE always sends its permanent identifier in clear
the session key. The elimination of SQN also avoids any
text to the network, allowing it to be stolen by either a de-synchronization attacks between the user and HN.
malicious network or a passive adversary over the radio The last two weaknesses are eliminated by the modification
interface; in message encryption. First, the UE verifies the validity of
• The HN is consulted during authentication only to gen-
the authentication response received from the SN. Second,
erate authentication vectors; it does not make decisions the SN which receives an encrypted message, composed of
on the authentication results. a SUPI and session key, is only capable of decrypting the
message when it satisfies two conditions: 1) owning the
TABLE 3. Comparison with other protocols.
private key of the SN and 2) reception of a commitment from
the UE, by Res parameter, which approves the authentication
response.
We should point out that our protocol, by virtue of existing
on a blockchain, has some odd features. It is inherently
distributed, thus DoS attacks against the HN cannot occur
during the running of the protocol. Further, it is auditable,
and the legitimate nodes, including both the HN and SN, can
obtain information on authentication requests and responses
by scanning the blockchain transactions and decrypting the
messages. As a result, undeniability of both requests and
responses are satisfied by the proposed protocol, while this
is not supported by either 5G-AKA or Braeken’s protocol.
However, using blockchain has some side effects. The
major drawback of blockchain is the transaction delay, which
imposes an inevitable latency on the whole system. For exam-
ple, on the Ethereum platform, the transaction delay is about
12 seconds. Since we need two transactions at every run of the
protocol, the total delay is 25 seconds. Although this transac-
tion delay is considerable compared to non-blockchain AKA
protocols, it is a reasonable trade-off when we consider the
issues not supported by the other protocols. Moreover, using
Both the mentioned weaknesses have been resolved by a private blockchain, such as Hyperledger, can reduce the
5G-AKA. First, the UE uses the public key of the HN and transaction time by restricting the set of full nodes. In this
solution, each HN sets up its own blockchain network with a
2 Evolved Packet System Authentication and Key Agreement small set of full nodes to run the consensus algorithm.

216474 VOLUME 8, 2020

M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

Unlinkability against an active attacker is another feature by different operators including terrestrial, aerial, and even
that is satisfied by our protocol. As the authors mentioned satellite. Our scheme can facilitate the authentication of users
in [24], linkability attacks can be seen in current LTE protocol in such sophisticated B5G networks as outlined below:
and earlier versions of it. Further, Basin’s privacy analysis • It has a decentralized and fault tolerant architecture
shows that the 5G AKA fails to ensure unlinkability against which is secure against DoS, DDoS and replay attacks,
an active attacker [9]. In our protocol, unlinkability against • It is highly protected against malicious SNs which would
active attacker is originated from the confidentiality of the have likely appeared in VHetNet framework,
SUPI which only an authenticated SN can reveal it at the end • By means of blockchain it provides a platform to connect
of a successful run. Otherwise, SUPI cannot be exposed to a different type of operators,
malicious SN. • It provides an auditable log for tracking abnormal
Furthermore, the proposed protocol is far from the assump- activities.
tion for secure channel between the HN and SN which is a
primary requirement of the previous protocol and many vul- VII. CONCLUSION
nerabilities may be ignored by this assumption. This feature We proposed a novel AKA protocol for roaming service in 5G
is the result of encrypting the exchanged messages which mobile networks. The protocol uses blockchain to commu-
are located in the metadata of transactions on the public nicate messages between the HN and SN. The protocol was
blockchain. From a practical point of view, there is no need designed in order to leverage the benefits of blockchain,
for the HN to establish a secure session with the SN for including its undeniable and auditable logs and its preser-
message exchanging. vation of privacy. Further, the protocol eliminates the need
Finally, the public nature of the blockchain provides an for a secure communication channel between the HN and
opportunity to use digital currency for service payments. SN. We proved the security of the protocol with a formal
In this scenario, the UE, which receives service from the SN, verification procedure. The protocol was modeled in ProVerif
can pay for the cost of service directly to the SN, thereby and successfully verified the secrecy of sensitive data as
avoiding an otherwise complex financial transaction process well as the authentication of the participants. The evaluation
and cleaning room between the HN and SN. results on the Ethereum blockchain showed that the cost of
implementation in GAS are acceptable.
VI. APPLICATION TO AERIAL NETWORKS
Various forms of aerial base stations have started receiving REFERENCES
substantial attention in a wide range of applications since [1] D. Fang, Y. Qian, and R. Q. Hu, ‘‘Security for 5G mobile wireless net-
they have the potential of providing enhanced and seamless works,’’ IEEE Access, vol. 6, pp. 4850–4874, 2018.
connectivity in 5G and beyond (B5G) networks. Due to their [2] Security Architecture and Procedures for 5G System, document TS 33.501,
3GPP, May 2019.
3D-mobility and adaptable altitude, aerial base stations can
[3] P. Ahokangas, M. Matinmikko-Blue, S. Yrjölä, V. Seppänen,
efficiently support the connectivity of both terrestrial and H. Hämmäinen, R. Jurva, and M. Latva-Aho, ‘‘Business models for
aerial users (such as cargo drones). Based on the operation local 5G micro operators,’’ IEEE Trans. Cognit. Commun. Netw., vol. 5,
altitudes, two main types of aerial base stations are distin- no. 3, pp. 730–740, Sep. 2019.
[4] Y. Siriwardhana, P. Porambage, M. Liyanage, J. S. Walia,
guished, the ones deployed on Unmanned Aerial Vehicles M. Matinmikko-Blue, and M. Ylianttila, ‘‘Micro-operator driven local
(UAVs) and those in the form of High-Altitude Platform 5G network architecture for industrial Internet,’’ in Proc. IEEE Wireless
Station (HAPS) systems. UAVs operate at low altitudes of Commun. Netw. Conf. (WCNC), Apr. 2019, pp. 1–8.
[5] P. Hegedũs, ‘‘Towards analyzing the complexity landscape of solid-
around a few hundred meters and act as flexible and agile ity based ethereum smart contracts,’’ Technologies, vol. 7, no. 1, p. 6,
nodes in the form of mere relays or fully fledged base stations Jan. 2019.
(UAV-BSs, referred to as UxNB in recent 3GPP documents [6] Internet Key Exchange Protocol Version 2 (IKEv2), document RFC 7296,
IETF, 2014. [Online]. Available: https://tools.ietf.org/html/rfc7296
such as TR 22.829); in contrast, HAPS systems operate at [7] R. Borgaonkar, H. Lucca, P. Shinjo, and S. Altaf, ‘‘New privacy threat on
higher altitudes of 8 to 50 km above the ground (TR 38.811). 3G, 4G, and upcoming 5G AKA protocols,’’ in Proc. Privacy Enhancing
It is envisioned that HAPS systems will facilitate 3D high- Technol., no. 3, 2019, pp. 108–127.
[8] M. Liyanage, J. Salo, A. Braeken, T. Kumar, S. Seneviratne, and
ways which may drive a disruptive transformation in the retail M. Ylianttila, ‘‘5G Privacy: Scenarios and Solutions,’’ in Proc. IEEE 5G
industry [25]. HAPS systems also allow wider coverage areas World Forum, Jul. 2018, pp. 197–203.
and longer flight times compared to UAV-BSs. In practice, [9] D. Basin, J. Dreier, L. Hirschi, S. Radomirovic, R. Sasse, and V. Stettler,
‘‘A formal analysis of 5G authentication,’’ in Proc. ACM SIGSAC Conf.
HAPS can act as a super macro base station to provide Comput. Commun. Secur., Jan. 2018, pp. 1383–1396.
connectivity in a plethora of applications [26]. [10] S. Meier, B. Schmidt, C. Cremers, and D. Basin, ‘‘The TAMARIN prover
By means of UAV-BSs and HAPS systems, we can set for the symbolic analysis of security protocols,’’ in Proc. Int. Conf. Comput.
up local SNs to provide roaming service in different sit- Aided Verification, Saint Petersburg, Russia, 2013, pp. 696–701.
[11] A. Braeken, M. Liyanage, P. Kumar, and J. Murphy, ‘‘Novel 5G authentica-
uations. Roaming will have a totally new meaning in the tion protocol to improve the resistance against active attacks and malicious
envisioned B5G multi-tier network; this paradigm is referred serving networks,’’ IEEE Access, vol. 7, pp. 64040–64052, 2019.
to as a Vertical Heterogenous Network (VHetNet) in the recent [12] M. Tahir, M. H. Habaebi, M. Dabbagh, A. Mughees, A. Ahad, and
K. I. Ahmed, ‘‘A review on application of blockchain in 5G and beyond
literature [27]. This is a novel wireless access architecture networks: Taxonomy, field-trials,challenges and opportunities,’’ IEEE
in the form of a network of networks owned and managed Access, vol. 8, pp. 115876–115904, 2020.

VOLUME 8, 2020 216475

 M. Hojjati et al.: Blockchain-Based AKA Protocol for 5G Networks

[13] A. Refaey, K. Hammad, S. Magierowski, and E. Hossain, ‘‘A blockchain ALIREZA SHAFIEINEJAD received the B.S.
policy and charging control framework for roaming in cellular networks,’’ degree in computer engineering from the Sharif
IEEE Netw., vol. 34, no. 3, pp. 170–177, May 2020. University of Technology, Tehran, in 1999, and
[14] A. V. Rivera, A. Refaey, and E. Hossain, ‘‘A blockchain framework for the M.Sc. and Ph.D. degrees in electrical engineer-
secure task sharing in multi-access edge computing,’’ IEEE Netw., early ing from the Isfahan University of Technology,
access, Sep. 30, 2020, doi: 10.1109/MNET.011.2000497. Isfahan, Iran, in 2002 and 2013, respectively. Since
[15] Z. Chen, S. Chen, H. Xu, and B. Hu, ‘‘A security authentication scheme 2015, he has been an Assistant Professor with
of 5G ultra-dense network based on block chain,’’ IEEE Access, vol. 6,
Tarbiat Modares University, Tehran, Iran. He is
pp. 55372–55379, 2018.
currently an Assistant Professor with the Depart-
[16] (Dec. 2017). BubbleTone Blockchain. [Online]. Available: https://
coinwoot.com/wp-content/uploads/BubbleTone-Yellow-Paper.pdf. ment of Electrical and Computer Engineering,
[17] A. Idris, A. Khan, and Y. S. Lee, ‘‘Genetic programming and adaboosting Tarbiat Modares University. His research interests include wireless network
based churn prediction for telecom,’’ in Proc. IEEE Int. Conf. Syst., Man, coding, network security, and design and analysis of cryptography algo-
Cybern. (SMC), Oct. 2012, pp. 1328–1332. rithms. At Tarbiat Modares University, he leads research in network security
[18] Study on New Radio (NR) Access Technology Physical Layer Aspects, and penetration test in the Security Evaluation Laboratory (SE-Lab).
document TR 38.802, 3GPP, Mar. 2017.
[19] Y. Zhang, S. He, S. Li, and J. Chen, ‘‘Intra-operator customer churn in
telecommunications: A systematic perspective,’’ IEEE Trans. Veh. Tech-
nol., vol. 69, no. 1, pp. 948–957, Jan. 2020.
[20] Digital Cellular Telecommunications System (Phase 2+) (GSM);Universal
Mobile Telecommunications System (UMTS); 3G Security; Security Archi-
tecture, document ETSI, TS 33.102 version 16.0.0 Release, 3GPP,
Aug. 2020.
[21] M. Liyanage, P. Kumar, M. Ylianttila, and A. Gurtov, ‘‘Novel secure VPN
architectures for LTE backhaul networks,’’ Secur. Commun. Netw., vol. 9,
no. 10, pp. 1198–1215, Jul. 2016.
[22] B. Blanchet, M. Abadi, and C. Fournet, ‘‘Automated verification of
selected equivalences for security protocols,’’ J. Log. Algebr. Program.,
vol. 75, no. 1, pp. 3–51, Feb. 2008.
[23] G. Wood. (Sep. 5, 2020). Ethereum: A Secure Decentralized General-
ized Transaction Ledger, Petersburg Version 3e2c089. [Online]. Available:
https://ethereum.github.io/yellowpaper/paper.pdf
[24] C. Dannen, Introducing Ethereum and Solidity, vol. 1. Berkeley, CA, USA:
Apress, 2017.
[25] N. Cherif, W. Jaafar, H. Yanikomeroglu, and A. Yongacoglu, ‘‘3D aerial
highway: The key enabler of the retail industry transformation,’’ 2020,
arXiv:2009.09477. [Online]. Available: http://arxiv.org/abs/2009.09477
[26] M. S. Alam, G. K. Kurt, H. Yanikomeroglu, P. Zhu, and N. D. Ðào,
‘‘High altitude platform station based super macro base station (HAPS-
SMBS) constellations,’’ 2020, arXiv:2007.08747. [Online]. Available: HALIM YANIKOMEROGLU (Fellow, IEEE) is
http://arxiv.org/abs/2007.08747 currently a Professor with the Department of Sys-
[27] T. Darwish, G. K. Kurt, H. Yanikomeroglu, G. Senarath, and P. Zhu, tems and Computer Engineering, Carleton Uni-
‘‘A vision of self-evolving network management for future intelli- versity, Ottawa, ON, Canada. His current research
gent vertical HetNet,’’ 2020, arXiv:2009.02771. [Online]. Available: interest includes many aspects of 5G/6G wireless
http://arxiv.org/abs/2009.02771 networks. His collaborative research with industry
has resulted in 37 granted patents. He is also a Fel-
low of the Engineering Institute of Canada (EIC)
and the Canadian Academy of Engineering (CAE).
He is also a Distinguished Speaker of IEEE Com-
MAEDE HOJJATI was born in Tehran, Iran, munications Society and IEEE Vehicular Technology Society. He received
in 1993. She received the B.S. degree in com- several awards for his research, teaching, and service, including the IEEE
puter engineering from Arak University, in 2015, Communications Society Wireless Communications Technical Committee
and the M.Sc. degree in computer engineering Recognition Award in 2018 and the IEEE Vehicular Technology Society
from Tarbiat Modares University, Tehran, in 2020. Stuart Meyer Memorial Award in 2020. He is also serving as the Chair for
Since 2019, she has been a Researcher with the the IEEE Wireless Communications and Networking Conference (WCNC)
Security Evaluation Laboratory (SE-Lab), Tarbiat Steering Committee. He was the Technical Program Chair/Co-Chair of
Modares University. She is currently working as a WCNC 2004, Atlanta, WCNC 2008, Las Vegas, and WCNC 2014, Istanbul.
Penetration Testing. Her research interests include He was the General Chair of IEEE VTC 2010-Fall, Ottawa, and VTC 2017-
network security, 5G networks, and blockchain. Fall, Toronto. He has also served as the Chair for the IEEE’s Technical
Her current research interests include security and privacy protocols for IoT, Committee on Personal Communications.
blockchain, and 5G security.

216476 VOLUME 8, 2020