5G Handover: When Forward Security Breaks

Navya Sivaraman

and Simin Nadjm-Tehrani

Department of Computer and Information Science, Link

oping University, Sweden

Keywords:

5G Xn Handover Protocol, Forward Security, Protocol Veriﬁcation, Formal Analysis.

Abstract:

5G mobility management is dependent on a couple of complex protocols for managing handovers, based on

the available network interfaces (such as Xn and N2). In our work, we focus on the 5G Xn handover procedure,

as deﬁned by the 3GPP standard. In Xn handovers, the source base station hands the user equipment (UE)

over to a target base station through two different mechanisms: horizontal or vertical key derivation. To

ascertain the security of these complex protocols, recent works have formally described the protocols and

proved some security properties. In this work, we formulate a new property, forward security, which ensures

the secrecy of future handovers following a session key exchange in one handover. Using a formal model and

the Tamarin prover, we show that forward security breaks in the 5G Xn handover in presence of an untrusted

base station. We also propose a solution to mitigate this counter-example with a small modiﬁcation of the

3GPP Xn handover procedures based on the perceived source base station state.

1 INTRODUCTION

In cellular networks, mobility management plays a

vital role in maintaining mobile services with mini-

mal latency while a user is moving from one loca-

tion to another. Cellular networks rely on handover

procedures to achieve this functionality (Bitsikas and

opper, 2021). Handover helps to transfer the User

Equipment (UE) from one cell to another.

A handover is initiated by the source base station

(source gNB in the 3GPP terminology) either when

the current serving network is incapable of serving the

UE or when the user moves along a continuous path

towards a new gNB (which is known as target gNB).

UE helps the source gNB to make a handover decision

by providing signal measurements to the network via

reports when it detects a more appropriate gNB (target

gNB) (Bitsikas and P

opper, 2021). These reports are

known as measurement report.

We consider the handover procedures within a

standalone ﬁfth generation of mobile networks (5G)

network, i.e., intra-system handover with 5G Radio

Access Network (RAN) and 5G core. In comparison

with other type of handovers, Xn handovers aim to be

of lower latency due to less interaction with the 5G

core network. However, security is also a key factor

to be considered. Therefore, we mainly focus on the

https://orcid.org/0000-0003-0123-1970

https://orcid.org/0000-0002-1485-0802

security properties of Xn handovers.

Our work aims to thoroughly study the different

session key generation procedures during the 5G Xn

handover. We use formal methods and the Tamarin

prover, to create an abstract model of the 5G Xn pro-

tocol for the security analysis. Our work is not lim-

ited to verifying the secrecy of a single communica-

tion session during handover. Rather, we formulate

a new security property (informally deﬁned by the

3GPP standard), known as forward security, to ver-

ify the secrecy of future handovers. To the best of

our knowledge, we are the ﬁrst to formally deﬁne and

verify the forward security property for 5G Xn han-

dovers.

The contributions of this work are as follows:

• We provide an overview of how a strong adversary

with access to a key generated at a base station

can use the 3GPP standard operations to derive all

future keys when the UE is outside its range.

• We formalize the threat model, security properties

for Xn handovers, including the forward security

property, and show how it breaks in this context

using the Tamarin prover.

• We mitigate the threat, based on adopting of a

slightly modiﬁed key derivation, depending on the

perceived honesty of the base stations.

Sivaraman, N. and Nadjm-Tehrani, S.

5G Handover: When Forward Security Breaks.

DOI: 10.5220/0012128400003555

In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 503-510

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

503

2 BACKGROUND

Cellular communication divides the geographical area

into hexagonal cells. Each cell includes a base station

(gNB) that serves the network. We use the term RAN

interchangeably for gNB in this paper, i.e., SRAN and

TRAN for source gNB and target gNB. The 3GPP de-

ﬁnes the 5G Core Network (CN) architecture. It is a

service-based architecture that constitutes several net-

work functions (NF), such as Authentication Server

Function, Access and Mobility Management Function

(AMF), and so on (3GPP TS 33.501, V17.7.0, 2022).

AMF is a network function within the control

plane that handles access authentication and autho-

rization of handovers. This function is responsible

for managing registration, detach procedures, paging,

and services related to registration, connection, and

mobility (Hussain et al., 2019). UE and RAN are sep-

