A formal analysis of authentication protocols for mobile devices in next generation networks

CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCEConcurrency Computat.: Pract. Exper. (2014)Published online in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/cpe.3260

SPECIAL ISSUE PAPER

A formal analysis of authentication protocols for mobile devices innext generation networks

Mahdi Aiash*,†

School of Science and Technology, Middlesex University, London, UK

SUMMARY

Next Generation Networks comprise a wide variety of access technologies such as 2G/3G, WLAN as well asthe Long-Term Evolution (LTE) networks. In this environment, mobile devices are expected to store sensitivedata and represent users to access the underlying networks and connect to a wide variety of sensitive servers.It is crucial, in this sense, for end users to trust their mobile devices and for all transactions using themto be secure. Therefore, a number of communication frameworks in Next Generation Networks have beenworking on designing device authentication protocols that achieve mutual authentication between users andmobile terminals. This paper analyses some of these protocols and introduces two new device authenticationprotocols, verifies them using formal methods approach and discusses how they achieved desired securityproprieties. The performance analysis highlights another advantage of the proposed protocols. Copyright ©2014 John Wiley & Sons, Ltd.

Received 31 January 2013; Revised 5 February 2014; Accepted 15 February 2014

KEY WORDS: device authentication protocols; Casper/FDR; formal methods; authentication and keyagreements protocols

1. INTRODUCTION

The concept of Next Generation Networks (NGNs) has initially been proposed to provide mobileusers with an anywhere, any time connectivity to end servers; NGNs represent an architecture inwhich two different domains need to cooperate in order to provide ubiquitous connectivity. Thefirst is the network operators domain, where multiple network operators share the core network toprovide network accessibility over a wide variety of wireless technologies such as WiFi and mobilenetwork technologies. The other is the application service providers (SPs) domain, which launchesvarious services ranging from the normal video-streaming to the most confidential e-commerceservices. In order for end-users or clients to obtain these services, they need to identify and authen-ticate themselves to the network operators as well as to the application service providers. In thisenvironment, mobile terminals (MTs) will become part of the authentications procedures and act onbehalf of end users when accessing underlying networks or contacting end servers.

This discussion highlights the fact that any efficient security solution for heterogeneous networkshas to consider the security in the different domains. Therefore, a number of communicationframeworks in NGNs such as the Mobile Ethernet and Y-Comm [1, 2] have proposed deployinga multilevel Authentication and Key Agreement (AKA) framework. The framework providesauthentication and key agreement at the Device, Service and Network levels as shown in Figure 1.The device-level AKA comprises two substages: the first achieves mutual authentication betweenthe SIM/personal ID card (PIC) and the MT. In the second, the user is authenticated, based on his

*Correspondence to: Mahdi Aiash, School of Science and Technology, Middlesex University, London, UK.†E-mail: [email protected]

Copyright © 2014 John Wiley & Sons, Ltd.

M. AIASH

Figure 1. The Authentication and Key Agreement (AKA) Framework.

biometric information, to use the mobile terminal. The network-level AKA (NL-AKA) achievesmutual authentication between the network and the mobile terminal when the MT joins the net-work for the first time [3], secure handover could be achieved using mechanisms such as [4, 5]. Theservice-level AKA (SL-AKA) authenticates the MT to access the subscribed service over variousaccess networks [6].

While the network and service AKA protocols have been introduced in different works suchas [4, 6], this paper only considers the device-level AKA protocol. Hence, it discusses differentchallenges and solutions for device authentication, and it also analyses a number of device authen-tication protocols proposed by NGN communication frameworks such as the ones proposed by theMobile Ethernet [24] and the Authentication framework in [7]. Based on the analysis, two deviceauthentication protocols are introduced. The proposed protocols achieve mutual authentication andset up a secure connection between the MT and the PIC, which holds security and subscriptioninformation. The proposed protocols are verified using Casper/failure divergence refinement (FDR)compiler [8], which is a formal methods-based approach that accepts an abstract description of sys-tems and translates them into Communication Sequential Processes (CSP) [9], and the generatedCSP description is then verified using the FDR model checker [10]. Furthermore, the proposedprotocols will be analysed against a number of desired security properties.

The rest of this paper is organized as follows. Section 2 defines the problem of device authen-tication in NGNs. Section 3 briefly explains the factors considered when designing authenticationprotocols in general, and it also describes our approach to formally verify the security protocols.Section 4 considers the research efforts by some NGNs communication frameworks to providedevice-level authentication. Section 5 introduces the two proposed protocols, describes the formalanalysis procedure of the protocols and analyses their security properties. The section also comparesthe proposed protocols to the ones in the literature. A comparison discussion in terms of secu-rity and performance between the discussed protocols is given in Section 6. The paper concludesin Section 7.

2. PROBLEM DEFINITION

For communication in NGNs, highly developed mobile devices will enable users to store andmanage a lot of credentials on their terminals. Furthermore, these terminals will represent andact on behalf of users when accessing different networks and a wide variety of services such ase-Commerce, online banking and electronic public services in addition to access to email, Grid andCloud resources/services. To access these services, end users might need to submit information suchas passwords, secret keys, digital certificates via their devices to end servers before acquiring theservices. To address security in this environment, there is a need to provide security between mobile

Copyright © 2014 John Wiley & Sons, Ltd. Concurrency Computat.: Pract. Exper. (2014)DOI: 10.1002/cpe

A FORMAL ANALYSIS OF AUTHENTICATION PROTOCOLS FOR MOBILE DEVICES IN NGNs

terminals and access networks from on side, and between the terminals and end servers on the otherside. However, because the mobile terminal will be representing the user in these transactions, thisimplies the need for securing transactions between the end users and their mobile terminals as wellmaintaining the integrity of the mobile terminals. Creating such a secure environment will empha-size on the trust worthiness of mobile devices and encourage end users to delegate their devicesthe communication with sensitive services. The paper considers this latter issue and proposes twodevice authentication protocols.

3. DESIGNING AND VERIFYING AUTHENTICATION PROTOCOLS

3.1. User authentication on mobile devices: challenges and solutions

