MODELING and ANALYSIS of MOBILE TELEPHONY PROTOCOLS by Chunyu Tang a DISSERTATION Submitted to the Faculty of the Stevens Instit

MODELING AND ANALYSIS OF MOBILE TELEPHONY PROTOCOLS

Chunyu Tang

A DISSERTATION

Submitted to the Faculty of the Stevens Institute of Technology in partial fulﬁllment 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

MODELING AND ANALYSIS OF MOBILE TELEPHONY PROTOCOLS

ABSTRACT

The GSM (2G), UMTS (3G), and LTE (4G) mobile telephony protocols are all in active use, giving rise to a number of interoperation situations. This poses serious challenges in ensuring authentication and other security properties. Analyzing the security of all possible interoperation scenarios by hand is, at best, tedious undertaking. Model checking techniques provide an effective way to automatically find vulnerabilities in or to prove the security properties of security protocols. Although the specifications address the interoperation cases between GSM and UMTS and the switching and mapping of established security context between LTE and previous technologies, there is not a comprehensive specification of which are the possible interoperation cases. Nor is there comprehensive specification of the procedures to establish security context (authentication and short-term keys) in the various interoperation scenarios. We systematically enumerate the cases, classifying them as allowed, disallowed, or uncertain with rationale based on detailed analysis of the specifications. We identify the authentication and key agreement procedure for each of the possible cases. We formally model the pure GSM, UMTS, LTE authentication protocols, as well as all the interoperation scenarios; we analyze their security, in the symbolic model 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 of attacks: one is the false base station attack which is inherited from GSM; another attack is a similar false base station attack but with a 4G base station; the third one modifies the CMC message. Based on the proved and refuted properties, we compare the authenticity achieved in different scenarios, and we provide recommendations to improve the mobile telephony standards.

Author: Chunyu Tang Advisor: David A. Naumann Date: January 13, 2014 Department: Computer Science Degree: 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 inspire me. He spent countless hours discussing my work, reading my papers, proposal, and dissertation, and criticizing my talks. This dissertation would not be possible without the 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 time and energy she invested into my research. This dissertation would not have existed without her detailed comments, endless patience, and valuable advice. I give my sincere thanks to the members of my Ph.D committee, Professor Daniel Duchamp and Professor Yingying Chen. Their valuable comments on my proposal and dissertation greatly enhanced and strengthened my work. I would also like to thank Professor Adriana Compagnoni for serving on my proposal committee and for her valuable comments on my work. I would like to thank Andrey Chudnov, Stan Rosenberg, and Ye Wu for their excellent comments and helpful discussion of my work. I thank the professors and students in our regular LSS meeting for sharing their 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 adorable son, Albert Tang. They keep my life with love. They shared all my exciting and disappointing moments over the years. v

Table of Contents

Abstract iii

Acknowledgments iv

List of Tables ix

List of Figures x

Index of Deﬁned Terms xii

1 Introduction 1 1.1 Motivation and Goals1 1.2 Approach2 1.3 Thesis3 1.4 Contribution3 1.5 Outline4

2 Background on Security Protocol Analysis and Related Work 5 2.1 Informal Analysis Techniques and Prior Work for Mobile Telephony Protocols5 2.1.1 Conventional Analysis5 2.1.2 Prior Work6 2.2 Background on Formal Analysis7 2.2.1 Dolev-Yao (Symbolic) and Computational Model7 2.2.2 Events and Correspondence Assertion8 2.3 Comparative Overview of Formal Tools9 2.3.1 Formal Analysis Tools9 2.3.2 Scyther 11 2.3.3 AVISPA 12 2.4 ProVerif 14 2.4.1 Rationale for the choice of ProVerif 14 2.4.2 Specifying Protocols and Security Properties 14 2.4.3 Analysis Technique and Approximation 16 2.4.4 Applications 19 2.5 Prior Work on Formal Analysis of Mobile Telephony Protocols 19

3 Modeling and Analysis of GSM 21 3.1 Overview of GSM AKA 21 3.2 Modeling the GSM AKA 24 3.2.1 Design Choices 24 vi

3.2.2 GSM Model 28 3.3 Security Property Speciﬁcations and Findings 33

4 Modeling and Analysis of UMTS 37 4.1 Overview of UMTS AKA 37 4.2 Modeling the UMTS AKA 40 4.2.1 Design Choices 40 4.2.2 UMTS Model 40 4.3 Security Property Speciﬁcations and Findings 44

5 Modeling and Analysis of LTE 46 5.1 Overview of LTE AKA 46 5.2 Modeling the LTE AKA 50 5.2.1 Design Choices 50 5.2.2 LTE Model 51 5.3 Security Property Speciﬁcations and Findings 57

6 Comparative Authenticity 59 6.1 Authentication of the MS to the SN 59 6.1.1 GSM vs. UMTS 59 6.1.2 UMTS vs. LTE 60 6.2 Authentication of the SN to the MS 62 6.2.1 GSM vs. UMTS 62 6.2.2 UMTS vs. LTE 62 6.3 Summary 64

7 Establishing a Initial Security Context in Interoperation 66 7.1 System Components 66 7.2 Allowed Interoperation Cases 74 7.3 Disallowed Interoperation Cases 75 7.4 Uncertain Interoperation Cases 75

8 Modeling and Analysis of Interoperation Scenarios involving GSM and UMTS Procedures Only 77 8.1 Determining the Scenarios only involving GSM and UMTS Components 77 8.2 Scenario S4: A UMTS MS roams to an SN with a GSM BS and GSM MSC 79 8.2.1 Overview of the AKA Scenario 79 8.2.2 Modeling the AKA Scenario 80 8.2.3 Security Property Speciﬁcations and Findings 82 8.3 Scenario S5: A GSM MS roams to an SN with a UMTS BS and UMTS MSC 83 8.3.1 Overview of the AKA Scenario 83 vii

8.3.2 Modeling the AKA Scenario 84 8.3.3 Security Property Speciﬁcations and Findings 87 8.4 Scenario S6: A UMTS MS roams to an SN with a GSM BS and a UMTS MSC 87 8.4.1 Overview of the AKA Scenario 88 8.4.2 Modeling the AKA Scenario 88 8.4.3 Security Property Speciﬁcations and Findings 90

9 Modeling and Analysis of Scenarios involving LTE Procedures 93 9.1 Determining the Scenarios involving LTE Components 93 9.2 Scenario S7: LTE I k UMTS II–III k [optionally, LTE IV] k LTE V, conv(CK IK → KASME , MME) 98 9.2.1 Overview of the AKA Scenario 99 9.2.2 Modeling the AKA Scenario 99 9.2.3 Security Property Specifications and Findings 107 9.3 Scenario S8: LTE I’ k UMTS II–III k LTE IV–V, conv(CK IK nonces → KASME , MME) 108 9.3.1 Overview of the AKA Scenario 108 9.3.2 Modeling the AKA Scenario 108 9.3.3 Security Property Specifications and Findings 113 9.4 Scenario S9: GSM I k LTE II–III k [optionally, LTE IV] k GSM IV, conv(CK IK → Kc, MME), AV = 4G AV + CK + IK 114 9.4.1 Overview of the AKA Scenario 114 9.4.2 Modeling the AKA Scenario 114 9.4.3 Security Property Specifications and Findings 121 9.5 Scenario S10: UMTS I k LTE II–III k [optionally, LTE IV] k UMTS IV, AV = 4G AV + CK + IK 122 9.5.1 Overview of the AKA Scenario 122 9.5.2 Modeling the AKA Scenario 123 9.5.3 Security Property Specifications and Findings 128

10 Summary of Findings 130 10.1 Secrecy and Integrity Properties 130 10.2 Authentication Properties 130 10.2.1 Authentication of the MS to the SN 131 10.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 65 6.2 Parameters of the correspondence assertions used in the proved authentication properties 65

7.1 Legend used in Table 7.2 67 7.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) 78 8.2 Classifying the interoperation cases involving GSM and UMTS components only. (The reasons are in Table 8.1) 79 8.3 Analysis result of S4 model 83 8.4 Analysis result of S5 model 87 8.5 Analysis result of S6 model 91

9.1 Reasons used for determining AKA scenarios 94 9.2 Classifying the interoperation cases (for GSM, UMTS, and LTE) 95 9.3 Determining components of each scenario 99 9.4 Analysis result of S7 models 107 9.5 Analysis result of S8 model 113 9.6 Analysis result of S9 models 121 9.7 Analysis result of S10 models 129

10.1 Types of SN components authenticity achieved by the scenarios 133 10.2 Analysis results of authentication properties 134 x

List of Figures

1.1 Example of an interoperation case1

2.1 Term and Process Grammar 15

3.1 GSM architecture [94, 76] 22 3.2 GSM message sequence diagram [94, 76] 23 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 Figure 3.2), abstracts from the details of the SN, and adds a ﬁrst message of data traﬃc 29

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

5.1 LTE architecture [94, 52] 47 5.2 LTE AKA 48 5.3 LTE I’ when the AKA starts with a TAU request 49 5.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 and UMTS 60 6.2 Events used to specify the authentication of MS to SN in UMTS and LTE 61 6.3 Events used to specify the authentication of SN to MS in UMTS and LTE 63

8.1 UMTS subscriber roams into GSM network 80 8.2 UMTS subscriber roams into GSM network, annotated in accord with our model 81 8.3 GSM MS roams into UMTS network 84 8.4 GSM subscriber roams into UMTS network annotated in accord with our model 85 8.5 UMTS subscriber roams into mixed network [94, 76] 88 8.6 UMTS subscriber roams into mixed network annotated in accord with our model 89

9.1 AKA scenario S7 without LTE IV 100 9.2 AKA scenario S7 with LTE IV 100 xi

9.3 AKA scenario S7, version without LTE IV, annotated in accord with our model 101 9.4 AKA scenario S7, version with LTE IV, annotated in accord with our model 104 9.5 AKA scenario S8 109 9.6 AKA scenario S8 annotated in accord with our model 110 9.7 AKA scenario S9 without LTE IV 115 9.8 AKA scenario S9 with LTE IV 115 9.9 AKA scenario S9, version without LTE IV, annotated in accord with our model 116 9.10 AKA scenario S9, version with LTE IV, annotated in accord with our model 119 9.11 AKA scenario S10 without LTE IV 122 9.12 AKA scenario S10 with LTE IV 123 9.13 AKA scenario S10, version without LTE IV, annotated in accord with our model 124 9.14 AKA scenario S10, version with LTE IV, annotated in accord with our model 126 Index

3GPP, 1 RAU, 77 RNC, 37 AK, 37 RNS, 37 AKA, 2 RRC, 49 AMF, 37 AS, 46 SAE, 1 AuC, 21 SAT, 10 AUTN, 37 SIM, 21 SMC, 47 BDDs, 9 SN, 21 BSC, 21 SQN, 37 BSS, 21 BTS, 21 TAU, 47 TMSI, 21 CAP, 22 challenge-response authentication, 59 UMTS, 1 CK, 37 UP, 49 CMC, 23 use-based proved knowledge authentication, 62 use-based proved knowledge with SNid authenti- E-UTRAN, 46 cation, 63 eNB, 46 USIM, 37 EPS, 40 UTRAN, 37

FN, 21 VLR, 21 GSM, 1 handover, 1 HLR, 21 HN, 21 HSS, 66 idle mode mobility, 1 IK, 37 IMSI, 22 indirect use-based proved knowledge authentication, 62

LTE, 1

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

NAS, 46

xii 1

Chapter 1 Introduction

Over the last several decades, mobile telephony has evolved greatly and mobile devices have become ubiquitous. The ﬁrst generation (1G) technology, which was based on analog technologies, was introduced in the 1980s [10]. Roughly a decade later, the second generation (2G) technology, which used digital radio signals, was introduced. The Global System for Mobile Communications (GSM ) has been the main standard for 2G technology. The third generation (3G) technology Universal Mobile Telecommunications System (UMTS) was developed by the 3rd Generation Part- nership Project (3GPP) and was introduced at the beginning of the twenty-ﬁrst century. Recently, 3GPP has developed the fourth generation (4G) technology, which is best known under the names System Architecture Evolution (SAE) and Long Term Evolution (LTE) [52]. Currently GSM, UMTS, and LTE are all in active use. This leads to interoperation cases such as shown in Figure 1.1 in which a 4G mobile device whose 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 development of mobile telephony technologies and the pervasiveness of mobile communications in our everyday lives, the security of mobile telephony technologies has become more and more important. Over the years, the security of the pure technologies and the interoperation between GSM and UMTS has been investigated thoroughly. How- ever, LTE brings a big challenge of studying the interoperation cases involving all the three technologies. The 3GPP speciﬁcations systematically specify the interoperation cases between UMTS and GSM [1, 7]. The LTE speciﬁcation [8] details the mechanisms for security context switching and mapping to facilitate idle mode mobility and handover1

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

4G mobile station 2G serving network 3G home network (Verizon) (T-Mobile) (Verizon)

Figure 1.1: Example of an interoperation case 2

between LTE and the previous technologies. However, this applies to maintaining context during handover and idle mode mobility. The specification for LTE does not explicitly address establishing of an initial security context, which is established by an authentication procedure, for interoperation. In particular, to date there is no comprehensive enumeration of all interoperation cases and their respective procedures for Authentication and Key Agreement (AKA)2. Consequently, analyzing the security of all possible combinations of interoperation scenarios by hand is a tedious and unreliable undertaking. Model checking techniques provide an effective way to automatically find vulnerabilities in, or to prove the security properties of, security protocols. The goal of this work is to find attacks or give evidence for the security of mobile telephony AKAs, especially in LTE and the interoperation scenarios involving LTE components, by using automated security protocol analysis tools instead of using tedious ad hoc (pencil and paper) approaches.

1.2 Approach

