MODELING AND ANALYSIS OF MOBILE TELEPHONY PROTOCOLS

by

Chunyu Tang

A DISSERTATION

Submitted to the Faculty of the Stevens Institute of Technologyin partial fulfillment of the requirements for the degree of

DOCTOR OF PHILOSOPHY

Chunyu Tang, Candidate

ADVISORY COMMITTEE

David A. Naumann, Chairman Date

Yingying Chen Date

Daniel Duchamp Date

Susanne Wetzel Date

STEVENS INSTITUTE OF TECHNOLOGYCastle Point on Hudson

Hoboken, NJ 070302013

c©2013, Chunyu Tang. All rights reserved.

iii

MODELING AND ANALYSIS OF MOBILE TELEPHONY PROTOCOLS

ABSTRACT

The GSM (2G), UMTS (3G), and LTE (4G) mobile telephony protocols are all inactive use, giving rise to a number of interoperation situations. This poses seriouschallenges in ensuring authentication and other security properties. Analyzing thesecurity of all possible interoperation scenarios by hand is, at best, tedious under-taking. Model checking techniques provide an effective way to automatically findvulnerabilities in or to prove the security properties of security protocols.

Although the specifications address the interoperation cases between GSM andUMTS and the switching and mapping of established security context between LTEand previous technologies, there is not a comprehensive specification of which arethe possible interoperation cases. Nor is there comprehensive specification of theprocedures to establish security context (authentication and short-term keys) in thevarious interoperation scenarios. We systematically enumerate the cases, classifyingthem as allowed, disallowed, or uncertain with rationale based on detailed analysis ofthe specifications. We identify the authentication and key agreement procedure foreach of the possible cases.

We formally model the pure GSM, UMTS, LTE authentication protocols, aswell as all the interoperation scenarios; we analyze their security, in the symbolicmodel of cryptography, using the tool ProVerif. We find the previously known man-in-the-middle attack on GSM. For the interoperation scenarios, we find three kind ofattacks: one is the false base station attack which is inherited from GSM; anotherattack is a similar false base station attack but with a 4G base station; the third onemodifies the CMC message. Based on the proved and refuted properties, we comparethe authenticity achieved in different scenarios, and we provide recommendations toimprove the mobile telephony standards.

Author: Chunyu TangAdvisor: David A. NaumannDate: January 13, 2014Department: Computer ScienceDegree: Doctor of Philosophy

iv

Acknowledgments

I am deeply grateful to my advisor, Professor David A. Naumann, for his teaching,supporting, and kindness. His enthusiasm for research and broad knowledge inspireme. He spent countless hours discussing my work, reading my papers, proposal, anddissertation, and criticizing my talks. This dissertation would not be possible withoutthe insightful guidance of Professor Naumann. It was a great honor to work with him.

I would also like to thank Professor Susanne Wetzel for the tremendous timeand energy she invested into my research. This dissertation would not have existedwithout her detailed comments, endless patience, and valuable advice.

I give my sincere thanks to the members of my Ph.D committee, ProfessorDaniel Duchamp and Professor Yingying Chen. Their valuable comments on myproposal and dissertation greatly enhanced and strengthened my work.

I would also like to thank Professor Adriana Compagnoni for serving on myproposal committee and for her valuable comments on my work.

I would like to thank Andrey Chudnov, Stan Rosenberg, and Ye Wu for theirexcellent comments and helpful discussion of my work.

I thank the professors and students in our regular LSS meeting for sharingtheir helpful comments.

I would like to thank my parents for their love, encouragement, and support.I am proud to be their son.

Finally, I would like to thank my wonderful wife, Yan Zhuang, and my adorableson, Albert Tang. They keep my life with love. They shared all my exciting anddisappointing moments over the years.

v

Table of Contents

Abstract iii

Acknowledgments iv

List of Tables ix

List of Figures x

Index of Defined Terms xii

1 Introduction 11.1 Motivation and Goals 11.2 Approach 21.3 Thesis 31.4 Contribution 31.5 Outline 4

2 Background on Security Protocol Analysis and Related Work 52.1 Informal Analysis Techniques and Prior Work for Mobile Telephony

Protocols 52.1.1 Conventional Analysis 52.1.2 Prior Work 6

2.2 Background on Formal Analysis 72.2.1 Dolev-Yao (Symbolic) and Computational Model 72.2.2 Events and Correspondence Assertion 8

2.3 Comparative Overview of Formal Tools 92.3.1 Formal Analysis Tools 92.3.2 Scyther 112.3.3 AVISPA 12

2.4 ProVerif 142.4.1 Rationale for the choice of ProVerif 142.4.2 Specifying Protocols and Security Properties 142.4.3 Analysis Technique and Approximation 162.4.4 Applications 19

2.5 Prior Work on Formal Analysis of Mobile Telephony Protocols 19

3 Modeling and Analysis of GSM 213.1 Overview of GSM AKA 213.2 Modeling the GSM AKA 24

3.2.1 Design Choices 24

vi

3.2.2 GSM Model 283.3 Security Property Specifications and Findings 33

4 Modeling and Analysis of UMTS 374.1 Overview of UMTS AKA 374.2 Modeling the UMTS AKA 40

4.2.1 Design Choices 404.2.2 UMTS Model 40

4.3 Security Property Specifications and Findings 44

5 Modeling and Analysis of LTE 465.1 Overview of LTE AKA 465.2 Modeling the LTE AKA 50

5.2.1 Design Choices 505.2.2 LTE Model 51

5.3 Security Property Specifications and Findings 57

6 Comparative Authenticity 596.1 Authentication of the MS to the SN 59

6.1.1 GSM vs. UMTS 596.1.2 UMTS vs. LTE 60

6.2 Authentication of the SN to the MS 626.2.1 GSM vs. UMTS 626.2.2 UMTS vs. LTE 62

6.3 Summary 64

7 Establishing a Initial Security Context in Interoperation 667.1 System Components 667.2 Allowed Interoperation Cases 747.3 Disallowed Interoperation Cases 757.4 Uncertain Interoperation Cases 75

8 Modeling and Analysis of Interoperation Scenarios involving GSMand UMTS Procedures Only 778.1 Determining the Scenarios only involving GSM and UMTS Components 778.2 Scenario S4: A UMTS MS roams to an SN with a GSM BS and GSM

MSC 798.2.1 Overview of the AKA Scenario 798.2.2 Modeling the AKA Scenario 808.2.3 Security Property Specifications and Findings 82

8.3 Scenario S5: A GSM MS roams to an SN with a UMTS BS and UMTSMSC 838.3.1 Overview of the AKA Scenario 83

vii

8.3.2 Modeling the AKA Scenario 848.3.3 Security Property Specifications and Findings 87

8.4 Scenario S6: A UMTS MS roams to an SN with a GSM BS and aUMTS MSC 878.4.1 Overview of the AKA Scenario 888.4.2 Modeling the AKA Scenario 888.4.3 Security Property Specifications and Findings 90

9 Modeling and Analysis of Scenarios involving LTE Procedures 939.1 Determining the Scenarios involving LTE Components 939.2 Scenario S7: LTE I ‖ UMTS II–III ‖ [optionally, LTE IV] ‖ LTE V,

conv(CK IK → KASME , MME) 989.2.1 Overview of the AKA Scenario 999.2.2 Modeling the AKA Scenario 999.2.3 Security Property Specifications and Findings 107

9.3 Scenario S8: LTE I’ ‖UMTS II–III ‖ LTE IV–V, conv(CK IK nonces →KASME , MME) 1089.3.1 Overview of the AKA Scenario 1089.3.2 Modeling the AKA Scenario 1089.3.3 Security Property Specifications and Findings 113

9.4 Scenario S9: GSM I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ GSM IV,conv(CK IK → Kc, MME), AV = 4G AV + CK + IK 1149.4.1 Overview of the AKA Scenario 1149.4.2 Modeling the AKA Scenario 1149.4.3 Security Property Specifications and Findings 121

9.5 Scenario S10: UMTS I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ UMTSIV, AV = 4G AV + CK + IK 1229.5.1 Overview of the AKA Scenario 1229.5.2 Modeling the AKA Scenario 1239.5.3 Security Property Specifications and Findings 128

10 Summary of Findings 13010.1 Secrecy and Integrity Properties 13010.2 Authentication Properties 130

10.2.1 Authentication of the MS to the SN 13110.2.2 Authentication of the SN to the MS 131

10.3 Attacks 133

11 Conclusion and Future Work 135

Appendix A 138

Bibliography 175

viii

Vita 183

ix

List of Tables

3.1 Analysis result of GSM model 34

4.1 Analysis result of UMTS model 45

5.1 Analysis result of LTE model 58

6.1 Types of authentication achieved by the pure AKAs 656.2 Parameters of the correspondence assertions used in the proved au-

thentication properties 65

7.1 Legend used in Table 7.2 677.2 Classifying the 243 interoperation cases (legend explained in Table 7.1) 67

8.1 Reasons used for determining AKA scenarios (see Table 9.1 for full set) 788.2 Classifying the interoperation cases involving GSM and UMTS com-

ponents only. (The reasons are in Table 8.1) 798.3 Analysis result of S4 model 838.4 Analysis result of S5 model 878.5 Analysis result of S6 model 91

9.1 Reasons used for determining AKA scenarios 949.2 Classifying the interoperation cases (for GSM, UMTS, and LTE) 959.3 Determining components of each scenario 999.4 Analysis result of S7 models 1079.5 Analysis result of S8 model 1139.6 Analysis result of S9 models 1219.7 Analysis result of S10 models 129

10.1 Types of SN components authenticity achieved by the scenarios 13310.2 Analysis results of authentication properties 134

x

List of Figures

1.1 Example of an interoperation case 1

2.1 Term and Process Grammar 15

3.1 GSM architecture [94, 76] 223.2 GSM message sequence diagram [94, 76] 233.3 GSM diagram annotated in accord with our model. Compared to Fig-

ure 3.2, our model omits TMSI/ID Request (messages numbered 2 and3 in Figure 3.2), abstracts from the details of the SN, and adds a firstmessage of data traffic 29

4.1 UMTS architecture [94, 76] 384.2 UMTS AKA [94, 76] 394.3 UMTS AKA (Figure 4.2) annotated in accord with our model 41

5.1 LTE architecture [94, 52] 475.2 LTE AKA 485.3 LTE I’ when the AKA starts with a TAU request 495.4 LTE AKA (Figure 5.2) annotated in accord with our model 52

6.1 Events used to specify the authentication of MS to SN in GSM andUMTS 60

6.2 Events used to specify the authentication of MS to SN in UMTS andLTE 61

6.3 Events used to specify the authentication of SN to MS in UMTS andLTE 63

8.1 UMTS subscriber roams into GSM network 808.2 UMTS subscriber roams into GSM network, annotated in accord with

our model 818.3 GSM MS roams into UMTS network 848.4 GSM subscriber roams into UMTS network annotated in accord with

our model 858.5 UMTS subscriber roams into mixed network [94, 76] 888.6 UMTS subscriber roams into mixed network annotated in accord with

our model 89

9.1 AKA scenario S7 without LTE IV 1009.2 AKA scenario S7 with LTE IV 100

xi

9.3 AKA scenario S7, version without LTE IV, annotated in accord withour model 101

9.4 AKA scenario S7, version with LTE IV, annotated in accord with ourmodel 104

9.5 AKA scenario S8 1099.6 AKA scenario S8 annotated in accord with our model 1109.7 AKA scenario S9 without LTE IV 1159.8 AKA scenario S9 with LTE IV 1159.9 AKA scenario S9, version without LTE IV, annotated in accord with

our model 1169.10 AKA scenario S9, version with LTE IV, annotated in accord with our

model 1199.11 AKA scenario S10 without LTE IV 1229.12 AKA scenario S10 with LTE IV 1239.13 AKA scenario S10, version without LTE IV, annotated in accord with

our model 1249.14 AKA scenario S10, version with LTE IV, annotated in accord with our

model 126

Index

3GPP, 1

AK, 37AKA, 2AMF, 37AS, 46AuC, 21AUTN, 37

BDDs, 9BSC, 21BSS, 21BTS, 21

CAP, 22challenge-response authentication, 59CK, 37CMC, 23

E-UTRAN, 46eNB, 46EPS, 40

FN, 21

GSM, 1

handover, 1HLR, 21HN, 21HSS, 66

idle mode mobility, 1IK, 37IMSI, 22indirect use-based proved knowledge authentica-

tion, 62

LTE, 1

MAC, 37MCC, 26ME, 21MME, 46MNC, 26MS, 21MSC, 21MSIN, 26

NAS, 46

RAU, 77RNC, 37RNS, 37RRC, 49

SAE, 1SAT, 10SIM, 21SMC, 47SN, 21SQN, 37

TAU, 47TMSI, 21

UMTS, 1UP, 49use-based proved knowledge authentication, 62use-based proved knowledge with SNid authenti-

cation, 63USIM, 37UTRAN, 37

VLR, 21

xii

1

Chapter 1Introduction

Over the last several decades, mobile telephony has evolved greatly and mobile de-vices have become ubiquitous. The first generation (1G) technology, which was basedon analog technologies, was introduced in the 1980s [10]. Roughly a decade later,the second generation (2G) technology, which used digital radio signals, was intro-duced. The Global System for Mobile Communications (GSM ) has been the mainstandard for 2G technology. The third generation (3G) technology Universal MobileTelecommunications System (UMTS) was developed by the 3rd Generation Part-nership Project (3GPP) and was introduced at the beginning of the twenty-firstcentury. Recently, 3GPP has developed the fourth generation (4G) technology, whichis best known under the names System Architecture Evolution (SAE ) and Long TermEvolution (LTE) [52]. Currently GSM, UMTS, and LTE are all in active use. Thisleads to interoperation cases such as shown in Figure 1.1 in which a 4G mobile devicewhose home network is 3G, roaming to a 2G serving network.

1.1 Motivation and Goals

There are over 6.8 billion mobile subscriptions worldwide [9]. With the rapid devel-opment of mobile telephony technologies and the pervasiveness of mobile communica-tions in our everyday lives, the security of mobile telephony technologies has becomemore and more important. Over the years, the security of the pure technologies andthe interoperation between GSM and UMTS has been investigated thoroughly. How-ever, LTE brings a big challenge of studying the interoperation cases involving all thethree technologies.

The 3GPP specifications systematically specify the interoperation cases be-tween UMTS and GSM [1, 7]. The LTE specification [8] details the mechanisms forsecurity context switching and mapping to facilitate idle mode mobility and handover1

1The term handover refers to mechanisms supporting mobility in the context of ongoing phonecall or data exchange; idle mode mobility refers to mechanisms supporting mobility while no such

4G mobile station(Verizon)

2G serving network(T-Mobile)

3G home network(Verizon)

Figure 1.1: Example of an interoperation case

2

between LTE and the previous technologies. However, this applies to maintainingcontext during handover and idle mode mobility. The specification for LTE doesnot explicitly address establishing of an initial security context, which is establishedby an authentication procedure, for interoperation. In particular, to date there isno comprehensive enumeration of all interoperation cases and their respective proce-dures for Authentication and Key Agreement (AKA)2. Consequently, analyzing thesecurity of all possible combinations of interoperation scenarios by hand is a tediousand unreliable undertaking. Model checking techniques provide an effective way toautomatically find vulnerabilities in, or to prove the security properties of, securityprotocols.

The goal of this work is to find attacks or give evidence for the security ofmobile telephony AKAs, especially in LTE and the interoperation scenarios involvingLTE components, by using automated security protocol analysis tools instead of usingtedious ad hoc (pencil and paper) approaches.

1.2 Approach

Wireless networks are complex and possess different aspects of security including thesecurity of the protocols, the cryptography systems, the application interfaces, theimplementations, and the systems. Attacks can exploit any aspect. When analyzingthe mobile telephony protocols and the interoperation scenarios, we focus on theAKAs, and we abstract from the cryptographic algorithms and other aspects of thesystem. The AKAs are crucial for the security of the technologies. Through theAKAs, the communicating parties aim to authenticate each other (except in GSM –only one-way authentication is expected in GSM AKA) and to establish the sessionkeys, which are used in the future communications.

Our analysis is based on the Dolev-Yao model ([50], see Section 2.2.1), whichassumes perfect cryptography. We also assume the communication in the network sideis secure. Specifically, the communication between the serving network and the homenetwork and the communication between the core network and the base stations areassumed secure. Although the inside network protocols are specified by the standard,the operators may have different implementations.

We choose ProVerif [27] to model and analyze the mobile telephony protocols.According to the comparison of several well-known protocol verifiers by Cremers etal. [43], ProVerif has good running time performance. It is a mature tool under activedevelopment. It has a significant user community and has been used for a numberof security protocols. The modeling language is intuitive and expressive; it allowsinfinite state systems. The analysis technique has been formally defined and provensound [27]. It allows checking an unbounded number of sessions. In case a property

service is currently active.2In some standards, the term AKA has more specific meaning and varying terminology is used,

e.g., depending on whether authentication is mutual.

3

does not hold, the tool can generate attack traces; these can then be used to testactual implementations, although that is beyond the scope of this work.

1.3 Thesis

Symbolic analysis tools can effectively find attacks in, and show the security of, mobiletelephony authentication protocol interactions in interoperation scenarios.

1.4 Contribution

The first contribution of this work is to provide new formal models for the GSM,UMTS, and LTE AKA scenarios in the symbolic (Dolev-Yao) model of cryptogra-phy. We provide a detailed discussion on rationale on design decisions for the modelsand their abstractions from the real protocols. Using ProVerif, the secrecy and au-thentication properties can be automatically checked, thus replacing tedious manualanalysis.

The second contribution of this dissertation is to systematically enumerate ofall possible interoperation cases between GSM, UMTS, and LTE. We classify thesecases as allowed, disallowed, or uncertain, with explicit rationale making detailedreference to the specifications. Of the 243 cases identified, 19 cases involve GSMand UMTS technologies only, and as such are fully treated by the UMTS specifica-tion [7]. For cases involving LTE components, an enumeration did not previouslyexist; it required extensive study of the lengthy specifications. Based on the compat-ibilities (explicitly specified in the specifications) between the components, 138 casesare clearly ruled out and 38 cases are clearly allowed. For the remaining 48 cases thespecifications and documentation based on the specifications do not provide a clearindication whether these cases are allowed. For the 48 uncertain cases, we determinethe conditions under which these cases could occur.

As a third contribution of this dissertation, we identify the corresponding AKAscenario used to establish the initial security context for each allowed or uncertaincase. It turns out that there are only 10 distinct AKA scenarios, including the pureGSM, pure UMTS, and pure LTE AKA scenarios which apply in some interoperationcases. Although the GSM/UMTS scenarios are described in the specifications, thatis not the case for 86 roaming cases involving LTE. For three of those scenarios weidentify two variations which are both consistent with the specifications and whichhave different authenticity properties.

As a fourth contribution, we provide formal models for all the interoperationscenarios including variations. We provide a security analysis based on these models.The models are composed in a modular fashion from the blocks that comprise the basicprotocol models for GSM, UMTS, and LTE. This will facilitate adding or modifyingscenarios, in case of changes to the specifications or the conditions for the uncertaincases to occur.

4

As a fifth contribution, we compare the authenticity achieved by the AKAscenarios. We categorize the authenticity of the MS to the SN and the authenticityof the SN to the MS into four levels and identify the level of authenticity achieved byeach scenario. We also summarize that which protocol blocks are critical to achievethe highest level of the authenticity.

1.5 Outline

The remainder of this dissertation is structured as follows: In Chapter 2, we introducebackground on model checking as well as the Dolev-Yao attacker model and Woo-Lam correspondence assertions which are used to specify authentication and secrecyproperties. We also review several tools which are used to formally analyze securityprotocols. We conclude the chapter by introducing the tool ProVerif, which is used inthis work. The next three chapters deal with the three standards respectively. Chap-ter 3 describes the GSM AKA, our model of the protocol, and the analysis results.Section 3.2 provides rationale and guidelines for modeling that apply throughout thework. Chapter 4 provides an overview of the UMTS AKA and discusses our model andanalysis results. Chapter 5 reviews the LTE AKA and presents our model and anal-ysis results. Chapter 6 compares the authenticity achieved by the three pure AKAs.Chapter 7 categorizes all possible interoperation cases into allowed, disallowed anduncertain based on the standards and other documentations. Chapter 8 describesthe interoperation cases only involving GSM and UMTS components, and presentsour models and findings. Chapter 9 describes the interoperation cases involving LTEcomponents, and presents our models and findings. Chapter 10 summarizes the anal-ysis results of all the AKA scenarios. Chapter 11 concludes this work and suggestsdirections for the future work. An index of definitions is provided on page xii, as wellas an appendix with all the models.

5

Chapter 2Background on Security Protocol Analysis and Related Work

In this Chapter, we first review informal analysis techniques for security protocolanalysis and prior results on analysis of mobile telephony protocols using the infor-mal analysis techniques (Section 2.1). We then provide background on formal analysisof security protocols (Section 2.2). To determine which tool to be used in this work,we review several tools which are used to formally analyze security protocols (Sec-tion 2.3). We introduce an automatic cryptographic protocol verifier called ProVerif,which is used in this work (Section 2.4). At the end, we highlight the prior work onformal analysis of mobile telephony protocols (Section 2.5).

2.1 Informal Analysis Techniques and Prior Work for Mobile TelephonyProtocols

Section 2.1.1 introduces conventional analysis of security protocols by hand or bymeans of fuzz testing. Section 2.1.2 summarizes the prior work on analysis of mobiletelephony protocols.

2.1.1 Conventional Analysis

In current practice, protocol analysis commonly uses informal techniques, specifi-cally, manual protocol analysis and fuzz testing of security protocols. These informalanalysis techniques are discussed in this section.

In conventional analysis of security protocols, a protocol is described as aprogram or as a set of runs. The attacker is assumed to have various capabilities,for example, the attacker may have certain knowledge, and can intercept and injectmessages. Typically, experts go through the possible runs of the protocol, and try tofind scenarios which violate the expected security properties. Such manual protocolanalysis is very time-consuming and tedious, even if the analyzed protocols are simple.By using such methods, it is difficult and problematic to analyze a protocol withmultiple sessions and runs. This kind of analysis depends largely on the skills andknowledge of the experts. There is no guarantee that all attacks will be found.

Fuzz testing [10] is another approach to discover security vulnerabilities inprotocols. It works by mutating the normal traffic or generating and injecting attackscenarios [81, 80] in order to reveal unexpected behaviors such as security propertyviolations or protocol system crashes. To accelerate the testing procedure, faultinjection tools (e.g., DOCTOR [60], ORCHESTRA [48]) have been developed andapplied in validating network communication protocols and distributed protocols. Abenefit of fuzz testing is that it can find implementation flaws as well as protocoldesign flaws. A shortcoming is that it could be difficult to set up realistic tests for

6

interoperation and achieve reasonable coverage. It is not necessary to have access tothe source code in protocol fuzz testing. However, fuzz testing of security protocolsis usually conducted in an ad-hoc manner with input selected either randomly ormanually. While it can find attacks, fuzz testing provides little assurance of theirabsence.

2.1.2 Prior Work

This section highlights the prior work on analysis of mobile telephony protocols.Most of them have been analyzed informally. The ones using formal techniques willbe discussed later in this chapter.

The A5 family of cryptosystems used in GSM and UMTS has been studiedextensively. Golic [56], Goldberg [57], Petrovic et al. [84], Barkan et al. [21], andDunkelman et al. [51] find attacks on the GSM encryption algorithms. Ahmadian etal. [16] show attacks which exploit weakness of A5/2 to eavesdrop or impersonate aUMTS subscriber in a mixed network. Our work focus on protocol flaws rather thancryptographic weaknesses.

Fox [53] finds the false base station attack on the GSM AKA due to the lackof authentication of the network. Meyer and Wetzel [76, 77] show that a man-in-the-middle attack can be performed on one of the cases of interoperation between GSMand UMTS. Meyer and Wetzel [78] also show the attacks on the handover betweenGSM and UMTS based on the GSM encryption and the man-in-the-middle attacks.

Zhang and Fang [93] show that the UMTS AKA is vulnerable to a redirectionattack, which is a variant of the false base station attack. Because the UMTS AKAdoes not include the network identity, the false base station can redirect the trafficto an unintended network. This attack could cause billing problem. They also showa network impersonation attack, in which the attacker requests the authenticationvectors on behalf of an corrupted network and use these authentication vectors toimpersonate another network.

Han and Choi [59] demonstrate a threat against the LTE handover key man-agement, involving a compromised base station. The attack violates the forward keyseparation, and could compromise all the future keys between the victim and sub-sequent base stations. In the attack, the attacker controls a rogue base station anddesynchronizes the fresh keying material in the targeted base station to force the userand the base station to compute the next session key based on the current sessionkey and values about the physical layer information. Because the attacker can learnthe next session key, the attacker can decipher the messages until the next AKA.

Mobarhan et al. [79] evaluate the publically known attacks on GSM and UMTS(and the related technology GPRS), categorizing them in terms of secrecy, integrity,or authenticity properties. Possible security improvements are also discussed.

Golde et al. [54] find and implement two attacks on the GSM paging procedure.The paging procedure is used by the network to locate the mobile stations to start the

7

establishment of incoming call service. The first attack is against a single subscriber.In the attack, the attacker sends out the paging response earlier than the victim, sothat the network ignores the paging response from the victim. Following this denialof service attack, the attacker can also impersonate the victim if no authentication isperformed by the network. The second attack has the same attack scenario, but isagainst a large number of subscribers in a geographic region. Two countermeasuresare proposed to prevent the attacks. The first suggestion is to combine the challenge-response in the AKA with the paging procedure. The other countermeasure is thatthe network always authenticates the subscribers and the network maps all incomingpaging responses to the correct service.

Several other denial-of-service attacks have been found. Lee et al. [69] finda denial-of-service attack on UMTS. In the attack, the attacker triggers the mobileto constantly establish and release radio channels with the network to overload theserving network or cause denial-of-service due to congestion in the signal path. Khanet al. [66] describes the denial-of-service attacks on UMTS by modifying the unpro-tected messages in the UMTS AKA to cause authentication failure or by sending alarge number of valid IMSIs to cause massive authentication data request to exhaustthe bandwidth between the serving network and the home network. Kambourakis etal. [65] also identify similar denial-of-service attacks against UMTS by modifying theunprotected signaling messages transmitted before or during the UMTS AKA.

2.2 Background on Formal Analysis

In this section, we introduce two formal methods to analyze cryptographic protocols:the Dolev-Yao (symbolic) model and the computational model (Section 2.2.1). Wealso discuss the correspondence assertions which are used to formally specify authen-tication properties (Section 2.2.2).

2.2.1 Dolev-Yao (Symbolic) and Computational Model

This section introduces the Dolev-Yao model and discusses what it means to “prove”a property with Dolev-Yao model. This section also introduces the computationalmodel.

Formal methods constitute an effective approach to the analysis of crypto-graphic protocols. There are two main approaches to the formal verification of cryp-tographic protocols. One approach, the so called Dolev-Yao or symbolic model, isintroduced in the seminal paper by Dolev and Yao [50]. In the Dolev-Yao model theactive attacker has complete control over the network. Thus, the attacker can inter-cept, block, remove, or replay any message sent by an honest principal. The attackercan also create new messages from his/her knowledge, and send these messages to thehonest participants. The attacker is a legitimate user and can initiate a conversationwith any other user. It is also assumed that the underlying cryptographic primitives

8

achieve perfect security. The attacker can encrypt and decrypt messages with knownkeys. However, if the attacker does not know the correct decryption key for a givenciphertext, then he/she cannot gain any information from the ciphertext. The perfectcryptography assumption allows that the cryptographic primitives can be representedas symbolic operations. When a property is proved in a Dolev-Yao model, it meansif the protocol is accurately modeled at an abstract level, then there are no attacksat this abstract level. It could be that there are attacks on implementation features,or on cryptographic functions.

Another approach is the computational modeling [55] (e.g. CryptoVerif [26] isan automatic protocol prover using the computational model; the tools EasyCrypt[22] helps automate game-based proofs.), which is based on complexity theory. Ina computational model, messages are bitstrings and cryptographic operations areprobabilistic algorithms on these bitstrings. The attacker in a computational modelis a polynomial-time probabilistic Turing machine. A protocol or system is secure ifthe probability of breaking the protocol or system by the plolynomial-time attackersis very low. The proof of security is to reduce the security properties to computationalhard problems.

Abadi et al. [13] survey computational soundness theorems that relate thesymbolic and computational models. An early survey of the application of formalmethods is provided in [73].

2.2.2 Events and Correspondence Assertion

This section introduces the correspondence assertions and the events used in thecorrespondence assertions.

Woo and Lam [92] define a formal semantic model for authentication protocolsthat is based on two basic security properties, correspondence and secrecy. Informally,correspondence means that the execution of the different principals in an authentica-tion protocol proceeds in a locked-step fashion. When an authenticating principal fin-ishes his/her part of the protocol, the authenticated principal must have been presentand participated in his/her part of the protocol. Secrecy requires that certain infor-mation should not be derivable by an attacker. To specify correspondence propertiesusing correspondence assertions [58, 32], the processes representing the protocol areannotated with events, possibly with arguments that record nonces, keys and otherrelevant information. The events are used to mark important points reached by theprincipals and have no effect on the principals’ behaviors. Events are not visibleto the attacker, nor can they be generated by the attacker. A protocol satisfies anon-injective correspondence assertion, in the form of event(e1(M)) event(e2(M)), ifin all runs, and in the presence of the attacker, each execution of the event e1 withparticular arguments M corresponds to an earlier event e2 with the same arguments.An injective correspondence assertion, in from of inj−event(e1(M)) inj−event(e2(M)),captures a one-to-one relationship. It requires that, for each occurrence of the event

9

e1 with the arguments M, there is a distinct earlier occurrence of the event e2 withthe same arguments. It follows immediately that the number of occurrences of theevent e1 is less than, or equal to, the number of occurrences of the event e2.

Events can also be used to express conditional secrecy, which means thatthe secrecy holds under certain conditions. An example in mobile telephony pro-tocols is that if a principal does not explicitly disable encryption, then cipheredmessage payload will be never learned by the attacker under Dolev-Yao cryp-tographic assumption. To specify such property, an event disableEnc is insertedin the point where the principal disables encryption. The query is specified asquery attacker(paylaod) event(disableEnc), which means that if the attacker obtains thesecret payload then the event disableEnc must have been previously executed.

2.3 Comparative Overview of Formal Tools

In this section, we briefly review the general-purpose model checker and formal toolsused to analyze security protocols (Section 2.3.1). Since Scyther (Section 2.3.2) andAVISPA (Section 2.3.3) are similar to ProVerif and are currently in active use, wediscuss them in detail.

2.3.1 Formal Analysis Tools

In this section, we introduce general-purpose model checkers, SAL and FDR, andspecial purpose tools: NRL Protocol Analyzer and LySa.

In early stages of this work we used SAL, a general purpose model checker. Themain reason to discuss it here is to provide background, because some of the specialpurpose tools are based on model checking. Model checking [40, 39] is a collectionof techniques for automated formal verification of finite-state concurrent systems.To use a general-purpose model checker, the system or protocol is modeled as astate transition system, and the properties are specified in temporal logic. The toolthen performs an exhaustive search of the state space of the state transition systemto check whether the specification is satisfied. The model usually contains severalcomponents, which can be combined synchronously or asynchronously. At each timeinstant, each component performs a transition in synchronous composition, while onlyone component is selected to perform a transition in asynchronous composition. Thestate space can be huge. This causes the so-called state explosion problem [63]. Toavoid the state explosion problem, the symbolic model checking technique has beenproposed and studied. A symbolic model checker works with sets of states, whichare represented by formulas in propositional logic. One symbolic technique is to useBinary Decision Diagrams (BDDs) [63], which often can represent boolean functionscompactly. A number of efficient algorithms for manipulating BDD representationsenable this symbolic technique to be used in model checking. Another technique isknown as Bounded Model Checking, which is based on encoding the model into a

10

propositional SATisfiability (SAT ) problem. A SAT solver is used to search counter-example paths by increasing the path length. This technique can be use with infinitestate system.

SAL (Symbolic Analysis Laboratory) is a general purpose model checker de-veloped by SRI and is a framework combining tools for program analysis, theoremproving, and model checking of transition systems [49]. Protocols are defined as statetransition systems, and security properties including correspondence assertions canbe expressed in temporal logic. The SAL bounded model checker translates a tran-sition system plus properties into a SAT or Satisfiability Modulo Theories (SMT)problem [34]. More specifically, it generates SMT formulae that describe the compu-tations of the system. The SMT solver is used to search for computations that violatethe properties. SAL provides a language for specifying state machines as modules.The transition relation of a module may be specified using guarded commands. Sys-tems may be constructed by composing modules synchronously or asynchronously.SAL also provides a simulator to execute specific transitions, filter states, and findstates satisfying certain assertions.

FDR [71] is another general purpose model checker analyzing CSP processeswhich are translated from protocol descriptions by a compiler called Casper [72].FDR searches the state space to check whether any trace could violate the speci-fications representing the security properties in the presence of the attacker. Loweuses Casper/FDR to find the man-in-the-middle attack on the Needham-Schroederprotocol [71].

Also, there are some special purpose tools: the NRL Protocol Analyzer, LySa,Scyther, and AVISPA. In this section, we briefly introduce the NRL Protocol Analyzerand LySa. We will introduce Scyther and AVISPA in later sections.

The NRL Protocol Analyzer [75, 74] was one of the first tools able to provethe correctness of security protocols without bounding the number of sessions or themessage size. The NRL Protocol Analyzer uses the Dolev-Yao attacker model andspecifies insecure states using a combination of constants and existentially quantifiedvariables. The security properties are specified using rewrite rules. Users may provea set of lemmas to cut down the search space size. When a state is generated,lemmas are used to determine whether it should be kept or discarded. The tool usesa backward search to determine whether a set of “bad” states is reachable.

LySa [31] is a tool similar to ProVerif, which will be introduced later in thischapter. It describes protocols using a process calculus similar to the Spi-calculus [15].The LySa tool provides feedback regarding which message parts can be decrypted aswell as whether a Dolev-Yao attacker can falsely achieve authentication by insertingmessages at any point. The Lysa tool generates an extension of Horn clauses fromthe processes and solves them by the Succinct Solver [82].

11

2.3.2 Scyther

In this section, we review how protocols and security properties are specified andverified in Scyther and list some applications of Scyther. Most material of this sectionis adapted from [41, 46, 47, 42].

Scyther [41] can verify either bounded or an unbounded number of runs, usinga symbolic backwards search based on patterns. Scyther includes the possibility ofunbounded verification with guaranteed termination, analyzes infinite sets of tracesin terms of patterns, and supports multi-protocol analysis.

Protocols are specified in the Security Protocol Description Language(SPDL) [44]. In a security protocol, each principal performs one or more roles, andthe system executes the protocol roles. A role performed by a principal is called arun. The protocol specification describes the behavior of each role in the protocol.Honest principals only execute the events described in the specification sequentially,and may execute any finite number of runs in parallel. A role specification includesa list of role events and some initial knowledge. Dynamic behavior is modeled asa labeled transition system. Messages are exchanged through two multiset buffersshared by all participants. Attacker’s capabilities determine how the messages aretransferred from the output buffer to the input buffer. The options of the attackermodel may be no attacker, Dolev-Yao attacker, wireless communications attacker (itdoes not allow learning from a message and preventing its arrival at the same time),or passive attacker which can only eavesdrop.

Security properties are specified in terms of claim events [46, 47]. A claim eventmeans that if a principal has executed his part of the protocol up to the claim event,he can be sure that the claimed property holds. Secrecy properties are specified suchthat, for each trace, certain information is unknown to the attacker. Authenticationproperties can be specified as synchronizations or message agreements. The authen-tication properties are trace properties. Each trace of the protocol can contain anumber of instances of claim events. Only the claims of principals that communicatewith non-compromised principals are considered. Non-Injective Synchronization (NI-SYNCH) requires that: the send events must occur before their corresponding readevents; the events in the trace corresponds to the events from the protocol; and thecontents of the read messages and their corresponding send messages must match.NI-SYNCH does not rule out replay attacks. Besides the requirements of NI-SYNCH,the Injective Synchronization (I-SYNCH) claim event requires that for all communi-cations preceding the claim, there are a unique set of runs executing the roles in theprotocol.

Scyther verifies the security properties by analyzing classes of traces defined bytrace patterns [42]. All attacks against a security property have a particular pattern.If there exist traces of the protocol that match the attack trace pattern, then the se-curity property is violated by any such trace. If no trace of the protocol matches theattack trace pattern, the security property holds. Scyther provides concise represen-tation of sets of traces. The pattern refinement algorithm takes a pattern representing

12

a set of traces which violate a security property, and refines the pattern into a finiteset of patterns from which one can directly construct traces of the protocol. Therefined patterns represent the same set of traces as the original pattern. If there existsuch refined patterns, then the security property is violated. Otherwise, the securityproperty holds.

Scyther has been successfully used for the analysis and design of a numberof protocols. Here are some highlights. Cremers and Mauw [45] propose a familyof protocols for multi-party authentication and check the protocols using Scyther.They find type-flaw attacks on the protocols. Taha et al. [85] analyze the han-dover schemes and the pre-authentication handover protocol in IEEE 802.16e stan-dard (Mobile WiMAX) using Scyther. An attack in which the attacker learns themaster session key was found in the handover schemes. Another attack found on thepre-authentication handover protocol reveals that the attacker can gain the uniquekey. Taha et al.[86] analyze the privacy and key management protocol in IEEE 802.16(PKMv1) and 802.16e (PKMv2) standards using Scyther. They find a pseudonymityattack in which the attacker can learn the ID of the mobile station in both protocols,and an attack violating the secrecy of the mobile station’s data on PKMv1.

2.3.3 AVISPA

In this section, we review the specification of the protocols and the security prop-erties in the Automated Validation of Internet Security Protocols and Applications(AVISPA) [19]. We also introduce the four back-ends and some applications ofAVISPA. Most material of this section is adapted from [19, 18, 88].

The AVISPA tools use a web-based graphical user interface and support tospecify the security protocols and properties by means of a modular and expressivespecification language, the High-Level Protocol Specification Language (HLPSL) [18].The HLPSL allows users to specify protocols by defining the states of the participantsand transitions between states. The behavior of each kind of participant is specifiedin a module, which can be instantiated by one or more participants. (This is similarto what is done in a general purpose model checker like SAL, but in a general purposechecker one must explicitly model channels and the attacker.)

The message exchanges are specified in transitions, which consist of precondi-tions and actions to be performed when the conditions are satisfied. One session ofthe protocol is a composition of instantiated participants which communicate typi-cally on channels controlled by a Dolev-Yao attacker. The whole system composesone or more sessions and also specifies the initial knowledge of the attacker. A trans-lator named HLPSL2IF automatically translates the specification into IntermediateFormat (IF) based on first-order set rewriting.

Security properties are specified as security goals using concise macros whichare internally specified in terms of linear temporal logic. The secrecy property specifiesthat certain values are allowed to be known only by certain participants. During

13

the runs, whenever the attacker gains the knowledge of a secret value which is notexplicitly specified between him/her and someone else, it should be considered asan attack. Authentication properties check that a principal’s responder is presentin the current session, has reached a certain state, and agrees on certain values.Authentication properties are specified using two auxiliary events: request and witness[88]. Similar to non-injective correspondence assertion, the authentication goal assertsthat a request event has been preceded by a witness event and the two events agreeon certain values. For strong authentication, like injective correspondence assertion,no principal should accept the same values twice from the same responder.

The AVISPA integrates four model-checker back-ends to search a transition sys-tem model for states that represent attacks, i.e. which violate the specified properties.The four back-ends are: the On-the-fly Model Checker (OFMC) [24], the Constraint-Logic-based Attack Searcher (CL-AtSe) [90], the SAT-based Model Checker (SATMC)[20] and the Tree Automata based on Automatic Approximations for the Analysis ofSecurity Protocols (TA4SP) [19]. The OFMC combines infinite state forward model-checking with a lazy Dolev-Yao attacker [23], where terms are generated on-demandduring the forward model-checking process. OFMC uses lazy data type to modelthe infinite state space associated with a protocol. When modeling a lazy Dolev-Yao attacker, it represents terms symbolically to avoid explicitly enumerating thepossible messages which may be generated by the attacker. The representation isevaluated in a demand-driven way. When a particular message part is not to be an-alyzed, the decision about which value the attacker will choose is postponed duringthe search. The CL-AtSe applies constraint solving with simplification heuristics andredundancy elimination techniques. The CL-AtSe is built in a modular way and isopen to extensions for handling algebraic properties of cryptographic operators. TheSATMC builds a propositional formula which represents the transitions relations ofthe protocol. A SAT solver is used to analyze the propositional formula. The TA4SPapproximates the attacker knowledge by using regular tree languages and rewriting.The Dolev-Yao attacker model is assumed in all the four back-ends.

A number of security protocols have been tested by the AVISPA tools, includ-ing the protocols from the Clark/Jacob library [38]. The AVISPA tools have detecteda number of previously unknown attacks on some of the protocols analyzed. Lim etal. [70] propose a handover protocol for WLAN, WiBro and UMTS, and verify itusing AVISPA. Bouassida et al. [33] analyze the key management architecture forhierarchical group protocols using AVISPA, and find an attack on the members pro-motion protocol. Oheimb and Cuellar [91] propose protocols for location privacy andverify the protocols using AVISPA. They find a man-in-the-middle attack during thedesign process by analyzing the AVISPA models of the proposed protocols.

14

2.4 ProVerif

This section gives the rationale of our choice of ProVerif (Section 2.4.1) and introducesthe modeling language (Section 2.4.2) which will be used throughout this dissertation.We briefly describe the analysis techniques (Section 2.4.3). We briefly survey theapplications (Section 2.4.4) of ProVerif.

2.4.1 Rationale for the choice of ProVerif

Recall from the previous sections, general purpose model checkers, such as SAL, canbe used to analyze different aspects of security. The behavior of the attacker can becustomized when modeling protocols using general purpose model checkers. However,in our experience, SAL may take hours or days to check the security properties due to alarge or infinite state space. ProVerif, Scyther, AVISPA and NRL are specialized toolsfor cryptographic protocol analysis. They all have the built-in Dolev-Yao attacker,thus the user does not need to explicitly specify the attacker’s behavior. Since theNRL Protocol Analyzer is not publicly available, we discuss the other three specializedtools in order to decide to use which one to model and analyze the mobile telephonyprotocols.

In the authentication scenarios of mobile telephony technologies, the servingnetwork may run a large number of sessions at the same time. We want to model andcheck the security properties involving an unbounded number of sessions. ProVerif,Scyther, and TA4SP of AVISPA support analysis of an unbounded number of ses-sions. However, no trace is output by TA4SP when an attack is found. Thus it isinfeasible to decide whether the attack found by TA4SP is a false attack. Accordingto the performance comparison of ProVerif, Scyther and AVISPA done by Cremers etal. in [43], ProVerif is the fastest tool when checking the secrecy and authenticationproperties for the set of protocols analyzed in that work. ProVerif has capabilities inmodeling and specifying the features equivalent to Scyther and AVISPA. In addition,ProVerif is a mature tool under active development. It has a significant user commu-nity and has a good documentation [83]. Additionally, ProVerif is able to model thefeatures we want to model. Therefore we choose ProVerif to model and analyze themobile telephony protocols.

2.4.2 Specifying Protocols and Security Properties

In this section, we introduce the process algebra used by ProVerif to specify protocols.We describe the term and process grammar, as well as functions and rewrite rules torepresent cryptographic primitives. This section also discusses how to specify secrecyand authentication properties in ProVerif. We briefly describe how to use ProVerif inpractice. Most of the material is adapted from [27, 25, 30].

The protocol specification language is an extension of pi-calculus (Spi-calculus[15]), which is defined in Figure 2.1. Terms include variables and names. The attacker

15

M, N ::= terms

x, y, z variable

a, b, c, k name

(M1, . . . ,Mn ) tuple

f(M1, . . . ,Mn ) constructor

P, Q ::= process

0 nil

out(M, N); P message output

in(M, x: t ); P message input

P|Q parallel composition

!P replication

new n:t; P name restriction

let x: t = M in P else Q term evaluation

if M=N then P else Q conditional

event(M); P event

Figure 2.1: Term and Process Grammar

knows the free names by default. However, names can be declared private. Privatenames are not a priori knowledge to the attacker. ProVerif supports tuples, writtenas (M1, . . . ,Mn). The attacker has the capability of constructing a tuple when he/shehas the terms M1, . . . ,Mn , and the attacker also can recover the i-th element whenhe/she possesses the tuple. There are constructors that are used to model primitivessuch as one way functions, encryption and digital signatures. Data is a special kindof constructor. A constructor declared as data is similar to a record: the attackercan construct and decompose data constructors. The relationships between the prim-itives are captured by destructors which are modeled using rewrite rules. Destructorsmay be non-deterministic operations on terms. Specifically, when several rules canbe applied, only one is chosen. However, ProVerif considers all possibilities when rea-soning. For example, symmetric encryption can be defined by the binary constructorsencrypt which takes a bitstring and a key as arguments and returns a bitstring.

fun s e n c r y p t ( b i t s t r i ng , key ) : b i t s t r i n g

A destructor expressing how decryption inverts encryption may be defined as:

reduc f o r a l l m: b i t s t r i ng , k : key ; s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.

Any party, including the attacker, can compute sdecrypt(X,k) if he/she has obtained X

and k, so m can be obtained if X is sencrypt(m,k). In a symbolic model, the attackercan learn nothing from sencrypt(m,k) if he/she does not have k. Constructors anddestructors can be declared as public or private. If they are declared as public, theattacker can use them to build or manipulate terms. Otherwise, they can only beused by honest principals. One application of private destructors is to model key

16

distribution (See section 3.2.1).Processes are defined as follows. The nil process does nothing. The process

out(M, N); P outputs N on the channel M, and then executes P. The process in(M, x:t ); P

awaits a message of the type t from the channel M, and then executes P. P|Q is theparallel composition of process P and Q. The replication !P represents an unboundednumber of processes of P running in parallel. The restriction new n:t; P creates a newname of the type t, which can be used to model fresh random numbers, private chan-nels, or keys. In the term evaluation let x: t = M in P else Q, if M contains destructors,it first evaluates M; if the evaluation succeeds, then x is bound to the value of M andexecutes P; otherwise, it executes Q. If M does not contain destructors, x is alwaysbound to M and P is always executed. The syntax of the conditional is standard: ifM and N can be reduced to the same term, the branch of P is taken; otherwise thebranch of Q is taken. The process event(M); P executes event(M), and then executesP. Events annotate processes and mark the stages reached by the protocol but donot affect their behavior. Events are used to specify correspondence assertions (seeSection 2.2.2).

The pi calculus of ProVerif supports types. There are built-in types channel,bitstring and bool. ProVerif statically checks types, which helps the user avoid mod-eling errors. However, ProVerif ignores types during analysis, i.e., types do not affectthe dynamic semantics of processes. This enables ProVerif to detect type flaw at-tacks [61].

2.4.3 Analysis Technique and Approximation

In this section, we introduce how ProVerif translates the processes into Horn clauses.Given a process and a set of names which model the protocol, ProVerif first instru-ments the process to define formal terms (i.e., function symbols, which are introducedlater in this section) associated with the names, and then builds a set of Horn clausesthat encode protocol executions including the behavior of the attacker. This sectionalso introduces the basic idea of the resolution-based algorithm used by ProVerif todetermine whether a fact is derivable from the Horn clauses.

The instrumentation records dependencies and keeps track of sessions in orderto model freshness. The new names are treated as function symbols, which takethe messages received by inputs before the new action and the session identifiers asarguments. Each replication of the process is labeled with a distinct, fresh sessionidentifier. The identifier indicates which copy (or session) is executed. Each restrictionnew a in processes representing honest principals is labeled as a function symbol a[t , s ],where t may be (1) a sequence of messages received before the new name is generated,and/or (2) the results of non-deterministic destructor applications before the newaction; and where s is a sequence of session identifiers that label replications beforethe new action. Using function symbols for new names, at most one name correspondsto a given a[t , s ] in each run of the process. Therefore, different names are not merged

17

by the verifier. In fact, moving the restrictions downwards in the process includesmore received messages in the first argument of the function symbol. Therefore, theanalysis is more precise and more costly. A new name b created by the attacker islabeled as a function symbol b0[b[s ]] , where s is a sequence of session identifiers thatlabel replications before the new action. The symbol b0 is a special name which isdistinct from other such symbols. It is easy to generate the instrumentation for theattacker by using such a special symbol. Since the attacker can generate names atany time, there is no relation between the generation of new names and the messagespreviously received by the attacker.

The Horn clauses are in the form F1 ∧ · · · ∧ Fn ⇒ F, where F1, . . . , Fn , and F

are facts. Several facts are defined as follows: The fact attacker(p) represents thatthe attacker knows p. The fact message(p, p’) represents that the message p’ may besent on the channel p. The fact m-event(p) represents that event p must have beenexecuted. The fact event(p) represents that event p may have been executed.

ProVerif first builds the initial knowledge of the attacker. Each public freename a is known by the attacker, so the clause attacker(a []) is generated. Since the at-tacker can generate an unbounded number of new names, the clause attacker(b0[x])

is included in the attacker’s clauses. For each constructor f(M1, . . . , Mn ), if theattacker has the knowledge of M1, . . . ,Mn , then the attacker can apply the publicconstructor. This is represented by the clause attacker(M1) ∧ · · · ∧ attacker(Mn ) ⇒attacker (f(M1, . . . , Mn )). Similarly, for each public destructor reduction g(M1, . . . , Mn )

→ M, if the attacker has the knowledge of M1, . . . , Mn , then the attacker can applythe public destructor. The destructor is represented by the clause attacker(M1) ∧ · · · ∧attacker(Mn ) ⇒ attacker(M). The attacker can listen to all channels he/she has, sothe clause message(x,y) ∧ attacker(x) ⇒ attacker(y) is generated. The attacker can alsosend the messages he/she has on the channels known by the attacker, so the clauseattacker(x) ∧ attacker(y) ⇒ message(x,y) is generated.

A protocol is typically specified in terms of the process calculus described inSection 2.4.2. A process is translated into a set of clauses. These clauses have theform H ⇒ F, meaning that if the steps defined by H have happened then the stepdefined by F can happen. The translation uses a sequence of facts (H) which has theform F1,∧ . . . ,∧ Fn to keep track of messages received and the events that have beenexecuted. Initially, this sequence is empty.

The nil process does nothing, so the translation of the nil process is empty.The translation of message output out(M, N); P in the context of an enclosing processadds a clause H ⇒ message(M, N), where H is a sequence of facts. Since the messagesreceived and events executed before this output are recorded in H, the clause signifiesthat if all facts in H are true, then the message (output N on the channel M) istriggered. The translation of message input in(M, x: t ); P extends H with the fact ofthe inputing message as H ∧ message(M, x). The translation of parallel compositionof two processes is the union of the clauses for both processes. Replication does notneed to be translated, because Horn clauses can be applied many times arbitrarily.

18

The translation only inserts new session identifiers into the environment. Since thenew names are substituted with function symbols in the instrumentation process, nomore translation is needed here. The translation of term evaluation is the union oftwo sets of clauses: those for the process where the evaluation succeeds (boundedvariables are replaced by the corresponding terms), and those for the process wherethe evaluation fails. Similarly, the translation of the conditional is the union of clausesfor the processes where the condition is true, and clauses for the processes where thecondition is false. The translation of events extends H with the fact m-event(M) as H

∧ m-event(M). Adding m-event into the hypothesis means the following process can beexecuted only if the event has occurred before. Furthermore, the translation of theevent also adds another clause H ⇒ m-event(M) to signify that the event is triggeredwhen all facts in H are true.

The translation ignores the replications of actions, because the Horn clausescan be applied any number of times. This approximation (implicit replications ofactions) helps for efficient verification with infinite state space and with any numberof protocol runs. However, the approximation can cause false attacks. A particularcase of this approximation is that if a message has been sent on a private channel atsome point, it may be sent again later.

Security properties in ProVerif are specified as queries. A secrecy property isspecified as a query of the attacker’s knowledge (the fact attacker(M)). When the factattacker(M) is derivable from the Horn clauses, the attacker may have the knowledgeof M. When the fact attacker(M) is not derivable from the clauses, there is no way thatthe attacker can gain the knowledge of M. The authentication properties are specifiedas correspondence assertions in the form of event(e1(M)) event(e2(M)). If all clausesthat conclude event e1 contain event e2 in their hypotheses, then event e1 is derivableonly when event e2 holds, so the correspondence assertion is proven. To determinewhether a fact is derivable from the Horn clauses, ProVerif uses a resolution-basedalgorithm [25]. The basic idea is to combine pairs of clauses by unification. When thehypothesis of one clause C and the conclusion of another clause C’ are unifiable, a newclause C’ ◦ C can be inferred by removing the conclusion of C’ and replacing it withthe hypothesis of C. The facts which are not in the form of attacker(x) or m-event(x)are selected in each clause, and the resolution is performed only on the selected facts.The search for a derivation consists of two phases: in the first phase, the clausesrepresenting the protocol and the attacker are inserted. After simplification andelimination, ProVerif executes a fixpoint iteration that adds clauses created by theresolution. In the second phase, it executes a backward depth-first search, whichstarts with the goal as the root of the derivation and tries to grow the tree. Eachbranch of the tree grows upwards until it is complete, before the algorithm moves onto grow the next branch. The solving algorithm is described in [25] in detail.

This solving algorithm is not always guaranteed to terminate. But it is provento terminate for tagged protocols [29] with some conditions. A tagged protocol is de-fined as a protocol in which a unique constant is added to each message. By adding the

19

unique constants, each application of a constructor can be distinguished from otherconstructors. It is shown that the solving algorithm terminates on tagged protocolsusing only public channels, public-key cryptography with atomic keys, shared-keycryptography and hash functions.

2.4.4 Applications

This section highlights the applications of ProVerif on a number of protocols. Changand Shmatikov [36] use ProVerif to analyze the Bluetooth device pairing protocols.They confirm the offline guessing attack [64] in the Bluetooth device pairing protocolspecified in Bluetooth standard version 1.2 and find an attack scenario in BluetoothSSP when the same device is involved in concurrent SSP sessions. In the attackscenario, the number displayed on the screen may not have been computed in thesession which the user is trying to authenticate. This attack may not be practical,since the real implementation may not allow concurrent sessions of pairing. Abadiet al. [14] analyze the Just Fast Key protocol using ProVerif and find some minorlimitations and weaknesses. Abadi et al. [12] use ProVerif to verify a certified emailprotocol and prove the main security properties. Blanchet and Chaudhuri [28] useProVerif to analyze the protocol of secure file sharing on untrusted storage. Theyfind an integrity attack and propose the fix. Chen and Ryan [37] confirm an attackon current authorization protocols for TPM using ProVerif. They propose and provecorrectness of a new authorization protocol for TPM. ProVerif is used to analyze andverify an electronic voting protocol by Kremer and Ryan [67]. ProVerif is used toprove strong secrecy properties in work of Bruso et al [35] on privacy for RFID.

2.5 Prior Work on Formal Analysis of Mobile Telephony Protocols

We discussed some prior work on analysis of mobile telephony protocols using theinformal analysis techniques in Section 2.1.2. In this section, we highlight some workfor mobile telephony protocols using formal techniques.

The UMTS AKA is manually proved using an enhanced BAN-logic and theTemporal Logic of Actions (TLA) in the 3GPP specification [2].

Tsay and Mjølsnes [89] find an attack on the UMTS and LTE AKA usingCryptoVerif, an automated protocol analyzer based on a computational model. Infact the attack lives at the symbolic level. It depends on insecurity of the connectionbetween the serving network and the home network. In the attack, the attacker sendsout the victim’s IMSI and his own IMSI at the same time to trigger two concurrentAKA sessions. The attacker then redirects the authentication vector response in-tended for him to the SN and makes the SN believe that the authentication vector isfor the victim. At the same time, the attacker blocks the authentication vector mes-sage for the victim. Then the attacker redirects the authentication challenge messageintended for the victim to himself. Because the authentication vector is originally

20

generated for the attacker, the attacker can compute the correct response. So theattacker can complete the authentication with the SN by impersonating the victim,causing HN bill the victim for the service used by the attacker. In our work we assumethe connection between serving network and home network is secure. (Although thestandard specifies the protocols, their implementations are operator-specific.)

Lee et al. [68] analyze the anonymity property of the UMTS and LTE AKAand connection establishment protocols using formal security (computational) models.The assumption in this work is that the attacker is not capable of impersonating anynetwork devices and the underlying cryptographic system is perfect. They manuallyprove the protocols meet the anonymity requirement, under these assumptions.

Arapinis et al. [17] find two attacks against anonymity in UMTS, usingProVerif. To perform the first attack, the attacker sends the paging request messagewith a victim IMSI to check whether the victim is in a particular area. By sendingthe paging request multiple times, the attacker can learn the correlation between theIMSI and the TMSI (These terms are introduced in Chapter 3.). In the second at-tack, the attacker first intercepts one legitimate AKA and records the authenticationchallenge message. The attacker then replays this authentication challenge messageto learn whether the victim is in the area by checking the return failure message.

21

Chapter 3Modeling and Analysis of GSM

This chapter provides an overview of the GSM AKA and its security goals (Sec-tion 3.1) and presents our model of the protocol (Section 3.2), the specifications ofsecurity properties, and our findings (Section 3.3). The security goals, design deci-sions, and security property specifications are applicable to other protocols, so thischapter serves as an introduction for all three technologies.

3.1 Overview of GSM AKA

This section describes the GSM AKA and informally specifies the security goals. Wedivide the AKA into blocks and explain which blocks intend to achieve which goals.

The GSM network architecture is depicted in Figure 3.1 [94, 76]. The figureis taken from [76]. A GSM network consists of several functional entities. A MobileStation (MS) is a combination of the Mobile Equipment (ME ) and the SubscriberIdentity Module (SIM ). The SIM card contains the subscriber’s data such as theuser’s identification number and a list of available networks. The SIM card alsocontains the algorithms for authentication and ciphering. In a GSM network, theMS connects to a Serving Network (SN ) via a particular Base Transceiver Station(BTS). An SN may be the MS’s wireless service provider, i.e., its HN or a ForeignNetwork (FN ). An MS might receive service from an FN in areas where its HN doesnot provide service. The SN consists of Mobile Switching Centers (MSC ) and Vis-itor Location Registers (VLR). One MSC controls several Base Station Subsystems(BSS). The Base Station Controller (BSC ) is the central network element of BSSand controls the radio network. Each BSC maintains multiple BTSs. The VLR con-tains the information of MSs currently in the service area and keeps track of the MSs’locations. The Home Network (HN ) contains MSCs, the Home Location Registers(HLR) and the Authentication Centers (AuC ). The HLR maintains the permanentinformation of subscribers and also keeps track of the MS’s location. The AuC storesthe long-term key Ki and contains the algorithms to generate authentication data.

The goal of the GSM authentication is to authenticate the MS to the SN and toestablish an encryption key that can then be used to protect the user data exchangebetween the MS and BS. In addition to the authentication of the MS, GSM is alsodesigned to keep the encryption key secret. If the traffic between the MS and SN isencrypted under the encryption key, the Dolev-Yao attacker (see Section 2.2.1) is notsupposed to be able to learn the message payloads.

Figure 3.2 shows the AKA. We divide the AKA into blocks following [76], whichwill be used in the interoperation cases. In block GSM I of the protocol, an MS firsttransmits its Temporary Mobile Subscriber Identity (TMSI ) to the MSC/VLR. The

22

MS

ME + SIM

SN VLR

BSS

MSC

BTS BTS

BSC

HN MSC

HLR

AuC

MS: Mobile Station ME: Mobile Equipment SIM: Subscriber Identity Module SN: Serving Network MSC: Mobile Switching Center VLR: Visitor Location Register BSS: Base Station Subsystem BSC: Base Station Controller BTS: Base Transceiver Station HN: Home Network HLR: Home Location Register AuC: Authentication Center

Figure 3.1: GSM architecture [94, 76]

CAPabilities (CAP), i.e., the encryption algorithms the MS supports is also sentto the BS. In case the MSC/VLR does not recognize the TMSI, i.e., the MSC/VLRcannot resolve the received TMSI to a unique International Mobile Subscriber Identity(IMSI ), the MSC/VLR will require the MS to send its unique IMSI, and will allocatea new TMSI to the MS. (Allocating a new TMSI is not shown in Figure 3.2; it occursafter the successful authentication.)

In block GSM II, the MSC requests authentication vectors from the MS’s HN(see Message 5 in Figure 3.2) by sending the IMSI. The MS and the HN share a long-term symmetric secret key Ki . Using this pre-shared secret key Ki and a randomnonce RAND , the HN generates an authentication vector consisting of the threecomponents RAND , XRES , and a session key Kc. XRES and Kc are computedusing the algorithms A3 and A8 [94] respectively.

Upon receiving the authentication vector (Message 6), the MSC starts a chal-lenge response exchange with the MS in block GSM III. Specifically, the MSC sendsthe challenge RAND to the MS (Message 7). Based on the received RAND and thepre-shared key Ki stored on its SIM card, the MS computes the session key Kc as wellas a response RES to the received challenge RAND . Subsequently, the MS sends thecomputed response RES to the MSC. If RES matches the response XRES (whichthe MSC received from the HN as part of the authentication vector), then the MShas successfully authenticated itself to the SN.

In block GSM IV, the MSC forwards the session key to the BS on a securechannel. The BS then decides which encryption algorithm will be used to encrypt the

23

MS HN

7. RAND

8. RES

5. IMSI

6. RAND, XRES, KC .

4. IMSI

1. CAP

10. Selected algorithms

BS

RES = A3(Ki, RAND) KC = A8(Ki, RAND)

Verify RES = XRES

Decide algorithms

Generate RAND XRES = A3(Ki, RAND)

KC = A8(Ki, RAND)

2. TMSI

3. User ID Request

GSM

I G

SM II

GSM

III G

SM IV

MSC

11. CMComplete

9. KC

Figure 3.2: GSM message sequence diagram [94, 76]

communication on the air interface between the BS and the MS (based on the CAPit received from the MS earlier). The BS informs the MS of its choice in the CipherMode Command (CMC ) message (Message 9) and starts the possibly encryptedcommunication. The MSC/VLR generates a new TMSI for the MS and sends it tothe MS. The new TMSI is recorded for subsequent traffic.

The protocol assures the SN of the authenticity of the MS in case the responseRES received from the MS matches the XRES received from the HN as part of theauthentication vector. Only an MS holding the pre-shared key Ki will be able to com-pute the correct result RES in response to the random challenge RAND (assumingthe security of algorithms A3 and A8).

However, GSM does not provide any assurance for the MS that it is in factconnected to a legitimate BS of the SN. The false base station attack was first de-scribed in [53]. The false base station attack is a man-in-the-middle attack, i.e., thefalse base station sits in between the MS and the legitimate BS, pretending to be alegitimate BS when communicating with the MS and pretending to be a legitimateMS when communicating with the actual BS. Since the MS sends its capabilitiesCAP in the clear, it is possible for a false base station to intercept and modify that

24

information before forwarding it to a legitimate BS. In particular, it can change thecapabilities CAP it received from the MS so that the legitimate BS will believe thatthe MS cannot support encryption of data or voice traffic. The false BS will simplyrelay Messages 7 and 8 between the MS and the legitimate BS thus facilitating theproper authentication of the MS to the legitimate BS. The verification of whether ornot the RES matches the XRES succeeds and the BS believes it is serving the MS.The legitimate BS has no choice but to select the no-encryption option as it believesthat the MS does not support encryption. (Of course, the BS could refuse to servicethe MS). Consequently, the false BS will be able to listen in and arbitrarily modifythe unencrypted communication between the MS and the legitimate BS.

In summary, the following security properties are expected:

• Key SecrecyThe pre-shared key Ki and the cipher key Kc should be kept secret, i.e., the keysare unknown to the attacker.

• Conditional Payload SecrecyThe data traffic should remain secret against the attacker if the SN chooses to useencryption. Vulnerabilities of the encryption mechanisms are not taken into ac-count, because the attacker model is the Dolev-Yao attacker model, which assumesperfect cryptography (Section 2.2.1).

• Authentication of the MS to the SNThe GSM AKA is designed to provide for the authentication of the MS to the SN.

The GSM AKA is not intended to guarantee the following properties:

• Payload Secrecy (unconditional)The secrecy of the data traffic cannot be guaranteed in general, e.g., if the SNdecides not to use encryption.

• Authentication of the SN to the MSThe GSM AKA does not provide for the authentication of the SN to the MS.

3.2 Modeling the GSM AKA

In this section we provide an overview of the main design choices and design rationales.We also present detailed explanation of the ProVerif model.

3.2.1 Design Choices

In this section, we list the key design choices used in the model.Modeling secure communication using a private channel: In our work,

it is assumed that the communication between the SN and the HN is adequatelysecure. One way of modeling the secure communication can be done by using a private

25

channel between the SN and the HN. Traffic on a private channel is not accessible tothe attacker, while messages on a non-private channel can be copied, deleted, andfabricated by the attacker.

Another way of modeling the secure communication between the SN and theHN is by encrypting the communication on a public channel. A secret key is sharedbetween the SN and the HN and is never disclosed. The communication betweenthe SN and the HN are encrypted and decrypted using the secret shared key. Sinceperfect cryptography is assumed in the Dolev-Yao attacker model (Section 2.2.1), thecommunication over the public channel is secure as long as the shared key is keptsecret.

The model using encryption on communication between the SN and the HNis more complex than the one using private channel, because when modeling securecommunication using encryption, each message has to be encrypted when it is sentout and has to be decrypted when it is received. We use a private channel to modelthe secure communication between the SN and the HN in our model.

A consequence of using private channel is that if we use injective correspon-dence assertion to specify authentication properties for multiple sessions, false attackswill be found due to the approximation used by ProVerif (see Section 2.4.3). Sincestandard devices do not support multiple sessions of authentication, we feel it is notimportant to require injectivity when specifying authentication properties. If an or-dinary correspondence assertion holds, then the injective version will in fact hold aslong as the device does not support multiple sessions.

Using message headers to identify messages: In our model, each messagehas a header to indicate the type of the message content. Using message headersallows us to use only one channel between two principals. If message headers are notused and only one channel is used between two principals, type flaw attacks [61] mayexist. In addition, with message headers in the model, each principal checks whetherthe message header in the received message matches the expected header. If it doesnot match, the message is simply discarded. This mechanism dramatically reducesthe state space of the model.

In practice, the general message format is defined in [11]. Some fields arespecified to help the communicating parties to identify messages. The message typesare listed in [62]. For example, message type “IDENT REQ” is used in the messagesent by the BTS to the MS to request the identification of the MS. So, we believe itis reasonable to use message headers to identify the messages.

Using boolean variables to represent capabilities: The capabilities of theMS are a set of encryption algorithms supported by the MS. By employing the Dolev-Yao attacker model which assumes perfect cryptography, any encryption algorithmis assumed adequately secure in our model. Thus, we only consider two kinds ofcapabilities: capable of encryption or not. So we model that the MSs may or maynot support encryption, but we abstract the particular algorithms prescribed by thestandard, using just a boolean variable. By using rewrite rules, the MS process can

26

non-deterministically choose whether it is capable of encryption or not. The analysisof ProVerif will consider all possible executions, which thus include those where theMS has encryption and those where it does not. This is similar than analyzing twodifferent models for the two kinds of MSs.

Omitting TMSI/ID request messages: When an MS first roams into anFN, an IMSI is always requested. As mentioned in Section 3.1, if the SN cannotresolve the received TMSI, the SN will require the MS to send the IMSI. An activeattacker can always intercept the message containing the TMSI and send a “wrong”TMSI to the SN, so that the SN cannot resolve this “wrong” TMSI; thus forces theSN to request the MS to send its IMSI. To simplify our model, the TMSI and IDrequest messages are omitted.

Using a fresh value to represent an IMSI: IMSI is the permanent identifierof a subscriber and it is used to uniquely identify the mobile subscriber. An IMSIconsists of three parts [3]: (a) Mobile Country Code (MCC ), which identifies thecountry that the subscriber domiciles, (b) Mobile Network Code (MNC ), whichidentifies the HN of the subscriber, and (c) Mobile Subscriber Identification Number(MSIN ), which identifies the subscriber within the HN. The IMSIs of the MSs couldbe modeled as a sequence of numbers, represented by integers in ProVerif [28], touniquely identify the subscribers. In our model, we use fresh value to represent theIMSI. This is a modeling convenience: it models uniqueness; it means we cannotfind attacks that somehow exploit information carried by the IMSI. Fresh values areunguessable by the attacker. However, in our model, the MS sends the IMSI in clearover the public channel as it should according to Figure 3.1. Thus, the attacker canlearn the IMSI by eavesdropping on the public channel. In practice, an active attackercan gain the IMSI using the so-called “IMSI catchers” [53].

Using a table to model registration of the MS: It is assumed that reg-istration of the MS devices, including key distribution, is done securely by providers.In practice, the AuC maintains a database of the credential pair (IMSI, Ki). Asdiscussed in [30], key distribution can be modeled using private channels, using con-structors and private destructors, or using a table.

When modeling key distribution using a private channel c, one process outputsan unbounded number of copies of the credential pair (IMSI, Ki) over the privatechannel (out(c, (IMSI, Ki))). To get the key corresponding to the IMSI, another processreads on the private channel by in(c, (=IMSI, k:key)).

When modeling the key distribution using constructors and private destructors,the IMSI is defined as a function (constructor) of the Ki , which is declared as a privatefree name. This constructor is public, so that the attacker can also use the constructorto associate the key he/she generates with an IMSI. The destructor returns the keyfrom the IMSI. The destructor is private so that the attacker cannot obtain all thekeys from the IMSIs.

Our model uses a private table to associate keys with identities. In ProVerif,processes can access and populate the tables, but not delete entries. Two actions can

27

be executed on the table, insert and get. The insert action inserts a record into atable. The get action tries to retrieve a record which matches some pattern, if norecord is found, the process blocks; if several records can be matched, one possibilityis chosen, however, ProVerif considers all the possibilities when reasoning.

Modeling key distribution using private channels is equivalent to modeling itusing tables [30]. One advantage of modeling key distribution using constructors anddestructors is that it sometimes may solve the termination issues caused by tables.We model this database as a table, because it is easy to understand and our model hasno termination problem. In practice, the database schema may or may not actuallybe defined as the one in our model; but if we find attacks, those attacks do not exploitflaws in registration or key distribution.

Adding the IMSI to the authentication data response message: In ourmodel, the IMSI is included in the authentication data response message, which is notspecified in the standard (but might well be present in an implementation). Withoutit, ProVerif finds a candidate derivation from which a trace cannot be automaticallyreconstructed. We manually analyze the derivation and find that it is a false attack,which arises due to conservative approximations (Section 2.4.3). The authenticationdata response message is sent to the SN on the private channel after the HN generatesthe authentication vectors. Due to the approximation, ProVerif finds the derivationwhere this message is sent again later. In the false attack, the authentication dataresponse message for one IMSI may be sent to the SN in response to a request withanother IMSI. To rule out such false attacks, the IMSI is added to the authenticationdata response message to identify the responses.

Adding a data message to specify the secrecy of the data traffic: Atthe end of the AKA, the SN informs the MS of its choice of encryption and startscommunication, which may or may not be encrypted due to the choice of the SN. Wewant to check the secrecy of the data traffic when encryption is enabled. To checkthis secrecy property, a data message is included at the end of the model, even thoughit is not part of the AKA per se.

Adding private free names to test the secrecy of session keys: Thestandard secrecy queries of ProVerif can only check the secrecy of private free names.To test the secrecy of session keys, we use the general ProVerif technique for testing thesecrecy of bound variables: encrypting some private free names with the session keysand sending the encrypted messages over a public channel and testing the secrecy ofthose free names. Since the attacker can gain the encrypted message by eavesdroppingon the public channel, the secrecy of the free names implies the secrecy of the sessionkeys.

Abstracting algorithms and algorithm identifiers in key derivationfunctions: Since perfect cryptography is assumed in the Dolev-Yao attacker model,and we only model whether encryption is enabled or not, it does not matter whichalgorithm is chosen. Therefore, the algorithms and the algorithm identifiers are ab-stracted from key derivation functions.

28

Modeling the MS to engage only one session As mentioned previously,the IMSI is represented as a fresh value. For each execution explored by ProVerif,the MS gets a fresh IMSI, i.e. the MS is modeled as it only engages one session. Tomodel than an MS can engage in multiple authentications, we made a model thatapplies the replication operator to the part of the process that follows generating theIMSI and registering it with the long term key Ki (Section 2.4.2). The result of themodel in which the MS engages multiple sessions of AKA is the same as the resultof the model in which the MS only engages one session. This has been tried all themodels of all AKA scenarios and the results do not change. So we present the modelsin which the MS only engages one session.

3.2.2 GSM Model

In this section, we discuss the GSM model along with the diagram annotated ac-cord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S1_GSM_I-IV.pv.

Figure 3.3 augments the protocol diagram of Figure 3.2, as a guide to ourmodel. We abstract from the details of the SN, which consists of the BS and theMSC. In the model, we use one process to represent the SN. Labels, like cap ms andcap sn for the first message, are the names of the relevant variables in the processes thatmodel protocol roles. Besides variable names, the other augmentation is the additionof events (the dashed boxes). As described in Section 2.2.2, these are instrumentationused in order to specify authenticity properties as correspondence assertions. Suchproperties take the form “if event E happens then event F must have happenedpreviously”. For example, whenever the SN decides to proceed with communication,using a particular Kc, because it successfully verified the response to a challenge, thenthat MS must indeed have sent the response and computed Kc for itself. We specifythis by putting events begSN and endSN in block GSM III. We include events begMS

and endMS to specify authentication of the SN to the MS. Recall from Section 3.1,this property is not expected to hold in GSM.

In the events used to specify the authentication of the MS to the SN, we choosethe identity of the MS (IMSI ) and the session key (Kc) as the parameters. Because Kc

is derived from the permanent key Ki and the random number RAND , the two eventsagree on Kc implies that they agree on RAND . Since the response is generated fromthe Ki and the RAND , agreement on Kc also implies the agreement on the response.

The event begSN is put immediately before sending the response to the SN.It cannot be put earlier, because the parameters of the events are not present untilthis point. It cannot be put later either, otherwise, there would be executions inwhich endSN is executed prior to begSN, due to relative timing. This would violate thecorresponding property but would not indicate an actual protocol flaw. The eventendSN is put immediately after receiving the response from the MS. It cannot be putearlier, otherwise, we cannot capture the stage where the SN has received the response

29

MS HN

5. RAND

6. RES

3. IMSI

4. IMSI, RAND, XRES, KC

2. IMSI

1. CAP

7. cap_sn

SN

res__ms = a3(Ki, rand_ms), kc_ms = a8(Ki, rand_ms)

Verify res_sn = xres_sn

Decide whether to use encryption

Generate rand_hn xres_hn = a3(Ki, rand_hn), kc_hn = a8(Ki, rand_hn)

event endSN(imsi_hn_sn, kc_sn)

event begSN(imsi_ms,kc_ms)

event begMS(imsi_hn_sn, kc_sn)

event endMS(imsi_ms, kc_ms)

cap_ms cap_sn

imsi_ms imsi_sn

imsi_sn imsi_hn

imsi_hn rand_hn xres_hn kc_hn

imsi_hn_sn rand_sn xres_sn kc_sn

rand_sn rand_ms

res_ms res_sn

cap_sn enableEnc_ms

9. payload, if no encryption {payload}_kc_sn, otherwise

Decrypt message if enableEnc_ms is true

if cap_sn is false event disableEnc

msg_ms

8. CMComplete

GSM

I G

SM II

GSM

III G

SM IV

Figure 3.3: GSM diagram annotated in accord with our model. Compared to Fig-ure 3.2, our model omits TMSI/ID Request (messages numbered 2 and 3 in Fig-ure 3.2), abstracts from the details of the SN, and adds a first message of data traffic

and authenticated the MS. The end event could be placed later, which means thatthe SN has reached the point where the response is verified earlier. However, puttingthe end event at the exact point where the response is verified is natural and providesbetter understanding of what the correspondence assertion captures.

Ideally, we decompose a protocol into blocks that have an identifiable purpose,and sometimes this purpose can be formalized by events within the block.

The MS, SN, and HN are modeled as processes that send and receive messagesover two shared channels. The MS and the SN communicate over the public channel,while the SN and the HN securely communicate over the private channel.

(∗ Pub l i c channe l between the MS and the SN ∗)f r ee pubChannel : channel .(∗ Secure channe l between the SN and the HN ∗)f r ee s e cu r eChanne l : channel [ pr i va te ] .

Besides the built-in types channel, bitstring , and bool, we declare additional types.

30

type key . (∗ Permanent key ∗)type i d e n t . (∗ I d e n t i t y o f MS ∗)type nonce . (∗ Random number ∗)type msgHdr . (∗ Constant message heade r ∗)type r e s p . (∗ Response ∗)type s e s sKey . (∗ Se s s i o n key ∗)

We also define a number of (distinct) constant values as message headers to identifymessages. The comments refer to message numbers in Figure 3.3.

const CAP: msgHdr . (∗ Header o f Msg 1 ∗)const ID : msgHdr . (∗ Header o f Msg 2 ∗)const AV REQ : msgHdr . (∗ Header o f Msg 3 ∗)const AV: msgHdr . (∗ Header o f Msg 4 ∗)const CHALLENGE: msgHdr . (∗ Header o f Msg 5 ∗)const RES : msgHdr . (∗ Header o f Msg 6 ∗)const CMC: msgHdr . (∗ Header o f Msg 7 ∗)const CMComplete : msgHdr . (∗ Header o f Msg 8 ∗)

In ProVerif, the cryptographic functions are declared as constructors and their alge-braic properties are defined by rewrite rules (see Section 2.4.2). In our model, thefollowing constructors and destructors are defined.

1 fun a3 ( nonce , key ) : r e s p .2 fun a8 ( nonce , key ) : s e s sKey .3 fun s e n c r y p t ( b i t s t r i ng , s e s sKey ) : b i t s t r i n g .4 reduc f o r a l l m: b i t s t r i ng , k : s e s sKey ;5 s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.6 reduc e n cC a p a b i l i t y ( ) = t r u e ; e n cC a p a b i l i t y ( ) = f a l s e .

The destructor in lines 4–5 says how decryption inverts encryption: any party, in-cluding the attacker, can compute sdecrypt(X,k) if he/she has obtained X and k, som can be obtained if X is sencrypt(m,k). In the symbolic model of cryptography, theattacker can learn nothing from sencrypt(m,k) if he/she does not have k. Functions,and rewriting via equations, are available to the attacker unless declared private. Asdescribed in Section 3.2.1, a public function with a private destructor could be usedto model key distributions. However, in this work, we choose to use table to modelthe key distribution. ProVerif allows non-deterministic rewrite rules, e.g., in line 6there are two equations for encCapability so that the MS process can choose whetherits capability includes encryption or not (see Section 3.2.1).

We declare the events used in the correspondence assertions as follows:

event begSN ( iden t , s e s sKey ) .event endSN( iden t , s e s sKey ) .event begMS( iden t , s e s sKey ) .event endMS( iden t , s e s sKey ) .

Our model uses a private table which associates keys with identities to modelthe registration of the MS.

(∗ The key t a b l e c o n s i s t s o f p a i r s ( i d en t , key ) sha r ed between

31

the MS and the HN. Table i s not a c c e s s i b l e by the a t t a c k e r ∗)tab le keys ( i d en t , key ) .

The dynamic part of the model is declared as follows:

process( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

The main process forks multiple sessions for each kind of process (indicated by thereplication symbol, !).

The MS is represented by the following process. The comments refer to messagenumbers in Figure 3.3.

1 l e t processMS =2 (∗ R e g i s t r a t i o n and se tup ∗)3 new ims i ms : i d e n t ;4 new k i : key ;5 i n s e r t keys ( ims i ms , k i ) ; (∗ pre−sha r ed i d e n t i t y and key ∗)6 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n (∗ choose c a p a b i l i t y ∗)7 (∗ The p r o t o c o l ∗)8 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)9 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)

10 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)11 (∗ Compute r e s pon s e ∗)12 l e t r e s ms : r e s p = a3 ( rand ms , k i ) i n13 (∗ Compute e n c r y p t i o n key ∗)14 l e t kc ms : s e s sKey = a8 ( rand ms , k i ) i n15 (∗ MS i s a u t h e n t i c a t i n g i t s e l f to SN ∗)16 event begSN ( ims i ms , kc ms ) ;17 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)18 i n ( pubChannel , (=CMC, enab leEnc ms : bool ) ) ; (∗ [Msg 7 ] ∗)19 event endMS( ims i ms , kc ms ) ;20 out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)21 i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)22 out ( pubChannel , s e n c r y p t ( sec r e tKc , kc ms ) ) ;23 i f enab leEnc ms = t r u e then24 l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n 0 .

An instance of processMS models the initial activation of an MS followed by a singleattempt at authentication. In lines 3–4, the MS generates a fresh IMSI and a freshKi ; in line 5 these are inserted in the table. In our models, only the HN reads thetable and only the MS writes it.

In line 6, the MS non-deterministically decides on its encryption capability. Inlines 8–9 the MS sends its capability and IMSI. The message in line 8 is the headerliteral CAP paired with boolean cap ms; the one in line 9 pairs the ID header with a valueof type ident. In line 10, the process waits until a message is available on the publicchannel. The message must match the designated format or the process terminatesprematurely. The syntax expresses that the message should have two parts, the firstbeing the literal value CHALLENGE, the second being of type nonce. If the message

32

matches, the nonce gets assigned to local variable rand ms, the scope of which is therest of the process.

In lines 12 and 14, cryptographic functions are computed and their values areassigned to variables res ms and kc ms. The events in lines 16 and 19 instrument theprocess to facilitate specification of security properties. Event begSN records the IMSIand Kc, to express that, if the response is successfully verified by the SN, then theSN will consider that it has successfully authenticated the MS with this IMSI andestablished a shared key Kc with it. To specify the key secrecy, we use the techniquediscussed in Section 3.2.1. We declare a secret

f r ee s e c r e tKc : b i t s t r i n g [ pr i va te ] . (∗ a s e c r e t to be p r o t e c t e d by Kc∗)

and encrypt it under Kc, and send the ciphertext out over the public channel (line21). The last lines of the MS process receive a message with payload, and decrypt itif encryption was chosen. The process 0 halts immediately.

The process representing the SN is defined as follows. The comments refer tomessage numbers in Figure 3.3.

1 l e t processSN =2 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)3 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)4 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)5 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,6 x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)7 out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)8 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)9 i f r e s s n = x r e s s n then (∗ Check r e s pon s e ∗)

10 event endSN( ims i hn sn , k c sn ) ;11 event begMS( ims i hn sn , k c sn ) ;12 out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)13 i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)14 i f cap sn = f a l s e then15 event d i s a b l eEn c ;16 out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)17 e l s e18 out ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) . (∗ [Msg 9 ] ∗)

To be able to specify secrecy of data traffic following authentication, the model in-cludes message payload sent in line 16 or 18 and declared as

f r ee pay load : b i t s t r i n g [ pr i va te ] .

(One might expect to generate this value using new payload inside the process code; wedo not, because we need to refer to payload in specifications.) The SN encrypts payload,or not, based on the choice received in line 2. If encryption is not chosen, an eventin line 15 records that fact for use in specifications.

The process representing the HN is defined as follows.

1 l e t processHN =2 i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)

33

3 new rand hn : nonce ; (∗ Genera te a f r e s h random number ∗)4 get keys (= ims i hn , k i h n ) i n (∗ attempt to l ook up key ∗)5 l e t x r e s h n : r e s p = a3 ( rand hn , k i h n ) i n6 l e t kc hn : s e s sKey = a8 ( rand hn , k i h n ) i n7 (∗ Send out a u t h e n t i c a t i o n v e c t o r [Msg 4 ] ∗)8 out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn , kc hn ) ) .

In line 4 it uses the get operation on the private table of IMSI/Ki pairs for registeredMSs. The process blocks at this point if there is no pair for the value received intovariable imsi hn.

3.3 Security Property Specifications and Findings

This section presents the specifications of secrecy and authentication properties. Wethen present the analysis result which includes the proved security properties and theattacks found by ProVerif on the failed properties.

We specify the properties as follows:

• Key Secrecy (secrecy of Ki and Kc)1 not attacker (new k i ) .2 query attacker ( s e c r e tKc ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Authentication of the MS to the SNquery i d : i d en t , k : s e s sKey ; event ( endSN( id , k ) ) event ( begSN ( id , k ) ) .

• Payload Secrecyquery attacker ( pay load ) .

• Authentication of the SN to the MSquery i d : i d en t , k : s e s sKey ; event (endMS( id , k ) ) event (begMS( id , k ) ) .

Line 1 of the key secrecy specification is a secrecy assumption which is used tospeed up the resolution process of ProVerif. It is assumed that the key is unknownto the attacker. At the end of the solving process, ProVerif checks that the key isindeed not known by the attacker. If the attacker learns the key, the proof fails withan error message.

Line 2 specifies that the attacker does not obtain the secret secretKc. The built-in predicate attacker expresses the standard Dolev-Yao notion of “attacker knowledge”[50]: it says of a term that it can be obtained by the attacker from values that havebeen sent over public channels, by applying functions and rewriting by the specifiedequations (e.g., it can decrypt if it obtains the right key). The query of key secrecyimplies that Kc remains secret since otherwise the attacker would obtain secretKc. Theproperty is unconditional: the key remains secret regardless of whether encryption ischosen. Furthermore, because Kc is computed as a function of RAND , which is sentin the clear, and Ki , secrecy of Kc implies secrecy of Ki . (Recall that Ki is a freshvalue, unguessable in the Dolev-Yao model.)

34

Table 3.1: Analysis result of GSM modelKey

SecrecyConditional

Payload SecrecyAuthentication ofthe MS to the SN

PayloadSecrecy

Authentication ofthe SN to the MS

Proved Proved Proved Failed Failed

The conditional payload secrecy property expresses a requirement: if the at-tacker obtains the secret payload then the event disableEnc must have previously takenplace in the SN.

The authentication properties are specified as correspondence assertions (seeSection 2.2.2). The property “Authentication of the MS to the SN” says that when-ever the event endSN occurs with some arguments id and k , there must have been aprior occurrence of event begSN with the same arguments. Note that the former eventoccurs in line 10 in the process of the SN; it happens only following the successfulcheck of the expected response from the MS. This property captures authenticationof the MS to the SN, because event begSN only occurs at one place, line 13 of the MSprocess. This query says that if the SN believes it has established a session key Kc

associated with an MS using this particular IMSI, for which the HN has provided achallenge and expected response, then indeed there is an MS that reached that stageof its protocol role, for that IMSI and Kc. Note that the IMSI and Kc are parametersof the events. On the other hand, the protocol is clearly not designed to provideauthenticity of the MS capability, so that is not included as an event parameter. Theevent endSN occurs only following successful verification in the SN, as that is the stepthat is intended to establish authentication. The event begSN is placed in the MSprocess just before it sends the response, i.e., after it has computed the Kc to whichthe event refers. The event should not be placed later in the MS process, becausesuccessful verification by the SN does not give the SN evidence that the MS hasprogressed any further.

The property of payload secrecy says that payload remains secret. This is not arequirement for GSM; the attacker can certainly obtain payload, e.g., if the MS is notcapable of encryption. Nonetheless, we check the property in order to gain confidencein our model, and ProVerif indeed finds a trace which we present later.

Table 3.1 shows the analysis result of the above properties. The properties areproved means that there is no attacks against the properties at the Dolev-Yao (seeSection 2.2.1) abstract level. ProVerif finds attacks on the failed properties.

The protocol is not intended to authenticate the SN to the MS . However, asa sanity check on our model and for comparison with other AKAs, we specify theauthentication property. ProVerif does find a trace that violates the property:

1 new ims i ms c r e a t i n g ims i ms 12 new k i c r e a t i n g k i 23 i n s e r t keys ( ims i ms 1 , k i 2 )4 out ( pubChannel , (CAP, t r u e ) )5 out ( pubChannel , ( ID , ims i ms 1 ) )

35

6 i n ( pubChannel , (CHALLENGE, a 3 ) )7 event ( begSN ( ims i ms 1 , a8 ( a 3 , k i 2 ) ) )8 out ( pubChannel , (RES , a3 ( a 3 , k i 2 ) ) )9 i n ( pubChannel , (CMC, a 4 ) )

10 event (endMS( ims i ms 1 , a8 ( a 3 , k i 2 ) ) )

In this trace, imsi ms 1 and ki 2 are the fresh symbolic values.1 The MS sends outits encryption capability and identification in lines 4–5. The challenge and CMCmessages received in line 6 and line 9 are generated and sent by the attacker. Theattacker plays as a false BS and feeds the MS with arbitrary challenge and encryptionoption. This violates the correspondence assertion by executing the event endMS

without previously executing the begMS. In this scenario, the attacker cannot providereal service.

A more interesting man-in-the-middle scenario is the one ProVerif finds inviolation of the payload secrecy:2

1 new ims i ms c r e a t i n g ims i ms 12 new k i c r e a t i n g k i 33 i n s e r t keys ( ims i ms 1 , k i 3 )4 out ( pubChannel , (CAP, t r u e ) )5 out ( pubChannel , ( ID , ims i ms 1 ) )6 i n ( pubChannel , (CAP, f a l s e ) )7 i n ( pubChannel , ( ID , ims i ms 1 ) )8 out ( s ecu reChanne l , (AV REQ , ims i ms 1 ) )9 new rand hn c r e a t i n g rand hn 2

10 get keys ( ims i ms 1 , k i 3 )11 out ( s ecu reChanne l , (AV, ims i ms 1 , rand hn 2 ,12 a3 ( rand hn 2 , k i 3 ) , a8 ( rand hn 2 , k i 3 ) ) )13 out ( pubChannel , (CHALLENGE, rand hn 2 ) )14 i n ( pubChannel , (CHALLENGE, rand hn 2 ) )15 event ( begSN ( ims i ms 1 , a8 ( rand hn 2 , k i 3 ) ) )16 out ( pubChannel , (RES , a3 ( rand hn 2 , k i 3 ) ) )17 i n ( pubChannel , (RES , a3 ( rand hn 2 , k i 3 ) ) )18 event ( endSN( ims i ms 1 , a8 ( rand hn 2 , k i 3 ) ) )19 event (begMS( ims i ms 1 , a8 ( rand hn 2 , k i 3 ) ) )20 out ( pubChannel , (CMC, f a l s e ) )21 event ( d i s a b l eEn c )22 out ( pubChannel , (MSG, pay load ) )

The MS sends out its encryption capability and identification in lines 4–5 of thetrace. The attacker intercepts the capability message and changes it to no-encryption,so the SN receives the modified capability in line 6. In lines 9–11, the HN gener-ates the authentication vector and sends it to the SN. Lines 13–17 are the one-waychallenge-response authentication between the SN and the MS. Since the SN receives

1We modified the ProVerif output to use smaller numbers, for readability.2This trace is found by ProVerif when processSN is not replicated. Otherwise, ProVerif only finds

a candidate derivation, from which we reconstruct the same attack by hand (cf. [28]). A processunder replication engages in an unbounded number of sessions.

36

no-encryption from the attacker, it decides not to use encryption and sends the deci-sion to the MS in line 19. This is the same attack scenario as in the false base stationattack [53].

37

Chapter 4Modeling and Analysis of UMTS

This chapter provides an overview of the UMTS AKA and its security goals (Sec-tion 4.1) and presents our model of the protocol (Section 4.2), the specifications ofsecurity properties, and our findings (Section 4.3). We assume readers are familiarwith GSM as presented in Chapter 3. So we go quickly and focus on what’s new anddifferent. In Chapter 6, we revisit authentication properties of UMTS in contrast toGSM and LTE.

4.1 Overview of UMTS AKA

This section describes the UMTS AKA and informally specifies the security goals.Figure 4.1 shows the architecture of a UMTS network [94, 76]. The figure is

borrowed from [76]. As in GSM, UMTS entities are grouped into three domains:the MS, the SN, and the HN. The Universal Subscriber Identity Module (USIM ) issimilar in functionality to the SIM of the GSM network. The Universal TerrestrialRadio Access Network (UTRAN ) is the access network for UMTS networks. TheUTRAN is subdivided into individual Radio Network Subsystems (RNS), whichconsist of Radio Network Controllers (RNC ) and NodeBs. Like the BSC of theGSM network, the RNC is the controlling unit of the UTRAN. Following the GSMmodel, a single controller (RNC) may possibly control a large number of base stations,which are referred to as NodeBs.

Figure 4.2 shows the UMTS AKA. The workings to facilitate the connecting ofan MS to a BS of an SN in UMTS follows the same principles as those in GSM. Themain differences between the workings in GSM and UMTS are that those in UMTSare intended to provide mutual authentication of the MS and the SN and they alsosupport integrity protection and freshness guarantees. Specifically, in UMTS II, uponreceiving an authentication request from the SN (Message 5 in Figure 4.2), the HNcomputes an authentication vector that is more extensive than the one issued in GSM.In addition to determining a challenge response pair RAND and XRES as in GSM,in UMTS the HN also computes a Message Authentication Code (MAC ), a CipherKey (CK ), an Integrity Protection Key (IK ), and an Anonymity Key (AK ). At thecore of all computations again is the random nonce RAND as well as the pre-sharedkey Ki . In addition, the UMTS specification includes a so-called Sequence Number(SQN ) as well as an Authentication Management Field (AMF ).

In UMTS III, upon receiving the authentication vector (Message 6), the SNinitiates the challenge response exchange with the MS as was the case in GSM. Unlikein GSM, the MS receives the Authentication Token (AUTN ) as part of Message 7which allows the MS to determine whether or not this is a fresh authentication chal-

38

MS

ME + USIM

SN VLR

UTRAN

MSC

NodeB NodeB

RNC

HN MSC

HLR

AuC

MS: Mobile Station Node B: Base Transceiver Station VLR: Visitor Location Register ME: Mobile Equipment MSC: Mobile Switching Center RNC: Radio Network Controller SN: Serving Network HLR: Home Location Register AuC: Authentication Center HN: Home Network USIM: Universal Subscriber Identity Module UTRAN: Universal Terrestrial Radio Access Network

Figure 4.1: UMTS architecture [94, 76]

lenge. Upon receiving the response RES from the MS (Message 8), the SN checkswhether or not it matches XRES . If so, then the MS has successfully authenticatedto the SN.

In UMTS IV, the SN then proceeds to deciding on the encryption algorithm.In GSM, the SN only informs the MS of its choice of encryption algorithm to be usedto protect the subsequent communication. In contrast, in UMTS, the SN includes theCAP (which include both the MS’s encryption and integrity protection capabilities)in its message to the MS as it received them as part of Message 1. Message 10 isintegrity protected. Based on Message 10, the MS can verify that the SN received theCAP as the MS sent them. In addition, the integrity protecting as part of Message 10allows the SN to authenticate itself to the MS.

The security of UMTS networks is based and built on the security of GSMnetworks. However, UMTS provides new and enhanced security features. UMTSprovides mutual authentication between the MS and the SN. The SN has correctlyauthenticated the MS if RES matches XRES . In turn, the authentication of theSN by the MS requires two conditions: First, the AUTN (sent in Message 7) mustbe fresh—preventing the replay of authentication data—and second, there must bea correctly integrity-protected Message 10. The mandatory integrity protection inUMTS prevents the insertion and modification of messages between the MS and theBS. This integrity protection enables the MS to verify the instruction from the SN(Message 10) and also provides protection against bidding-down attacks [53] wherean attacker forces to not use any protection on the traffic between the MS and the

39

MS MSC HN

7. RAND, AUTN

8. RES

5. IMSI

6. RAND, XRES, CK, IK, AUTN

4. IMSI

1. CAP

10. ALG, CAP, FRESH, MAC-I

XMAC-I = f9((ALG, CAP, FRESH), IK) Verify MAC-I = XMAC-I, Verify CAP

Decide algorithms ALG, Generate FRESH MAC-I = f9((ALG, CAP, FRESH), IK)

Generate RAND & SQN MAC = f1(Ki, AMF, SQN, RAND)

XRES = f2(Ki, RAND), CK = f3(Ki, RAND) IK = f4(Ki, RAND), AK = f5(Ki, RAND)

AUTN = SQNAK || AMF || MAC

Verify RES = XRES

2. TMSI

3. User ID Request

RES = f2(Ki, RAND), CK = f3(Ki, RAND) IK = f4(Ki, RAND), AK = f5(Ki, RAND)

SQN = 1st(AUTN) AK XMAC = f1(Ki, 2nd(AUTN), SQN, RAND)

Verify 3rd(AUTN) = XMAC Verify SQN is in correct range

UM

TS

I U

MT

S II

UM

TS

III U

MT

S IV

BS

11. SMComplete

9. CK, IK

Figure 4.2: UMTS AKA [94, 76]

SN.The following security properties are expected:

• Key SecrecyThe pre-shared key Ki , the cipher key CK , and the integrity key IK should beunknown to the attacker.

• Conditional Payload SecrecyThe data traffic should remain unknown to the attacker if the SN chooses to useencryption.

• Mutual Authentication between the MS and the SNThe UMTS AKA is designed to provide for the mutual authentication between theMS and the SN.

40

It is clear that UMTS does not preserve the payload secrecy. For example, if the SNdecides not to use encryption, the attacker can learn the payload.

4.2 Modeling the UMTS AKA

In this section we provide an overview of the main design choices and design rationalesin modeling UMTS. We also present detailed explanation of the ProVerif model.

4.2.1 Design Choices

The UMTS model reuses the design choices used in the GSM model. In this section,we describe the additional design choices used in the UMTS model.

In UMTS, the authentication vectors generated by the HN include sequencenumber SQNs to help ensure freshness. Both the MS and the HN keep track oftheir own counters of SQN respectively. In particular, the HN keeps track of anindividual counter SQN for each user. The MS stores the highest sequence numberit has accepted in the USIM. When the MS receives the challenge message, it verifiesthe received SQN is in the correct range.

If we model SQNs, they could be represented by integers.1 We tried modelwithout SQN and we could prove the expected properties. So we omit the SQN forsimplicity. Moreover, in case of finding an attack, we could have changed the modelto include the SQN in the authentication vector to check whether this affected theresults.

In the UMTS standard, each authentication vector also includes an AMF toindicate whether this authentication vector is used in Evolved Packet System (EPS)context or non-EPS (GSM or UMTS) context. This could be modeled by adding aboolean variable which indicates whether the EPS context is in use. AMF is alsoused to support multiple AKA algorithms for disaster recovery purpose, to changeSQN verification parameters and to set the lifetime of keys. Since we model in UMTScontext, which is non-EPS context, and do not model the feature of SQN verificationand key lifetime, we also do not include the AMF in our model.

4.2.2 UMTS Model

In this section, we discuss the UMTS model along with the diagram annotated ac-cord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S2_UMTS_I-IV.pv.

In Figure 4.3 we augment the protocol diagram of Figure 4.2 with details ofthe ProVerif model. Figure 4.3 also shows the locations of the events which are usedin correspondence assertions to specify authentication properties. As with GSM, we

1As described in [28], the integers can be modeled as: zero is 0; the successor of an integer ican be represented by a constructor succ( i ); and two integers ( i , j) is compared by a predicategeq(i , j ).

41

MS SN HN

5. RAND, AUTN

6. RES

3. IMSI

4. IMSI, RAND, XRES, CK, IK, AUTN

2. IMSI

1. CAP

7. cap_sn, CAP, FRESH, MAC-I

Compute res_ms, ck_ms, ik_ms, xmac_ms Verify mac_ms=xmac_ms

Generate rand_hn, Compute mac_hn, xres_hn, ck_hn, ik_hn and autn_hn

event begMS(imsi_hn_sn, ck_sn,ik_sn, cap_sn)

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_hn_sn, ck_sn, ik_sn)

event endMS(imsi_ms, ck_ms, ik_ms, cap_ms)

Verify res_sn = xres_sn

9. payload, FRESH, MAC, if no encryption {payload}_ck_sn, FRESH, MAC, otherwise

VerifyMAC, decrypt message if alg_ms supports encryption

if cap_sn is false event disableEnc

Decide whether to use encryption Generate fresh_sn, Compute mac_i_sn

8. SMComplete, integrity protected

UM

TS I

UM

TS II

UM

TS III

UM

TS IV

Verify CAP, MAC-I

Figure 4.3: UMTS AKA (Figure 4.2) annotated in accord with our model

omit the TMSI and ID Request messages. As mentioned in Section 4.2.1, we alsoabstract from the SQN and AMF, which are included in the standard.

In addition to the types defined in the GSM model (Section 3.2.2), we alsodefine the types for UMTS session keys and message MACs.

type c i phe rKey .type i n t egKey .type msgMac .

The following constructors and destructors are defined in our model:

fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i ng , i n t egKey ) : msgMac .fun s e n c r y p t ( b i t s t r i ng , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : c i phe rKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.fun s e n c r y p t I n t e g ( b i t s t r i ng , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : i n t egKey ;

42

s d e c r y p t I n t e g ( s e n c r y p t I n t e g (m, k ) , k ) = m.

UMTS authentication establishes the cipher key CK and the integrity key IK , so theseare included in the parameters of the events. The protocol also ensures authenticity ofthe MS capability, which is also included as an event parameter in the correspondenceassertion expressing the authentication of the SN to the MS. The events are declaredas:

event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , c ipherKey , integKey , bool ) .event endMS( iden t , c ipherKey , integKey , bool ) .

The process of the MS is as follows. The comments refer to message numbersin Figure 4.3.

1 l e t processMS =2 (∗ r e g i s t r a t i o n and se tup ∗)3 new ims i ms : i d e n t ;4 new k i : key ;5 i n s e r t keys ( ims i ms , k i ) ;6 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n (∗ choose c a p a b i l i t y ∗)7 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)8 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)9 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

10 mac ms : mac ) ) ; (∗ [Msg 5 ] ∗)11 i f f 1 ( k i , rand ms ) = mac ms then12 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n13 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n14 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n15 event begSN ( ims i ms , ck ms , i k ms ) ;16 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)17 i n ( pubChannel , (=SMC, enab leEnc ms : bool , =cap ms ,18 f r e s h ms : nonce , =f9 ( ( enableEnc ms , cap ms , f r e s h ms ) ,19 i k ms ) ) ) ; (∗ [Msg 7 ] ∗)20 event endMS( ims i ms , ck ms , ik ms , cap ms ) ;21 out ( pubChannel , ( SMComplete , f 9 ( smcompleteMsg , i k ms ) ) ) ;22 (∗ [Msg 8 ] ∗)23 i n ( pubChannel , (=MSG, msg : b i t s t r i ng , f r e sh msg ms : nonce ,24 =f9 ( (msg , f r e sh msg ms ) , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)25 out ( pubChannel , s e n c r y p t ( sec r e tCk , ck ms ) ) ;26 out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;27 i f enab leEnc ms = t r u e then28 l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , ck ms ) i n 0 .

The registration process of the MS device is modeled in lines 2–5. The MS generatesthe identification (IMSI) and the pre-shared key (Ki) and inserts them into the table.As in the GSM model, only the HN process reads from the table and only the MSprocess writes to it. Upon receiving the integrity-protected challenge in lines 9–10,the MS first verifies the MAC (line 11), and then computes the responses and keys(lines 12–14). In lines 17–19 it checks that Message 7 has the two expected values,

43

and in lines 23–24 it checks for the expected value in Message 10. As in GSM, tospecify the secrecy of CK and IK , we use the technique discussed in Section 3.2.1.We declare secret values

f r ee s e c r e tCk : b i t s t r i n g [ pr i va te ] .f r ee s e c r e t I k : b i t s t r i n g [ pr i va te ] .

and encrypt it under CK and under IK respectively, and send the ciphertexts outover the public channel (lines 25–26 in the process of the MS).

The process of the SN is defined as follows. The comments refer to messagenumbers in Figure 4.3.

1 l e t processSN =2 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)3 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)4 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)5 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,6 x r e s s n : re sp , c k sn : c ipherKey , i k s n : integKey ,7 mac sn : mac ) ) ; (∗ [Msg 4 ] ∗)8 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)9 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)

10 i f r e s s n = x r e s s n then11 event endSN( ims i hn sn , ck sn , i k s n ) ;12 new f r e s h s n : nonce ;13 event begMS( ims i hn sn , ck sn , i k s n , cap sn ) ;14 out ( pubChannel , (SMC, cap sn , cap sn , f r e s h s n ,15 f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 7 ] ∗)16 i n ( pubChannel , (=SMComplete , =f9 ( smcompleteMsg , i k s n ) ) ) ;17 (∗ [Msg 8 ] ∗)18 new f r e s h msg s n : nonce ;19 i f cap sn = f a l s e then20 event d i s a b l eEn c ;21 out ( pubChannel , (MSG, pay load , f r e s h msg sn ,22 f 9 ( ( pay load , f r e s h msg s n ) , i k s n ) ) ) (∗ [Msg 9 ] ∗)23 e l s e24 out ( pubChannel , (MSG, s e n c r y p t ( pay load , ck sn ) , f r e s h msg sn ,25 f 9 ( ( s e n c r y p t ( pay load , ck sn ) , f r e s h msg s n ) , i k s n ) ) ) .26 (∗ [Msg 9 ] ∗)

In lines 5–7, the SN receives the authentication vector from the HN on the securechannel. After checking that the response received from the MS matches the expectedresponse in line 9, the SN sends out the integrity-protected SMC message (in lines 14–15), and includes the capabilities of the MS (received at line 2) in the SMC message.

The process of the HN is defined as follows.

1 l e t processHN =2 i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)3 new rand hn : nonce ;4 get keys (= ims i hn , k i h n ) i n5 l e t mac hn : mac = f1 ( k i hn , rand hn ) i n6 l e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i n

44

7 l e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i n8 l e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i n9 out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn ,

10 ck hn , i k hn , mac hn ) ) . (∗ [Msg 4 ] ∗)

As in the GSM model, the HN gets the pre-shared key in line 4 and sends out theauthentication vector on the secure channel in lines 9–10, which includes the integrityprotection computed in line 5.

4.3 Security Property Specifications and Findings

This section presents the specifications of secrecy and authentication properties. Wethen present the analysis result of the security properties.

The secrecy and authentication properties are specified similarly to those inthe GSM model.

• Key Secrecy (secrecy of Ki, CK, and IK)1 not attacker (new k i ) .2 query attacker ( s e c r e tCk ) .3 query attacker ( s e c r e t I k ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Mutual Authentication between the MS and the SN1 query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;2 event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .3 query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : bool ;4 event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

• Payload Secrecyquery attacker ( pay load ) .

As in GSM, the secrecy assumption in line 1 of the key secrecy stipulates thatthe pre-shared key Ki cannot be learned by the attacker. The query of conditionalpayload secrecy specifies that if the SN has enabled encryption, then the data trafficremains secret (in contrast with the property specified in “Payload Secrecy”, thisproperty is conditional).

The payload secrecy, which specifies the secrecy of data traffic, fails as expected:as in GSM, the MS can choose no-encryption, and regardless of the choice the attackercan modify the capability message to claim the MS has no encryption. However, if theMS chooses the capability of encryption and the attacker modifies that, this will bedetected by the MS (in line 13 in the process of the MS) which will stop responding.

Table 4.1 shows the analysis result of the above properties. Recall that weomit the SQN when modeling the protocol, the mutual authentication propertiesare proved by ProVerif. The purpose of using SQN is to provide fresh authenticationvector, so that an attack in which the attacker records earlier authentication challengeand re-uses it to establish session keys is prevented. Since we model a single roundof the AKA, the result shows that SQN is not needed in single round authentication.

45

Table 4.1: Analysis result of UMTS modelKey

SecrecyConditional

Payload SecrecyAuthentication ofthe MS to the SN

PayloadSecrecy

Authentication ofthe SN to the MS

Proved Proved Proved Failed Proved

46

Chapter 5Modeling and Analysis of LTE

This chapter provides an overview of the LTE AKA and its security goals (Section 5.1)and presents our model of the protocol (Section 5.2), the specifications of securityproperties, and our findings (Section 5.3). Like Chapter 4, we go quickly and focuson what’s new and different from GSM and UMTS. We revisit the authenticationproperties of LTE in Chapter 6 where we will compare them with the ones in GSMand UMTS.

5.1 Overview of LTE AKA

This section describes the LTE AKA and informally specifies the security goals. Incontrast to GSM and UMTS, LTE provides different key hierarchy. LTE also intro-duces the security context concept. In addition, LTE provides implicit authenticationof the serving network’s identity by binding the serving network identity with the keys.

Figure 5.1 shows the architecture of a LTE network [94, 52]. Entities aregrouped into three domains (the MS domain, the SN domain, and the HN domain),which function similarly to those in GSM and UMTS. Unlike the UTRAN (see UMTSarchitecture Figure 4.1), which has a star model (each RNC controls many BSs), thestructure of the Evolved Universal Terrestrial Radio Access Network (E-UTRAN )is quite simple. It is only composed of one network element: the evolved Node B(eNB), which directly connects to the Mobility Management Entity (MME). Thefeatures supported by the BS controller (BSS in GSM, RNC in UMTS) have beendistributed between the eNB and the MME. The MME is the main control elementfor the access network. It initiates the authentication, keeps track of the location ofthe MSs, retrieves the MSs’ subscription profile from the HN, and manages serviceconnectivity.

In contrast to UMTS security, LTE introduces an enhanced key derivation hier-archy that allows the distinguishing of protection mechanisms on Non Access Stratum(NAS) and Access Stratum (AS). The NAS traffic is the communication betweenthe MS and the MME. The AS traffic is the communication between the MS and theeNB. In addition, LTE defines a comprehensive security context framework, includingnative vs. mapped security contexts, current vs. non-current security contexts, andfull vs. partial contexts [8]. A security context typically consists of a set of securityparameters including cryptography keys and identifiers for respective cryptographicmechanisms. A native security context is established by a run of LTE AKA, while amapped security context is converted from another system during inter-system mo-bility 1. A current security context is the one which is activated most recently, while

1Security context has already existed before inter-system mobility, while interoperation scenario

47

MS

ME + USIM

SN VLR

E-UTRAN

MME

eNodeB

eNodeB

HN MME

HLR

AuC

MS: Mobile Station MME: Mobility Management Entity VLR: Visitor Location Register ME: Mobile Equipment HLR: Home Location Register AuC: Authentication Cente SN: Serving Network eNodeB: Base Transceiver Station (evolved NodeB) HN: Home Network USIM: Universal Subscriber Identity Module E-UTRAN: Evolved Universal Terrestrial Radio Access Network AS: Access Stratum NAS: Non-Access Stratum

AS

NAS

Figure 5.1: LTE architecture [94, 52]

a non-current one is not currently activated and exists simultaneously with the cur-rent one. A full security context contains the NAS keys and the identifiers of theNAS cipher and integrity algorithms, while a partial security context does not in-clude them, i.e., no successful NAS Security Mode Command (SMC ) procedure hasbeen run for a partial security context. A partial native security context is alwaysa non-current security context and it can be transformed into a full native securitycontext by executing the NAS SMC procedure.

The goal of the LTE AKA is to provide mutual authentication between the MSand a specific SN with a SN identifier and to establish a security context to protectthe communication between the MS and the SN. Figure 5.2 shows the authenticationscenario. The LTE AKA can be triggered by the initial network attach request,the Tracking Area Update (TAU ) request, or the service request [5]. When a NASsignalling connection exists, the network can initiate an AKA at any time [5]. Beforethe service request or the NAS signalling connection establishing, the attach requestmust have already been executed [5]. Therefore, the first block of the LTE AKAcan contain an attach request or a TAU request. If the AKA starts with an attachrequest, the first block (LTE I in Figure 5.2) contains the transmission of the identityand the security capabilities of the MS.

If instead of the initial network attach request, the AKA starts with a TAUrequest, in the first block (LTE I’, Figure 5.3), an additional nonce NONCEMS is sentto the MME. The nonce in the TAU request is only used when mapping an UMTS to

in this work is used to establish initial security context. Inter-system mobility could be idle modemobility or handover.

48

MS MME HN

7. RAND, AUTN, KSIASME

8. RES

5. IMSI, SNid, Network Type

6. RAND, AUTN, XRES, KASME

3. Identity Request

4. IMSI

1.CAP

2. GUTI

12. AS-Algs, AS-MAC

BS

AK = f5(Ki, RAND), SQN = 1st(AUTN)AK Verify SQN in correct range

XMAC = f1(Ki, 2nd(AUTN), SQN, RAND) Verify 3rd(AUTN) = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid, 1st(AUTN))

Verify RES = XRES

11. CAP, KeNB

Generate RAND & SQN MAC = f1(Ki, AMF, SQN, RAND)

XRES = f2(Ki, RAND), CK = f3(Ki, RAND) IK = f4(Ki, RAND), AK = f5(Ki, RAND)

AUTN=SQNAK || AMF || MAC KASME=KDF(CK, IK, SNid, SQNAK)

13. AS SMComplete Integrity protected

9. CAP, NAS-Algs, [NONCES], NAS-MAC

10. NAS SMComplete ciphered , integrity protected

LT

E IV

L

TE

V

LT

E I

LT

E II

LT

E III

KNASenc = KDF (KASME, NAS-enc-alg, Alg-ID) KNASint = KDF(KASME, NAS-int-alg, Alg-ID)

Decide NAS-Algs, NAS-MAC = EIA((CAP, Algs),KNASint)

KNASenc = KDF (KASME, NAS-enc-alg, Alg-ID) KNASint = KDF(KASME, NAS-int-alg, Alg-ID)

XNAS-MAC = EIA((CAP, Algs),KNASint) Verify XNAS-MAC = NAS-MAC

Start ciphering/deciphering and integrity protection

KeNB = KDF (KASME) KRRCenc = KDF (KeNB, RRC-enc-alg, Alg-ID) KRRCint = KDF(KeNB, RRC-int-alg, Alg-ID) KUPenc = KDF (KeNB, UP-enc-alg, Alg-ID)

Decide AS-Algs, AS-MAC = EIA(Algs, KRRCint)

KeNB = KDF (KASME) KRRCenc = KDF (KeNB, RRC-enc-alg, Alg-ID) KRRCint = KDF(KeNB, RRC-int-alg, Alg-ID) KUPenc = KDF (KeNB, UP-enc-alg, Alg-ID)

XAS-MAC = EIA(Algs, KRRCint) Verify XAS-MAC = AS-MAC

KeNB = KDF(KASME)

Verify integrity of message 10

Verify integrity of message 13

Figure 5.2: LTE AKA

an EPS security context [8]. However, since the MS does not know when the mappingwill happen, the nonce is always included in the TAU request message [52]. In LTEAKA, the nonce is never used. So the first block is always LTE I. LTE I’ will be usedin one interoperation scenario (Chapter 9).

In LTE II, the HN derives the authentication vector from the UMTS authen-tication vector (Section 4.1). Unlike in GSM and UMTS, the HN derives the masterkey KASME and provides it to the MME together with the respective authentication

49

MS MME

4. Identity Request

5. IMSI

1. CAP

2. GUTI

BS

LT

E I

3. NONCE_MS

Figure 5.3: LTE I’ when the AKA starts with a TAU request

vector. The id of the SN is an input to the key KASME derivation, i.e., the derivedkey is bound to a specific MME.

In LTE III, the MME sends the authentication challenge, which includes therandom challenge RAND , the authentication token AUTN , and the key identifierKSIASME . The KSIASME is used to identify the KASME and the session keys derivedfrom the KASME . Upon receiving the challenge, the MS verifies the freshness and theintegrity of the authentication vector. The MS then computes the response and themaster key and sends the response to the MME. The MME then checks whether theresponse matches the expected response.

After executing the challenge-response procedure (LTE III), the MS and theMME proceed to the NAS SMC procedure (LTE IV) in which the MME derives theNAS encryption and integrity keys and decides the encryption and integrity protectionalgorithms based on the capabilities of the MS. The decided algorithms, along withthe CAP received as part of message 1, are sent from the MME to the MS in anintegrity protected NAS SMC message. Upon the receipt of the SMC message, theMS verifies the integrity of the message and confirms that the security capabilitiesmatch the ones the MS has sent out.

In case starting with LTE I’, if the KASME is derived by the MME takingthe nonces NONCEMS and NONCEMME as input, both nonces are included in theintegrity protected message. In such case, in addition to the capabilities, the MS alsoverifies the NONCEMS matches the one originally sent in LTE I’ (this is discussedfurther in Chapter 9).

When the MS needs to send or receive data, the AS SMC procedure is exe-cuted. The MME sends the MS’s security capabilities and KASME to an eNB, whichdecides the AS algorithms and derives the eNB key KeNB from the KASME . TheeNB also derives the encryption and integrity protection keys for the Radio ResourceControl (RRC ) traffic and the User Plane (UP) traffic. The RRC keys are usedto encrypt and protect the integrity of RRC signaling traffic. The UP cipher key isused to encrypt user data. The AS security context is established by sending the ASSMC message from the eNB to the MS. The AS SMC message contains the selectedalgorithms and is integrity protected with the RRC integrity key. The AS securitymode complete message replied by the MS is also integrity protected with the RRCintegrity key. The AS SMC message does not include the security capabilities of the

50

MS.The LTE AKA provides mutual authentication between the MS and the SN.

Because the master key KASME is derived using the SN identity as a parameter, andthe cipher and integrity keys are derived from the master key. The successful use ofderived keys enables the MS to indirectly authenticate the specific MME.

The following security properties are expected:

• Key SecrecyThe pre-shared key Ki , the local master key KASME , the eNB key KeNB , and thederived NAS and AS integrity keys and cipher keys should be unknown to theattacker.

• Conditional Payload SecrecyThe data traffic should remain unknown to the attacker if the SN chooses to useencryption.

• Mutual Authentication between MS and MMEThe 4G AKA is designed to provide for the mutual authentication between the MSand the specific MME.

• Authentication of the BS to the MSThe 4G AKA is designed to provide for the authentication of the BS to the MS.

It is clear that 4G does not preserve the payload secrecy. For example, if the SNdecides not to use encryption, the attacker can learn the payload.

5.2 Modeling the LTE AKA

In this section we provide an overview of the key design choices and design rationales.We also present detailed explanation of the ProVerif model.

5.2.1 Design Choices

The LTE model reuses the design choices used in the GSM and UMTS model. In thissection, we discuss the design choices that distinguish our model from the GSM andUMTS models.

Abstracting the KSI from the authentication challenge message:When challenging the MS in the AKA, the MME includes the KSIASME , which isallocated by the MME and used to identify the KASME . The purpose of the KSIASME

is to identify a native KASME without invoking the AKA. Since we model a freshAKA, the KSIASME is omitted from the authentication challenge message.

Including both the IMSI and the SN identity in the authenticationdata response message: We explain the design choice of including the IMSI in theauthentication data response message in Section 3.2.1 (due to the approximations of

51

ProVerif, false attack can be found without the MS identity in the authenticationdata response message). For similar reasons, the SN identity is also included in theauthentication data response message.

Including the SN identity in the authentication challenge message:The SN identity is included in the authentication challenge message, which is notspecified in the standard. During the AKA, both the HN and the MS compute theKASME from CK , IK , and SN identity. However, the specification does not includehow the MS gets the SN identity. We model the MS to obtain the SN identity throughthe authentication challenge message.

Separating the eNB process from the MME process: Two main com-ponents of the SN are the MME and the eNB. As mentioned in Section 5.1, the NASSMC messages are exchanged between the MME and the MS and the AS SMC mes-sages are exchanged between the eNB and the MS. In the model, both the NAS andAS SMC procedures are included. We use a separate eNB process to specify the ASSMC procedure.

Modeling communication between the BS and the MME using aprivate channel In addition to assuming the security of communication betweenthe MME and the HN, we also assume that communication between the eNB and theMME is secure. For this reason, a private channel is declared to model the securecommunication between the BS and the MME.

5.2.2 LTE Model

In this section, we present the LTE model along with the diagram annotated ac-cord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S3_LTE_I-V.pv.

Figure 5.4 augments the protocol diagram of Figure 5.2 with details of theProVerif model. As mentioned before, the MME communicates with the HN and BSon secure channels.

(∗ Secure channe l between MME and HN ∗)f r ee s e cu r eChanne l : channel [ pr i va te ] .(∗ Secure channe l between MME and BS ∗)f r ee sChanne lSnBts : channel [ pr i va te ] .

In addition to the built-in types, we declare additional types.

type key . (∗ pre−sha r ed Ki ∗)type i d e n t . (∗ i d e n t i t y o f the MS and the SN ∗)type nonce . (∗ random number ∗)type msgHdr . (∗ message heade r ∗)type r e s p . (∗ r e s pon s e ∗)type c i phe rKey . (∗ c i p h e r key i n UMTS a u t h e n t i c a t i o n v e c t o r s ∗)type i n t egKey . (∗ i n t e g r i t y key i n UMTS a u t h e n t i c a t i o n v e c t o r s ∗)type mac . (∗ mac i n a u t h e n t i c a t i o n v e c t o r s ∗)type msgMac . (∗ i n t e g r i t y p r o t e c t i o n o f messages ∗)type asmeKey . (∗ K ASME ∗)

52

MS MME 4G HN

5. RAND, AUTN, SNid

6. RES

3. IMSI, SNid, Network Type

4. IMSI, SNid RAND, AUTN, XRES, KASME

2. IMSI

1.CAP

10. enableEnc, AS-MAC

BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid,)

Verify RES = XRES

9. CAP, KeNB

Generate RAND ,MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC KASME=KDF(CK, IK, SNid)

11. AS SMC Complete Integrity protected

7. eableEnc, CAP, NAS-MAC

KNASenc = KDF (KASME), KNASint = KDF(KASME) XNAS-MAC = EIA((CAP, enableEnc), KNASint)

Verify XNAS-MAC = NAS-MAC Start ciphering/deciphering and integrity protection

8. NAS Security Mode Complete ifenableEnbciphered , integrity protected

otherwise integrity protected

KNASenc = KDF (KASME,), KNASint = KDF(KASME,) Decide enableEnc?,

NAS-MAC = EIA((enableEnc, CAP), KNASint)

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

Decide enableENC, AS-MAC = EIA(enableEnc, KRRCint) Start integrity protection

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

XAS-MAC = EIA( enableEnc, KRRCint) Verify XAS-MAC = AS-MAC

12. payload, if no encryption {payload}_KRRCenc, otherwise

Decrypt message ifenableEnc_ms is true

event begSN(imsi_ms, snid_ms, kasme_ms)

event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms)

event endSN(imsi_sn, snid_sn, kasme_sn)

event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

KeNB = KDF(KASME)

LT

E IV

L

TE

V

LT

E I

LT

E II

LT

E III

Verify the integrity of message 8

Figure 5.4: LTE AKA (Figure 5.2) annotated in accord with our model

type nasEncKey . (∗ NAS en c r y p t i o n key ∗)type nas In tKey . (∗ NAS i n e g e r i t y key ∗)

53

type enbKey . (∗ type o f K enb ∗)type asEncKey . (∗ AS en c r y p t i o n key ∗)type a s I n tKey . (∗ AS i n t e g r i t y key ∗)type upEncKey . (∗ UP en c r y p t i o n key ∗)

Similarly to the GSM and UMTS model, we also define a number of distinct constantvalues as message headers to identify messages (not shown). The key derivationfunctions and the cryptographic functions are declared as:

fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : nas In tKey .fun f i n t e g n a s ( b i t s t r i ng , na s In tKey ) : msgMac .fun kd f enb ( asmeKey ) : enbKey .fun k d f a s e n c ( enbKey ) : asEncKey .fun k d f a s i n t ( enbKey ) : a s I n tKey .fun kd f up enc ( enbKey ) : upEncKey .fun f i n t e g a s ( b i t s t r i ng , a s I n tKey ) : msgMac .fun s e n c r y p t n a s ( b i t s t r i ng , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i ng , asEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : asEncKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i ng , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i ng , a s I n tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : a s I n tKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.fun s enc up ( b i t s t r i ng , upEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i ng , k : upEncKey ;

sdec up ( senc up (m, k ) , k ) = m.

The type system of ProVerif occasionally makes it difficult to apply functions toarguments due to type mismatches. We can overcome this by defining a special typeof constructor, which acts as an identity function. We define a type converter whichconverts bool into bitstring .

fun b o o l 2 b i t s t r i n g ( bool ) : b i t s t r i n g [ data , t y p eConve r t e r ] .

The type converter just changes the types and has no other effect. Because the typeconverter constructor is declared as a data constructor, the attacker can construct anddecompose it. That means the attacker can recover b from the term bool2bitstring (b).Recall that ProVerif statically checks types, to aid debugging, but ignores types duringreasoning. We use this default option. Therefore, the functions marked typeConverter

are removed when generating Horn clauses.

54

The non-deterministic choice of the MS’s capabilities and the table used tomodel the association of keys and identities are the same as those in the GSM model.

The events used in the correspondence assertions to specify the authenticationproperties are declared as:

event begSN ( iden t , i d en t , asmeKey ) .event endSN( iden t , i d en t , asmeKey ) .event begMS( iden t , i d en t , asmeKey , bool ) .event endMS( iden t , i d en t , asmeKey , bool ) .event begMS ENB( iden t , enbKey , bool ) .event endMS ENB( iden t , enbKey , bool ) .

There are four main processes in our model representing the behavior of the MS,the eNB, the MME, and the HN respectively. In the models of GSM (Section 3.2.2)and UMTS (Section 4.2.2), the SN is represented by a single process. The reason thatthe SN can be modeled in one process is that it is assumed that the communicationbetween the BS and the MSC is secure. We could also model the SN in LTE inone process, however, because the NAS SMC procedure has two options to enableencryption or not. The AS SMC procedure, which is modeled in the eNB process,is executed in both options. To avoid duplicating code, we could model the ASSMC procedure as a parameterized procedure (as in the MS process) or as a separateprocess. We choose to model it as a process, since it is natural to model a componentas a process.

The MS process is defined as follows. The comments refer to message numbersin Figure 5.4.

1 (∗ AS SMC procedu r e i n p r o c e s s MS ∗)2 l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : bool ) =3 l e t kenb ms : enbKey = kd f enb ( kasme ms ) i n4 l e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i n5 l e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i n6 l e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i n7 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s8 ( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)9 out ( pubChannel , (ASSMComplete , as smcomplete msg ,

10 f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 11 ] ∗)11 event endMS ENB( ims i ms , kenb ms , cap ms ) ;12 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng ,13 =f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 12 ] ∗)14 out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;15 out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;16 out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;17 i f enab l eEnc as ms = t r u e then18 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms ) i n 0 .19

20 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)21 l e t processMS =22 new ims i ms : i d e n t ;23 new k i : key ;

55

24 i n s e r t keys ( ims i ms , k i ) ;25 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n26 out ( pubChannel , (CAP, cap ms ) ) ;27 out ( pubChannel , ( ID , ims i ms ) ) ;28 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,29 =f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)30 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n31 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n32 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n33 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n34 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)35 l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i n36 l e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i n37 i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,38 =f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;39 (∗ [Msg 7 ] ∗)40 event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;41 out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;42 out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;43 event begSN ( ims i ms , sn id ms , kasme ms ) ;44 i f enab l eEnc nas ms = f a l s e then45 out ( pubChannel , (NASSMComplete , nas smcomplete msg ,46 f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)47 pMSAS( kasme ms , ims i ms , cap ms )48 e l s e49 out ( pubChannel , (NASSMComplete ,50 s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,51 f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,52 knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)53 pMSAS( kasme ms , ims i ms , cap ms ) .

Similarly to the GSM model, this model specifies the registration process of the MSdevice in lines 22–24. In lines 28–29, the MS receives and checks the authenticationchallenge message. The MS computes the KASME in line 33. In lines 37–39, the MSreceives the NAS SMC message and verifies the integrity and the received capabil-ities. The MS then sends out the SMC complete message which is ciphered if theencryption is enabled and integrity protected (lines 45–46 or 49–52). Lines 47 and 53call a parameterized process which specifies the AS SMC procedure in lines 3–10 andreceives the data message in lines 12–13. As in the GSM model, to test the secrecyof the keys, the MS encrypts a private free name with the keys, and sends them outon the public channel (lines 41–42 and 14–16).

The process representing the MME is defined as follows. The comments referto message numbers in Figure 5.4.

1 l e t processMME =2 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)3 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)4 new s n i d s n : i d e n t ;5 out ( s ecu reChanne l , (AV REQ , ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)6 i n ( s ecu reChanne l , (=AV, =ims i s n , =sn i d s n , r and sn : nonce ,

56

7 x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ) ) ; (∗ [Msg 4 ] ∗)8 out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;9 (∗ [Msg 5 ] ∗)

10 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)11 event begMS( ims i s n , s n i d s n , kasme sn , cap sn ) ;12 l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i n13 l e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i n14 out ( pubChannel , (NASSMC, cap sn , cap sn ,15 f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)16 i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i ng ,17 =f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)18 i f cap sn = t r u e then19 i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then20 event endSN( ims i s n , s n i d s n , kasme sn ) ;21 out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )22 e l s e 023 e l s e24 i f cap sn = f a l s e then25 i f msg nas = nas smcomplete msg then26 event endSN( ims i s n , s n i d s n , kasme sn ) ;27 out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )28 e l s e 029 e l s e 0 .

In lines 5–7, the MME communicates with the HN to gain the authentication vector.The MME sends out a challenge in line 8 and receives and verifies the response fromthe MS in line 10. The NAS SMC procedure of the MME side is specified in lines14–17. In lines 21 and 27, the MME sends the KASME , as well as the identity andcapabilities of the MS, to the eNB through the private channel.

The code of the eNB process is defined as follows. The comments refer tomessage numbers in Figure 5.4.

1 l e t processENB =2 i n ( sChannelSnBts , ( kasme enb : asmeKey , im s i e nb : i d en t ,3 cap enb : bool ) ) ;4 l e t kenb enb : enbKey = kd f enb ( kasme enb ) i n5 l e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i n6 l e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i n7 l e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i n8 event begMS ENB( ims i enb , kenb enb , cap enb ) ;9 out ( pubChannel , (ASSMC, cap enb ,

10 f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) , k a s i n t e n b ) ) ) ; (∗ [Msg 10 ] ∗)11 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,12 =f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 11 ] ∗)13 i f cap enb = f a l s e then14 event d i s a b l eEn c ;15 out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )16 (∗ [Msg 12 ] ∗)17 e l s e18 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,19 f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .

57

20 (∗ [Msg 12 ] ∗)

The eNB receives the KASME and the identity and capabilities of the MS from theMME in lines 2–3. The AS keys are derived in lines 4–7. The AS SMC procedure ismodeled in lines 9–12. After successfully executing the AS SMC procedure, the eNBsends out the data message either in line 15 or in lines 18–19, depending on whetherthe encryption is enabled or not.

The HN process is defined as follows.

1 l e t processHN =2 i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;3 (∗ [Msg 3 ] ∗)4 new rand hn : nonce ;5 get keys (= ims i hn , k i h n ) i n6 l e t mac hn : mac = f1 ( k i hn , rand hn ) i n7 l e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i n8 l e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i n9 l e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i n

10 l e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i n11 out ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn ,12 x r e s hn , mac hn , kasme hn ) ) . (∗ [Msg 4 ] ∗)

The HN gets the pre-shared key in line 5 and computes the KASME in line 10. Notethat the CK and IK computed in lines 8–9 never leave the HN.

5.3 Security Property Specifications and Findings

This section presents the specifications of secrecy and authentication properties. Wethen present the analysis result of the security properties.

The secrecy and authentication properties are specified as:

1 query attacker ( pay load ) .2 query attacker ( pay load ) event ( d i s a b l eEn c ) .3 query attacker ( s e c r e t ) .4 query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;5 event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .6 query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : bool ;7 event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .8 query x1 : i d en t , x2 : enbKey , x3 : bool ;9 event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

Like in the UMTS model, an additional data message is introduced to test the secrecyof the data. As expected, the payload can be learned by the attacker when the MSis not capable of encryption. The conditional secrecy (line 2) expresses that if theattacker obtains the secret payload then the event disableEnc must have previouslytaken place. Because the NAS and AS keys are computed only from KASME , thesecrecy of any NAS or AS key implies the secrecy of KASME .

The authentication of the MS to the MME (lines 4–5) is specified in such away that if the event endSN with arguments IMSI, SN identity and KASME is executed,

58

Table 5.1: Analysis result of LTE model

KeySecrecy

ConditionalPayloadSecrecy

Auth. ofthe MS to

the SN

PayloadSecrecy

Auth. ofthe MMEto the MS

Auth. ofthe BS tothe MS

Proved Proved Proved Failed Proved Proved

then the event begSN must have been executed previously with the same arguments.In fact, the SN identity can be implied by the KASME . To emphasize that the twoparties agree on the identity of the SN, we include the SN identity in the parame-ters of the correspondence assertion. The event endSN is inserted after receiving andchecking the security mode complete message. Since the KASME is computed fromthe CK, the IK and the SN identity, and they are not used in the challenge-responseround, until receiving and confirming the security mode complete message, the MMEcannot conclude that the MS receives the correct SN identity and derives the sameKASME . The authentication of the MME to the MS is specified in lines 6–7. Besidesthe identities and keys, the MS also provides for the authenticity of the security capa-bilities, so we include the capabilities in the parameters of events. In addition to theauthentication between the MS and the MME, the protocol should also provide forthe authentication of the BS to the MS, which is specified in lines 8–9. The securitycapabilities (modeled as encryption options) are included in the parameters of theevents to specify that the events should agree on the encryption option.

Table 5.1 shows the analysis result of the above properties.

59

Chapter 6Comparative Authenticity

In this chapter, we compare the authenticity achieved by the different generations ofthe technologies. We review differences between corresponding blocks in the differenttechnologies, which are defined in Chapter 3–5. We compare the specifications of theauthentication properties (correspondence assertions), including the parameters usedin the correspondence assertions. During the discussion, we establish some terminolo-gies for different types of the authenticity. This discussion of the authenticity in pureAKAs serves as a basis for our later comparison of the authenticity of interoperationscenarios (Chapters 8 and 9).

6.1 Authentication of the MS to the SN

In this section, we compare the standards in terms of the authentication of the MSto the SN.

6.1.1 GSM vs. UMTS

In this section, we introduce the authentication of the MS to the SN in GSM andUMTS using the challenge response procedure to check if the MS has the correct per-manent key Ki . We compare the corresponding blocks in GSM and UMTS, in whichthe MS achieves to authenticate itself to the SN. We consider the formal specifica-tions of the authentication properties, i.e., the correspondence assertions. In additionto the parameters used in the correspondence assertions, we also discuss the crypto-graphic material implied by the parameters. Both protocols provide the same typeof authentication using similar challenge-response procedures.

As we described in Chapter 3, in GSM, the MS and the HN share the permanentkey Ki , which never leaves the MS and the HN. The HN generates the authenticationvector based on the random number RAND and the permanent key Ki . The HNsends the authentication vector to the MSC. Note that the MSC cannot create thechallenge and the response. The MSC authenticates the MS by testing if the MS hasthe knowledge of the Ki . The testing is done by sending the RAND as challengeto the MS and checking if the response from the MS matches the expected responsein the authentication vector. If the responses match, which means the MS knowsthe permanent key Ki , then the MS is authenticated. In order to refer this type ofauthenticity, we use the term challenge-response authentication .

The left part of Figure 6.1 shows the block GSM III, which contains the chal-lenge response procedure, including the events used in the correspondence assertions.The correspondence assertion that specifies authentication of the MS to the SN inGSM is

60

MS

5. RAND

6. RES

SN

res__ms = a3(Ki, rand_ms), kc_ms = a8(Ki, rand_ms)

Verify res_sn = xres_sn

event endSN(imsi_hn_sn, kc_sn)

event begSN(imsi_ms,kc_ms)

GSM

III

MS SN

5. RAND, AUTN

6. RES

Compute res_ms, ck_ms, ik_ms, xmac_ms Verify mac_ms=xmac_ms

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_hn_sn, ck_sn, ik_sn)

Verify res_sn = xres_sn

UM

TS III

Figure 6.1: Events used to specify the authentication of MS to SN in GSM and UMTS

event endSN( IMSI , Kc) event begSN ( IMSI , Kc)

We choose the identity of the MS and the session key as parameters of the correspon-dence assertions. The correspondence assertion says that if the SN reaches the pointin its protocol marked by event endSN, for a given IMSI and session keys, then thereis a legitimate MS that reached the point marked begSN, with the same IMSI andsession key.

Because the session key is derived from the Ki and the RAND , the events’agreement on the key implies agreement on the Ki and the RAND as well. That is, ifSN reaches the point marked endSN for a particular IMSI , with associated long-termKi and with nonce RAND provided by HN, then there is an MS that reaches thepoint marked begSN, has long-term key Ki and is responding using RAND .

In UMTS (Chapter 4), the MS authenticates itself in the similar way as it doesin GSM. In the challenge from the MSC, in addition to the random number RAND ,an authentication token is also included. The sequence number in the authenticationtoken helps the MS to reject any older or pre-used authentication challenge. Despitethe authentication token being included in the challenge, the authentication of theMS to the SN in UMTS is the same type as the authentication of the MS to the SNin GSM, which is challenge-response authentication in our terminology.

The right part of Figure 6.1 shows the block UMTS III, which contains thechallenge response procedure, including the events used in the correspondence asser-tions. The correspondence assertion that specifies authentication of the MS to theSN in UMTS is

event endSN( IMSI , CK, IK ) event begSN ( IMSI , CK, IK )

The correspondence assertion has the same meaning as the one in GSM.

6.1.2 UMTS vs. LTE

We now carry out the same kind of analysis as in Section 6.1.1. The conclusion isthat LTE provides the same type of authentication as in GSM and UMTS.

61

MS SN

5. RAND, AUTN

6. RES

Compute res_ms, ck_ms, ik_ms, xmac_ms Verify mac_ms=xmac_ms

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_hn_sn, ck_sn, ik_sn)

Verify res_sn = xres_sn

UM

TS III

MS MME

5. RAND, AUTN, SNid

6. RES

LT

E III

KNASenc = KDF (KASME), KNASint = KDF(KASME) XNAS-MAC = EIA((CAP, enableEnc), KNASint)

Verify XNAS-MAC = NAS-MAC

event begSN(imsi_ms, snid_ms, kasme_ms)

7. eableEnc, CAP, NAS-MAC

8. NAS-SMComplete msg, NAS-SMComplete-MAC

event endSN(imsi_sn, snid_sn, kasme_sn)

LT

E IV

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid,)

Verify RES = XRES

Verify NAS-SMComplete-MAC

Figure 6.2: Events used to specify the authentication of MS to SN in UMTS and LTE

In LTE, the MME authenticates the MS by sending the challenge received fromthe HN and checking whether the response received from the MS matches the expectedresponse. If the responses match, the MME concludes the MS has the permanent keyKi . Similar to UMTS, the authentication token included in the challenge does notmake difference of the type of the authenticity. Therefore the authentication of theMS to the SN in LTE is also challenge-response authentication.

The right part of Figure 6.2 shows the blocks LTE III-IV including the eventsused in the correspondence assertions. The correspondence assertion that specifiesauthentication of the MS to the SN in LTE is

event endSN( IMSI , SNid , K ASME) event begSN ( IMSI , SNid , K ASME)

The correspondence assertion means that if the SN with identity SNid reaches thepoint endSN it knows there is an MS with the same IMSI which reaches begSN usingthe same master key KASME . The KASME is generated from the permanent key Ki ,the random number RAND , and the serving network identity SNid . In LTE III, theSN ensures that the MS has the correct Ki and RAND by checking the response.By contrast, agreement on the key KASME cannot be confirmed until the key is used.So the events used in the correspondence assertion are placed in LTE IV, where thekey is used. Agreement on KASME implies agreement on Ki and the RAND fromwhich it is derived. Despite the SNid being included as a parameter of the events,given that the SN knows its own identity it makes no difference for the type of theauthentication of the MS to the SN.

62

6.2 Authentication of the SN to the MS

In this section, we compare the standards in terms of the authentication of the SN tothe MS.

6.2.1 GSM vs. UMTS

As described in Chapter 3, GSM does not provide authentication of the SN to theMS. In UMTS, the MS does authenticate the SN, by verifying the integrity of theSMC message (in UMTS IV) to ensure the SN knows the correct integrity key whichis obtained from the HN. The knowledge checked by the MS is based on the derivedintegrity key. This authentication is not challenge response, rather is based on check-ing knowledge of the integrity key. In order to refer this type of authentication of theSN to the MS, we use the term use-based proved knowledge authentication .

The two components of the SN, i.e. the BS and the MSC, are each authenti-cated in different way. In UMTS, the MAC of the SMC message is generated by theBS. By successfully verifying the MAC, the MS in fact concludes that the BS has theknowledge of the correct integrity key. Therefore this is use-based proved knowledgeauthentication of the BS to the MS. The authentication of the MSC to the MS isbased on the following reasoning: the MS trusts that the HN and the MSC followthe protocol. The BS proves to the MS that it knows the integrity key; the only waythe BS obtains the integrity key is from the MSC which can only get it from the HN.In order to refer this type of authentication of the MSC to the MS, we use the termindirect use-based proved knowledge authentication .

The left part of Figure 6.3 shows the block UMTS IV including the events usedto specify the correspondence assertion, which is

event endMS( IMSI , CK, IK , CAP) event begMS( IMSI , CK, IK , CAP)

It means that if the MS with the IMSI reaches the event endSN then an SN must havereached its begSN with the same session keys and the same capabilities of the MS.Because the session keys are generated from the permanent key Ki and the nonceRAND , agreement on the keys implies agreement on Ki and RAND . (Recall fromchapter 4 that in the UMTS model we combine the BS with the MSC)

The CAP is used as a parameter in the events to check if the BS receives thecorrect capabilities, which prevents the false base station attack [53]. This is notrelevant to the authentication of the BS to the MS, because the authentication isestablished by the knowledge of the integrity key.

6.2.2 UMTS vs. LTE

Recall that the authentication of the BS to the MS in UMTS is the use-based provedknowledge authentication and the authentication of the MSC to the MS in UMTS isthe indirect use-based proved knowledge authentication.

63

MS SN

7. eableEnc, CAP, FRESH, MAC-I

event begMS(imsi_hn_sn, ck_sn,ik_sn, cap_sn)

event endMS(imsi_ms, ck_ms, ik_ms, cap_ms)

8. SMComplete, integrity protected

UM

TS IV

XNAS-MAC = EIA((CAP, enableEnc), CK) Verify XNAS-MAC = NAS-MAC

MS MME

10. enableEnc, AS-MAC

BS

9. CAP,KeNB

11. AS SMComplete msg AS-SMComplete-MAC

7. eableEnc, CAP, NAS-MAC

KNASenc = KDF (KASME) KNASint = KDF(KASME) XNAS-MAC = EIA(

(CAP, enableEnc), KNASint) Verify XNAS-MAC = NAS-MAC

8. NAS SMComplete msg NAS-SMComplete-MAC

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

Decide enableENC, AS-MAC = EIA(enableEnc,KRRCint)

KeNB = KDF (KASME) KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB) KUPenc = KDF (KeNB)

XAS-MAC = EIA( enableEnc, KRRCint)

Verify XAS-MAC = AS-MAC

event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms)

event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

KeNB = KDF(KASME)

LT

E IV

L

TE

V

Verify NAS-SMComplete-MAC

Verify AS-SMComplete-MAC

Figure 6.3: Events used to specify the authentication of SN to MS in UMTS and LTE

The LTE AKA separates the NAS and AS traffic and derives different keys forthe corresponding stratum. The NAS and AS security contexts are established by theNAS SMC procedure and the AS SMC procedure respectively. These two proceduresenable the authentication of the MME and the BS to the MS respectively. The MSauthenticates the MME by verifying the integrity of the NAS MSC message to checkif the MME has the knowledge of the NAS integrity key, which is derived from theKASME . The KASME is derived by the HN from the CK , the IK , and the identity ofthe SN SNid . Also the CK and IK are derived from the Ki and the RAND . So theidentity of the SN is bound to the KASME and keys derived from KASME . Comparedwith UMTS, the MME directly proves that it has the knowledge of the integrity keyand the MS obtains additional assurance of the identity of the SN. The authenticationof the MME to the MS in LTE is called use-based proved knowledge with SNidauthentication .

The MS authenticates the BS also by verifying the integrity of the AS SMCmessage, which is generated by the BS, to check whether the BS has the knowledgeof the correct AS integrity key. The AS integrity key is derived from the KeNB ; theKeNB is derived from the KASME . So the identity of the SN is also bound to the ASintegrity key. Which means that the authentication of the BS to the MS in LTE is

64

also the use-based proved knowledge with SNid authentication.The events used to specify the authentication of the MME to the MS are placed

in LTE IV in the right part of Figure 6.3. The correspondence assertion is

event endMS( IMSI , SNid , K ASME, CAP) event begMS( IMSI , SNid , K ASME, CAP)

which says that if an MS with given IMSI reaches its endMS it knows that the MMEwith the same SNid reaches its point begMS with the same master key and the samecapabilities sent by the MS.

Authentication of the BS to the MS is specified using the events in LTE V inthe right part of Figure 6.3. The correspondence assertion is

event endMS ENB( IMSI , K eNB , CAP) event begMS ENB( IMSI , K eNB , CAP)

Because the KeNB is derived from the KASME , and the KASME is derived from theKi , the RAND , and the SNid , agreement on KeNB implies agreement on the Ki , theRAND , and the SNid . The correspondence assertion says that if an MS with givenIMSI reaches its endMS ENB then it knows there is a BS, attached to an MME withidentity SNid , which reaches its begMS ENB with the same intermediate key and thesame capabilities of the MS.

6.3 Summary

We identify four main types of authentication that can be described in terms of themajor components, MS, BS, MSC/MME, and HN.

challenge-response Authentication is based on a random challenge and the re-sponse is used to prove that the responding party has the correct key and usedit to respond to the challenge. For example, the authentication of the MS tothe SN in all the pure AKAs is challenge-response authentication.

use-based proved knowledge Authentication is based on that one party possessesthe correct integrity key and uses it to generate the MAC. For example, theauthentication of the BS to the MS in UMTS is use-based proved knowledgeauthentication.

indirect use-based proved knowledge Authentication is indirect and based onthe use-based proved knowledge. The reasoning is that two participants con-nected by a secure channel trust each other to follow the protocol, and the onlyway one can get a derived key is by obtaining it from the other. For example,the authentication of the MSC to the MS in UMTS is indirect use-based provedknowledge authentication.

use-based proved knowledge with SNid This is like use-based proved knowl-edge authentication, but with the addition that the SNid is provided to the

65

Table 6.1: Types of authentication achieved by the pure AKAs

Auth. of MS to SNAuth. of SN to MS

Auth. of MSC/MME to MS Auth. of BS to MSGSM challenge-responseUMTS challenge-response indirect use-based proved knowledge use-based proved knowledgeLTE challenge-response use-based proved knowledge with SNid use-based proved knowledge with SNid

Table 6.2: Parameters of the correspondence assertions used in the proved authenti-cation properties

Implied parameters in addition to RAND and Ki are put in parentheses

Auth. of MS to SNAuth. of SN to MS

Auth. of MSC/MME to MS Auth. of BS to MSGSM IMSI , KcUMTS IMSI , CK , IK IMSI , CK , IK , CAPLTE IMSI , SNid , KASME IMSI , SNid , KASME , CAP IMSI , Kenb , CAP (SNid)

MS and the integrity key is derived not only from the long-term key but alsofrom the SNid. For example, the authentication of the MME to the MS in LTEis use-based proved knowledge with SNid authentication.

Table 6.1 summarizes the types of authenticity achieved by the pure AKAs.We have compared the specifications of the authentication properties by iden-

tifying the corresponding blocks which contains the events and discussing the param-eters used in the correspondence assertions. Table 6.2 shows the parameters used inthe correspondence assertions. The “parameters” in parentheses are implied by keyderivations rather than being explicit in events. Since all the session keys are derivedfrom the RAND and the Ki , those are also implied in every case, so we only list theadditional implied parameters.

66

Chapter 7Establishing a Initial Security Context in Interoperation

In this chapter, we systematically enumerate all possible interoperation cases, i.e.,combination of system components from different technologies. We first summarizethe system components in Section 7.1. Since each of the five main system componentscan be 2G, 3G, or 4G, there are 35 = 243 cases in which deployed components fromdifferent technologies might interact. We justify which cases are explicitly allowed(Section 7.2), which cases are disallowed (Section 7.3), and which cases are uncertain(Section 7.4). Our analysis is based on the standards [1, 6, 8, 11, 7] and otherdocumentations [52].

7.1 System Components

In this section, we summarize the main components which are introduced previouschapters. The three main components in the network architecture of GSM, UMTS,and LTE are the MS, the SN, the HN.

The MS is the combination of the ME and an identity module. The ME isthe user device that contains the radio functionality and the encryption/integritymechanisms used to protect the traffic between the MS and the network. A 4G MEalso includes the functionality to derive an LTE master secret key KASME . In GSM,the identity module of the SIM contains the unique IMSI, the subscriber’s permanentsecret key Ki , as well as the mechanisms used for GSM AKA and GSM session keyderivation. The UMTS identity module (USIM) includes the IMSI, Ki , and the UMTSAKA and session key derivation functionality. It furthermore may contain the SIMfunctionality, i.e., the GSM AKA and key derivation functionality. In contrast to a3G USIM, an LTE USIM (also referred to as enhanced USIM) provides for additionalfunctionality including enhanced capability for the storing of a security context.

The SN typically consists of the BS and either the MSC in GSM and UMTS,or the MME in LTE. The BS is the network access point which manages the radioresources and establishes the connection to the MS. In GSM, the BS includes theBTS which connects to the BSC. In GSM, encryption terminates at the BTS or atthe SGSN in GPRS. In UMTS, the BS includes the NodeB which connects to theRNC. Encryption and integrity protection in UMTS terminates in the RNC. In LTE,BS is the eNodeB. LTE distinguishes the protection of the connection between the MSand the eNodeB—the so-called AS and the connection between the MS and MME—the so-called NAS. In LTE, the MME is the end-point for the NAS and the respectiveprotection mechanisms.

The HN includes the HLR and the AuC in GSM and UMTS, respectively theHome Subscriber Server (HSS) in LTE. The HN stores all subscriber data including

67

Table 7.1: Legend used in Table 7.2Rows CasesNormal font with no color AllowedGreen color and bold font UncertainGrey color and italic font DisallowedBlue color and in bold italic font Involving only 2G/3G components

the IMSI and permanent shared secret key Ki . It furthermore, holds its (own) algo-rithms for deriving session keys as well as generating authentication vectors. A 4GHN also includes the functionality for deriving an LTE master secret key KASME .

Each one of the five main system components (the identity module, the ME,the BS, the MSC/MME, and the HN) can be 2G, 3G, or 4G—thus resulting in35 = 243 possible combinations. Each combination corresponds to an interoperationcase. Table 7.2 shows the details for the cases. The rows marked with blue colorand in bold italic font are the cases involving only 2G/3G components. These caseshave been analyzed in [1, 87] and will be further detailed in Chapter 8. We classifythe cases involving 4G components in the following sections. Section 7.2 gives theallowed interoperation cases. Section 7.3 gives the disallowed interoperation cases.Section 7.4 gives the uncertain cases.

Table 7.1 explains the color/font scheme we used in Table 7.2.

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

1 4G 4G 4G2 3G 4G 4G A1,A43 2G 4G 4G A1,A44 4G 3G 4G R55 3G 3G 4G6 2G 3G 4G7 4G 2G 4G R48 3G 2G 4G R49 2G 2G 4G

10 4G 4G 3G A2,A411 3G 4G 3G A1,A2,A412 2G 4G 3G A1,A2,A413 4G 3G 3G R514 4G 4G 3G 3G 3G A215 2G 3G 3G A2

68

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

16 4G 2G 3G R417 3G 2G 3G R418 2G 2G 3G A219 4G 4G 2G R620 3G 4G 2G A1,A2,A421 2G 4G 2G A1,A2,A422 4G 3G 2G R523 3G 3G 2G A2,A324 2G 3G 2G A2,A325 4G 2G 2G R426 3G 2G 2G R427 2G 2G 2G A2,A328 4G 4G 4G R329 3G 4G 4G A1,A430 2G 4G 4G A1,A431 4G 3G 4G R3,R532 3G 3G 4G33 2G 3G 4G34 4G 2G 4G R3,R435 3G 2G 4G R436 2G 2G 4G37 4G 4G 3G R338 3G 4G 3G A1,A2,A439 2G 4G 3G A1,A2,A440 4G 3G 3G R3,R541 4G 3G 3G 3G 3G A242 2G 3G 3G A243 4G 2G 3G R3,R444 3G 2G 3G R445 2G 2G 3G A246 4G 4G 2G R347 3G 4G 2G A1,A2,A448 2G 4G 2G A1,A2,A449 4G 3G 2G R3,R550 3G 3G 2G A2,A351 2G 3G 2G A2,A352 4G 2G 2G R3,R4

69

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

53 3G 2G 2G R454 2G 2G 2G A2,A355 4G 4G 4G R256 3G 4G 4G R257 2G 4G 4G A1,A458 4G 3G 4G R2,R559 3G 3G 4G R260 2G 3G 4G61 4G 2G 4G R2,R462 3G 2G 4G R2,R463 2G 2G 4G64 4G 4G 3G R265 3G 4G 3G R266 2G 4G 3G A1,A2,A467 4G 3G 3G R2,R568 4G 2G 3G 3G 3G R269 2G 3G 3G A270 4G 2G 3G R2,R471 3G 2G 3G R2,R472 2G 2G 3G A273 4G 4G 2G R274 3G 4G 2G R275 2G 4G 2G A1,A2,A476 4G 3G 2G R2,R577 3G 3G 2G R278 2G 3G 2G A2,A379 4G 2G 2G R2,R480 3G 2G 2G R2,R481 2G 2G 2G A2,A382 4G 4G 4G83 3G 4G 4G A1,A484 2G 4G 4G A1,A485 4G 3G 4G R586 3G 3G 4G87 2G 3G 4G88 4G 2G 4G R489 3G 2G 4G R4

70

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

90 2G 2G 4G91 4G 4G 3G A492 3G 4G 3G A1,A493 2G 4G 3G A1,A494 4G 3G 3G R595 3G 4G 3G 3G 3G96 2G 3G 3G97 4G 2G 3G R498 3G 2G 3G R499 2G 2G 3G

100 4G 4G 2G R6101 3G 4G 2G A1,A4102 2G 4G 2G A1,A4103 4G 3G 2G R5104 3G 3G 2G105 2G 3G 2G106 4G 2G 2G R4107 3G 2G 2G R4108 2G 2G 2G109 4G 4G 4G R3110 3G 4G 4G A1,A4111 2G 4G 4G A1,A4112 4G 3G 4G R3,R5113 3G 3G 4G114 2G 3G 4G115 4G 2G 4G R3,R4116 3G 2G 4G R4117 2G 2G 4G118 4G 4G 3G R3119 3G 4G 3G A1,A4120 2G 4G 3G A1,A4121 4G 3G 3G R3,R5122 3G 3G 3G 3G 3G123 2G 3G 3G124 4G 2G 3G R3,R4125 3G 2G 3G R4126 2G 2G 3G

71

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

127 4G 4G 2G R3128 3G 4G 2G A1,A4129 2G 4G 2G A1,A4130 4G 3G 2G R3,R5131 3G 3G 2G R7132 2G 3G 2G133 4G 2G 2G R3,R4134 3G 2G 2G R4135 2G 2G 2G136 4G 4G 4G R2137 3G 4G 4G R2138 2G 4G 4G A1,A4139 4G 3G 4G R2,R5140 3G 3G 4G R2141 2G 3G 4G142 4G 2G 4G R2,R4143 3G 2G 4G R2,R4144 2G 2G 4G145 4G 4G 3G R2146 3G 4G 3G R2147 2G 4G 3G A1,A4148 4G 3G 3G R2,R5149 3G 2G 3G 3G 3G R2150 2G 3G 3G151 4G 2G 3G R2,R4152 3G 2G 3G R2,R4153 2G 2G 3G154 4G 4G 2G R2155 3G 4G 2G R2156 2G 4G 2G A1,A4157 4G 3G 2G R2,R5158 3G 3G 2G R2159 2G 3G 2G160 4G 2G 2G R2,R4161 3G 2G 2G R2,R4162 2G 2G 2G163 4G 4G 4G R1

72

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

164 3G 4G 4G R1165 2G 4G 4G R1166 4G 3G 4G R1,R5167 3G 3G 4G168 2G 3G 4G169 4G 2G 4G R1,R4170 3G 2G 4G R1,R4171 2G 2G 4G172 4G 4G 3G R1173 3G 4G 3G R1174 2G 4G 3G R1175 4G 3G 3G R1,R5176 2G 4G 3G 3G 3G177 2G 3G 3G178 4G 2G 3G R1,R4179 3G 2G 3G R4180 2G 2G 3G181 4G 4G 2G R1182 3G 4G 2G R1183 2G 4G 2G R1184 4G 3G 2G R1,R5185 3G 3G 2G186 2G 3G 2G187 4G 2G 2G R1,R4188 3G 2G 2G R4189 2G 2G 2G190 4G 4G 4G R1,R3191 3G 4G 4G R1192 2G 4G 4G R1193 4G 3G 4G R1,R3, R5194 3G 3G 4G195 2G 3G 4G196 4G 2G 4G R1,R3,R4197 3G 2G 4G R1,R4198 2G 2G 4G199 4G 4G 3G R1,R3200 3G 4G 3G R1

73

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

201 2G 4G 3G R1202 4G 3G 3G R1,R3,R5203 2G 3G 3G 3G 3G204 2G 3G 3G205 4G 2G 3G R1,R3,R4206 3G 2G 3G R4207 2G 2G 3G208 4G 4G 2G R1,R3209 3G 4G 2G R1210 2G 4G 2G R1211 4G 3G 2G R1,R3,R5212 3G 3G 2G213 2G 3G 2G214 4G 2G 2G R1,R3,R4215 3G 2G 2G R4216 2G 2G 2G217 4G 4G 4G R1,R2218 3G 4G 4G R1,R2219 2G 4G 4G R1220 4G 3G 4G R1,R2,R5221 3G 3G 4G R1,R2222 2G 3G 4G223 4G 2G 4G R1,R2,R4224 3G 2G 4G R1,R2,R4225 2G 2G 4G226 4G 4G 3G R1,R2227 3G 4G 3G R1,R2228 2G 4G 3G R1229 4G 3G 3G R1,R2,R5230 2G 2G 3G 3G 3G R2231 2G 3G 3G232 4G 2G 3G R1,R2,R4233 3G 2G 3G R2,R4234 2G 2G 3G235 4G 4G 2G R1,R2236 3G 4G 2G R1,R2237 2G 4G 2G R1

74

Table 7.2: Classifying the 243 interoperation cases (leg-end explained in Table 7.1)

IDComponents Condition to

SupportOccurrence

Reasons forDisallowanceIdentity

ModuleME BS MSC/

MMEHN

238 4G 3G 2G R1,R5239 3G 3G 2G R1,R2240 2G 3G 2G241 4G 2G 2G R1,R2,R4242 3G 2G 2G R2,R4243 2G 2G 2G

7.2 Allowed Interoperation Cases

In this section, we list some facts about the system components according to the3GPP specifications which explicitly allow certain cases.

For the identity module, the SIM supports 2G AKA only [1]. A USIM supportsboth 2G and 3G AKA [1]. Similarly, a 4G USIM supports 2G, 3G, and 4G AKA[52]. Since a large number of USIMs is in current use, a 4G ME with the USIM isallowed to access the 4G network. Since the 4G ME is capable of deriving LTE keysand storing security contexts [6], the combination of a 4G ME with a USIM supports4G AKA.

For the ME, it is possible to use a SIM or a USIM with a 2G ME [1]. Sincethe 4G USIM is an enhanced version of the USIM, this implies that it is possible toalso use a 4G USIM with a 2G ME. Similarly, since a SIM or USIM can be used witha 3G ME, [1], it is also possible to use a 4G USIM with a 3G ME. A 4G ME canbe used with a SIM [52] or USIM [8] and certainly with a 4G USIM. A 2G ME onlysupports GERAN [1]. A 3G ME supports GERAN and UTRAN [1], and a 4G MEsupports GERAN, UTRAN, and E-UTRAN [52].

For the BS, a 2G BS is only capable of handling a GSM session key Kc [1],which means a 2G BS only supports a 2G ciphering mode setting [11]. Similarly,a 3G BS requires the UMTS cipher key CK and the UMTS integrity key IK [1]—supporting only the 3G security mode set-up and operation [7]. A 4G BS requiresKeNB and only supports the 4G AS security mode command procedure and operation[8].

For the MSC/MME, a 2G MSC can only control a 2G BS and only supports2G AKA [1]. A 3G MSC can control both a 2G BS and a 3G BS and can supportboth 2G and 3G AKA [1]. An MME can control a 4G BS and can support the 4GAKA [8].

For the HN, a 2G HN can maintain 2G and 3G subscriptions [1]. A 3G HNcan maintain 2G and 3G subscriptions [1]. A 4G HN can maintain 3G and 4G

75

subscriptions [8].Based on the above facts, we identify 38 allowed cases, which are the rows in

normal font with no color in Table 7.2.

7.3 Disallowed Interoperation Cases

In this section, we list the reasons, which are extracted from the 3GPP specifications,to rule out 138 cases.

The 3GPP specifications explicitly specifies the incompatibilities of some com-binations of the network components. The incompatibilities lead us to rule out the138 cases, which are the rows in gray color and italic font in Table 7.2. The followingreasons for disallowing various cases are referred in the table.

R1 Use of SIMs to access the 4G network is not allowed [8].

R2 A 2G ME cannot interoperate with a 3G or 4G BS [1].

R3 A 3G ME does not support the 4G radio access interface [1].

R4 A 2G MSC cannot control a 3G or 4G BS [1].

R5 A 3G MSC cannot control a 4G BS [1].

R6 An MME refuses to convert a GSM security context to 4G security context.Consequently, this rules out all interoperation cases which would require thederiving of the master key KASME from the GSM cipher key Kc [8].

R7 A 3G ME with USIM attaching to a 3G BS shall only participate in 3G AKAand shall not participate in 2G AKA [7]. This rules out the case in which aUSIM subscribed to a 2G HN is used in a 3G ME that connects to a 3G BS, asthe 2G HN can only support 2G AKA.

7.4 Uncertain Interoperation Cases

The 3GPP specifications do not provide indication as to whether or not the remain-ing 48 cases are allowable. These cases are marked in green color and bold font inTable 7.2. For those cases, Table 7.2 refers to these conditions under which they couldoccur:

A1 An MME can control a 3G BS or a 2G BS.

A2 A 3G HN or 2G HN can maintain 4G subscriptions.

A3 A 4G HN can maintain 2G subscriptions.

A4 An MME can support the 2G or 3G AKA.

76

These assumptions are inferred from the facts that listed in previous sections. A1,A3, and A4 are assumed based on the assumption that the components of latertechnologies supports the functionality of the corresponding components in earliertechnologies. A2 is assumed based on the fact that a 2G HN can maintain 3G sub-scriptions.

77

Chapter 8Modeling and Analysis of Interoperation Scenarios involving GSM andUMTS Procedures Only

This chapter begins our investigation of interoperation scenarios, i.e., hybrid proce-dures built from blocks from two different generations. It concentrates on the casesonly involving GSM and UMTS components. The interoperation scenarios of thesecases involve GSM and UMTS blocks only. These cases and scenarios are explicitlyspecified in the 3GPP specification [1]. Just like the pure protocols (Chapters 3–5),each scenario is presented as message sequence charts and provided with the modeland analysis.

In Chapter 9, we complete the picture by considering cases that involve someLTE components. Some of those cases fall into the scenarios in this chapter or intothe pure AKAs. Others require additional scenarios to be given in Chapter 9. Thisorganization is intended to break the analysis and results into digestible parts.

8.1 Determining the Scenarios only involving GSM and UMTS Compo-nents

In this section, we list the reasons to determine what AKA scenarios will occur for eachcase. We list all scenarios for the cases only involving GSM and UMTS components.Some of the scenarios are the pure case AKAs. We discuss the remaining threescenarios in the following sections.

The interoperation scenarios involving GSM and UMTS components have beenstudied in [1, 76, 87]. In order to determine a suitable AKA for a specific interoper-ation case, first we determine which messages should be in the first block. The AKAmight be triggered by initial network request or Routing Area Request (RAU ). Nomatter which message triggers the AKA, the first block always contains the transmit-ting of the IMSI and CAP as in GSM I or UMTS I. In fact, from the security pointof view, the GSM I and the UMTS I are equivalent to each other.

Second, we consider the authentication vector that is generated in the HN andsubsequently provided to the MSC. How and what kind of authentication vector isgenerated by the HN depends on HN’s capabilities, the type of MSC requesting/re-ceiving the authentication vector, the type of BS, and the type of the identity module.

Third, the authentication vector determines what kind of challenge-responseprocedure is carried out.

Fourth, we consider the type of the BS, which determines the type of thesecurity mode setup procedure. Depending on the type of BS it controls, the MSCmight have to convert the encryption/integrity keys.

Table 8.1 gives the reasoning we used to determine the AKA scenarios. To be

78

Table 8.1: Reasons used for determining AKA scenarios (see Table 9.1 for full set)

Type of AV

C Upon request by a 3G MSC, the 3G HN generates and sends out 3G AVs [7, Section 6.3.2Page 21-23].

D Upon request by a 2G MSC with a 3G IMSI, the 3G HN generates 2G AVs from 3G AVs [1,Section 6.1 Case 4 Page13, Page 30-32].

E 2G HN only supports to generate 2G AVs [1, Section 4.4 Page 9].F Upon request by a MSC with a 2G IMSI, the 3G HN always generates and delivers the 2G

AVs [1, Section 6.3.1 Page 19, Page 30-32].

Type of BSH 3G BS only supports 3G SMC [1, Section 6.3.1 Case 1 Page 20].I 2G BS only supports 2G SMC [1, Section 6.1 Case 2 Page 13].

Type of MEK XG ME supports XG SMC [8, 7, Section 7.2.4.5 Page 33, TS 33.102 Section 6.4.5 Page 31-33]L 3G ME supports 2G SMC [1, Section 6.1 Case 2 Page 13].

ConversionM The 3G BS requires CK and IK, the MSC generates them from Kc by applying conversion

function c3 [1, Section 6.3.1 Case1 Page 20].N 2G BS is not capable of handling of cipher and integrity keys. The MSC converts the CK

and IK into Kc [1, Section 6.1 Case 2 Page 13].First Block V Triggered by attach request or RAU request, the first block is GSM I or UMTS I [4, Section

6.5], [5, Section 5.3.3]

consistent with the labels for the reasons to determine the scenarios of interoperationcases involving LTE components (Chapter 9), We use the same labels as in the fulltable (Table 9.1) in Chapter 9. Based on the reasoning, we categorize the cases into5 distinct scenarios, which are consistent with the scenarios in [1, 76]:

S1 GSM authentication.

S2 UMTS AKA.

S4 A UMTS MS roams to an SN with a GSM BS and GSM MSC.

S5 A GSM MS roams to an SN with a UMTS BS and UMTS MSC.

S6 A UMTS MS roams to an SN with a GSM BS and a UMTS MSC.

To be consistent with the labels of the complete scenarios of the interoperation casesinvolving LTE components (Chapter 9), we use the same labels for the scenarios. Inthe description of the scenarios, a UMTS MS means that an MS uses a USIM smartcard and its home network is 3G HN; a GSM MS means that an 2G ME equippedwith a SIM.

Table 8.2 shows the authentication scenarios of the interoperation cases in-volving GSM and UMTS components only including the rationale which refers toTable 8.1. Scenarios S1 and S2 have been discussed in Chapter 3 and 4, and we usethe name S3 for pure LTE (Chapter 5). The remaining three scenarios S4–S6 will bediscussed in the following sections.

79

Table 8.2: Classifying the interoperation cases involving GSM and UMTS componentsonly. (The reasons are in Table 8.1)

IDComponents

Scenario ReasonIdentityModule

ME BS MSC HN

122

3G 3G

3G 3G 3G S2 CHKV123 2G 3G 3G S6 CILNV126 2G 2G 3G S4 DILV132 2G 3G 2G S1 EILV135 2G 2G 2G S1 EILV150

3G 2G

2G 3G 3G S6 CIKNV153 2G 2G 3G S4 DIKV159 2G 3G 2G S1 EIKV162 2G 2G 2G S1 EIKV203

2G 2G

3G 3G 3G S5 FHKMV204 2G 3G 3G S1 FILV207 2G 2G 3G S1 FILV212 3G 3G 2G S5 EHKMV213 2G 3G 2G S1 EILV216 2G 2G 2G S1 EILV231

2G 2G

2G 3G 3G S1 FIKV234 2G 2G 3G S1 FIKV240 2G 3G 2G S1 EIKV243 2G 2G 2G S1 EIKV

8.2 Scenario S4: A UMTS MS roams to an SN with a GSM BS and GSMMSC

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

8.2.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM and UMTS diagrams.

Figure 8.1 shows the authentication scenario. The MS sends its identity andcapabilities to the SN as in the GSM I in Figure 3.2. The GSM SN then requestsauthentication vectors from the UMTS HN by sending the MS’s identity. Because theSN can only support GSM authentication vectors (authentication triplets), the HN

80

GSM I

UMTS MS UMTS HN GSM BS, GSM MSC

IMSI

RAND, XRES_G, KC

Generate RAND & SQN MAC = f1(Ki, AMF, SQN, RAND)

XRES_U = f2(Ki, RAND), CK = f3(Ki, RAND) IK = f4(Ki, RAND), AK = f5(Ki, RAND)

AUTN = SQNAK || AMF || MAC XRES_G=c2(XRES_U), KC = c3(CK, IK)

RAND

RES_G

Verify RES_G = XRES_G

RES_U = f2(Ki, RAND), CK =f3(Ki, RAND) IK = f4(Ki, RAND), RES_G=c2(RES_U), KC = c3(CK, IK)

GSM IV

Figure 8.1: UMTS subscriber roams into GSM network

produces authentication triplets with conversion functions. In this case, the UMTSCK and IK are converted into the GSM cipher key Kc, and the expected response isalso converted by the function c2. Upon receiving the challenge from the GSM SN,the MS applies the same conversion functions to derive the GSM encryption key Kcand the response. The SN then verifies that the received response is the same as theexpected response. This is followed by the remainder of the standard GSM IV.

The goal of this scenario is to authenticate the MS and to establish an encryp-tion key that can then be used to protect the user data. This scenario is prone to thefalse base station attack as the GSM cipher command is not integrity protected anddoes not include the MS’s CAP.

8.2.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S4_GSM_I-IV_convert(3GAV-2GAV).pv.

Figure 8.2 augments the protocol diagram of Figure 8.1 with details of theProVerif model and shows the locations of the events which are used to specify au-thentication properties. Most of the code in this model is inherited from the GSMmodel and the UMTS model. The conversion functions are defined as:

fun c2 ( r e s p ) : r e s p .fun c3 ( c ipherKey , i n t egKey ) : s e s sKey .

Since the SN only supports GSM authentication, the events and queries are specifiedthe same way as in GSM authentication (Section 3.3). The three processes represent-

81

UMTS MS UMTS HN

2. IMSI

1. CAP

GSM BS, GSM MSC

event endSN(imsi_hn_sn, kc_sn)

event begSN(imsi_ms, kc_ms)

event begMS(imsi_hn_sn, kc_sn)

event endMS(imsi_ms, kc_ms)

7. Selected algorithms

Decide whether to use encryption

9. payload, if no encryption {payload}_kc_sn, otherwise

Decrypt message if enableEnc_ms is true

if cap_sn is false event disableEnc

3. IMSI

4. RAND, XRES_G, KC

Generate RAND & SQN MAC = f1(Ki, AMF, SQN, RAND)

XRES_U = f2(Ki, RAND), CK = f3(Ki, RAND) IK = f4(Ki, RAND), AK = f5(Ki, RAND)

AUTN = SQNAK || AMF || MAC XRES_G=c2(XRES_U), KC = c3(CK, IK)

5. RAND

6. RES_G

Verify RES_G = XRES_G

RES_U = f2(Ki, RAND), CK =f3(Ki, RAND) IK = f4(Ki, RAND), RES_G=c2(RES_U), KC = c3(CK, IK)

GSM

I U

MT

S II’ G

SM III’

GSM

IV

8. CMC Complete

Figure 8.2: UMTS subscriber roams into GSM network, annotated in accord withour model

ing the MS, the SN, and the HN respectively are defined as follows. The commentsrefer to message numbers in Figure 8.2.

1 (∗ Proce s s r e s p r e s e n t i n g MS ∗)2 l e t processMS =3 new ims i ms : i d e n t ;4 new k i : key ;5 i n s e r t keys ( ims i ms , k i ) ;6 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n7 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)8 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)9 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)

10 l e t r e s ms u : r e s p = f2 ( k i , rand ms ) i n11 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n12 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n13 l e t r e s ms g : r e s p = c2 ( r e s ms u ) i n14 l e t kc ms : s e s sKey = c3 ( ck ms , i k ms ) i n15 event begSN ( ims i ms , kc ms ) ;16 out ( pubChannel , (RES , r e s ms g ) ) ; (∗ [Msg 6 ] ∗)

82

17 i n ( pubChannel , (=CMC, enab leEnc ms : bool ) ) ; (∗ [Msg 7 ] ∗)18 event endMS( ims i ms , kc ms ) ;19 out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)20 i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)21 out ( pubChannel , s e n c r y p t ( sec r e tKc , kc ms ) ) ;22 i f enab leEnc ms = t r u e then23 l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n24 0 .25

26 l e t processSN =27 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)28 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)29 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)30 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,31 x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)32 out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)33 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)34 i f r e s s n = x r e s s n then35 event endSN( ims i hn sn , k c sn ) ;36 event begMS( ims i hn sn , k c sn ) ;37 out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)38 i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)39 i f cap sn = f a l s e then40 event d i s a b l eEn c ;41 out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)42 e l s e43 out ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) . (∗ [Msg 9 ] ∗)44

45 l e t processHN =46 i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)47 new rand hn : nonce ;48 get keys (= ims i hn , k i h n ) i n49 l e t mac hn : mac = f1 ( k i hn , rand hn ) i n50 l e t x r e s h n u : r e s p = f2 ( k i hn , rand hn ) i n51 l e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i n52 l e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i n53 l e t x r e s h n g : r e s p = c2 ( x r e s h n u ) i n54 l e t kc hn : s e s sKey = c3 ( ck hn , i k hn ) i n55 out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn g , kc hn ) ) .

The MS converts the response and the keys in lines 13–14. Similarly, in lines 53–54,the process of the HN converts the response and the keys.

8.2.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

We specify the security properties as following:

• Key Secrecy (secrecy of Ki and Kc)

83

Table 8.3: Analysis result of S4 modelKey

SecrecyConditional

Payload SecrecyAuthentication ofthe MS to the SN

PayloadSecrecy

Authentication ofthe SN to the MS

Proved Proved Proved Failed Failed

1 not attacker (new k i ) .2 query attacker ( s e c r e tKc ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Authentication of the MS to the SNquery i d : i d en t , k : s e s sKey ; event ( endSN( id , k ) ) event ( begSN ( id , k ) ) .

• Authentication of the SN to the MSquery i d : i d en t , k : s e s sKey ; event (endMS( id , k ) ) event (begMS( id , k ) ) .

• Payload Secrecyquery attacker ( pay load ) .

The analysis results are the same as in GSM authentication (Section 3.3).Table 8.3 shows the analysis result of the above properties. Proverif fails and findsan attack against the authentication of the SN to the MS. In this attack, the attackerimpersonates as a false BS and feeds the MS with arbitrary challenge and encryptionoption. ProVerif finds a similar man-in-the-middle attack as in the GSM modelwhen checking payload secrecy. The attack trace shows that the attacker interceptsthe message that contains the MS’s capabilities and changes them to no-encryption,which forces the SN to choose not to encrypt the payload.

8.3 Scenario S5: A GSM MS roams to an SN with a UMTS BS andUMTS MSC

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

8.3.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM and UMTS diagrams.

The components of the scenario shown in Figure 8.3 exchange messages fol-lowing the GSM I, II, and III (see Figure 3.2). In this case, the UMTS BS forwardsall GSM traffic transparently. The GSM encryption key K c is then expanded to CKand IK using conversion functions both in the SN and in the MS. The MS and theSN then follow the steps of UMTS IV (Figure 4.2). The goal of this scenario is toprovide for mutual authentication between the MS and the SN and to establish anencryption key that can then be used to protect the user data.

84

MS HN

GSM III

GSM II

BS

GSM I

MSC

CK = c4(Kc) IK = c5(Kc)

CK = c4(Kc) IK = c5(Kc)

UMTS IV

Figure 8.3: GSM MS roams into UMTS network

8.3.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S5_GSM_I-III_UMTS_IV.pv.

Figure 8.4 provides details of the ProVerif model and shows the locations ofthe events which are used to specify authentication properties. Most of this model’scode is also inherited from the GSM model and the UMTS model. The conversionfunctions are defined as:

fun c4 ( se s sKey ) : c i phe rKey .fun c5 ( se s sKey ) : i n t egKey .

Since the SN authenticates the MS as in the GSM AKA, the events begSN and endSN

use the GSM session key as one parameter. The MS authenticates the SN as in UMTSauthentication, and the events begMS and endMS use UMTS keys as parameters. Theevents are declared as:

event begSN ( iden t , s e s sKey ) .event endSN( iden t , s e s sKey ) .event begMS( iden t , c ipherKey , i n t egKey ) .event endMS( iden t , c ipherKey , i n t egKey ) .

To specify the secrecy properties of the GSM session key Kc, the UMTS cipher keyCK , and the UMTS integrity key IK , we declare a secret (the technique is discussedin Section 3.2.1):

f r ee s e c r e t : b i t s t r i n g [ pr i va te ] .

The secret is encrypted under the Kc, the CK , and the IK respectively and is sentout over the public channel.

The MS process and the SN process are specified as follows. The commentsrefer to message numbers in Figure 8.4.

85

GSM MS GSM HN

5. RAND

6. RES

3. IMSI

4. IMSI, RAND, XRES, KC

2. IMSI

1. CAP

7. enableEnc, CAP, FRESH, MAC-I

UMTS BS, UMTS MSC

res_ms = a3(rand_ms, Ki) kc_ms = a8(rand_ms, Ki)

Verify res_sn = xres_sn

Decide whether to use encryption Generate fresh_sn

MAC-I_sn = f9((enableEnc_sn, cap_sn, fresh_sn), ik_sn)

Generate rand_hn xres_hn = a3(rand_hn, Ki) kc_hn = a8(rand_hn, Ki)

event endSN(imsi_hn_sn, kc_sn)

event begSN(imsi_ms,kc_ms)

event begMS(imsi_hn_sn, ck_sn, ik_sn, cap_sn)

ck_ms = c4(kc_ms) ik_ms = c5(kc_ms)

ck_sn = c4(kc_sn) ik_sn = c5(kc_sn)

event endMS(imsi_ms, ck_ms, ik_ms, cap_ms)

Verify cap_ms = cap_sn_ms and MAC-I

9. payload, FRESH, MAC, if no encryption {payload}_ck_sn, FRESH, MAC, otherwise

Verify MAC, decrypt message if alg_ms supports encryption

if enableEnc_sn is false event disableEnc

GSM

I G

SM II

GSM

III U

MT

S IV

8. SMC complete, MAC-I

Verify MAC-I

Figure 8.4: GSM subscriber roams into UMTS network annotated in accord with ourmodel

1 l e t processMS =2 new ims i ms : i d e n t ;3 new k i : key ;4 i n s e r t keys ( ims i ms , k i ) ;5 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n6 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)7 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)8 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)9 l e t r e s ms : r e s p = a3 ( rand ms , k i ) i n

10 l e t kc ms : s e s sKey = a8 ( rand ms , k i ) i n11 event begSN ( ims i ms , kc ms ) ;

86

12 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)13 l e t ck ms : c i phe rKey = c4 ( kc ms ) i n14 l e t i k ms : i n t egKey = c5 ( kc ms ) i n15 i n ( pubChannel , (=SMC, enab leEnc ms : bool , =cap ms , f r e s h ms : nonce ,16 =f9 ( ( enableEnc ms , cap ms , f r e s h ms ) , i k ms ) ) ) ; (∗ [Msg 7 ] ∗)17 event endMS( ims i ms , ck ms , ik ms , cap ms ) ;18 out ( pubChannel , ( SMComplete , f 9 ( smcompleteMsg , i k ms ) ) ) ;19 (∗ [Msg 8 ] ∗)20 i n ( pubChannel , (=MSG, msg : b i t s t r i ng , f r e sh msg ms : nonce ,21 =f9 ( (msg , f r e sh msg ms ) , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)22 out ( pubChannel , s e n c r y p t S e s s ( s e c r e t , kc ms ) ) ;23 out ( pubChannel , s e n c r y p t ( sec r e tCk , ck ms ) ) ;24 out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;25 i f enab leEnc ms = t r u e then26 l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , ck ms ) i n 0 .27

28 l e t processSN =29 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)30 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)31 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)32 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,33 x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)34 out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)35 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)36 i f r e s s n = x r e s s n then37 event endSN( ims i hn sn , k c sn ) ;38 l e t ck sn : c i phe rKey = c4 ( kc sn ) i n39 l e t i k s n : i n t egKey = c5 ( kc sn ) i n40 new f r e s h s n : nonce ;41 event begMS( ims i hn sn , ck sn , i k s n , cap sn ) ;42 out ( pubChannel , (SMC, cap sn , cap sn , f r e s h s n ,43 f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 7 ] ∗)44 i n ( pubChannel , (=SMComplete , =f9 ( smcompleteMsg , i k s n ) ) ) ;45 (∗ [Msg 8 ] ∗)46 new f r e s h msg s n : nonce ;47 i f cap sn = f a l s e then48 event d i s a b l eEn c ;49 out ( pubChannel , (MSG, pay load , f r e s h msg sn ,50 f 9 ( ( pay load , f r e s h msg s n ) , i k s n ) ) ) (∗ [Msg 9 ] ∗)51 e l s e52 out ( pubChannel , (MSG, s e n c r y p t ( pay load , ck sn ) , f r e s h msg sn ,53 f 9 ( ( s e n c r y p t ( pay load , ck sn ) , f r e s h msg s n ) , i k s n ) ) ) .54 (∗ [Msg 9 ] ∗)

The HN process is the same as the HN process in the GSM model. The MS convertsthe CK and IK from GSM cipher key Kc in lines 13–14, and the SN converts themin lines 38-39.

87

Table 8.4: Analysis result of S5 modelKey

SecrecyConditional

Payload SecrecyAuthentication ofthe MS to the SN

PayloadSecrecy

Authentication ofthe SN to the MS

Proved Proved Proved Failed Proved

8.3.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

The secrecy and authentication properties are specified as:

• Key Secrecy (secrecy of Ki, Kc, CK, and IK)not attacker (new k i ) .query attacker ( s e c r e t ) .query attacker ( s e c r e tCk ) .query attacker ( s e c r e t I k ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Mutual Authentication between the MS and the SNquery d : i d en t , k : s e s sKey ; event ( endSN(d , k ) ) event ( begSN (d , k ) ) .query d : i d en t , c : c ipherKey , i : i n t egKey ;

event (endMS(d , c , i ) ) event (begMS(d , c , i ) ) .

• Payload Secrecyquery attacker ( pay load ) .

Table 8.4 shows the analysis result of the above properties. As expected, the payloadsecrecy property fails. The attack trace found by ProVerif shows that the attackerintercepts and modifies the encryption capability of the MS to no capability of en-cryption, thus forcing the SN to choose not to enable encryption and to send outpayload in clear text. The attacker can at least learn the contents of the first messagesent by the SN.

8.4 Scenario S6: A UMTS MS roams to an SN with a GSM BS and aUMTS MSC

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

88

MS HN

UMTS III

UMTS II

BS

UMTS I

MSC

Kc = c3(CK, IK) Kc = c3(CK, IK)

GSM IV

Figure 8.5: UMTS subscriber roams into mixed network [94, 76]

8.4.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM and UMTS diagrams.

The scenario in which a UMTS MS roams to an SN with a GSM BS and aUMTS MSC is shown in Figure 8.5. Since the MS and UMTS MSC support theUMTS I, II, and III (shown in Figure 4.2), these three blocks of message exchangesare executed. The GSM BS forwards the traffic transparently. Because this roamingscenario uses the GSM BS, the CK and IK are not supported. A conversion functionhas to be used both in the MS and in the SN to generate the GSM encryption keyKc. Since the GSM BS does not support the SMC procedure of the UMTS, the MSand the SN proceed with GSM IV from Figure 3.2. The goal of this scenario is toprovide for mutual authentication between the MS and the SN and to establish anencryption key that can then be used to protect the user data.

8.4.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S6_UMTS_I-III_GSM_IV.pv.

Building on the protocol diagram of Figure 8.5, Figure 8.6 shows details of theProVerif model and the locations of the events which are used to specify authentica-tion properties.

Once again, most of this model’s code is inherited from the GSM model andthe UMTS model. The conversion function is defined as:

fun c3 ( c ipherKey , i n t egKey ) : s e s sKey .

Since the SN authenticates the MS as in UMTS authentication, the events begSN andendSN use UMTS keys in the authentication property specification. The events aredeclared as:

89

UMTS MS UMTS HN

5. RAND, AUTN

6. RES

3. IMSI

4.IMSI, RAND, XRES, CK, IK, AUTN

2. IMSI

1. CAP

GSM BS, UMTS MSC

Verify res_sn = xres_sn

event endSN(imsi_hn_sn, ck_sn, ik_sn)

event begSN(imsi_ms,ck_ms, ik_ms)

kc_ms = c3(ck_ms, ik_ms) kc_sn = c3(ck_sn, ik_sn)

8. payload, if no encryption {payload}_kc_sn, otherwise

Decrypt message if enableEnc_ms is true

Generate rand_hn, Compute mac_hn, xres_hn, ck_hn, ik_hn and autn_hn

Compute res_ms, ck_ms, ik_ms, xmac_ms Verify mac_ms=xmac_ms

UM

TS I

UM

TS II

UM

TS III

GSM

IV

event begMS(imsi_hn_sn, kc_sn)

event endMS(imsi_ms, kc_ms)

7. Selected algorithms

Decide whether to use encryption

if cap_sn is false event disableEnc

8. CMC Complete

Figure 8.6: UMTS subscriber roams into mixed network annotated in accord withour model

event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , s e s sKey ) .event endMS( iden t , s e s sKey ) .

Similar to previous cases, we use a secret to specify the secrecy of the Kc, the CKand the IK .

The MS process and the SN process are defined as follows. The commentsrefer to message numbers in Figure 8.6.

1 l e t processMS =2 new ims i ms : i d e n t ;3 new k i : key ;4 i n s e r t keys ( ims i ms , k i ) ;5 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n6 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)7 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)

90

8 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , mac ms : mac ) ) ;9 (∗ [Msg 5 ] ∗)

10 i f f 1 ( k i , rand ms ) = mac ms then11 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n12 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n13 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n14 event begSN ( ims i ms , ck ms , i k ms ) ;15 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)16 l e t kc ms : s e s sKey = c3 ( ck ms , i k ms ) i n17 i n ( pubChannel , (=CMC, enab leEnc ms : bool ) ) ; (∗ [Msg 7 ] ∗)18 event endMS( ims i ms , kc ms ) ;19 out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)20 i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)21 out ( pubChannel , s e n c r y p t ( sec r e tKc , kc ms ) ) ;22 out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;23 out ( pubChannel , s e n c r y p tC i p h e r ( sec r e tCk , ck ms ) ) ;24 i f enab leEnc ms = t r u e then25 l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n 0 .26

27 (∗ Proce s s r e s p r e s e n t i n g SN ∗)28 l e t processSN =29 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)30 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)31 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)32 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,33 x r e s s n : re sp , c k sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ;34 (∗ [Msg 4 ] ∗)35 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)36 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)37 i f r e s s n = x r e s s n then38 event endSN( ims i hn sn , ck sn , i k s n ) ;39 l e t kc sn : s e s sKey = c3 ( ck sn , i k s n ) i n40 event begMS( ims i hn sn , k c sn ) ;41 out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)42 i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)43 i f cap sn = f a l s e then44 event d i s a b l eEn c ;45 out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)46 e l s e47 out ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) .48 (∗ [Msg 9 ] ∗)

The HN process is the same as the HN process in the UMTS model. The MS convertsthe GSM cipher key Kc from CK and IK in line 16, and the SN converts it in line39.

8.4.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

91

Table 8.5: Analysis result of S6 modelKey

SecrecyConditional

Payload SecrecyAuthentication ofthe MS to the SN

PayloadSecrecy

Authentication ofthe SN to the MS

Proved Proved Proved Failed Failed

The secrecy and authentication properties are specified as:

• Key Secrecy (secrecy of Ki, Kc, CK, and IK)not attacker (new k i ) .query attacker ( s e c r e tKc ) .query attacker ( s e c r e tCk ) .query attacker ( s e c r e t I k ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Mutual Authentication between the MS and the SN1 query d : i d en t , c : c ipherKey , i : i n t egKey ;2 event ( endSN(d , c , i ) ) event ( begSN (d , c , i ) ) .3 query d : i d en t , k : s e s sKey ; event (endMS(d , k ) ) event (begMS(d , k ) ) .

• Payload Secrecyquery attacker ( pay load ) .

Table 8.5 shows the analysis result of the above properties. The query of payloadsecrecy fails and ProVerif finds a trace similar to the one we describe for the samequery against the GSM (Section 3.3). The attacker intercepts and modifies the en-cryption capability of the MS to no capability of encryption, thus forcing the SN tochoose not to encrypt the payload and send out it in clear text.

What is interesting is that the required authentication of the SN to the MS(the query in line 3 of the mutual authentication between the MS and the SN) isviolated and yields the following attack trace:

1 new ims i ms c r e a t i n g ims i ms 12 new k i c r e a t i n g k i 23 i n s e r t keys ( ims i ms 1 , k i 2 )4 out ( pubChannel , (CAP, t r u e ) )5 out ( pubChannel , ( ID , ims i ms 1 ) )6 i n ( pubChannel , (CAP, f a l s e ) )7 i n ( pubChannel , ( ID , ims i ms 1 ) )8 out secu r eChanne l , (AV REQ , ims i ms 1 ) )9 new rand hn c r e a t i n g rand hn 3

10 get keys ( ims i ms 1 , k i 2 )11 out secu r eChanne l , (AV, ims i ms 1 , rand hn 3 , f 2 ( k i 2 , r and hn 3 ) ,12 f 3 ( k i 2 , r and hn 3 ) , f 4 ( k i 2 , r and hn 3 ) , f 1 ( k i 2 , r and hn 3 ) ) )13 out ( pubChannel , (CHALLENGE, rand hn 3 , f 1 ( k i 2 , r and hn 3 ) ) )14 i n ( pubChannel , (CHALLENGE, rand hn 3 , f 1 ( k i 2 , r and hn 3 ) ) )15 event ( begSN ( ims i ms 1 , f 3 ( k i 2 , r and hn 3 ) , f 4 ( k i 2 , r and hn 3 ) ) )16 out ( pubChannel , (RES , f 2 ( k i 2 , r and hn 3 ) ) )17 i n ( pubChannel , (CMC, f a l s e ) )18 event (endMS( ims i ms 1 , c3 ( f 3 ( k i 2 , r and hn 3 ) , f 4 ( k i 2 , r and hn 3 ) ) ) )

92

In the attack trace, the attacker first acts as a BS to intercept the capability messageand replace it with no-encryption. The attacker forwards the challenge and responsemessages to the MS and the BS. Since there is no integrity protection, the attackerforges the CMC message and sends it to the MS. That means the MS can receivethe CMC message without executing the event in line 40 in the SN process. As aresult, the correspondence assertion event(endMS(d,k)) event(begMS(d,k)) is violated byexecuting the event endMS without previously executing the event begMS.

93

Chapter 9Modeling and Analysis of Scenarios involving LTE Procedures

In this chapter, we determine the authentication scenarios of the cases involving LTEsystem components (Section 9.1). Some cases fall into pure AKAs (Chapter 3–5).Other cases fall into scenarios introduced in Chapter 8 which use only blocks fromthe GSM and UMTS AKAs. The remaining cases fall into scenarios that use protocolblocks from LTE; those scenarios are discussed in this chapter. Just like the previouschapters, each scenario is presented as message sequence charts and provided withthe model and analysis (Sections 9.2–9.5). Table 9.2 gives complete classification forall interoperation cases of 3 generations (including what is in Table 8.2).

9.1 Determining the Scenarios involving LTE Components

In this section, we list the reasons to determine what authentication scenarios occurfor each case. It turns out there are 10 distinct authentication scenarios. 3 of themare the native GSM, UMTS, and LTE AKAs. Chapter 8 discussed 3 interoperationauthentication scenarios involving GSM and UMTS procedures only. The remaining4 scenarios will be discussed in the following sections.

We follow the same rationale as in Section 8.1 to determine the authenticationscenario block by block for each case. First we consider which message might trig-ger the AKA to determine the messages transmitted in the first block. Second, weconsider what kind of authentication vector should be generated and subsequentlyprovided to the MSC/MME in the second block. The kind of authentication vectoris depend on the type and capabilities of the HN, the MSC, the BS, and the identitymodule. Third, we consider the challenge response procedure, which is determinedby the kind of authentication vector, in the third block. Fourth, we consider whetherthe NAS SMC procedure is possible for the cases containing the MME as one com-ponent. If it is possible, we consider if the NAS SMC procedure is optional. If it isoptional, we check both possibilities. Fifth, we consider the type of the BS, whichdetermines the type of the security mode setup procedure. Depending on the type ofBS it controls, the MSC/MME might have to convert the encryption/integrity keys.Table 9.1 provides the detailed reasons.

Using this approach, we categorize the allowable and uncertain interoperationcases involving LTE system components into 10 distinct scenarios:

S1 GSM I–IV.

S2 UMTS I–IV.

S3 LTE I–V.

94

Table 9.1: Reasons used for determining AKA scenarios

Type of AV

A Upon request by an MME with network type equals E-UTRAN, the 4G HN generates anddelivers the 4G AVs (separation bit = 1) [8, Section 6 Page 20-21].

B Upon request by an MME with network type equals UTRAN or GERAN, the 4G HN gen-erates and delivers the 4G AVs, plus CK and IK (separation bit = 0) [8, Section 6 Page20-21].

C Upon request by a 3G VLR/SGSN, the 3G HN generates and sends out 3G AVs [7, Section6.3.2 Page 21-23].

D Upon request by a 2G VLR/SGSN with a 3G IMSI, the 3G HN generates 2G AVs from 3GAVs [1, Section 6.1 Case 4 Page13, Page 30-32].

E 2G HN only supports to generate 2G AVs [1, Section 4.4 Page 9].F Upon request by a VLR/SGSN/MME with a 2G IMSI, the 3G HN always generates and

delivers the 2G AVs [1, Section 6.3.1 Page 19, Page 30-32].O Upon request by a 3G VLR/SGSN, the 4G HN generates 3G AVs [8, Section 6.1.2 Page 21,

or derived from D].P Upon request by a 2G VLR/SGSN with 3G/4G IMSI, the 4G HN generates 2G AVs from

UMTS AVs [Derived from D].Q Upon request by an MME, the 3G HN generates 3G AVs [1, Section 6.1 Case 5 Page 14,

Section 6.2.2 Case 6 Page 18, and derived from E].R Upon request by a 2G VLR/SGSN with a 4G IMSI, the 3G HN generates 2G AVs from 3G

AVs [Derived from D].S Upon request by a VLR/SGSN/MME with a 2G IMSI, the 4G HN always generates and

delivers the 2G AVs [Derived from F].

Type of BSG 4G BS only supports 4G SMC [8, Section 7.2.4.5 Page 33].H 3G BS only supports 3G SMC [1, Section 6.3.1 Case 1 Page 20].I 2G BS only supports 2G SMC [1, Section 6.1 Case 2 Page 13].

Type of ME

J The 4G ME supports to derive KASME and store the security contexts. [6, Section 5.4.2.1Page 61]

K XG ME supports XG SMC [8, Section 7.2.4.5 Page 33],[7, Section 6.4.5 Page 31-33]L 3G ME supports 2G SMC [1, Section 6.1 Case 2 Page 13].T 4G ME supports 2G/3G SMC [Derived from L]

ConversionM The 3G BS requires CK and IK, the VLR/SGSN/MME generates them from Kc by applying

conversion function c3 [1, Section 6.3.1 Case 1 Page 20].N 2G BS is not capable of handling of cipher and integrity keys. The VLR/SGSN/MME

converts the CK and IK into Kc [1, Section 6.1 Case 2 Page 13].U Because the 4G BS requires KeNB , which is derived from the KASME , the VLR/SGSN/MME

generates KASME from the CK, IK and sends it to the BS [Derived from M] or [8, Section9.1.2 Page 51].

First BlockV Triggered by attach request or RAU request, the first block is GSM I or UMTS I [4, Section

6.5], [5, Section 5.3.3]W Triggered by LTE attach request or TAU request in which the nonce is never used, the first

block is LTE I [8, Section 9.1.2].X Triggered by TAU request and the nonce is used in latter blocks, the first block is LTE I’ [5,

Section 8.2.4.1], [52, Section 11.1.2].

S4 GSM I ‖ UMTS II’ ‖ GSM III’–IV, conv(3G AV → 2G AV).

S5 GSM I–III ‖ UMTS IV, conv(Kc → CK IK , VLR/SGSN).

S6 UMTS I–III ‖ GSM IV, conv(CK IK → Kc, VLR/SGSN).

S7 LTE I ‖ UMTS II–III ‖ [optionally, LTE IV] ‖ LTE V, conv(CK IK → KASME ,MME).

S8 LTE I’ ‖ UMTS II–III ‖ LTE IV–V, conv(CK IK nonces → KASME , MME).

95

S9 GSM I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ GSM IV, conv(CK IK → Kc,MME), AV = 4G AV + CK + IK.

S10 UMTS I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ UMTS IV, AV = 4G AV + CK+ IK.

The blocks are as introduced in Figs. 3.2, 4.2, and 5.2. With notation “a ‖ b” weindicate that block b follows after block a.

Scenarios S7, S9, and S10 have blocks marked in brackets as optional. It isconsistent with the specifications to either include or omit these blocks, so we analyzeversions with and without the block.

The notation “conv(K 1 → K 2, C)” denotes that network component C con-verts key K 1 into K 2. Furthermore, “AV = 4G AV + CK + IK” indicates that the4G HN provides not only the 4G authentication vector to the MME but also includesthe UMTS encryption key CK and integrity key IK. S1–S3 are the pure cases andare discussed in Chapter 3–5. Scenarios S4–S6 coincide with scenarios described inChapter 8.

In Table 9.2, we determine and categorize the AKA for all of the allowedand uncertain cases involving LTE system components, including the rationale whichrefers to Table 9.1.

Table 9.2: Classifying the interoperation cases (for GSM,UMTS, and LTE)

IDComponents

ScenarioReason

IdentityModule

ME BS MSC/MME

HNStated in

specInterpretation

1 4G 4G 4G S3 AGKW2 3G 4G 4G S10 BHV T3 2G 4G 4G S9 BINV T5 3G 3G 4G S2 HV OT6 2G 3G 4G S6 INV OT9 2G 2G 4G S4 IV PT

10 4G 4G 3G S7/8 GKWX QT11 3G 4G 3G S2 HV QT12 4G 4G 2G 4G 3G S6 INV QT14 3G 3G 3G S2 CHV T15 2G 3G 3G S6 CINV T18 2G 2G 3G S4 IV RT20 3G 4G 2G S5 EHMV T21 2G 4G 2G S1 EIV T23 3G 3G 2G S5 EIV T24 2G 3G 2G S1 EIV T27 2G 2G 2G S1 EIV T

96

Table 9.2: Classifying the interoperation cases (for GSM,UMTS, and LTE)

IDComponents

ScenarioReason

IdentityModule

ME BS MSC/MME

HNStated in

specInterpretation

29 3G 4G 4G S10 BHKV30 2G 4G 4G S9 BILNV32 3G 3G 4G S2 HKV O33 2G 3G 4G S6 ILNV O36 2G 2G 4G S4 ILV P38 3G 4G 3G S2 HKV Q39 2G 4G 3G S6 ILNV Q41 4G 3G 3G 3G 3G S2 CHKV42 2G 3G 3G S6 CILNV45 2G 2G 3G S4 ILV R47 3G 4G 2G S5 EHKMV48 2G 4G 2G S1 EILV50 3G 3G 2G S5 EHKMV51 2G 3G 2G S1 EILV54 2G 2G 2G S1 EILV57 2G 4G 4G S9 BIKNV60 2G 3G 4G S6 IKNV O63 2G 2G 4G S4 IKV P66 2G 4G 3G S6 IKNV Q69 4G 2G 2G 3G 3G S6 CIKNV72 2G 2G 3G S4 IKV R75 2G 4G 2G S1 EIKV78 2G 3G 2G S1 EIKV81 2G 2G 2G S1 EIKV82 4G 4G 4G S3 AGJKW83 3G 4G 4G S10 BHV T84 2G 4G 4G S9 BINV T86 3G 3G 4G S2 HV QT87 2G 3G 4G S6 INV QT90 2G 2G 4G S4 IV PT91 4G 4G 3G S7/8 GKWX QU92 3G 4G 3G S2 HV QT93 3G 4G 2G 4G 3G S6 INV QT95 3G 3G 3G S2 CHV T96 2G 3G 3G S6 CINV T99 2G 2G 3G S4 DIV T

97

Table 9.2: Classifying the interoperation cases (for GSM,UMTS, and LTE)

IDComponents

ScenarioReason

IdentityModule

ME BS MSC/MME

HNStated in

specInterpretation

101 3G 4G 2G S5 EHMV T102 2G 4G 2G S1 EIV T104 3G 3G 2G S5 EHMV T105 2G 3G 2G S1 EIV T108 2G 2G 2G S1 EIV T110 3G 4G 4G S2 BHKV111 2G 4G 4G S6 BILNV113 3G 3G 4G S2 HKV O114 2G 3G 4G S6 ILNV O117 2G 2G 4G S4 ILV P119 3G 4G 3G S2 HKV Q120 3G 3G 2G 4G 3G S6 ILNV Q122 3G 3G 3G S2 CHKV123 2G 3G 3G S6 CILNV126 2G 2G 3G S4 DILV128 3G 4G 2G S5 EHKMV129 2G 4G 2G S1 EILV132 2G 3G 2G S1 EILV135 2G 2G 2G S1 EILV138 2G 4G 4G S6 BIKNV141 2G 3G 4G S6 IKNV O144 2G 2G 4G S4 IKV P147 2G 4G 3G S6 IKNV Q150 3G 2G 2G 3G 3G S6 CIKNV153 2G 2G 3G S4 DIKV156 2G 4G 2G S1 EIKV159 2G 3G 2G S1 EIKV162 2G 2G 2G S1 EIKV167 3G 3G 4G S5 HMV ST168 2G 3G 4G S1 IV ST171 2G 2G 4G S1 IV ST176 3G 3G 3G S5 FHMV T177 2G 4G 2G 3G 3G S1 FIV T180 2G 2G 3G S1 FIV T185 3G 3G 2G S5 EHMV T186 2G 3G 2G S1 EIV T

98

Table 9.2: Classifying the interoperation cases (for GSM,UMTS, and LTE)

IDComponents

ScenarioReason

IdentityModule

ME BS MSC/MME

HNStated in

specInterpretation

189 2G 2G 2G S1 EIV T194 3G 3G 4G S5 HKMV S195 2G 3G 4G S1 ILV S198 2G 2G 4G S1 ILV S203 3G 3G 3G S5 FHKMV204 2G 3G 2G 3G 3G S1 FILV207 2G 2G 3G S1 FILV212 3G 3G 2G S5 EHKMV213 2G 3G 2G S1 EILV216 2G 2G 2G S1 EILV222 2G 3G 4G S1 IKV S225 2G 2G 4G S1 IKV S231 2G 2G 2G 3G 3G S1 FIKV234 2G 2G 3G S1 FIKV240 2G 3G 2G S1 EIKV243 2G 2G 2G S1 EIKV

As a summary, Table 9.3 shows what combination of the components lead tothe scenarios. For each case that is allowed or uncertain, if its components matchesthe one of the conditions then its AKA scenario is the one for that row. For example,if the BS and HN are 2G then the AKA scenario is S1. Conversely, for each scenariothe condition characterizes the components for all the cases that use that scenario.In the table, a 4G capable MS means that either the identity module is a 4G USIMor it is a 4G ME, i.e., the MS supports 4G AKA. There are a variety of cases resultin scenario S2. It is difficult to summarize the common characterization of the cases.However, since all other scenarios have determining combination of components, ifone case does not contains any combination of components listed for other scenarios,the AKA scenario of the case is scenario S2.

9.2 Scenario S7: LTE I ‖ UMTS II–III ‖ [optionally, LTE IV] ‖ LTE V,conv(CK IK → KASME , MME)

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

99

Table 9.3: Determining components of each scenario

Scenario Component conditionS1 2GBS + 2GHN or SIM + 2GBSS2 all othersS3 USIM/4G USIM + 4GME + 4GBS + MME + 4GHNS4 USIM/4G USIM + 2GBS + 2GVLR/SGSN + 3GHN/4GHNS5 3GBS+2GHN or SIM+3GBS

S6USIM/4G USIM + 2GBS + 3GVLR/SGSN/4GMME + 3GHN/4GHN

but not 4G capable MS + MME + 4G HNS7/S8 4GBS + MME + 3GHN

S9 4G capable MS + 2GBS + MME + 4GHNS10 4G capable MS + 3GBS + MME +4GHN

9.2.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM, UMTS, and LTE diagrams.

This scenario is characterized by a 4G ME, a 4G SN (i.e., 4G BS and 4G MME)and a USIM or 4G USIM identity module subscribed to a 3G HN. A typical case iswhen a 4G ME equipped with a USIM whose home network is 3G HN roams intoa 4G serving network. Two of the allowable/uncertain cases fall into this category.The AKA is triggered by the attach request. The identity request and responseprocedure is the same as in LTE I (Fig. 5.2). The 3G HN can generate 2G or 3Gauthentication vectors, but cannot generate 4G authentication vectors. Upon requestby the MME, the 3G HN therefore generates and delivers a 3G authentication vectorwhich thus is identical to UMTS II. Upon receiving the authentication vector, theMME communicates with the MS as in UMTS III. The 4G BS requires 4G AS keys,which are derived from the intermediate key KeNB . Because the intermediate keyKeNB is derived from the local master key KASME , the MME applies a key derivationfunction to generate the local master key KASME from the UMTS encryption keyCK and integrity key IK . Including LTE IV is optional in this scenario. Later, weanalyze both variations and show that the AKA without LTE IV is prone to an attackin which a false base station can both eavesdrop and modify the messages betweenthe MS and the SN. Executing both LTE IV and V prevents this attack. LTE V(Fig. 5.2) is executed which includes the deriving of KeNB . Fig. 9.1 shows this AKAscenario without LTE IV. Fig. 9.2 shows this AKA scenario with LTE IV.

9.2.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model.

100

4G ME with USIM MME 3G HN 4G BS

LTE I

UMTS II

UMTS III

KASME = KDF’(CK, IK) KASME = KDF’(CK, IK)

LTE V

Figure 9.1: AKA scenario S7 without LTE IV

4G ME with USIM MME 3G HN 4G BS

LTE I

UMTS II

UMTS III

KASME = KDF’(CK, IK) KASME = KDF’(CK, IK)

LTE V

LTE IV

Figure 9.2: AKA scenario S7 with LTE IV

Scenario S7 without LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S7_LTE-I_UMTS_II-III_LTE_V.pv.

Fig. 9.3 elaborates the scenario in Fig. 9.1 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. Most of the code in this model is inherited from the LTEmodel and the UMTS model. The SN authenticates the MS as in UMTS authenti-cation, the events begSN and endSN use UMTS keys in the authentication propertyspecification. The MS authenticates the SN (through the eNB) as in LTE authenti-cation, and the events begMS ENB and endMS ENB use the intermediate key KeNB andthe capabilities as input parameters.

event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS ENB( iden t , enbKey , bool ) .event endMS ENB( iden t , enbKey , bool ) .

Using the same technique (see Section 3.2.1) to check the secrecy of the keys as inother models, a private value is declared as

f r ee s e c r e t : b i t s t r i n g [ pr i va te ] .

101

4G ME with USIM MME 3G HN

5. RAND, AUTN

6. RES

3. IMSI

4. IMSI, RAND, AUTN, XRES, CK, IK

2. IMSI

1.CAP

8. enableEnc, AS-MAC

4G BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND)

Verify RES = XRES

7. CAP, KeNB

Generate RAND ,MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC

9. AS SMComplete Integrity protected

KASME = KDF’(CK, IK)

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

Decide enableENC, AS-MAC = EIA(enableEnc, KRRCint)

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

XAS-MAC = EIA(enableEnc, KRRCint) Verify XAS-MAC = AS-MAC

10. payload, if no encryption {payload}_KRRCenc, otherwise

Decrypt message ifenableEnc_ms is true

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_sn, ck_sn, ik_sn)

event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

KeNB = KDF(KASME)

KASME = KDF’(CK, IK)

LT

E I

UM

TS II

UM

TS III

LT

E V

Verify integrity of message 9

Figure 9.3: AKA scenario S7, version without LTE IV, annotated in accord with ourmodel

The secret is encrypted under the keys and is sent out over the public channel.The processes of the MS and the SN (MME + BS) are defined as follows. The

comments refer to message numbers in Figure 9.3.

1 l e t processMS =2 new ims i ms : i d e n t ;

102

3 new k i : key ;4 i n s e r t keys ( ims i ms , k i ) ;5 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n6 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)7 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)8 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , mac ms : mac ) ) ;9 (∗ [Msg 5 ] ∗)

10 i f f 1 ( k i , rand ms ) = mac ms then11 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n12 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n13 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n14 event begSN ( ims i ms , ck ms , i k ms ) ;15 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)16 l e t kasme ms = kdf asme ( ck ms , i k ms ) i n17 l e t kenb ms : enbKey = kd f enb ( kasme ms ) i n18 l e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i n19 l e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i n20 l e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i n21 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s22 ( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)23 out ( pubChannel , (ASSMComplete , as smcomplete msg ,24 f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)25 event endMS ENB( ims i ms , kenb ms , cap ms ) ;26 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng ,27 =f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)28 out ( pubChannel , s e n c r y p t ( s e c r e t , ck ms ) ) ;29 out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t , i k ms ) ) ;30 out ( pubChannel , s enc ryptEnb ( s e c r e t , kenb ms ) ) ;31 i f enab l eEnc as ms = t r u e then32 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms )33 i n 0 .34

35 l e t processSN =36 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)37 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)38 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 3 ] ∗)39 i n ( s ecu reChanne l , (=AV, =ims i s n , r and sn : nonce , x r e s s n : re sp ,40 ck sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ; (∗ [Msg 4 ] ∗)41 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)42 i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)43 i f r e s s n = x r e s s n then44 event endSN( ims i s n , ck sn , i k s n ) ;45 l e t kasme sn = kdf asme ( ck sn , i k s n ) i n46 l e t kenb sn : enbKey = kd f enb ( kasme sn ) i n47 l e t ka s enc sn : asEncKey = kd f a s e n c ( kenb sn ) i n48 l e t k a s i n t s n : a s I n tKey = k d f a s i n t ( kenb sn ) i n49 l e t kupenc sn : upEncKey = kd f up enc ( kenb sn ) i n50 event begMS ENB( ims i s n , kenb sn , cap sn ) ;51 out ( pubChannel , (ASSMC, cap sn , f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap sn ) ,52 k a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)53 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

103

54 =f i n t e g a s ( as smcomplete msg , k a s i n t s n ) ) ) ; (∗ [Msg 9 ] ∗)55 i f cap sn = f a l s e then56 event d i s a b l eEn c ;57 out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t s n ) ) )58 (∗ [Msg 10 ] ∗)59 e l s e60 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k a s en c sn ) ,61 f i n t e g a s ( s e n c r y p t a s ( pay load , k a s en c sn ) , k a s i n t s n ) ) ) .62 (∗ [Msg 10 ] ∗)

In lines 39–40, the SN receives the UMTS authentication vector from the HN. Inlines 16 and 45, the MS and the SN derive the master key KASME from the UMTScipher and integrity keys. The MS and the SN derive the intermediate key KeNB andthe AS keys in lines 17–20 and lines 46–49 respectively. The HN process is the sameas the one in the UMTS model (Section 4.2.2).

Scenario S7 with LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S7_LTE-I_UMTS_II-III_LTE_IV-V.pv.

Fig. 9.4 elaborates the scenario in Fig. 9.2 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. In addition to the authentication of the MS to theSN and the authentication of the BS to the MS, this scenario also provides for theauthentication of the MME to the MS. The events specifying the authenticationproperties are defined as:

event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , asmeKey , bool ) .event endMS( iden t , asmeKey , bool ) .event begMS ENB( iden t , enbKey , bool ) .event endMS ENB( iden t , enbKey , bool ) .

The processes representing the behavior of the components are defined as fol-lows. The comments refer to message numbers in Figure 9.4.

1 (∗ AS SMC procedu r e i n p r o c e s s MS ∗)2 l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : bool ) =3 l e t kenb ms : enbKey = kd f enb ( kasme ms ) i n4 l e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i n5 l e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i n6 l e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i n7 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s8 ( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)9 event endMS ENB( ims i ms , kenb ms , cap ms ) ;

10 out ( pubChannel , (ASSMComplete , as smcomplete msg ,11 f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)12 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng ,13 =f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)

104

MS MME-HN

2. IMSI

1.CAP

8. enableEnc, AS-MAC

BS

7. CAP, KeNB

9. AS SMC Complete Integrity protected

6. NAS Security Mode Complete ifenableEnbciphered , integrity protected

otherwise integrity protected

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

Decide enableENC, AS-MAC = EIA(enableEnc, KRRCint) Start integrity protection

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

XAS-MAC = EIA(enableEnc, KRRCint) Verify XAS-MAC = AS-MAC

10. payload, if no encryption {payload}_KRRCenc, otherwise

Decrypt message ifenableEnc_ms is true

event begMS(imsi_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, kasme_ms, cap_ms)

event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

KeNB = KDF(KASME)

LT

E IV

L

TE

V

LT

E I

UM

TS III

3. RAND, AUTN

4. RES

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND)

Verify RES = XRES

Generate RAND ,MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_sn, ck_sn, ik_sn)

KNASenc = KDF (KASME)KNASint = KDF(KASME) Decide enableEnc?

NAS-MAC = EIA((enableEnc, CAP), KNASint)

5. enableEnc, CAP, NAS-MAC

Verify CAP

KNASenc = KDF (KASME), KNASint = KDF(KASME) XNAS-MAC = EIA((CAP, enableEnc), KNASint)

Verify XNAS-MAC = NAS-MAC

KASME = KDF’(CK, IK)

KASME = KDF’(CK, IK)

Verify integrity of message 9

Figure 9.4: AKA scenario S7, version with LTE IV, annotated in accord with ourmodel

14 out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;15 out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;

105

16 out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;17 i f enab l eEnc as ms = t r u e then18 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms )19 i n 0 .20

21 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)22 l e t processMS =23 new ims i ms : i d e n t ;24 new k i : key ;25 i n s e r t keys ( ims i ms , k i ) ;26 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n27 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)28 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)29 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ) ) ;30 (∗ [Msg 3 ] ∗)31 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n32 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n33 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n34 event begSN ( ims i ms , ck ms , i k ms ) ;35 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 4 ] ∗)36 l e t kasme ms : asmeKey = kdf asme ( ck ms , i k ms ) i n37 l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i n38 l e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i n39 i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,40 =f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;41 (∗ [Msg 5 ] ∗)42 event endMS( ims i ms , kasme ms , cap ms ) ;43 out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;44 out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;45 i f enab l eEnc nas ms = f a l s e then46 out ( pubChannel , (NASSMComplete , nas smcomplete msg ,47 f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 6 ] ∗)48 pMSAS( kasme ms , ims i ms , cap ms )49 e l s e50 out ( pubChannel , (NASSMComplete , s e n c r y p t n a s ( nas smcomplete msg ,51 knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,52 knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 6 ] ∗)53 pMSAS( kasme ms , ims i ms , cap ms ) .54

55 (∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)56 l e t pENB( kasme enb : asmeKey , im s i e nb : i d en t , cap enb : bool ) =57 l e t kenb enb : enbKey = kd f enb ( kasme enb ) i n58 l e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i n59 l e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i n60 l e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i n61 event begMS ENB( ims i enb , kenb enb , cap enb ) ;62 out ( pubChannel , (ASSMC, cap enb , f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) ,63 k a s i n t e n b ) ) ) ; (∗ [Msg 8 ] ∗)64 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,65 =f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 9 ] ∗)66 i f cap enb = f a l s e then

106

67 event d i s a b l eEn c ;68 out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )69 (∗ [Msg 10 ] ∗)70 e l s e71 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,72 f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .73 (∗ [Msg 10 ] ∗)74

75 (∗ p r o c e s s r e p r e s e n t i n g MME and HN ∗)76 l e t processMMEHN =77 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)78 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)79 new r and sn : nonce ;80 get keys (= ims i s n , k i s n ) i n81 l e t mac sn : mac = f1 ( k i s n , r and sn ) i n82 l e t x r e s s n : r e s p = f2 ( k i s n , r and sn ) i n83 l e t ck sn : c i phe rKey = f3 ( k i s n , r and sn ) i n84 l e t i k s n : i n t egKey = f4 ( k i s n , r and sn ) i n85 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 3 ] ∗)86 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 4 ] ∗)87 event endSN( ims i s n , ck sn , i k s n ) ;88 l e t kasme sn : asmeKey = kdf asme ( ck sn , i k s n ) i n89 l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i n90 l e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i n91 event begMS( ims i s n , kasme sn , cap sn ) ;92 out ( pubChannel , (NASSMC, cap sn , cap sn ,93 f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 5 ] ∗)94 i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i ng ,95 =f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 6 ] ∗)96 i f cap sn = t r u e then97 i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then98 pENB( kasme sn , im s i s n , cap sn )99 e l s e 0

100 e l s e101 i f msg nas = nas smcomplete msg then102 pENB( kasme sn , im s i s n , cap sn )103 e l s e 0 .

When modeling the MME and the HN as separated processes as in other models,ProVerif finds a false attack which due to the approximation of the private channel(see Section 2.4.3) between the MME and the HN. Because our assumption is thatthe communication between the MME and the HN is secure, we omit the messagestransmitted between them and model the MME and the HN in one process. Byspecifying the behavior of the MME and the HN in one process, the false attack isremoved. In lines 79–84, the authentication vector is generated. As in the model ofthe S7 without LTE IV, the master keys KASME is derived from the UMTS cipher andintegrity key in lines 36 and 88 by the MS and the MME respectively. The NAS SMCmessage is sent by the MME in lines 92–93, and is received by the MS in lines 39–40.Subsequently, the NAS SMComplete message is sent by the MS in lines 46–47 or

107

Table 9.4: Analysis result of S7 models

KeySecrecy

ConditionalPayloadSecrecy

Auth. ofthe MS tothe MME

Auth. ofthe MMEto the MS

Auth. ofthe BS tothe MS

PayloadSecrecy

S7 w/oLTE IV

Proved Proved Proved N/A Failed Failed

S7 w/LTE IV

Proved Proved Proved Proved Proved Failed

lines 50–52 depending on whether the encryption is enabled. This message is receivedby the MME in line 94–95.

9.2.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

In both models, the secrecy and authentication properties are specified as:

• Key Secrecy (secrecy of Ki, CK, IK, NAS and AS keys)not attacker (new k i ) .query attacker ( s e c r e t ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Mutual Authentication between the MS and the SN1 query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;2 event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .3 query x1 : i d en t , x2 : enbKey , x3 : bool ;4 event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

• Payload Secrecyquery attacker ( pay load ) .

In the model of S7 with LTE IV, the authentication of the MME to the MS is specifiedas:

query x1 : i d en t , x2 : asmeKey , x3 : bool ;event (endMS( x1 , x2 , x3 ) ) event (begMS( x1 , x2 , x3 ) ) .

Table 9.4 shows the analysis result of the above properties. Plain secrecy of themessage payload does not hold because the attacker can always learn the payload ifthe MS is not capable of encryption. For the version without LTE IV, ProVerif findsan attack that violates the property of the authentication of the SN to the MS whichis specified in lines 3–4. In the attack, the attacker intercepts the capability messagesent by the MS and replaces the capabilities with different ones. The event endMS isexecuted after the MS receives the SMC message. Because the SMC message doesnot contain the received MS’s capabilities, the MS has no way to confirm whether the

108

SN receives the correct capabilities. ProVerif detects the violation because, althoughthere was a begMS event, it has a different value for capabilities. For the version withLTE IV, the property is proved.

9.3 Scenario S8: LTE I’ ‖UMTS II–III ‖ LTE IV–V, conv(CK IK nonces →KASME , MME)

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

9.3.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM, UMTS, and LTE diagrams.

This scenario is characterized by the same cases as in S7. The difference toS7 is that this scenario is triggered by the TAU request and the NONCEMS in theTAU request is used in LTE IV. The retrieving and generating of the authentica-tion vector and the challenge-response procedure are the same as in S7. In LTEIV, the MME generates a nonce NONCEMME and uses it with the CK , IK , andNONCEMS as input parameters to derive the KASME . The MME sends the integrityprotected SMC message containing the nonce NONCEMS received from the MS andthe nonce NONCEMME . Upon receiving the SMC message, the MS checks whetherthe NONCEMS and the capabilities match what it originally sent in LTE I’. If thecheck successes, the MS uses the same key derivation function as in the MME toderive the KASME and sends out the SMC complete message. Subsequently, LTE Vis executed. Fig. 9.5 shows this AKA scenario.

9.3.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model. The complete model is in Section 11 and in our repository asdissertation/models/S8_LTE_I’_UMTS_II-III_LTE_IV-V.pv.

Fig. 9.6 elaborates the scenario in Fig. 9.5 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. Most of the code in this model is inherited from the LTEmodel and the UMTS model. The events used in the correspondence assertions tospecify the authentication properties are declared as:

event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , c ipherKey , integKey , bool ) .event endMS( iden t , c ipherKey , integKey , bool ) .event begMS ENB( iden t , enbKey , bool ) .

109

5. IMSI

1. CAP

2. GUTI

10. NAS-Algs, CAP, NONCEMS, NONCEMME, NAS-MAC

11. NAS SMComplete ciphered , integrity protected

LT

E IV

’ L

TE

I’

KASME = KDF(CK, IK, NONCEMS, NONCEMME) KNASenc = KDF (KASME, NAS-enc-alg, Alg-ID) KNASint = KDF(KASME, NAS-int-alg, Alg-ID)

Decide NAS-Algs, NAS-MAC = EIA(KNASint, (CAP, Algs))

Verify CAP, NONCEMS KASME = KDF(CK, IK, NONCEMS, NONCEMME) KNASenc = KDF (KASME, NAS-enc-alg, Alg-ID) KNASint = KDF(KASME, NAS-int-alg, Alg-ID)

XNAS-MAC = EIA(KNASint, (CAP, Algs)) Verify XNAS-MAC = NAS-MAC

3. NONCEMS

UMTS II

UMTS III

LTE V

4. Identity Request

4G ME with USIM MME 3G HN 4G BS

Verify integrity of message 11

Figure 9.5: AKA scenario S8

event endMS ENB( iden t , enbKey , bool ) .

The process representing HN is the same as the one in the UMTS model (see Sec-tion 4.2.2). The processes representing the MS, the BS, and the MME are defined asfollows. The comments refer to message numbers in Figure 9.6.

1 (∗ AS SMC procedu r e i n p r o c e s s MS ∗)2 l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : bool ) =3 l e t kenb ms : enbKey = kd f enb ( kasme ms ) i n4 l e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i n5 l e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i n6 l e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i n7 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s8 ( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 11 ] ∗)9 out ( pubChannel , (ASSMComplete , as smcomplete msg ,

10 f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 12 ] ∗)11 event endMS ENB( ims i ms , kenb ms , cap ms ) ;12 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng ,13 =f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 13 ] ∗)14 out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;15 out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;16 out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;17 i f enab l eEnc as ms = t r u e then18 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms ) i n 0 .

110

MS MME 4G HN

2. IMSI

1.CAP

11. enableEnc, AS-MAC

BS

10. CAP, KeNB

12. AS SMC Complete Integrity protected

9. NAS Security Mode Complete if enableEnc, ciphered , integrity protected

otherwise integrity protected

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

Decide enableEnc?, AS-MAC = EIA(enableEnc, KRRCint) Start integrity protection

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB)

XAS-MAC = EIA(enableEnc, KRRCint) Verify XAS-MAC = AS-MAC

13. payload, if no encryption {payload}_KRRCenc, otherwise

Decrypt message ifenableEnc_ms is true

event begMS(imsi_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, kasme_ms, cap_ms)

event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

KeNB = KDF(KASME)

LT

E IV

’ L

TE

V

LT

E I’

UM

TS II

UM

TS III

3. NONCEMS

6. RAND, AUTN

7. RES

4. IMSI

5. IMSI, RAND, AUTN, XRES, CK, IK

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND)

Verify RES = XRES

Generate RAND ,MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_sn, ck_sn, ik_sn)

KASME = KDF(CK, IK, NONCEMS, NONCEMME) KNASenc = KDF (KASME), KNASint = KDF(KASME)

Decide enableEnc?, NAS-MAC = EIA((enableEnc, CAP, NONCEMS, NONCEMME), KNASint)

8. enableEnc, CAP, NONCEMS, NONCEMME, NAS-MAC

Verify CAP, NONCEMS

KASME = KDF(CK, IK, NONCEMS, NONCEMME) KNASenc = KDF (KASME), KNASint = KDF(KASME)

XNAS-MAC = EIA((enableEnc, CAP, NONCEMS, NONCEMME), KNASint) Verify XNAS-MAC = NAS-MAC

verify integrity of the message 9

Figure 9.6: AKA scenario S8 annotated in accord with our model

19

111

20 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)21 l e t processMS =22 new ims i ms : i d e n t ;23 new k i : key ;24 i n s e r t keys ( ims i ms , k i ) ;25 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n26 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)27 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)28 new nonce ms : nonce ;29 out ( pubChannel , (NONCE TAU, nonce ms ) ) ; (∗ [Msg 3 ] ∗)30 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ) ) ;31 (∗ [Msg 6 ] ∗)32 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n33 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n34 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n35 event begSN ( ims i ms , ck ms , i k ms ) ;36 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 7 ] ∗)37 i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,38 =nonce ms , nonce mme ms : nonce , nas mac : msgMac ) ) ; (∗ [Msg 8 ] ∗)39 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , nonce ms ,40 nonce mme ms ) i n41 l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i n42 l e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i n43 i f ( nas mac = f i n t e g n a s ( ( enab leEnc nas ms , cap ms , nonce ms ,44 nonce mme ms ) , kna s i n t ms ) ) then45 event endMS( ims i ms , ck ms , ik ms , cap ms ) ;46 out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;47 out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;48 i f enab l eEnc nas ms = f a l s e then49 out ( pubChannel , (NASSMComplete , nas smcomplete msg ,50 f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)51 pMSAS( kasme ms , ims i ms , cap ms )52 e l s e53 out ( pubChannel , (NASSMComplete , s e n c r y p t n a s54 ( nas smcomplete msg , knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s55 ( nas smcomplete msg , knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)56 pMSAS( kasme ms , ims i ms , cap ms ) .57

58 (∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)59 l e t processENB =60 i n ( sChannelSnBts , ( kasme enb : asmeKey , im s i e nb : i d en t ,61 cap enb : bool ) ) ;62 l e t kenb enb : enbKey = kd f enb ( kasme enb ) i n63 l e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i n64 l e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i n65 l e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i n66 event begMS ENB( ims i enb , kenb enb , cap enb ) ;67 out ( pubChannel , (ASSMC, cap enb ,68 f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) , k a s i n t e n b ) ) ) ; (∗ [Msg 11 ] ∗)69 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,70 =f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 12 ] ∗)

112

71 i f cap enb = f a l s e then72 event d i s a b l eEn c ;73 out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )74 (∗ [Msg 13 ] ∗)75 e l s e76 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,77 f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .78 (∗ [Msg 13 ] ∗)79

80 (∗ p r o c e s s r e p r e s e n t i n g MME ∗)81 l e t processMME =82 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)83 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)84 i n ( pubChannel , (=NONCE TAU, nonce ms sn : nonce ) ) ; (∗ [Msg 3 ] ∗)85 out ( s ecu reChanne l , (AV REQ , im s i s n ) ) ; (∗ [Msg 4 ] ∗)86 i n ( s ecu reChanne l , (=AV, =ims i s n , r and sn : nonce , x r e s s n : re sp ,87 ck sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ; (∗ [Msg 5 ] ∗)88 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 6 ] ∗)89 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 7 ] ∗)90 event endSN( ims i s n , ck sn , i k s n ) ;91 new nonce mme : nonce ;92 l e t kasme sn : asmeKey = kdf asme ( ck sn , i k s n , nonce ms sn ,93 nonce mme ) i n94 l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i n95 l e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i n96 event begMS( ims i s n , ck sn , i k s n , cap sn ) ;97 out ( pubChannel , (NASSMC, cap sn , cap sn , nonce ms sn , nonce mme ,98 f i n t e g n a s ( ( cap sn , cap sn , nonce ms sn , nonce mme ) ,99 k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)

100 i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i ng ,101 =f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 9 ] ∗)102 i f cap sn = t r u e then103 i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then104 out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )105 e l s e 0106 e l s e107 i f cap sn = f a l s e then108 i f msg nas = nas smcomplete msg then109 out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )110 e l s e 0111 e l s e 0 .

In lines 28–29, the MS generates the nonce in the TAU request and sends it to theMME. In lines 37–38, the MS receives the NAS SMC message which contains thecapabilities and the nonce received by the MME, as well as the nonce generated bythe MME. The MS verifies the capabilities and the nonce received from the MMEare the same as it sent out earlier. In lines 39-40, the MS derives the master keyfrom the UMTS cipher and integKey keys, and the nonces generated by the MS andMME respectively. Based on the master key, the MS derives the NAS and AS keysand finishes the NAS and AS SMC procedure as in LTE model (see Section 5.2.2).

113

Table 9.5: Analysis result of S8 model

KeySecrecy

ConditionalPayloadSecrecy

Auth. ofthe MS tothe MME

Auth. ofthe MMEto the MS

Auth. ofthe BS tothe MS

PayloadSecrecy

Proved Proved Proved Proved Proved Failed

The MME receives the nonce in the TAU request in line 84 and generates anonce in line 91. Using these two nonces together with the UMTS keys, the MMEderives the master key in lines 92–93. In lines 97–98, the MME sends out the NASSMC message, which contains the received capabilities and nonce from the MS andthe nonce generated by itself. The subsequent NAS and AS SMC procedures arespecified the same as in the LTE model (see Section 5.2.2).

9.3.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

The secrecy and authentication properties are specified as:

• Key Secrecy (secrecy of Ki, NAS and AS keys)not attacker (new k i ) .query attacker ( s e c r e t ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

• Authentication of the MS to the MMEquery x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;

event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

• Authentication of the MME to the MSquery x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : bool ;

event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

• Authentication of the BS to the MSquery x1 : i d en t , x2 : enbKey , x3 : bool ;

event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

• Payload Secrecyquery attacker ( pay load ) .

Table 9.5 shows the analysis result of the above properties. ProVerif proves all theproperties except the payload secrecy, since the attacker can always learn the payloadif the MS is not capable of encryption.

114

9.4 Scenario S9: GSM I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ GSM IV,conv(CK IK → Kc, MME), AV = 4G AV + CK + IK

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

9.4.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM, UMTS, and LTE diagrams.

This scenario is characterized by a mixed SN including a 2G BS and a 4G MMEas well as an MS that is subscribed to a 4G HN where either the identity module is a4G USIM or it is a 4G ME, i.e., the MS supports 4G AKA. A typical case of this AKAscenario is that a 4G ME equipped with a 4G USIM whose HN is the 4G HN roamsinto a mixed network with 2G BS and MME. Four of the allowable/uncertain casesfall into this category. Because the 2G BS covers routing areas, the initial messagecan be the attach request or the RAU request. So the transmitting of the identity andthe capabilities is as in GSM I (Fig. 3.2). When the MME requests the authenticationvector from the HN by sending the IMSI and the network type, because the networktype is GERAN (because of the 2G BS), the 4G HN generates and delivers the 4Gauthentication vector with the UMTS cipher key CK and integrity key IK . Becausethe NAS signaling is transparent to the BS, the LTE challenge response procedureLTE III (Fig. 5.2) is executed between the MS and the MME. In this interoperationscenario, we consider the two variations with and without LTE IV (Fig. 5.2). Thefirst variation sticks to the LTE AKA as long as possible (i.e., until executing LTEIV before setting up the cipher between the MS and the BS). The other one goesto set the cipher between MS and the BS as soon as finishing the challenge-responseprocedure (without executing LTE IV). Later we show that the AKA without LTEIV is prone to a false base station attack and the AKA with LTE IV is prone to anattack against the CMC message between the 2G BS and the MS. Because the 2G BSrequires the GSM session key Kc, the MME derives the encryption key Kc from theUMTS cipher key CK and integrity key IK . Since only the 2G cipher mode setting issupported by the 2G BS, the 2G cipher mode setting procedure GSM IV (Fig. 3.2) isexecuted between the 2G BS and the MS—which also includes the MME sending theGSM session key to the 2G BS. Fig. 9.7 shows this AKA scenario without LTE IV.Fig. 9.8 shows this AKA scenario with LTE IV.

9.4.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model.

115

4G ME with USIM MME 4G HN 2G BS

GSM I

LTE II

LTE III

KC = KDF(CK, IK) KC = KDF(CK, IK)

GSM IV

Figure 9.7: AKA scenario S9 without LTE IV

4G ME with USIM MME 4G HN 2G BS

GSM I

LTE II

LTE III

KC = KDF(CK, IK) KC = KDF(CK, IK)

GSM IV

LTE IV

Figure 9.8: AKA scenario S9 with LTE IV

Scenario S9 without LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S9_GSM_I_LTE_II-III_GSM_IV.pv.

Fig. 9.9 elaborates the scenario in Fig. 9.7 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. The process representing the MS , the SN, and the HNare defined as follows. The comments refer to message numbers in Figure 9.9.

1 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)2 l e t processMS =3 new ims i ms : i d e n t ;4 new k i : key ;5 i n s e r t keys ( ims i ms , k i ) ;6 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n7 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)8 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)9 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

10 =f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)11 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n12 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n13 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n

116

4G MS MME 4G HN

5. RAND, AUTN, SNid

6. RES

3. IMSI, SNid, Network Type

4. IMSI, SNid, CK, IK RAND, AUTN, XRES, KASME

2. IMSI

1.CAP

8. enableEnc

2G BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid,)

Verify RES = XRES

7. CAP, KC

Generate RAND , MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC KASME= KDF(CK, IK, SNid)

9. CMComplete

10. payload, if no encryption {payload}_KC, otherwise

Decrypt message if enableEnc_ms is true

event begMS_AS(imsi_sn, kc_sn, cap_sn)

event endMS_AS(imsi_ms, kc_ms, cap_ms)

KC = c3(CK, IK)

Decide enableEnc?

KC = c3(CK, IK)

GSM

I L

TE

II L

TE

III G

SM IV

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_sn, ck_sn, ik_sn)

Figure 9.9: AKA scenario S9, version without LTE IV, annotated in accord with ourmodel

14 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n15 event begSN ( ims i ms , ck ms , i k ms ) ;16 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)17 l e t kc ms : gsmKey = c3 ( ck ms , i k ms ) i n18 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool ) ) ; (∗ [Msg 8 ] ∗)19 event endMS AS( ims i ms , kc ms , cap ms ) ;20 out ( pubChannel , CMComplete ) ; (∗ [Msg 9 ] ∗)21 i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ) ) ; (∗ [Msg 10 ] ∗)22 out ( pubChannel , s e n c r y p t a s ( s e c r e t , kc ms ) ) ;23 i f enab l eEnc as ms = t r u e then24 l e t msgcontent : b i t s t r i n g =25 s d e c r y p t a s ( datamsg , kc ms ) i n 0 .

117

26

27 (∗ p r o c e s s r e p r e s e n t i n g SN ∗)28 l e t processSN =29 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)30 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)31 new s n i d s n : i d e n t ;32 out ( s ecu reChanne l , (AV REQ , ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)33 i n ( s ecu reChanne l , (=AV, =ims i s n , s n i d h n s n : i d en t ,34 r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,35 ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)36 out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;37 (∗ [Msg 5 ] ∗)38 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)39 event endSN( ims i s n , ck sn , i k s n ) ;40 l e t kc sn : gsmKey = c3 ( ck sn , i k s n ) i n41 event begMS AS( ims i s n , kc sn , cap sn ) ;42 out ( pubChannel , (ASSMC, cap sn ) ) ; (∗ [Msg 8 ] ∗)43 i n ( pubChannel , =CMComplete ) ; (∗ [Msg 9 ] ∗)44 i f cap sn = f a l s e then45 event d i s a b l eEn c ;46 out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 10 ] ∗)47 e l s e48 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k c sn ) ) ) .49 (∗ [Msg 10 ] ∗)50

51 (∗ p r o c e s s r e p r e s e n t i n g HN ∗)52 l e t processHN =53 i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;54 (∗ [Msg 3 ] ∗)55 new rand hn : nonce ;56 get keys (= ims i hn , k i h n ) i n57 l e t mac hn : mac = f1 ( k i hn , rand hn ) i n58 l e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i n59 l e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i n60 l e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i n61 l e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i n62 out ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn , x r e s hn ,63 mac hn , kasme hn , ck hn , i k hn ) ) . (∗ [Msg 4 ] ∗)

In lines 55–63, the HN generates the LTE authentication vector and sends it out withthe UMTS cipher and integrity keys. Because the BS is GSM BS, the MS and theSN derive the GSM session key in lines 17 and 40 respectively. Same as in the GSMmodel (see Section 3.2.2), the CMC procedure is executed by the MS (lines 18 and20) and the SN (lines 42–43).

Scenario S9 with LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S9_GSM_I_LTE_II-IV_GSM_IV.pv.

118

Fig. 9.10 elaborates the scenario in Fig. 9.8 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. The HN process is the same as the one in the versionwithout LTE IV. The process representing the MS , the BS, and the MME are definedas follows. The comments refer to message numbers in Figure 9.10.

1 (∗ AS SMC procedu r e i n p r o c e s s MS ∗)2 l e t pMSAS( kc ms : gsmKey , ims i ms : i d en t , cap ms : bool ) =3 i n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool ) ) ; (∗ [Msg 10 ] ∗)4 event endMS AS( ims i ms , kc ms , cap ms ) ;5 out ( pubChannel , CMComplete ) ; (∗ [Msg 11 ] ∗)6 i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ) ) ;7 out ( pubChannel , s e n c r y p t a s ( s e c r e t , kc ms ) ) ;8 i f enab l eEnc as ms = t r u e then9 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kc ms ) i n 0 .

10

11 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)12 l e t processMS =13 new ims i ms : i d e n t ;14 new k i : key ;15 i n s e r t keys ( ims i ms , k i ) ;16 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n17 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)18 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)19 i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,20 =f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)21 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n22 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n23 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n24 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n25 event begSN ( ims i ms , sn id ms , kasme ms ) ;26 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)27 l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i n28 l e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i n29 i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,30 =f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;31 (∗ [Msg 7 ] ∗)32 event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;33 out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;34 out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;35 l e t kc ms : gsmKey = c3 ( ck ms , i k ms ) i n36 i f enab l eEnc nas ms = f a l s e then37 out ( pubChannel , (NASSMComplete , nas smcomplete msg ,38 f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)39 pMSAS( kc ms , ims i ms , cap ms )40 e l s e41 out ( pubChannel , (NASSMComplete ,42 s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,43 f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,44 kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)45 pMSAS( kc ms , ims i ms , cap ms ) .

119

4G MS MME 4G HN

5. RAND, AUTN, SNid

6. RES

3. IMSI, SNid, Network Type

4. IMSI, SNid, CK, IK RAND, AUTN, XRES, KASME

2. IMSI

1.CAP

10. enableEnc

2G BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid,)

Verify RES = XRES

9. CAP, KC

Generate RAND , MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC KASME= KDF(CK, IK, SNid)

11. CMComplete

7. enableEnc, CAP, NAS-MAC

XNAS-MAC = EIA((enableEnc, CAP), KNASint) Verify XNAS-MAC = NAS-MAC

8. NAS Security Mode Complete if enableEnb ciphered , integrity protected

otherwise integrity protected

KNASenc = KDF (KASME,), KNASint = KDF(KASME,) Decide enableEnc?,

NAS-MAC = EIA((enableEnc, CAP), KNASint)

12. payload, if no encryption {payload}_KC, otherwise

Decrypt message if enableEnc_ms is true

event begSN(imsi_ms, snid_ms, kasme_ms)

event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms)

event endSN(imsi_sn, snid_sn, kasme_sn)

event begMS_AS(imsi_sn, kc_sn, cap_sn)

event endMS_AS(imsi_ms, kc_ms, cap_ms)

KC = c3(CK, IK)

Decide enableEnc?

KC = c3(CK, IK)

KNASenc = KDF (KASME) KNASint = KDF(KASME)

GSM

I L

TE

II L

TE

III G

SM IV

L

TE

IV

verify integrity of message 8

Figure 9.10: AKA scenario S9, version with LTE IV, annotated in accord with ourmodel

46

47 (∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)48 l e t processBS =

120

49 i n ( sChannelSnBts , ( k c b s : gsmKey , im s i b s : i d en t , cap bs : bool ) ) ;50 event begMS AS( ims i b s , kc bs , cap bs ) ;51 out ( pubChannel , (ASSMC, cap bs ) ) ; (∗ [Msg 10 ] ∗)52 i n ( pubChannel , =CMComplete ) ; (∗ [Msg 11 ] ∗)53 i f cap bs = f a l s e then54 event d i s a b l eEn c ;55 out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 12 ] ∗)56 e l s e57 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k c b s ) ) ) .58 (∗ [Msg 12 ] ∗)59

60 (∗ p r o c e s s r e p r e s e n t i n g MME ∗)61 l e t processMME =62 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)63 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)64 new s n i d s n : i d e n t ;65 out ( s ecu reChanne l , (AV REQ , ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)66 i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , s n i d h n s n : i d en t ,67 r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,68 ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)69 out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;70 (∗ [Msg 5 ] ∗)71 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)72 event begMS( ims i hn sn , s n i d hn sn , kasme sn , cap sn ) ;73 l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i n74 l e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i n75 out ( pubChannel , (NASSMC, cap sn , cap sn ,76 f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)77 i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i ng ,78 =f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)79 l e t kc sn : gsmKey = c3 ( ck sn , i k s n ) i n80 i f cap sn = t r u e then81 i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then82 event endSN( ims i hn sn , s n i d hn sn , kasme sn ) ;83 out ( sChannelSnBts , ( kc sn , im s i hn sn , cap sn ) )84 e l s e 085 e l s e86 i f cap sn = f a l s e then87 i f msg nas = nas smcomplete msg then88 event endSN( ims i hn sn , s n i d hn sn , kasme sn ) ;89 out ( sChannelSnBts , ( kc sn , im s i hn sn , cap sn ) )90 e l s e 091 e l s e 0 .

Compared with the version without LTE IV, the difference is that the NAS SMCprocedure is included in this model. The MME sends out the NAS SMC message inlines 75–76, and receives the NAS SMComplete message in lines 77–78. While theMS receives the NAS SMC message and verifies the capabilities in lines 29–30. TheMS sends out the NAS SMComplete message in lines 37–39 or lines 41–44, dependingon whether the encryption is enabled or not.

121

Table 9.6: Analysis result of S9 models

KeySecrecy

ConditionalPayloadSecrecy

Auth. ofthe MS tothe MME

Auth. ofthe MMEto the MS

Auth. ofthe BS tothe MS

PayloadSecrecy

S9 w/oLTE IV

Proved Proved Proved N/A Failed Failed

S9 w/LTE IV

Proved Proved Proved Proved Failed Failed

9.4.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

In both models, the properties of key secrecy, payload secrecy, and conditionalpayload secrecy are specified in the same way:

• Key Secrecy (secrecy of Ki, Kc and NAS keys)not attacker (new k i ) .query attacker ( s e c r e t ) .

• Payload Secrecyquery attacker ( pay load ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

In the version without LTE IV, the authentication properties are specified as:

1 query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;2 event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .3 query x1 : i d en t , x2 : gsmKey , x3 : bool ;4 event ( endMS AS( x1 , x2 , x3 ) ) event ( begMS AS( x1 , x2 , x3 ) ) .

In the version with LTE IV, the authentication properties are specified as:

1 query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;2 event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .3 query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : bool ;4 event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .5 query x1 : i d en t , x2 : gsmKey , x3 : bool ;6 event ( endMS AS( x1 , x2 , x3 ) ) event ( begMS AS( x1 , x2 , x3 ) ) .

Table 9.6 shows the analysis result of the above properties. In the version withoutLTE IV, ProVerif finds the false base station attack (similar to the one found inGSM model, see Section 3.3) when checking the authentication of the BS to the MS(lines 3–4). The attack is possible because neither is the CMC message integrityprotected nor is the capabilities sent back by the GSM BS.

In the version with LTE IV, An attack is found when checking the authenti-cation of the BS to the MS (lines 5–6). In the attack, the attacker modifies the CMCmessage (which is not integrity protected) to tell the MS to use no encryption. Thisattack will be detected by the BS once the MS sends messages to the BS.

122

4G ME with USIM MME 4G HN 3G BS

UMTS I I

LTE II

LTE III

UMTS IV

Figure 9.11: AKA scenario S10 without LTE IV

9.5 Scenario S10: UMTS I ‖ LTE II–III ‖ [optionally, LTE IV] ‖ UMTSIV, AV = 4G AV + CK + IK

In this section, we provide an overview of the authentication scenario and its securitygoals and present our model of the scenario, the specifications of security properties,and our findings.

9.5.1 Overview of the AKA Scenario

This section describes the authentication scenario and informally specifies the securitygoals by introducing the blocks which are from the GSM, UMTS, and LTE diagrams.

This scenario is characterized by a 4G HN, a mixed SN consisting of a 3GBS and a 4G MME, as well as an MS that is subscribed to a 4G HN where eitherthe identity module is a 4G USIM or it is a 4G ME with a 3G USIM, i.e., the MSsupports 4G AKA. A typical case of this scenario is that a 4G ME equipped with a 4GUSIM whose HN is 4G HN roams into a mixed network with 3G BS and MME. Threeof the allowable/uncertain cases fall into this category. The 3G BS covers routingareas, so the initial message can be the attach request or a RAU request. Thus,the transmitting of identity and capabilities is as in UMTS I (Fig. 4.2). In orderto obtain an authentication vector, the MME sends the authentication data requestwith the IMSI and the network type to the 4G HN. Because the access network isUTRAN, the 4G HN generates and delivers the 4G authentication vector as well asthe UMTS encryption key CK and integrity key IK . Subsequently, the LTE challengeresponse procedure LTE III (Fig. 5.2) is executed between the MS and the MME. As inscenarios S7 and S9, the LTE IV is optional. Later we show that the authenticationproperties hold in both variations. The 3G BS obtains the UMTS encryption keyCK , the UMTS integrity key IK , as well as the capabilities as part of UMTS IV(Fig. 4.2)—which also includes the UMTS security mode set-up procedure betweenthe 3G BS and the MS. Fig. 9.11 shows this AKA scenario without LTE IV. Fig. 9.12shows this AKA scenario with LTE IV.

123

4G ME with USIM MME 4G HN 3G BS

UMTS I

LTE II

LTE III

LTE IV

UMTS IV

Figure 9.12: AKA scenario S10 with LTE IV

9.5.2 Modeling the AKA Scenario

In this section, we discuss the model of this scenario along with the diagram annotatedaccord with our model.

Scenario S10 without LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S10_UMTS_I_LTE_II-III_UMTS_IV.pv.

Fig. 9.13 elaborates the scenario in Fig. 9.11 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. Most of the code in this model is inherited from the LTEmodel and the UMTS model. The process representing HN is the same as the one inthe S9 model (see Section 9.4.2). The processes representing the MS an the SN aredefined as follows. The comments refer to message numbers in Figure 9.13.

1 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)2 l e t processMS =3 new ims i ms : i d e n t ;4 new k i : key ;5 i n s e r t keys ( ims i ms , k i ) ;6 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n7 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)8 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)9 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ,

10 sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)11 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n12 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n13 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n14 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n15 event begSN ( ims i ms , ck ms , i k ms ) ;16 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)17 i n ( pubChannel , (=ASSMC, =cap ms , enab l eEnc as ms : bool ,18 f r e s h ms : nonce , =f9 ( ( cap ms , enab leEnc as ms , f r e s h ms ) ,19 i k ms ) ) ) ; (∗ [Msg 8 ] ∗)

124

4G MS MME 4G HN

5. RAND, AUTN, SNid

6. RES

3. IMSI, SNid, Network Type

4. IMSI, SNid, CK, IK RAND, AUTN, XRES, KASME

2. IMSI

1.CAP

8. enableEnc, CAP, AS-MAC

3G BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid)

Verify RES = XRES

7. CAP, CK, IK

Generate RAND , MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC KASME=KDF(CK, IK, SNid)

9. AS SMC Complete Integrity protected

XAS-MAC = f9((enableEnc, CAP), IK) Verify XAS-MAC = AS-MAC

10. payload, if no encryption {payload}_CK, otherwise

Decrypt message if enableEnc_ms is true

event begSN(imsi_ms, ck_ms, ik_ms)

event endSN(imsi_sn, ck_sn, ik_sn)

event begMS_AS(imsi_sn, ck_sn, ik_sn, cap_sn)

event endMS(imsi_ms, ck_ms, ik_ms, cap_ms)

UM

TS

I L

TE

II L

TE

III U

MT

S IV

Decide enableEnc?, AS-MAC = f9((enableEnc, CAP), IK)

Figure 9.13: AKA scenario S10, version without LTE IV, annotated in accord withour model

20 out ( pubChannel , (ASSMComplete , as smcomplete msg ,21 f 9 ( as smcomplete msg , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)22 event endMS( ims i ms , ck ms , ik ms , cap ms ) ;23 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng , =f9 ( datamsg , i k ms ) ) ) ;24 (∗ [Msg 10 ] ∗)25 out ( pubChannel , s e n c r y p t a s ( s e c r e t , ck ms ) ) ;26 out ( pubChannel , s e n c i n t a s ( s e c r e t , i k ms ) ) ;27 i f enab l eEnc as ms = t r u e then28 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , ck ms ) i n 0 .29

30 (∗ p r o c e s s r e p r e s e n t i n g SN ∗)31 l e t processSN =32 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)

125

33 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)34 new s n i d s n : i d e n t ;35 out ( s ecu reChanne l , (AV REQ , ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)36 i n ( s ecu reChanne l , (=AV, =ims i s n , =sn i d s n , r and sn : nonce ,37 x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,38 ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)39 out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;40 (∗ [Msg 5 ] ∗)41 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)42 event endSN( ims i s n , ck sn , i k s n ) ;43 new f r e s h s n : nonce ;44 event begMS( ims i s n , ck sn , i k s n , cap sn ) ;45 out ( pubChannel , (ASSMC, cap sn , cap sn , f r e s h s n ,46 f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 8 ] ∗)47 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,48 =f9 ( as smcomplete msg , i k s n ) ) ) ; (∗ [Msg 9 ] ∗)49 i f cap sn = f a l s e then50 event d i s a b l eEn c ;51 out ( pubChannel , (MSG, pay load , f 9 ( pay load , i k s n ) ) ) (∗ [Msg 10 ] ∗)52 e l s e53 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ck sn ) ,54 f 9 ( s e n c r y p t a s ( pay load , ck sn ) , i k s n ) ) ) . (∗ [Msg 10 ] ∗)

The SN receives the 4G authentication vector and the UMTS cipher and integritykeys in lines 36-38. The challenge response procedure is specified in lines 39–41 inthe SN process and in lines 9-10 and 16 in the MS process. The UMTS securitymode setup procedure is the same as in the UMTS model (see Section 4.2.2), whichis specified in lines 45–46 in the SN process and in lines 17–21 in the MS process.

Scenario S10 with LTE IV

The complete model of this scenario is in Section 11 and in our repository asdissertation/models/S10_UMTS_I_LTE_II-IV_UMTS_IV.pv.

Fig. 9.14 elaborates the scenario in Fig. 9.12 with details of the ProVerif modeland shows the locations of the events which are used to specify authentication andconditional payload secrecy. Most of the code is the same as in the version withoutLTE IV. The MS, the BS, and the MME processes are defined as follows. Thecomments refer to message numbers in Figure 9.14.

1 (∗ AS SMC procedu r e i n p r o c e s s MS ∗)2 l e t pMSAS( ck ms : c ipherKey , i k ms : integKey , ims i ms : i d en t ,3 cap ms : bool ) =4 i n ( pubChannel , (=ASSMC, =cap ms , enab l eEnc as ms : bool ,5 =f9 ( ( cap ms , enab l eEnc as ms ) , i k ms ) ) ) ; (∗ [Msg 10 ] ∗)6 out ( pubChannel , (ASSMComplete , as smcomplete msg ,7 f 9 ( as smcomplete msg , i k ms ) ) ) ; (∗ [Msg 11 ] ∗)8 event endMS AS( ims i ms , ck ms , ik ms , cap ms ) ;9 i n ( pubChannel , (=MSG, datamsg : b i t s t r i ng , =f9 ( datamsg , i k ms ) ) ) ;

10 (∗ [Msg 12 ] ∗)

126

4G MS MME 4G HN

5. RAND, AUTN, SNid

6. RES

3. IMSI, SNid, Network Type

4. IMSI, SNid, CK, IK RAND, AUTN, XRES, KASME

2. IMSI

1.CAP

10. enableEnc, CAP, AS-MAC

3G BS

XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid)

Verify RES = XRES

9. CAP, CK, IK

Generate RAND , MAC = f1(Ki, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

IK = f4(Ki, RAND), AUTN=MAC KASME=KDF(CK, IK, SNid)

11. AS SMC Complete Integrity protected

7. enableEnc, CAP, NAS-MAC

KNASenc = KDF (KASME), KNASint = KDF(KASME) XNAS-MAC = EIA((enableEnc, CAP), KNASint)

Verify XNAS-MAC = NAS-MAC

8. NAS Security Mode Complete ifenableEnb ciphered , integrity protected

otherwise integrity protected

KNASenc = KDF (KASME,), KNASint = KDF(KASME,) Decide enableEnc?,

NAS-MAC = EIA((enableEnc, CAP), KNASint)

XAS-MAC = f9((enableEnc, CAP), IK) Verify XAS-MAC = AS-MAC

12. payload, if no encryption {payload}_CK, otherwise

Decrypt message if enableEnc_ms is true

event begSN(imsi_ms, snid_ms, kasme_ms)

event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn)

event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms)

event endSN(imsi_sn, snid_sn, kasme_sn)

event begMS_AS(imsi_sn, ck_sn, ik_sn, cap_sn)

event endMS_AS(imsi_ms, ck_ms, ik_ms, cap_ms)

UM

TS

I L

TE

II L

TE

III U

MT

S IV

LT

E IV

Decide enableEnc?,

AS-MAC = f9((enableEnc, CAP), IK)

Verify integrity of message 8

Figure 9.14: AKA scenario S10, version with LTE IV, annotated in accord with ourmodel

11 out ( pubChannel , s e n c r y p t a s ( s e c r e t , ck ms ) ) ;

127

12 out ( pubChannel , s e n c i n t a s ( s e c r e t , i k ms ) ) ;13 i f enab l eEnc as ms = t r u e then14 l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , ck ms ) i n 0 .15

16 (∗ p r o c e s s r e s p r e s e n t i n g MS ∗)17 l e t processMS =18 new ims i ms : i d e n t ;19 new k i : key ;20 i n s e r t keys ( ims i ms , k i ) ;21 l e t cap ms : bool = en cC a p a b i l i t y ( ) i n22 out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)23 out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)24 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ,25 sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)26 l e t r e s ms : r e s p = f2 ( k i , rand ms ) i n27 l e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i n28 l e t i k ms : i n t egKey = f4 ( k i , rand ms ) i n29 l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n30 event begSN ( ims i ms , sn id ms , kasme ms ) ;31 out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)32 l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i n33 l e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i n34 i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,35 =f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;36 (∗ [Msg 7 ] ∗)37 event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;38 out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;39 out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;40 i f enab l eEnc nas ms = f a l s e then41 out ( pubChannel , (NASSMComplete , nas smcomplete msg ,42 f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)43 pMSAS( ck ms , ik ms , ims i ms , cap ms )44 e l s e45 out ( pubChannel , (NASSMComplete , s e n c r y p t n a s ( nas smcomplete msg ,46 knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,47 knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)48 pMSAS( ck ms , ik ms , ims i ms , cap ms ) .49

50 (∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)51 l e t processBS =52 i n ( sChannelSnBts , ( ck b s : c ipherKey , i k b s : integKey ,53 i m s i b s : i d en t , cap bs : bool ) ) ;54 event begMS AS( ims i b s , ck bs , i k b s , cap bs ) ;55 out ( pubChannel , (ASSMC, cap bs , cap bs , f 9 ( ( cap bs , cap bs ) ,56 i k b s ) ) ) ; (∗ [Msg 10 ] ∗)57 i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,58 =f9 ( as smcomplete msg , i k b s ) ) ) ; (∗ [Msg 11 ] ∗)59 i f cap bs = f a l s e then60 event d i s a b l eEn c ;61 out ( pubChannel , (MSG, pay load , f 9 ( pay load , i k b s ) ) ) (∗ [Msg 12 ] ∗)62 e l s e

128

63 out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ck b s ) ,64 f 9 ( s e n c r y p t a s ( pay load , ck b s ) , i k b s ) ) ) . (∗ [Msg 12 ] ∗)65

66 (∗ p r o c e s s r e p r e s e n t i n g MME ∗)67 l e t processMME =68 i n ( pubChannel , (=CAP, cap sn : bool ) ) ; (∗ [Msg 1 ] ∗)69 i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)70 new s n i d s n : i d e n t ;71 out ( s ecu reChanne l , (AV REQ , ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)72 i n ( s ecu reChanne l , (=AV, =ims i s n , s n i d h n s n : i d en t ,73 r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,74 ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)75 out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;76 (∗ [Msg 5 ] ∗)77 i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)78 event begMS( ims i s n , s n i d hn sn , kasme sn , cap sn ) ;79 l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i n80 l e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i n81 out ( pubChannel , (NASSMC, cap sn , cap sn ,82 f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)83 i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i ng ,84 =f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)85 i f cap sn = t r u e then86 i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then87 event endSN( ims i s n , s n i d hn sn , kasme sn ) ;88 out ( sChannelSnBts , ( ck sn , i k s n , im s i s n , cap sn ) )89 e l s e 090 e l s e91 i f cap sn = f a l s e then92 i f msg nas = nas smcomplete msg then93 event endSN( ims i s n , s n i d hn sn , kasme sn ) ;94 out ( sChannelSnBts , ( ck sn , i k s n , im s i s n , cap sn ) )95 e l s e 096 e l s e 0 .

Compared with the version without LTE IV, the additional NAS SMC procedure isspecified in lines 81–84 in the MME process and in lines 34–35 and either lines 41–42or lines 45–47 depending on the encryption is enabled or not.

9.5.3 Security Property Specifications and Findings

This section presents the specifications and analysis result of the secrecy and authen-tication properties.

In both models, the properties of key secrecy, payload secrecy, and conditionalpayload secrecy are specified in the same way:

• Key Secrecy (secrecy of Ki, CK, IK, and NAS keys)not attacker (new k i ) .query attacker ( s e c r e t ) .

• Payload Secrecy

129

Table 9.7: Analysis result of S10 models

KeySecrecy

ConditionalPayloadSecrecy

Auth. ofthe MS tothe MME

Auth. ofthe MMEto the MS

Auth. ofthe BS tothe MS

PayloadSecrecy

S10 w/oLTE IV

Proved Proved Proved N/A Proved Failed

S10 w/LTE IV

Proved Proved Proved Proved Proved Failed

query attacker ( pay load ) .

• Conditional Payload Secrecyquery attacker ( pay load ) event ( d i s a b l eEn c ) .

In the version without LTE IV, the authentication properties are specified as:

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : bool ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

In the version with LTE IV, the authentication properties are specified as:

query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : bool ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : bool ;event ( endMS AS( x1 , x2 , x3 , x4 ) ) event ( begMS AS( x1 , x2 , x3 , x4 ) ) .

Table 9.7 shows the analysis result of the above properties. ProVerif proves all theproperties except the payload secrecy, because the BS could choose not to enableencryption when communicating with the MS.

130

Chapter 10Summary of Findings

This chapter summarizes the analysis results for secrecy and authentication propertiesof the 10 authentication scenarios that cover all the possible interoperation cases. Thischapter also highlights the different types of authenticity achieved by the scenarios.At the end, we summarize the attacks on these scenarios.

10.1 Secrecy and Integrity Properties

In this section, we summarize the analysis results of the secrecy properties of allthe scenarios. The conditional secrecy and key secrecy properties are proved in allscenarios. The attacker cannot get the session or long-term keys, and if encryptionis chosen by the BS, then the attacker cannot get the message payload. Payloadintegrity is not provided by any of the standards.

10.2 Authentication Properties

In this section, we discuss the analysis result of the authentication properties of allthe scenarios. In Chapter 6, we established the following terminology for the typesof the authenticity.

challenge-response Authentication is based on a random challenge and the re-sponse is used to prove that the responding party has the correct key. Forexample, the authentication of the MS to the SN in all the pure AKAs ischallenge-response authentication.

use-based proved knowledge Authentication is based on one party proving thatit possesses the correct integrity key and by using it to generate the MAC. Forexample, the authentication of the BS to the MS in UMTS is use-based provedknowledge authentication.

indirect use-based proved knowledge Authentication is indirect and based onthe use-based proved knowledge. The reasoning is that two participants con-nected by a secure channel trust each other to follow the protocol, and the onlyway one can get a derived key is by obtaining it from the other. For example,the authentication of the MSC to the MS in UMTS is indirect use-based provedknowledge authentication.

use-based proved knowledge with SNid This is like use-based proved knowl-edge authentication, but with the addition that the SNid is provided to theMS and the integrity key is derived not only from the long-term key but also

131

from the SNid. For example, the authentication of the MME to the MS in theLTE is use-based proved knowledge with SNid authentication.

As described in Chapter 6, each type of the authentication is achieved in a specificblock of the pure AKAs. Because the interoperation scenarios are built on the blocks,the blocks determine which type of the authentication is achieved.

10.2.1 Authentication of the MS to the SN

For the authentication of the MS to the SN, all the scenarios have the same typeof the authentication, that is the challenge-response authentication of the MS to theSN. The MS proves that it knows the long-term key that the HN associates with theIMSI of the MS.

10.2.2 Authentication of the SN to the MS

For the authentication of the SN to the MS, there are some variations. We considerthe scenarios and summarize them in Table 10.1.

Scenario S1 (GSM I–IV) is the pure GSM. The authentication types of GSM arediscussed in Chapter 6. GSM does not provide authentication of the SN to theMS.

Scenario S2 (UMTS I–IV) is the pure UMTS, which is also discussed in Chapter 6.UMTS provides the use-based proved knowledge authentication of the BS to theMS and the indirect use-based proved knowledge authentication of the MSC tothe MS.

Scenario S3 (LTE I–V) is the pure LTE and provides the use-based proved knowl-edge with SNid authentication of both the BS and the MME to the MS.

Scenario S4 (GSM I ‖ UMTS II’ ‖ GSM III’–IV, conv(3G AV → 2G AV))(Section 8.2) does not provide the authentication of the SN to the MS.

Scenario S5 (GSM I–III ‖ UMTS IV, conv(Kc → CK IK , VLR/SGSN))(Section 8.3) uses the UMTS SMC procedure (UMTS IV), so S5 provides thesame authentication of the SN components to the MS as in UMTS.

Scenario S6 (UMTS I–III ‖ GSM IV, conv(CK IK → Kc, VLR/SGSN))(Section 8.4) uses the GSM CMC procedure (GSM IV), so S6 does not provideauthentication of the SN to the MS as in GSM.

Scenario S7– (LTE I ‖ UMTS II–III ‖ LTE V, conv(CK IK → KASME ,MME)) (Section 9.2) uses the LTE AS SMC procedure (LTE V). Because theKASME is derived by the MME without binding the SNid , the authentication of

132

the BS to the MS is the use-based proved knowledge authentication. Becausethe NAS SMC procedure is not used in this scenario, it provides the indirectuse-based proved knowledge authentication of the MME to the MS as in UMTS.

Scenario S7 (S7– with LTE IV) (Section 9.2) is similar to S7–, but uses both NASSMC and AS SMC procedures. S7 provides the use-based proved knowledgeauthentication of both the BS and the MME to the MS.

Scenario S8 (LTE I’ ‖UMTS II–III ‖ LTE IV–V, conv(CK IK nonces → KASME ,MME)) (Section 9.3) In this scenario, the MS sends a nonce NONCEMS to theMME and the MME generates a nonce NONCEMME . The master key KASME isderived by the MME using the two nonces, CK , and IK . The knowledge of theMME to be checked by the MS is the integrity key which is derived from theKASME . To authenticate itself to the MS, the MME generates the MAC of theSMC message which contains the two nonces, the capabilities of the MS, andthe decided algorithm. In addition to proving the knowledge of the integrity,the MME also replies the challenge of the MS (NONCEMS ) using the MAC asa response. Similarly, the BS proves the knowledge of the integrity key, whichis derived from the KASME , and replies the challenge by sending the AS SMCmessage with the MAC that is generated using the integrity key. The integritykeys used by the MME and the BS bind the two nonces but not the SNid . SoS8 provides both the use-based proved knowledge and the challenge-responseauthentication of the SN components to the MS.

Scenario S9– (GSM I ‖ LTE II–III ‖ GSM IV, conv(CK IK → Kc, MME),AV = 4G AV + CK + IK) (Section 9.4) only uses GSM SMC procedure(GSM IV), so S9– does not provide authentication of the SN to the MS as inGSM.

Scenario S9 (S9– with LTE IV) (Section 9.4) uses the NAS SMC procedure(LTE IV) and the GSM SMC procedure (GSM IV), so S9 provides the use-based proved knowledge with SNid authentication of the MME to the MS anddoes not provide the authentication of the BS to the MS.

Scenario S10– (UMTS I ‖ LTE II–III ‖ UMTS IV, AV = 4G AV + CK +IK) (Section 9.5) only uses UMTS SMC procedure (UMTS IV), so the type ofthe authentication of the SN components to the MS is the same as in UMTS.

Scenario S10 (S10– with LTE IV) (Section 9.5) use both the LTE NAS SMCprocedure and the UMTS SMC procedure, so S10 provides the use-based provedknowledge with SNid authentication of the MME to the MS and the use-basedproved knowledge authentication of the BS to the MS.

Table 10.1 shows the types of authentication of the SN components to the MS achievedby all the scenarios. The keys in the parentheses are the proved knowledge. In S8, the

133

Table 10.1: Types of SN components authenticity achieved by the scenarios

Auth. of SN to MSAuth. of MSC/MME to MS Auth. of BS to MS

S1S2 indirect use-based proved knowledge (IK ) use-based proved knowledge (IK )S3 use-based proved knowledge with SNid (KNASINT ) use-based proved knowledge with SNid (KASINT )S4S5 indirect use-based proved knowledge (IK ) use-based proved knowledge (IK )S6S7- indirect use-based proved knowledge (KASINT ) use-based proved knowledge (KASINT )S7 use-based proved knowledge (KNASINT ) use-based proved knowledge (KASINT )S8 use-based proved knowledge (KNASINT ), challenge-

response (NONCEMS )use-based proved knowledge (KASINT ), challenge-response (NONCEMS )

S9-S9 use-based proved knowledge with SNid (KNASINT )S10- indirect use-based proved knowledge (IK ) use-based proved knowledge (IK )S10 use-based proved knowledge with SNid (KNASINT ) use-based proved knowledge (IK )

NONCEMS is the challenge. Empty cells mean that the corresponding authenticationis not provided by the scenario.

The authentication properties are specified by the correspondence assertionsusing the identity(ies) and the session key(s). The correspondence assertions usedto specify the authentication of the SN to the MS also include the capabilities asone parameter. This parameter is used for checking if the SN receives the correctcapabilities. If not, there might be a false base station attack. Most of the authen-tication properties specified as correspondence assertions are proved. For all provedauthentication properties, we list the parameters used in the correspondence asser-tions in Table 10.2. Because all the correspondence assertions contain session key(s)as parameters, and all the session keys are derived from the long term key Ki andthe random number RAND , the Ki and the RAND are implied in all proved corre-spondence assertions. In some scenarios, the session key(s) are derived from materials(such as nonces, SN’s identity) in addition to the Ki and the RAND . The additionalmaterials are also implied in these cases. We list the additional implied materialsinside parentheses in the table. For the correspondence assertions which are violatedby an attack scenario found by ProVerif, we list the attacks.

10.3 Attacks

In this section, we discuss the attacks listed in Table 10.2.In the models of scenario S1, S4, S6, and S9 without LTE IV, we find the known

false base station attack [77] which has the same attack scenario as in the native GSMauthentication. In this attack, the attacker intercepts the CAP message and modifiesthe capabilities of the MS as no-encryption. When the BS decides which algorithmto use, the BS has to choose not to enable encryption. Because the subsequent traffic

134

Table 10.2: Analysis results of authentication properties

Parameters inside parentheses are the implied ones in addition to RAND and Ki

Auth. of MS to SNAuth. of SN to MS

Auth. of MSC/MME to MS Auth. of BS to MSS1 IMSI ,Kc false base station attackS2 IMSI ,CK , IK IMSI ,CK , IK ,CAPS3 IMSI ,SNid ,KASME IMSI ,SNid ,KASME ,CAP IMSI ,Kenb ,CAP (SNid)S4 IMSI ,Kc false base station attackS5 IMSI ,Kc IMSI ,CK , IK ,CAPS6 IMSI ,CK , IK false base station attackS7– IMSI ,CK , IK false base station attackS7 IMSI ,CK , IK IMSI ,KASME ,CAP IMSI ,Kenb ,CAP

S8 IMSI ,CK , IKIMSI ,KASME ,CAP(NONCEMS , NONCEMME )

IMSI ,Kenb ,CAP(NONCEMS , NONCEMME )

S9– IMSI ,CK , IK false base station attackS9 IMSI ,SNid ,KASME IMSI ,SNid ,KASME ,CAP CMC attackS10– IMSI ,CK , IK IMSI ,CK , IK ,CAPS10 IMSI ,SNid ,KASME IMSI ,SNid ,KASME ,CAP IMSI ,CK , IK ,CAP

between the MS and the 2G BS is not encrypted nor integrity protected, the attackercan both eavesdrop and modify the messages.

The attack found in scenario S7 without LTE IV is similar. The attackerintercepts and modifies the capabilities of MS to no-encryption to force the 4G BSto choose not to use encryption. Although integrity protection is mandatory for thesignaling traffic of 4G BS, there is no integrity protection on the user plane traffic, sothe attack can both eavesdrop and modify the data traffic.

In the model of scenario S9 with LTE IV, we find an attack in which theattacker simply modifies the CMC message to tell the MS to use no encryption. Thisattack would be detected once the MS sends unencrypted messages to the BS.

135

Chapter 11Conclusion and Future Work

This chapter provides the conclusion of this work and recommends which blocks touse in the scenarios. This chapter also suggests directions for the future work.

In this work we study the AKA scenarios for GSM, UMTS, LTE, as well asthe interoperation cases among them. To determine the AKA scenarios in each inter-operation case, we consider all combinations of the five relevant system components(the identity module, the ME, the BS, the MSC/MME, and the HN). We classifysome cases as allowed or disallowed, based on information about component compat-ibility gleaned from the standards documents. Some cases are classified as uncertain,for lack of definite information in the standards. For each possible (allowed or un-certain) interoperation case, we identify and justify a particular AKA scenario builtfrom elements (“blocks”) of the pure GSM, UMTS, and LTE AKAs.

It turns out that 10 scenarios are needed to cover all the possible interoperationcases. Of these scenarios, 3 are the pure GSM, UMTS, and LTE; 3 involve just GSMand UMTS blocks; the remaining 4 involve LTE as well as GSM and UMTS blocks. Inmost cases, the AKA scenario is completely determined by the type and capabilitiesof the components involved. However, a few cases have multiple feasible versions ofthe scenarios which differ by whether block LTE IV is included or whether the noncein TAU request is used.

We model and analyze all the scenarios, using ProVerif, focusing on authenti-cation and secrecy properties. We find attacks in some scenarios and confirm the ab-sence of other attacks at the Dolev-Yao level of abstraction. The attacks are possiblebecause either the MS cannot verify whether the SN receives the correct capabilitiesor the decision of the encryption setting is sent to the MS unprotected. For GSMauthentication, we find the known false base station attack. For the scenarios of theinteroperation cases, we find three kind of attacks. One is the false base station attackwhich is inherited from the GSM system on S4, S6, and the version of S9 withoutLTE IV. Another attack, on one version of scenario S7, is a similar false base stationattack but with a 4G BS. The attack is prevented by including block LTE IV. In thethird attack on the AKA of scenario S9 with LTE IV, the CMC message is modified.This attack will be detected by the BS once the MS sends a message to the BS. Asidefrom these attacks, the desired authentication and secrecy properties are proved forall other cases.

In Chapter 10 we compare the authenticity achieved by the different scenarios.There are four types of authenticity: challenge-response, use-based proved knowledge,indirect use-based proved knowledge, and use-based proved knowledge with SNid. Wesummarize the types of authenticity achieved by all the authentication scenarios.

Based on our analysis, we propose the following recommendations.

136

First, since we classified some cases as uncertain cases, we suggest the standardorganization or operators clarify whether the uncertain cases are allowed or not.

Second, this work shows that model checking provides an effective way to findattacks in, and show the security of, the mobile telephony AKAs. We recommendthe protocol designers to provide analyzable formal models for future protocol speci-fications, in order to use use formal methods to check the security of AKAs, as wellas other protocols, during design process.

Third, in our analysis, we provide the message sequence diagrams of the AKAsand separate them into blocks. These blocks are used to build the authenticationscenarios for the interoperation cases. Future generations of mobile technology mightintroduce much more interoperation cases, which might also be able to built fromthe blocks of the protocols of pure technologies. We suggest to include the messagesequence diagrams with blocks in the specifications.

Fourth, Ideally, the blocks could be written a procedure in ProVerif, so themodel of a scenario could be composed automatically from the block procedures. Wehad to resort to cut-and-paste to combine blocks, because in some cases key conversionfunction need to be applied. We suggest that ProVerif’s language could be extendedso that the models of blocks could be parameterized on the key conversions.

Fifth, each of the blocks GSM III, UMTS III, and LTE III provides thechallenge-response authentication of the MS to the SN. The blocks UMTS IV andLTE IV–V provide the authentication of the SN to the MS. However, because thereis no protection for the messages in the block GSM IV, false base station attack canbe performed against the authentication scenarios ending with GSM IV (but withoutLTE IV executed before GSM IV). The false base station attack is possible becausethe MS has no way to verify that whether the SN has received the correct capabilitiesof the MS or not. In LTE IV, the capabilities of the MS is sent back to the MS inthe integrity protected message, so that the MS can confirm that the SN receives thecorrect capabilities. Therefore, executing LTE IV before GSM IV prevents the falsebase station attack. The interoperation cases involving future technologies mightalso need GSM IV (if a 2G BS is included in the interoperation cases), we suggest toinclude LTE IV before GSM IV to prevent the false base station attack.

Sixth, because the use-based proved knowledge with SNid authentication achieveshigher level of authenticity than use-based proved knowledge authentication or indi-rect use-based proved knowledge authentication, and the use-based proved knowledgewith SNid authentication is achieved by the scenarios with LTE II–IV, we recommendthe AKAs should support and use the blocks LTE II–IV. Specifically, the session keyshould be generated in the HN with the identity of the SN and be used in latterprotocol steps.

Seventh, when modeling the LTE AKA, we choose to transmit the identity ofthe SN to the MS in the authentication challenge message (see Section 5.2), becausethe specification [8] does not specify how the MS obtains the identity of the SN. Infact, the SN broadcasts his identity in earlier stage when the MS selects the serving

137

network. We recommend to add the transmission of the SN’s identity to the MS inthe protocol specification.

For future work, we would like to analyze the handover in GSM, UMTS, andLTE, as well as across the technologies. Handover is the mechanisms supporting mo-bility in the context of ongoing phone call or data exchange. We also are interestedin exploring the interworking between 4G and non-3GPP networks. In the currentwork, we assume the communication in the network side is secure. For future work,we can investigate what can happen if the communication between the BS and theMSC/MME can be controlled by the Dolev-Yao attacker. Furthermore, the commu-nication between the SN and the HN might also be treated that way.

As stated in the recommendations, we suggest to use automated composedmodels from the models of the blocks to analyze interoperation cases involving futuregenerations of protocols. We would like to experiment with this idea on the modelsof interoperation scenarios introduced in this work.

138

Appendix A

Complete code listings for all scenarios. All models are checked by ProVerif version1.86pl4.S1. GSM I – IV

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key . (∗ Permanent key ∗)type i d e n t . (∗ I d e n t i t y o f MS ∗)type nonce . (∗ Random number ∗)type msgHdr . (∗ Constant message heade r ∗)type r e s p . (∗ Response ∗)type s e s sKey . (∗ Se s s i o n key ∗)

(∗ Constant message heade r s ∗)const CAP: msgHdr . (∗ Header o f Msg 1 ∗)const ID : msgHdr . (∗ Header o f Msg 2 ∗)const AV REQ : msgHdr . (∗ Header o f Msg 3 ∗)const AV: msgHdr . (∗ Header o f Msg 4 ∗)const CHALLENGE: msgHdr . (∗ Header o f Msg 5 ∗)const RES : msgHdr . (∗ Header o f Msg 6 ∗)const CMC: msgHdr . (∗ Header o f Msg 7 ∗)const CMComplete : msgHdr . (∗ Header o f Msg 8 ∗)const MSG: msgHdr . (∗ Header o f Msg 9 ∗)

(∗ Func t i on s ∗)fun a3 ( nonce , key ) : r e s p .fun a8 ( nonce , key ) : s e s sKey .fun s e n c r y p t ( b i t s t r i n g , s e s sKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : s e s sKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.reduc e n cC a p a b i l i t y ( ) = t r u e ; e n cC a p a b i l i t y ( ) = f a l s e .

(∗ The key t a b l e c o n s i s t s o f p a i r s ( i d en t , key ) sha r ed betweenthe MS and the HN. Table i s not a c c e s s i b l e by the a t t a c k e r ∗)

t a b l e keys ( i d en t , key ) .

(∗ Fresh v a l u e not i n i t i a l l y known to a t t a c k e r ∗)f r e e pay load : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f on l y ∗)(∗ dea l w i th the s e c r e c y o f p r i v a t e f r e e names ∗)(∗ s e c r e tKc i s s e c r e t i f and on l y i f a l l kc s a r e s e c r e t ∗)f r e e s e c r e tKc : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tKc ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , s e s sKey ) .event endSN( iden t , s e s sKey ) .event begMS( iden t , s e s sKey ) .event endMS( iden t , s e s sKey ) .event d i s a b l eEn c .

query x1 : i d en t , x2 : s e s sKey ;

139

event ( endSN( x1 , x2 ) ) event ( begSN ( x1 , x2 ) ) .query x1 : i d en t , x2 : s e s sKey ;

event (endMS( x1 , x2 ) ) event (begMS( x1 , x2 ) ) .

(∗ When the a t t a c k e r knows pay load ,the even t d i s a b l eEn c has been execu ted . ∗)

query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .

l e t processMS =(∗ R e g i s t r a t i o n and se tup ∗)new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ; (∗ pre−sha r ed i d e n t i t y and key ∗)l e t cap ms : boo l = en cC a p a b i l i t y ( ) i n (∗ choose c a p a b i l i t y ∗)(∗ The p r o t o c o l ∗)out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)(∗ Compute r e s pon s e ∗)l e t r e s ms : r e s p = a3 ( rand ms , k i ) i n(∗ Compute e n c r y p t i o n key ∗)l e t kc ms : s e s sKey = a8 ( rand ms , k i ) i n(∗ MS i s a u t h e n t i c a t i n g i t s e l f to SN ∗)event begSN ( ims i ms , kc ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)i n ( pubChannel , (=CMC, enab leEnc ms : boo l ) ) ; (∗ [Msg 7 ] ∗)event endMS( ims i ms , kc ms ) ;out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)out ( pubChannel , s e n c r y p t ( sec re tKc , kc ms ) ) ;i f enab leEnc ms = t r u e then

l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n 0 .

l e t processSN =i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,

x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then (∗ Check r e s pon s e ∗)

event endSN( ims i hn sn , k c sn ) ;event begMS( ims i hn sn , k c sn ) ;out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) . (∗ [Msg 9 ] ∗)

l e t processHN =i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)new rand hn : nonce ; (∗ Genera te a f r e s h random number ∗)get keys (= ims i hn , k i h n ) i n (∗ attempt to l ook up key ∗)l e t x r e s h n : r e s p = a3 ( rand hn , k i h n ) i nl e t kc hn : s e s sKey = a8 ( rand hn , k i h n ) i n(∗ Send out a u t h e n t i c a t i o n v e c t o r [Msg 4 ] ∗)out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn , kc hn ) ) .

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

140

S2. UMTS I – IV

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const SMC: msgHdr .const SMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : msgMac .fun s e n c r y p t ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.

reduc e n cC a p a b i l i t y ( ) = t r u e ; e n cC a p a b i l i t y ( ) = f a l s e .

(∗ To t e s t s e c r e c y o f the i n t e g r i t y key , ∗)(∗ use them as s e s s i o n keys to en c r yp t a f r e e p r i v a t e name ∗)fun s e n c r y p t I n t e g ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c r y p t I n t e g ( s e n c r y p t I n t e g (m, k ) , k ) = m.

(∗ the t a b l e i d e n t / keys , the key t a b l e c o n s i s t s o f p a i r s ( i d en t , key )sha r ed between MS and HN Table i s not a c c e s s i b l e by the a t t a c k e r ∗)

t a b l e keys ( i d en t , key ) .

f r e e smcompleteMsg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f on l y ∗)(∗ dea l w i th the s e c r e c y o f p r i v a t e f r e e names ∗)(∗ s e c r e tCk i s s e c r e t i f and on l y i f a l l cks a r e s e c r e t ∗)f r e e s e c r e tCk : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tCk ) .

(∗ s e c r e t I k i s s e c r e t i f and on l y i f a l l i k s a r e s e c r e t ∗)f r e e s e c r e t I k : b i t s t r i n g [ p r i v a t e ] .

141

query a t t a cke r ( s e c r e t I k ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , c ipherKey , integKey , boo l ) .event endMS( iden t , c ipherKey , integKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

event d i s a b l eEn c .query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .

l e t processMS =(∗ r e g i s t r a t i o n and se tup ∗)new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i n (∗ choose c a p a b i l i t y ∗)out ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

mac ms : mac ) ) ; (∗ [Msg 5 ] ∗)i f f 1 ( k i , rand ms ) = mac ms then

l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)i n ( pubChannel , (=SMC, enab leEnc ms : bool , =cap ms ,

f r e s h ms : nonce , =f9 ( ( enableEnc ms , cap ms , f r e s h ms ) ,i k ms ) ) ) ; (∗ [Msg 7 ] ∗)

event endMS( ims i ms , ck ms , ik ms , cap ms ) ;out ( pubChannel , ( SMComplete , f 9 ( smcompleteMsg , i k ms ) ) ) ;

(∗ [Msg 8 ] ∗)i n ( pubChannel , (=MSG, msg : b i t s t r i n g , f r e sh msg ms : nonce ,

=f9 ( (msg , f r e sh msg ms ) , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)out ( pubChannel , s e n c r y p t ( sec r e tCk , ck ms ) ) ;out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;i f enab leEnc ms = t r u e then

l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , ck ms ) i n 0 .

l e t processSN =i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,

x r e s s n : re sp , c k sn : c ipherKey , i k s n : integKey ,mac sn : mac ) ) ; (∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then

event endSN( ims i hn sn , ck sn , i k s n ) ;new f r e s h s n : nonce ;event begMS( ims i hn sn , ck sn , i k s n , cap sn ) ;out ( pubChannel , (SMC, cap sn , cap sn , f r e s h s n ,

f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=SMComplete , =f9 ( smcompleteMsg , i k s n ) ) ) ;

142

(∗ [Msg 8 ] ∗)new f r e s h msg s n : nonce ;i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f r e s h msg sn ,

f 9 ( ( pay load , f r e s h msg s n ) , i k s n ) ) ) (∗ [Msg 9 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t ( pay load , ck sn ) , f r e s h msg sn ,f 9 ( ( s e n c r y p t ( pay load , ck sn ) , f r e s h msg s n ) , i k s n ) ) ) .

(∗ [Msg 9 ] ∗)

l e t processHN =i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nout ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn ,

ck hn , i k hn , mac hn ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S3. LTE I – V

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between MME and HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .(∗ Secure channe l between MME and BS ∗)f r e e sChanne lSnBts : channe l [ p r i v a t e ] .

type key . (∗ pre−sha r ed Ki ∗)type i d e n t . (∗ i d e n t i t y o f the MS and the SN ∗)type nonce . (∗ random number ∗)type msgHdr . (∗ message heade r ∗)type r e s p . (∗ r e s pon s e ∗)type c i phe rKey . (∗ c i p h e r key i n UMTS a u t h e n t i c a t i o n v e c t o r s ∗)type i n t egKey . (∗ i n t e g r i t y key i n UMTS a u t h e n t i c a t i o n v e c t o r s ∗)type mac . (∗ mac i n a u t h e n t i c a t i o n v e c t o r s ∗)type msgMac . (∗ i n t e g r i t y p r o t e c t i o n o f messages ∗)type asmeKey . (∗ K ASME ∗)type nasEncKey . (∗ NAS en c r y p t i o n key ∗)type nas In tKey . (∗ NAS i n e g e r i t y key ∗)type enbKey . (∗ t ype o f K enb ∗)type asEncKey . (∗ AS en c r y p t i o n key ∗)type a s I n tKey . (∗ AS i n t e g r i t y key ∗)type upEncKey . (∗ UP en c r y p t i o n key ∗)

(∗ Constant message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .

143

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun kd f enb ( asmeKey ) : enbKey .fun k d f a s e n c ( enbKey ) : asEncKey .fun k d f a s i n t ( enbKey ) : a s I n tKey .fun kd f up enc ( enbKey ) : upEncKey .fun f i n t e g a s ( b i t s t r i n g , a s I n tKey ) : msgMac .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , asEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : asEncKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , a s I n tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : a s I n tKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.fun s enc up ( b i t s t r i n g , upEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : upEncKey ;

sdec up ( senc up (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ The t a b l e i d e n t / keys The key t a b l e c o n s i s t s o f p a i r s ( i d en t , key )sha r ed between MS and HN Table i s not a c c e s s i b l e by the a t t a c k e r ∗)

t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , i d en t , asmeKey ) .event endSN( iden t , i d en t , asmeKey ) .event begMS( iden t , i d en t , asmeKey , boo l ) .event endMS( iden t , i d en t , asmeKey , boo l ) .event begMS ENB( iden t , enbKey , boo l ) .event endMS ENB( iden t , enbKey , boo l ) .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .

query a t t a cke r ( pay load ) .query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( s e c r e t ) .query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;

event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

144

query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

query x1 : i d en t , x2 : enbKey , x3 : boo l ;event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

(∗ AS SMC procedu r e i n p r o c e s s MS ∗)l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : boo l ) =

l e t kenb ms : enbKey = kd f enb ( kasme ms ) i nl e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i nl e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i nl e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i ni n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s

( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)out ( pubChannel , (ASSMComplete , as smcomplete msg ,

f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 11 ] ∗)event endMS ENB( ims i ms , kenb ms , cap ms ) ;i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ,

=f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 12 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms ) i n 0 .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ;out ( pubChannel , ( ID , ims i ms ) ) ;i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

=f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i nout ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i nl e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i ni n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,

=f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;(∗ [Msg 7 ] ∗)

event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;event begSN ( ims i ms , sn id ms , kasme ms ) ;i f enab l eEnc nas ms = f a l s e then

out ( pubChannel , (NASSMComplete , nas smcomplete msg ,f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)

pMSAS( kasme ms , ims i ms , cap ms )e l s e

out ( pubChannel , (NASSMComplete ,s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)

pMSAS( kasme ms , ims i ms , cap ms ) .

(∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)l e t processENB =

145

i n ( sChannelSnBts , ( kasme enb : asmeKey , im s i e nb : i d en t ,cap enb : boo l ) ) ;

l e t kenb enb : enbKey = kd f enb ( kasme enb ) i nl e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i nl e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i nl e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i nevent begMS ENB( ims i enb , kenb enb , cap enb ) ;out ( pubChannel , (ASSMC, cap enb ,

f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) , k a s i n t e n b ) ) ) ; (∗ [Msg 10 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 11 ] ∗)i f cap enb = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )

(∗ [Msg 12 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .

(∗ [Msg 12 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g MME ∗)l e t processMME =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new s n i d s n : i d e n t ;out ( s ecu reChanne l , (AV REQ, ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , =sn i d s n , r and sn : nonce ,

x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ) ) ; (∗ [Msg 4 ] ∗)out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;

(∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)event begMS( ims i s n , s n i d s n , kasme sn , cap sn ) ;l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i nl e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i nout ( pubChannel , (NASSMC, cap sn , cap sn ,

f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i n g ,

=f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)i f cap sn = t r u e then

i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg thenevent endSN( ims i s n , s n i d s n , kasme sn ) ;out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )

e l s e 0e l s e

i f cap sn = f a l s e theni f msg nas = nas smcomplete msg then

event endSN( ims i s n , s n i d s n , kasme sn ) ;out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )

e l s e 0e l s e 0 .

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;(∗ [Msg 3 ] ∗)

new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i nout ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn ,

x r e s hn , mac hn , kasme hn ) ) . (∗ [Msg 4 ] ∗)

146

p roce s s( ( ! processMS ) | ( ! processMME ) | ( ! processENB ) | ( ! processHN ) )

S4. GSM I ‖ UMTS II’ ‖ GSM III’–IV, convert(3G AV → 2G AV)

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .type s e s sKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const CMC: msgHdr .const CMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : msgMac .fun c2 ( r e s p ) : r e s p .fun c3 ( c ipherKey , i n t egKey ) : s e s sKey .fun s e n c r y p t ( b i t s t r i n g , s e s sKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : s e s sKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ The t a b l e i d e n t / keys . The key t a b l e c o n s i s t s o f p a i r s ( i d en t , key )sha r ed between MS and HN. Table i s not a c c e s s i b l e by the a t t a c k e r ∗)

t a b l e keys ( i d en t , key ) .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f ∗)f r e e s e c r e tKc : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tKc ) .

not a t t a cke r (new k i ) .

147

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , s e s sKey ) .event endSN( iden t , s e s sKey ) .event begMS( iden t , s e s sKey ) .event endMS( iden t , s e s sKey ) .event d i s a b l eEn c .

query x1 : i d en t , x2 : s e s sKey ;event ( endSN( x1 , x2 ) ) event ( begSN ( x1 , x2 ) ) .

query x1 : i d en t , x2 : s e s sKey ;event (endMS( x1 , x2 ) ) event (begMS( x1 , x2 ) ) .

(∗ When the a t t a c k e r knows pay load , the even td i s a b l eEn c has been execu ted . ∗)

query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .

(∗ Proce s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms u : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t r e s ms g : r e s p = c2 ( r e s ms u ) i nl e t kc ms : s e s sKey = c3 ( ck ms , i k ms ) i nevent begSN ( ims i ms , kc ms ) ;out ( pubChannel , (RES , r e s ms g ) ) ; (∗ [Msg 6 ] ∗)i n ( pubChannel , (=CMC, enab leEnc ms : boo l ) ) ; (∗ [Msg 7 ] ∗)event endMS( ims i ms , kc ms ) ;out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)out ( pubChannel , s e n c r y p t ( sec re tKc , kc ms ) ) ;i f enab leEnc ms = t r u e then

l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n0 .

l e t processSN =i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,

x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then

event endSN( ims i hn sn , k c sn ) ;event begMS( ims i hn sn , k c sn ) ;out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) . (∗ [Msg 9 ] ∗)

l e t processHN =i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)new rand hn : nonce ;

148

get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n u : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t x r e s h n g : r e s p = c2 ( x r e s h n u ) i nl e t kc hn : s e s sKey = c3 ( ck hn , i k h n ) i nout ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn g , kc hn ) ) .

(∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S5. GSM I–III ‖ UMTS IV, conv(Kc → CK IK , VLR/SGSN)

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type s e s sKey .type c i phe rKey .type i n t egKey .type mac .type msgMac .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const SMC: msgHdr .const SMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun a3 ( nonce , key ) : r e s p .fun a8 ( nonce , key ) : s e s sKey .fun c4 ( se s sKey ) : c i phe rKey .fun c5 ( se s sKey ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : msgMac .fun s e n c r y p t ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.fun s e n c r y p t S e s s ( b i t s t r i n g , s e s sKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : s e s sKey ;

s d e c r y p t S e s s ( s e n c r y p t S e s s (m, k ) , k ) = m.

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ To t e s t s e c r e c y o f the i n t e g r i t y key , ∗)(∗ use them as s e s s i o n keys to en c r yp t a f r e e p r i v a t e name ∗)fun s e n c r y p t I n t e g ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .

149

reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;s d e c r y p t I n t e g ( s e n c r y p t I n t e g (m, k ) , k ) = m.

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

f r e e smcompleteMsg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f on l y ∗)(∗ dea l w i th the s e c r e c y o f p r i v a t e f r e e names ∗)(∗ s e c r e tCk i s s e c r e t i f and on l y i f a l l cks a r e s e c r e t ∗)f r e e s e c r e tCk : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tCk ) .

(∗ s e c r e t I k i s s e c r e t i f and on l y i f a l l i k s a r e s e c r e t ∗)f r e e s e c r e t I k : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t I k ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , s e s sKey ) .event endSN( iden t , s e s sKey ) .event begMS( iden t , c ipherKey , integKey , boo l ) .event endMS( iden t , c ipherKey , integKey , boo l ) .

query x1 : i d en t , x2 : s e s sKey ;event ( endSN( x1 , x2 ) ) event ( begSN ( x1 , x2 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .

(∗ Proce s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = a3 ( rand ms , k i ) i nl e t kc ms : s e s sKey = a8 ( rand ms , k i ) i nevent begSN ( ims i ms , kc ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t ck ms : c i phe rKey = c4 ( kc ms ) i nl e t i k ms : i n t egKey = c5 ( kc ms ) i ni n ( pubChannel , (=SMC, enab leEnc ms : bool , =cap ms , f r e s h ms : nonce ,

=f9 ( ( enableEnc ms , cap ms , f r e s h ms ) , i k ms ) ) ) ; (∗ [Msg 7 ] ∗)event endMS( ims i ms , ck ms , ik ms , cap ms ) ;out ( pubChannel , ( SMComplete , f 9 ( smcompleteMsg , i k ms ) ) ) ;

(∗ [Msg 8 ] ∗)i n ( pubChannel , (=MSG, msg : b i t s t r i n g , f r e sh msg ms : nonce ,

=f9 ( (msg , f r e sh msg ms ) , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)

150

out ( pubChannel , s e n c r y p t S e s s ( s e c r e t , kc ms ) ) ;out ( pubChannel , s e n c r y p t ( sec r e tCk , ck ms ) ) ;out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;i f enab leEnc ms = t r u e then

l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , ck ms ) i n 0 .

l e t processSN =i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,

x r e s s n : re sp , k c sn : s e s sKey ) ) ; (∗ [Msg 4 ] ∗)out ( pubChannel , (CHALLENGE, r and sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then

event endSN( ims i hn sn , k c sn ) ;l e t ck sn : c i phe rKey = c4 ( kc sn ) i nl e t i k s n : i n t egKey = c5 ( kc sn ) i nnew f r e s h s n : nonce ;event begMS( ims i hn sn , ck sn , i k s n , cap sn ) ;out ( pubChannel , (SMC, cap sn , cap sn , f r e s h s n ,

f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=SMComplete , =f9 ( smcompleteMsg , i k s n ) ) ) ;

(∗ [Msg 8 ] ∗)new f r e s h msg s n : nonce ;i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f r e s h msg sn ,

f 9 ( ( pay load , f r e s h msg s n ) , i k s n ) ) ) (∗ [Msg 9 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t ( pay load , ck sn ) , f r e s h msg sn ,f 9 ( ( s e n c r y p t ( pay load , ck sn ) , f r e s h msg s n ) , i k s n ) ) ) .

(∗ [Msg 9 ] ∗)

(∗ Proce s s r e p r e s e n t i n g HN ∗)l e t processHN =

(∗ Rece i v e a u t h e n t i c a t i o n v e c t o r r e q u e s t [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ;new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t x r e s h n : r e s p = a3 ( rand hn , k i h n ) i nl e t kc hn : s e s sKey = a8 ( rand hn , k i h n ) i n(∗ Send out a u t h e n t i c a t i o n v e c t o r [Msg 4 ] ∗)out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn , kc hn ) ) .

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S6. UMTS I–III ‖ GSM IV, conv(CK IK → Kc, VLR/SGSN)

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the MS and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .

151

type i n t egKey .type s e s sKey .type mac .type msgMac .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const CMC: msgHdr .const CMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : msgMac .fun c3 ( c ipherKey , i n t egKey ) : s e s sKey .fun s e n c r y p t ( b i t s t r i n g , s e s sKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : s e s sKey ;

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.

(∗ To t e s t s e c r e c y o f the c i p h e r key , ∗)fun s e n c r y p tC i p h e r ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

s d e c r y p tC i p h e r ( s e n c r y p tC i p h e r (m, k ) , k ) = m.fun s e n c r y p t I n t e g ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c r y p t I n t e g ( s e n c r y p t I n t e g (m, k ) , k ) = m.

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f on l y ∗)(∗ dea l w i th the s e c r e c y o f p r i v a t e f r e e names ∗)(∗ s e c r e tKc i s s e c r e t i f and on l y i f a l l kc s i s s e c r e t ∗)f r e e s e c r e tKc : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tKc ) .

(∗ s e c r e tCk i s s e c r e t i f and on l y i f a l l cks a r e s e c r e t ∗)f r e e s e c r e tCk : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e tCk ) .f r e e s e c r e t I k : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t I k ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , s e s sKey ) .event endMS( iden t , s e s sKey ) .

152

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : s e s sKey ;event (endMS( x1 , x2 ) ) event (begMS( x1 , x2 ) ) .

event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .

(∗ Proce s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , mac ms : mac ) ) ;

(∗ [Msg 5 ] ∗)i f f 1 ( k i , rand ms ) = mac ms then

l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t kc ms : s e s sKey = c3 ( ck ms , i k ms ) i ni n ( pubChannel , (=CMC, enab leEnc ms : boo l ) ) ; (∗ [Msg 7 ] ∗)event endMS( ims i ms , kc ms ) ;out ( pubChannel , CMComplete ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=MSG, msg : b i t s t r i n g ) ) ; (∗ [Msg 9 ] ∗)out ( pubChannel , s e n c r y p t ( sec re tKc , kc ms ) ) ;out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t I k , i k ms ) ) ;out ( pubChannel , s e n c r y p tC i p h e r ( s ec r e tCk , ck ms ) ) ;i f enab leEnc ms = t r u e then

l e t msgcontent : b i t s t r i n g = sde c r y p t (msg , kc ms ) i n 0 .

(∗ Proce s s r e s p r e s e n t i n g SN ∗)l e t processSN =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , r and sn : nonce ,

x r e s s n : re sp , c k sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ;(∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then

event endSN( ims i hn sn , ck sn , i k s n ) ;l e t kc sn : s e s sKey = c3 ( ck sn , i k s n ) i nevent begMS( ims i hn sn , k c sn ) ;out ( pubChannel , (CMC, cap sn ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , =CMComplete ) ; (∗ [Msg 8 ] ∗)i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 9 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t ( pay load , k c sn ) ) ) .

(∗ [Msg 9 ] ∗)

(∗ Proce s s r e p r e s e n t i n g HN ∗)l e t processHN =

(∗ Rece i v e a u t h e n t i c a t i o n v e c t o r r e q u e s t [Msg 3 ] ∗)

153

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ;new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i n(∗ Send out a u t h e n t i c a t i o n v e c t o r [Msg 4 ] ∗)out ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn ,

ck hn , i k hn , mac hn ) ) .

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S7–. LTE I ‖ UMTS II–III ‖ LTE V, conv(CK IK → KASME , MME)

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type asmeKey .type enbKey .type asEncKey .type a s I n tKey .type upEncKey .type mac .type msgMac .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun kdf asme ( c ipherKey , i n t egKey ) : asmeKey .fun kd f enb ( asmeKey ) : enbKey .fun k d f a s e n c ( enbKey ) : asEncKey .fun k d f a s i n t ( enbKey ) : a s I n tKey .fun kd f up enc ( enbKey ) : upEncKey .fun f i n t e g a s ( b i t s t r i n g , a s I n tKey ) : msgMac .fun s e n c r y p t ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

154

s d e c r y p t ( s e n c r y p t (m, k ) , k ) = m.fun s e n c r y p t I n t e g ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c r y p t I n t e g ( s e n c r y p t I n t e g (m, k ) , k ) = m.fun s enc ryptEnb ( b i t s t r i n g , enbKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : enbKey ;

sdec ryptEnb ( senc ryptEnb (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , asEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : asEncKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.

(∗Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

(∗ The s t anda rd s e c r e c y q u e r i e s o f P r oVe r i f on l y ∗)(∗ dea l w i th the s e c r e c y o f p r i v a t e f r e e names ∗)f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS ENB( iden t , enbKey , boo l ) .event endMS ENB( iden t , enbKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : enbKey , x3 : boo l ;event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

l e t processMS =new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , mac ms : mac ) ) ;

(∗ [Msg 5 ] ∗)i f f 1 ( k i , rand ms ) = mac ms then

l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t kasme ms = kdf asme ( ck ms , i k ms ) i nl e t kenb ms : enbKey = kd f enb ( kasme ms ) i n

155

l e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i nl e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i nl e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i ni n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s

( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)out ( pubChannel , (ASSMComplete , as smcomplete msg ,

f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)event endMS ENB( ims i ms , kenb ms , cap ms ) ;i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ,

=f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)out ( pubChannel , s e n c r y p t ( s e c r e t , ck ms ) ) ;out ( pubChannel , s e n c r y p t I n t e g ( s e c r e t , i k ms ) ) ;out ( pubChannel , s enc ryp tEnb ( s e c r e t , kenb ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms )i n 0 .

l e t processSN =i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , r and sn : nonce , x r e s s n : re sp ,

c k sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ; (∗ [Msg 4 ] ∗)out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=RES , r e s s n : r e s p ) ) ; (∗ [Msg 6 ] ∗)i f r e s s n = x r e s s n then

event endSN( ims i s n , ck sn , i k s n ) ;l e t kasme sn = kdf asme ( ck sn , i k s n ) i nl e t kenb sn : enbKey = kd f enb ( kasme sn ) i nl e t ka s en c sn : asEncKey = kd f a s e n c ( kenb sn ) i nl e t k a s i n t s n : a s I n tKey = k d f a s i n t ( kenb sn ) i nl e t kupenc sn : upEncKey = kd f up enc ( kenb sn ) i nevent begMS ENB( ims i s n , kenb sn , cap sn ) ;out ( pubChannel , (ASSMC, cap sn , f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap sn ) ,

k a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f i n t e g a s ( as smcomplete msg , k a s i n t s n ) ) ) ; (∗ [Msg 9 ] ∗)i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t s n ) ) )

(∗ [Msg 10 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k a s en c sn ) ,f i n t e g a s ( s e n c r y p t a s ( pay load , k a s en c sn ) , k a s i n t s n ) ) ) .

(∗ [Msg 10 ] ∗)

l e t processHN =i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 3 ] ∗)new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nout ( s ecu reChanne l , (AV, ims i hn , rand hn , x r e s hn , ck hn ,

i k hn , mac hn ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S7. LTE I ‖ UMTS II–III ‖ LTE IV–V, conv(CK IK → KASME , MME)

156

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .type asmeKey .type nasEncKey .type nas In tKey .type enbKey .type asEncKey .type a s I n tKey .type upEncKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun kdf asme ( c ipherKey , i n t egKey ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun kd f enb ( asmeKey ) : enbKey .fun k d f a s e n c ( enbKey ) : asEncKey .fun k d f a s i n t ( enbKey ) : a s I n tKey .fun kd f up enc ( enbKey ) : upEncKey .fun f i n t e g a s ( b i t s t r i n g , a s I n tKey ) : msgMac .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , asEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : asEncKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

157

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , a s I n tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : a s I n tKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.fun s enc up ( b i t s t r i n g , upEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : upEncKey ;

sdec up ( senc up (m, k ) , k ) = m.

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , asmeKey , boo l ) .event endMS( iden t , asmeKey , boo l ) .event begMS ENB( iden t , enbKey , boo l ) .event endMS ENB( iden t , enbKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : asmeKey , x3 : boo l ;event (endMS( x1 , x2 , x3 ) ) event (begMS( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : enbKey , x3 : boo l ;event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

(∗ AS SMC procedu r e i n p r o c e s s MS ∗)l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : boo l ) =

l e t kenb ms : enbKey = kd f enb ( kasme ms ) i nl e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i nl e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i nl e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i ni n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s

( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)event endMS ENB( ims i ms , kenb ms , cap ms ) ;out ( pubChannel , (ASSMComplete , as smcomplete msg ,

f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ,

=f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 10 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms )i n 0 .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;

158

i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ) ) ;

(∗ [Msg 3 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 4 ] ∗)l e t kasme ms : asmeKey = kdf asme ( ck ms , i k ms ) i nl e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i nl e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i ni n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,

=f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;(∗ [Msg 5 ] ∗)

event endMS( ims i ms , kasme ms , cap ms ) ;out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;i f enab l eEnc nas ms = f a l s e then

out ( pubChannel , (NASSMComplete , nas smcomplete msg ,f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 6 ] ∗)

pMSAS( kasme ms , ims i ms , cap ms )e l s e

out ( pubChannel , (NASSMComplete , s e n c r y p t n a s ( nas smcomplete msg ,knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 6 ] ∗)

pMSAS( kasme ms , ims i ms , cap ms ) .

(∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)l e t pENB( kasme enb : asmeKey , im s i e nb : i d en t , cap enb : boo l ) =

l e t kenb enb : enbKey = kd f enb ( kasme enb ) i nl e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i nl e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i nl e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i nevent begMS ENB( ims i enb , kenb enb , cap enb ) ;out ( pubChannel , (ASSMC, cap enb , f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) ,

k a s i n t e n b ) ) ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 9 ] ∗)i f cap enb = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )

(∗ [Msg 10 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .

(∗ [Msg 10 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g MME and HN ∗)l e t processMMEHN =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new r and sn : nonce ;get keys (= ims i s n , k i s n ) i nl e t mac sn : mac = f1 ( k i s n , r and sn ) i nl e t x r e s s n : r e s p = f2 ( k i s n , r and sn ) i nl e t ck sn : c i phe rKey = f3 ( k i s n , r and sn ) i nl e t i k s n : i n t egKey = f4 ( k i s n , r and sn ) i nout ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 3 ] ∗)i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 4 ] ∗)event endSN( ims i s n , ck sn , i k s n ) ;l e t kasme sn : asmeKey = kdf asme ( ck sn , i k s n ) i n

159

l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i nl e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i nevent begMS( ims i s n , kasme sn , cap sn ) ;out ( pubChannel , (NASSMC, cap sn , cap sn ,

f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 5 ] ∗)i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i n g ,

=f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 6 ] ∗)i f cap sn = t r u e then

i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg thenpENB( kasme sn , im s i s n , cap sn )

e l s e 0e l s e

i f msg nas = nas smcomplete msg thenpENB( kasme sn , im s i s n , cap sn )

e l s e 0 .

p roce s s( ( ! processMS ) | ( ! processMMEHN ) )

S8. LTE I’ ‖ UMTS II–III ‖ LTE IV–V, conv(CK IK nonces → KASME ,MME)

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the MME and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .(∗ Secure channe l between the MME and the BS ∗)f r e e sChanne lSnBts : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .type asmeKey .type nasEncKey .type nas In tKey .type enbKey .type asEncKey .type a s I n tKey .type upEncKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .const NONCE TAU: msgHdr .

(∗ Func t i on s ∗)

160

fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun kdf asme ( c ipherKey , integKey , nonce , nonce ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun kd f enb ( asmeKey ) : enbKey .fun k d f a s e n c ( enbKey ) : asEncKey .fun k d f a s i n t ( enbKey ) : a s I n tKey .fun kd f up enc ( enbKey ) : upEncKey .fun f i n t e g a s ( b i t s t r i n g , a s I n tKey ) : msgMac .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , asEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : asEncKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , a s I n tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : a s I n tKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.fun s enc up ( b i t s t r i n g , upEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : upEncKey ;

sdec up ( senc up (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , c ipherKey , integKey , boo l ) .event endMS( iden t , c ipherKey , integKey , boo l ) .event begMS ENB( iden t , enbKey , boo l ) .event endMS ENB( iden t , enbKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

161

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

query x1 : i d en t , x2 : enbKey , x3 : boo l ;event (endMS ENB( x1 , x2 , x3 ) ) event (begMS ENB( x1 , x2 , x3 ) ) .

(∗ AS SMC procedu r e i n p r o c e s s MS ∗)l e t pMSAS( kasme ms : asmeKey , ims i ms : i d en t , cap ms : boo l ) =

l e t kenb ms : enbKey = kd f enb ( kasme ms ) i nl e t kasenc ms : asEncKey = kd f a s e n c ( kenb ms ) i nl e t ka s i n t ms : a s I n tKey = k d f a s i n t ( kenb ms ) i nl e t kupenc ms : upEncKey = kd f up enc ( kenb ms ) i ni n ( pubChannel , (=ASSMC, enab l eEnc as ms : bool , =f i n t e g a s

( b o o l 2 b i t s t r i n g ( enab l eEnc as ms ) , k a s i n t ms ) ) ) ; (∗ [Msg 11 ] ∗)out ( pubChannel , (ASSMComplete , as smcomplete msg ,

f i n t e g a s ( as smcomplete msg , k a s i n t ms ) ) ) ; (∗ [Msg 12 ] ∗)event endMS ENB( ims i ms , kenb ms , cap ms ) ;i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ,

=f i n t e g a s ( datamsg , k a s i n t ms ) ) ) ; (∗ [Msg 13 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , kasenc ms ) ) ;out ( pubChannel , s e n c i n t a s ( s e c r e t , k a s i n t ms ) ) ;out ( pubChannel , s enc up ( s e c r e t , kupenc ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kasenc ms ) i n 0 .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)new nonce ms : nonce ;out ( pubChannel , (NONCE TAU, nonce ms ) ) ; (∗ [Msg 3 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ) ) ;

(∗ [Msg 6 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,

=nonce ms , nonce mme ms : nonce , nas mac : msgMac ) ) ; (∗ [Msg 8 ] ∗)l e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , nonce ms ,

nonce mme ms ) i nl e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i nl e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i ni f ( nas mac = f i n t e g n a s ( ( enab leEnc nas ms , cap ms , nonce ms ,

nonce mme ms ) , kna s i n t ms ) ) thenevent endMS( ims i ms , ck ms , ik ms , cap ms ) ;out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;i f enab l eEnc nas ms = f a l s e then

out ( pubChannel , (NASSMComplete , nas smcomplete msg ,f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)

pMSAS( kasme ms , ims i ms , cap ms )e l s e

out ( pubChannel , (NASSMComplete , s e n c r y p t n a s( nas smcomplete msg , knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s( nas smcomplete msg , knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 9 ] ∗)pMSAS( kasme ms , ims i ms , cap ms ) .

(∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)l e t processENB =

162

i n ( sChannelSnBts , ( kasme enb : asmeKey , im s i e nb : i d en t ,cap enb : boo l ) ) ;

l e t kenb enb : enbKey = kd f enb ( kasme enb ) i nl e t kasenc enb : asEncKey = kd f a s e n c ( kenb enb ) i nl e t k a s i n t e n b : a s I n tKey = k d f a s i n t ( kenb enb ) i nl e t kupenc enb : upEncKey = kd f up enc ( kenb enb ) i nevent begMS ENB( ims i enb , kenb enb , cap enb ) ;out ( pubChannel , (ASSMC, cap enb ,

f i n t e g a s ( b o o l 2 b i t s t r i n g ( cap enb ) , k a s i n t e n b ) ) ) ; (∗ [Msg 11 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f i n t e g a s ( as smcomplete msg , k a s i n t e n b ) ) ) ; (∗ [Msg 12 ] ∗)i f cap enb = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f i n t e g a s ( pay load , k a s i n t e n b ) ) )

(∗ [Msg 13 ] ∗)e l s e

out ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ka senc enb ) ,f i n t e g a s ( s e n c r y p t a s ( pay load , ka senc enb ) , k a s i n t e n b ) ) ) .

(∗ [Msg 13 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g MME ∗)l e t processMME =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=NONCE TAU, nonce ms sn : nonce ) ) ; (∗ [Msg 3 ] ∗)out ( s ecu reChanne l , (AV REQ, im s i s n ) ) ; (∗ [Msg 4 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , r and sn : nonce , x r e s s n : re sp ,

c k sn : c ipherKey , i k s n : integKey , mac sn : mac ) ) ; (∗ [Msg 5 ] ∗)out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [Msg 6 ] ∗)i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 7 ] ∗)event endSN( ims i s n , ck sn , i k s n ) ;new nonce mme : nonce ;l e t kasme sn : asmeKey = kdf asme ( ck sn , i k s n , nonce ms sn ,

nonce mme ) i nl e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i nl e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i nevent begMS( ims i s n , ck sn , i k s n , cap sn ) ;out ( pubChannel , (NASSMC, cap sn , cap sn , nonce ms sn , nonce mme ,

f i n t e g n a s ( ( cap sn , cap sn , nonce ms sn , nonce mme ) ,k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)

i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i n g ,=f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 9 ] ∗)

i f cap sn = t r u e theni f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg then

out ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )e l s e 0

e l s ei f cap sn = f a l s e then

i f msg nas = nas smcomplete msg thenout ( sChannelSnBts , ( kasme sn , im s i s n , cap sn ) )

e l s e 0e l s e 0 .

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d e n t ) ) ; (∗ [Msg 4 ] ∗)new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nout ( s ecu reChanne l , (AV, ims i hn , rand hn ,

x r e s hn , ck hn , i k hn , mac hn ) ) . (∗ [Msg 5 ] ∗)

163

p roce s s( ( ! processMS ) | ( ! processMME ) | ( ! processENB ) | ( ! processHN ) )

S9–. GSM I ‖ LTE II–III ‖ GSM IV, conv(CK IK → Kc, MME), AV = 4GAV + CK + IK

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type gsmKey .type mac .type msgMac .type asmeKey .type nasEncKey .type nas In tKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .const CMComplete : msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun c3 ( c ipherKey , i n t egKey ) : gsmKey .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , gsmKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : gsmKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .

164

reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS AS( iden t , gsmKey , boo l ) .event endMS AS( iden t , gsmKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : gsmKey , x3 : boo l ;event ( endMS AS( x1 , x2 , x3 ) ) event ( begMS AS( x1 , x2 , x3 ) ) .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

=f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i n

event begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t kc ms : gsmKey = c3 ( ck ms , i k ms ) i ni n ( pubChannel , (=ASSMC, enab l eEnc as ms : boo l ) ) ; (∗ [Msg 8 ] ∗)event endMS AS( ims i ms , kc ms , cap ms ) ;out ( pubChannel , CMComplete ) ; (∗ [Msg 9 ] ∗)i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ) ) ; (∗ [Msg 10 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , kc ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g =sd e c r y p t a s ( datamsg , kc ms ) i n 0 .

165

(∗ p r o c e s s r e p r e s e n t i n g SN ∗)l e t processSN =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new s n i d s n : i d e n t ;out ( s ecu reChanne l , (AV REQ, ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , s n i d h n s n : i d en t ,

r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;(∗ [Msg 5 ] ∗)

i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)event endSN( ims i s n , ck sn , i k s n ) ;l e t kc sn : gsmKey = c3 ( ck sn , i k s n ) i n

event begMS AS( ims i s n , kc sn , cap sn ) ;out ( pubChannel , (ASSMC, cap sn ) ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , =CMComplete ) ; (∗ [Msg 9 ] ∗)i f cap sn = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 10 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k c sn ) ) ) .

(∗ [Msg 10 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;(∗ [Msg 3 ] ∗)

new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i nout ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn , x r e s hn ,

mac hn , kasme hn , ck hn , i k h n ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S9. GSM I ‖ LTE II–IV ‖ GSM IV, conv(CK IK → Kc, MME), AV = 4GAV + CK + IK

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the MME and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .(∗ Secure channe l between the MME and the BS ∗)f r e e sChanne lSnBts : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type gsmKey .type mac .type msgMac .

166

type asmeKey .type nasEncKey .type nas In tKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .const CMComplete : msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun c3 ( c ipherKey , i n t egKey ) : gsmKey .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , gsmKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : gsmKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.

(∗Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , the even t

d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

167

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , i d en t , asmeKey ) .event endSN( iden t , i d en t , asmeKey ) .event begMS( iden t , i d en t , asmeKey , boo l ) .event endMS( iden t , i d en t , asmeKey , boo l ) .event begMS AS( iden t , gsmKey , boo l ) .event endMS AS( iden t , gsmKey , boo l ) .

query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

query x1 : i d en t , x2 : gsmKey , x3 : boo l ;event ( endMS AS( x1 , x2 , x3 ) ) event ( begMS AS( x1 , x2 , x3 ) ) .

(∗ AS SMC procedu r e i n p r o c e s s MS ∗)l e t pMSAS( kc ms : gsmKey , ims i ms : i d en t , cap ms : boo l ) =

i n ( pubChannel , (=ASSMC, enab l eEnc as ms : boo l ) ) ; (∗ [Msg 10 ] ∗)event endMS AS( ims i ms , kc ms , cap ms ) ;out ( pubChannel , CMComplete ) ; (∗ [Msg 11 ] ∗)i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ) ) ;out ( pubChannel , s e n c r y p t a s ( s e c r e t , kc ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , kc ms ) i n 0 .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce ,

=f1 ( k i , rand ms ) , sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i nevent begSN ( ims i ms , sn id ms , kasme ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i nl e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i ni n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,

=f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;(∗ [Msg 7 ] ∗)

event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;l e t kc ms : gsmKey = c3 ( ck ms , i k ms ) i ni f enab l eEnc nas ms = f a l s e then

out ( pubChannel , (NASSMComplete , nas smcomplete msg ,f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)

pMSAS( kc ms , ims i ms , cap ms )e l s e

out ( pubChannel , (NASSMComplete ,s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg , knasenc ms ) ,kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)

pMSAS( kc ms , ims i ms , cap ms ) .

168

(∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)l e t processBS =

i n ( sChannelSnBts , ( k c b s : gsmKey , im s i b s : i d en t , cap bs : boo l ) ) ;event begMS AS( ims i b s , kc bs , cap bs ) ;out ( pubChannel , (ASSMC, cap bs ) ) ; (∗ [Msg 10 ] ∗)i n ( pubChannel , =CMComplete ) ; (∗ [Msg 11 ] ∗)i f cap bs = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load ) ) (∗ [Msg 12 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t a s ( pay load , k c b s ) ) ) .

(∗ [Msg 12 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g MME ∗)l e t processMME =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new s n i d s n : i d e n t ;out ( s ecu reChanne l , (AV REQ, ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, im s i h n s n : i d en t , s n i d h n s n : i d en t ,

r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;(∗ [Msg 5 ] ∗)

i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)event begMS( ims i hn sn , s n i d hn sn , kasme sn , cap sn ) ;l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i nl e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i nout ( pubChannel , (NASSMC, cap sn , cap sn ,

f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i n g ,

=f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)l e t kc sn : gsmKey = c3 ( ck sn , i k s n ) i ni f cap sn = t r u e then

i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg thenevent endSN( ims i hn sn , s n i d hn sn , kasme sn ) ;out ( sChannelSnBts , ( kc sn , im s i hn sn , cap sn ) )

e l s e 0e l s e

i f cap sn = f a l s e theni f msg nas = nas smcomplete msg then

event endSN( ims i hn sn , s n i d hn sn , kasme sn ) ;out ( sChannelSnBts , ( kc sn , im s i hn sn , cap sn ) )

e l s e 0e l s e 0 .

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;(∗ [Msg 3 ] ∗)

new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i nout ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn , x r e s hn ,

mac hn , kasme hn , ck hn , i k h n ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processMME ) | ( ! processBS ) | ( ! processHN ) )

169

S10–. UMTS I ‖ LTE II–III ‖ UMTS IV, AV = 4G AV + CK + IK

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the SN and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .type asmeKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun s e n c r y p t a s ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , ∗)(∗ the even t d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .

170

query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , c ipherKey , i n t egKey ) .event endSN( iden t , c ipherKey , i n t egKey ) .event begMS( iden t , c ipherKey , integKey , boo l ) .event endMS( iden t , c ipherKey , integKey , boo l ) .

query x1 : i d en t , x2 : c ipherKey , x3 : i n t egKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ,

sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i nevent begSN ( ims i ms , ck ms , i k ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)i n ( pubChannel , (=ASSMC, =cap ms , enab l eEnc as ms : bool ,

f r e s h ms : nonce , =f9 ( ( cap ms , enab leEnc as ms , f r e s h ms ) ,i k ms ) ) ) ; (∗ [Msg 8 ] ∗)

out ( pubChannel , (ASSMComplete , as smcomplete msg ,f 9 ( as smcomplete msg , i k ms ) ) ) ; (∗ [Msg 9 ] ∗)

event endMS( ims i ms , ck ms , ik ms , cap ms ) ;i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g , =f9 ( datamsg , i k ms ) ) ) ;

(∗ [Msg 10 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , ck ms ) ) ;out ( pubChannel , s e n c i n t a s ( s e c r e t , i k ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , ck ms ) i n 0 .

(∗ p r o c e s s r e p r e s e n t i n g SN ∗)l e t processSN =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new s n i d s n : i d e n t ;out ( s ecu reChanne l , (AV REQ, ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , =sn i d s n , r and sn : nonce ,

x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;(∗ [Msg 5 ] ∗)

i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)event endSN( ims i s n , ck sn , i k s n ) ;new f r e s h s n : nonce ;event begMS( ims i s n , ck sn , i k s n , cap sn ) ;out ( pubChannel , (ASSMC, cap sn , cap sn , f r e s h s n ,

f 9 ( ( cap sn , cap sn , f r e s h s n ) , i k s n ) ) ) ; (∗ [Msg 8 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f9 ( as smcomplete msg , i k s n ) ) ) ; (∗ [Msg 9 ] ∗)i f cap sn = f a l s e then

171

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f 9 ( pay load , i k s n ) ) ) (∗ [Msg 10 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ck sn ) ,

f 9 ( s e n c r y p t a s ( pay load , ck sn ) , i k s n ) ) ) . (∗ [Msg 10 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;(∗ [Msg 3 ] ∗)

new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i nout ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn , x r e s hn ,

mac hn , kasme hn , ck hn , i k h n ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processSN ) | ( ! processHN ) )

S10. UMTS I ‖ LTE II–IV ‖ UMTS IV, AV = 4G AV + CK + IK

(∗ Pub l i c channe l between the MS and the SN ∗)f r e e pubChannel : channe l .(∗ Secure channe l between the MME and the HN ∗)f r e e s e cu r eChanne l : channe l [ p r i v a t e ] .(∗ Secure channe l between the MME and the BS ∗)f r e e sChanne lSnBts : channe l [ p r i v a t e ] .

(∗ t yp e s ∗)type key .type i d e n t .type nonce .type msgHdr .type r e s p .type c i phe rKey .type i n t egKey .type mac .type msgMac .type asmeKey .type nasEncKey .type nas In tKey .

(∗ con s t an t message heade r s ∗)const CAP: msgHdr .const ID : msgHdr .const AV REQ : msgHdr .const AV: msgHdr .const CHALLENGE: msgHdr .const RES : msgHdr .const NASSMC: msgHdr .const NASSMComplete : msgHdr .const ASSMC: msgHdr .const ASSMComplete : msgHdr .const MSG: msgHdr .

(∗ Func t i on s ∗)fun f 1 ( key , nonce ) : mac .fun f 2 ( key , nonce ) : r e s p .

172

fun f 3 ( key , nonce ) : c i phe rKey .fun f 4 ( key , nonce ) : i n t egKey .fun f 9 ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .fun kdf asme ( c ipherKey , integKey , i d e n t ) : asmeKey .fun kd f n a s e n c ( asmeKey ) : nasEncKey .fun k d f n a s i n t ( asmeKey ) : na s In tKey .fun f i n t e g n a s ( b i t s t r i n g , na s In tKey ) : msgMac .fun s e n c r y p t n a s ( b i t s t r i n g , nasEncKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : nasEncKey ;

s d e c r y p t n a s ( s e n c r y p t n a s (m, k ) , k ) = m.fun s e n c r y p t a s ( b i t s t r i n g , c i phe rKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : c i phe rKey ;

s d e c r y p t a s ( s e n c r y p t a s (m, k ) , k ) = m.fun s e n c i n t n a s ( b i t s t r i n g , na s In tKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : na s In tKey ;

s d e c i n n a s ( s e n c i n t n a s (m, k ) , k ) = m.fun s e n c i n t a s ( b i t s t r i n g , i n t egKey ) : b i t s t r i n g .reduc f o r a l l m: b i t s t r i n g , k : i n t egKey ;

s d e c i n a s ( s e n c i n t a s (m, k ) , k ) = m.

(∗ Type Conve r t e r ∗)fun b o o l 2 b i t s t r i n g ( boo l ) : b i t s t r i n g [ data , t y p eConv e r t e r ] .

reduc e n cC a p a b i l i t y ( ) = t r u e ;e n cC a p a b i l i t y ( ) = f a l s e .

(∗ the t a b l e i d e n t / keys ∗)t a b l e keys ( i d en t , key ) .

(∗ SMC command msg ∗)f r e e nas smcomplete msg : b i t s t r i n g .f r e e as smcomplete msg : b i t s t r i n g .

f r e e pay load : b i t s t r i n g [ p r i v a t e ] .event d i s a b l eEn c .(∗ When the a t t a c k e r knows pay load , ∗)(∗ the even t d i s a b l eEn c has been execu ted . ∗)query a t t a cke r ( pay load ) event ( d i s a b l eEn c ) .query a t t a cke r ( pay load ) .

f r e e s e c r e t : b i t s t r i n g [ p r i v a t e ] .query a t t a cke r ( s e c r e t ) .

not a t t a cke r (new k i ) .

(∗ Events used to s p e c i f y co r r e spondence a s s e r t i o n s ∗)event begSN ( iden t , i d en t , asmeKey ) .event endSN( iden t , i d en t , asmeKey ) .event begMS( iden t , i d en t , asmeKey , boo l ) .event endMS( iden t , i d en t , asmeKey , boo l ) .event begMS AS( iden t , c ipherKey , integKey , boo l ) .event endMS AS( iden t , c ipherKey , integKey , boo l ) .

query x1 : i d en t , x2 : i d en t , x3 : asmeKey ;event ( endSN( x1 , x2 , x3 ) ) event ( begSN ( x1 , x2 , x3 ) ) .

query x1 : i d en t , x2 : i d en t , x3 : asmeKey , x4 : boo l ;event (endMS( x1 , x2 , x3 , x4 ) ) event (begMS( x1 , x2 , x3 , x4 ) ) .

query x1 : i d en t , x2 : c ipherKey , x3 : integKey , x4 : boo l ;event ( endMS AS( x1 , x2 , x3 , x4 ) ) event ( begMS AS( x1 , x2 , x3 , x4 ) ) .

(∗ AS SMC procedu r e i n p r o c e s s MS ∗)l e t pMSAS( ck ms : c ipherKey , i k ms : integKey , ims i ms : i d en t ,

cap ms : boo l ) =i n ( pubChannel , (=ASSMC, =cap ms , enab l eEnc as ms : bool ,

173

=f9 ( ( cap ms , enab l eEnc as ms ) , i k ms ) ) ) ; (∗ [Msg 10 ] ∗)out ( pubChannel , (ASSMComplete , as smcomplete msg ,

f 9 ( as smcomplete msg , i k ms ) ) ) ; (∗ [Msg 11 ] ∗)event endMS AS( ims i ms , ck ms , ik ms , cap ms ) ;i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g , =f9 ( datamsg , i k ms ) ) ) ;

(∗ [Msg 12 ] ∗)out ( pubChannel , s e n c r y p t a s ( s e c r e t , ck ms ) ) ;out ( pubChannel , s e n c i n t a s ( s e c r e t , i k ms ) ) ;i f enab l eEnc as ms = t r u e then

l e t msgcontent : b i t s t r i n g = sd e c r y p t a s ( datamsg , ck ms ) i n 0 .

(∗ p r o c e s s r e s p r e s e n t i n g MS ∗)l e t processMS =

new ims i ms : i d e n t ;new k i : key ;i n s e r t keys ( ims i ms , k i ) ;l e t cap ms : boo l = en cC a p a b i l i t y ( ) i nout ( pubChannel , (CAP, cap ms ) ) ; (∗ [Msg 1 ] ∗)out ( pubChannel , ( ID , ims i ms ) ) ; (∗ [Msg 2 ] ∗)i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f1 ( k i , rand ms ) ,

sn id ms : i d e n t ) ) ; (∗ [Msg 5 ] ∗)l e t r e s ms : r e s p = f2 ( k i , rand ms ) i nl e t ck ms : c i phe rKey = f3 ( k i , rand ms ) i nl e t i k ms : i n t egKey = f4 ( k i , rand ms ) i nl e t kasme ms : asmeKey = kdf asme ( ck ms , ik ms , sn id ms ) i nevent begSN ( ims i ms , sn id ms , kasme ms ) ;out ( pubChannel , (RES , r e s ms ) ) ; (∗ [Msg 6 ] ∗)l e t knasenc ms : nasEncKey = kd f n a s e n c ( kasme ms ) i nl e t kna s i n t ms : nas In tKey = k d f n a s i n t ( kasme ms ) i ni n ( pubChannel , (=NASSMC, enab l eEnc nas ms : bool , =cap ms ,

=f i n t e g n a s ( ( enab leEnc nas ms , cap ms ) , kna s i n t ms ) ) ) ;(∗ [Msg 7 ] ∗)

event endMS( ims i ms , sn id ms , kasme ms , cap ms ) ;out ( pubChannel , s e n c r y p t n a s ( s e c r e t , knasenc ms ) ) ;out ( pubChannel , s e n c i n t n a s ( s e c r e t , kna s i n t ms ) ) ;i f enab l eEnc nas ms = f a l s e then

out ( pubChannel , (NASSMComplete , nas smcomplete msg ,f i n t e g n a s ( nas smcomplete msg , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)

pMSAS( ck ms , ik ms , ims i ms , cap ms )e l s e

out ( pubChannel , (NASSMComplete , s e n c r y p t n a s ( nas smcomplete msg ,knasenc ms ) , f i n t e g n a s ( s e n c r y p t n a s ( nas smcomplete msg ,knasenc ms ) , kna s i n t ms ) ) ) ; (∗ [Msg 8 ] ∗)

pMSAS( ck ms , ik ms , ims i ms , cap ms ) .

(∗ p r o c e s s r e p r e s e n t i n g e−nodeB ∗)l e t processBS =

i n ( sChannelSnBts , ( c k b s : c ipherKey , i k b s : integKey ,im s i b s : i d en t , cap bs : boo l ) ) ;

event begMS AS( ims i b s , ck bs , i k b s , cap bs ) ;out ( pubChannel , (ASSMC, cap bs , cap bs , f 9 ( ( cap bs , cap bs ) ,

i k b s ) ) ) ; (∗ [Msg 10 ] ∗)i n ( pubChannel , (=ASSMComplete , =as smcomplete msg ,

=f9 ( as smcomplete msg , i k b s ) ) ) ; (∗ [Msg 11 ] ∗)i f cap bs = f a l s e then

event d i s a b l eEn c ;out ( pubChannel , (MSG, pay load , f 9 ( pay load , i k b s ) ) ) (∗ [Msg 12 ] ∗)

e l s eout ( pubChannel , (MSG, s e n c r y p t a s ( pay load , ck b s ) ,

f 9 ( s e n c r y p t a s ( pay load , ck b s ) , i k b s ) ) ) . (∗ [Msg 12 ] ∗)

(∗ p r o c e s s r e p r e s e n t i n g MME ∗)l e t processMME =

i n ( pubChannel , (=CAP, cap sn : boo l ) ) ; (∗ [Msg 1 ] ∗)

174

i n ( pubChannel , (=ID , im s i s n : i d e n t ) ) ; (∗ [Msg 2 ] ∗)new s n i d s n : i d e n t ;out ( s ecu reChanne l , (AV REQ, ims i s n , s n i d s n ) ) ; (∗ [Msg 3 ] ∗)i n ( s ecu reChanne l , (=AV, =ims i s n , s n i d h n s n : i d en t ,

r and sn : nonce , x r e s s n : re sp , mac sn : mac , kasme sn : asmeKey ,ck sn : c ipherKey , i k s n : i n t egKey ) ) ; (∗ [Msg 4 ] ∗)

out ( pubChannel , (CHALLENGE, rand sn , mac sn , s n i d s n ) ) ;(∗ [Msg 5 ] ∗)

i n ( pubChannel , (=RES , =x r e s s n ) ) ; (∗ [Msg 6 ] ∗)event begMS( ims i s n , s n i d hn sn , kasme sn , cap sn ) ;l e t kna s enc sn : nasEncKey = kd f n a s e n c ( kasme sn ) i nl e t k n a s i n t s n : nas In tKey = k d f n a s i n t ( kasme sn ) i nout ( pubChannel , (NASSMC, cap sn , cap sn ,

f i n t e g n a s ( ( cap sn , cap sn ) , k n a s i n t s n ) ) ) ; (∗ [Msg 7 ] ∗)i n ( pubChannel , (=NASSMComplete , msg nas : b i t s t r i n g ,

=f i n t e g n a s ( msg nas , k n a s i n t s n ) ) ) ; (∗ [Msg 8 ] ∗)i f cap sn = t r u e then

i f s d e c r y p t n a s ( msg nas , kna s enc sn ) = nas smcomplete msg thenevent endSN( ims i s n , s n i d hn sn , kasme sn ) ;out ( sChannelSnBts , ( ck sn , i k s n , im s i s n , cap sn ) )

e l s e 0e l s e

i f cap sn = f a l s e theni f msg nas = nas smcomplete msg then

event endSN( ims i s n , s n i d hn sn , kasme sn ) ;out ( sChannelSnBts , ( ck sn , i k s n , im s i s n , cap sn ) )

e l s e 0e l s e 0 .

(∗ p r o c e s s r e p r e s e n t i n g HN ∗)l e t processHN =

i n ( s ecu reChanne l , (=AV REQ, im s i h n : i d en t , s n i d hn : i d e n t ) ) ;(∗ [Msg 3 ] ∗)

new rand hn : nonce ;get keys (= ims i hn , k i h n ) i nl e t mac hn : mac = f1 ( k i hn , rand hn ) i nl e t x r e s h n : r e s p = f2 ( k i hn , rand hn ) i nl e t ck hn : c i phe rKey = f3 ( k i hn , rand hn ) i nl e t i k h n : i n t egKey = f4 ( k i hn , rand hn ) i nl e t kasme hn : asmeKey = kdf asme ( ck hn , i k hn , s n i d hn ) i nout ( s ecu reChanne l , (AV, ims i hn , sn id hn , rand hn ,

x r e s hn , mac hn , kasme hn , ck hn , i k h n ) ) . (∗ [Msg 4 ] ∗)

p roce s s( ( ! processMS ) | ( ! processMME ) | ( ! processBS ) | ( ! processHN ) )

175

Bibliography

[1] 3GPP TR 31.900 version 11.0.0 Release 11; Universal Mobile Telecommunica-tions System (UMTS); LTE; SIM/USIM internal and external interworking as-pects. http://www.3gpp.org/ftp/Specs/html-info/31900.htm.

[2] 3GPP TR 33.902 version 4.0.0 Release 4; Universal Mobile TelecommunicationsSystem (UMTS); Formal Analysis of the 3G Authentication Protocol . http:

//www.3gpp.org/DynaReport/33902.htm.

[3] 3GPP TS 23.003 version 10.3.0 Release 10; Digital cellular telecommunicationssystem (Phase 2+); Universal Mobile Telecommunications System (UMTS);Numbering, addressing and identification. http://www.3gpp.org/ftp/Specs/

html-info/23003.htm.

[4] 3GPP TS 23.060 version 11.5.0 Release 11; Digital cellular telecommunicationssystem (Phase 2+); Universal Mobile Telecommunications System (UMTS);General Packet Radio Service (GPRS); Service description; Stage 2. http:

//www.3gpp.org/ftp/Specs/html-info/23060.htm.

[5] 3GPP TS 23.401 version 11.4.0 Release 11; LTE; General Packet Radio Ser-vice (GPRS) enhancements for Evolved Universal Terrestrial Radio AccessNetwork (E-UTRAN) access. http://www.3gpp.org/ftp/Specs/html-info/

23401.htm.

[6] 3GPP TS 24.301 version 11.4.0 Release 11; Universal Mobile Telecommunica-tions System (UMTS); LTE; Non-Access-Stratum (NAS) protocol for EvolvedPacket System (EPS); Stage 3. http://www.3gpp.org/ftp/Specs/html-info/24301.htm.

[7] 3GPP TS 33.102 version 11.4.0 Release 11; Digital cellular telecommunicationssystem (Phase 2+); Universal Mobile Telecommunications System (UMTS);LTE; 3G security; Security architecture . http://www.3gpp.org/ftp/Specs/

html-info/33102.htm.

[8] 3GPP TS 33.401 version 10.0.0 Release 10; Digital cellular telecommunicationssystem (Phase 2+); Universal Mobile Telecommunications System (UMTS);LTE; 3gpp System Architecture Evolution (SAE); Security architecture. http:

//www.3gpp.org/ftp/Specs/html-info/33401.htm.

[9] The international telecommunication union. http://www.itu.int/en/ITU-D/

Statistics/Pages/facts/default.aspx.

[10] Wikipedia. http://www.wikipedia.org/.

176

[11] GSM 04.08 version 7.8.0 Release 1998; Digital cellular telecommunications sys-tem (Phase 2+); Mobile radio interface layer 3 specification, 1998.

[12] Martın Abadi and Bruno Blanchet. Computer-assisted verification of a protocolfor certified email. In Static Analysis, pages 316–335. Springer, 2003.

[13] Martın Abadi, Bruno Blanchet, and Hubert Comon-Lundh. Models and proofsof protocol security: A progress report. In Computer Aided Verification, pages35–49. Springer, 2009.

[14] Martın Abadi, Bruno Blanchet, and Cedric Fournet. Just fast keying in thepi calculus. In Programming Languages and Systems, pages 340–354. Springer,2004.

[15] Martın Abadi and Andrew D Gordon. A calculus for cryptographic protocols:The spi calculus. In Proceedings of the 4th ACM conference on Computer andcommunications security, pages 36–47. ACM, 1997.

[16] Zahra Ahmadian, Somayeh Salimi, and Ahmad Salahi. New attacks on UMTSnetwork access. In Wireless Telecommunications Symposium, 2009. WTS 2009,pages 1–6. IEEE, 2009.

[17] Myrto Arapinis, Loretta Mancini, Eike Ritter, Mark Ryan, Nico Golde, KevinRedon, and Ravishankar Borgaonkar. New privacy issues in mobile telephony:fix and verification. In Proceedings of the 2012 ACM conference on Computerand communications security, pages 205–216. ACM, 2012.

[18] Alessandro Armando. The high level protocol specification language, 2003.

[19] Alessandro Armando, David Basin, Yohan Boichut, Yannick Chevalier, LucaCompagna, Jorge Cuellar, P Hankes Drielsma, Pierre-Cyrille Heam, OlgaKouchnarenko, Jacopo Mantovani, et al. The avispa tool for the automatedvalidation of internet security protocols and applications. In Computer AidedVerification, pages 281–285. Springer, 2005.

[20] Alessandro Armando and Luca Compagna. Sat-based model-checking for securityprotocols analysis. volume 7, pages 3–32. Springer, 2008.

[21] Elad Barkan, Eli Biham, and Nathan Keller. Instant ciphertext-only cryptanaly-sis of gsm encrypted communication. In Advances in Cryptology-CRYPTO 2003,pages 600–616. Springer, 2003.

[22] Gilles Barthe, Benjamin Gregoire, Sylvain Heraud, and Santiago ZanellaBeguelin. Computer-aided security proofs for the working cryptographer. InAdvances in Cryptology–CRYPTO 2011, pages 71–90. Springer, 2011.

177

[23] David Basin. Lazy infinite-state analysis of security protocols. In Secure Net-workingCQRE [Secure]99, pages 30–42. Springer, 1999.

[24] David Basin, Sebastian Modersheim, and Luca Vigano. Ofmc: A symbolic modelchecker for security protocols. volume 4, pages 181–208. Springer, 2005.

[25] Bruno Blanchet. An efficient cryptographic protocol verifier based on prologrules. In IN 14TH IEEE COMPUTER SECURITY FOUNDATIONS WORK-SHOP (CSFW-14), pages 82–96. IEEE Computer Society Press, 2001.

[26] Bruno Blanchet. A computationally sound mechanized prover for security pro-tocols. Dependable and Secure Computing, IEEE Transactions on, 5(4):193–207,2008.

[27] Bruno Blanchet. Automatic verification of correspondences for security protocols.Journal of Computer Security, 17(4):363–434, July 2009.

[28] Bruno Blanchet and Avik Chaudhuri. Automated formal analysis of a protocolfor secure file sharing on untrusted storage. In Security and Privacy, 2008. SP2008. IEEE Symposium on, pages 417–431. IEEE, 2008.

[29] Bruno Blanchet and Andreas Podelski. Verification of cryptographic protocols:Tagging enforces termination. In Foundations of Software Science and Compu-tation Structures, pages 136–152. Springer, 2003.

[30] Bruno Blanchet and Ben Smyth. Proverif 2.0: Automatic cryptographic protocolverifier, user manual and tutorial, 2010.

[31] Chiara Bodei, Mikael Buchholtz, Pierpaolo Degano, Flemming Nielson, andH Riis Nielson. Automatic validation of protocol narration. In Computer Se-curity Foundations Workshop, 2003. Proceedings. 16th IEEE, pages 126–140.IEEE, 2003.

[32] Eduardo Bonelli, Adriana Compagnoni, and Elsa Gunter. Correspondence as-sertions for process synchronization in concurrent communications. Journal ofFunctional Programming, 15(2):219–247, 2005.

[33] Mohamed Salah Bouassida, Najah Chridi, Isabelle Chrisment, Olivier Festor, andLaurent Vigneron. Automated verification of a key management architecture forhierarchical group protocols. 62(11-12):1365–1387, 2007.

[34] Aaron R Bradley and Zohar Manna. The calculus of computation: decisionprocedures with applications to verification. Springer, 2007.

[35] Mayla Bruso, Konstantinos Chatzikokolakis, and Jerry Den Hartog. Formalverification of privacy for RFID systems. In Computer Security FoundationsSymposium (CSF), 2010 23rd IEEE, pages 75–88. IEEE, 2010.

178

[36] Richard Chang and Vitaly Shmatikov. Formal analysis of authentication inbluetooth device pairing. page 45. Citeseer, 2007.

[37] Liqun Chen and Mark Ryan. Attack, solution and verification for shared au-thorisation data in TCG TPM. In Formal Aspects in Security and Trust, pages201–216. Springer, 2010.

[38] John Andrew Clark and Jeremy Lawrence Jacob. A survey of authenticationprotocol literature: Version 1.0. 1997.

[39] Edmund M Clarke, Orna Grumberg, and David E Long. Model checkingand abstraction. ACM Transactions on Programming Languages and Systems(TOPLAS), 16(5):1512–1542, 1994.

[40] Edmund M Clarke, Orna Grumberg, and Doron A Peled. Model checking. MITPress, 1999.

[41] Cas J.F. Cremers. The Scyther Tool: Verification, falsification, and analysis ofsecurity protocols. In CAV, volume 5123 of LNCS, pages 414–418, 2008.

[42] Cas J.F. Cremers. Unbounded verification, falsification, and characterization ofsecurity protocols by pattern refinement. In CCS ’08: Proceedings of the 15thACM conference on Computer and communications security, pages 119–128, NewYork, NY, USA, 2008. ACM.

[43] Cas J.F. Cremers, Pascal Lafourcade, and Philippe Nadeau. Comparing statespaces in automatic protocol analysis. In Formal to Practical Security, volume5458/2009 of Lecture Notes in Computer Science, pages 70–94. Springer, 2009.

[44] Cas J.F. Cremers and Sjouke Mauw. Operational semantics of security proto-cols. In Scenarios: Models, Transformations and Tools, International Workshop,Dagstuhl, pages 66–89. Springer, 2005.

[45] Cas J.F. Cremers and Sjouke MauW. Generalizing Needham-Schroeder-Lowe formulti-party authentication. Technical report, Eindhoven University of Technol-ogy, 2006.

[46] Cas J.F. Cremers, Sjouke Mauw, and EP De Vink. Defining authentication in atrace model. In Fast, pages 131–145. Citeseer, 2003.

[47] Cas J.F. Cremers, Sjouke Mauw, and Erik P de Vink. Injective synchronisation:an extension of the authentication hierarchy. Theoretical Computer Science,367(1):139–161, 2006.

[48] Scott Dawson, Farnam Jahanian, and Todd Mitton. ORCHESTRA: A faultinjection environment for distributed systems. Ann Arbor, 1001:48109–2122,1996.

179

[49] Leonardo de Moura, Sam Owre, and N. Shankar. The SAL Language Manual.SRI International, 2003.

[50] Danny Dolev and Andrew Yao. On the security of public key protocols. Infor-mation Theory, IEEE Transactions on, 29(2):198–208, 1983.

[51] Orr Dunkelman, Nathan Keller, and Adi Shamir. A practical-time related-keyattack on the KASUMI cryptosystem used in GSM and 3G telephony. In Ad-vances in Cryptology–CRYPTO 2010, pages 393–410. Springer, 2010.

[52] Dan Forsberg, Gunther Horn, Wolf-Dietrich Moeller, and Valtteri Niemi. LTESecurity. John Wiley and Sons, Ltd, 2010.

[53] Dirk Fox. Der IMSI catcher. In DuD Datenschutz und Datensicherheit, 2002.

[54] Nico Golde, Kevin Redon, and Jean-Pierre Seifert. Let me answer that for you:Exploiting broadcast information in cellular networks. In Proceedings of the 22ndUSENIX Security Symposium, pages 33–48, 2013.

[55] Shafi Goldwasser and Silvio Micali. Probabilistic encryption. Journal of Com-puter and System Sciences, 28(2):270–299, 1984.

[56] Jovan Dj. Golic. Cryptanalysis of alleged a5 stream cipher. In EUROCRYPT,1997.

[57] Jovan Dj Golic. Cryptanalysis of alleged a5 stream cipher. In Advances inCryptologyEUROCRYPT97, pages 239–255. Springer, 1997.

[58] Andrew D Gordon and Alan Jeffrey. Authenticity by typing for security proto-cols. Journal of computer security, 11(4):451–519, 2003.

[59] C Han and H Choi. Security analysis of handover key management in 4GLTE/SAE network. 2012.

[60] Seungjae Han, Kang G Shin, and Harold A Rosenberg. DOCTOR: An integratedsoftware fault injection environment for distributed real-time systems. pages 204–213, 1995.

[61] James Heather, Gavin Lowe, and Steve Schneider. How to prevent type flawattacks on security protocols. Journal of Computer Security, 11(2):217–244,2003.

[62] Gunnar Heine and Matt Horrer. GSM Networks: Protocols, Terminology, andImplementation. Artech House, January 1999.

[63] Michael Huth and Mark Ryan. Logic in Computer Science: Modelling and Rea-soning about Systems. Cambridge University Press, 2004.

180

[64] Markus Jakobsson and Susanne Wetzel. Security weaknesses in bluetooth. InTopics in CryptologyCT-RSA 2001, pages 176–191. Springer, 2001.

[65] Georgios Kambourakis, Constantinos Kolias, Stefanos Gritzalis, and Jong Hyuk-Park. Signaling-oriented dos attacks in umts networks. In Advances in Informa-tion Security and Assurance, pages 280–289. Springer, 2009.

[66] Muzammil Khan, Attiq Ahmed, and Ahmad Raza Cheema. Vulnerabilities ofumts access domain security architecture. In Software Engineering, ArtificialIntelligence, Networking, and Parallel/Distributed Computing, 2008. SNPD’08.Ninth ACIS International Conference on, pages 350–355. IEEE, 2008.

[67] Steve Kremer and Mark Ryan. Analysis of an electronic voting protocol in theapplied pi calculus. In Programming Languages and Systems, pages 186–200.Springer, 2005.

[68] Ming-Feng Lee, Nigel P Smart, Bogdan Warinschi, and Gaven J Watson.Anonymity guarantees of the UMTS/LTE authentication and connection pro-tocol. IACR Cryptology ePrint Archive, 2013:27, 2013.

[69] Patrick PC Lee, Tian Bu, and Thomas Woo. On the detection of signaling dosattacks on 3g wireless networks. In INFOCOM 2007. 26th IEEE InternationalConference on Computer Communications. IEEE, pages 1289–1297. IEEE, 2007.

[70] Sun-Hee Lim, Ki-Seok Bang, Okyeon Yi, and Jongin Lim. A secure handoverprotocol design in wireless networks with formal verification. In Wired/WirelessInternet Communications, pages 67–78. Springer, 2007.

[71] Gavin Lowe. Breaking and fixing the Needham-Schroeder public-key protocol us-ing FDR. In Tools and Algorithms for the Construction and Analysis of Systems,pages 147–166. Springer, 1996.

[72] Gavin Lowe. Casper: A compiler for the analysis of security protocols. Journalof computer security, 6(1):53–84, 1998.

[73] Catherine Meadows. Formal verification of cryptographic protocols: A survey.In Josef Pieprzyk and Reihaneh Safavi-Naini, editors, ASIACRYPT, volume 917of Lecture Notes in Computer Science, pages 135–150. Springer, 1994.

[74] Catherine Meadows. Language generation and verification in the NRL protocolanalyzer. In Computer Security Foundations Workshop, 1996. Proceedings., 9thIEEE, pages 48–61. IEEE, 1996.

[75] Catherine Meadows. The NRL protocol analyzer: An overview. The Journal ofLogic Programming, 26(2):113–131, 1996.

181

[76] Ulrike Meyer. Secure Roaming and Handover Procedures in Wireless AccessNetworks. PhD thesis, Darmstadt University of Technology, Germany, 2005.

[77] Ulrike Meyer and Susanne Wetzel. A man-in-the-middle attack on UMTS. InProceedings of the 3rd ACM workshop on Wireless security, pages 90–97. ACM,2004.

[78] Ulrike Meyer and Susanne Wetzel. On the impact of GSM encryption and man-in-the-middle attacks on the security of interoperating GSM/UMTS networks. InPersonal, Indoor and Mobile Radio Communications, 2004. PIMRC 2004. 15thIEEE International Symposium on, volume 4, pages 2876–2883. IEEE, 2004.

[79] Mojtaba Ayoubi Mobarhan, Mostafa Ayoubi Mobarhan, and Asadollah Shah-bahrami. Evaluation of security attacks on UMTS authentication mechanism.International Journal of Network Security & Its Applications, 4(4), 2012.

[80] Anderson Morais, Eliane Martins, and Ana Cavalli. Generating attack scenariosfor the validation of security protocol implementations. In The 2nd BrazilianWorkshop on Systematic and Automated Software Testing, 2008.

[81] Anderson Morais, Eliane Martins, Ana Cavalli, and Willy Jimenez. Securityprotocol testing using attack trees. In Computational Science and Engineering,2009. CSE’09. International Conference on, volume 2, pages 690–697. IEEE,2009.

[82] Flemming Nielson, Hanne Riis Nielson, and Helmut Seidl. A succinct solver forALFP. Nordic Journal of Computing, 9(4):335–372, 2002.

[83] M Peters and P Rogaar. A review of proverif as an automatic security protocolverifier, 2011.

[84] Slobodan Petrovic and Amparo Fuster-Sabater. Cryptanalysis of the A5/2 algo-rithm. IACR Cryptology ePrint Archive, 2000:52, 2000.

[85] Ahmed M Taha, Amr T Abdel-Hamid, and Sofiene Tahar. Formal analysisof the handover schemes in mobile WiMAX networks. In Wireless and OpticalCommunications Networks, 2009. WOCN’09. IFIP International Conference on,pages 1–5. IEEE, 2009.

[86] Ahmed M Taha, Amr T Abdel-Hamid, and Sofiene Tahar. Formal verificationof IEEE 802.16 security sublayer using Scyther tool. In Network and ServiceSecurity, 2009. N2S’09. International Conference on, pages 1–5. IEEE, 2009.

[87] Chunyu Tang, David A Naumann, and Susanne Wetzel. Symbolic analysis forsecurity of roaming protocols in mobile networks. In Security and Privacy inCommunication Networks, pages 480–490. Springer, 2012.

182

[88] The AVISPA Team. AVISPA v1.1 user manual, 2006.

[89] Joe-Kai Tsay and Stig F Mjølsnes. A vulnerability in the UMTS and LTEauthentication and key agreement protocols. In Computer Network Security,pages 65–76. Springer, 2012.

[90] Mathieu Turuani. The CL-Atse protocol analyser. In Term Rewriting and Ap-plications, pages 277–286. Springer, 2006.

[91] David von Oheimb and Jorge Cuellar. Designing and verifying core protocols forlocation privacy. In Information Security, pages 502–516. Springer, 2006.

[92] Thomas YC Woo and Simon S Lam. A semantic model for authentication pro-tocols. In Research in Security and Privacy, 1993. Proceedings., 1993 IEEEComputer Society Symposium on, pages 178–194. IEEE, 1993.

[93] Muxiang Zhang and Yuguang Fang. Security analysis and enhancements of 3gppauthentication and key agreement protocol. Wireless Communications, IEEETransactions on, 4(2):734–742, 2005.

[94] 3GPP The mobile broadband standard. http://www.3gpp.org/

specifications.

183

Vita

Chunyu Tang

Address 404 Madison St Apt 3, Hoboken, NJ 07030

Education Stevens Institute of Technology, Hoboken, NJDoctoral Candidate in Computer Scienceexpected date of graduation, Dec 2013

Peking University, Beijing, ChinaMaster in Software Engineering, 2005

Northeastern University, Shenyang, ChinaBachelor in Mechanical Engineering, 2001

Industrial Techfaith Wireless, Beijing, ChinaExperience Lead Senior Developer (2005-2007)

Designed the touch screen module for cellphones from scratchLed a team of 5 in implementing and maintaining the touchscreen moduleDesigned memory card detection mechanism

IBM, Beijing, China (Intern 2004-2005)Investigated the security of the Workplace Client TechnologyClassified the Universal Network Objects APIs into threelevels according to the severity of possible attacksImplemented the security mechanism by auditing the called APIs

Publications Chunyu Tang, David A. Naumann, and Susanne WetzelSymbolic Analysis for Security of Roaming Protocolsin Mobile Networks7th International ICST Conference onSecurity and Privacy in Communication NetworksChunyu Tang, David A. Naumann, and Susanne WetzelAnalysis of authentication and key establishmentin inter-generational mobile telephonyThe Fourth IEEE International Symposium onTrust, Security and Privacy for Emerging Applications (TSP-13)

Honors Member of Upsilon Pi Epsilon (Computer Science Honor Society)IEEE student member, ACM student member