Generally, authentication protocols consider three main authentication factors: something youknow, something you have, and something you are. While these factors are not unique to mobiledevices, we will discuss them in the context of device authentication.

3.1.1. Something you know. A secret value is shared between two entities and used to achieveauthentication. This approach is used in password-based authentication protocols as well as ImageBased Authentication (IBA) [11–13].

While password-based authentication protocols are one of the most popular approaches thatapplications (not just mobile applications) use today to provide security if devices are borrowed orstolen, this approach requires users to use a complex password, which is not easy to break. Enteringa complex password might be difficult on mobile devices; therefore, users might choose to save thepassword as a plain text in a normal text file, enter a simple password instead or use a third partypassword manager application.

To deal with the shortages of password-based, IBA has been proposed. The process of authenti-cating in IBA involves (1)selecting at least one image that depicts one or more categories with whichthe user should be familiar such as (cars, animals and furniture), where the image is stored persis-tently on the device, (2) displaying the image. When authentication is required, the device displaysa grid of images that are randomly selected from a large pool of images. The user is asked to selectthe images related to his/her chosen categories.

While the IBA dealt with the issue of using a weak password, the approach, on its own, is stillvulnerable to brute force attack, for instance, choosing four categories in a 4�4 grid only permits16Š=4Š D 1820 and choosing four categories in a 5�5 grid permits 25Š=5Š D 53130. To deal withthis issue, there is a need to set a limit of failed authentication attempts after which the user has togo through the initial setup again.

3.1.2. Something you have. A user somehow proves the possession of something external to thesystem, such as hardware or software tokens that generate one-time passwords as in RSA SecurIDor ActivIdentity OTP Token [14, 15]. Regardless of the type of hardware token used, these schemesrely on the following:

� Cryptographic operations are performed in a secure environment that is very unlikely to getinfected with malware.� The hardware tokens include physical and software-based protection mechanisms that make

them very difficult to clone.

One major issue in this factor is that the authentication token needs to be securely generated andexchanges. Therefore, extra security measures are needed to check the integrity of the system andmaking sure that the token could not be intercepted.

3.1.3. Something you are. This authentication factor uses biometrics to authenticate users. Typicalbiometrics used to authenticate users (not just on mobile devices) include facial features, speechpatterns, fingerprints, iris patterns, etc. Unlike other authentication mechanisms based on ‘somethingyou know’ and ‘something you are’ that can be verified using exact matches, biometrics require


M. AIASH

Table I. The headers of CASPER’s input file.

The header Description

# Free variables Defines the agents, variables and functions in the protocol# Processes Represents each agent as a process# Protocol description Shows all the messages exchanged between the agents# Specification Specifies the security properties to be checked# Actual variables Defines the real variables, in the actual system to be checked# Functions Defines all the functions used in the protocol# System Lists the agents participating in the actual system with their parameters instantiated# Intruder information Specifies the intruder’s knowledge and capabilities

complex algorithms for matching that can generally be tuned for false accept/false reject rates [16].Therefore, this factor is usually used in a combination with the other factors.

3.1.4. Verifying security protocols using Casper/FDR. The proposed protocols are verified usingformal methods based on CSP [9], which is a formal language to describe the interactions and statesin concurrent systems, it has been used to model communicating and security protocols as in [4, 17,18] and [19]. To verify the CSP models, model checkers such as the FDR [10] is used. Althoughmodelling and verifying security protocols using CSP and FDR have proven to be effective andwidely deployed, modelling directly in CSP is a time-consuming and error-prone. Therefore, a newcompiler for generating the CSP description of the protocol was designed by Lowe in [8]. Thenew complier is called Casper, and it accepts an abstract description of a system and translates itinto CSP. This paper will model the security properties of the proposed protocols using Casper andanalyse the CSP output with FDR. The CASPER’s input file that describes the systems consists ofeight headers as explained in Table I.

Furthermore, as stated in [20], it is desired for AKA protocols to meet certain security properties.Therefore, a list of these properties will be used to analyse the security features of all the proposedAKA protocols. The properties are as follows:

1. Mutual Entity Authentication: This is achieved when each party is assured of the identity ofthe other party.

2. Mutual Key Authentication: This is achieved when each party is assured that no other partyaside from a specifically identified second party gains access to a particular secret key.

3. Mutual Key Confirmation: This requirement means that each party should be ensured that theother has possession of a particular secret key.

4. Key Freshness: A key is considered fresh if it can be guaranteed to be new and not reusedthrough actions of either an adversary or authorized party.

5. Unknown-Key Share Resilience: In this attack, the two parties compute the same session keybut have different views of their peers in the key exchange. In other words, in this attack, anentity A ends up believing she shares a key with B, although this is the case, B mistakenlybelieves the key is instead shared with an entity E 6D A.

6. Key Compromise Impersonation Resilience: This property implies that if the Intruder compro-mised the long-term key of one party, he should not be able to masquerade to the party as adifferent party.

3.1.5. Usability of authentication protocols in constrained devices.

4. DEVICE AUTHENTICATION PROTOCOLS IN NGNS

Future mobile devices are expected to access different networks (such as 3rd generation network,WLAN, Bluetooth, Internet, and etc). Hence, many sensitivity data are stored in them. Unfortu-nately, the password-based identification is not secure enough to control user’s access to the mobileterminal and vulnerable to birthday and brute force attack. This section describes some of research



efforts by a number of NGNs frameworks to address the authentication between the MT, the PICand the User.

4.1. The authentication and authorization scheme

The authors in [7] propose an AKA and authorization framework for 4G networks. At the initialstage, the framework combines password, biometric information as well as public key infrastructure(PKI) to achieve mutual authentication between the user, the SIM card and the device. In thatsense, the framework combines all the three authentication factors as defined in Section 3.1. Also,the result of the authentication in the initial stage, the framework achieves authentication betweenthe mobile device and the network. Although it is stated in [7] that the framework was proven tobe scalable and provides some desired security features such as multi-pronged mutual authentica-tion, the framework suffers from two major drawbacks: firstly, in order to provide a considerablyrobust platform for user’s access to sensitive services and data and achieve the authentication pro-cess in the initial stage, the framework associates the Trusted Computing (TC) with the PKI byimplementing Trusted Mobile Platform (TMP) [21]. These represent major modification to thearchitecture of mobile devices. Secondly, some of the required functions is based on asymmetriccryptography such as PKI. However, the unsuitability of PKI for mobile devices has been high-lighted in different research work. In [22], the authors argue that the resources required to performasymmetric key operations and to transmit large messages may result in unacceptable performanceresult and intolerable user authentication response times. Additionally, it is stated that traditionalauthentication methods that are based on public key cryptography are not suitable for networksof low powered devices because public key cryptography involves intensive computation [23].These two reasons make the framework inapplicable with current architecture and capabilities ofmobile devices.