Wireless networks are complex and possess different aspects of security including the security of the protocols, the cryptography systems, the application interfaces, the implementations, and the systems. Attacks can exploit any aspect. When analyzing the mobile telephony protocols and the interoperation scenarios, we focus on the AKAs, and we abstract from the cryptographic algorithms and other aspects of the system. The AKAs are crucial for the security of the technologies. Through the AKAs, the communicating parties aim to authenticate each other (except in GSM – only one-way authentication is expected in GSM AKA) and to establish the session keys, which are used in the future communications. Our analysis is based on the Dolev-Yao model ([50], see Section 2.2.1), which assumes perfect cryptography. We also assume the communication in the network side is secure. Specifically, the communication between the serving network and the home network and the communication between the core network and the base stations are assumed 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 et al. [43], ProVerif has good running time performance. It is a mature tool under active development. It has a significant user community and has been used for a number of security protocols. The modeling language is intuitive and expressive; it allows infinite state systems. The analysis technique has been formally defined and proven sound [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 test actual implementations, although that is beyond the scope of this work.

1.3 Thesis

Symbolic analysis tools can eﬀectively ﬁnd attacks in, and show the security of, mobile telephony 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 cryptography. We provide a detailed discussion on rationale on design decisions for the models and their abstractions from the real protocols. Using ProVerif, the secrecy and authentication properties can be automatically checked, thus replacing tedious manual analysis. The second contribution of this dissertation is to systematically enumerate of all possible interoperation cases between GSM, UMTS, and LTE. We classify these cases as allowed, disallowed, or uncertain, with explicit rationale making detailed reference to the specifications. Of the 243 cases identified, 19 cases involve GSM and UMTS technologies only, and as such are fully treated by the UMTS specification [7]. For cases involving LTE components, an enumeration did not previously exist; it required extensive study of the lengthy specifications. Based on the compat- ibilities (explicitly specified in the specifications) between the components, 138 cases are clearly ruled out and 38 cases are clearly allowed. For the remaining 48 cases the specifications and documentation based on the specifications do not provide a clear indication whether these cases are allowed. For the 48 uncertain cases, we determine the conditions under which these cases could occur. As a third contribution of this dissertation, we identify the corresponding AKA scenario used to establish the initial security context for each allowed or uncertain case. It turns out that there are only 10 distinct AKA scenarios, including the pure GSM, pure UMTS, and pure LTE AKA scenarios which apply in some interoperation cases. Although the GSM/UMTS scenarios are described in the specifications, that is not the case for 86 roaming cases involving LTE. For three of those scenarios we identify two variations which are both consistent with the specifications and which have different authenticity properties. As a fourth contribution, we provide formal models for all the interoperation scenarios 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 basic protocol models for GSM, UMTS, and LTE. This will facilitate adding or modifying scenarios, in case of changes to the specifications or the conditions for the uncertain cases to occur. 4

As a ﬁfth contribution, we compare the authenticity achieved by the AKA scenarios. We categorize the authenticity of the MS to the SN and the authenticity of the SN to the MS into four levels and identify the level of authenticity achieved by each scenario. We also summarize that which protocol blocks are critical to achieve the highest level of the authenticity.

1.5 Outline

The remainder of this dissertation is structured as follows: In Chapter 2, we introduce background on model checking as well as the Dolev-Yao attacker model and Woo- Lam correspondence assertions which are used to specify authentication and secrecy properties. We also review several tools which are used to formally analyze security protocols. We conclude the chapter by introducing the tool ProVerif, which is used in this 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 the work. Chapter 4 provides an overview of the UMTS AKA and discusses our model and analysis results. Chapter 5 reviews the LTE AKA and presents our model and analysis results. Chapter 6 compares the authenticity achieved by the three pure AKAs. Chapter 7 categorizes all possible interoperation cases into allowed, disallowed and uncertain based on the standards and other documentations. Chapter 8 describes the interoperation cases only involving GSM and UMTS components, and presents our models and findings. Chapter 9 describes the interoperation cases involving LTE components, and presents our models and findings. Chapter 10 summarizes the analysis results of all the AKA scenarios. Chapter 11 concludes this work and suggests directions for the future work. An index of definitions is provided on page xii, as well as an appendix with all the models. 5

Chapter 2 Background on Security Protocol Analysis and Related Work

In this Chapter, we ﬁrst review informal analysis techniques for security protocol analysis and prior results on analysis of mobile telephony protocols using the informal analysis techniques (Section 2.1). We then provide background on formal analysis of 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 veriﬁer called ProVerif, which is used in this work (Section 2.4). At the end, we highlight the prior work on formal analysis of mobile telephony protocols (Section 2.5).

2.1 Informal Analysis Techniques and Prior Work for Mobile Telephony Protocols

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

2.1.1 Conventional Analysis In current practice, protocol analysis commonly uses informal techniques, specifically, manual protocol analysis and fuzz testing of security protocols. These informal analysis techniques are discussed in this section. In conventional analysis of security protocols, a protocol is described as a program 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 inject messages. Typically, experts go through the possible runs of the protocol, and try to find scenarios which violate the expected security properties. Such manual protocol analysis 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 with multiple sessions and runs. This kind of analysis depends largely on the skills and knowledge of the experts. There is no guarantee that all attacks will be found. Fuzz testing [10] is another approach to discover security vulnerabilities in protocols. It works by mutating the normal traffic or generating and injecting attack scenarios [81, 80] in order to reveal unexpected behaviors such as security property violations or protocol system crashes. To accelerate the testing procedure, fault injection tools (e.g., DOCTOR [60], ORCHESTRA [48]) have been developed and applied in validating network communication protocols and distributed protocols. A benefit of fuzz testing is that it can find implementation flaws as well as protocol design 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 to the source code in protocol fuzz testing. However, fuzz testing of security protocols is usually conducted in an ad-hoc manner with input selected either randomly or manually. While it can ﬁnd attacks, fuzz testing provides little assurance of their absence.

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 will be discussed later in this chapter. The A5 family of cryptosystems used in GSM and UMTS has been studied extensively. Golic [56], Goldberg [57], Petrovic et al. [84], Barkan et al. [21], and Dunkelman et al. [51] find attacks on the GSM encryption algorithms. Ahmadian et al. [16] show attacks which exploit weakness of A5/2 to eavesdrop or impersonate a UMTS subscriber in a mixed network. Our work focus on protocol flaws rather than cryptographic weaknesses. Fox [53] finds the false base station attack on the GSM AKA due to the lack of 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 GSM and UMTS. Meyer and Wetzel [78] also show the attacks on the handover between GSM 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 redirection attack, which is a variant of the false base station attack. Because the UMTS AKA does not include the network identity, the false base station can redirect the traffic to an unintended network. This attack could cause billing problem. They also show a network impersonation attack, in which the attacker requests the authentication vectors on behalf of an corrupted network and use these authentication vectors to impersonate another network. Han and Choi [59] demonstrate a threat against the LTE handover key management, involving a compromised base station. The attack violates the forward key separation, and could compromise all the future keys between the victim and subsequent base stations. In the attack, the attacker controls a rogue base station and desynchronizes the fresh keying material in the targeted base station to force the user and the base station to compute the next session key based on the current session key and values about the physical layer information. Because the attacker can learn the 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, so that the network ignores the paging response from the victim. Following this denial of service attack, the attacker can also impersonate the victim if no authentication is performed by the network. The second attack has the same attack scenario, but is against a large number of subscribers in a geographic region. Two countermeasures are 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 that the network always authenticates the subscribers and the network maps all incoming paging responses to the correct service. Several other denial-of-service attacks have been found. Lee et al. [69] find a denial-of-service attack on UMTS. In the attack, the attacker triggers the mobile to constantly establish and release radio channels with the network to overload the serving network or cause denial-of-service due to congestion in the signal path. Khan et al. [66] describes the denial-of-service attacks on UMTS by modifying the unprotected messages in the UMTS AKA to cause authentication failure or by sending a large number of valid IMSIs to cause massive authentication data request to exhaust the bandwidth between the serving network and the home network. Kambourakis et al. [65] also identify similar denial-of-service attacks against UMTS by modifying the unprotected 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). We also discuss the correspondence assertions which are used to formally specify authentication 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 computational model. Formal methods constitute an eﬀective approach to the analysis of cryptographic protocols. There are two main approaches to the formal veriﬁcation of cryptographic protocols. One approach, the so called Dolev-Yao or symbolic model, is introduced in the seminal paper by Dolev and Yao [50]. In the Dolev-Yao model the active attacker has complete control over the network. Thus, the attacker can intercept, block, remove, or replay any message sent by an honest principal. The attacker can also create new messages from his/her knowledge, and send these messages to the honest participants. The attacker is a legitimate user and can initiate a conversation with any other user. It is also assumed that the underlying cryptographic primitives 8

achieve perfect security. The attacker can encrypt and decrypt messages with known keys. However, if the attacker does not know the correct decryption key for a given ciphertext, then he/she cannot gain any information from the ciphertext. The perfect cryptography assumption allows that the cryptographic primitives can be represented as symbolic operations. When a property is proved in a Dolev-Yao model, it means if the protocol is accurately modeled at an abstract level, then there are no attacks at 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] is an automatic protocol prover using the computational model; the tools EasyCrypt [22] helps automate game-based proofs.), which is based on complexity theory. In a computational model, messages are bitstrings and cryptographic operations are probabilistic algorithms on these bitstrings. The attacker in a computational model is a polynomial-time probabilistic Turing machine. A protocol or system is secure if the probability of breaking the protocol or system by the plolynomial-time attackers is very low. The proof of security is to reduce the security properties to computational hard problems. Abadi et al. [13] survey computational soundness theorems that relate the symbolic and computational models. An early survey of the application of formal methods is provided in [73].

2.2.2 Events and Correspondence Assertion This section introduces the correspondence assertions and the events used in the correspondence assertions. Woo and Lam [92] define a formal semantic model for authentication protocols that is based on two basic security properties, correspondence and secrecy. Informally, correspondence means that the execution of the different principals in an authentication 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 present and participated in his/her part of the protocol. Secrecy requires that certain information should not be derivable by an attacker. To specify correspondence properties using correspondence assertions [58, 32], the processes representing the protocol are annotated with events, possibly with arguments that record nonces, keys and other relevant information. The events are used to mark important points reached by the principals and have no effect on the principals’ behaviors. Events are not visible to the attacker, nor can they be generated by the attacker. A protocol satisfies a non-injective correspondence assertion, in the form of event(e1(M)) event(e2(M)), if in all runs, and in the presence of the attacker, each execution of the event e1 with particular 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 with the same arguments. It follows immediately that the number of occurrences of the event 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 that the secrecy holds under certain conditions. An example in mobile telephony protocols is that if a principal does not explicitly disable encryption, then ciphered message payload will be never learned by the attacker under Dolev-Yao cryptographic assumption. To specify such property, an event disableEnc is inserted in the point where the principal disables encryption. The query is speciﬁed as query attacker(paylaod) event(disableEnc), which means that if the attacker obtains the secret payload then the event disableEnc must have been previously executed.

2.3 Comparative Overview of Formal Tools

In this section, we brieﬂy review the general-purpose model checker and formal tools used to analyze security protocols (Section 2.3.1). Since Scyther (Section 2.3.2) and AVISPA (Section 2.3.3) are similar to ProVerif and are currently in active use, we discuss them in detail.

