Authentication 2G 3G 4G

Embed Size (px)

Citation preview

  • 8/19/2019 Authentication 2G 3G 4G

    1/39

    Analysis of authentication and key establishment ininter-generational mobile telephony (with appendix July 31, 2013)

    Chunyu Tang, David A. Naumann, and Susanne WetzelStevens Institute of Technology

    Abstract —Second (GSM), third (UMTS), and fourth-generation (LTE) mobile telephony protocols are all in active use,giving rise to a number of interoperation situations. Although thestandards address roaming by specifying switching and mappingof established security context, there is not a comprehensivespecication of which are the possible interoperation cases.Nor is there comprehensive specication of the procedures toestablish security context (authentication and short-term keys) inthe various interoperation scenarios. This paper systematicallyenumerates the cases, classifying them as allowed, disallowed,or uncertain with rationale based on detailed analysis of thespecications. We identify the authentication and key agreement

    procedure for each of the possible cases. We formally model thesescenarios and analyze their security, in the symbolic model, usingthe tool ProVerif. We nd two scenarios that inherit a known falsebase station attack. We nd an attack on the CMC message of another scenario.

    I. INTRODUCTION

    Mobile telephony has become an integral part of our dailyactivities, in part due to the tremendous success and marketpenetration of smartphones and tablets. In many locationsaround the world, mobile communication is already facilitatedthrough the fourth generation (4G) technology called LongTerm Evolution (LTE)—which evolved from the third genera-tion (3G) technology, Universal Mobile Telecommunications

    System (UMTS). Along with the opportunities created bytechnology evolution there are challenges. One challenge isthe interoperation of different generations of technologies, i.e.,communication involving mixed network components. Pastexperience has shown that such interoperation may introduceunexpected security vulnerabilities [ 1], [2].

    The specications promulgated by the 3GPP organizationfor UMTS [ 3] and LTE [4] do address interoperation betweenthe different generations of technologies. The specicationfor UMTS systematically studies all possible combinationsof interoperation between UMTS and second generation (2G)GSM. The LTE specication details the mechanisms for secu-rity context switching and mapping to facilitate interoperationbetween LTE, UMTS, and GSM. However, this applies tomaintaining context during handover and idle mode mobility.To the best of our knowledge, the specication for LTE doesnot explicitly address establishing of an initial security contextfor interoperation. In particular, to date there is no comprehen-sive enumeration of all interoperation cases and their respectiveprocedures for authentication and key agreement (AKA). Inthis paper we close this gap.

    The rst contribution of this paper is to systematicallyenumerate of all possible interoperation cases between LTE,UMTS, and GSM. We classify these cases as allowed, dis-allowed, or uncertain, with explicit rationale making detailed

    reference to the specications. Of the 243 cases identied,19 cases involve GSM and UMTS technologies only, and assuch are fully treated by the UMTS specication [ 3]. Forcases involving LTE components, 138 cases are clearly ruledout somewhere in the specication and 38 cases are clearlyallowed. For the remaining 48 cases the specications anddocumentation based on the specications do not provide aclear indication whether these cases are allowed.

    As a second contribution of this paper, we provide detailson what we call the AKA scenarios ,1 i.e., the specic protocolsteps for authentication and key agreement, in each allowed oruncertain case. For each uncertain case we identify conditionsunder which the case could occur. For all of the 19+38+48cases we identify the corresponding AKA scenario. It turnsout that there are only 10 distinct AKA scenarios, includingthe pure GSM, pure UMTS, and pure LTE scenarios whichapply in some interoperation cases. Although the GSM/UMTSscenarios are described in the specications, that is not thecase for 86 roaming cases involving LTE. For three of thosescenarios we identify two variations which are both consistentwith the specications and which have different authenticityproperties.

    As a third contribution, we provide formal models for all10 of the AKA scenarios, including variations, in the symbolic

    (Dolev-Yao) model of cryptography and using the ProVerif tool[5]. We provide a security analysis based on these models.The models are composed in a modular fashion from thebasic protocol models for GSM, UMTS, and LTE. This willfacilitate adding or modifying scenarios, in case of changes tothe specications or the conditions for the uncertain cases tooccur.

    Our security analysis addresses authentication propertiesand secrecy. We show that two of the LTE interoperationscenarios inherit an attack, known from GSM and the interop-eration between UMTS and GSM [ 6], in which a false basestation can eavesdrop and modify data trafc. We show howthe attack can be prevented in one scenario. We also show that

    one scenario is prone to an attack against the Cipher ModeCommand (CMC) message.

    Outline: Sect. II surveys related work and Sect. III isan overview of the GSM, UMTS, and LTE AKA protocols.Sect. IV presents the rst of our main contributions, thesystematic enumeration of possible cases and classicationof what is (dis)allowed or uncertain according to the 3GPP.Sect. V presents our second contribution, the AKA scenariosfor each allowed or uncertain case, justied with reference to

    1 In some standards, AKA has more specic meaning and varying termi-nology is used, e.g., depending on whether authentication is mutual.

  • 8/19/2019 Authentication 2G 3G 4G

    2/39

    the specications. Sect. VI describes our ProVerif models forGSM, UMTS, and LTE, and the specications of desired se-curity properties. Sect. VII presents our third contribution, theProVerif models for AKA scenarios involving interoperationbetween technologies, and analysis results for those models.

    For reasons of space, we cannot present the completeclassication of cases, scenarios, and analysis results; insteadwe present excerpts and highlights. A long version onlineincludes full details [7].

    II. R ELATED WORK

    Several attacks have been found against the GSM encryp-tion algorithms [ 8], [9], [10], [11 ], [12]. Ahmadian et al. [13]show attacks which exploit weakness of one GSM cipherto eavesdrop or impersonate a UMTS subscriber in a mixednetwork. In this paper we focus on protocol aws rather thancryptographic weaknesses.

    Fox [ 14] nds the false base station attack on the GSMAKA due to the lack of authentication of the network. Meyerand Wetzel [ 1], [2], [15] show that a man-in-the-middle attack

    can be performed on one of the cases of interoperation betweenGSM and UMTS. In prior work [ 16] , we use the ProVerif (PV)tool to analyze GSM, UMTS, and roaming cases between GSMand UMTS. The false base station attack [ 14] and the man-in-the-middle attack [ 1] were conrmed by the PV models.

    PV is an automatic protocol verier that can verify authen-tication, secrecy, and other properties, in the symbolic (Dolev-Yao) model, considering an unbounded number of sessionsand unbounded message space. Quite a few protocols havebeen analyzed using PV. For example, Chang and Shmatikov[17] use PV to analyze the Bluetooth device pairing protocols;they rediscover an ofine guessing attack [ 18] as well as anew attack. Blanchet and Chaudhuri [ 19] nd an integrityattack against a le sharing protocol. Chen and Ryan analyzeTPM authorization [ 20]. Kremer and Ryan use PV to verifyan electronic voting protocol [ 21]. Arapinis et al. [22 ] nd twoattacks against anonymity in UMTS, using PV.

    Han and Choi [ 23] demonstrate a threat against the LTEhandover key management, involving a compromised basestation. This is concerned with maintaining security context,whereas our work addresses establishing such context. Tsayand Mjølsnes [ 24] nd an attack on the UMTS and LTE AKAprotocols using CryptoVerif, an automated protocol analyzerbased on a computational model. In fact the attack lives atthe symbolic level. It depends on insecurity of the connectionbetween the serving network and the home network. In ourwork we assume the connection between serving network and

    home network is secure. (Although the standard species theprotocols, their implementations are operator-specic.)

    Lee et al. [ 25] analyze the anonymity property of theUMTS and LTE AKA and connection establishment protocolsusing formal security (computational) models. The assumptionin this work is that the attacker is not capable of imperson-ating any network devices and the underlying cryptographicsystem is perfect. They manually prove the protocols meet theanonymity requirement, under these assumptions.

    Mobarhan et al. [ 26] evaluate the publically known attackson GSM and UMTS (and the related technology GPRS),

    categorizing them in terms of secrecy, integrity, or authenticityproperties. Possible security improvements are also discussed.

    III. O VERVIEW OF GSM, UMTS, AND LTE SECURITYMECHANISMS

    In GSM, UMTS, and LTE, the network architecture in-cludes three main elements: the Mobile Station (MS), theServing Network (SN), and the Home Network (HN).

    The MS is the combination of the Mobile Equipment (ME)and an identity module. The ME is the user device thatcontains the radio functionality and the encryption/integritymechanisms used to protect the trafc between the MS and thenetwork. A 4G ME also includes the functionality to derive anLTE master secret key K ASME . In GSM, the identity module of the Subscriber Identity Module (SIM) contains the unique In-ternational Mobile Subscriber Identity (IMSI), the subscriber’spermanent secret key Ki, as well as the mechanisms usedfor GSM AKA and GSM session key derivation. The UMTSidentity module (USIM) includes the IMSI, K i, and the UMTSAKA and session key derivation functionality. It furthermoremay contain the SIM functionality, i.e., the GSM AKA andkey derivation functionality. In contrast to a 3G USIM, anLTE USIM (also refered to as enhanced USIM) provides foradditional functionality including enhanced capability for thestoring of a security context.

    The SN typically consists of the Base Station (BS) and ei-ther the Visitor Location Register / Serving GPRS Support Node(VLR/SGSN) in GSM and UMTS, or the Mobile Management Entity (MME) in LTE. The BS is the network access pointwhich manages the radio resources and establishes the connec-tion to the MS. In GSM, the BS includes the Base Transceiver Station (BTS) which connects to the Base Station Controller (BSC). In GSM, encryption terminates at the BTS or at theSGSN in GPRS. In UMTS, the BS includes the NodeB which

    connects to the Radio Network Controller (RNC). Encryptionand integrity protection in UMTS terminates in the RNC. InLTE, BS is the evolved NodeB (eNodeB). LTE distinguishesthe protection of the connection between the MS and theeNodeB—the so-called Access Stratum (AS) and the connec-tion between the MS and MME—the so-called Non-AccessStratum (NAS). In LTE, the MME is the end-point for theNAS and the respective protection mechanisms.

    The HN includes the Home Location Register (HLR) andthe Authentication Center (AuC) in GSM and UMTS, respec-tively the Home Subscriber Server (HSS) in LTE. The HNstores all subscriber data including the IMSI and permanentshared secret key Ki. It furthermore, holds its (own) algorithmsfor deriving session keys as well as generating authenticationvectors. A 4G HN also includes the functionality for derivingan LTE master secret key K ASME .

    Overview of GSM Security Mechanisms. Fig. 1 showsthe GSM AKA procedure. The goal of the GSM AKA is toauthenticate the MS and to establish an encryption key thatcan then be used to protect the user data exchange betweenthe MS and BS. The GSM AKA procedure can be triggeredby the initial network attach request [27], the Routing AreaUpdate (RAU) request [ 28] , or the service request [29]. Theservice request happens after a dedicated channel has beenestablished between the MS and the SN [29], which means

    2

  • 8/19/2019 Authentication 2G 3G 4G

    3/39

    Fig. 1. GSM message sequence diagram [ 29] , [15]

    Fig. 2. UMTS message sequence diagram [ 3], [15]

    that the attach request must have been executed previously.The identity and CAPabilities (CAP) in the attach request orthe RAU request are used in the AKA procedure. Therefore,in GSM I, the MS sends the identity and the CAP to the SN.In GSM block II, the SN obtains authentication vectors fromthe HN. In GSM III a typical challenge-response procedure iscarried out to authenticate the MS to SN. Then, in GSM IV,the VLR/SGSN provides the BS with the session key Kc . BSselects the encryption algorithm based on MS’s capabilitiesand informs MS.

    GSM is prone to a false base station attack [14] as theGSM AKA only authenticates the MS to the SN. Since a falseBS can intercept and modify the sending of MS’s capabilities,a false BS may force the use of no encryption thus enabling thefalse BS to control all trafc between the MS and the network.

    Overview of UMTS Security Mechanisms. Similar toGSM, the UMTS AKA procedure can be triggered by theattach request or the RAU request. In UMTS I, the same

    Fig. 3. LTE message sequence diagram [4 ]

    messages are transmitted as in GSM I. In comparison toGSM, UMTS includes mechanisms for integrity protection.Specically, as part of block UMTS II (see Fig. 2), the HNderives session keys for both encryption and integrity protec-tion based on MS’s long-term secret key Ki. Like in GSM, MSauthenticates to the VLR/SGSN through a challenge-responseprotocol using the authentication vector that the VLR/SGSNobtained from HN. The authentication of the network to MSis achieved indirectly, as the BS integrity protects the sendingof CAP which it can only do if it has received key IK fromHN via VLR/SGSN. This prevents a false base station attack.

    Overview of LTE Security Mechanisms. The LTE AKA

    (Fig. 3) is built on the UMTS AKA. In contrast to UMTSsecurity, LTE introduces an enhanced key derivation hierarchythat allows the distinguishing of protection mechanisms onNAS and AS. Furthermore, inclusion of the id of SN as part of the key derivation enables the MS to indirectly authenticate theMME (through the successful use of derived keys). In addition,LTE denes a comprehensive security context framework,including native vs. mapped security contexts, full vs. partialsecurity contexts, and current vs. non-current contexts [ 4].A security context typically consists of a set of securityparameters including cryptography keys and identiers forrespective cryptographic mechanisms.

    3

  • 8/19/2019 Authentication 2G 3G 4G

    4/39

    The LTE AKA can be triggered by the initial network attach request, the Tracking Area Update (TAU) request orthe service request [28]. When a NAS signalling connectionexists, the network can initiate an authentication procedure atany time [ 28] . Before the service request or the NAS signallingconnection establishing, the attach request must have alreadybeen executed [28 ]. Therefore, the rst block of the LTE AKAcan contain an attach request or a TAU request. If the AKA

    starts with an attach request, the rst block (LTE I) containsthe transmission of the identity and the security capabilities of the MS. If the AKA starts with a TAU request, in the rst block (LTE I’), an additional nonce NONCE MS is sent to the MME.The nonce in the TAU request is only used when mappingan UMTS to an EPS security context. However, since the MSdoes not know when the mapping will happen, the nonce isalways included in the TAU request message 2 [30] . In LTE, themaster key K ASME is derived and provided to MME togetherwith the respective authentication vector. Unlike in GSM andUMTS, the id of the SN is an input to the key derivation,i.e., the derived key is bound to a specic MME. In block LTE IV, MME derives the keys which are used to protect NAS,while in LTE V the BS derives the keys to protect AS as well

    as user data. The MS does the corresponding key derivationsin LTE IV and LTE V. Furthermore, the proper use of keysderived from K ASME indirectly authenticates the MME to MS.Given that LTE distinguishes between the protection of NASand AS, MME selects the respective algorithms to protect NAS(based on MS’s capabilities) and announces the choice to MSin LTE IV as part of the NAS Security Mode Command (SMC).Similarly, BS announces its choice of algorithms in LTE V aspart of the AS SMC.

    IV. E STABLISHING A NATIVE SECURITY CONTEXT ININTEROPERATION

    As mentioned previously, LTE introduces a comprehensive

    framework for handling security contexts [4]. In particular,this includes the mapping of security contexts in the case of interoperation of LTE with GSM or UMTS. The specicationdenes the use of existing native or mapped security contextsand recommends the performing of an AKA procedure once amapped security context is used. However, to the best of ourknowledge, the specication to date does not include details onwhat this AKA is to entail in case of interoperation of LTE,UMTS, and GSM, i.e., if the network components are fromdifferent generations of technologies.

    In the following, we systematically enumerate all possibleinteroperation cases and classify them as allowed, disallowed,or uncertain based on various information in the 3GPP speci-

    cations for GSM, UMTS, and LTE. In Sect. V we then focus onthe allowed and uncertain cases only determining the specicAKA scenarios for each one of these cases.

    Enumeration of Interoperation Cases. As discussed inSect. III, there are ve main system components: the identitymodule, the ME, the BS, the VLR/SGSN/MME and the HN.Each one of those components can be 2G, 3G, or 4G—thusresulting in 3 5 = 243 possible combinations. Table I showsthe details for ve cases. In order to improve readability of

    2 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 (S8).

    TABLE I. E XCERPT OF CLASSIFYING THE 24 3 INTEROPERATIONCASES (THE FULL TABLE IS IN [7])

    ID Components Condition

    to supportOccurrence

    Reasons forDisal-

    lowanceIdentityModule ME BS

    VLR/SGSN /MME HN

    1

    4G 4G

    4G 4G 4G2 3G 4G 4G A13 2G 4G 4G A14 4G 3G 4G R5... ... ... ... ... ...

    122 3G 3G 3G 3G 3G... ... ... ... ... ...

    the table, we have adopted a color/font scheme: Rows innormal font with no color indicate cases which are explicitlyallowed based on the 3GPP specications (e.g., the case withID 1). Green color and bold font indicates uncertain cases(e.g., cases 2 and 3). Grey color and italic font indicates caseswhich are ruled out by the specications (e.g., case 4). Thecases involving only 2G/3G components are marked with bluecolor and in bold italic font (e.g., case 122). There are 19 suchcases which are not further detailed in this paper as they havebeen analyzed previously [ 6], [16] . For the disallowed anduncertain cases the table includes the details for the reasoningto determine the respective classication.

    Allowed Interoperation Cases. For cases involving a mixof 4G, 3G, and 2G network components, we have identied 38cases which are explicitly allowed by the 3GPP specications.

    For the identity module, the SIM supports 2G AKA only[6]. A USIM supports both 2G and 3G AKA [ 6]. Similarly, a4G USIM supports 2G, 3G, and 4G AKA [ 30]. Since a largenumber of USIMs is in current use, a 4G ME with the USIM isallowed to access the 4G network. Since the 4G ME is capableof deriving LTE keys and storing security contexts [31], thecombination of a 4G ME with a USIM supports 4G AKA.

    For the ME, it is possible to use a SIM or a USIM witha 2G ME [6]. Since the 4G USIM is an enhanced version of the USIM, this implies that it is possible to also use a 4GUSIM with a 2G ME. Similarly, since a SIM or USIM canbe used with a 3G ME, [ 6], it is also possible to use a 4GUSIM with a 3G ME. A 4G ME can be used with a SIM[30] or USIM [ 4] and certainly with a 4G USIM. A 2G MEonly supports GERAN [6]. A 3G ME supports GERAN andUTRAN [ 6], and a 4G ME supports GERAN, UTRAN, andE-UTRAN [ 30].

    For the BS, a 2G BS is only capable of handling a GSMsession key K c [6] , which means a 2G BS only supports a 2Gciphering mode setting [ 29] . Similarly, a 3G BS requires theUMTS cipher key CK and the UMTS integrity key IK [6]—

    supporting only the 3G security mode set-up and operation [ 3].A 4G BS requires K eNB and only supports the 4G AS securitymode command procedure and operation [ 4].

    For the VLR/SGSN/MME, a 2G VLR/SGSN can onlycontrol a 2G BS and only supports 2G AKA [6] . A 3GVLR/SGSN can control both a 2G BS and a 3G BS and cansupport both 2G and 3G AKA [6]. An MME can control a 4GBS and can support the 4G AKA [4].

    For the HN, a 2G HN can maintain 2G and 3G subscrip-tions [ 6]. A 3G HN can maintain 2G and 3G subscriptions [ 6].A 4G HN can maintain 3G and 4G subscriptions [ 4].

    4

  • 8/19/2019 Authentication 2G 3G 4G

    5/39

  • 8/19/2019 Authentication 2G 3G 4G

    6/39

    TABLE II. R EASONS USED FOR DETERMINING AK A SCENARIOS

    Type of AV

    A Upon request by an MME with network type equals E-UTRAN, the 4G HN generates and delivers the 4G AVs (separation bit = 1) [4].B Upon request by an MME with network type equals UTRAN or GERAN, the 4G HN generates and delivers the 4G AVs, plus CK and IK (separation

    bit = 0) [4] .C Upon request by a 3G VLR/SGSN, the 3G HN generates and sends out 3G AVs [3] .D Upon request by a 2G VLR/SGSN with a 3G IMSI, the 3G HN generates 2G AVs from 3G AVs [6] .E 2G HN only supports to generate 2G AVs [6] .F Upon request by a VLR/SGSN/MME with a 2G IMSI, the 3G HN always generates and delivers the 2G AVs [ 6].O Upon request by a 3G VLR/SGSN, the 4G HN generates 3G AVs [4] [or derived from D].P Upon request by a 2G VLR/SGSN with 3G/4G IMSI, the 4G HN generates 2G AVs from UMTS AVs [Derived from D].Q Upon request by an MME, the 3G HN generates 3G AVs [Derived from E and [ 6]].

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

    Type of BSG 4G BS only supports 4G SMC [4] .H 3G BS only supports 3G SMC [6] .I 2G BS only supports 2G SMC [6] .

    Type of MEJ The 4G ME supports to derive K ASME and store the security contexts. [31]K XG ME supports XG SMC [4] , [3]L 3G ME supports 2G SMC [6] .T 4G ME supports 2G/3G SMC [Derived from L]

    ConversionM The 3G BS requires CK and IK, the VLR/SGSN/MME generates them from Kc by applying conversion function c3 [ 6].N 2G BS is not capable of handling of cipher and integrity keys. The VLR/SGSN/MME converts the CK and IK into Kc [6] .U Because the 4G BS requires K eNB , which is derived from the K ASME , the VLR/SGSN/MME generates K ASME from the CK, IK and sends it to the

    BS [Derived from M or [4] ].

    First Block V Triggered by attach request or RAU request, the rst block is GSM I or UMTS I [27] , [28]W Triggered by LTE attach request or TAU request in which the nonce is never used, the rst block is LTE I [4 ].X Triggered by TAU request and the nonce is used in latter blocks, the rst block is LTE I’ [ 28] , [30] .

    Fig. 4. AKA scenario S7; in alternate version, LTE IV added before LTE V

    S7. This scenario is characterized by a 4G ME, a 4G SN(i.e., 4G BS and 4G MME) and a USIM or 4G USIM identitymodule subscribed to a 3G HN. Two of the allowable/uncertaincases fall into this category. The AKA is triggered by the attachrequest. The identity request and response procedure is thesame as in LTE I (Fig. 3). The 3G HN can generate 2G or 3Gauthentication vectors, but cannot generate 4G authenticationvectors. Upon request by the MME, the 3G HN thereforegenerates and delivers a 3G authentication vector which thusis identical to UMTS II. Upon receiving the authenticationvector, the MME communicates with the MS as in UMTS III.The 4G BS requires 4G AS keys, which are derived from theintermediate key K eNB . Because the intermediate key K eNB isderived from the local master key K ASME , the MME applies akey derivation function to generate the local master key K ASME from the UMTS encryption key CK and integrity key IK .Including LTE IV is optional in this scenario. Later, we analyzeboth variations and show that the AKA without LTE IV isprone to an attack in which a false base station can botheavesdrop and modify the messages between the MS and theSN. Executing both LTE IV and V prevents this attack. LTE V(Fig. 3) is executed which includes the deriving of K eNB . Fig. 4shows this AKA scenario without LTE IV.

    S8. This scenario is characterized by the same cases as inS7. The difference to S7 is that this scenario is triggered by theTAU request and the NONCE MS in the TAU request is usedin LTE IV. The retrieving and generating of the authenticationvector and the challenge-response procedure are the same as inS7. In LTE IV, the MME generates a nonce NONCE MME and

    uses it with the CK , IK , and NONCE MS as input parametersto derive the K ASME . The MME sends the integrity protectedSMC message containing the nonce NONCE MS received fromthe MS and the nonce NONCE MME . Upon receiving the SMCmessage, the MS checks whether the NONCE MS and thecapabilities match what it originally sent in LTE I’. If thecheck successes, the MS uses the same key derivation functionas in the MME to derive the K ASME and sends out the SMCcomplete message. Subsequently, LTE V is executed.

    S9. This scenario is characterized by a mixed SN includinga 2G BS and a 4G MME as well as an MS that is subscribedto a 4G HN where either the identity module is a 4G USIMor it is a 4G ME, i.e., the MS supports 4G AKA. Four of

    the allowable/uncertain cases fall into this category. Becausethe 2G BS covers routing areas, the initial message can bethe attach request or the RAU request. So the transmittingof the identity and the capabilities is as in GSM I (Fig. 1).When the MME requests the authentication vector from theHN by sending the IMSI and the network type, because thenetwork type is GERAN (because of the 2G BS), the 4G HNgenerates and delivers the 4G authentication vector with theUMTS cipher key CK and integrity key I K . Because the NASsignaling is transparent to the BS, the LTE challenge-responseprocedure LTE III (Fig. 3) is executed between the MS andthe MME. In this interoperation scenario, we consider the twovariations with and without LTE IV (Fig. 3). The rst variationsticks to the LTE AKA as long as possible (i.e., until executing

    LTE IV before setting up the cipher between the MS and theBS). The other one goes to set the cipher between MS andthe BS as soon as nishing the challenge-response procedure(without executing LTE IV). Later we show that the AKAwithout LTE IV is prone to a false base station attack andthe AKA with LTE IV is prone to an attack against the CMCmessage between the 2G BS and the MS. Because the 2GBS requires the GSM session key Kc, the MME derives theencryption key K c from the UMTS cipher key CK and integritykey IK . Since only the 2G cipher mode setting is supportedby the 2G BS, the 2G cipher mode setting procedure GSM IV(Fig. 1) is executed between the 2G BS and the MS—which

    6

  • 8/19/2019 Authentication 2G 3G 4G

    7/39

    also includes the MME sending the GSM session key to the2G BS.

    S10. This scenario is characterized by a 4G HN, a mixedSN consisting of a 3G BS and a 4G MME, as well as anMS that is subscribed to a 4G HN where either the identitymodule is a 4G USIM or it is a 4G ME with a 3G USIM, i.e.,the MS supports 4G AKA. Three of the allowable/uncertaincases fall into this category. The 3G BS covers routing areas,so the initial message can be the attach request or a RAUrequest. Thus, the transmitting of identity and capabilities isas in UMTS I (Fig. 2). In order to obtain an authenticationvector, the MME sends the authentication data request withthe IMSI and the network type to the 4G HN. Because theaccess network is UTRAN, the 4G HN generates and deliversthe 4G authentication vector as well as the UMTS encryptionkey CK and integrity key IK . Subsequently, the LTE challenge-response procedure LTE III (Fig. 3) is executed between theMS and the MME. As in scenarios S7 and S9, the LTE IV isoptional. Later we show that the authentication properties holdin both variations. The 3G BS obtains the UMTS encryptionkey CK , the UMTS integrity key IK , as well as the capabilitiesas part of UMTS IV (Fig. 2)—which also includes the UMTSsecurity mode set-up procedure between the 3G BS and theMS.

    VI. M ODELING AND ANALYZING THE PURE PROTOCOLSIN P RO V ERIF

    The ProVerif (PV) tool has been described well elsewhere,and we use standard idioms in our modeling. We give herea brief overview of our design decisions followed by a fewdetails concerning the LTE model. Details of the GSM andUMTS models can be found in [ 16]. The roaming models arediscussed in Sect. VII, together with our analysis results. Thecomplete models are available with the long version of the

    paper [7].In PV, protocols are dened using process algebra. Prop-

    erties are specied as correspondence assertions [32] thatrefer to events . Events are instrumentation that mark impor-tant points reached by the principals and have no effect onprotocol behavior. For example, the correspondence assertionevent (e1(M)) event (e2(M)) says that if event e1 occurs, withargument value M, then event e2 must have happened previ-ously with the same argument M. In checking an assertion, PVmay terminate having successfully proved the property, withrespect to unbounded message space and number of sessions,or having found a possible or denite attack.

    Here are some design decisions that apply to all of our

    models. Each message has a header to indicate the type of the message content. The secure communications between SNand HN are modeled as private channels. Registration of theMS, i.e., pre-sharing of each long-term credential pair ( IMSI ,Ki ), is modeled using PV’s table construct. We do not modeldetails of algorithm capabilities/selection. The capability is anondeterministically chosen boolean value interpreted to meanwhether the MS has encryption capability. (Integrity protectionis mandatory in 3G/4G, and absent in 2G.) Because the value isnondeterministically chosen, our analysis considers all cases.Following authentication, a single data message is included,which sufces to specify the secrecy of data trafc. In the

    Fig. 5. Part of the 4G AKA scenario (Fig. 3) annotated in accord with ourmodel

    long version of the paper we consider integrity of data trafc,

    which is also specied using this message.The 4G model in ProVerif. There are four main processes

    in our PV model, representing the behavior of the MS, theeNB, the MME and the HN respectively. Fig. 5 shows thedetails of part of the model, specically Blocks III and IV fromFig. 3. Fig. 5 shows the events for correspondence assertions.It also shows the name of the variables which are used in ourmodel, which facilitates checking that the models accuratelyreect the protocol diagrams.

    In the LTE protocol, the MS already has the SN id beforestarting the AKA shown in Fig. 3. In our model, we add the SNid to the authentication challenge (message 7). In addition,ourmodel omits sequence numbering and the key AK, so they

    do not appear in Fig. 5. Sequence numbers aid in preventingre-use of authentication vectors. Instead of modeling sequencenumbers, our models simply do not re-use AVs.

    Fig. 6 shows the code of the MS process. The registrationprocess of the MS device is in lines 22–24. Lines 28–29model that the MS receives and checks the authenticationchallenge message. The process awaits a message on the publicchannel, with designated format and particular values: theformat must be (msgHdr, nonce, mac, ident) where msgHdr is theliteral CHALLENGE and the mac must equal f1(ki, rand ms) . Inlines 38–39, the MS receives the NAS SMC message andveries the integrity and the received capabilities. The MS thensends out the SMC complete message which is ciphered if theencryption is enabled and integrity protected (lines 43–51).Lines 46 and 52 call a parameterized process which speciesthe AS SMC procedure in lines 3–11 and receives the datamessage in lines 18–19. The other three processes representingthe BS, the MME, and the HN are similar to this (see [ 7]).

    The secrecy and authentication properties are specied asfollows.

    1 query a t tacker (payload ) .2 query a t tacker ( pay load) event ( disableEnc ) .3 query a t tacker ( s ec re t ) .4 query x 1 : i d e nt , x 2 : i d e nt , x 3 : asmeKey ;5 event (endSN( x1 , x2 , x3 ) ) event (begSN(x1 , x2 , x3 ) ) .6 query x 1 : i d e nt , x 2 : i d e nt , x 3 : asmeKey, x 4 : bool ;

    7

  • 8/19/2019 Authentication 2G 3G 4G

    8/39

    1 l e t pMSAS(kasme ms: asmeKey, imsi ms : iden t , cap ms: bool ) =2 l e t kenb ms: enbKey = kdf enb(kasme ms) in3 l e t kasenc ms : asEncKey = kdf as enc( kenb ms) in4 l e t ka s in t ms : a s In tKey = kd f a s i n t (kenb ms) in5 l e t kupenc ms : upEncKey = kdf up enc(kenb ms) in6 i n ( pubChannel , (=ASSMC, enableEnc as ms : bool ,7 = f in t eg a s ( boo l2b i t s t r i ng ( enab leEnc a s ms) , kas in t ms ) ) ) ;8 event begENB(imsi ms , kenb ms ) ;9 out ( pubChannel , (ASSMComplete, as smcomplete msg ,

    10 f int eg as (as smcomplete msg , kasint ms ) ) ) ;11 event endMS ENB( imsi ms , kenb ms, cap ms ) ;12 i n ( pubChannel , (=MSG, datamsg : b i t s t r i n g ,13 =f i nteg as (datamsg , kasint ms ) ) ) ;14 out (pubChannel , sencrypt as ( secret , kasenc ms ) ) ;15 out (pubChannel , s enc in t a s ( s ec re t , kasin t ms ) ) ;16 out (pubChannel , senc up( secret , kupenc ms ) ) ;17 i f enableEnc as ms = t ru e then18 l e t msgcontent : b i t s t r i n g = sdecrypt as (datamsg ,19 kasenc ms) i n 0.20

    21 l e t processMS =22 new imsi ms : i den t ;23 new k i : k ey ;24 i n s e r t k ey s ( i ms i m s , k i ) ;25 l e t cap ms: bool = e n c C a p ab i l i t y ( ) in26 out ( pubChannel , (CAP, cap ms ) ) ;27 out (pubChannel , ( ID , imsi ms ) ) ;28 i n (pubChannel , (=CHALLENGE, rand ms: nonce ,29 = f 1 ( k i , r and m s ) , s ni d ms : i d e n t ) ) ;30 l e t r e s ms : r e sp = f2 ( k i , r and ms) in

    31 l e t ck ms : c iphe rKey = f3 ( k i , r and ms) i n32 l e t i k ms : i n t egKey = f4 ( k i , r and ms) i n33 l e t kasme ms: asmeKey = kdf asme(ck ms, ik ms , snid ms) i n34 event begSN( imsi ms , snid ms , kasme ms) ;35 out ( pubChannel , (RES, res ms ) ) ;36 l e t knasenc ms = kdf nas enc(kasme ms) i n37 l e t knas int ms = kd f nas in t (kasme ms) i n38 i n ( pubChannel , (=NASSMC, enableEnc nas ms : bool , =cap ms,39 =f in teg nas ( ( enableEnc nas ms , cap ms) , knasint ms ) ) ) ;40 event endMS( imsi ms , snid ms , kasme ms, cap ms ) ;41 out (pubChannel , sencrypt nas ( secret , knasenc ms ) ) ;42 out (pubChannel , s enc in t nas ( s ec re t , knas int ms ) ) ;43 i f enableEnc nas ms = fal se then44 out ( pubChannel , (NASSMComplete, nas smcomplete msg ,45 f inte g nas (nas smcomplete msg , knasint ms ) ) ) ;46 pMSAS(kasme ms, imsi ms , cap ms)47 else48 out ( pubChannel ,49 (NASSMComplete, senc rypt n as ( nas smcomplete msg ,50 knasenc ms) , f inte g na s ( sencrypt nas (51 nas smcomplete msg , knasenc ms) , knasint ms ) ) ) ;52 pMSAS(kasme ms, imsi ms , cap ms ) .

    Fig. 6. MS process for LTE

    7 event (endMS( x1 , x2 , x3 , x4 )) event (begMS(x1 , x2 , x3 , x4 ) ) .

    8 query x 1 : i d e nt , x 2 : enbKey, x 3 : bool ;9 event (endMS ENB( x1 , x2 , x3 ) )

    event (begMS ENB(x1 , x2 , x3 ) ) .10 query x 1 : i d e nt , x 2 : en bKey ; event (endENB(x1 , x2 ) )

    event (begENB( x1 , x2 ) ) .

    The payload can be learned by the attacker when the MS is notcapable of encryption, and indeed PV nds violations of thesecrecy property in query line 1. Conditional secrecy, queryline 2, says that if the attacker obtains the secret payload thenthe event disableEnc must have previously taken place —this isproved by PV. To test the secrecy of the keys, the MS encryptsa fresh secret (a private free name in the code, not shown inFig. 6) under each of the keys and sends the ciphertexts on thepublic channel (lines 43–44 and 17–19), and query line 3 teststhe secrecy. PV proves conditional secrecy and key secrecy.

    Authentication of the MS to the MME is specied inquery lines 4–5. This refers to event endSN placed followingmessage 10 (Fig. 5) so that it follows both verication of the

    challenge and successful use of the keys derived from K ASME .Authentication of the MME to MS is specied in query lines6–7; it includes authenticity of the security capabilities. Theauthentication of the eNB to the MS is specied in query lines8–9. The encryption capability is included in the parametersof the events to specify that the events should agree on theencryption option. These authentication properties are provedsuccessfully.

    Because communication between eNB and MME is as-sumed secure, it is authentication of MS to MME impliesauthentication to eNB as well. However, as a sanity check on the model, query line 10 says that if eNB believes thatit has established the K eNB associated with an MS using theparticular IMSI, then indeed there is an MS that reached thatstage of its protocol role, for that IMSI and K eNB .

    VII. M ODELING AND ANALYZING INTEROPERATION INPRO V ERIF

    In Sect. III we annotate the protocol diagrams to mark “blocks” of message exchanges, which are composed to formthe interoperation scenarios in Sect. V. Where it is convenient,we use sub-processes in our PV models to express this struc-ture. To make the PV model for an interoperation scenario,we can easily combine these sub-processes and other codefragments that correspond to blocks, with minor modications(adding conversion functions that enable a BS to perform aparticular SMC procedure, and adding keys to the AV in S9and S10).

    For example, for the MS in LTE we factor out a processprocessMS that models the rst four blocks of LTE. Thisprocess is reused in the models for scenarios S9 and S10. If the assumptions that underly our scenarios for uncertain casesturn out to be wrong, we expect to be able to easily modelthe corrected scenarios as well. For security specications, the

    blocks already include events and the queries are easily adaptedfrom queries for the pure protocols.

    Of the 10 AKA scenarios, 5 of them are the same scenariosas in the roaming cases of GSM and UMTS, for which themodels and analysis appears in [ 16] . One of them is the pure4G AKA, which is modeled and analyzed in Sect. VI. In thissection, we discuss the models of the 4 new scenarios, andthen summarize results for all 10 scenarios.

    Scenario S7: LTE I UMTS II–III [LTE IV] LTE V,conv( CK IK → K ASME , MME). Fig. 7 elaborates the scenarioin Fig. 4 with details of the PV model and shows the locationsof the events which are used to specify authentication andconditional payload secrecy. Most of the code in this model

    is inherited from the 4G model and the UMTS model. Thesecrecy and authentication properties are specied similar tothe ones in the 4G model:

    1 query a t tacker ( pay load) event ( disableEnc ) .2 query a t tacker ( s ec re t ) .3 query x 1 : i d e nt , x 2 : c ip he r Ke y , x 3 : i n te g Ke y ;4 event (endSN( x1 , x2 , x3 ) ) event (begSN(x1 , x2 , x3 ) ) .5 query x 1 : i d e nt , x 2 : enbKey, x 3 : bool ;6 event (endMS( x1 , x2 , x3 ) ) event (begMS(x1 , x2 , x3 ) ) .

    As in pure 4G, plain secrecy of the message payload does nothold because the attacker can always learn the payload if theMS is not capable of encryption. Conditional secrecy (query

    8

  • 8/19/2019 Authentication 2G 3G 4G

    9/39

    Fig. 7. Authentication scenario S7, version without LTE IV, annotated inaccord with our model

    line 1) does hold. Secrecy of keys (line 2) is also proved.Authentication of the MS to the SN is specied in lines 3–4and is proved. Authentication of the SN to the MS is speciedin lines 5–6. For the version without LTE IV, PV nds anattack that violates the property. The attacker intercepts thecapability message sent by the MS and replaces the capabilitieswith different ones. The event endMS is executed after the MSreceives the SMC message. Because the SMC message doesnot contain the received MS’s capabilities, the MS has no wayto conrm whether the SN receives the correct capabilities.PV detects the violation because, although there was a begMSevent, it has a different value for capabilities. For the versionwith LTE IV, the property is proved.

    Scenario S8: LTE I’ UMTS II–III LTE IV–V,conv( CK IK nonces → K ASME , MME). ProVerif proves allthe properties except the payload secrecy.

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

    CK + IK. In the models (with or without LTE IV) of this scenario, the MME uses the key conversion functionfun c3(cipherKey, integKey): gsmKey to derive the GSM sessionkey from the UMTS cipher and integrity keys. Because theBS is the GSM BS, the false base station attack on the AKAwithout LTE IV is found when checking the authentication of the BS to the MS. In the model with LTE IV, an attack is foundwhen checking the authentication of the BS to the MS. In theattack, the attacker modies the CMC message (which is notintegrity protected) to tell the MS to use no encryption. Thisattack will be detected by the BS once the MS sends messagesto the BS. As in other scenarios, the payload secrecy could be

    TABLE IV. A NALYSIS RESULTS

    Scenario ConditionalsecrecyKey

    secrecy

    Auth. of MS toVLR/

    SGSN/MME

    Auth. of VLR/

    SGSN/MMEto MS

    Auth. of BSto MS

    S1 Proved Proved Proved N/Aknown falsebase station

    attack S2 Proved Proved Proved N/A ProvedS3 Proved Proved Proved Proved Proved

    S4 Proved Proved Proved N/A

    known false

    base stationattack

    S5 Proved Proved Proved N/A Proved

    S6 Proved Proved Proved N/Aknown falsebase station

    attack

    S7 w/oLTE IV Proved Proved Proved N/A

    false basestationattack

    S7 w/ LTE IV Proved Proved Proved Proved Proved

    S8 Proved Proved Proved Proved ProvedS9 w/

    LTE IV Proved Proved Proved Proved CMC attack

    S9 w/oLTE IV Proved Proved Proved N/A

    known falsebase station

    attack S10 w/ LTE IV Proved Proved Proved Proved Proved

    S10w/o

    LTE IVProved Proved Proved N/A Proved

    violated because the BS could choose to disable encryptionwhen communicating with the MS.

    Scenario S10: UMTS I LTE II–III [LTE IV] UMTS IV, AV = 4G AV + CK + IK. ProVerif proves all theproperties except the payload secrecy.

    Analysis Results. Table IV gives results for all the 10scenarios. In the model of scenario S9 without LTE IV, wend the known false base station attack [ 1] which has the same

    attack scenario as in the native GSM AKA, i.e., in S1 and S4.In this attack, the attacker intercepts the CAP message andmodies the capabilities of the MS as no-encryption. When theBS decides which algorithm to use, the BS has to choose notto enable encryption. Because the subsequent trafc betweenthe MS and the 2G BS is not encrypted nor integrity protected,the attacker can both eavesdrop and modify the messages.

    The attack found in scenario S7 without LTE IV is similar.The attacker intercepts and modies the capabilities of MSto no-encryption to force the 4G BS to choose not to useencryption. Although integrity protection is mandatory for thesignaling trafc of 4G BS, there is no integrity protection onthe user plane trafc, so the attack can both eavesdrop andmodify the data trafc.

    In the model of scenario S9 with LTE IV, we nd an attack in which the attacker simply modies the CMC message to tellthe MS to use no encryption. This attack would be detectedonce the MS sends unencrypted messages to the BS.

    VIII . C ONCLUSION

    In this paper we study authentication and key agreement(AKA) for interoperation among GSM, UMTS and LTE. Todetermine the AKA procedures in each interoperation case,we consider all combinations of the ve relevant system

    9

  • 8/19/2019 Authentication 2G 3G 4G

    10/39

    components. We classify some cases as allowed or disallowed,based on information about component compatibility gleanedfrom the standards documents. Some cases are classied asuncertain, for lack of denite information in the standards.For each possible (allowed or uncertain) interoperation case,we identify and justify a particular AKA scenario built fromelements (“blocks”) of the pure GSM, UMTS, and LTEprotocols.

    It turns out that 10 scenarios are needed to cover all the 105possible interoperation cases. Of these scenarios, 5 involve justGSM and UMTS and were identied previously (see Sect. II);one is the pure LTE; the remaining 4 are new. In most cases,the AKA scenario is completely determined by the componentsinvolved. However, a few cases have two feasible versions of the scenarios which differ by whether block LTE IV is includedor whether the nonce in TAU request is used.

    We model and analyze pure LTE and the 4 new AKAscenarios involving LTE components, using ProVerif, focusingin this paper on authentication and secrecy properties. For thescenarios involving LTE, we nd three attacks. One is the falsebase station attack which is inherited from the GSM system

    and is also found in GSM-UMTS interoperation. Anotherattack, on one version of scenario S7, is a similar false basestation attack but with a 4G BS. The attack is prevented byincluding block LTE IV. In the third attack on the AKA of scenario S9 with LTE IV, the CMC message is modied. Asidefrom these attacks, the desired authentication and secrecyproperties are proved (in the symbolic model of perfect crypto,with unbounded sessions) for all other cases.

    For further work, we would like to analyze the handoverin GSM, UMTS, and LTE, as well as across the technologies.We also are interested in exploring the interworking between4G and non-3GPP networks.

    REFERENCES

    [1] U. Meyer and S. Wetzel, “A man-in-the-middle attack on UMTS,” in ACM WiSec , 2004, pp. 90–97.

    [2] ——, “On the impact of GSM encryption and man-in-the-middle attackson the security of interoperating GSM/UMTS networks,” in IEEE Symposium on Personal, Indoor and Mobile Radio Communications ,2004.

    [3] “3GPP TS 33.102 version 11.4.0 Release 11 Digital cellular telecom-munications system (Phase 2+); Universal Mobile TelecommunicationsSystem (UMTS); LTE; 3G security; Security architecture ,” http://www.3gpp.org/ftp/Specs/html-info/33102.htm.

    [4] “3GPP TS 33.401 v10.0.0; Digital cellular telecommunications system(Phase 2+); Universal Mobile Telecommunications System (UMTS);LTE; 3gpp System Architecture Evolution (SAE); Security architec-ture,” http://www.3gpp.org/ftp/Specs/html-info/33401.htm.

    [5] B. Blanchet, “Automatic verication of correspondences for securityprotocols,” Journal of Computer Security , vol. 17, no. 4, pp. 363–434,Jul. 2009.

    [6] “3GPP TR 31.900 v11.0.0 Release 11; Universal Mobile Telecommu-nications System (UMTS); LTE; SIM/USIM internal and external inter-working aspects,” http://www.3gpp.org/ftp/Specs/html-info/31900.htm.

    [7] C. Tang, D. A. Naumann, and S. Wetzel, “Analysis of authen-tication and key establishment in inter-generational mobile tele-phony (long version),” 2013, http://www.cs.stevens.edu/ ∼naumann/pub/ TangNaumannWetzel2013.pdf.

    [8] J. D. Golic, “Cryptanalysis of alleged a5 stream cipher,” in EURO-CRYPT , 1997.

    [9] L. G. I. Goldberg, D. Wagner, “The real-time cryptanalysis of A5/2,”Rumpsession of CRYPTO, 1999.

    [10] S. Petrovic and A. Fster-Sabater, “Cryptanalysis of the A5/2 algorithm,”Cryptology ePrint Archive, Report 2000/052, 2000, http://eprint.iacr.org/.

    [11] E. Barkan, E. Biham, and N. Keller, “Instant ciphertext-only crypt-analysis of GSM encrypted communication,” J. Cryptol. , vol. 21, pp.392–429, March 2008.

    [12] O. Dunkelman, N. Keller, and A. Shamir, “A practical-time related-keyattack on the KASUMI cryptosystem used in GSM and 3G telephony,”in CRYPTO , 2010.

    [13] Z. Ahmadian, S. Salimi, and A. Salahi, “New attacks on UMTS network access,” in Wireless Telecommunications Symposium, 2009. WTS 2009 .IEEE, 2009, pp. 1–6.

    [14] D. Fox, “Der IMSI catcher,” in DuD Datenschutz und Datensicherheit ,2002.

    [15] U. Meyer, “Secure roaming and handover procedures in wireless accessnetworks,” Ph.D. dissertation, Darmstadt University of Technology,Germany, 2005.

    [16] C. Tang, D. A. Naumann, and S. Wetzel, “Symbolic analysis for securityof roaming protocols in mobile networks,” in SecureComm 2011 :Seventh International ICST Conference on Security and Privacy inCommunication Networks , 2011.

    [17] R. Chang and V. Shmatikov, “Formal analysis of authentication inBluetooth device pairing,” in FCS-ARSPA , 2007.

    [18] M. Jakobsson and S. Wetzel, “Security weaknesses in Bluetooth,” inCryptographer’s Track at the RSA Conference (CT-RSA) , 2001, pp. 176–191.

    [19] B. Blanchet and A. Chaudhuri, “Automated formal analysis of aprotocol for secure le sharing on untrusted storage,” in IEEE Symp.on Sec. and Priv. , 2008.

    [20] L. Chen and M. Ryan, “Attack, solution and verication for sharedauthorisation data in TCG TPM,” in Formal Aspects in Security and Trust , 2009, pp. 201–216.

    [21] S. Kremer and M. Ryan, “Analysis of an electronic voting protocol inthe applied pi calculus,” in ESOP , 2005, pp. 186–200.

    [22] M. Arapinis, L. Mancini, E. Ritter, M. Ryan, N. Golde, K. Redon,and R. Borgaonkar, “New privacy issues in mobile telephony: x andverication,” in ACM CCS . ACM, 2012, pp. 205–216.

    [23] C. Han and H. Choi, “Security analysis of handover key managementin 4G LTE/SAE network,” 2012.

    [24] J.-K. Tsay and S. F. Mjølsnes, “A vulnerability in the UMTS and

    LTE authentication and key agreement protocols,” in Computer Network Security . Springer, 2012, pp. 65–76.[25] M.-F. Lee, N. P. Smart, B. Warinschi, and G. J. Watson, “Anonymity

    guarantees of the UMTS/LTE authentication and connection protocol,” IACR Cryptology ePrint Archive , vol. 2013, p. 27.

    [26] M. A. Mobarhan, M. A. Mobarhan, and A. Shahbahrami, “Evaluationof security attacks on UMTS authentication mechanism,” International Journal of Network Security & Its Applications , vol. 4, no. 4, 2012.

    [27] “TS 23.060 version 11.5.0 Release 11; Digital cellular telecommunica-tions system (Phase 2+); Universal Mobile Telecommunications System(UMTS); General Packet Radio Service (GPRS); Service description;Stage 2,” http://www.3gpp.org/ftp/Specs/html-info/23060.htm.

    [28] “3GPP TS 23.401 version 11.4.0 Release 11; LTE; General PacketRadio Service (GPRS) enhancements for Evolved Universal TerrestrialRadio Access Network (E-UTRAN) access,” http://www.3gpp.org/ftp/ Specs/html-info/23401.htm.

    [29] “Digital cellular telecommunications system (Phase 2+); Mobile radiointerface layer 3 specication (GSM 04.08 version 7.8.0 Release 1998),”1998.

    [30] D. Forsberg, G. Horn, W.-D. Moeller, and V. Niemi, LTE Security .John Wiley and Sons, Ltd, 2010.

    [31] “3GPP TS 24.301 version 11.4.0 Release 11; Universal Mo-bile Telecommunications System (UMTS); LTE; Non-Access-Stratum(NAS) protocol for Evolved Packet System (EPS); Stage 3,” http: //www.3gpp.org/ftp/Specs/html-info/24301.htm.

    [32] A. D. Gordon and A. Jeffrey, “Authenticity by typing for securityprotocols.” Journal of Computer Security , pp. 451–520, 2003.

    10

    http://www.3gpp.org/ftp/Specs/html-info/33102.htmhttp://www.3gpp.org/ftp/Specs/html-info/33102.htmhttp://www.3gpp.org/ftp/Specs/html-info/33401.htmhttp://www.3gpp.org/ftp/Specs/html-info/31900.htmhttp://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://eprint.iacr.org/http://eprint.iacr.org/http://www.3gpp.org/ftp/Specs/html-info/23060.htmhttp://www.3gpp.org/ftp/Specs/html-info/23401.htmhttp://www.3gpp.org/ftp/Specs/html-info/23401.htmhttp://www.3gpp.org/ftp/Specs/html-info/24301.htmhttp://www.3gpp.org/ftp/Specs/html-info/24301.htmhttp://www.3gpp.org/ftp/Specs/html-info/24301.htmhttp://www.3gpp.org/ftp/Specs/html-info/24301.htmhttp://www.3gpp.org/ftp/Specs/html-info/23401.htmhttp://www.3gpp.org/ftp/Specs/html-info/23401.htmhttp://www.3gpp.org/ftp/Specs/html-info/23060.htmhttp://eprint.iacr.org/http://eprint.iacr.org/http://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://www.cs.stevens.edu/~naumann/pub/TangNaumannWetzel2013.pdfhttp://www.3gpp.org/ftp/Specs/html-info/31900.htmhttp://www.3gpp.org/ftp/Specs/html-info/33401.htmhttp://www.3gpp.org/ftp/Specs/html-info/33102.htmhttp://www.3gpp.org/ftp/Specs/html-info/33102.htm

  • 8/19/2019 Authentication 2G 3G 4G

    11/39

    A PPENDICES

    Sect. A gives the complete table of cases and Sect. B givesthe complete table of scenarios. Sect. C presents the modelsof the scenarios and Sect. D gives the complete code.

    A PPENDIX ATABLE OF CASES

    Figures 8 – 14 show the classication the 243 interoper-ation cases. The table makes reference to the list of reasonsR1–R7 in Sect. IV and the list of conditions A1–A4 at the endof Sect. IV.

    As stated in the main body of the paper, rows in normalfont with no color indicate the allowed cases. Green color andbold font indicates the uncertain cases. Grey color and italicfont indicates the disallowed cases. Blue color and bold italicfont indicates the cases involving only 2G/3G components.

    Fig. 8. Table of cases, part 1 of 7

    Fig. 9. Table of cases, part 2

    11

  • 8/19/2019 Authentication 2G 3G 4G

    12/39

    Fig. 10. Table of cases, part 3 Fig. 11. Table of cases, part 4

    12

  • 8/19/2019 Authentication 2G 3G 4G

    13/39

    Fig. 12. Table of cases, part 5

    Fig. 13. Table of cases, part 6

    Fig. 14. Table of cases, part 7

    13

  • 8/19/2019 Authentication 2G 3G 4G

    14/39

    A PPENDIX BTABLE OF SCENARIOS

    Figure 15 – 17 show the determination of the AKAscenarios and respective reasoning, with reference to the listA–X in Table II.

    Fig. 15. Table of scenarios, part 1 of 3

    Fig. 16. Table of scenarios, part 2

    Fig. 17. Table of scenarios, part 3

    14

  • 8/19/2019 Authentication 2G 3G 4G

    15/39

    A PPENDIX CMODELS OF THE SCENARIOS

    This section presents scenarios S7 (without LTE IV), S8,S9+ (with LTE IV) and S10+ (with LTE IV) with someexplanation. The pure 4G model is discussed in Sect. VI.The other pure models and scenarios are presented in [ 16] .Appendix D gives the complete code les for all models.

    S7. LTE I UMTS II–III LTE V, conv(CK IK → K ASME , MME)

    Most of the code in this model is inherited from the 4Gmodel and the UMTS model. The key derivation function usedby the MME and the MS to generate the local master keyK ASME is declared as:fun kdf asme( cipherKey , integKey ) : asmeKey.

    There are three main processes in our model representing thebehavior of the MS, the SN and the HN respectively.

    1 ( ∗MS non − d e t e r m i n i s t i c a l l y c h oo se 2 t he c a p a b i l i t y o f e n cr y p ti o n ∗ )3 l e t cap ms: bool = e n c C a p ab i l i t y ( ) in4 ( ∗Send out cap ms to SN ∗ )5 out ( pubChannel , (CAP, cap ms ) ) ;6 ( ∗Send out permanent ID ∗ )7 out (pubChannel , ( ID , imsi ms ) ) ;8 ( ∗Inpu t chal lenge message from SN ∗ )9 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , mac ms: mac ) ) ;

    10 i f f1 ( ki , rand ms) = mac ms then11 ( ∗Compute response and encry pt ion key ∗ )12 l e t r e s ms : r e sp = f2 ( k i , r and ms) i n13 l e t ck ms : c iphe rKey = f3 ( k i , r and ms) in14 l e t i k ms : i n t egKey = f4 ( k i , r and ms) in15 ( ∗MS i s a u t he n ti c at i n g i t s e l f t o SN ∗ )16 event begSN( imsi ms , ck ms, ik ms ) ;17 ( ∗Send out response to SN ∗ )18 out ( pubChannel , (RES, res ms ) ) ;19 l e t kasme ms = kdf asme(ck ms, ik ms ) in20 l e t kenb ms: enbKey = kdf enb (kasme ms) i n21 l e t kasenc ms : asEncKey = kdf as enc( kenb ms) in22 l e t k as i nt m s : a s In t Ke y = k d f a s i n t ( kenb m s ) in23 l e t kupenc ms : upEncKey = kdf up enc(kenb ms) in24 ( ∗Receive GSM ci ph er mode command ∗ )25 i n ( pubChannel , (=ASSMC, enableEnc as ms : bool ,26 = f in t eg a s ( boo l2b i t s t r in g ( enab leEnc a s ms) ,27 kasint ms ) ) ) ;28 out ( pubChannel , (ASSMComplete, as smcomplete msg ,29 f int eg a s (as smcomplete msg , kasint ms ) ) ) ;30 event endMS(imsi ms , kenb ms, cap ms) ;31 i n ( pubChannel , (=MSG, datamsg: b i t s t r i n g ,32 =f i nteg as (datamsg , kasint ms ) ) ) ;33 out (pubChannel , sencrypt ( secret , ck ms ) ) ;34 out (pubChannel , s enc ryp t In t eg ( s ec re t , i k ms ) ) ;35 i f enableEnc as ms = t ru e then36 l e t msgconten t : b i t s t r i n g = sdecrypt as (datamsg ,37 kasenc ms) in 0 .38

    39 l e t processSN =40 ( ∗Rece ive MS’ s cap ab i l i t y ∗ )41 i n (pubChannel , (=CAP, cap sn: bool ) ) ;42 ( ∗Receive permanent ID ∗ )43 i n ( pubChannel , (= ID , ims i sn : i den t ) ) ;44 ( ∗Send o u t a u t h e n t i c a t i o n v e c t o r r e q ue s t ∗ )45 out ( secureChannel , (AV REQ, imsi sn ) ) ;46 ( ∗R ec ei ve a u t h e n t i c a t i o n v e c t o r ∗ )47 i n (secureChannel , (=AV, =imsi sn , rand sn : nonce ,48 x r e s sn : r e sp , ck sn : c iphe rKey , i k sn : i n t egKey ,49 mac sn : mac) ) ;50 ( ∗Send a u t h e n t i c a t i o n c h a ll e n ge t o MS ∗ )51 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ;52 ( ∗Receive response ∗ )53 i n (pubChannel , (=RES, res sn : resp ) ) ;54 ( ∗Check whether received response equal to XRES ∗ )55 i f r e s s n = x re s s n then56 ( ∗A t t h i s p o i n t , SN a u t h e n t i c a t e d MS ∗ )57 event endSN( imsi sn , ck sn , ik sn ) ;

    58 l e t ka sme sn = kdf a sme(ck sn , i k sn ) in59 l e t kenb sn : enbKey = kdf enb( kasme sn) i n60 l e t ka senc sn : a sEncKey = kd f a s enc (kenb sn ) i n61 l e t k a s i n t s n : a s In t Ke y = k d f a s i n t ( k en b sn ) in62 l e t kupenc sn : upEncKey = kdf up enc( kenb sn) in63 event begMS( imsi sn , kenb sn , cap sn ) ;64 out ( pubChannel , (ASSMC, cap sn ,65 f i n t e g a s ( b o o l 2 b i t s t r i n g ( c ap sn ) , k a s in t s n ) ) ) ;66 i n ( pubChannel , (=ASSMComplete, =as smcomplete msg ,67 =f in teg as (as smcomplete msg , k asint sn ) ) ) ;68 i f c a p s n = f a l s e then

    69 event di sableEnc ;70 ou t ( pubChannel , (MSG, payload ,71 f i n t e g a s ( p a yl oa d , k a s in t s n ) ) )72 else73 ou t (pubChannel , (MSG, sencryp t as ( payload ,74 kasenc sn ) , f i n t eg a s ( s enc ryp t a s (pay load ,75 kasenc sn) , kasint sn ) ) ) .76

    77 l e t processHN =78 ( ∗R ec ei ve a u t h e n t i c a t i o n v e c t o r r e q ue s t ∗ )79 i n ( secureChannel , (=AV REQ, imsi hn : iden t ) ) ;80 ( ∗Generate a f res h random number ∗ )81 new rand hn : nonce;82 ( ∗Computes expected response and Kc ∗ )83 ge t keys (= ims i hn , k i hn ) i n84 l e t mac hn : mac = f1 (k i hn , r and hn ) i n85 l e t x r e s h n : r e sp = f 2 ( k i h n , r an d h n ) in86 l e t c k h n : c i ph e rK e y = f 3 ( k i h n , r an d h n ) i n87 l e t i k h n : i n te g Ke y = f 4 ( k i h n , r an d h n ) in88 (

    Send o u t a u t h e n t i c a t i o n v e c t o r ∗

    )89 out ( secureChannel , (AV, imsi hn , rand hn ,90 x re s hn , c k hn , i k hn , m ac hn ) ) .

    The HN process is the same as the one in the UMTS model.In line 19 and line 58, the MS and the SN derive the localmaster key K ASME from the cipher key and the integrity key.

    Security Property Specications and Findings Theevents used in the correspondence assertions to specify theauthentication properties are declared as:

    1 event begSN( ident , c ipherKey , integKey ) .2 event endSN( ident , c ipherKey , integKey ) .3 event begMS( id ent , enbKey, bool ) .4 event endMS( id ent , enbKey, bool ) .

    The secrecy and authentication properties are specied as:1 query a t tacker (payload ) .2 query a t tacker ( pay load) event ( disableEnc ) .3 query a t tacker ( s ec re t ) .4 query x 1 : i d e nt , x 2 : c ip he r Ke y , x 3 : i n te g Ke y ;5 event (endSN( x1 , x2 , x3 ) ) event (begSN(x1 , x2 , x3 ) ) .6 query x 1 : i d e nt , x 2 : enbKey, x 3 : bool ;7 event (endMS( x1 , x2 , x3 )) event (begMS(x1 , x2 , x3 ) ) .

    The secrecy property of the message payload does not hold,because the attacker can always learn the payload if the MSis not capable of encryption. The conditional secrecy (line 2)holds. That means if the encryption is enabled, the attacker cannever learn the message payload. The property specied in line

    3 is used to test the secrecy of the keys. ProVerif proves the keysecrecy. The authentication of the MS to the SN is speciedin lines 4–5. ProVerif proves this authentication property. Theauthentication of the SN to the MS is specied in lines 6–7.Proverif nds a attack trace that violates the property:

    1 new i ms i m s c r e a t i n g i ms i m s 5 87 0 a t {2} in copy a2 new k i c r e a t in g k i 5 87 1 a t {3} in copy a3 i n s e r t keys ( imsi ms 5870 , k i 5871) a t {4} in copy a4 ou t (pubChannel , (CAP, t ru e )) a t {6} in copy a5 ou t (pubChannel , ( ID , imsi ms 5870 )) a t {7} in copy a6 in (pubChannel , (CAP,a 5860) ) a t {31 } in copy a 58617 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 58618 in (pubChannel , (CAP,as smcomplete msg) ) at {31 } in copy a 58629 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 5862

    15

  • 8/19/2019 Authentication 2G 3G 4G

    16/39

    10 in (pubChannel , (CAP,a 5863) ) a t {31 } in copy a 586411 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 586412 in (pubChannel , (CAP,as smcomplete msg) ) at {31 } in copy a 586513 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 586514 in (pubChannel , (CAP,a 5866) ) a t {31 } in copy a 586715 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 586716 in (pubChannel , (CAP,a 5868) ) a t {31 } in copy a 586917 in (pubChannel , ( ID , imsi ms 5870 )) a t {32 } in copy a 586918 ou t ( secureChannel , (AV REQ, imsi ms 5870 )) at {33 } i n19 c op y a 5 86 5 r e c ei v e d a t {55 } i n copy a 585920 new r an d h n c r e a t i n g r an d h n 5 87 2 a t {56 } in copy a 585921 ge t keys ( imsi ms 5870 , k i 5871) a t {57 } i n copy a 585922 ou t (secureChannel , (AV,imsi ms 5870 , rand hn 5872 ,23 f 2 (k i 5871 , r and hn 5872) , f3 (k i 5871 , r and hn 5872) ,24 f 4 (k i 5871 , r and hn 5872) , f1 (k i 5871 , r and hn 5872 ) ) )25 a t {62 } i n copy a 5859 r ece ived a t {34 } in copy a 586526 ou t ( pubChannel , (CHALLENGE, rand hn 5872 , f1 ( ki 5871 ,27 r and hn 5872 ) ) ) a t {35 } i n copy a 586528 in (pubChannel , (CHALLENGE, rand hn 5872 , f1 ( ki 5871 ,29 r and hn 5872 ) ) ) a t {8} in copy a30 event (begSN(imsi ms 5870 , f3 (ki 5871 , rand hn 5872) ,31 f 4 (k i 5871 , r and hn 5872 ) ) ) a t {13 } in copy a32 ou t (pubChannel , (RES, f2 ( ki 5871 , rand hn 5872 ) ))33 a t {14 } i n copy a34 in (pubChannel , (RES, f2 ( ki 5871 , rand hn 5872 ) ) )35 a t {36 } i n copy a 586536 event (endSN(imsi ms 5870 , f3 (ki 5871 , rand hn 5872) ,37 f 4 (k i 5871 , r and hn 5872 ) ) ) a t {38 } in copy a 586538 event (begMS(imsi ms 5870 , kdf enb (kdf asme( f3 ( ki 5871 ,39 r and hn 5872) , f4 (k i 5871 , r and hn 5872 ) ) ) ,40 as smcomplete msg )) a t

    {44

    } in copy a 5865

    41 ou t ( pubChannel , (ASSMC,as smcomplete msg ,42 f i n t eg a s ( a s smcomplet e msg , kd f a s i n t (kd f enb(kdf a sme(43 f3 (ki 5871 , rand hn 5872) , f4 ( ki 5871 , rand hn 5872 ) ) ) ) ) ) )44 a t {46 } i n copy a 586545 in (pubChannel , (ASSMComplete , as smcomplete msg ,46 f i n t eg a s ( a s smcomplet e msg , kd f a s i n t (kd f enb(kdf a sme(47 f3 (ki 5871 , rand hn 5872) , f4 ( ki 5871 , rand hn 5872 ) ) ) ) ) ) )48 a t {47 } i n copy a 586549 ou t (pubChannel , (MSG, sencrypt as (payload ,50 kd f a s enc (kdf enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,51 f 4 (k i 5871 , r and hn 5872 ) ) ) ) ) , f i n t eg a s ( s enc ryp t a s (pay load ,52 kd f a s enc (kdf enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,53 f 4 (k i 5871 , r and hn 5872 ) ) ) ) ) ,54 kd f a s i n t (kd f enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,55 f4 ( ki 5871 , rand hn 5872 ) ) ) ) ) ) )56 a t {53 } i n copy a 586557 in ( pubChannel , (ASSMC, senc ryp t as ( payload ,58 kd f a s enc (kdf enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,59 f 4 (k i 5871 , r and hn 5872 ) ) ) ) ) , f i n t eg a s ( s enc ryp t a s (pay load ,60 kd f a s enc (kdf enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,61 f 4 (k i 5871 , r and hn 5872 ) ) ) ) ) ,62 kd f a s i n t (kd f enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,63 f4 ( ki 5871 , rand hn 5872 ) ) ) ) ) ) )64 a t {20 } i n copy a65 ou t ( pubChannel , (ASSMComplete , as smcomplete msg ,66 f i n t eg a s ( a s smcomplet e msg , kd f a s i n t (67 kd f enb(kdf a sme( f3 (k i 5871 , r and hn 5872) ,68 f4 (ki 5871 , rand hn 5872 ) ) ) ) ) ) ) a t {22 } i n copy a69 event (endMS(imsi ms 5870 , kdf enb (kdf asme( f3 ( ki 5871 ,70 rand hn 5872 ) , f4 ( ki 5871 , rand hn 5872 )) ) , t ru e ))71 a t {23 } i n copy a72 The event endMS( imsi ms 5870 , kdf enb ( kdf asme( f3 ( ki 5871 ,73 r and hn 5872) , f4 (k i 5871 , r and hn 5872 ) ) ) , t rue )74 i s executed .

    In this trace, the attacker intercepts the capability messagesent by the MS and replaces the capabilities with differentones. Since the event beginMS in process SN records thecapabilities received by the SN, which are the replaced ones.The event endMS is executed after the MS receives the securitymode command message. Because the security mode commandmessage does not contain the received MS’s capabilities, theMS has no way to conrm whether the SN receives the correctcapabilities. The event endMS is executed with recordingthe original capabilities of the MS. The two events do notagree the third parameter (the capabilities), which violates thecorrespondence assertion.

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

    Figure 18 shows details of the ProVerif model and the lo-cations of the events which are used to specify the conditionalpayload secrecy and the authentication properties. Most of thecode in this model is inherited from the 4G model and theUMTS model. The key derivation function used to derive theK ASME is dened as:fun kdf asme( cipherKey , integKey , nonce , nonce ) : asmeKey.

    There are four main processes in our model representing thebehavior of the MS, the BS, the SN and the HN respectively.

    1 ( ∗AS SMC procedur e in process MS ∗ )2 l e t pMSAS(kasme ms: asmeKey, imsi ms : iden t , cap ms: bool ) =3 l e t kenb ms: enbKey = kdf enb (kasme ms) i n4 l e t kasenc ms : asEncKey = kdf as enc(kenb ms) i n5 l e t ka s in t ms : a s In tKey = kd f a s i n t (kenb ms) i n6 l e t kupenc ms : upEncKey = kdf up enc(kenb ms) i n7 i n ( pubChannel , (=ASSMC, enableEnc as ms : bool ,8 = f in t eg a s ( boo l2b i t s t r in g ( enab leEnc a s ms) ,9 kasint ms ) ) ) ;

    10 out ( pubChannel , (ASSMComplete, as smcomplete msg ,11 f int eg as (as smcomplete msg , kasint ms ) ) ) ;12 event endMS ENB( imsi ms , kenb ms, cap ms) ;13 i n ( pubChannel , (=MSG, datamsg: b i t s t r i n g ,14 =f i nteg as (datamsg , kasint ms ) ) ) ;15 out (pubChannel , sencrypt as ( secret , kasenc ms ) ) ;16 out (pubChannel , s enc in t a s ( s ec re t , kas in t ms ) ) ;17 out (pubChannel , senc up( secret , kupenc ms ) ) ;18 i f enableEnc as ms = t ru e then19 l e t msgcontent : b i t s t r i n g =20 sdecry pt as (datamsg , kasenc ms) i n 0 .21

    22 ( ∗process r e sp resen t ing MS ∗ )23 l e t processMS =24 ( ∗The i d e n t i t y o f t he MS ∗ )25 new imsi ms : i den t ;26 ( ∗Pre − shared key ∗ )27 new k i : k ey ;28 ( ∗ I n s e r t i d / p re − s ha re d key p a i r i n t o t he p r i v a t e t a b l e ∗ )29 i n s e r t k ey s ( i ms i m s , k i ) ;30 ( ∗MS non − d e t e r m i n i s t i c a l l y ch oos e t he c a p a b i l i t y o f e n cr y p ti o31 l e t cap ms: bool = e n c C a p ab i l i t y ( ) i n32 out ( pubChannel , (CAP, cap ms ) ) ;33 out (pubChannel , ( ID , imsi ms ) ) ;34 new nonce ms: nonce;35 out ( pubChannel , (NONCE TAU, nonce ms ) ) ;36 i n ( pubChannel , (=CHALLENGE, rand ms : nonce , =f 1 ( ki , rand ms ) 37 l e t r e s ms : r e sp = f2 ( k i , r and ms) i n38 l e t ck ms : c iphe rKey = f3 ( k i , r and ms) in39 l e t i k ms : i n t egKey = f4 ( k i , r and ms) in40 event begSN( imsi ms , ck ms, ik ms ) ;41 out ( pubChannel , (RES, res ms ) ) ;42 ( ∗NAS SMC pro ced ure ∗ )43 i n ( pubChannel , (=NASSMC, enableEnc nas ms : bool , =cap ms,44 =nonce ms, nonce mme ms: nonce , nas mac: msgMac) ) ;45 l e t kasme ms: asmeKey = kdf asme( ck ms, ik ms ,46 nonce ms, nonce mme ms) i n47 l e t knasenc ms : nasEncKey = kdf nas enc( kasme ms) in48 l e t knas int ms : nas IntKey = kd f nas in t (kasme ms) in49 i f (nas mac = f inte g nas ( ( enableEnc nas ms , cap ms,50 nonce ms, nonce mme ms) , knasint ms ) ) then51 event endMS(imsi ms , ck ms, ik ms , cap ms) ;52 ( ∗NAS key secrecy ∗ )53 out (pubChannel , sencrypt nas ( secret , knasenc ms ) ) ;54 out (pubChannel , s enc in t nas ( s ec re t , knas int ms ) ) ;55 i f enableEnc nas ms = fal se then56 ou t ( pubChannel , (NASSMComplete, nas smcomplete msg ,57 f int eg nas (nas smcomplete msg , knasint ms ) ) ) ;58 pMSAS(kasme ms, imsi ms , cap ms)59 else60 ou t ( pubChannel , (NASSMComplete,61 sencrypt nas (nas smcomplete msg , knasenc ms) ,62 f int eg nas ( sencrypt nas (nas smcomplete msg ,63 knasenc ms) , knasint ms ) ) ) ;64 pMSAS(kasme ms, imsi ms , cap ms) .65

    66 ( ∗process r ep resen t ing e − nodeB ∗ )

    16

  • 8/19/2019 Authentication 2G 3G 4G

    17/39

    Fig. 18. Scenario S8 annotated in accord with our model

    67 l e t processENB =68 i n (sChannelSnBts , (kasme enb: asmeKey, imsi enb : ident ,69 cap enb: bool ) ) ;70 l e t kenb enb: enbKey = kdf enb( kasme enb) i n71 l e t kasenc enb: asEncKey = kdf as enc( kenb enb) i n72 l e t k a s in t e n b : a s In t Ke y = k d f a s i n t ( k enb e n b ) i n73 l e t kupenc enb : upEncKey = kdf up enc( kenb enb) i n74 event begMS ENB( imsi enb , kenb enb , cap enb ) ;75 out ( pubChannel , (ASSMC, cap enb ,76 f i n t eg a s ( boo l2b i t s t r in g ( cap enb) , kas in t enb ) ) ) ;77 i n ( pubChannel , (=ASSMComplete, =as smcomplete msg ,78 =f i nteg as (as smcomplete msg , kasint enb ) ) ) ;79 i f c ap e nb = f a l s e then80 event di sableEnc ;

    81 out ( pubChannel , (MSG, payload ,82 f i n t e g a s ( p a yl oa d , k a si n t e n b ) ) )83 e lse84 out ( pubChannel , (MSG, sencryp t as ( payload , kasenc enb) ,85 f int eg as ( sencrypt as ( payload , kasenc enb) ,86 kasint enb ) ) ) .87

    88 ( ∗process repre sent i ng MME ∗ )89 l e t processMME =90 i n ( pubChannel , (=CAP, cap sn: bool ) ) ;91 i n ( pubChannel , (= ID , ims i sn : i den t ) ) ;92 i n ( pubChannel , (=NONCE TAU, nonce ms sn: nonce ) ) ;93 out ( secureChannel , (AV REQ, imsi sn ) ) ;94 i n ( secureChannel , (=AV, =imsi sn , rand sn : nonce ,

    17

  • 8/19/2019 Authentication 2G 3G 4G

    18/39

    95 x r e s sn : r e sp , ck sn : c iphe rKey ,96 i k sn : i n tegKey , mac sn : mac) ) ;97 out ( pubChannel , (CHALLENGE, rand sn , mac sn ) ) ;98 i n (pubChannel , (=RES, =xres sn ) ) ;99 event endSN( imsi sn , ck sn , ik sn ) ;

    100 new nonce mme: nonce;101 ( ∗NAS SMC pro ced ure ∗ )102 l e t kasme sn: asmeKey = kdf asme(ck sn , ik sn ,103 nonce ms sn, nonce mme) i n104 l e t knasenc sn : nasEncKey = kdf nas enc(kasme sn) in105 l e t knas in t sn : nas IntKey = kd f nas in t (kasme sn ) in

    106 event begMS( imsi sn , ck sn , ik sn , cap sn ) ;107 out ( pubChannel , (NASSMC, cap sn , cap sn , nonce ms sn,108 nonce mme, f inte g n as ( ( cap sn , cap sn ,109 nonce ms sn, nonce mme) , knasi nt sn ) ) ) ;110 i n ( pubChannel , (=NASSMComplete, msg nas: b i t s t r i ng ,111 = f in t eg nas (msg nas , knas in t sn ) ) ) ;112 i f c ap s n = t r u e then113 i f sdecrypt nas (msg nas , knasenc sn)114 = nas smcomplete msg then115 out ( sChannelSnBts , (kasme sn,116 imsi sn , cap sn ) )117 else 0118 e lse119 i f c a p s n = f a l s e then120 i f msg nas = nas smcomplete msg then121 out ( sChannelSnBts , (kasme sn,122 imsi sn , cap sn ) )123 else 0124 else 0 .125

    126 ( ∗process r ep resen t ing HN ∗ )127 l e t processHN =128 ( ∗R ec ei ve a u t h e n t i c a t i o n v e c t o r r e q ue s t ∗ )129 i n (secureChannel , (=AV REQ, imsi hn : iden t ) ) ;130 ( ∗Generate a f res h random number ∗ )131 new rand hn : nonce;132 ( ∗Computes expected response and Kc ∗ )133 ge t keys (= ims i hn , k i hn ) i n134 l e t mac hn : mac = f1 (k i hn , r and hn ) i n135 l e t x r e s h n : r e sp = f 2 ( k i h n , r an d h n ) i n136 l e t c k h n : c i ph e rK e y = f 3 ( k i h n , r an d h n ) i n137 l e t i k h n : i n te g Ke y = f 4 ( k i h n , r an d h n ) in138 ( ∗Send o u t a u t h e n t i c a t i o n v e c t o r ∗ )139 out ( secureChannel , (AV, imsi hn , rand hn ,140 x re s hn , c k hn , i k hn , m ac hn ) ) .

    This scenario is triggered by the TAU request, in addition to theIMSI and capabilities, the MS generates a nonce and sends it tothe MME (lines 34–35). The authentication vector request andresponse procedure is modeled in lines 93–96 and lines 129–140. The MME generates a nonce (line 100) and derivesthe K ASME using the nonces and cipher and integrity keys(lines 102–103). The MME then sends the integrity protectedNAS SMC messages which includes the received capabilitiesand both nonces in lines 107–109. Upon receiving the NASSMC messages, the MS derives the K ASME using the noncesand cipher and integrity keys as in MME (lines 45–46). TheMS then veries the MAC of the messages and sends out theNAS Complete messages to the MME. The AS SMC procedureis the same as in 4G model.

    Security Property Specications and Findings Theevents used to specify the authentication properties are speci-ed as:

    1 event begSN( ident , c ipherKey , integKey ) .2 event endSN( ident , c ipherKey , integKey ) .3 event begMS( iden t , cipherKey , integKey , bool ) .4 event endMS( iden t , cipherKey , integKey , bool ) .5 event begMS ENB( ide nt , enbKey, bool ) .6 event endMS ENB( ide nt , enbKey, bool ) .

    We specify the security properties as following:

    • Key Secrecy

    1 not a t t acke r (new k i ) .2 query a t tacker ( s ec re t ) .

    • Conditional Payload Secrecyquery a t tacker ( payload) event ( disableEnc ) .

    • Mutual Authentication between the MS and the MME1 query x 1 : i d e n t , x 2 : c ip he rK ey , x 3 : i n te g Ke y ;2 event (endSN( x1 , x2 , x3 )) 3 event (begSN(x1 , x2 , x3 ) ) .4 query x 1 : i d e n t , x 2 : c ip he rK ey , x 3 : i n te gK ey , x 4 : bool ;5 event (endMS( x1 , x2 , x3 , x4 )) 6 event (begMS(x1 , x2 , x3 , x4 ) ) .

    • Authentication of the BS to the MS1 query x 1 : i d e n t , x 2 : enbKey, x 3 : bool ;2 event (endMS ENB( x1 , x2 , x3 ) ) 3 event (begMS ENB(x1 , x2 , x3 ) ) .

    • Payload Secrecyquery a t tacker (payload ) .

    The analysis results are the same as the ones in 4Gauthentication (Section VI). ProVerif proves all the propertiesexcept the payload secrecy, because the BS could choose notto enable encryption when communicating with the MS.

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

    Figure 19 shows details of the ProVerif model and thelocations of the events which are used to specify the condi-tional payload secrecy and the authentication properties. Mostof the code in this model is inherited from the 4G model andthe GSM model. The MME uses the conversion function c3to derive the GSM session key from the UMTS cipher andintegrity keys:fun c3( cipherKey , integKey ) : gsmKey.

    There are four main processes in our model representing thebehavior of the MS, the BS, the SN and the HN respectively.

    1 ( ∗AS SMC procedur e in process MS ∗ )2 l e t pMSAS(kc ms: gsmKey, imsi ms : iden t , cap ms: bool ) =3 i n ( pubChannel , (=ASSMC, enableEnc as ms : bool ) ) ;4 event endMS AS(imsi ms , kc ms, cap ms) ;5 out ( pubChannel , CMComplete) ;6 i n ( pubChannel , (=MSG, datamsg: b i t s t r i n g ) ) ;7 out (pubChannel , sencrypt as ( secret , kc ms ) ) ;8 i f enableEnc as ms = t ru e then9 l e t msgcontent : b i t s t r i n g = sdecrypt as (datamsg , kc ms)

    10 i n 0 .11

    12 ( ∗process r e sp resen t ing MS ∗ )13 l e t processMS =14 ( ∗The i d e n t i t y o f t he MS ∗ )15 new imsi ms : i den t ;16 ( ∗Pre − shared key ∗ )17 new k i : k ey ;18 ( ∗ I n s e r t i d / p re − s ha re d key p a i r i n t o t he p r i v a t e t a b l e ∗ )19 i n s e r t k ey s ( i ms i m s , k i ) ;20 ( ∗MS non − d e t e r m i n i s t i c a l l y ch oo se 21 t h e c a p a b i l i t y o f e n c ry p t io n ∗ )22 l e t cap ms: bool = e n c C a p ab i l i t y ( ) i n23 out ( pubChannel , (CAP, cap ms ) ) ;24 out (pubChannel , ( ID , imsi ms ) ) ;25 i n (pubChannel , (=CHALLENGE, rand ms : nonce ,26 = f 1 ( k i , r an d m s ) , s n id ms : i d e n t ) ) ;27 l e t r e s ms : r e sp = f2 ( k i , r and ms) i n28 l e t ck ms : c iphe rKey = f3 ( k i , r and ms) in29 l e t i k ms : i n t egKey = f4 ( k i , r and ms) in30 l e t kasme ms: asmeKey = kdf asme(ck ms, ik ms , snid ms) i31 event begSN( imsi ms , snid ms , kasme ms) ;

    18

  • 8/19/2019 Authentication 2G 3G 4G

    19/39

    Fig. 19. Scenario S9+ annotated in accord with our model

    32 out ( pubChannel , (RES, res ms ) ) ;33 ( ∗NAS SMC pro ced ure ∗ )

    34 l e t knasenc ms : nasEncKey = kdf nas enc( kasme ms) in35 l e t knas int ms : nas IntKey = kd f nas in t (kasme ms) in36 i n ( pubChannel , (=NASSMC, enableEnc nas ms : bool , =cap ms,37 =f in teg nas ( ( enableEnc nas ms , cap ms) , knasint ms ) ) ) ;38 event endMS( imsi ms , snid ms , kasme ms, cap ms ) ;39 ( ∗NAS key secrecy ∗ )40 out (pubChannel , sencrypt nas ( secret , knasenc ms ) ) ;41 out (pubChannel , senc int nas ( secret , knasint ms ) ) ;42 l e t kc ms :gsmKey = c3 (ck ms , i k ms) i n43 i f enableEnc nas ms = fal se then44 out ( pubChannel , (NASSMComplete, nas smcomplete msg ,45 f inte g na s (nas smcomplete msg , knasint ms ) ) ) ;46 pMSAS(kc ms, imsi ms , cap ms)47 e lse48 out ( pubChannel , (NASSMComplete,49 sencrypt nas (nas smcomplete msg , knasenc ms) ,

    50 f inte g nas ( sencrypt nas (nas smcomplete msg ,51 knasenc ms) , knasint ms ) ) ) ;

    52 pMSAS(kc ms, imsi ms , cap ms) .5354 ( ∗process r ep resen t ing e − nodeB ∗ )55 l e t processBS =56 i n ( sChannelSnBts , ( kc bs : gsmKey,57 i m si b s : i de n t , c ap b s : bool ) ) ;58 event begMS AS( imsi bs , kc bs , cap bs ) ;59 out ( pubChannel , (ASSMC, cap bs ) ) ;60 i n (pubChannel , =CMComplete) ;61 i f c ap b s = f a l s e then62 event di sableEnc ;63 out ( pubChannel , (MSG, payload ) )64 e lse65 out ( pubChannel , (MSG, sencryp t as ( payload , kc bs ) ) ) .66

    67 ( ∗process repre sent i ng MME ∗ )

    19

  • 8/19/2019 Authentication 2G 3G 4G

    20/39

    68 l e t processSN =69 i n ( pubChannel , (=CAP, cap sn: bool ) ) ;70 i n ( pubChannel , (= ID , ims i sn : i den t ) ) ;71 new s n i d s n : i d e n t ;72 out ( secureChannel , (AV REQ, imsi sn , snid sn ) ) ;73 i n ( s ecureChannel , (=AV, imsi hn sn : i den t ,74 sn id hn sn : i den t , r and sn : nonce ,75 xres sn : resp , mac sn: mac, kasme sn: asmeKey,76 c k s n : c i p he r Ke y , i k s n : i n te g Ke y ) ) ;77 out ( pubChannel , (CHALLENGE, rand sn , mac sn , snid sn ) ) ;78 i n (pubChannel , (=RES, =xres sn ) ) ;

    79 event begMS( imsi hn sn , snid hn sn , kasme sn , cap sn ) ;80 ( ∗NAS SMC pro ced ure ∗ )81 l e t knasenc sn : nasEncKey = kdf nas enc(kasme sn) in82 l e t knas in t sn : nas IntKey = kd f nas in t (kasme sn ) in83 out ( pubChannel , (NASSMC, cap sn , cap sn ,84 f i n t eg nas ( ( cap sn , cap sn ) , knas in t sn ) ) ) ;85 i n ( pubChannel , (=NASSMComplete, msg nas: b i t s t r i ng ,86 = f in t eg nas (msg nas , knas in t sn ) ) ) ;87 l e t kc sn : gsmKey = c3 (ck sn , i k sn ) i n88 i f c ap s n = t r u e then89 i f sdecrypt nas (msg nas , knasenc sn) =90 nas smcomplete msg then91 event endSN( imsi hn sn , snid hn sn , kasme sn ) ;92 ou t ( sChannelSnBts , (kc sn , imsi hn sn , cap sn ) )93 else 094 e lse95 i f c a p s n = f a l s e then96 i f msg nas = nas smcomplete msg then97 event endSN( imsi hn sn , snid hn sn , kasme sn ) ;98 out ( sChannelSnBts , (kc sn , imsi hn sn , cap sn ) )99 else 0

    100 else 0 .101

    102 ( ∗process r ep resen t ing HN ∗ )103 l e t processHN =104 i n ( s ecureChannel , (=AV REQ, ims i hn : i den t , sn id hn : i den t ) ) ;105 ( ∗Generat e a then i ca t ion vec to r s ∗ )106 new rand hn : nonce;107 ge t keys (= imsi hn , k i hn ) in108 l e t mac hn : mac = f1 ( k i hn , r and hn ) i n109 l e t x r e s h n : r e sp = f 2 ( k i h n , r an d h n ) in110 l e t c k h n : c i ph e rK e y = f 3 ( k i h n , r an d h n ) i n111 l e t i k h n : i n te g Ke y = f 4 ( k i h n , r an d h n ) i n112 l e t kasme hn: asmeKey = kdf asme( ck hn , ik hn , snid hn) in113 out ( secureChannel , (AV, imsi hn , snid hn , rand hn ,114 x r es hn , mac hn , kasme hn , ck hn , i k hn ) ) .

    The authentication vector request and response procedure ismodeled in lines 72–76 and lines 104-114. The MME derivesthe GSM session key in line 87 and sends the key to the GSMBS in line 92 or 98 through the private channel between theMME and the GSM BS. The MS also computes the GSMsession key in line 42. The code of the GSM SMC procedure(lines 3–5 and lines 59–60) is inherited from the GSM model.

    Security Property Specications and Findings Since theGSM BS uses the GSM session key K c , the events used tospecify the authentication of the BS to the MS use this key asone of the parameters:

    1 event begMS AS( ide nt , gsmKey, bool ) .2 event endMS AS( ide nt , gsmKey, bool ) .

    The authentication properties between the MME and the MSare specied the same as the ones in the 4G model. We specifythe security properties as following:

    • Key Secrecy1 not a t t acke r (new k i ) .2 query a t tacker ( s ec re t ) .

    • Conditional Payload Secrecyquery a t tacker ( payload) event ( disableEnc ) .

    • Mutual Authentication between the MS and the MME

    1 query x 1 : i d e n t , x 2 : i d e n t , x 3 : asmeKey ;2 event (endSN( x1 , x2 , x3 )) event (begSN(x1 , x2 , x3 ) ) .3 query x 1 : i d e n t , x 2 : i d e n t , x 3 : asmeKey, x 4 : bool ;4 event (endMS(x1 , x2 , x3 , x4 ) )

    event (begMS(x1 , x2 , x3 , x4 ) ) .

    • Authentication of the BS to the MS1 query x 1 : i d e n t , x 2 : gsmKey, x 3 : bool ;2 event (endMS AS( x1 , x2 , x3 ) )

    event (begMS AS(x1 , x2 , x3 ) ) .

    • Payload Secrecyquery a t tacker (payload ) .

    All the keys are proved to be remained secret. The conditionalpayload secrecy also holds, that means, if the encryption isenabled, the content of the encrypted data messages cannot belearned by the attacker. The mutual authentication propertiesbetween the MS and the MME are proved. However, becausethe BS is the GSM BS, the CMC attack is found whenchecking the authentication of the BS to the MS. As in othermodels, the payload secrecy could be violated because the BScould choose to disable encryption when communicating withthe MS.

    S10+. UMTS I LTE II–IV UMTS IV, AV = 4G AV + CK + IK

    Figure 20 shows details of the ProVerif model and thelocations of the events which are used to specify the condi-tional payload secrecy, authentication properties. Most of thecode in this model is inherited from the 4G model and theUMTS model. There are four main processes in our modelrepresenting the behavior of the MS, the BS, the SN and theHN respectively.

    1 ( ∗AS SMC procedur e in process MS ∗ )2 l e t pMSAS(ck ms: c ipherKey , ik ms : integKey ,3 ims i ms : i den t , c ap ms : bool ) =4 i n ( pubChannel , (=ASSMC, =cap ms , enableEnc as ms : bool ,5 =f9 (( cap ms, enableEnc as ms) , ik ms ) ) ) ;6 out ( pubChannel , (ASSMComplete, as smcomplete msg ,7 f9 (as smcomplete msg , ik ms ) ) ) ;8 event endMS AS(imsi ms , ck ms, ik ms , cap ms );9 i n ( pubChannel , (=MSG, datamsg: b i t s t r i n g ,

    10 =f 9 (datamsg , ik ms ) ) ) ;11 out (pubChannel , sencrypt as ( secret , ck ms ) ) ;12 out (pub