4.2. The device authentication protocol of the mobile ethernet security framework

Mobile Ethernet Architecture is a Beyond 3G network system for the all IP integrated network usingMAC layer technologies [1]. The architecture is based on the Wide Area Ethernet (WAE), which isa virtual private network aimed at providing connectivity based on the Ethernet (MAC) addressingand thus achieves interoperability among different IP-based operators. The Mobile Ethernet grouphas in [24] proposed an AKA framework that deals with security at the network and service levelsas well as achieving mutual authentication between the user, the PIC and the mobile terminal. Thesecurity system comprises the following entities:

� The PIC: Similarly to the SIM card in 2, 2.5 and 3G technologies, the PIC holds user’scredentials such as the subscribed services’ IDs and security keys.� The MT: Is the user’s device.

As described in [19], Casper/FDR has been used to verify the AKA protocol of the MobileEthernet framework. The protocol was found to be vulnerable to a replay attack in which, theintruder intercepts and relays the messages between the MT and the PIC.

Furthermore, the AKA protocol of the Mobile Ethernet follows the ‘something you know’approach because the authentication process was based on the assumption that the PIC and the MTpre-shared a secret key K. This key acts as an authentication and session key; no short-term sessionkey is derived, which puts the security of the whole system at risk.

5. THE PROPOSED DEVICE AUTHENTICATION PROTOCOLS

In order to address the shortages of the authentication protocols in Section 4, two novel protocolsare proposed in this section. The proposed protocols will be verified using Casper/FDR and thenanalysed against a set of the desired security properties, described in Section 3.1.4.

Setting up a PKI is a complex and costly process that consists of several steps: users registra-tion, keys generation and certificates issuance and distribution. Additionally, PKI involves othercomplex processes such as certificate retrieval and certification path construction and validation.


M. AIASH

Consequently, it becomes widely accepted that symmetric encryption is more suitable for light-weight security protocols in constrained devices [25, 26]. Therefore, the proposed protocols in thispaper will be based on a symmetric encryption.

5.1. The first proposed protocol

The proposed protocol comprises two stages: the first achieves mutual authentication between thePIC and the MT, while in the second, the user is authenticated based on his biometric information.By considering the notations in Table II, the AKA protocol for the MT, PIC authentication is basedin the Challenge-Response paradigm, and it runs as follows:Msg1: PIC !MT: {r1, Pseq, h(r1, Pseq)}{SK(MT)}Upon plugging the PIC into the MT, the AKA process starts by sending a random number r1 inMsg1. The MT will also derive the key (K) as : K= F(SK(MT), r1, r2, miD, PSeq).Msg2: MT ! PIC: {MiD, r1, r2, h(MiD, r1, r2)}{SK(MT)}The MT constructs a challenge message Msg2 containing a mobile ID, a fresh challenge randomr2 and the received random r1, this message is encrypted by the pre-shared key SK(MT). Using theinformation included in Msg2, both ends generate a secret key K= F(SK(MT), r1, r2, miD, PSeq) tosecure the connection between the ends, the uniqueness of the derived key is based on the freshnessof nonce r1, r2 and the secrecy of the pre-shared key SK. Upon receiving this message, the PIC willderive the key (K): : K= F(SK(MT), r1, r2, miD, PSeq).Msg3: PIC! MT:{r3,r2, h(r3,r2)}{K}The PIC responds to the challenge in Msg2 by constructing Msg3 which contains the receivedchallenge random r2 and another challenge random number r3, this message is encrypted using thederived secret key K.Msg4: MT! PIC:{r3, Ackm, h(r3, Ackm)}{K}The MT responds by sending Msg4, which includes the received challenge r3 along with thepre-shared acknowledgement string (Ackm), which acts as an authentication token. As shown inTable II, the Ackm is derived in a way to include the identities of the two parties (the MT and thePIC), also it includes fresh random values (r1, r2) to guarantee the freshness, this way possessingthe Ackm will help in achieving entity authentication as will be described in Section 5.1.2.Msg5: PIC ! MT:{Ackm, h(Ackm)}{K}The PIC verifies the included Ackm in Msg4 and composes Msg5. It’s worth pointing out that theauthor believes that the majority of current hashing and symmetric encryption mechanisms couldbe used in the proposed protocol. However, discussing the implementation of these mechanisms ordesigning new ones is beyond the scope of this paper. Furthermore, the key derivation function (F)is not defined in this paper; however, functions such as the one proposed in [5] could be used.

Table II. The notation.

Abbreviation Full name and description

PIC The personal identification card (PIC), initially shares SK(MT) with the MT andholds the (UK)

MT Mobile terminalh A hash function such as MD5 or SHA-1 to maintain messages integrityr1, r2, r3 Random numbersmiD Mobile device unique IDK A secret key derived to secure the connection between the MT and the PIC,

whereas K= F(SK(MT), r1, r2, miD, PSeq)SK(MT) A pre-shared key between the PIC and the MTPSeq PIC unique sequence numberF An irreversible key derivation functionF1 A pseudorandom functionAckm An authentication token: Ackm= F1( MiD, PSeq, r1, r2){m}{K} Encrypting the message (m) using the key (K)