arate entities from the 5G core architecture, thus un-

able to communicate directly with the AMF. Hence,

they use secure network interfaces to communicate

with AMF. For example, N1 is a network interface

that allows interaction between the UE and AMF.

The handovers may differ according to how the

source gNB and target gNB interact during the han-

dover. Whenever the source gNB initiates a 5G intra-

system handover request, it decides on either an Xn

or N2 handover procedure based on the available in-

terface. The availability of the network interface de-

pends on the conﬁguration that an operator chooses

for running its RAN. The intention is that, the source

gNB and the target gNB have minimal interaction

with the 5G CN during the Xn handover.

2.1 5G Xn Handover Protocol

Every standard Xn inter gNB handover consists of

three distinct stages, Handover Preparation, Han-

dover Execution, and Handover Completion.

• Handover Preparation: During the Handover

Preparation stage, the source gNB initiates trans-

ferring a UE to the target gNB through a Han-

dover Request message. The Handover Re-

quest consists of the newly derived session key

gNB*

and the target gNB ID). Then, the tar-

get gNB performs admission control and trans-

mits a Handover Acknowledge message to the

source gNB if the handover request is accept-

able (3GPP TS 38.423, V17.1.0, 2022; 3GPP TS

33.501, V17.7.0, 2022).

• Handover Execution: The Handover Execution

phase begins when the source gNB transmits the

Handover Command message to UE (3GPP TS

33.501, V17.7.0, 2022), and this message con-

tains information about the target gNB, such as

target gNB ID. Once the UE receives the Han-

dover Command message, it attempts to recom-

pute the same session key K

gNB*

and updates the

signaling with the target gNB through the Radio

Resource Controller (RRC) Reconﬁguration com-

pletion message by encrypting with the session

key K

gNB*

• Handover Completion: In the ﬁnal stage the UE

content release and implementation of ﬁnal bear-

ers occur (Bitsikas and P

opper, 2021). In this

stage, the target gNB interacts with the AMF

within 5G CN using NGAP PATH SWITCH Re-

quest and NGAP PATH SWITCH Acknowledge

message to collect the the keying material. Thus,

the AMF will compute the new next hop (NH) and

next hop chaining counter (NCC) parameters for a

future handover. Finally, the source gNB releases

the UE content (3GPP TS 33.501, V17.7.0, 2022).

2.2 Session Key Generation

The generation of session key (K

gNB*

) is a critical

stage within the 5G handover procedure. The ses-

sion key generation procedure may vary depending

on the available keying parameters within the source

gNB. There are two procedures, namely horizon-

tal key derivation (hkd), and vertical key derivation

(vkd).

2.2.1 Horizontal Key Derivation

In hkd, a new session key (K

gNB*

) is derived from the