2.3.1 Formal Analysis Tools In this section, we introduce general-purpose model checkers, SAL and FDR, and special purpose tools: NRL Protocol Analyzer and LySa. In early stages of this work we used SAL, a general purpose model checker. The main reason to discuss it here is to provide background, because some of the special purpose tools are based on model checking. Model checking [40, 39] is a collection of techniques for automated formal verification of finite-state concurrent systems. To use a general-purpose model checker, the system or protocol is modeled as a state transition system, and the properties are specified in temporal logic. The tool then performs an exhaustive search of the state space of the state transition system to check whether the specification is satisfied. The model usually contains several components, which can be combined synchronously or asynchronously. At each time instant, each component performs a transition in synchronous composition, while only one component is selected to perform a transition in asynchronous composition. The state space can be huge. This causes the so-called state explosion problem [63]. To avoid the state explosion problem, the symbolic model checking technique has been proposed and studied. A symbolic model checker works with sets of states, which are represented by formulas in propositional logic. One symbolic technique is to use Binary Decision Diagrams (BDDs) [63], which often can represent boolean functions compactly. A number of efficient algorithms for manipulating BDD representations enable this symbolic technique to be used in model checking. Another technique is known 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 infinite state system. SAL (Symbolic Analysis Laboratory) is a general purpose model checker developed by SRI and is a framework combining tools for program analysis, theorem proving, and model checking of transition systems [49]. Protocols are defined as state transition systems, and security properties including correspondence assertions can be expressed in temporal logic. The SAL bounded model checker translates a transition system plus properties into a SAT or Satisfiability Modulo Theories (SMT) problem [34]. More specifically, it generates SMT formulae that describe the computations of the system. The SMT solver is used to search for computations that violate the 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 find states satisfying certain assertions. FDR [71] is another general purpose model checker analyzing CSP processes which are translated from protocol descriptions by a compiler called Casper [72]. FDR searches the state space to check whether any trace could violate the specifications representing the security properties in the presence of the attacker. Lowe uses Casper/FDR to find the man-in-the-middle attack on the Needham-Schroeder protocol [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 Analyzer and LySa. We will introduce Scyther and AVISPA in later sections. The NRL Protocol Analyzer [75, 74] was one of the first tools able to prove the correctness of security protocols without bounding the number of sessions or the message size. The NRL Protocol Analyzer uses the Dolev-Yao attacker model and specifies insecure states using a combination of constants and existentially quantified variables. The security properties are specified using rewrite rules. Users may prove a 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 uses a 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 this chapter. 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 as well as whether a Dolev-Yao attacker can falsely achieve authentication by inserting messages at any point. The Lysa tool generates an extension of Horn clauses from the 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 and verified in Scyther and list some applications of Scyther. Most material of this section is adapted from [41, 46, 47, 42]. Scyther [41] can verify either bounded or an unbounded number of runs, using a symbolic backwards search based on patterns. Scyther includes the possibility of unbounded verification with guaranteed termination, analyzes infinite sets of traces in 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, and the system executes the protocol roles. A role performed by a principal is called a run. 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 includes a list of role events and some initial knowledge. Dynamic behavior is modeled as a labeled transition system. Messages are exchanged through two multiset buffers shared by all participants. Attacker’s capabilities determine how the messages are transferred from the output buffer to the input buffer. The options of the attacker model may be no attacker, Dolev-Yao attacker, wireless communications attacker (it does 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 event means 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 such that, for each trace, certain information is unknown to the attacker. Authentication properties can be specified as synchronizations or message agreements. The authentication properties are trace properties. Each trace of the protocol can contain a number of instances of claim events. Only the claims of principals that communicate with non-compromised principals are considered. Non-Injective Synchronization (NI- SYNCH) requires that: the send events must occur before their corresponding read events; the events in the trace corresponds to the events from the protocol; and the contents 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 communications preceding the claim, there are a unique set of runs executing the roles in the protocol. Scyther verifies the security properties by analyzing classes of traces defined by trace 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 security property is violated by any such trace. If no trace of the protocol matches the attack trace pattern, the security property holds. Scyther provides concise representation 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 finite set of patterns from which one can directly construct traces of the protocol. The refined patterns represent the same set of traces as the original pattern. If there exist such refined patterns, then the security property is violated. Otherwise, the security property holds. Scyther has been successfully used for the analysis and design of a number of protocols. Here are some highlights. Cremers and Mauw [45] propose a family of 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 handover schemes and the pre-authentication handover protocol in IEEE 802.16e standard (Mobile WiMAX) using Scyther. An attack in which the attacker learns the master session key was found in the handover schemes. Another attack found on the pre-authentication handover protocol reveals that the attacker can gain the unique key. 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 pseudonymity attack 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 properties in the Automated Validation of Internet Security Protocols and Applications (AVISPA) [19]. We also introduce the four back-ends and some applications of AVISPA. Most material of this section is adapted from [19, 18, 88]. The AVISPA tools use a web-based graphical user interface and support to specify the security protocols and properties by means of a modular and expressive specification language, the High-Level Protocol Specification Language (HLPSL) [18]. The HLPSL allows users to specify protocols by defining the states of the participants and transitions between states. The behavior of each kind of participant is specified in a module, which can be instantiated by one or more participants. (This is similar to what is done in a general purpose model checker like SAL, but in a general purpose checker 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 of the protocol is a composition of instantiated participants which communicate typically on channels controlled by a Dolev-Yao attacker. The whole system composes one or more sessions and also specifies the initial knowledge of the attacker. A trans- lator named HLPSL2IF automatically translates the specification into Intermediate Format (IF) based on first-order set rewriting. Security properties are specified as security goals using concise macros which are internally specified in terms of linear temporal logic. The secrecy property specifies that 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 not explicitly specified between him/her and someone else, it should be considered as an attack. Authentication properties check that a principal’s responder is present in 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 asserts that a request event has been preceded by a witness event and the two events agree on 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 system 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 of Security Protocols (TA4SP) [19]. The OFMC combines infinite state forward model- checking with a lazy Dolev-Yao attacker [23], where terms are generated on-demand during the forward model-checking process. OFMC uses lazy data type to model the infinite state space associated with a protocol. When modeling a lazy Dolev- Yao attacker, it represents terms symbolically to avoid explicitly enumerating the possible messages which may be generated by the attacker. The representation is evaluated in a demand-driven way. When a particular message part is not to be analyzed, the decision about which value the attacker will choose is postponed during the search. The CL-AtSe applies constraint solving with simplification heuristics and redundancy elimination techniques. The CL-AtSe is built in a modular way and is open to extensions for handling algebraic properties of cryptographic operators. The SATMC builds a propositional formula which represents the transitions relations of the protocol. A SAT solver is used to analyze the propositional formula. The TA4SP approximates 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, including the protocols from the Clark/Jacob library [38]. The AVISPA tools have detected a number of previously unknown attacks on some of the protocols analyzed. Lim et al. [70] propose a handover protocol for WLAN, WiBro and UMTS, and verify it using AVISPA. Bouassida et al. [33] analyze the key management architecture for hierarchical group protocols using AVISPA, and find an attack on the members pro- motion protocol. Oheimb and Cuellar [91] propose protocols for location privacy and verify the protocols using AVISPA. They find a man-in-the-middle attack during the design 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 introduces the modeling language (Section 2.4.2) which will be used throughout this dissertation. We brieﬂy describe the analysis techniques (Section 2.4.3). We brieﬂy survey the applications (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, can be used to analyze different aspects of security. The behavior of the attacker can be customized 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 a large or infinite state space. ProVerif, Scyther, AVISPA and NRL are specialized tools for 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 the NRL Protocol Analyzer is not publicly available, we discuss the other three specialized tools in order to decide to use which one to model and analyze the mobile telephony protocols. In the authentication scenarios of mobile telephony technologies, the serving network may run a large number of sessions at the same time. We want to model and check the security properties involving an unbounded number of sessions. ProVerif, Scyther, and TA4SP of AVISPA support analysis of an unbounded number of sessions. However, no trace is output by TA4SP when an attack is found. Thus it is infeasible to decide whether the attack found by TA4SP is a false attack. According to the performance comparison of ProVerif, Scyther and AVISPA done by Cremers et al. in [43], ProVerif is the fastest tool when checking the secrecy and authentication properties for the set of protocols analyzed in that work. ProVerif has capabilities in modeling and specifying the features equivalent to Scyther and AVISPA. In addition, ProVerif is a mature tool under active development. It has a significant user community and has a good documentation [83]. Additionally, ProVerif is able to model the features we want to model. Therefore we choose ProVerif to model and analyze the mobile 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 to represent cryptographic primitives. This section also discusses how to specify secrecy and authentication properties in ProVerif. We briefly describe how to use ProVerif in practice. 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. Private names are not a priori knowledge to the attacker. ProVerif supports tuples, written as (M1,..., Mn ). The attacker has the capability of constructing a tuple when he/she has the terms M1,..., Mn , and the attacker also can recover the i-th element when he/she possesses the tuple. There are constructors that are used to model primitives such as one way functions, encryption and digital signatures. Data is a special kind of constructor. A constructor declared as data is similar to a record: the attacker can construct and decompose data constructors. The relationships between the primitives are captured by destructors which are modeled using rewrite rules. Destructors may be non-deterministic operations on terms. Specifically, when several rules can be applied, only one is chosen. However, ProVerif considers all possibilities when reasoning. For example, symmetric encryption can be defined by the binary constructor sencrypt 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 n g , key ) : b i t s t r i n g A destructor expressing how decryption inverts encryption may be defined as: reduc forall m: b i t s t r i n g , k:key; sdecrypt(sencrypt(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 attacker can learn nothing from sencrypt(m,k) if he/she does not have k. Constructors and destructors can be declared as public or private. If they are declared as public, the attacker can use them to build or manipulate terms. Otherwise, they can only be used 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 the parallel composition of process P and Q. The replication !P represents an unbounded number of processes of P running in parallel. The restriction new n:t; P creates a new name of the type t, which can be used to model fresh random numbers, private channels, 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 and executes P; otherwise, it executes Q. If M does not contain destructors, x is always bound to M and P is always executed. The syntax of the conditional is standard: if M and N can be reduced to the same term, the branch of P is taken; otherwise the branch of Q is taken. The process event(M); P executes event(M), and then executes P. Events annotate processes and mark the stages reached by the protocol but do not affect their behavior. Events are used to specify correspondence assertions (see Section 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 modeling errors. However, ProVerif ignores types during analysis, i.e., types do not affect the dynamic semantics of processes. This enables ProVerif to detect type flaw attacks [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 introduced later in this section) associated with the names, and then builds a set of Horn clauses that encode protocol executions including the behavior of the attacker. This section also introduces the basic idea of the resolution-based algorithm used by ProVerif to determine whether a fact is derivable from the Horn clauses. The instrumentation records dependencies and keeps track of sessions in order to model freshness. The new names are treated as function symbols, which take the messages received by inputs before the new action and the session identifiers as arguments. Each replication of the process is labeled with a distinct, fresh session identifier. The identifier indicates which copy (or session) is executed. Each restriction new 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 new action; and where s is a sequence of session identifiers that label replications before the new action. Using function symbols for new names, at most one name corresponds to 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 includes more received messages in the first argument of the function symbol. Therefore, the analysis is more precise and more costly. A new name b created by the attacker is labeled as a function symbol b0[b[s ]] , where s is a sequence of session identifiers that label replications before the new action. The symbol b0 is a special name which is distinct from other such symbols. It is easy to generate the instrumentation for the attacker by using such a special symbol. Since the attacker can generate names at any time, there is no relation between the generation of new names and the messages previously 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 that the attacker knows p. The fact message(p, p’) represents that the message p’ may be sent on the channel p. The fact m-event(p) represents that event p must have been executed. The fact event(p) represents that event p may have been executed. ProVerif first builds the initial knowledge of the attacker. Each public free name a is known by the attacker, so the clause attacker(a []) is generated. Since the attacker 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 the attacker has the knowledge of M1,..., Mn , then the attacker can apply the public constructor. 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 apply the 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, so the clause message(x,y) ∧ attacker(x) ⇒ attacker(y) is generated. The attacker can also send the messages he/she has on the channels known by the attacker, so the clause attacker(x) ∧ attacker(y) ⇒ message(x,y) is generated. A protocol is typically specified in terms of the process calculus described in Section 2.4.2. A process is translated into a set of clauses. These clauses have the form H ⇒ F, meaning that if the steps defined by H have happened then the step defined by F can happen. The translation uses a sequence of facts (H) which has the form F1, ∧ ..., ∧ Fn to keep track of messages received and the events that have been executed. 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 process adds a clause H ⇒ message(M, N), where H is a sequence of facts. Since the messages received and events executed before this output are recorded in H, the clause signifies that if all facts in H are true, then the message (output N on the channel M) is triggered. The translation of message input in(M, x: t ); P extends H with the fact of the inputing message as H ∧ message(M, x). The translation of parallel composition of two processes is the union of the clauses for both processes. Replication does not need to be translated, because Horn clauses can be applied many times arbitrarily. 18

The translation only inserts new session identifiers into the environment. Since the new names are substituted with function symbols in the instrumentation process, no more translation is needed here. The translation of term evaluation is the union of two sets of clauses: those for the process where the evaluation succeeds (bounded variables are replaced by the corresponding terms), and those for the process where the evaluation fails. Similarly, the translation of the conditional is the union of clauses for the processes where the condition is true, and clauses for the processes where the condition 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 be executed only if the event has occurred before. Furthermore, the translation of the event also adds another clause H ⇒ m-event(M) to signify that the event is triggered when all facts in H are true. The translation ignores the replications of actions, because the Horn clauses can be applied any number of times. This approximation (implicit replications of actions) helps for efficient verification with infinite state space and with any number of protocol runs. However, the approximation can cause false attacks. A particular case of this approximation is that if a message has been sent on a private channel at some point, it may be sent again later. Security properties in ProVerif are specified as queries. A secrecy property is specified as a query of the attacker’s knowledge (the fact attacker(M)). When the fact attacker(M) is derivable from the Horn clauses, the attacker may have the knowledge of M. When the fact attacker(M) is not derivable from the clauses, there is no way that the attacker can gain the knowledge of M. The authentication properties are specified as correspondence assertions in the form of event(e1(M)) event(e2(M)). If all clauses that conclude event e1 contain event e2 in their hypotheses, then event e1 is derivable only when event e2 holds, so the correspondence assertion is proven. To determine whether a fact is derivable from the Horn clauses, ProVerif uses a resolution-based algorithm [25]. The basic idea is to combine pairs of clauses by unification. When the hypothesis of one clause C and the conclusion of another clause C’ are unifiable, a new clause C’ ◦ C can be inferred by removing the conclusion of C’ and replacing it with the 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 clauses representing the protocol and the attacker are inserted. After simplification and elimination, ProVerif executes a fixpoint iteration that adds clauses created by the resolution. In the second phase, it executes a backward depth-first search, which starts with the goal as the root of the derivation and tries to grow the tree. Each branch of the tree grows upwards until it is complete, before the algorithm moves on to 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 proven to terminate for tagged protocols [29] with some conditions. A tagged protocol is defined 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 other constructors. It is shown that the solving algorithm terminates on tagged protocols using only public channels, public-key cryptography with atomic keys, shared-key cryptography and hash functions.

2.4.4 Applications This section highlights the applications of ProVerif on a number of protocols. Chang and Shmatikov [36] use ProVerif to analyze the Bluetooth device pairing protocols. They confirm the offline guessing attack [64] in the Bluetooth device pairing protocol specified in Bluetooth standard version 1.2 and find an attack scenario in Bluetooth SSP when the same device is involved in concurrent SSP sessions. In the attack scenario, the number displayed on the screen may not have been computed in the session which the user is trying to authenticate. This attack may not be practical, since the real implementation may not allow concurrent sessions of pairing. Abadi et al. [14] analyze the Just Fast Key protocol using ProVerif and find some minor limitations and weaknesses. Abadi et al. [12] use ProVerif to verify a certified email protocol and prove the main security properties. Blanchet and Chaudhuri [28] use ProVerif to analyze the protocol of secure file sharing on untrusted storage. They find an integrity attack and propose the fix. Chen and Ryan [37] confirm an attack on current authorization protocols for TPM using ProVerif. They propose and prove correctness of a new authorization protocol for TPM. ProVerif is used to analyze and verify an electronic voting protocol by Kremer and Ryan [67]. ProVerif is used to prove strong secrecy properties in work of Brusò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 the informal analysis techniques in Section 2.1.2. In this section, we highlight some work for mobile telephony protocols using formal techniques. The UMTS AKA is manually proved using an enhanced BAN-logic and the Temporal Logic of Actions (TLA) in the 3GPP speciﬁcation [2]. Tsay and Mjølsnes [89] ﬁnd an attack on the UMTS and LTE AKA using CryptoVerif, an automated protocol analyzer based on a computational model. In fact the attack lives at the symbolic level. It depends on insecurity of the connection between the serving network and the home network. In the attack, the attacker sends out the victim’s IMSI and his own IMSI at the same time to trigger two concurrent AKA sessions. The attacker then redirects the authentication vector response intended for him to the SN and makes the SN believe that the authentication vector is for the victim. At the same time, the attacker blocks the authentication vector message for the victim. Then the attacker redirects the authentication challenge message intended for the victim to himself. Because the authentication vector is originally 20

generated for the attacker, the attacker can compute the correct response. So the attacker 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 assume the connection between serving network and home network is secure. (Although the standard specifies the protocols, their implementations are operator-specific.) Lee et al. [68] analyze the anonymity property of the UMTS and LTE AKA and connection establishment protocols using formal security (computational) models. The assumption in this work is that the attacker is not capable of impersonating any network devices and the underlying cryptographic system is perfect. They manually prove the protocols meet the anonymity requirement, under these assumptions. Arapinis et al. [17] find two attacks against anonymity in UMTS, using ProVerif. To perform the first attack, the attacker sends the paging request message with a victim IMSI to check whether the victim is in a particular area. By sending the paging request multiple times, the attacker can learn the correlation between the IMSI and the TMSI (These terms are introduced in Chapter 3.). In the second attack, the attacker first intercepts one legitimate AKA and records the authentication challenge message. The attacker then replays this authentication challenge message to learn whether the victim is in the area by checking the return failure message. 21

Chapter 3 Modeling 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 of security properties, and our findings (Section 3.3). The security goals, design decisions, and security property specifications are applicable to other protocols, so this chapter 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. We divide 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 figure is taken from [76]. A GSM network consists of several functional entities. A Mobile Station (MS) is a combination of the Mobile Equipment (ME) and the Subscriber Identity Module (SIM ). The SIM card contains the subscriber’s data such as the user’s identification number and a list of available networks. The SIM card also contains the algorithms for authentication and ciphering. In a GSM network, the MS 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 Foreign Network (FN ). An MS might receive service from an FN in areas where its HN does not 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 BSS and controls the radio network. Each BSC maintains multiple BTSs. The VLR contains 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 permanent information of subscribers and also keeps track of the MS’s location. The AuC stores the 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 to establish an encryption key that can then be used to protect the user data exchange between the MS and BS. In addition to the authentication of the MS, GSM is also designed to keep the encryption key secret. If the traffic between the MS and SN is encrypted under the encryption key, the Dolev-Yao attacker (see Section 2.2.1) is not supposed to be able to learn the message payloads. Figure 3.2 shows the AKA. We divide the AKA into blocks following [76], which will be used in the interoperation cases. In block GSM I of the protocol, an MS first transmits its Temporary Mobile Subscriber Identity (TMSI ) to the MSC/VLR. The 22

SN HN

VLR MSC MSC

BSS HLR

BSC

MS BTS BTS AuC

ME + SIM

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 sent to the BS. In case the MSC/VLR does not recognize the TMSI, i.e., the MSC/VLR cannot 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 allocate a new TMSI to the MS. (Allocating a new TMSI is not shown in Figure 3.2; it occurs after 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 random nonce RAND, the HN generates an authentication vector consisting of the three components RAND, XRES, and a session key Kc. XRES and Kc are computed using the algorithms A3 and A8 [94] respectively. Upon receiving the authentication vector (Message 6), the MSC starts a challenge response exchange with the MS in block GSM III. Speciﬁcally, the MSC sends the challenge RAND to the MS (Message 7). Based on the received RAND and the pre-shared key Ki stored on its SIM card, the MS computes the session key Kc as well as a response RES to the received challenge RAND. Subsequently, the MS sends the computed response RES to the MSC. If RES matches the response XRES (which the MSC received from the HN as part of the authentication vector), then the MS has successfully authenticated itself to the SN. In block GSM IV, the MSC forwards the session key to the BS on a secure channel. The BS then decides which encryption algorithm will be used to encrypt the 23

MS BS MSC HN

1. CAP GSM I GSM 2. TMSI

3. User ID Request 4. IMSI

5. IMSI GSM II GSM Generate RAND XRES = A3(Ki, RAND) KC = A8(Ki, RAND) 6. RAND, XRES, KC . GSM IIIGSM 7. RAND

RES = A3(Ki, RAND)

KC = A8(Ki, RAND) 8. RES Verify RES = XRES

9. KC

GSM IV GSM Decide algorithms 10. Selected algorithms

11. CMComplete

Figure 3.2: GSM message sequence diagram [94, 76] communication on the air interface between the BS and the MS (based on the CAP it received from the MS earlier). The BS informs the MS of its choice in the Cipher Mode Command (CMC ) message (Message 9) and starts the possibly encrypted communication. The MSC/VLR generates a new TMSI for the MS and sends it to the MS. The new TMSI is recorded for subsequent traﬃc. The protocol assures the SN of the authenticity of the MS in case the response RES received from the MS matches the XRES received from the HN as part of the authentication vector. Only an MS holding the pre-shared key Ki will be able to compute the correct result RES in response to the random challenge RAND (assuming the security of algorithms A3 and A8). However, GSM does not provide any assurance for the MS that it is in fact connected to a legitimate BS of the SN. The false base station attack was ﬁrst described in [53]. The false base station attack is a man-in-the-middle attack, i.e., the false base station sits in between the MS and the legitimate BS, pretending to be a legitimate BS when communicating with the MS and pretending to be a legitimate MS when communicating with the actual BS. Since the MS sends its capabilities CAP 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 the capabilities CAP it received from the MS so that the legitimate BS will believe that the MS cannot support encryption of data or voice traﬃc. The false BS will simply relay Messages 7 and 8 between the MS and the legitimate BS thus facilitating the proper authentication of the MS to the legitimate BS. The veriﬁcation of whether or not 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 believes that the MS does not support encryption. (Of course, the BS could refuse to service the MS). Consequently, the false BS will be able to listen in and arbitrarily modify the unencrypted communication between the MS and the legitimate BS. In summary, the following security properties are expected: • Key Secrecy The pre-shared key Ki and the cipher key Kc should be kept secret, i.e., the keys are unknown to the attacker.

• Conditional Payload Secrecy The data traﬃc should remain secret against the attacker if the SN chooses to use encryption. Vulnerabilities of the encryption mechanisms are not taken into ac- count, because the attacker model is the Dolev-Yao attacker model, which assumes perfect cryptography (Section 2.2.1).

• Authentication of the MS to the SN The 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 traﬃc cannot be guaranteed in general, e.g., if the SN decides not to use encryption.

• Authentication of the SN to the MS The 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 adequately secure. 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 to the attacker, while messages on a non-private channel can be copied, deleted, and fabricated by the attacker. Another way of modeling the secure communication between the SN and the HN is by encrypting the communication on a public channel. A secret key is shared between the SN and the HN and is never disclosed. The communication between the SN and the HN are encrypted and decrypted using the secret shared key. Since perfect cryptography is assumed in the Dolev-Yao attacker model (Section 2.2.1), the communication over the public channel is secure as long as the shared key is kept secret. The model using encryption on communication between the SN and the HN is more complex than the one using private channel, because when modeling secure communication using encryption, each message has to be encrypted when it is sent out and has to be decrypted when it is received. We use a private channel to model the secure communication between the SN and the HN in our model. A consequence of using private channel is that if we use injective correspondence assertion to specify authentication properties for multiple sessions, false attacks will be found due to the approximation used by ProVerif (see Section 2.4.3). Since standard devices do not support multiple sessions of authentication, we feel it is not important to require injectivity when specifying authentication properties. If an or- dinary correspondence assertion holds, then the injective version will in fact hold as long as the device does not support multiple sessions. Using message headers to identify messages: In our model, each message has a header to indicate the type of the message content. Using message headers allows us to use only one channel between two principals. If message headers are not used and only one channel is used between two principals, type flaw attacks [61] may exist. In addition, with message headers in the model, each principal checks whether the message header in the received message matches the expected header. If it does not match, the message is simply discarded. This mechanism dramatically reduces the state space of the model. In practice, the general message format is defined in [11]. Some fields are specified to help the communicating parties to identify messages. The message types are listed in [62]. For example, message type “IDENT REQ” is used in the message sent by the BTS to the MS to request the identification of the MS. So, we believe it is reasonable to use message headers to identify the messages. Using boolean variables to represent capabilities: The capabilities of the MS are a set of encryption algorithms supported by the MS. By employing the Dolev- Yao attacker model which assumes perfect cryptography, any encryption algorithm is assumed adequately secure in our model. Thus, we only consider two kinds of capabilities: capable of encryption or not. So we model that the MSs may or may not support encryption, but we abstract the particular algorithms prescribed by the standard, 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 analysis of ProVerif will consider all possible executions, which thus include those where the MS has encryption and those where it does not. This is similar than analyzing two different models for the two kinds of MSs. Omitting TMSI/ID request messages: When an MS first roams into an FN, an IMSI is always requested. As mentioned in Section 3.1, if the SN cannot resolve the received TMSI, the SN will require the MS to send the IMSI. An active attacker 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 the SN to request the MS to send its IMSI. To simplify our model, the TMSI and ID request messages are omitted. Using a fresh value to represent an IMSI: IMSI is the permanent identifier of a subscriber and it is used to uniquely identify the mobile subscriber. An IMSI consists of three parts [3]: (a) Mobile Country Code (MCC ), which identifies the country that the subscriber domiciles, (b) Mobile Network Code (MNC ), which identifies the HN of the subscriber, and (c) Mobile Subscriber Identification Number (MSIN ), which identifies the subscriber within the HN. The IMSIs of the MSs could be modeled as a sequence of numbers, represented by integers in ProVerif [28], to uniquely identify the subscribers. In our model, we use fresh value to represent the IMSI. This is a modeling convenience: it models uniqueness; it means we cannot find attacks that somehow exploit information carried by the IMSI. Fresh values are unguessable by the attacker. However, in our model, the MS sends the IMSI in clear over the public channel as it should according to Figure 3.1. Thus, the attacker can learn the IMSI by eavesdropping on the public channel. In practice, an active attacker can gain the IMSI using the so-called “IMSI catchers” [53]. Using a table to model registration of the MS: It is assumed that registration 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). As discussed in [30], key distribution can be modeled using private channels, using constructors and private destructors, or using a table. When modeling key distribution using a private channel c, one process outputs an unbounded number of copies of the credential pair (IMSI, Ki) over the private channel (out(c, (IMSI, Ki))). To get the key corresponding to the IMSI, another process reads 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 private free name. This constructor is public, so that the attacker can also use the constructor to associate the key he/she generates with an IMSI. The destructor returns the key from the IMSI. The destructor is private so that the attacker cannot obtain all the keys 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 a table. The get action tries to retrieve a record which matches some pattern, if no record is found, the process blocks; if several records can be matched, one possibility is chosen, however, ProVerif considers all the possibilities when reasoning. Modeling key distribution using private channels is equivalent to modeling it using tables [30]. One advantage of modeling key distribution using constructors and destructors 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 has no termination problem. In practice, the database schema may or may not actually be defined as the one in our model; but if we find attacks, those attacks do not exploit flaws in registration or key distribution. Adding the IMSI to the authentication data response message: In our model, the IMSI is included in the authentication data response message, which is not specified in the standard (but might well be present in an implementation). Without it, ProVerif finds a candidate derivation from which a trace cannot be automatically reconstructed. We manually analyze the derivation and find that it is a false attack, which arises due to conservative approximations (Section 2.4.3). The authentication data response message is sent to the SN on the private channel after the HN generates the authentication vectors. Due to the approximation, ProVerif finds the derivation where this message is sent again later. In the false attack, the authentication data response message for one IMSI may be sent to the SN in response to a request with another IMSI. To rule out such false attacks, the IMSI is added to the authentication data response message to identify the responses. Adding a data message to specify the secrecy of the data traffic: At the end of the AKA, the SN informs the MS of its choice of encryption and starts communication, which may or may not be encrypted due to the choice of the SN. We want to check the secrecy of the data traffic when encryption is enabled. To check this secrecy property, a data message is included at the end of the model, even though it is not part of the AKA per se. Adding private free names to test the secrecy of session keys: The standard 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 the secrecy of bound variables: encrypting some private free names with the session keys and sending the encrypted messages over a public channel and testing the secrecy of those free names. Since the attacker can gain the encrypted message by eavesdropping on the public channel, the secrecy of the free names implies the secrecy of the session keys. Abstracting algorithms and algorithm identifiers in key derivation functions: 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 which algorithm 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. To model than an MS can engage in multiple authentications, we made a model that applies the replication operator to the part of the process that follows generating the IMSI and registering it with the long term key Ki (Section 2.4.2). The result of the model in which the MS engages multiple sessions of AKA is the same as the result of the model in which the MS only engages one session. This has been tried all the models of all AKA scenarios and the results do not change. So we present the models in 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 accord with our model. The complete model is in Section 11 and in our repository as dissertation/models/S1_GSM_I-IV.pv. Figure 3.3 augments the protocol diagram of Figure 3.2, as a guide to our model. We abstract from the details of the SN, which consists of the BS and the MSC. In the model, we use one process to represent the SN. Labels, like cap ms and cap sn for the first message, are the names of the relevant variables in the processes that model protocol roles. Besides variable names, the other augmentation is the addition of events (the dashed boxes). As described in Section 2.2.2, these are instrumentation used in order to specify authenticity properties as correspondence assertions. Such properties take the form “if event E happens then event F must have happened previously”. For example, whenever the SN decides to proceed with communication, using a particular Kc, because it successfully verified the response to a challenge, then that MS must indeed have sent the response and computed Kc for itself. We specify this 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 choose the 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 events agree on Kc implies that they agree on RAND. Since the response is generated from the 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 until this point. It cannot be put later either, otherwise, there would be executions in which endSN is executed prior to begSN, due to relative timing. This would violate the corresponding property but would not indicate an actual protocol flaw. The event endSN is put immediately after receiving the response from the MS. It cannot be put earlier, otherwise, we cannot capture the stage where the SN has received the response 29

MS SN HN

GSM I GSM 1. CAP cap_ms cap_sn 2. IMSI

imsi_ms imsi_sn 3. IMSI imsi_sn imsi_hn GSM II GSM Generate rand_hn xres_hn = a3(Ki, rand_hn), kc_hn = a8(Ki, rand_hn)

imsi_hn_sn imsi_hn rand_sn 4. IMSI, RAND, XRES, KC rand_hn xres_sn xres_hn kc_sn kc_hn 5. RAND rand_ms rand_sn res__ms = a3(Ki, rand_ms), kc_ms = a8(Ki, rand_ms)

GSM IIIGSM event begSN(imsi_ms,kc_ms) 6. RES res_ms res_sn

Verify res_sn = xres_sn

event endSN(imsi_hn_sn, kc_sn)

Decide whether to use encryption

GSM IV GSM event begMS(imsi_hn_sn, kc_sn) 7. cap_sn enableEnc_ms cap_sn

event endMS(imsi_ms, kc_ms) if cap_sn is false event disableEnc

8. CMComplete

9. payload, if no encryption msg_ms {payload}_kc_sn, otherwise Decrypt message if enableEnc_ms is true

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 ﬁrst message of data traﬃc

and authenticated the MS. The end event could be placed later, which means that the SN has reached the point where the response is verified earlier. However, putting the end event at the exact point where the response is verified is natural and provides better 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 messages over 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. (∗ Public channel between the MS and the SN ∗) f r e e pubChannel: channel . (∗ Secure channel between the SN and the HN ∗) f r e e secureChannel: channel [ p r i v a t e ].

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

type key . (∗ Permanent key ∗) type i d e n t . (∗ Identity of MS ∗) type nonce . (∗ Random number ∗) type msgHdr . (∗ Constant message header ∗) type r e s p . (∗ Response ∗) type sessKey . (∗ S e s s i o n key ∗) We also define a number of (distinct) constant values as message headers to identify messages. The comments refer to message numbers in Figure 3.3. const CAP: msgHdr. (∗ Header of Msg 1 ∗) const ID : msgHdr . (∗ Header of Msg 2 ∗) const AV REQ: msgHdr. (∗ Header of Msg 3 ∗) const AV: msgHdr . (∗ Header of Msg 4 ∗) const CHALLENGE : msgHdr . (∗ Header of Msg 5 ∗) const RES : msgHdr . (∗ Header of Msg 6 ∗) const CMC: msgHdr. (∗ Header of Msg 7 ∗) const CMComplete: msgHdr. (∗ Header of Msg 8 ∗) In ProVerif, the cryptographic functions are declared as constructors and their algebraic properties are defined by rewrite rules (see Section 2.4.2). In our model, the following constructors and destructors are defined.

1 fun a3(nonce, key) : resp. 2 fun a8(nonce, key): sessKey. 3 fun s e n c r y p t ( b i t s t r i n g , sessKey ) : b i t s t r i n g . 4 reduc forall m: b i t s t r i n g , k: sessKey; 5 sdecrypt(sencrypt(m, k), k) = m. 6 reduc encCapability() = true; encCapability() = false. The destructor in lines 4–5 says how decryption inverts encryption: 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 the symbolic model of cryptography, the attacker 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. As described in Section 3.2.1, a public function with a private destructor could be used to model key distributions. However, in this work, we choose to use table to model the key distribution. ProVerif allows non-deterministic rewrite rules, e.g., in line 6 there are two equations for encCapability so that the MS process can choose whether its capability includes encryption or not (see Section 3.2.1). We declare the events used in the correspondence assertions as follows: event begSN(ident , sessKey). event endSN(ident , sessKey). event begMS(ident , sessKey). event endMS(ident , sessKey). Our model uses a private table which associates keys with identities to model the registration of the MS. (∗ The key table consists of pairs (ident, key) shared between 31

the MS and the HN. Table is not accessible by the attacker ∗) table keys(ident , 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 the replication symbol, !). The MS is represented by the following process. The comments refer to message numbers in Figure 3.3.

1 l e t processMS = 2 (∗ Registration and setup ∗) 3 new imsi ms : i d e n t ; 4 new k i : key ; 5 insert keys(imsi ms , k i ) ; (∗ pre−shared identity and key ∗) 6 l e t cap ms : bool = encCapability() in (∗ choose capability ∗) 7 (∗ The protocol ∗) 8 out (pubChannel , (CAP, cap ms ) ) ; (∗ [ Msg 1 ] ∗) 9 out (pubChannel, (ID, imsi ms ) ) ; (∗ [ Msg 2 ] ∗) 10 in ( pubChannel , (=CHALLENGE, rand ms: nonce)); (∗ [ Msg 5 ] ∗) 11 (∗ Compute response ∗) 12 l e t res ms: resp = a3(rand ms , k i ) in 13 (∗ Compute encryption key ∗) 14 l e t kc ms: sessKey = a8(rand ms , k i ) in 15 (∗ MS is authenticating itself to SN ∗) 16 event begSN ( imsi ms , kc ms ) ; 17 out ( pubChannel , (RES , res ms ) ) ; (∗ [ Msg 6 ] ∗) 18 in (pubChannel , (=CMC, enableEnc ms : bool )); (∗ [ Msg 7 ] ∗) 19 event endMS( imsi ms , kc ms ) ; 20 out (pubChannel , CMComplete); (∗ [ Msg 8 ] ∗) 21 in (pubChannel , (=MSG, msg: b i t s t r i n g )); (∗ [ Msg 9 ] ∗) 22 out (pubChannel, sencrypt(secretKc , kc ms ) ) ; 23 i f enableEnc ms = t r u e then 24 l e t msgcontent: b i t s t r i n g = sdecrypt(msg, kc ms ) in 0 .

An instance of processMS models the initial activation of an MS followed by a single attempt at authentication. In lines 3–4, the MS generates a fresh IMSI and a fresh Ki ; in line 5 these are inserted in the table. In our models, only the HN reads the table and only the MS writes it. In line 6, the MS non-deterministically decides on its encryption capability. In lines 8–9 the MS sends its capability and IMSI. The message in line 8 is the header literal CAP paired with boolean cap ms; the one in line 9 pairs the ID header with a value of type ident. In line 10, the process waits until a message is available on the public channel. The message must match the designated format or the process terminates prematurely. The syntax expresses that the message should have two parts, the ﬁrst being 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 the rest of the process. In lines 12 and 14, cryptographic functions are computed and their values are assigned to variables res ms and kc ms. The events in lines 16 and 19 instrument the process to facilitate speciﬁcation of security properties. Event begSN records the IMSI and Kc, to express that, if the response is successfully veriﬁed by the SN, then the SN will consider that it has successfully authenticated the MS with this IMSI and established a shared key Kc with it. To specify the key secrecy, we use the technique discussed in Section 3.2.1. We declare a secret f r e e s e c r e t K c : b i t s t r i n g [ p r i v a t e ]. (∗ a secret to be protected by Kc∗)

and encrypt it under Kc, and send the ciphertext out over the public channel (line 21). The last lines of the MS process receive a message with payload, and decrypt it if encryption was chosen. The process 0 halts immediately. The process representing the SN is deﬁned as follows. The comments refer to message numbers in Figure 3.3.

(One might expect to generate this value using new payload inside the process code; we do 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 event in line 15 records that fact for use in specifications. The process representing the HN is defined as follows.

1 l e t processHN = 2 in (secureChannel , (=AV REQ , i m s i hn: ident)); (∗ [ Msg 3 ] ∗) 33

3 new rand hn : nonce ; (∗ Generate a fresh random number ∗) 4 get keys (= imsi hn , k i h n ) in (∗ attempt to look up key ∗) 5 l e t x r e s hn: resp = a3(rand hn , k i h n ) in 6 l e t kc hn: sessKey = a8(rand hn , k i h n ) in 7 (∗ Send out authentication vector [Msg 4] ∗) 8 out (secureChannel , (AV, imsi hn , rand hn , x r e s h n , kc hn ) ) .

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

3.3 Security Property Speciﬁcations and Findings

This section presents the specifications of secrecy and authentication properties. We then present the analysis result which includes the proved security properties and the attacks 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 (secretKc). • Conditional Payload Secrecy query attacker ( payload ) event (disableEnc). • Authentication of the MS to the SN query id: ident, k: sessKey; event (endSN(id , k)) event (begSN(id , k)). • Payload Secrecy query attacker ( payload ) . • Authentication of the SN to the MS query id: ident, k: sessKey; event (endMS(id , k)) event (begMS(id , k)). Line 1 of the key secrecy specification is a secrecy assumption which is used to speed up the resolution process of ProVerif. It is assumed that the key is unknown to the attacker. At the end of the solving process, ProVerif checks that the key is indeed not known by the attacker. If the attacker learns the key, the proof fails with an 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 have been sent over public channels, by applying functions and rewriting by the specified equations (e.g., it can decrypt if it obtains the right key). The query of key secrecy implies that Kc remains secret since otherwise the attacker would obtain secretKc. The property is unconditional: the key remains secret regardless of whether encryption is chosen. Furthermore, because Kc is computed as a function of RAND, which is sent in the clear, and Ki , secrecy of Kc implies secrecy of Ki . (Recall that Ki is a fresh value, unguessable in the Dolev-Yao model.) 34

Table 3.1: Analysis result of GSM model Key Conditional Authentication of Payload Authentication of Secrecy Payload Secrecy the MS to the SN Secrecy the SN to the MS Proved Proved Proved Failed Failed

The conditional payload secrecy property expresses a requirement: if the attacker obtains the secret payload then the event disableEnc must have previously taken place in the SN. The authentication properties are specified as correspondence assertions (see Section 2.2.2). The property “Authentication of the MS to the SN” says that whenever the event endSN occurs with some arguments id and k, there must have been a prior occurrence of event begSN with the same arguments. Note that the former event occurs in line 10 in the process of the SN; it happens only following the successful check of the expected response from the MS. This property captures authentication of the MS to the SN, because event begSN only occurs at one place, line 13 of the MS process. 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 a challenge and expected response, then indeed there is an MS that reached that stage of its protocol role, for that IMSI and Kc. Note that the IMSI and Kc are parameters of the events. On the other hand, the protocol is clearly not designed to provide authenticity of the MS capability, so that is not included as an event parameter. The event endSN occurs only following successful verification in the SN, as that is the step that is intended to establish authentication. The event begSN is placed in the MS process just before it sends the response, i.e., after it has computed the Kc to which the event refers. The event should not be placed later in the MS process, because successful verification by the SN does not give the SN evidence that the MS has progressed any further. The property of payload secrecy says that payload remains secret. This is not a requirement for GSM; the attacker can certainly obtain payload, e.g., if the MS is not capable of encryption. Nonetheless, we check the property in order to gain confidence in 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 are proved means that there is no attacks against the properties at the Dolev-Yao (see Section 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, as a sanity check on our model and for comparison with other AKAs, we specify the authentication property. ProVerif does find a trace that violates the property:

1 new imsi ms creating imsi m s 1 2 new ki creating ki 2 3 insert keys(imsi ms 1 , k i 2 ) 4 out (pubChannel , (CAP,true)) 5 out (pubChannel , (ID,imsi m s 1 ) ) 35

6 in ( pubChannel , (CHALLENGE, a 3 ) ) 7 event (begSN(imsi ms 1 , a8 ( a 3 , k i 2 ) ) ) 8 out (pubChannel , (RES,a3(a 3 , k i 2 ) ) ) 9 in (pubChannel , (CMC,a 4 ) ) 10 event (endMS(imsi 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 out its encryption capability and identiﬁcation in lines 4–5. The challenge and CMC messages received in line 6 and line 9 are generated and sent by the attacker. The attacker plays as a false BS and feeds the MS with arbitrary challenge and encryption option. This violates the correspondence assertion by executing the event endMS without previously executing the begMS. In this scenario, the attacker cannot provide real service. A more interesting man-in-the-middle scenario is the one ProVerif ﬁnds in violation of the payload secrecy:2

1 new imsi ms creating imsi m s 1 2 new ki creating ki 3 3 insert keys(imsi ms 1 , k i 3 ) 4 out (pubChannel , (CAP,true)) 5 out (pubChannel , (ID,imsi m s 1 ) ) 6 in (pubChannel , (CAP, false )) 7 in (pubChannel , (ID,imsi m s 1 ) ) 8 out (secureChannel , (AV REQ , i m s i m s 1 ) ) 9 new rand hn creating rand hn 2 10 get keys ( imsi ms 1 , k i 3 ) 11 out (secureChannel , (AV,imsi 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 in (pubChannel , (CHALLENGE, rand hn 2 ) ) 15 event (begSN(imsi ms 1 , a8 ( rand hn 2 , k i 3 ) ) ) 16 out (pubChannel , (RES,a3(rand hn 2 , k i 3 ) ) ) 17 in (pubChannel , (RES,a3(rand hn 2 , k i 3 ) ) ) 18 event (endSN(imsi ms 1 , a8 ( rand hn 2 , k i 3 ) ) ) 19 event (begMS(imsi ms 1 , a8 ( rand hn 2 , k i 3 ) ) ) 20 out (pubChannel , (CMC, false )) 21 event (disableEnc) 22 out (pubChannel , (MSG,payload)) The MS sends out its encryption capability and identiﬁcation in lines 4–5 of the trace. The attacker intercepts the capability message and changes it to no-encryption, so the SN receives the modiﬁed capability in line 6. In lines 9–11, the HN generates the authentication vector and sends it to the SN. Lines 13–17 are the one-way challenge-response authentication between the SN and the MS. Since the SN receives

1We modiﬁed the ProVerif output to use smaller numbers, for readability. 2This trace is found by ProVerif when processSN is not replicated. Otherwise, ProVerif only ﬁnds a candidate derivation, from which we reconstruct the same attack by hand (cf. [28]). A process under replication engages in an unbounded number of sessions. 36

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

Chapter 4 Modeling 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 of security properties, and our findings (Section 4.3). We assume readers are familiar with GSM as presented in Chapter 3. So we go quickly and focus on what’s new and different. In Chapter 6, we revisit authentication properties of UMTS in contrast to GSM 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 ) is similar in functionality to the SIM of the GSM network. The Universal Terrestrial Radio Access Network (UTRAN ) is the access network for UMTS networks. The UTRAN is subdivided into individual Radio Network Subsystems (RNS), which consist of Radio Network Controllers (RNC ) and NodeBs. Like the BSC of the GSM network, the RNC is the controlling unit of the UTRAN. Following the GSM model, 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 of an MS to a BS of an SN in UMTS follows the same principles as those in GSM. The main differences between the workings in GSM and UMTS are that those in UMTS are intended to provide mutual authentication of the MS and the SN and they also support integrity protection and freshness guarantees. Specifically, in UMTS II, upon receiving an authentication request from the SN (Message 5 in Figure 4.2), the HN computes 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 Cipher Key (CK ), an Integrity Protection Key (IK ), and an Anonymity Key (AK ). At the core of all computations again is the random nonce RAND as well as the pre-shared key 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 SN initiates the challenge response exchange with the MS as was the case in GSM. Unlike in GSM, the MS receives the Authentication Token (AUTN ) as part of Message 7 which allows the MS to determine whether or not this is a fresh authentication chal- 38

SN HN

VLR MSC MSC

UTRAN HLR

RNC

MS NodeB NodeB AuC

ME + USIM

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 checks whether or not it matches XRES. If so, then the MS has successfully authenticated to 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 used to protect the subsequent communication. In contrast, in UMTS, the SN includes the CAP (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 is integrity protected. Based on Message 10, the MS can verify that the SN received the CAP as the MS sent them. In addition, the integrity protecting as part of Message 10 allows the SN to authenticate itself to the MS. The security of UMTS networks is based and built on the security of GSM networks. However, UMTS provides new and enhanced security features. UMTS provides mutual authentication between the MS and the SN. The SN has correctly authenticated the MS if RES matches XRES. In turn, the authentication of the SN by the MS requires two conditions: First, the AUTN (sent in Message 7) must be fresh—preventing the replay of authentication data—and second, there must be a correctly integrity-protected Message 10. The mandatory integrity protection in UMTS prevents the insertion and modiﬁcation of messages between the MS and the BS. This integrity protection enables the MS to verify the instruction from the SN (Message 10) and also provides protection against bidding-down attacks [53] where an attacker forces to not use any protection on the traﬃc between the MS and the 39

MS BS MSC HN 1. CAP

UMTS 2. TMSI 3. User ID Request

I 4. IMSI

5. IMSI

UMTS Generate RAND & SQN MAC = f1(Ki, AMF, SQN, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

II IK = f4(Ki, RAND), AK = f5(Ki, RAND) AUTN = SQNAK || AMF || MAC

6. RAND, XRES, CK, IK, AUTN

7. RAND, AUTN

UMTS 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)

III Verify 3rd(AUTN) = XMAC

Verify SQN is in correct range

8. RES Verify RES = XRES

9. CK, IK

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

IV 10. ALG, CAP,

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

Figure 4.2: UMTS AKA [94, 76]

SN. The following security properties are expected:

• Key Secrecy The pre-shared key Ki, the cipher key CK , and the integrity key IK should be unknown to the attacker.

• Conditional Payload Secrecy The data traﬃc should remain unknown to the attacker if the SN chooses to use encryption.

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

It is clear that UMTS does not preserve the payload secrecy. For example, if the SN decides 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 rationales in 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 sequence number SQNs to help ensure freshness. Both the MS and the HN keep track of their own counters of SQN respectively. In particular, the HN keeps track of an individual counter SQN for each user. The MS stores the highest sequence number it has accepted in the USIM. When the MS receives the challenge message, it verifies the received SQN is in the correct range. If we model SQNs, they could be represented by integers.1 We tried model without SQN and we could prove the expected properties. So we omit the SQN for simplicity. Moreover, in case of finding an attack, we could have changed the model to include the SQN in the authentication vector to check whether this affected the results. In the UMTS standard, each authentication vector also includes an AMF to indicate 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 a boolean variable which indicates whether the EPS context is in use. AMF is also used to support multiple AKA algorithms for disaster recovery purpose, to change SQN verification parameters and to set the lifetime of keys. Since we model in UMTS context, which is non-EPS context, and do not model the feature of SQN verification and 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 accord with our model. The complete model is in Section 11 and in our repository as dissertation/models/S2_UMTS_I-IV.pv. In Figure 4.3 we augment the protocol diagram of Figure 4.2 with details of the ProVerif model. Figure 4.3 also shows the locations of the events which are used in 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 i can be represented by a constructor succ( i ); and two integers (i , j) is compared by a predicate geq(i , j). 41

MS SN HN

UMTS I UMTS 1. CAP 2. IMSI

3. IMSI

UMTS II UMTS Generate rand_hn, Compute mac_hn, xres_hn, ck_hn, ik_hn and autn_hn 4. IMSI, RAND, XRES,

CK, IK, AUTN 5. RAND, AUTN Compute res_ms, ck_ms, ik_ms, xmac_ms UMTS IIIUMTS Verify mac_ms=xmac_ms

event begSN(imsi_ms, ck_ms, ik_ms) 6. RES

Verify res_sn = xres_sn event endSN(imsi_hn_sn, ck_sn, ik_sn)

Decide whether to use encryption Generate fresh_sn, Compute mac_i_sn

UMTS IV UMTS event begMS(imsi_hn_sn, ck_sn,ik_sn, cap_sn)

7. cap_sn,

CAP, FRESH, MAC-I Verify CAP, MAC-I if cap_sn is false event endMS(imsi_ms, ck_ms, ik_ms, cap_ms) event disableEnc

8. SMComplete, integrity protected

9. payload, FRESH, MAC, if no encryption {payload}_ck_sn, FRESH, MAC, otherwise VerifyMAC, decrypt message if alg_ms supports encryption

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 also abstract 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 also define the types for UMTS session keys and message MACs. type c ip h e rK e y . type integKey . type msgMac . The following constructors and destructors are defined in our model: fun f1(key, nonce): mac. fun f2(key, nonce): resp. fun f3(key, nonce): cipherKey. fun f4(key, nonce): integKey. fun f 9 ( b i t s t r i n g , integKey): msgMac. fun s e n c r y p t ( b i t s t r i n g , cipherKey): b i t s t r i n g . reduc forall m: b i t s t r i n g , k: cipherKey; sdecrypt(sencrypt(m, k), k) = m. fun sencryptInteg( b i t s t r i n g , integKey): b i t s t r i n g . reduc forall m: b i t s t r i n g , k: integKey; 42

sdecryptInteg(sencryptInteg(m, k), k) = m. UMTS authentication establishes the cipher key CK and the integrity key IK , so these are included in the parameters of the events. The protocol also ensures authenticity of the MS capability, which is also included as an event parameter in the correspondence assertion expressing the authentication of the SN to the MS. The events are declared as: event begSN(ident , cipherKey , integKey). event endSN(ident , cipherKey , integKey). event begMS(ident , cipherKey , integKey , bool ). event endMS(ident , cipherKey , integKey , bool ). The process of the MS is as follows. The comments refer to message numbers in Figure 4.3.

1 l e t processMS = 2 (∗ registration and setup ∗) 3 new imsi ms : i d e n t ; 4 new k i : key ; 5 insert keys(imsi ms , k i ) ; 6 l e t cap ms : bool = encCapability() in (∗ choose capability ∗) 7 out (pubChannel , (CAP, cap ms ) ) ; (∗ [ Msg 1 ] ∗) 8 out (pubChannel, (ID, imsi ms ) ) ; (∗ [ Msg 2 ] ∗) 9 in ( pubChannel , (=CHALLENGE, rand ms : nonce , 10 mac ms : mac ) ) ; (∗ [ Msg 5 ] ∗) 11 i f f 1 ( ki , rand ms ) = mac ms then 12 l e t res ms: resp = f2(ki, rand ms ) in 13 l e t ck ms: cipherKey = f3(ki, rand ms ) in 14 l e t ik ms: integKey = f4(ki, rand ms ) in 15 event begSN ( imsi ms , ck ms , ik ms ) ; 16 out ( pubChannel , (RES , res ms ) ) ; (∗ [ Msg 6 ] ∗) 17 in (pubChannel , (=SMC, enableEnc ms : bool , =cap ms , 18 f r e s h ms: nonce, =f9((enableEnc ms , cap ms , f r e s h m s ) , 19 ik ms ) ) ) ; (∗ [ Msg 7 ] ∗) 20 event endMS( imsi ms , ck ms , ik ms , cap ms ) ; 21 out (pubChannel , (SMComplete, f9(smcompleteMsg, ik ms ) ) ) ; 22 (∗ [ Msg 8 ] ∗) 23 in (pubChannel , (=MSG, msg: b i t s t r i n g , fresh msg ms : nonce , 24 =f9((msg, fresh msg ms ) , ik ms ) ) ) ; (∗ [ Msg 9 ] ∗) 25 out (pubChannel, sencrypt(secretCk , ck ms ) ) ; 26 out (pubChannel, sencryptInteg(secretIk , ik ms ) ) ; 27 i f enableEnc ms = t r u e then 28 l e t msgcontent: b i t s t r i n g = sdecrypt(msg, ck ms ) in 0 . The registration process of the MS device is modeled in lines 2–5. The MS generates the 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 MS process 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, to specify the secrecy of CK and IK , we use the technique discussed in Section 3.2.1. We declare secret values f r e e s e c r e t C k : 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 I k : b i t s t r i n g [ p r i v a t e ]. and encrypt it under CK and under IK respectively, and send the ciphertexts out over the public channel (lines 25–26 in the process of the MS). The process of the SN is deﬁned as follows. The comments refer to message numbers in Figure 4.3.

1 l e t processSN = 2 in (pubChannel , (=CAP, cap sn : bool )); (∗ [ Msg 1 ] ∗) 3 in (pubChannel, (=ID, imsi sn: ident)); (∗ [ Msg 2 ] ∗) 4 out (secureChannel , (AV REQ , i m s i s n ) ) ; (∗ [ Msg 3 ] ∗) 5 in (secureChannel , (=AV, imsi h n sn: ident, rand s n : nonce , 6 x r e s s n : resp , c k sn: cipherKey, ik sn: integKey, 7 mac sn : mac ) ) ; (∗ [ Msg 4 ] ∗) 8 out (pubChannel , (CHALLENGE, rand sn , mac sn ) ) ; (∗ [ Msg 5 ] ∗) 9 in (pubChannel, (=RES, res s n : r e s p ) ) ; (∗ [ Msg 6 ] ∗) 10 i f r e s s n = x r e s s n then 11 event endSN ( i m s i h n s n , ck sn , i k s n ) ; 12 new f r e s h s n : nonce ; 13 event begMS( i m s i h n s n , 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 in (pubChannel , (=SMComplete, =f9(smcompleteMsg, ik s n ) ) ) ; 17 (∗ [ Msg 8 ] ∗) 18 new f r e s h m s g s n : nonce ; 19 i f cap sn = f a l s e then 20 event disableEnc; 21 out (pubChannel, (MSG, payload , fresh m s g s n , 22 f9((payload , fresh m s g s n ) , i k s n ) ) ) (∗ [ Msg 9 ] ∗) 23 e l s e 24 out (pubChannel, (MSG, sencrypt(payload , ck s n ) , f r e s h m s g s n , 25 f9((sencrypt(payload , ck s n ) , f r e s h m s g s n ) , i k s n ) ) ) . 26 (∗ [ Msg 9 ] ∗) In lines 5–7, the SN receives the authentication vector from the HN on the secure channel. After checking that the response received from the MS matches the expected response 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 deﬁned as follows.

1 l e t processHN = 2 in (secureChannel , (=AV REQ , i m s i hn: ident)); (∗ [ Msg 3 ] ∗) 3 new rand hn : nonce ; 4 get keys (= imsi hn , k i h n ) in 5 l e t mac hn: mac = f1(ki hn , rand hn ) in 6 l e t x r e s hn: resp = f2(ki hn , rand hn ) in 44

7 l e t ck hn: cipherKey = f3(ki hn , rand hn ) in 8 l e t i k hn: integKey = f4(ki hn , rand hn ) in 9 out (secureChannel , (AV, imsi hn , rand hn , x r e s h n , 10 ck hn , ik hn , mac hn ) ) . (∗ [ Msg 4 ] ∗) As in the GSM model, the HN gets the pre-shared key in line 4 and sends out the authentication vector on the secure channel in lines 9–10, which includes the integrity protection computed in line 5.

4.3 Security Property Speciﬁcations and Findings

This section presents the specifications of secrecy and authentication properties. We then present the analysis result of the security properties. The secrecy and authentication properties are specified similarly to those in the GSM model. • Key Secrecy (secrecy of Ki, CK, and IK) 1 not attacker (new k i ) . 2 query attacker (secretCk). 3 query attacker (secretIk). • Conditional Payload Secrecy query attacker ( payload ) event (disableEnc). • Mutual Authentication between the MS and the SN 1 query x1: ident, x2: cipherKey, x3: integKey; 2 event (endSN(x1, x2, x3)) event (begSN(x1, x2, x3)). 3 query x1: ident, x2: cipherKey, x3: integKey, x4: bool ; 4 event (endMS(x1, x2, x3, x4)) event (begMS(x1, x2, x3, x4)). • Payload Secrecy query attacker ( payload ) . As in GSM, the secrecy assumption in line 1 of the key secrecy stipulates that the pre-shared key Ki cannot be learned by the attacker. The query of conditional payload secrecy specifies that if the SN has enabled encryption, then the data traffic remains secret (in contrast with the property specified in “Payload Secrecy”, this property 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 attacker can modify the capability message to claim the MS has no encryption. However, if the MS chooses the capability of encryption and the attacker modifies that, this will be detected 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 we omit the SQN when modeling the protocol, the mutual authentication properties are proved by ProVerif. The purpose of using SQN is to provide fresh authentication vector, so that an attack in which the attacker records earlier authentication challenge and re-uses it to establish session keys is prevented. Since we model a single round of the AKA, the result shows that SQN is not needed in single round authentication. 45

Table 4.1: Analysis result of UMTS model Key Conditional Authentication of Payload Authentication of Secrecy Payload Secrecy the MS to the SN Secrecy the SN to the MS Proved Proved Proved Failed Proved 46

Chapter 5 Modeling 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 security properties, and our findings (Section 5.3). Like Chapter 4, we go quickly and focus on what’s new and different from GSM and UMTS. We revisit the authentication properties of LTE in Chapter 6 where we will compare them with the ones in GSM and UMTS.

5.1 Overview of LTE AKA

This section describes the LTE AKA and informally specifies the security goals. In contrast to GSM and UMTS, LTE provides different key hierarchy. LTE also introduces the security context concept. In addition, LTE provides implicit authentication of 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 are grouped 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 UMTS architecture Figure 4.1), which has a star model (each RNC controls many BSs), the structure 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). The features supported by the BS controller (BSS in GSM, RNC in UMTS) have been distributed between the eNB and the MME. The MME is the main control element for the access network. It initiates the authentication, keeps track of the location of the MSs, retrieves the MSs’ subscription profile from the HN, and manages service connectivity. In contrast to UMTS security, LTE introduces an enhanced key derivation hierarchy that allows the distinguishing of protection mechanisms on Non Access Stratum (NAS) and Access Stratum (AS). The NAS traffic is the communication between the MS and the MME. The AS traffic is the communication between the MS and the eNB. In addition, LTE defines a comprehensive security context framework, including native vs. mapped security contexts, current vs. non-current security contexts, and full vs. partial contexts [8]. A security context typically consists of a set of security parameters including cryptography keys and identifiers for respective cryptographic mechanisms. A native security context is established by a run of LTE AKA, while a mapped security context is converted from another system during inter-system mobility 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

SN HN

VLR MME MME

E-UTRAN HLR NAS eNodeB

MS eNodeB AuC AS ME + USIM

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

Figure 5.1: LTE architecture [94, 52] a non-current one is not currently activated and exists simultaneously with the current one. A full security context contains the NAS keys and the identifiers of the NAS cipher and integrity algorithms, while a partial security context does not include them, i.e., no successful NAS Security Mode Command (SMC ) procedure has been run for a partial security context. A partial native security context is always a non-current security context and it can be transformed into a full native security context by executing the NAS SMC procedure. The goal of the LTE AKA is to provide mutual authentication between the MS and a specific SN with a SN identifier and to establish a security context to protect the communication between the MS and the SN. Figure 5.2 shows the authentication scenario. 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 NAS signalling connection exists, the network can initiate an AKA at any time [5]. Before the service request or the NAS signalling connection establishing, the attach request must have already been executed [5]. Therefore, the first block of the LTE AKA can contain an attach request or a TAU request. If the AKA starts with an attach request, the first block (LTE I in Figure 5.2) contains the transmission of the identity and the security capabilities of the MS. If instead of the initial network attach request, the AKA starts with a TAU request, in the first block (LTE I’, Figure 5.3), an additional nonce NONCEMS is sent to 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 mode mobility or handover. 48

MS BS MME HN

1.CAP LTE LTE 2. GUTI

3. Identity Request

I 4. IMSI 5. IMSI, SNid, Network Type Generate RAND & SQN LTE LTE MAC = f1(Ki, AMF, SQN, RAND) XRES = f2(Ki, RAND), CK = f3(Ki, RAND)

II IK = f4(Ki, RAND), AK = f5(Ki, RAND) AUTN=SQNAK || AMF || MAC KASME=KDF(CK, IK, SNid, SQNAK) 6. RAND, AUTN, XRES, KASME

7. RAND, AUTN, KSIASME

AK = f5(Ki, RAND), SQN = 1st(AUTN)AK

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

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

st KASME = KDF(CK, IK, SNid, 1 (AUTN)) 8. RES

Verify RES = XRES

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) 9. CAP, NAS-Algs, [NONCES], NAS-MAC LTE LTE KNASenc = KDF (KASME, NAS-enc-alg, Alg-ID) K = KDF(K , NAS-int-alg, Alg-ID) NASint ASME

IV XNAS-MAC = EIA((CAP, Algs),KNASint) Verify XNAS-MAC = NAS-MAC Start ciphering/deciphering and integrity protection 10. NAS SMComplete ciphered , integrity protected Verify integrity of message 10

KeNB = KDF(KASME)

11. CAP, KeNB

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)

LTE LTE 12. AS-Algs, AS-MAC

V 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 13. AS SMComplete Integrity protected Verify integrity of message 13

Figure 5.2: LTE AKA an EPS security context [8]. However, since the MS does not know when the mapping will happen, the nonce is always included in the TAU request message [52]. In LTE AKA, the nonce is never used. So the ﬁrst block is always LTE I. LTE I’ will be used in one interoperation scenario (Chapter 9). In LTE II, the HN derives the authentication vector from the UMTS authentication vector (Section 4.1). Unlike in GSM and UMTS, the HN derives the master key KASME and provides it to the MME together with the respective authentication 49

MS BS MME

1. CAP LTE LTE 2. GUTI

3. NONCE_MS

4. Identity Request 5. IMSI

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 derived key is bound to a specific MME. In LTE III, the MME sends the authentication challenge, which includes the random challenge RAND, the authentication token AUTN , and the key identifier KSIASME . The KSIASME is used to identify the KASME and the session keys derived from the KASME . Upon receiving the challenge, the MS verifies the freshness and the integrity of the authentication vector. The MS then computes the response and the master key and sends the response to the MME. The MME then checks whether the response matches the expected response. After executing the challenge-response procedure (LTE III), the MS and the MME proceed to the NAS SMC procedure (LTE IV) in which the MME derives the NAS encryption and integrity keys and decides the encryption and integrity protection algorithms based on the capabilities of the MS. The decided algorithms, along with the CAP received as part of message 1, are sent from the MME to the MS in an integrity protected NAS SMC message. Upon the receipt of the SMC message, the MS verifies the integrity of the message and confirms that the security capabilities match the ones the MS has sent out. In case starting with LTE I’, if the KASME is derived by the MME taking the nonces NONCEMS and NONCEMME as input, both nonces are included in the integrity protected message. In such case, in addition to the capabilities, the MS also verifies the NONCEMS matches the one originally sent in LTE I’ (this is discussed further in Chapter 9). When the MS needs to send or receive data, the AS SMC procedure is executed. The MME sends the MS’s security capabilities and KASME to an eNB, which decides the AS algorithms and derives the eNB key KeNB from the KASME . The eNB also derives the encryption and integrity protection keys for the Radio Resource Control (RRC ) traffic and the User Plane (UP) traffic. The RRC keys are used to encrypt and protect the integrity of RRC signaling traffic. The UP cipher key is used to encrypt user data. The AS security context is established by sending the AS SMC message from the eNB to the MS. The AS SMC message contains the selected algorithms and is integrity protected with the RRC integrity key. The AS security mode complete message replied by the MS is also integrity protected with the RRC integrity 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, and the cipher and integrity keys are derived from the master key. The successful use of derived keys enables the MS to indirectly authenticate the speciﬁc MME. The following security properties are expected:

• Key Secrecy The pre-shared key Ki, the local master key KASME , the eNB key KeNB , and the derived NAS and AS integrity keys and cipher keys should be unknown to the attacker.

• Conditional Payload Secrecy The data traﬃc should remain unknown to the attacker if the SN chooses to use encryption.

• Mutual Authentication between MS and MME The 4G AKA is designed to provide for the mutual authentication between the MS and the speciﬁc MME.

• Authentication of the BS to the MS The 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 SN decides 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 this section, we discuss the design choices that distinguish our model from the GSM and UMTS models. Abstracting the KSI from the authentication challenge message: When challenging the MS in the AKA, the MME includes the KSIASME , which is allocated 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 fresh AKA, the KSIASME is omitted from the authentication challenge message. Including both the IMSI and the SN identity in the authentication data response message: We explain the design choice of including the IMSI in the authentication 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 authentication data response message). For similar reasons, the SN identity is also included in the authentication data response message. Including the SN identity in the authentication challenge message: The SN identity is included in the authentication challenge message, which is not speciﬁed in the standard. During the AKA, both the HN and the MS compute the KASME from CK , IK , and SN identity. However, the speciﬁcation does not include how the MS gets the SN identity. We model the MS to obtain the SN identity through the authentication challenge message. Separating the eNB process from the MME process: Two main components of the SN are the MME and the eNB. As mentioned in Section 5.1, the NAS SMC messages are exchanged between the MME and the MS and the AS SMC messages are exchanged between the eNB and the MS. In the model, both the NAS and AS SMC procedures are included. We use a separate eNB process to specify the AS SMC procedure. Modeling communication between the BS and the MME using a private channel In addition to assuming the security of communication between the MME and the HN, we also assume that communication between the eNB and the MME is secure. For this reason, a private channel is declared to model the secure communication between the BS and the MME.

5.2.2 LTE Model In this section, we present the LTE model along with the diagram annotated accord with our model. The complete model is in Section 11 and in our repository as dissertation/models/S3_LTE_I-V.pv. Figure 5.4 augments the protocol diagram of Figure 5.2 with details of the ProVerif model. As mentioned before, the MME communicates with the HN and BS on secure channels. (∗ Secure channel between MME and HN ∗) f r e e secureChannel: channel [ p r i v a t e ]. (∗ Secure channel between MME and BS ∗) f r e e sChannelSnBts: channel [ p r i v a t e ]. In addition to the built-in types, we declare additional types. type key . (∗ pre−s h a r e d Ki ∗) type i d e n t . (∗ identity of the MS and the SN ∗) type nonce . (∗ random number ∗) type msgHdr . (∗ message header ∗) type r e s p . (∗ r e s p o n s e ∗) type c ip h e rK e y . (∗ cipher key in UMTS authentication vectors ∗) type integKey . (∗ integrity key in UMTS authentication vectors ∗) type mac . (∗ mac in authentication vectors ∗) type msgMac . (∗ integrity protection of messages ∗) type asmeKey . (∗ K ASME ∗) 52

MS BS MME 4G HN

LTE I LTE 1.CAP 2. IMSI

3. IMSI, SNid, Network Type

LTE IILTE 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) 4. IMSI, SNid RAND, AUTN, XRES, KASME 5. RAND, AUTN, SNid XMAC = f1(Ki, RAND) MAC = XMAC, RES = f2(Ki, RAND)

LTE IIILTE CK = f3(Ki, RAND), IK = f4(Ki, RAND) KASME = KDF(CK, IK, SNid,) 6. RES

Verify RES = XRES

KNASenc = KDF (KASME,), KNASint = KDF(KASME,) Decide enableEnc?, NAS-MAC = EIA((enableEnc, CAP), KNASint)

event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn) 7. eableEnc, CAP, NAS-MAC

KNASenc = KDF (KASME), KNASint = KDF(KASME) XNAS-MAC = EIA((CAP, enableEnc), KNASint) LTE IV LTE Verify XNAS-MAC = NAS-MAC Start ciphering/deciphering and integrity protection

event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms) event begSN(imsi_ms, snid_ms, kasme_ms) 8. NAS Security Mode Complete ifenableEnbciphered , integrity protected otherwise integrity protected Verify the integrity of message 8 event endSN(imsi_sn, snid_sn, kasme_sn)

KeNB = KDF(KASME)

9. CAP, KeNB

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB) Decide enableENC, AS-MAC = EIA(enableEnc, KRRCint) Start integrity protection

LTE V LTE event begMS_ENB(imsi_sn, kenb_sn, cap_sn)

10. enableEnc, AS-MAC

KeNB = KDF (KASME), KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB), KUPenc = KDF (KeNB) XAS-MAC = EIA( enableEnc, KRRCint) Verify XAS-MAC = AS-MAC

event endMS_ENB(imsi_ms, kenb_ms, cap_ms)

11. AS SMC Complete Integrity protected

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

Decrypt message ifenableEnc_ms is true

Figure 5.4: LTE AKA (Figure 5.2) annotated in accord with our model type nasEncKey . (∗ NAS encryption key ∗) type nasIntKey . (∗ NAS inegerity key ∗) 53

type enbKey . (∗ type o f K enb ∗) type asEncKey . (∗ AS encryption key ∗) type a s I n t K e y . (∗ AS integrity key ∗) type upEncKey . (∗ UP encryption key ∗) Similarly to the GSM and UMTS model, we also define a number of distinct constant values as message headers to identify messages (not shown). The key derivation functions and the cryptographic functions are declared as: fun f1(key, nonce): mac. fun f2(key, nonce): resp. fun f3(key, nonce): cipherKey. fun f4(key, nonce): integKey. fun kdf asme(cipherKey , integKey , ident): asmeKey. fun k d f n a s enc(asmeKey) : nasEncKey. fun k d f n a s int(asmeKey): nasIntKey. fun f i n t e g n a s ( b i t s t r i n g , nasIntKey): msgMac. fun k d f enb(asmeKey): enbKey. fun k d f a s enc(enbKey): asEncKey. fun k d f a s int(enbKey): asIntKey. fun k d f u p enc(enbKey): upEncKey. fun f i n t e g a s ( b i t s t r i n g , asIntKey): 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 forall m: b i t s t r i n g , k: nasEncKey; s d e c r y p t nas(sencrypt nas(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 forall m: b i t s t r i n g , k: asEncKey; s d e c r y p t as(sencrypt as(m, k), k) =m. fun s e n c i n t n a s ( b i t s t r i n g , nasIntKey): b i t s t r i n g . reduc forall m: b i t s t r i n g , k: nasIntKey; s d e c i n n a s ( s e n c i n t nas(m, k), k) =m. fun s e n c i n t a s ( b i t s t r i n g , asIntKey): b i t s t r i n g . reduc forall m: b i t s t r i n g , k: asIntKey; s d e c i n a s ( s e n c i n t as(m, k), k) =m. fun senc up ( b i t s t r i n g , upEncKey): b i t s t r i n g . reduc forall m: b i t s t r i n g , k: upEncKey; sdec up ( senc up(m, k), k) =m. The type system of ProVerif occasionally makes it difficult to apply functions to arguments due to type mismatches. We can overcome this by defining a special type of constructor, which acts as an identity function. We define a type converter which converts bool into bitstring . fun bool2bitstring( bool ): b i t s t r i n g [data, typeConverter]. The type converter just changes the types and has no other effect. Because the type converter constructor is declared as a data constructor, the attacker can construct and decompose 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 during reasoning. 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 to model 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 authentication properties are declared as: event begSN(ident , ident , asmeKey). event endSN(ident , ident , asmeKey). event begMS(ident , ident , asmeKey, bool ). event endMS(ident , ident , asmeKey, bool ). event begMS ENB(ident , enbKey, bool ). event endMS ENB(ident , 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 that the SN can be modeled in one process is that it is assumed that the communication between the BS and the MSC is secure. We could also model the SN in LTE in one process, however, because the NAS SMC procedure has two options to enable encryption 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 AS SMC procedure as a parameterized procedure (as in the MS process) or as a separate process. We choose to model it as a process, since it is natural to model a component as a process. The MS process is deﬁned as follows. The comments refer to message numbers in Figure 5.4.

1 (∗ AS SMC procedure in process MS ∗) 2 l e t pMSAS( kasme ms: asmeKey, imsi ms: ident, cap ms : bool ) = 3 l e t kenb ms: enbKey = kdf e n b ( kasme ms ) in 4 l e t kasenc ms: asEncKey = kdf a s e n c ( kenb ms ) in 5 l e t k a s i n t ms: asIntKey = kdf a s i n t ( kenb ms ) in 6 l e t kupenc ms: upEncKey = kdf u p e n c ( kenb ms ) in 7 in (pubChannel , (=ASSMC, enableEnc as ms : bool , =f i n t e g a s 8 (bool2bitstring(enableEnc as ms ) , k a s i n t m s ) ) ) ; (∗ [ 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 m s ) ) ) ; (∗ [ Msg 11] ∗) 11 event endMS ENB( imsi ms , kenb ms , cap ms ) ; 12 in (pubChannel , (=MSG, datamsg: b i t s t r i n g , 13 =f i n t e g as(datamsg, kasint m s ) ) ) ; (∗ [ Msg 12] ∗) 14 out (pubChannel , sencrypt as(secret , kasenc ms ) ) ; 15 out (pubChannel, senc i n t as(secret , kasint m s ) ) ; 16 out (pubChannel , senc up(secret , kupenc ms ) ) ; 17 i f enableEnc as ms = t r u e then 18 l e t msgcontent: b i t s t r i n g = s d e c r y p t as(datamsg, kasenc ms ) in 0 . 19 20 (∗ process respresenting MS ∗) 21 l e t processMS = 22 new imsi ms : i d e n t ; 23 new k i : key ; 55

24 insert keys(imsi ms , k i ) ; 25 l e t cap ms : bool = encCapability() in 26 out (pubChannel , (CAP, cap ms ) ) ; 27 out (pubChannel, (ID, imsi ms ) ) ; 28 in ( pubChannel , (=CHALLENGE, rand ms : nonce , 29 =f1(ki , rand ms ) , snid ms: ident)); (∗ [ Msg 5 ] ∗) 30 l e t res ms: resp = f2(ki, rand ms ) in 31 l e t ck ms: cipherKey = f3(ki, rand ms ) in 32 l e t ik ms: integKey = f4(ki, rand ms ) in 33 l e t kasme ms: asmeKey = kdf asme ( ck ms , ik ms , snid ms ) in 34 out ( pubChannel , (RES , res ms ) ) ; (∗ [ Msg 6 ] ∗) 35 l e t knasenc ms: nasEncKey = kdf n a s e n c ( kasme ms ) in 36 l e t k n a s i n t ms: nasIntKey = kdf n a s i n t ( kasme ms ) in 37 in (pubChannel , (=NASSMC, enableEnc nas ms : bool , =cap ms , 38 =f i n t e g nas ((enableEnc nas ms , cap ms), knasint m s ) ) ) ; 39 (∗ [ Msg 7 ] ∗) 40 event endMS( imsi ms , snid ms , kasme ms , cap ms ) ; 41 out (pubChannel , sencrypt nas(secret , knasenc ms ) ) ; 42 out (pubChannel, senc i n t nas(secret , knasint m s ) ) ; 43 event begSN ( imsi ms , snid ms , kasme ms ) ; 44 i f enableEnc nas ms = f a l s e then 45 out (pubChannel , (NASSMComplete, nas smcomplete msg , 46 f i n t e g n a s ( nas smcomplete msg, knasint m s ) ) ) ; (∗ [ Msg 8 ] ∗) 47 pMSAS( kasme ms , imsi ms , cap ms ) 48 e l s e 49 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 nas(sencrypt n a s ( nas smcomplete msg , 52 knasenc ms), knasint m s ) ) ) ; (∗ [ Msg 9 ] ∗) 53 pMSAS( kasme ms , imsi ms , cap ms ) . Similarly to the GSM model, this model specifies the registration process of the MS device in lines 22–24. In lines 28–29, the MS receives and checks the authentication challenge message. The MS computes the KASME in line 33. In lines 37–39, the MS receives the NAS SMC message and verifies the integrity and the received capabilities. The MS then sends out the SMC complete message which is ciphered if the encryption is enabled and integrity protected (lines 45–46 or 49–52). Lines 47 and 53 call a parameterized process which specifies the AS SMC procedure in lines 3–10 and receives the data message in lines 12–13. As in the GSM model, to test the secrecy of the keys, the MS encrypts a private free name with the keys, and sends them out on the public channel (lines 41–42 and 14–16). The process representing the MME is defined as follows. The comments refer to message numbers in Figure 5.4.

1 l e t processMME = 2 in (pubChannel , (=CAP, cap sn : bool )); (∗ [ Msg 1 ] ∗) 3 in (pubChannel, (=ID, imsi sn: ident)); (∗ [ Msg 2 ] ∗) 4 new s n i d s n : i d e n t ; 5 out (secureChannel , (AV REQ , i m s i s n , s n i d s n ) ) ; (∗ [ Msg 3 ] ∗) 6 in (secureChannel , (=AV, =imsi s n , =s n i d s n , r a n d s n : nonce , 56

7 x r e s sn: resp, 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 in (pubChannel , (=RES, =xres s n ) ) ; (∗ [ Msg 6 ] ∗) 11 event begMS( i m s i s n , s n i d s n , kasme sn , cap sn ) ; 12 l e t k n a s e n c sn: nasEncKey = kdf n a s e n c ( kasme sn ) in 13 l e t k n a s i n t sn: nasIntKey = kdf n a s i n t ( kasme sn ) in 14 out (pubChannel , (NASSMC, cap sn , cap sn , 15 f i n t e g n a s ( ( cap sn , cap sn), knasint s n ) ) ) ; (∗ [ Msg 7 ] ∗) 16 in (pubChannel , (=NASSMComplete, msg nas : b i t s t r i n g , 17 =f i n t e g n a s ( msg nas, knasint s n ) ) ) ; (∗ [ Msg 8 ] ∗) 18 i f cap sn = t r u e then 19 i f s d e c r y p t n a s ( msg nas, knasenc s n ) = nas smcomplete msg then 20 event endSN ( i m s i s n , s n i d s n , kasme sn ) ; 21 out (sChannelSnBts , (kasme sn , i m s i s n , cap sn ) ) 22 e l s e 0 23 e l s e 24 i f cap sn = f a l s e then 25 i f msg nas = nas smcomplete msg then 26 event endSN ( i m s i s n , s n i d s n , kasme sn ) ; 27 out (sChannelSnBts , (kasme sn , i m s i s n , cap sn ) ) 28 e l s e 0 29 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 from the MS in line 10. The NAS SMC procedure of the MME side is specified in lines 14–17. In lines 21 and 27, the MME sends the KASME , as well as the identity and capabilities of the MS, to the eNB through the private channel. The code of the eNB process is defined as follows. The comments refer to message numbers in Figure 5.4.

1 l e t processENB = 2 in (sChannelSnBts , (kasme enb: asmeKey, imsi e n b : i d e n t , 3 cap enb : bool )); 4 l e t kenb enb: enbKey = kdf e n b ( kasme enb ) in 5 l e t kasenc enb: asEncKey = kdf a s e n c ( kenb enb ) in 6 l e t k a s i n t enb: asIntKey = kdf a s i n t ( kenb enb ) in 7 l e t kupenc enb: upEncKey = kdf u p e n c ( kenb enb ) in 8 event begMS ENB( i m s i e n b , kenb enb , cap enb ) ; 9 out (pubChannel , (ASSMC, cap enb , 10 f i n t e g as(bool2bitstring(cap enb), kasint e n b ) ) ) ; (∗ [ Msg 10] ∗) 11 in (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 then 14 event disableEnc; 15 out (pubChannel, (MSG, payload , finteg as(payload , kasint e n b ) ) ) 16 (∗ [ Msg 12] ∗) 17 e l s e 18 out (pubChannel , (MSG, sencrypt as(payload , kasenc enb ) , 19 f i n t e g as(sencrypt as(payload , kasenc enb), kasint e n b ) ) ) . 57

20 (∗ [ Msg 12] ∗)

The eNB receives the KASME and the identity and capabilities of the MS from the MME in lines 2–3. The AS keys are derived in lines 4–7. The AS SMC procedure is modeled in lines 9–12. After successfully executing the AS SMC procedure, the eNB sends out the data message either in line 15 or in lines 18–19, depending on whether the encryption is enabled or not. The HN process is deﬁned as follows.

1 l e t processHN = 2 in (secureChannel , (=AV REQ , i m s i hn: ident, snid hn: ident)); 3 (∗ [ Msg 3 ] ∗) 4 new rand hn : nonce ; 5 get keys (= imsi hn , k i h n ) in 6 l e t mac hn: mac = f1(ki hn , rand hn ) in 7 l e t x r e s hn: resp = f2(ki hn , rand hn ) in 8 l e t ck hn: cipherKey = f3(ki hn , rand hn ) in 9 l e t i k hn: integKey = f4(ki hn , rand hn ) in 10 l e t kasme hn: asmeKey = kdf asme ( ck hn , ik hn , s n i d h n ) in 11 out (secureChannel , (AV, imsi hn , snid hn , rand hn , 12 x r e s h n , mac hn , kasme hn ) ) . (∗ [ Msg 4 ] ∗)

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

5.3 Security Property Speciﬁcations and Findings

1 query attacker ( payload ) . 2 query attacker ( payload ) event (disableEnc). 3 query attacker ( s e c r e t ) . 4 query x1: ident, x2: ident, x3: asmeKey; 5 event (endSN(x1, x2, x3)) event (begSN(x1, x2, x3)). 6 query x1: ident, x2: ident, x3: asmeKey, x4: bool ; 7 event (endMS(x1, x2, x3, x4)) event (begMS(x1, x2, x3, x4)). 8 query x1: ident, 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 secrecy of the data. As expected, the payload can be learned by the attacker when the MS is not capable of encryption. The conditional secrecy (line 2) expresses that if the attacker obtains the secret payload then the event disableEnc must have previously taken place. Because the NAS and AS keys are computed only from KASME , the secrecy of any NAS or AS key implies the secrecy of KASME . The authentication of the MS to the MME (lines 4–5) is speciﬁed in such a way that if the event endSN with arguments IMSI, SN identity and KASME is executed, 58

Table 5.1: Analysis result of LTE model Conditional Auth. of Auth. of Auth. of Key Payload Payload the MS to the MME the BS to Secrecy Secrecy Secrecy the SN to the MS the 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 two parties agree on the identity of the SN, we include the SN identity in the parameters of the correspondence assertion. The event endSN is inserted after receiving and checking the security mode complete message. Since the KASME is computed from the CK, the IK and the SN identity, and they are not used in the challenge-response round, until receiving and confirming the security mode complete message, the MME cannot conclude that the MS receives the correct SN identity and derives the same KASME . The authentication of the MME to the MS is specified in lines 6–7. Besides the identities and keys, the MS also provides for the authenticity of the security capabilities, so we include the capabilities in the parameters of events. In addition to the authentication between the MS and the MME, the protocol should also provide for the authentication of the BS to the MS, which is specified in lines 8–9. The security capabilities (modeled as encryption options) are included in the parameters of the events to specify that the events should agree on the encryption option. Table 5.1 shows the analysis result of the above properties. 59

Chapter 6 Comparative Authenticity

In this chapter, we compare the authenticity achieved by the different generations of the technologies. We review differences between corresponding blocks in the different technologies, which are defined in Chapter 3–5. We compare the specifications of the authentication properties (correspondence assertions), including the parameters used in the correspondence assertions. During the discussion, we establish some terminolo- gies for different types of the authenticity. This discussion of the authenticity in pure AKAs serves as a basis for our later comparison of the authenticity of interoperation scenarios (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 MS to the SN.

6.1.1 GSM vs. UMTS In this section, we introduce the authentication of the MS to the SN in GSM and UMTS using the challenge response procedure to check if the MS has the correct permanent key Ki. We compare the corresponding blocks in GSM and UMTS, in which the MS achieves to authenticate itself to the SN. We consider the formal speciﬁca- tions of the authentication properties, i.e., the correspondence assertions. In addition to the parameters used in the correspondence assertions, we also discuss the cryptographic material implied by the parameters. Both protocols provide the same type of authentication using similar challenge-response procedures. As we described in Chapter 3, in GSM, the MS and the HN share the permanent key Ki, which never leaves the MS and the HN. The HN generates the authentication vector based on the random number RAND and the permanent key Ki. The HN sends the authentication vector to the MSC. Note that the MSC cannot create the challenge and the response. The MSC authenticates the MS by testing if the MS has the knowledge of the Ki. The testing is done by sending the RAND as challenge to the MS and checking if the response from the MS matches the expected response in the authentication vector. If the responses match, which means the MS knows the permanent key Ki, then the MS is authenticated. In order to refer this type of authenticity, we use the term challenge-response authentication. The left part of Figure 6.1 shows the block GSM III, which contains the challenge response procedure, including the events used in the correspondence assertions. The correspondence assertion that speciﬁes authentication of the MS to the SN in GSM is 60

MS SN MS SN

5. RAND 5. RAND, AUTN

res__ms = a3(Ki, rand_ms), IIIUMTS Compute res_ms, ck_ms, ik_ms, xmac_ms

GSM IIIGSM kc_ms = a8(Ki, rand_ms) Verify mac_ms=xmac_ms

event begSN(imsi_ms,kc_ms) event begSN(imsi_ms, ck_ms, ik_ms)

6. RES 6. RES

Verify res_sn = xres_sn Verify res_sn = xres_sn

event endSN(imsi_hn_sn, kc_sn) event endSN(imsi_hn_sn, ck_sn, ik_sn)

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 correspondence assertions. The correspondence assertion says that if the SN reaches the point in its protocol marked by event endSN, for a given IMSI and session keys, then there is a legitimate MS that reached the point marked begSN, with the same IMSI and session 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, if SN reaches the point marked endSN for a particular IMSI , with associated long-term Ki and with nonce RAND provided by HN, then there is an MS that reaches the point 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 does in 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 authentication token helps the MS to reject any older or pre-used authentication challenge. Despite the authentication token being included in the challenge, the authentication of the MS to the SN in UMTS is the same type as the authentication of the MS to the SN in GSM, which is challenge-response authentication in our terminology. The right part of Figure 6.1 shows the block UMTS III, which contains the challenge response procedure, including the events used in the correspondence assertions. The correspondence assertion that speciﬁes authentication of the MS to the SN 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 is that LTE provides the same type of authentication as in GSM and UMTS. 61

MS MME

5. RAND, AUTN, SNid

XMAC = f1(Ki, RAND)

LTE MAC = XMAC, RES = f2(Ki, RAND) MS SN CK = f3(Ki, RAND), IK = f4(Ki, RAND)

III KASME = KDF(CK, IK, SNid,)

5. RAND, AUTN 6. RES

UMTS IIIUMTS Compute res_ms, ck_ms, ik_ms, xmac_ms Verify RES = XRES Verify mac_ms=xmac_ms

event begSN(imsi_ms, ck_ms, ik_ms) 7. eableEnc, CAP, NAS-MAC

6. RES KNASenc = KDF (KASME), KNASint = KDF(KASME) Verify res_sn = xres_sn XNAS-MAC = EIA((CAP, enableEnc), KNASint) Verify XNAS-MAC = NAS-MAC

event endSN(imsi_hn_sn, ck_sn, ik_sn) IVLTE event begSN(imsi_ms, snid_ms, kasme_ms)

8. NAS-SMComplete msg,

NAS-SMComplete-MAC

Verify NAS-SMComplete-MAC

event endSN(imsi_sn, snid_sn, kasme_sn)

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 from the HN and checking whether the response received from the MS matches the expected response. If the responses match, the MME concludes the MS has the permanent key Ki. Similar to UMTS, the authentication token included in the challenge does not make difference of the type of the authenticity. Therefore the authentication of the MS 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 events used in the correspondence assertions. The correspondence assertion that specifies authentication 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 the point endSN it knows there is an MS with the same IMSI which reaches begSN using the 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, the SN 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 the key is used. Agreement on KASME implies agreement on Ki and the RAND from which 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 the authentication 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 to the MS.

6.2.1 GSM vs. UMTS As described in Chapter 3, GSM does not provide authentication of the SN to the MS. In UMTS, the MS does authenticate the SN, by verifying the integrity of the SMC message (in UMTS IV) to ensure the SN knows the correct integrity key which is obtained from the HN. The knowledge checked by the MS is based on the derived integrity key. This authentication is not challenge response, rather is based on checking knowledge of the integrity key. In order to refer this type of authentication of the SN 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 authenticated in diﬀerent way. In UMTS, the MAC of the SMC message is generated by the BS. By successfully verifying the MAC, the MS in fact concludes that the BS has the knowledge of the correct integrity key. Therefore this is use-based proved knowledge authentication of the BS to the MS. The authentication of the MSC to the MS is based on the following reasoning: the MS trusts that the HN and the MSC follow the protocol. The BS proves to the MS that it knows the integrity key; the only way the 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 term indirect use-based proved knowledge authentication. The left part of Figure 6.3 shows the block UMTS IV including the events used to 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 have reached 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 nonce RAND, agreement on the keys implies agreement on Ki and RAND. (Recall from chapter 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 the correct capabilities, which prevents the false base station attack [53]. This is not relevant to the authentication of the BS to the MS, because the authentication is established 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 proved knowledge authentication and the authentication of the MSC to the MS in UMTS is the indirect use-based proved knowledge authentication. 63

MS BS MME event begMS(imsi_sn, snid_sn, kasme_sn, cap_sn) 7. eableEnc, CAP, NAS-MAC

KNASenc = KDF (KASME)

LTE IV LTE KNASint = KDF(KASME) XNAS-MAC = EIA(

(CAP, enableEnc), KNASint) Verify XNAS-MAC = NAS-MAC event endMS(imsi_ms, snid_ms, kasme_ms, cap_ms) MS SN 8. NAS SMComplete msg NAS-SMComplete-MAC event begMS(imsi_hn_sn, ck_sn,ik_sn, cap_sn) Verify NAS-SMComplete-MAC 7. eableEnc, CAP, FRESH, MAC-I

KeNB = KDF(KASME)

UMTS IV

XNAS-MAC = EIA((CAP, enableEnc), CK) 9. CAP,KeNB Verify XNAS-MAC = NAS-MAC KeNB = KDF (KASME), KRRCenc = KDF (KeNB)

LTE V LTE KRRCint = KDF(KeNB), KUPenc = KDF (KeNB) event endMS(imsi_ms, ck_ms, ik_ms, cap_ms) Decide enableENC,

AS-MAC = EIA(enableEnc,KRRCint) 8. SMComplete, integrity protected event begMS_ENB(imsi_sn, kenb_sn, cap_sn) 10. enableEnc, AS-MAC

KeNB = KDF (KASME) KRRCenc = KDF (KeNB) KRRCint = KDF(KeNB) KUPenc = KDF (KeNB) XAS-MAC = EIA( enableEnc, KRRCint) Verify XAS-MAC = AS-MAC event endMS_ENB(imsi_ms, kenb_ms, cap_ms) 11. AS SMComplete msg AS-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 traﬃc and derives diﬀerent keys for the corresponding stratum. The NAS and AS security contexts are established by the NAS SMC procedure and the AS SMC procedure respectively. These two procedures enable the authentication of the MME and the BS to the MS respectively. The MS authenticates the MME by verifying the integrity of the NAS MSC message to check if the MME has the knowledge of the NAS integrity key, which is derived from the KASME . The KASME is derived by the HN from the CK , the IK , and the identity of the SN SNid. Also the CK and IK are derived from the Ki and the RAND. So the identity of the SN is bound to the KASME and keys derived from KASME . Compared with UMTS, the MME directly proves that it has the knowledge of the integrity key and the MS obtains additional assurance of the identity of the SN. The authentication of the MME to the MS in LTE is called use-based proved knowledge with SNid authentication. The MS authenticates the BS also by verifying the integrity of the AS SMC message, which is generated by the BS, to check whether the BS has the knowledge of the correct AS integrity key. The AS integrity key is derived from the KeNB ; the KeNB is derived from the KASME . So the identity of the SN is also bound to the AS integrity 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 MME with the same SNid reaches its point begMS with the same master key and the same capabilities sent by the MS. Authentication of the BS to the MS is speciﬁed using the events in LTE V in the 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 the Ki, the RAND, and the SNid, agreement on KeNB implies agreement on the Ki, the RAND, and the SNid. The correspondence assertion says that if an MS with given IMSI reaches its endMS ENB then it knows there is a BS, attached to an MME with identity SNid, which reaches its begMS ENB with the same intermediate key and the same capabilities of the MS.

6.3 Summary

We identify four main types of authentication that can be described in terms of the major components, MS, BS, MSC/MME, and HN. challenge-response Authentication is based on a random challenge and the response is used to prove that the responding party has the correct key and used it to respond to the challenge. For example, the authentication of the MS to the SN in all the pure AKAs is challenge-response authentication. use-based proved knowledge Authentication is based on that one party possesses the correct integrity key and uses it to generate the MAC. For example, the authentication of the BS to the MS in UMTS is use-based proved knowledge authentication. indirect use-based proved knowledge Authentication is indirect and based on the use-based proved knowledge. The reasoning is that two participants connected by a secure channel trust each other to follow the protocol, and the only way 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 proved knowledge authentication. use-based proved knowledge with SNid This is like use-based proved knowledge 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 SN to MS Auth. of MS to SN Auth. of MSC/MME to MS Auth. of BS to MS GSM challenge-response UMTS challenge-response indirect use-based proved knowledge use-based proved knowledge LTE 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 authentication properties Implied parameters in addition to RAND and Ki are put in parentheses

Auth. of SN to MS Auth. of MS to SN Auth. of MSC/MME to MS Auth. of BS to MS GSM IMSI , Kc UMTS IMSI , CK , IK IMSI , CK , IK , CAP LTE 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 also from the SNid. For example, the authentication of the MME to the MS in LTE is use-based proved knowledge with SNid authentication.

Table 6.1 summarizes the types of authenticity achieved by the pure AKAs. We have compared the speciﬁcations of the authentication properties by iden- tifying the corresponding blocks which contains the events and discussing the parameters used in the correspondence assertions. Table 6.2 shows the parameters used in the correspondence assertions. The “parameters” in parentheses are implied by key derivations rather than being explicit in events. Since all the session keys are derived from the RAND and the Ki, those are also implied in every case, so we only list the additional implied parameters. 66

Chapter 7 Establishing 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 summarize the system components in Section 7.1. Since each of the five main system components can be 2G, 3G, or 4G, there are 35 = 243 cases in which deployed components from different 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 other documentations [52].

7.1 System Components

In this section, we summarize the main components which are introduced previous chapters. 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 is the user device that contains the radio functionality and the encryption/integrity mechanisms used to protect the traﬃc between the MS and the network. A 4G ME also 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 permanent secret key Ki, as well as the mechanisms used for GSM AKA and GSM session key derivation. The UMTS identity module (USIM) includes the IMSI, Ki, and the UMTS AKA and session key derivation functionality. It furthermore may contain the SIM functionality, i.e., the GSM AKA and key derivation functionality. In contrast to a 3G USIM, an LTE USIM (also referred to as enhanced USIM) provides for additional functionality 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 radio resources and establishes the connection to the MS. In GSM, the BS includes the BTS which connects to the BSC. In GSM, encryption terminates at the BTS or at the SGSN in GPRS. In UMTS, the BS includes the NodeB which connects to the RNC. 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 MS and 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 respective protection mechanisms. The HN includes the HLR and the AuC in GSM and UMTS, respectively the Home Subscriber Server (HSS) in LTE. The HN stores all subscriber data including 67

Table 7.1: Legend used in Table 7.2 Rows Cases Normal font with no color Allowed Green color and bold font Uncertain Grey color and italic font Disallowed Blue color and in bold italic font Involving only 2G/3G components

the IMSI and permanent shared secret key Ki. It furthermore, holds its (own) algorithms for deriving session keys as well as generating authentication vectors. A 4G HN also includes the functionality for deriving an LTE master secret key KASME . Each one of the ﬁve main system components (the identity module, the ME, the BS, the MSC/MME, and the HN) can be 2G, 3G, or 4G—thus resulting in 35 = 243 possible combinations. Each combination corresponds to an interoperation case. Table 7.2 shows the details for the cases. The rows marked with blue color and in bold italic font are the cases involving only 2G/3G components. These cases have been analyzed in [1, 87] and will be further detailed in Chapter 8. We classify the cases involving 4G components in the following sections. Section 7.2 gives the allowed 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.