5.1.1. Formal verification. We modelled our protocol by preparing a Casper input file describingthe UL-AKA protocol. For conciseness, we only show here the # Specification and # Intruderheadings, while the # Free Variables, # Protocol Descriptions and # System headings are includedin Appendix A. The # Free variables heading defines the participating parties, the variables andthe used functions. It is worth noting that Casper does not specify a built-in method to simulatekey derivation functions; therefore, we specifically defined therein the function F, which is used toderive the session key (K) specific. The Protocol Description heading specifies how the intendedparties will use the functions to generate the corresponding keys. The security requirements of thesystem are defined under the # Specification heading. The lines starting with the keyword Secretdefine the secrecy properties of the protocol. For example, the first line specifies SK(MT) as a secretbetween the PIC and MT. The lines starting with Agreement define the protocol’s authenticityproperties; thus, the first authenticity check specifies that the MT is correctly authenticated to thePIC and agreed on the nonce value (r3). The WeakAgreement(X,Y) specification means that if Ythinks he has successfully completed a run of the protocol with X, then X has previously beenrunning the protocol with Y.

# SpecificationSecret(PIC,SK(MT),[MT])Secret(MT,SK(MT),[PIC])Secret(PIC,miD,[MT])Secret(PIC,K,[MT])Secret(MT,K,[PIC])Agreement(MT,PIC,[r3])Agreement(PIC,MT,[r2])WeakAgreement(MT, PIC)WeakAgreement(PIC, MT)

The # Intruder Information heading shows that the intruder identity is Mallory, the identitiesof all agents, the nonce R1 and the function F are included in the intruder initial knowledge. TheCrackable keyword is used to simulate key compromise attack, where a key is compromised eitherthrough cryptographic techniques, or through the key being stolen and then used to lead to a failureof authentication in a subsequent session. We specify the pre-shared key SK as compromisable.

# Intruder InformationIntruder = MalloryIntruderKnowledge = {PICard, Mobile, R1, F}Crackable = presharedKeys

Running Casper/FDR tool verifies that none of the checked assertions defined in the #Specification heading was vulnerable to an attack as described in [19].

5.1.2. Protocol analysis and security considerations. Although Casper/FDR has shown no attackagainst the proposed protocol, we need to carefully consider the result, Casper/FDR proves theprotocol in the system specified in the #System heading Appendix A; however, the protocol mightbe vulnerable in another system. Further analysis of the protocol based on the security requirementlist is given in this section.

� Mutual Entity Authentication: There is no direct specification within Casper to check thisproperty, yet in order to show how our protocol could meet this requirement, we explicitlyconsidered the Ackm value is generated as follows: Ackm= F1(MiD, PSeq, r1, r2). This value ispre-stored in the PIC and Mobile terminal. In Msg4 and 5, each entity ensures the other party tohave the right Ackm, which includes the parties’ identities as parameters, thus enforcing entityauthentication. If the MiD and Pseq were exposed, it is not feasible for the Intruder to generatethe Ackm, because it does not know the right random value. Even if the Intruder recordedMsg5, it could not be used in next sessions because a fresh key K is used for each session.


M. AIASH

� Mutual Key Authentication: The mutual authentication between the MT and the PIC is basedon the secrecy of the derived session key (K). We got Casper to check this using the Secret(PIC, K, [MT]) assertion check.� Mutual Key Confirmation: This requirement is achieved by performing the checks after Msg3

and 4 in the Protocol Description heading Appendix A. By using the Decryptable function,each party makes sure that the valid secret key K is possessed by the other part. If any of thecheck failed, the protocol aborts.� Key Freshness: Casper does not have any function to check this requirement, so we included

freshly generated values r1, r2 in the derivation function of the session key K: KDF(SK(MT),r1,r2,miD,PSeq); thus, the fact that Casper does not detect any attack on the secrecyof the session key (K) implies that key freshness is not violated.� Unknown-Key Share: The WeakAgreement assertion is used to check this attack. Additionally,

making a binding between the Keys and the parties’ identity deals with this attack. This hasbeen achieved in this protocol by including the identities of the MT and the PIC in the KeyDerivation Function (KDF) of the K.� Key Compromise Impersonation Resilience: We modelled this requirement by specifying the

long-term keys as crackable and using the Agreement assertion to check any breach of theauthenticity feature. However, this property will be analysed in more detailed in the followingsubsection.

5.1.3. Analysing the key compromise impersonation resilience property. The key mentioned afterthe Crackable keyword will be compromised and passed to the Intruder when all agents whoseruns overlap in time with any agent using that key have finished their runs [8]. Our proposedprotocol was not vulnerable to this attack, because there was no overlapping among the agents’runs. However, to be very exhaustive, we simulate the case when the Intruder has managed tocompromise the SK(MT)—either in a previous run or in the current one—by adding the SK(MT)to the Intruder Knowledge as shown in the succeeding text:# Intruder InformationIntruder = MalloryIntruderKnowledge = {PICard, Mobile, R1, F, SK(MT)}Crackable = presharedKeys

The following attacks have been discovered:

� The first attack is against the secrecy of the derived key (K), which is specified infirst two assertions in the # Specification, namely Secret(PIC,SK(MT),[MT])andSecret(MT,SK(MT),[PIC])The discovered attack goes as follows:

0. -> PICard : Mobile1a. PICard -> I_Mobile : {R1, PSEQ,h(R1, PSEQ)}{SK(Mobile)}1b. I_PICard -> Mobile : {R1, PSEQ, h(R1, PSEQ)}{SK(Mobile)}2a. Mobile -> I_PICard : {MID, R2, R1, h(MID, R2,R1)}{SK(Mobile)}2b. I_Mobile -> PICard : {MID, R1, R1, h(MID, R1,R1)}{SK(Mobile)}3. PICard -> I_Mobile : {R1, R3, h(R1, R3)}{Knew}The intruder knows K,Knew

The notation I_ PICard, I_ Mobile represents the case where the Intruder impersonates thePIC and Mobile, respectively. As shown in the attack messages. The Intruder intercepts Msg1and replays it to the MT as Msg1b. However, after intercepting Msg2a, the Intruder replacesR2 with R1 and replays it towards PICard as Msg2b. In this way, the PICard will not be ableto derive the same key (K)—derived by the Mobile—because it has not received R2 in Msg2b.