source base station’s key (K

gNB

KgNB* = KDF (KgNB || TRAN_ID )

The key derivation function (KDF) takes the current

key of the source base station (K

gNB

) and the target

base station’s identiﬁer (TRAN ID) as input to derive

the new session key K

gNB*

2.2.2 Vertical Key Derivation

In vkd, a new session key (K

gNB*

) is derived using the

intermediate NH parameter transferred from AMF.

KgNB* = KDF (NH || TRAN_ID)

Hence, KDF takes the NH and TRAN ID to derive

gNB*

. NCC acts as a counter of NH and increments

after each handover.

In legitimate Xn-based handovers, the ﬁrst session

key is derived using hkd, followed by the vkd for fu-

ture handovers if the source gNB has an unused {

NH,NCC } pair (3GPP TS 33.501, V17.7.0, 2022).

SECRYPT 2023 - 20th International Conference on Security and Cryptography

504

2.3 The Tamarin Prover

The Tamarin prover is a state-of-the-art veriﬁcation

tool designed to analyze security protocols (Basin

et al., )(Peltonen et al., 2021)(Meier et al., 2013).

Security protocols are programs that rely on crypto-

graphic primitives to achieve secure communication

over insecure networks. To prove the correctness

of a security protocol, it is represented mathemati-

cally, either using a symbolic model or a computa-

tional model (Blanchet, 2012). The default underly-

ing threat model of Tamarin is Dolev Yao (Dolev and

Yao, 1983), a strong threat model with a powerful at-

tacker who will be able to tamper with any publicly

available information.

The Tamarin prover builds on symbolic modeling.

It takes the formal model of the protocol, which in-

cludes the formalization of the threat model, and the

properties to be veriﬁed as input. The tool attempts to

prove the property by constructing a proof of correct-

ness or returning a counter-example.

3 RELATED WORK

Various security features of 5G handover protocols,

including the Xn handover, have been analyzed and

formally veriﬁed. However, most of the recent works

have been focusing on authentication and key secrecy

features in 5G Xn handover.

Huang et al., and Yan et al., propose a new

secure handover authentication protocol for 5G

handovers based on the Chinese Remainder The-

orem and formally prove its correctness using

Burrows–Abadi–Needham logic (BAN logic) and

Scyther tool (Yan and Ma, 2021)(Huang and Qian,

2020).

Peltonen et al. present the ﬁrst comprehensive

formal veriﬁcation model of 5G handovers (Peltonen

et al., 2021). They uphold a strong assumption by

considering honest entities throughout the operational

life of their system model. They then formally verify

the authentication and key secrecy of 5G handovers,

including injective agreement.

Gupta et al. propose a Secrecy and Efﬁciency

Aware Inter-gNB handover Authentication and Key

Agreement protocol (AKA) to achieve session key se-

crecy and authenticity (Gupta et al., 2022). Formal se-

curity analysis and veriﬁcation is performed with the

Random Oracle Model and AVISPA tool.

Nyangaresi and Rodrigues extend the protocol for

selection of the target gNB using a multilayer neural

network. They prove the privacy and security proper-

ties, such as forward and backward key secrecy dur-

ing handover authentication, using BAN logic (Nyan-

garesi and Rodrigues, 2022).

In addition to the handover, Miller et al. pro-

pose a combined model for 5G registration and 5G

AKA protocol (Miller et al., 2022). They formally

model and verify the handover authentication and key

secrecy, including multiple threat models, using the

Tamarin prover. However, the security enhancement

of protocol data unit sessions with smart ﬁltering are

the main focus of this work.

From the literature study, it is evident that the

authentication, session key secrecy, forward secrecy,

backward secrecy, and availability (resistance to de-

synchronization or replay attack) features of 5G han-

dover have been formally veriﬁed. Huang et al., Yan

et al., Gupta et al., and Nyangaresi and Rodrigues,

cover performance analysis, computational overhead,

and energy consumption, as well as comparing the

proposed protocols with the existing 3GPP standard.

Evidently, the proposed protocols are slightly differ-

ent from the standardized handover procedure. Pel-

tonen et al., and Miller et al., adopt the standardized

5G handover procedure, as deﬁned by the 3GPP, in

their model. To the best of our knowledge, we are the

ﬁrst to formally deﬁne and verify the forward security

property in 5G Xn handovers.

4 OUR SYSTEM AND THREAT

MODEL

This section introduces the relevant actors within our

Xn handover model in accordance with the 5G Xn

handover, deﬁned by 3GPP. In addition, our threat

model reﬂects plausible adversary capabilities within

the modeled protocol.

4.1 System Model

There exist different variations of Xn handover in the

3GPP standard. In our system model, we consider a

conventional Xn handover model that consists of two

base stations, i.e., source gNB and target gNB, UE,

and AMF as shown in Figure 1.

The AMF NF within 5G CN remains unchanged

in this model. The source gNB and target gNB are

connected with an Xn interface. The network inter-

face N1 is used for the communication between UE

and 5G CN. On the other hand, N2 is a network inter-

face used for communication between gNBs and 5G

CN.

5G Handover: When Forward Security Breaks

505

Figure 1: System model of 5G Xn handover.

4.2 Threat Model

The main goal of the attacker is to potentially cre-

ate a massive service disruption or service compro-

mise for an arbitrary set of users. That is, the at-

tacker may intercept or modify legitimate messages

to the users during emergencies. In our threat model,

we consider a powerful attacker who has complete

protocol knowledge and access to some sensitive in-

formation within a base station (e.g., within compro-

mised equipment or a malicious insider). We assume

that the base stations are protected by physical secu-

rity as the 3GPP standard stipulates. Access to any

clear text data is limited except when the attacker is

an insider or has obtained unauthorized remote access

to the base station equipment by exploiting potential

vulnerabilities, or a misconﬁguration. If all sensitive

data is stored in an encrypted manner within the base

station, then the attacker is assumed to possess the ca-

pability required to access some sensitive information

within a base station, such as the temporary session

keys used for local storage. The critical information,

such as long-term keys, is assumed to be secure and

thus inaccessible to the attacker. In our threat model,

our attacker can compromise temporary session keys

from the base station, and by using these session keys

he/she will be able to compromise not only the cur-

rent session but also the future handover sessions of

an arbitrary number of UEs. That is, he/she will be

able to eavesdrop, modify, drop, or may reuse the in-

formation to perform malicious actions in the future.

In comparison to other existing works (Peltonen

et al., 2021) (Miller et al., 2022), we have proven the

new security requirement in presence of a stronger in-

sider threat model. This helps to identify the impacts

of new attack surfaces.

5 SECURITY ASSUMPTIONS

AND REQUIREMENTS

In this work, we reuse some useful fragments of the

existing formal model from (Peltonen et al., 2021).

The 5G AKA procedure is a prerequisite for a UE to

authenticate itself with the CN. We begin our model

with Xn handover by assuming that UE has success-

fully authenticated itself with the CN beforehand.

5.1 Initial Security Assumptions

Our work mainly focuses on the in-depth analysis of

key generation during the 5G handover. We next de-

scribe the used notions from the 5G key hierarchy

adopted in our model.

5.1.1 Keys in 5G Key Stack

Here, we provide a brief overview of keys modeled

in our formal model from the 5G key stack and de-

ﬁne certain assumptions to reduce model complexity.

Figure 2 presents the keys within the 5G key stack.

Figure 2: Keys in 5G Key Stack.

SEAF

is the anchor key generated during the primary

5G AKA procedure between UE and CN. All the sub-

sequent security keys are derived using this K

SEAF

key. K

AMF

is the long-term key, from which all the

session keys are derived by the SRAN and UE dur-

ing handover. The K

NASint

and K

NASenc

are the keys

for protecting the Non-access stratum (NAS) signal-

ing between UE and AMF. The key K

gNB

is the ses-

sion key derived from the long-term key K

AMF

dur-

ing the 5G AKA procedure. The key K

gNB*

is the

session key derived by the SRAN using hkd or vkd

for each session during handover. The communica-

tion between UE and RAN is secured by four keys:

UPenc

, K

UPint

, K

RRCenc

and K

RRCint

and they are de-

rived from session key K

gNB

to enable encryption and

integrity protection of user plane trafﬁc and RRC sig-

naling.

In our model, we consider the anchor key K

SEAF

and the long-term key K

AMF

is assumed to be secure.

That is, the attacker will not be able to compromise

any long-term keys in the 5G key stack. To avoid the

complexity in modeling, we use the K

AMF

for encryp-

tion and integrity protection instead of K

NASint

and

NASenc

keys. In addition to this, the keys K

UPenc

UPint

, K

RRCenc

and K

RRCint

keys are substituted with

gNB*

for encryption and integrity protection.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

506

5.1.2 Network Interfaces for Communication

We recall here the claims of secure network interfaces

from the 5G standard. The NFs like AMF, within the

5G core, can communicate directly with each other.

On the other hand, RAN and UE are separate entities

from the 5G core architecture, thus unable to commu-

nicate directly with the AMF. Hence, they use secure

network interfaces to communicate with the AMF.

Therefore, we assume that the N1, N2, Xn, and air

interfaces are secure during the handover.

5.2 Security Requirements

The security requirement for 5G Xn handovers is

not explicitly stated in the 3GPP standard (3GPP TS

33.501, V17.7.0, 2022). The three security require-

ments for 5G Xn handover protocol that can be con-

sidered are (1) injective agreement of re-derived keys,

(2) secrecy of all keys and identiﬁers used during a

handover, and (3) forward security, which ensures the

secrecy for future handovers.

5.2.1 Injective Agreement

Injective agreement, also simply known as ”agree-

ment”, is a key security requirement that needs to be

accomplished among the communicating entities dur-

ing a handover (in our study) or speciﬁcally during a

key agreement. We use Lowe’s deﬁnition to formally

deﬁne injective agreement (Lowe, 1997).

During the Xn handover, both the UE and target

gNB must agree upon the same key K

gNB*

for the ses-

sion. It is important to satisfy the injective agreement

between the UE and target gNB to eliminate replay

attacks.

5.2.2 Secrecy

Secrecy ensures the conﬁdentiality of the information

exchanged during a key exchange procedure. During

an authentication key exchange procedure, secrecy is

considered an indispensable security requirement for

protecting data from being disclosed to unauthorized

entities.

During the 5G Xn handover, the secrecy of session

keys, such as K

gNB

and K

gNB*

, as well as the com-

munication channels (i.e., the network interfaces used

for communication) need to be veriﬁed to ensure the

conﬁdentiality of information exchanged during the

handover.

5.2.3 Forward Security

The 3GPP (3GPP TS 33.501, V17.7.0, 2022) standard

presents the semi-formal deﬁnition of forward secu-

rity. It refers to the fulﬁllment of the property that for

an entity a, with the knowledge of K

, used between

a and a second entity b, it should be computation-

ally infeasible to predict any future keys K

m+n

,(n > 0)

used between a third entity c and entity b.

Forward security plays an inevitable role during

5G Xn handovers to ensure the secrecy of future han-

dovers. If forward security holds for a base station

gNB

with the knowledge of the key K

gNB

, shared

with a UE, it is computationally infeasible to predict

any future K

gNB

(i > 1) that will be shared between

the same UE and another base station node gNB

Furthermore, the n hop forward security is deﬁned

as the property where a gNB is unable to compute the

keys that will be used between any UE and another

gNB to which the UE is connected after n or more

handovers (n >= 1).

6 FORMAL VERIFICATION

Formal analysis of a protocol requires resolving three

sub-problems: how to model a protocol, the threat

model or adversary knowledge, and security proper-

ties. All three may vary depending on the choice of

the proof tool that will be used.

In our approach, we use the Tamarin prover, one

of the most prominent security protocol veriﬁcation

tools for formal analysis. In this section, we describe

how we can model the protocol, adversary capabili-

ties, and security properties using the Tamarin prover,

and conclude by summarizing our results.

6.1 Protocol Modelling

In the Tamarin prover, the protocols and the adversary

knowledge are modeled using a multi-set rewriting

rule. The security properties are deﬁned using ﬁrst-

order logic and they are denoted by lemmas.

Rules operate on the system’s state, which is rep-

resented using a multiset (i.e., a bag) of facts. The

rules are comprised of premises, action facts, and con-

clusions. The execution of rules shows the system’s

state transition from the premises, a set of facts, to the

conclusions, i.e., a potentially different set of facts.

The actions during protocol state transitions are cap-

tured by action facts that appear in the traces. The

trace of a system or protocol is a sequence of events

that starts from an empty state, and consists of a se-

quence of labeled actions, captured by the action facts

for a sequence of rules that were applied.

The rules in the Tamarin prover for protocol mod-

eling are represented as follows:

[p] --[a]-> [c]

5G Handover: When Forward Security Breaks

507

where p is the premise, a is the action fact, and c is

the conclusion.

Let us consider a rule to initialize the UE with the

serving network in our protocol model. We present a

simpliﬁed version of the actual rule here.

rule init_UE:

[ !UE(˜SUPI, ˜CN_ID)]

--[ KeyDerived( K_gNB, ˜K_SEAF, K_AMF, ˜SUPI)

]-> [ Session_key(˜SUPI, ˜SRAN_ID, K_gNB)]

The rule init UE is comprised of several facts:

!UE(...) is a fact in premises, KeyDerived(...)

is an action fact, and Session key(...) denotes

a fact within conclusions. The symbol ! with a

fact (!UE(...)) indicates that the fact is persis-

tent. Each fact contains one or more terms, such as

(˜SUPI,˜CN ID). The symbol ˜ denotes the freshness

of the terms.

The rule init UE states that a new UE is ini-

tialized or registered with the CN (with the identi-

ﬁer ˜CN ID) using the UE’s Subscription Permanent

Identiﬁer (SUPI). Each ˜SUPI value will be unique

for each UE. This UE will derive a new session key

K gNB from the long-term key K AMF, which is de-

rived using the anchor key ˜K SEAF, and the UE iden-

tiﬁer ˜SUPI. This action is captured by the action fact

KeyDerived(...). The fact Session key(...) in

the conclusion indicates that the UE and source gNB

(˜SRAN ID) derive the same session key K gNB.

We also formalize the adversary capabilities using

rules in the Tamarin prover, as follows:

rule reveal_session_key_k_gnb:

[ Session_key(˜SUPI, ˜SRAN_ID, K_gNB) ]

--[ InsiderAttacker(K_gNB)

, Rev(<’K_gNB’, K_gNB>)]-> [ Out(K_gNB) ]

Similar to the rule init UE, the rule

reveal session key k gnb is comprised of

three facts, Session key(...) is the premise,

InsiderAttacker(...) and Rev(...), the action

facts, and Out(...) is the conclusion fact. The

terms ’K gNB’, K gNB included within the <>

represents association of the label (’K gNB’) with the

term (K gNB) itself. In the Tamarin prover, labels are

strings within single quotes enclosed within angle

brackets (<>).

The special facts, In() and Out() are used to send

and receive messages over the network, modeling in-

formation which can be intercepted by the attacker.

The rule reveal session key k gnb states

that if an insider attacker obtains access to

the session key (captured by the action fact

InsiderAttacker(K gNB)), then he/she will be

able to reveal this session key (using action fact

Rev(...)). As a result, the session key (K gNB) is

considered as sent out to the public.

6.2 Formalizing Security Properties

In this section, we specify the security properties

described in subsection 5.2 as relevant for the 5G

Xn handover protocol. We use lemmas to formalize

the following security properties using the Tamarin

prover.

6.2.1 Injective Agreement

We deﬁne the lemma of the injective agreement by

following the standard formula deﬁnitions within the

Tamarin prover manual (in detail). During the 5G Xn

handover, we want to guarantee the injective agree-

ment property, that is the agreement between the

UE and target gNB (TRAN) on the key K

gNB*

(i.e.,

K gNB star in the lemma). We used the action facts

Commit(...) and Running(...) to formulate in-

jective agreement, as deﬁned in the Tamarin prover

manual.

6.2.2 Secrecy

Our work mainly focuses on the session key deriva-

tion and exchange during the 5G Xn handover, we

formulate the following lemma to require its secrecy.

lemma secret_KgNB :

" All p #i. Secret (<’K_gNB’, p>) @i

== > (not (Ex #j. K ( p ) @j))

| (Ex A #j1. Rev( A, p)@j1

& InsiderAttacker(A) @i )"

The lemma secret KgNB with the action fact

Secret(...) indicates the fact that any key p, which

is labelled as K gNB, and is considered to be secret

at any time (#i), requires that no attacker has knowl-

edge (K(...)) about the key p at another time point

(#j), nor is there an insider attacker A, denoted by the

action fact InsiderAttacker(A), at the same time

point (#i), who can reveal (Rev(A, p)) the key. The

inbuilt action fact K(...) within the Tamarin prover

denotes the attacker’s knowledge.

6.2.3 Forward Security

Forward Security is the key property of 5G Xn han-

dover, and it is important to verify this property for

both hkd and vkd during the 5G Xn handover.

lemma forward_securtiy:

" not ( Ex q #i1 #j1.

ForwardSecuritySecret(

<’K_gNB_star’, q>) @i1

& K(q) @#j1

& not ( Ex p #r.

Rev(<’K_gNB’, p>)@r

& #r < #i1) & #j1 < #i1) "

SECRYPT 2023 - 20th International Conference on Security and Cryptography

508

The lemma forward security states that there

is no forward security secret at any time (#i1),

which is known to the attacker at any time point

#j1 and is exposed by the session key (K gNB),

being revealed (Rev(...)) at some time point

#r. The term q denotes the forward security se-

crect, i.e., the key K gNB star, and the action fact

ForwardSecuritySecret(...) is used to capture

this in a trace.

6.3 Results

Our formal model is used to verify the lemmas, Se-

crecy, injective agreement, executability (not shown

here), and forward security. Here, we mainly focus on

the forward security lemma from our results, which

has not been veriﬁed in any other 5G protocol model.

Our results showed that forward security breaks for

5G Xn handovers if the session key is derived using

hkd. Therefore, the Tamarin prover returns a counter-

example.

In the hkd, each session key K

gNB

is dependent

on the previous session key. Therefore, if one key is

revealed within this key dependency chain, it helps

the attacker to generate the subsequent keys, such as

gNB*

, K

UPenc

, K

UPint

, K

RRCenc

and K

RRCint

. This

breaks the forward security property, as a result of

which the attacker can modify, intercept, or hinder

the service during (any future) handover. In contrast,

the vkd satisﬁes the forward security because of the

unique NH parameter provided by the 5G CN. Thus,

it is hard to compromise all future session keys with-

out compromising the 5G CN.

6.4 Mitigation Method

Our proof clearly shows that the secrecy of future han-

dovers strongly depends on the choice of session key

generation, i.e., hkd or vkd, during handover. We can

remove the counter-example for the forward security

lemma during the protocol execution by using the mit-

igation method below.

To provide an effective solution to our problem,

ﬁrst, we need to distinguish an untrusted base station,

which is accessible to an attacker, from a trusted one.

For that, we consider the base stations have a desig-

nated state as honest or dishonest. The base stations

with the dishonest state are those that may reveal the

temporary session keys.

The terms s1 and s2 below denote the states of

source gNB and target gNB during a handover.

predicates:

HonestOrDishonestgNBhandovers (s1,s2) <=>

((s1 = ’dishonest’ & s2 = ’honest’)

|(s1 = ’honest’))

In addition, we add a rule honest dishonest to in-

dicate the possible states of gNBs.

rule honest_dishonest:

[] -->

[!H_or_DH(’honest’), !H_or_DH(’dishonest’)]

Using the predicates and the rule honest dishonest

above, we modify the original rule init RAN, in

order to initialize the source gNB in the protocol

model to honest or dishonest respectively. The state

of the source gNB is traced using the action fact

RANState(...). The premise !H or DH(s) is a per-

sistent fact that represents the state of the gNB. The

label for a state s in !H or DH(s) can be either

’honest’ or ’dishonest’.

rule init_RAN:

[ Fr(˜RAN_ID) ,!H_or_DH(s)]

--[ RadioAccessNetwork(˜RAN_ID)

, RANState(˜RAN_ID, s) ]->

[ !NG_RAN(˜RAN_ID, s), Out(˜RAN_ID) ]

In the Tamarin prover, embedded restrictions are

used to enforce a restriction on the trace once

a certain rule is invoked. Hence, we enforce

the states of the source (’honest’/ ’dishonest’)

and target gNB (’honest’) using a restriction

restrict(HonestOrDishonestgNBhandovers (

s1, s2)) to cover both possible scenarios.

In addition, we implement two rules for hkd based

on the state of the source gNB. If the state of the

source gNB is ’honest’, then the source and target

gNB will engage in the standard Xn handover proce-

dures, including hkd. On the other hand, if the source

gNB is ’dishonest’, then we invoke a different rule

during the Handover Execution stage.

The modiﬁed rule includes the following steps:

• CN generates a unique key material (˜Akey) in the

Handover preparation stage.

• This key material (˜Akey) is shared and stored

within the UE, while the UE initializes itself with

the CN.

• During the Handover preparation stage, the

source gNB is identiﬁed by the target gNB as hon-

est or dishonest when exchanging the session key

gNB*

through Handover Request message.

• When the Target gNB receives a Handover Re-

quest message from an untrusted gNB, it forwards

this message to the 5G CN/AMF.

• AMF will derive the new session key (K

gNB**

)

and send it to UE, through Handover Acknowl-

edge from Target gNB to Source gNB, and Han-

dover Command from Source gNB to UE. The

derivation of the new session key (K

gNB**

) is

modelled as:

K gNB star star = KDF(K gNB star,˜Akey)

5G Handover: When Forward Security Breaks

509

• After receiving the Handover Command message

from Source gNB during the Handover Execu-

tion stage, UE will initially derive the session

key K

gNB*

, and then derive the unique session

key (K

gNB**

) using the key material (˜Akey) and

gNB*

• If the authentication is successful, then the UE

will send the RRC Reconﬁguration Completion

message to the Target gNB.

In the ﬁnal stage, Handover Completion stage, we

follow the original Xn handover procedure.

7 CONCLUSIONS AND FUTURE

WORK

Forward security plays a vital role in 5G Xn han-

dovers. It guarantees security for future handovers.

The failure of the proof of forward security during 5G

Xn handovers reveals the strong attack surface that

allows intercepting communications while remaining

invisible or unnoticed. Our study shows that the se-

crecy of future handovers strongly depends on the

choice of the session key generation, i.e., hkd, or vkd,

during handovers.

We also present a possible solution to mitigate this

kind of attack to enhance secrecy. While our model

of an untrusted base station is a simpliﬁed binary one,

and this classiﬁcation may, in reality, be more com-

plex policy-based decisions or signaling-based detec-

tion of rogue base stations.

We would like to recall and emphasize that 5G

standards do mandate some security requirements but

also leave some options to operators to promote ﬂex-

ibility. The operators implementing 3GPP standards

that are aware of this security problem may have al-

ready implemented a mitigation of these effects as

part of optional features of their systems. Any such

solution could also be formalized and proved correct

in a similar manner to what we did here. Therefore,

future works may include the assessment of various

other approaches for hardening the security of han-

dover protocols using formal modelling and veriﬁca-

tion.

ACKNOWLEDGEMENTS

This work was funded by ELLIIT, Excellence Center

at Link

oping-Lund on Information Technology.

REFERENCES

3GPP TS 33.501, V17.7.0 (2022). 5G; Security architecture

and procedures for 5G System. 3GPP TS 33.501.

3GPP TS 38.423, V17.1.0 (2022). 5G; NG-RAN; Xn Ap-

plication protocol (XnAP). 3GPP TS38.423.

Basin, D., Cremers, C., Dreier, J., Meier, S., Sasse, R., and

Schmidt, B. Tamarin-prover Manual Security Proto-

col Analysis in the Symbolic Model, 2019.

Bitsikas, E. and P

opper, C. (2021). Don’t hand it over:

Vulnerabilities in the Handover Procedure of Cellular

Telecommunications. In Annual Computer Security

Applications Conference, pages 900–915.

Blanchet, B. (2012). Security protocol veriﬁcation: Sym-

bolic and Computational models. In International

Conference on Principles of Security and Trust, pages

3–29. Springer.

Dolev, D. and Yao, A. (1983). On the security of public key

protocols. IEEE Transactions on information theory,

29(2):198–208.

Gupta, S., Parne, B. L., Chaudhari, N. S., and Saxena, S.

(2022). SEAI: Secrecy and Efﬁciency Aware Inter-

gNB Handover Authentication and Key Agreement

Protocol in 5G Communication Network. Wireless

Personal Communications, 122(4):2925–2962.

Huang, J. and Qian, Y. (2020). A secure and efﬁcient

handover authentication and key management proto-

col for 5G networks. Journal of Communications and

Information Networks, 5(1):40–49.

Hussain, S. R., Echeverria, M., Karim, I., Chowdhury, O.,

and Bertino, E. (2019). 5GReasoner: A property-

directed security and privacy analysis framework for

5G cellular network protocol. In Proceedings of the

2019 ACM SIGSAC Conference on Computer and

Communications Security, pages 669–684.

Lowe, G. (1997). A hierarchy of authentication speciﬁca-

tions. In Proceedings 10th computer security founda-

tions workshop, pages 31–43. IEEE.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The TAMARIN prover for the symbolic analysis of

security protocols. In International conference on

computer aided veriﬁcation, pages 696–701. Springer.

Miller, R., Boureanu, I., Wesemeyer, S., and Newton, C. J.

(2022). The 5G Key-Establishment Stack: In-Depth

Formal Veriﬁcation and Experimentation. In Proceed-

ings of the 2022 ACM on Asia Conference on Com-

puter and Communications Security, pages 237–251.

Nyangaresi, V. O. and Rodrigues, A. J. (2022). Efﬁcient

handover protocol for 5G and beyond networks. Com-

puters & Security, 113:102546.

Peltonen, A., Sasse, R., and Basin, D. (2021). A compre-

hensive formal analysis of 5G handover. In Proceed-

ings of the 14th ACM Conference on Security and Pri-

vacy in Wireless and Mobile Networks, pages 1–12.

Yan, X. and Ma, M. (2021). NSEHA: a neighbor-based se-

cure and efﬁcient handover authentication mechanism

for 5G networks. In 2021 9th International Confer-

ence on Communications and Broadband Networking,

pages 209–216.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

510