The PICard derives a different value of the key (K), referred to as Knew , and uses it to encryptMsg3, which will be intercepted by the Intruder again, because the Intruder can derive bothvalues (K) and (Knew ); he possesses all the required parameters, the Intruder will launch anactive man-in-the-middle attack between the PICard and the Mobile.� The second discovered attack is against the Agreement(PIC,MT,[r2,Ackm, K]),WeakAgreement(PIC, MT) assertions, and it goes as follows:

0. -> PICard : Mobile1a. PICard -> I_Mobile : {R1, PSEQ, h(R1, PSEQ)}{SK(Mobile)}1b. I_PICard -> Mobile : {R1, PSEQ, h(R1, PSEQ)}{SK(Mobile)}2a. Mobile -> I_PICard : {MID, R2, R1, h(MID, R2,R1)}{SK(Mobile)}2b. I_Mobile -> PICard : {MID, R2, R1, h(MID, R2,R1)}{SK(Mobile)}3a. PICard -> I_Mobile : {R2, R3, h(R2, R3)}{K}3b. I_PICard -> Mobile : {R2, R3, h(R2, R3)}{K}4. Mobile -> I_PICard : {ACKM, R3, h(ACKM, R3)}{K}5. I_PICard -> Mobile : {ACKM, h(ACKM)}{K}

In this attack, the Intruder intercepts and replays messages 1, 2 and 3, and upon receivingMsg4, he will decrypt the message and compose Msg5 acting as the PICard. In this attack, theMobile will complete a run of the protocol believing it is with PICard while in reality it is withthe Intruder.

5.1.4. Biometric information based authentication. For the second stage of the protocol, we assumethat the Mobile terminal is equipped with a trusted biometricinformation reader such as finger-print reader. When the user makes the initial contract, a brief hashed value of the user’s biometricinformation is stored in the PIC. This hashed value could be generated using algorithms like [27, 28],which have been designed to provide similarity preserve and eliminate any noise in the biometricsample. After running the previous AKA protocol and setting up a secure channel between the MTand the PIC, the user is prompted to enter his biometric information, the MT processes the data andgenerates a hashed value of the submitted info. This hashed value is passed to the PIC, which com-pares it with the previously stored value. In case of match, the user is authenticated as the PIC ownerand consequently to use the MT.

5.2. The second proposed protocol

The first proposed protocol in Section 5.1 is of the challenge-response type and is based on onesecret key SK(MT), which is pre-shared between the MT and PIC. Generally speaking, challenge-response protocols are vulnerable to replay attacks. To avoid such attacks the proposed protocolin Section 5.1 uses three random numbers r1, r2 and r3. Furthermore, in order to meet some ofthe desired security requirements such as the mutual entity authentication, the authentication tokenAckm is used in the protocol as explained in section 5.1.2. Another possible way to stop replayattacks is by using different keys to encrypt the messages in the two directions. Based on this, wepresume that MT has the SK(MT), which is shared with the PIC and can derive a fresh secret key(K): K= F(SK(MT),r1, miD, PSeq). Using the same notations in Table II, the second proposedprotocol goes as follows:Msg1: MT ! PIC : {r1,K, miD h(r1,k, miD)}{SK(MT)}Msg2: PIC ! MT : {r1, r2, PSeq, h(r1,r2, PSeq)}{K}Msg3: MT ! PIC : {r2,h(r2)}{K}

Similar to the protocol in Section 5.1, the PIC and the MT will share a secret key SK(MT), theMT will derive a secret key (K) and includes it in Msg1. The PIC will use this key to encrypt Msg2,


M. AIASH

which includes the nonce r1 and a nonce challenge r2. The MT will respond to the challenge sent inMsg2 as shown in Msg3.

5.2.1. Formal verification. A Casper input file describing the protocol was prepared, the whole fileis included in Appendix B. In the #Specification heading, we define the security assertions to bechecked as follows:#SpecificationSecret(PIC, K, [MT])Secret(MT, K, [PIC])Secret(PIC,r2,[MT])Secret(PIC,r1,[MT])Agreement(MT,PIC,[r2,K])Agreement(PIC,MT,[r1, K])WeakAgreement(MT, PIC)WeakAgreement(PIC, MT)

As specified in the Agreement assertions, the MT is authenticated to the PIC by returning thenonce r2 encrypted with the secret key (K), while the PIC is authenticated to the MT by returningthe r1 encrypted with the key (K).

The Intruder’s capability is defined in the #Intruder Information heading. So, the Intruder knowsthe identities of all participants as well as the function (F), used to derive the secret key (K).#Intruder InformationIntruder = MalloryIntruderKnowledge = {PICard, Mobile, F}Crackable = presharedKeys

After compiling the input file using Casper and checking it with FDR, no attacks have beendiscovered.

5.2.2. Protocol analysis and security considerations. This section analyses the proposed securityprotocol against the security requirement list in Section 5.1.2.

� Mutual Entity Authentication: Unlike the first proposed protocol 5.1, which used the Ackmto meet this requirement, this protocol does not fulfil the requirement because there is noinformation that could verify the identity of participating parties.� Mutual Key Authentication: The mutual authentication between the MT and the PIC is based

on the secrecy of the derived secret key (K). We got Casper to check this using the Secret (PIC,K, [MT]) assertion check.� Mutual Key Confirmation: This requirement is achieved by performing the checks after Msg2

and 3 in the Protocol Description heading Appendix B. By using the Decryptable function,each party makes sure that the valid secret key K is possessed by the other part. If any of thechecks failed, the protocol aborts.� Key Freshness: Because Casper cannot check this requirement, the only way to fulfil it is by

including freshly generated information (random numbers and time stamps) in the key deriva-tion function of the secret key (K): K= F(SK(MT), r1 , miD, PSeq). Because a new randomnumber (r1) will be used to derive (K), we could claim to meet this requirement.� Unknown-Key Share Resilience: The WeakAgreement assertion is used to check this require-

ment, because no attacks found, this means that the requirement has been fulfilled.� Key Compromise Impersonation Resilience: The compromise of the SK(MT) will expose

Msg2, which will lead to compromising the secret key (K).

5.3. Security considerations

The proposed protocols are cryptographic protocol that achieves mutual authentication and keyagreement, based on symmetric encryption and biometric information, between three entities: the



PIC, the MT and the end user. Sections 5.1.2 and 5.2.2 explain how the proposed protocols certainsecurity properties based on the formal verification conducted using Casper/FDR tool. This sectionwill analyse how the proposed protocols fulfil further requirements of AKA security

5.3.1. Passive attacks. We say that an AKA protocol is secure against passive attacks if anadversary who merely observes honest entities carrying out the protocol, fails to derive a sessionkey, which was authenticated and agreed by the honest entities.

� The First Proposed Protocol: The protocol is secure because the messages 1 and 2,eavesdropped by a passive attacker, do not reveal the corresponding session key K, becausethey are encrypted with key SK(MT) and the secure one-way hash function.� The Second Proposed Protocol: Similar to the first protocol, eavesdropping message 1 by an

attacker will not lead to exposing the secret key K, because of same reasons.

5.3.2. Active attacks. We say that an AKA protocol is secure against active attacks if an adversarywho controls the protocol messages, for example, by injection, interception, replay, and/or modi-fication, fails to subvert the communications of the honest entities. We will discuss the followingpossible active attacks:

� Impersonation of Entity: In either protocol, to impersonate the PIC, an attacker needs to provethe possession of two secrets: the PSeq and the SK(MT). Similarly, to impersonate the MT, anattacker needs to possess the MID and the SK(MT). The security of the system in this situationis related to the secrecy of the SK(MT). Furthermore, the first proposed protocol achievesmutual entity authentication by using the Ackm as discussed in Section 5.1.2.� Man-in-the-middle attack: In order to reside as a middle man in the protocol, an adversary

should enforce a fresh secret key K. However, because the integrity as well as the confidentialityof the exchanged message are preserved using encryption and hashing functions, an adversarycould only passively relay the messages without being able to reveal any information.

5.4. Comparing the two proposed protocols

As shown in Table III, the first proposed protocol combines the three authentication factors asdefined in Section 3.1. The first stage of the protocols follows the ‘something you know’approachbecause a secret key SK(MT) is pre-shared between the PIC and MT. It also uses the ‘somethingyou have’, because authentication is based on the ability of the PIC and MT to derive the sessionkey (K). The second stage of the protocol is based on ‘something you are’ approach and is usedto compliment the first stage. While the second proposed protocol is based on the ‘something youknow’ factor as well as the ‘something you are’.

Both proposed protocols have been successfully verified. However, the second protocol inSection 5.2 requires one of the parties (the MT) to manage two keys, one is pre-shared with theother party (the PIC) and will be used to encrypt the first message. The second key is sent in the firstmessage to the second party and will be used to encrypt the rest of the messages. Furthermore, somesecurity requirements such as mutual entity authentication and the resilience to key compromiseimpersonation attack are not achieved.

The following table compares between the two proposed protocols:

Table III. Comparing between the two proposed protocols.

The security property The first AKA The second AKA

Mutual entity authentication Yes NoMutual key authentication Yes YesMutual key confirmation Yes YesKey freshness Yes YesUnknown-key share Yes YesKey compromise impersonation resilience Yes No


M. AIASH

6. COMPARATIVE DISCUSSION

6.1. Security discussion

The discussion in Section 3.1 shows that each of the three authentication factors has it is ownadvantages and disadvantages. It also argues that different factors compliment each other towards amore secure system. Section 4 discusses two device authentication protocols used with communica-tion framework in NGNs. This section will compare between these protocols and the ones proposedby this paper.

The authentication protocol in [7] adopted a combination of the three authentication factors byusing Password-based authentication, PKI and biometric-based authentication. While the analysis ofthe protocol as discussed in [7] proves its validity. However, as discussed in Section 4.1, the securityof the protocol is based on the implementation of TMP hardware, the protocol also is based on PKIinfrastructure. the main drawback of the protocol is its complexity which makes it unsuitable forconstrained devices.

The Mobile Ethernet’s AKA protocol has presumed a symmetric key to be pre-shared betweenthe PIC and the MT. Hence, the protocol is based on the “Something You Have” factor. In a previouswork, we analysed this protocol and found it vulnerable to a Man-in-The-Middle Attack as explainedin [19].

The proposed protocols in this paper, combined the three authentication factors by using a pre-shared symmetric key, freshly derived session key and using biometric authentication to identifythe end user. The protocols have been formally checked using Casper/FDR. A summary of thiscomparison is found in Table IV.

6.2. Performance discussion

Although the main contribution of this paper is in highlighting security threats in current deviceauthentication protocols for NGNs, we will briefly compare our proposed protocols to the othersdiscussed in Section 4 with regards to the computational loads.

To compare the performance of the discussed protocols, we use the metric proposed in [7] whichinvolves the following elements: The numbers of public key encryption (PKE), public key decryp-tion (PKD), symmetric key encryption/decryption (EK), signature (Sig), signature verification (Ver),

Table IV. Comparing between the protocols.

Authentication factors

Something Something SomethingThe protocol you know you have you are Formally verified Suitability

The AKA Yes Yes Yes Yes, secure Not suitableFramework

The Mobile Ethernet Yes No No Yes, vulnerable SuitableAKA Protocol

The 1st Yes Yes Yes Yes, secure SuitableProposed Protocol

The 2nd Yes No Yes Yes, secure SuitableProposed Protocol with considerations

Table V. Comparison of computational loads.

The Protocol PKE PKD EK Sig Ver Hash Messages

The AKA framework [7] 2 1 8 2 0 5 4The Mobile Ethernet AKA protocol 0 0 4 0 0 2 4The 1st proposed protocol 0 0 10 0 0 5 5The 2nd proposed protocol 0 0 6 0 0 3 3



and hash operation (Hash). Additionally, we add the number of exchanged messages (Messages) asshown in Table V. As could be seen in Table V, our proposed protocols could be finished with anacceptable number of messages. Because our proposed protocols are based on symmetric encryp-tion, the PKE and PKD are 0s, in comparison with 2 and 1 in the AKA framework. Furthermore,because symmetric encryption like AES is typically 100 times faster than asymmetric ones like RSAencryption and 2000 times than RSA decryption [29, 30], speed will be another advantage to ourproposed protocols.

7. CONCLUSION

A number of research groups have realized the need for a multilevel security approach to addressthe security in NGNs. Research has considered three security levels, the network-level between themobile terminal and network operators, the service-level between the mobile terminal and the appli-cation service provider, and the device-level between the mobile terminal and the user. This paperconcentrates on the device-level authentication protocols, and it considered a number of protocolsin the literature that have been proposed to address device authentication in NGNs. The analysisshowed that these protocols were either unsuitable for mobile devices because of their complexityor have been found to be vulnerable to security attacks. Therefore, the paper proposes two new pro-tocols, which have been formally verified and analytically analysed. In comparison with the securityprotocols in the literature, the proposed protocols have been proven to meet a number of desiredsecurity properties without resulting in an unnecessary overhead.

APPENDIX A

#Free VariablesPIC, MT : Agentsr1, r2 : Noncesr3 : challNonceSK : Agents -> presharedKeysF : presharedKeys x Nonces x Nonces xDeviceID -> SessionKeysmiD : DeviceIDK : SessionKeysh : HashFunctionAckm: AcknowledgmentPseq: PIC-ID InverseKeys = (K, K), (SK, SK),(F, F)# PocessesINITIATOR(PIC,r1,r3,Ackm) knows SK(MT)RESPONDER(MT,PIC, r2, miD, Ackm) knows SK(MT)# Protocol Description0. -> PIC : MT1. PIC -> MT : {r1, Pseq, h(r1, Pseq)}{SK(MT)}< K := F(SK(MT); r1, r2,miD) >2. MT -> PIC : {miD,r2,r1, h(miD,r2,r1)}{SK(MT)}< K := F(SK(MT), r1, r2,miD) >3. PIC -> MT : {r2,r3, h(r2,r3)}{K}%vdecryptable(v,K)andnth(decrypt(v,K), 1) == r2

< r3 := nth(decrypt(v,K), 2) >4. MT -> PIC : ({Ackm, r3, h(Ackm, r3)}{K})%wdecryptable(w,K)andnth(decrypt(w,K), 1) ==r3 and nth(decrypt(w,K),2) == Ackm5. PIC -> MT: {Ackm, h(Ackm)}{K}%w1decryptable(w1,K)and nth(decrypt(w1,K), 1) == Ackm


M. AIASH

# SpecificationSecret(PIC,SK(MT),[MT])Secret(MT,SK(MT),[PIC])Secret(PIC,miD,[MT])Secret(PIC,K,[MT])Secret(MT,K,[PIC])Agreement(MT,PIC,[r3])Agreement(PIC,MT,[r2])WeakAgreement(MT, PIC)WeakAgreement(PIC, MT)# Actual VariablesPICard, Mobile, Mallory : AgentsR1,R2: NoncesR3, R4 : challNonceMID : DeviceIDk : SessionKeysInverseKeys = (k, k)ACKM: Acknowledgment# Functionssymbolic SK, F# SystemINITIATOR(PICard,R1,R3, ACKM)RESPONDER(Mobile,PICard, R2, MID, ACKM)# Intruder InformationIntruder = MalloryIntruderKnowledge = {PICard, Mobile,R1, F}Crackable = presharedKeys}

APPENDIX B

#Free variablesPIC, MT : Agentsr1, r2 : Noncesr3 : challNonceSK : Agents -> presharedKeysF : presharedKeys x Nonces x DeviceID x PICID -> SessionKeysmiD : DeviceIDPSeq: PICIDK : SessionKeysh : HashFunctionAckm: AcknowledgmentInverseKeys = (K, K), (SK, SK),(F, F)#ProcessesINITIATOR(PIC,r1,r3, Ackm, PSeq, miD) knows SK(MT)RESPONDER(MT,PIC, r2, miD, Ackm) knows SK(MT)#Protocol description0. -> MT : PIC< K:= F(SK(MT),r1, miD, PSeq)>1. MT -> PIC : {K, r1, miD, h(K, r1, miD)}{SK(MT)}< K:= F(SK(MT),r1, r2, miD, PSeq)>2. PIC -> MT : {PSeq,r2,r1, h(PSeq,r2,r1)}{K}3. MT -> PIC : {r2, h(r2)}{K}



#SpecificationSecret(PIC, K, [MT])Secret(MT, K, [PIC])Secret(PIC,r2,[MT])Secret(PIC,r1,[MT])Agreement(MT,PIC,[r2,K])Agreement(PIC,MT,[r1, K])WeakAgreement(MT, PIC)WeakAgreement(PIC, MT)#Actual variablesPICard, Mobile, Eve : AgentsR1,R2: NoncesR3 : challNonceMID : DeviceIDPSEQ: PICIDk : SessionKeysInverseKeys = (k, k)ACKM: Acknowledgment#Functionssymbolic SK, F#SystemINITIATOR(PICard,R1,R3, ACKM, PSEQ, MID )RESPONDER(Mobile,PICard, R2, MID, ACKM)#Intruder InformationIntruder = MalloryIntruderKnowledge = {PICard, Mobile, F}Crackable = presharedKeys

REFERENCES

1. Kuroda M, Inoue M, Okubo A, Sakakura T, Shimizu K, Adachi F. Scalable mobile Ethernet and fast vertical han-dover. Proceedings of IEEE Conference of Wireless Communications and Networking, Atlanta, Georgia USA, 2004;659–664.

2. Aiash M. An integrated approach to QoS and security in future mobile networks using the Y-Comm framework. PhDthesis, Middlesex University, 2012.

3. Aiash M. A formally verified initial authentication and key agreement protocol in heterogeneous environments usingCasper/FDR. The 7th International Conference on Network and System Security (NSS 2013), Madrid, Spain, 2013;742–748.

4. Aiash M, Mapp G, Lasebae A, Phan R, Loo J. A formally verified AKA protocol for vertical handover in hetero-geneous environments using Casper/FDR. EURASIP Journal on Wireless Communications and Networking 2012;57:57–80. DOI: 10.1186/1687-1499-2012-57.

5. Handover Keying (hokey). (Available from: http://datatracker.ietf.org/wg/hokey/charter/) [Accessed on 7 March2014].

6. Aiash M, Loo J. Introducing a novel authentication protocol for secure services in heterogeneous environments usingCasper/FDR. International Journal of Communication Systems 2013. DOI: 10.1002/dac.2561.

7. Zheng Y, He X, Wang H. AKA and authorization scheme for 4G mobile networks based on trusted mobile platform.Proceedings of ICICIS, Bangkok, 2005; 976–980.

8. Lowe G, Broadfoot C, Dilloway A. A compiler for the analysis of security protocol. Oxford University Comput-ing Laboratory: Oxford, UK, 2009. (Available from: http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/manual.pdf)[Accessed on 7 March 2014].

9. Ryan P, Schneider S, Goldsmith M, Lowe G, Roscoe AW. The Modelling And Analysis Of Security Protocols.PEARSON Ltd: London, 2010.

10. Formal Systems LTD, Failures-Divergence Refinement. FDR2 User Manual. (Available from: http://www.fsel.com/documentation/fdr2/fdr2manual.pdf) [Accessed on 7 March 2014].

11. Hao F, Ryan P. Password Authenticated Key Exchange by Juggling. Proceedings of the 16th International Workshopon Security Protocols, Berlin, 2008; 159–171.


http://datatracker.ietf.org/wg/hokey/charter/

http://www.cs.ox.ac.uk/gavin.lowe/Security/Casper/manual.pdf

http://www.fsel.com/documentation/fdr2/fdr2manual.pdf

http://www.fsel.com/documentation/fdr2/fdr2manual.pdf

M. AIASH

12. Kwon T, Yoon H, Kim S, 2013. I-PAKE: Identity-Based Password Authenticated Key Exchange INTERNET-DRAFT.

13. Akula S, Devisetty V. Image Based Registration and Authentication System, 2004. (Available from: http://www.micsymposium.org/mics_2004/Akula.pdf) [Accessed on 7 March 2014].

14. RSA SECUR ID AUTHENTICATORS: The gold standard in two-factor authentication. (Available from:http://www.emc.com/collateral/data-sheet/h9061-sid-ds.pdf) [Accessed on 7 March 2014].

15. Hoyer P. OTP and challenge/response algorithms for financial and e-government identity assurance: current land-scape and trends. In ISSE 2008 Securing Electronic Business Processes. Vieweg+Teubner, 2009; 281–290. DOI:10.1007/978-3-8348-9283-6_29.

16. Sethi A, Manzoor O, Tarun S. User Authentication on Mobile Devices, 2012. (Available from: http://www.cigital.com/wp-content/uploads/downloads/2012/11/mobile-authentication.pdf) [Accessed on 7 March 2014].

17. Xu S, Tser Huang C, Matthews M. Modeling and analysis of IEEE 802.16 PKM protocols using CasperFDR. InWireless Communication Systems, ISWCS08, Reykjavik, Iceland, 2008; 653657.

18. Krishnam Raju KV, Valli Kumari V, Sandeep Varma N, Raju K. Formal verification of IEEE802.16m PKMv3protocol using CasperFDR. Commun Comput Inf Sci. 2010; 101:590595. DOI: 10.1007/978-3-642-15766-0_101.

19. Aiash M, Mapp G, Lasebae A, Phan R. A formally verified device authentication protocol using Casper/FDR. Inthe Proceedings of 2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing andCommunications, Liverpool, 2012; 1293–1298.

20. Menezes A, van Oorschot P, Vanstone S. Handbook of Applied Cryptography. CRC Press: Boca Raton, FL, USA,1996.

21. Inamura Y, Nakayama T, Takeshita A. Trusted mobile platform technology for secure terminals. Technical Report 7,NTT DoCoMo Technical Journal.

22. Ki-Woong P, Sang Seok L, Kyu-Ho P. Computationally efficient PKI-based single sign-on protocol, PKASSO formobile devices. IEEE Transactions on Computers 2008; 57(6):821,834.

23. Mathias B, Wade T. TESLA Certificates: an authentication tool for networks of compute-constrained devices. InProc. of 2003 ACM workshop on Wireless Security (WiSE ’03), San Diego, CA, USA, 2003; 5.

24. Masahiro K, Daisuke I. secure service framework on mobile Ethernet. Journal of the National Institute of Informationand Communication Technology 2006; 29:161–190.

25. Bresson E. Mutual authentication and group key agreement for low-power mobile devices. Computer Communica-tions 2004; 27(2004):1730–1737.

26. Taejoon P, Shin KG. LiSP: a lightweight security protocol for wireless sensor networks. ACM Transactions onEmbedded Computing Systems (TECS) 2004; 3(3):634–660.

27. Memon N, Sutcu Y, Sencar T. A secure biometric authentication scheme based on robust hashing. ACM MM-SECWorkshop, New York, 2005; 111–116.

28. Mayerhoefer A, Vielhauer C, Steinmetz R. Biometric hash based on statistical features of online signatures. IEEEInternational Conference on Pattern Recognition (ICPR), Quebec, Canada, 2002; 123–126.

29. Caroline F, Fabien G. A survey of homomorphic encryption for nonspecialists. EURASIP Journal on InformationSecurity 2007; 2007:1–15. DOI: 10.1155/2007/13801.

30. Microsoft TechNet. Encryption. (Available from: http://technet.microsoft.com/en-us/library/cc962028.aspx)[Accessed on 7 March 2014].


http://www.micsymposium.org/mics_2004/Akula.pdf

http://www.micsymposium.org/mics_2004/Akula.pdf

http://www.emc.com/collateral/data-sheet/h9061-sid-ds.pdf

http://www.emc.com/collateral/data-sheet/h9061-sid-ds.pdf

http://www.cigital.com/wp-content/uploads/downloads/2012/11/mobile-authentication.pdf

http://www.cigital.com/wp-content/uploads/downloads/2012/11/mobile-authentication.pdf

http://technet.microsoft.com/en-us/library/cc962028.aspx

Documents

A formal analysis of authentication protocols for mobile devices in next generation networks