Smartphones as Practical and Secure LocationVerification Tokens for Payments

Claudio Marforio, Nikolaos Karapanos, Claudio Soriente,Kari Kostiainen and Srdjan Capkun

Institute of Information SecurityETH Zurich

{firstname.lastname}@inf.ethz.ch

Abstract—We propose a novel location-based second-factorauthentication solution for modern smartphones. We demonstrateour solution in the context of point of sale transactions and showhow it can be effectively used for the detection of fraudulenttransactions caused by card theft or counterfeiting. Our schememakes use of Trusted Execution Environments (TEEs), such asARM TrustZone, commonly available on modern smartphones,and resists strong attackers, even those capable of compromisingthe victim phone applications and OS. It does not require anychanges in the user behavior at the point of sale or to the deployedterminals. In particular, we show that practical deployment ofsmartphone-based second-factor authentication requires a secureenrollment phase that binds the user to his smartphone TEE andallows convenient device migration. We then propose two novelenrollment schemes that resist targeted attacks and provide easymigration. We implement our solution within available platformsand show that it is indeed realizable, can be deployed with smallsoftware changes, and does not hinder user experience.

I. INTRODUCTION

Fraudulent transactions at points of sale made with stolenor duplicated payment cards are a major problem. In 2010alone, these transactions constituted one third of the 1.26billion EUR total fraud in the Single Euro Payments Area [1].To improve the security of existing payment systems, compa-nies and researchers have suggested usage of mobile devicesas a second-factor authentication mechanism [2], [3]. Asmost users already have smartphones, deployment of suchsecond-factor authentication is practical. Many online serviceproviders already employ second-factor authentication usingsmartphones. Examples of this approach are online bankingapplications [4] and Google 2-Step Verification [5]. In a typicalimplementation, the user reads a one-time passcode off thesmartphone screen and enters it on the service’s web pageduring login. Login operations to services like online bankingare typically performed when the user has time to interactwith his smartphone to complete the authentication process.In addition, web services are easily modifiable. Thus, in mostcases, an extra authentication step can be added to the login

procedure of a web service at little cost. This approach cannotbe, however, integrated in point of sale transactions, becauseinteractions, at a shop counter, with a smartphone are inconve-nient and add undesirable transaction delay. Additionally, thepayment terminal infrastructure is hard to modify.

Recent proposals leverage location data from the user’sphone as the second authentication factor for payments [2], [3].During a transaction, either the card issuer [2] or the user [3]can verify that the location of the user’s smartphone matchesthe location of the point of sale terminal used for the trans-action. Previous work, however, overlooks important usabilityand security aspects, as it requires changes in both the pointof sale infrastructure and the user experience. Furthermore, itassumes a trustworthy mobile OS, even though compromise ofmobile operating systems has become commonplace [6], [7].

To secure mobile services despite mobile OS compromise,researchers have proposed using system-wide Trusted Execu-tion Environments (TEEs), such as ARM TrustZone [8], whichprovide isolated execution of applications and secure storageof credentials [9], [10]. Integrating system-wide TEEs withany second-factor authentication protocol, however, requiresthe verifying party (e.g., the card issuer) to correctly bind auser’s identity to the TEE running on his mobile device throughan enrollment scheme. How to establish this binding in thepresence of a compromised OS is an open problem [11].

In this paper we propose a smartphone-based second-factorauthentication solution for payments at points of sale that useslocation data to identify fraudulent transactions. In contrastto previous work, our solution does not require changes toestablished user interaction models and is compatible with theexisting point of sale infrastructure. We leverage system-wideTEE architectures to provide a secure system, despite mobileOS compromise. As part of our solution, we design two secureenrollment schemes for smartphones to bootstrap second-factorauthentication for payments, which may also be used in otherapplication scenarios. To summarize, We make the followingcontributions.

• We propose a smartphone-based second-factor authen-tication solution for payments at points of sale, thatuses the phone’s location as the second authenticationfactor. Our solution makes use of smartphone TEEsto resist mobile OS compromise.

• As part of our solution, we construct two secureenrollment schemes that allow a card issuer to bind

Permission to freely reproduce all or part of this paper for noncommercialpurposes is granted provided that copies bear this notice and the full citationon the first page. Reproduction for commercial purposes is strictly prohibitedwithout the prior written consent of the Internet Society, the first-named author(for reproduction of an entire paper only), and the author’s employer if thepaper was prepared within the scope of employment.NDSS ’14, 23-26 February 2014, San Diego, CA, USACopyright 2014 Internet Society, ISBN 1-891562-35-5http://dx.doi.org/

the identity of a user with the TEE running on hisdevice. The first enrollment scheme leverages theunique identity of the user’s SIM card and resistsadversaries that can remotely compromise the vic-tim’s mobile OS. The second enrollment scheme usesspecially crafted SMS messages that are processedwithin the device baseband OS. This scheme providesprotection against more powerful adversaries that canadditionally perform hardware attacks on devices towhich they have physical access.

• Through prototype implementation using an open-source baseband OS, Android devices, and an ARMTrustZone development board, we show that our solu-tion can be easily deployed. It requires small changesto existing smartphones, and no changes to the pointof sale infrastructure and the user experience. Ourexperiments show that, during a transaction, locationverification takes less than 4 seconds on average,which is a tolerable delay for most payment scenarios.

• We survey known approaches for second-factor au-thentication using mobile phones and argue why theycannot be deployed in the considered application sce-nario. We also analyze commonly suggested enroll-ment schemes and show why they do not withstandstrong attackers that we consider in this work.

The rest of the paper is structured as follows. Section IIdefines the problem we address is more detail. In Section III,we give background information on mobile device architec-tures, and Section IV defines the adversarial model. Oursecond-factor authentication solution, including the enrollmentschemes, is explained in Section V. We analyze the securityproperties of our solution in Section VI and Section VIIprovides implementation details. We provide performance eval-uation in Section VIII, and in Section IX we discuss paymentsystem integration, privacy considerations, and applicability ofour solution to other related use cases. Section X discussesalternative second-factor authentication mechanisms and en-rollment schemes. Section XI surveys related work, and weend the paper with a brief summary.

II. PROBLEM STATEMENT

Our goal is to design a smartphone-based second-factorauthentication mechanism that prevents fraudulent transactionsat points of sale. In the following we detail the requirementsfor any deployable and secure solution to this problem.

We first aim to design mechanisms that must not changethe user interaction model and the current point of saleinfrastructure. Previous work shows that introducing changesto established user interaction models makes adoption of newsecurity mechanisms impractical [12]. Similarly, having to up-date the deployed points of sale makes adoption of additionalsecurity mechanisms hard [13].

Second, a solution must remain secure despite a targetedadversary that may compromise the mobile OS on the vic-tim’s device. Current systems [4], [5] and related researchproposals [14], [15], which use smartphones for second-factorauthentication, assume the mobile OS to be trustworthy. This

Normal world (NW)

Mobile'OS'(e.g.,'Android)'

App1'

Secure world (SW)

Trusted'OS'

TA1'

Mobile device

'Applica;on'processor''(TrustZone)'

App2'

TA2'

'Baseband'processor''

Baseband'OS'

Peripherals'(GPS)'

SIM'

Fig. 1: Architecture overview of a TrustZone-enabled device.

assumption is too strong, as the complexity of smartphone plat-forms has increased, mobile operating system vulnerabilitieshave become commonplace [6], [7].

Third, any second-factor authentication mechanism thatreplaces dedicated tokens with smartphones, must have anenrollment scheme, where the verifying party binds the identityof a user to his device. A dedicated security token is a user-specific device, which the service provider binds to the useridentity before the token is shipped to the user. As smartphonesreplace such tokens, the service provider can only bind theuser identity to his device after the user has already purchasedthe smartphone. In addition to initial enrollment, a practicalsolution must also support device migration. In applicationslike payments at points of sale, it is realistic to assume aone-time service registration performed, for example, when theuser visits a branch of his bank in person. Requiring a similaroperation every time the user starts using a new smartphonebecomes both expensive for the bank and inconvenient for theuser.

III. MOBILE DEVICE ARCHITECTURE

A standard mobile device architecture has two processors.An application processor runs the mobile OS (e.g., Android)and the applications on top of it. A baseband processor,running the baseband OS, handles cellular communication andmediates communication between the application processorand the SIM card. Each SIM card has a unique identifier calledIMSI (International Mobile Subscriber Identity).

Most mobile devices support system-wide TEEs, like ARMTrustZone [8]. In a TrustZone-enabled device, the applica-tion processor supports two execution states, namely, secureworld and normal world (or non-secure world). The processorswitches between these states in a time-slicing manner, so thatonly one state is active at a time. The normal world runs themobile OS and regular applications on top of it. The secureworld runs trusted applications (TAs), which are executed ontop of a small layer of software called the trusted OS. Thearchitecture of a TrustZone-enabled mobile device is shown inFigure 1.

Applications in the secure world are isolated from themobile OS in the normal world. In contrast to dedicatedsecurity elements like smart cards, system-wide TEEs likeTrustZone allow secure access to various device hardware

2

Normal world

Mobile'OS'

App'

Secure world

TA'

Baseband'OS'

Trusted OS

Mobile device

Victim’s device

Normal world

Mobile'OS'

App'

Secure world

TA'

Baseband'OS'

Trusted OS

Mobile device

Normal world

Mobile'OS'

App'

Secure world

TA'

Baseband'OS'

Trusted OS

Mobile device

Adversary’s device

Software attacker Hardware attacker Software attacker and hardware attacker

Fig. 2: Adversarial model. Grey boxes show trusted components for each type of adversary. The victim’s device (on the left) canbe only targeted with remote attacks and the TCB is the same in both attacker models. Trusted components on the adversary’sdevice (on the right) depend on the considered attacker model: a software attacker cannot tamper with the TCB on his device;an hardware attacker has complete access to any component of his device.

resources from the TEE, and to configuration of secure mobiledevice event handling. Access to device peripherals and thebaseband processor environment is typically possible by boththe trusted OS in the secure world and the mobile OS in thenormal world. In addition, certain peripherals can be reservedfor secure world access only. Access to memory areas can beconfigured in a similar manner, and in a mobile device a smallamount of memory is reserved for the secure world. Accesscontrol to hardware resources is implemented through specificcontrol hardware and signals on the system communicationbus. Hardware interrupts can also be configured for secureworld processing if need be. For more details on TrustZone,see [8].

A standard trusted OS only allows execution of code thathas been signed by a trusted authority, such as the devicemanufacturer. Typically, the device manufacturer ships eachdevice with a device-specific key-pair (we refer to it as thedevice key). The public part of the device key is certified bythe manufacturer, and the issued device certificate containsan immutable device identifier, such as the IMEI number(International Mobile Equipment Identity). The correspondingprivate key is only accessible by software that runs in thesecure world [16].

To limit the size of the TCB, a typical trusted applicationhandles only security-critical processing, such as user creden-tial processing or data encryption. A companion application,running in the normal world, handles the communication, theUI rendering and other complex tasks. The rationale is thatinclusion of complex libraries in the trusted OS, like networkstacks or video drivers, considerably increases the size of thedevice TCB, and with that the attack surface of the secureworld.

Device manufacturers have shipped their mobile deviceswith system-wide TEEs like ARM TrustZone for almost adecade. The usage of these environments, thus far, has beenprimarily limited to a few manufacturer-specific use cases,like implementation of subsidy locks and secure boot [16].Deployment of third-party applications in system-wide TEEshas been limited, because the installation of new trusted appli-cations is subject to the approval of the device manufacturer.

Nevertheless, recent research shows that system-wide TEEscan be safely opened up for third-party trusted applicationdevelopment [17], and on-going TEE API standardization ac-tivities [18] are likely to make trusted application deploymentmore accessible to third-parties.

IV. ADVERSARIAL MODEL

We consider a targeted adversary who possesses the vic-tim’s payment card (or a clone) and knows its PIN code (ifany). His goal is to perform a fraudulent transaction at a pointof sale. The adversary does not have physical access to thevictim’s smartphone. He does, however, have access to othersimilar devices. We regard the device hardware, the trusted OSand the baseband OS as the TCB on the victim’s device, anddistinguish between two types of adversary.

A software attacker can remotely compromise the mobileOS on the victim’s smartphone, but cannot compromise itsTrustZone secure world nor the baseband OS execution. Like-wise, he cannot compromise the TrustZone secure world northe baseband OS on any other device. Software attacks againstthe mobile OS are a real threat [6], [7], while software attacksagainst the TCB (i.e., the baseband OS and the TrustZonesecure world) are significantly harder, due to its limited sizeand attack surface.

A hardware attacker can additionally perform hardwareattacks against devices that he owns or has physical accessto. On such devices, he may compromise the baseband OSexecution, the TrustZone secure world and, ultimately, ex-tract the TrustZone-protected secrets, such as the device key.This adversarial model is justified by the fact that neithera TrustZone-enabled processor nor the baseband processorprovide tamper resistance properties, commonly found in smartcards or hardware security modules. Figure 2 illustrates trustedsoftware components (gray boxes) in these different scenarios.

Neither of the attackers controls the cellular network com-munication. Furthermore, they cannot launch GPS spoofingattacks on the victim’s device. Finally, we do not addressdenial-of-service attacks.

3

User%smartphone%

Payment%card%

Point%of%sale%terminal%

1. payment protocol

3. location verification request

4. location statement

Card%issuer%

2. payment protocol

5. transaction authorization

Fig. 3: Overview of location-based second-factor authentica-tion for payments at point of sale. During a payment trans-action, the card issuer queries the user’s smartphone for itslocation over an Internet connection.

V. OUR SOLUTION

We use the location of the user’s phone as the secondauthentication factor during a transaction at a point of sale.Our solution leverages system-wide TEEs available on mobiledevices to provide card issuers with trustworthy locationinformation despite a potentially compromised mobile OS onthe user’s smartphone. We focus on ARM TrustZone since itis currently the most widely deployed system-wide TEE onmobile devices. The schemes we propose can, nevertheless,be used with other system-wide TEEs as well.

Figure 3 shows an overview of our scheme. Prior topayments at point of sales, we assume that the user has alreadyinstalled two applications provided by the card issuer on hisdevice: a companion application running in the normal worldand a trusted application running in the secure world. Addi-tionally, the user has also completed an enrollment scheme (seebelow), and the card issuer has established a binding betweenthe user and the TEE on his device. During payment, the userinserts or swipes his payment card in a point of sale terminaland optionally enters its PIN code (step 1). The terminal sendsthe transaction information to the card issuer (step 2). Thecard issuer contacts the TEE on the user’s smartphone (step3), which replies with a location statement (step 4). The cardissuer then checks whether the location statement was sent bythe correct device and compares it against the location of theterminal. Finally, the card issuer sends the transaction decision(authorize or deny) to the terminal (step 5).

We leverage location data due to two main reasons. First,we want a solution that does not change the user interactionmodel and the hardware infrastructure (see Section II). Wetherefore resort to the sensing capabilities of modern smart-phones. Second, among available smartphone sensors, GPSunits are almost ubiquitous, and previous work has shown thatGPS coordinates are a practical and useful means that cardissuers can leverage to identify fraudulent transactions [2], [3].Our solution could, in principle, use any sensor available onthe device.

Card%issuer%

1. user ID

Companion%applica0on%

User smartphone

User%Trusted%

applica0on%

2. trigger

Baseband%

3. query

4. IMSI and network status

6. user ID, signed IMSI, device certificate

7. service key encrypted using public device key

seal%service%key%

translate%phone%number%to%IMSI%

5. IMSI signed using private device key

Fig. 4: Signed-IMSI enrollment scheme. Gray boxes are trustedentities. The trusted application fetches the IMSI of the in-stalled SIM card from the baseband processor. It signs theIMSI with the private device key and forwards it to the cardissuer (through the companion application). The card issuercan link the IMSI to a previously registered phone number.

A. User Enrollment

Before the card issuer can verify the location of the user’ssmartphone, it needs to bind the user identity to the TEErunning on his mobile device. To achieve this binding, wepresent two enrollment schemes. The signed-IMSI enrollmentscheme is easier to deploy but can only withstand softwareattackers; the baseband-assisted enrollment scheme is alsosecure against hardware attackers. However, it requires minorsoftware changes to the baseband OS. Both schemes leveragethe implicit binding between the user and his SIM card. Theyrequire a one-time registration in which the user provides hisphone number to the card issuer in a reliable manner, forexample, by visiting his bank’s branch in person. The goal ofboth enrollment schemes is to establish a shared service key,between the card issuer and the trusted application running inthe TEE on the user’s device.

Signed-IMSI enrollment

The card issuer uses the SIM identifier (i.e., the IMSI) andthe mobile network infrastructure to verify that the enrollingdevice is indeed the one where the user’s SIM card is installed.Figure 4 illustrates the steps of the enrollment scheme.

The user starts the companion application and provideshis user ID, e.g., the bank customer number (step 1). Thisapplication triggers the execution of the trusted application(step 2) that queries the baseband OS for the IMSI of theSIM card (steps 3-4).1 The trusted application also verifiesfrom the baseband OS that the device is connected to themobile network, to discard the possibility of a fake SIM cardreporting a false IMSI.2 The trusted application signs the IMSI

1The IMSI is needed for cellular protocols and is available to the basebandOS through standardized interfaces.

2A false SIM card lacks the correct keying material to connect to the cellularnetwork

4

5. authenticated IMEI, device certificate

Card%issuer%

1. user ID

Companion%applica0on%

User smartphone

User%Trusted%

applica0on% Baseband%

2. user ID

3. enrollment key

4. IMEI authenticated using enrollment key

seal%service%key%

6. service key encrypted using public device key

compare%IMEI%to%device%cer0ficate%

Fig. 5: Baseband-assisted enrollment scheme. Gray boxes aretrusted entities. The card issuer sends an SMS message withan enrollment key (dotted line); the baseband OS uses thatkey to authenticate the device’s IMEI and deletes the key. Thecard issuer can check the authenticated IMEI against the onereceived in the device certificate.

using its device private key (step 5) and passes the signatureto the companion application. At this point the companionapplication sends the signed IMSI, the user ID, and the devicecertificate to the card issuer over the Internet (step 6). Thecard issuer uses the received user ID to retrieve the user’sphone number and queries the mobile infrastructure for thecorresponding IMSI (see Section VII for details). The cardissuer checks that the IMSI received from the user’s phonematches the one reported by the mobile infrastructure. If thetwo IMSIs match, the card issuer proceeds to verify (i) thevalidity of the device public key using the device certificate andthe public key of the manufacturer, and (ii) the validity of thesignature over the IMSI. If all checks are successful, the cardissuer picks a fresh service key and encrypts it under the devicepublic key; the ciphertext is sent to the user’s smartphone (step7). The companion application passes the encrypted servicekey to the trusted application that decrypts it using the privatepart of the device key and encrypts it using a symmetric storagekey available only in the secure world (sealing). The sealedservice key can be stored by the companion application in thenormal world.

Baseband-assisted Enrollment

In this scheme the card issuer sends an SMS messagecarrying an enrollment key to the phone number provided bythe user during registration. We augment the baseband OS touse this key and compute an authentication tag on the device’sIMEI.3 The steps of this scheme are in Figure 5.

The user starts the companion application and provides hisuser ID (step 1), which is forwarded to the card issuer overthe Internet (step 2). The card issuer sends an enrollment SMSmessage to the corresponding user’s phone number, containing

3The IMEI is bound to the device key by the device certificate.

Companion(applica+on((

Trusted(applica+on(Card(

issuer(

5. location and nonce signed with service key

1. nonce 2. nonce

User smartphone

6. signed location and nonce

GPS(peripheral(

3. read

4. location

Fig. 6: Location verification is a simple challenge-responseprotocol using the service key established during enrollment.Gray boxes are trusted entities. The card issuer sends anonce; the trusted application reads the GPS coordinates andauthenticates them together with the nonce.

a fresh enrollment key (step 3). The baseband OS on the user’sdevice intercepts the SMS message and extracts the enrollmentkey. The baseband OS uses the enrollment key to authenticatethe device’s IMEI,4 provides the authentication tag to thecompanion application (step 4), and deletes the enrollmentkey. The companion application forwards the authenticatedIMEI and the device certificate to the card issuer (step 5).The card issuer checks (i) the validity of the device certificate,(ii) the validity of the authentication tag, and (iii) that theIMEI authenticated with the enrollment key matches the onein the received certificate. If all checks are successful, thecard issuer picks a fresh service key and encrypts it underthe device public key extracted from the device certificate;the ciphertext is sent to the user’s smartphone (step 6). Thecompanion application passes the encrypted service key to thetrusted application that seals it.

B. Location Verification

After successful enrollment, the user’s device shares aservice key with the card issuer that can be used to create anauthentic channel between the two parties. During a transactionpayment, therefore, the card issuer can query the device for anauthenticated location statement. As detailed in Figure 6, thelocation verification is a simple challenge-response protocol.

The card issuer picks a fresh nonce (for replay protection)and sends it to the trusted application through the companionapplication (steps 1-2).5 The trusted application reads thelocation coordinates from the device GPS unit (steps 3-4),unseals the service key and uses it to authenticate the nonceand the current coordinates. The authenticated message is sent

4The IMEI is read from a read-only memory on the device, written bythe device manufacturer. The baseband OS has access to the IMEI to handlecellular communication.

5Alternatively, the card issuer could verify the freshness of location state-ments checking the timestamp provided by the GPS unit. As one of our goals isnot to change the payment transaction user experience, the location verificationmust be initiated by the card issuer. Thus, a location verification requires theexchange of two messages between the card issuer and the user smartphone ineither cases (i.e., usage of the GPS timestamp does not allow a more efficientimplementation).

5

back to the card issuer through the companion application(steps 5-6). The card issuer verifies the authenticity of thelocation statement using the service key. At this point, the cardissuer matches the location of the user’s smartphone against theone of the terminal used for the transaction, to decide whetherto authorize or deny the transaction.

We note that neither the companion application nor thetrusted application need to be continuously running in thebackground. The execution of the trusted application is trig-gered by the companion application which, in turn, is startedby the mobile OS when receiving a request for that application(e.g., through a push notification).

C. Device Migration

Both enrollment schemes support device migration by re-running the enrollment operation. When the user switches toa new device and moves his SIM card to it, he can start theenrollment process from the companion application of the newdevice. As a result of either the signed-IMSI or the baseband-assisted enrollment, the card issuer invalidates the previouslyused service key, re-associates the user identity to the devicekey of the new device, and sends a fresh service key to the TEEon that device. Device migration does not require out-of-bandcommunication with the card issuer as long as the user keepshis phone number (even if he gets a new SIM card associatedwith his old phone number).

VI. SECURITY ANALYSIS

Recall that our adversary holds the victim’s payment card(or a clone) and his goal is to make fraudulent transactions atpoints of sale. The adversary does not have physical access tothe victim’s smartphone but he does have remote control overthat smartphone’s mobile OS.

With the deployment of our system, the adversary mustconvince the card issuer that the enrolled user’s smartphoneis close to the terminal where the fraudulent transaction istaking place. To do so, the adversary must either succeed inan impersonation attack during enrollment or tamper with thelocation verification protocol.6

In an impersonation attack, the adversary must halt theenrollment scheme on the victim’s device (he can do so sincehe controls that device’s mobile OS), and use the victim’s IDto run the enrollment scheme on a device that he owns. Inparticular, the adversary has two possible strategies: he mustinduce the card issuer to encrypt the service key either

(a) under the public key of the adversary’s device (theadversary will thus be able to make fraudulent trans-actions if his phone is in proximity of the terminalwhere the transaction takes place), or

(b) under a public key for which the adversary knowsthe private key (so that the adversary will be able togenerate arbitrary location statements when the cardissuer requests them).

In the following we provide an informal analysis of theenrollment schemes, with respect to the two strategies above.

6We acknowledge that the adversary may still succeed in his goal if thefraudulent transaction takes place close to where the victim’s device is located.

Finally, we argue that the location verification mechanism issecure after successful user enrollment.

A. Signed-IMSI enrollment

This enrollment scheme is secure against a software at-tacker as defined in Section IV. This attacker can control themobile OS on any device (including the victim’s) but does nothave sufficient capabilities to control any baseband OS or theTrustZone secure world execution environment.

Strategy (a) requires the adversary to start an enrollmentscheme on his device using the victim’s ID. Since the cardissuer knows the victim’s phone number and can retrievethe corresponding IMSI, the adversary must force the trustedapplication on his device to send the IMSI of the victim’sSIM card. To do so, the adversary may use a custom SIMcard where he can manipulate the IMSI. However, such SIMcard misses the key that the victim’s SIM card uses forauthentication with the network operator and, thus, cannotconnect to the cellular network. When the trusted applicationon the adversary’s device queries the baseband OS for cellularnetwork status, it detects that the phone is not connected andwill abort the enrollment scheme.

Strategy (b) requires the adversary to hold a private keycorresponding to a valid (i.e., certified by the device man-ufacturer) public key. This is not possible since a softwareadversary cannot compromise the ARM TrustZone architectureof any device and leak the secrets stored therein.

B. Baseband-assisted Enrollment

This enrollment scheme is secure against an hardwareattacker, as defined in Section IV, that controls the mobile OSon any device (including the victim’s), as well as the basebandOS and the TrustZone secure world execution environment ondevices to which he has physical access.

Strategies (a) and (b) require the adversary to either inter-cept the enrollment SMS message and extract the enrollmentkey, or provide a crafted IMEI to the baseband OS on thevictim’s device. Since the adversary does not control the GSMnetwork, SMS messages cannot be intercepted. Furthermore,the enrollment key is deleted by the baseband OS, so that thenormal world cannot read it. Finally, the IMEI is stored onread-only memory during device manufacturing [16], thus theadversary cannot feed an arbitrary IMEI to the baseband OSon the victim’s device.

C. Location Verification

After a successful enrollment, the trusted application run-ning in the secure world on the victim’s device shares aservice key with the card issuer. At this time, the adversarycan only try to force the victim’s device to report a locationstatement with GPS coordinates matching the location wherethe fraudulent transaction takes place. Since none of theconsidered adversaries (i.e., software and hardware) control thesecure world on the victim’s device, the adversary can only tryto change the coordinates provided by the GPS unit on thatdevice. We note that GPS units on modern smartphones onlyallow to reset the GPS sensor. That is, the adversary cannotfeed the trusted application on the user’s phone with arbitrary

6

coordinates. The trusted application can, nevertheless, detect areset and restart the GPS sensor.

VII. IMPLEMENTATION

We implement three prototypes to evaluate the feasibilityof the proposed second-factor authentication solution andenrollment schemes. First, we modify an open-source basebandOS to show that the changes required to existing basebandoperating systems are small. We test our baseband modi-fications on an older mobile phone, because the basebandenvironment on modern smartphones is not modifiable bythird-party developers.

Second, we implement the trusted application on a Trust-Zone development board to show that its deployment onTrustZone-enabled devices is straightforward, and that thetime overhead to generate location statements is negligiblecompared to network delays. We use a TrustZone developmentboard because installation of trusted applications on currentsmartphones requires approval by the device manufacturer.

Third, we implement a client-server prototype using anAndroid smartphone to evaluate the end-to-end performance ofthe location verification mechanism at the time of a paymenttransaction.

A. Baseband Implementation

To accommodate the baseband-assisted enrollment schemeof Section V-A, we augment osmocomBB [19], which is theonly available open-source baseband OS. It is implemented forMotorola mobile phones like the C123 or C118, introduced in2005. The GSM layer 1 (the physical layer) executes directlyon the mobile phone, while layers 2 and 3 (respectively thedata-link layer and the third layer, subdivided in the RadioResource management, the Mobility Management, and theConnection Management) run as the mobile application ona host PC connected with the device through a USB-to-serialcable.

We leverage the widely used SMS Protocol Data Unitmode, standardized in [20], to format the enrollment SMSmessage sent by the card issuer to the user’s phone number.In the standard, a User Data Header structure can containso called Information Element Identifier elements, that arereserved for future use. We encode the enrollment key inthe Information Element Data field of one such identifier.We add to the baseband OS the logic to identify and handleenrollment SMS messages. Once the key is found in the SMSmessage header, the baseband OS extracts it and computes anauthentication tag over the device’s IMEI. We use the HMAC-SHA1 implementation provided by the PolarSSL [21] libraryas the authentication algorithm.

We test the prototype baseband OS in a Motorola C118connected through a USB-to-serial cable to a host PC runningUbuntu 12.10. The original mobile application provided byosmocomBB consists of 19,482 lines of C code; we add atotal of 523 lines of code, where polar_sha1.c accountsfor 451 lines of code. Our changes increase the code sizeby 2.7%. In terms of binary size, a compiled version of theoriginal mobile application is 2029 kB; our modified versionaccounts for 2077 kB in total (i.e., 2.3% larger). The layer1

firmware (layer1.compalram.bin) that is installed onthe mobile phone accounts for 63 kB and remains unmodified.

B. Trusted Application Implementation

We implement a trusted application that provides locationstatements, on a TrustZone-enabled development board. Weuse it to evaluate the implementation complexity and thetime required to produce location statements. The board isan ARM Motherboard Express uATX [22] coupled with anARM CoreTile Express A9 [23]. The board features a Cortex-A9 processor which is clocked at 400 MHz. The developmentboard contains no GPS unit or baseband processor. In thenormal world of the system, we run Android version 4.1.1 withLinux kernel version 2.6.38.7, properly patched to support theARM board as well as Android. In the secure world, we runOpen Virtualization SierraTEE [24], release “02 June 2013”.SierraTEE is an open-source framework that provides a basicsecure world kernel, compliant with the GlobalPlatform TEEspecifications [25].

The implementation of the trusted application accounts forless than 150 lines of code. Thus, incorporating our trustedapplication into an existing trusted OS, that already providesthe necessary cryptographic functions and system calls, wouldhardly change the existing memory and storage requirements.

Location Verification

The application that generates location statements runs ontop of Open Virtualization, in the secure world, while thecompanion application runs in the normal world, on top ofAndroid. When the card issuer initiates a location verificationprotocol with the user’s smartphone, that device switchesfrom normal world to secure world and executes the trustedapplication that generates the location statement.

We set up an experiment where the companion application,running in the normal world, invokes the trusted applicationand provides it with a 128-bit nonce. As the development boardhas no GPS unit, we emulate it by creating a system callin the secure kernel that just returns longitude, latitude andaccuracy values. The trusted application runs HMAC-SHA256over the data fetched from the system call and the providednonce. The location statement is returned to the companionapplication in the normal world. A shared memory buffer isused for exchanging data between the two worlds.

We measure the total time required for the companionapplication to receive a location statement from the trustedapplication. This time includes (i) the performance delayintroduced by the context switching and required data copyingbetween the normal world and the secure world, and (ii)the time it takes for the trusted application to generate alocation statement. The above experiment is repeated 1000times. Average completion time is 3.0 milliseconds, with astandard deviation of 0.04 milliseconds. The time spent incontext switching between the normal world and the secureworld is below one millisecond.

Enrollment

Since our board is not equipped with a baseband processor,we do not implement the enrollment schemes of Section V-A.Nevertheless, we now explain how they can be realized.

7

During the signed-IMSI enrollment scheme, the trustedapplication must query the baseband OS for the IMSI of theinstalled SIM card, and for the cellular network status. Ina mobile device, communication between the baseband OSand the mobile OS (e.g., Android) is implemented through amanufacturer-supplied binary (e.g., a driver). A stripped-downversion of this binary may be as well installed in the secureworld by the device manufacturer. Given that subsidy lock isone of the most used services in TrustZone-enabled devices,it is reasonable to assume that the secure world is able tocommunicate with the SIM card in a modern smartphone [16].For reference, the full binary in the Samsung Galaxy S3 phone(i.e., libril.so) is 49 kB. The complete API offers roughly200 function calls (extracted by looking at the strings of thebinary) to the baseband OS. In contrast, the stripped-downversion to support enrollment only requires the function callsGET_SIM_STATUS and GET_IMSI.

In the baseband-assisted enrollment scheme, the trustedapplication is only invoked at the end of the process to decryptand seal the service key sent by the card issuer. Hence, there isno requirement for direct communication between the secureworld and the baseband OS.

C. Client-Server Implementation

To evaluate the performance of the location verificationprotocol, the client prototype provides the functionalities ofboth the companion application running in normal world, andthe trusted application running in secure world. This imple-mentation does not account for the needed context switchingbetween the normal world and the secure world. As mentionedbefore, this time is below one millisecond, and thus negligiblecompared to networking delays of a full end-to-end implemen-tation.

We develop against the API level 16 of the Android SDK(version 4.1, “Jelly Bean”) [26]. Cryptographic operations arebased on the Bouncy Castle crypto library [27]. We use 2048-bit RSA keys as device keys. Authentication of location state-ments leverages HMAC-SHA256 with an 128-bit service key.Communication between the server and the client uses the pushnotification feature of Google Cloud Messaging (GCM) [28];the reverse channel is a standard HTTP connection.

The client provides functionalities for the signed-IMSIenrollment scheme (cf. Section V-A) and the location veri-fication mechanism (cf. Section V-B). During enrollment, theapplication queries the baseband OS through the Android JavaAPI provided by the TelephonyManager service, for theIMSI of the SIM card and the network connection status.During location verification, the application reads the GPSlocation (latitude and longitude, accuracy and satellite fix time)using the LocationManager system service.

The server-side processing is implemented in python, usingthe CherryPy Web Framework [29] and SQLite [30]. This webservice is accessed through a RESTful web API that providesenrollment and location verification operations. During thesigned-IMSI enrollment scheme, the server translates a phonenumber to the corresponding IMSI using an HLR-lookup querywith an external service provider. An HLR-lookup query iscarried out by network operators using the Signaling System#7 (SS7) protocols. In particular, the Home Location Register

Static tests Field study (3G)WiFi 3G Edge Orange Sunrise

(n=101) (n=101) (n=101) (n=46) (n=34)average (sec) 0.60 1.82 2.20 2.54 3.68std dev (sec) 0.08 0.05 0.30 0.78 1.45

TABLE I: Completion time for location verification duringpayment transactions. n denotes the number of samples in eachscenario.

(HLR) of a network operator holds information about its userssuch as their phone numbers and to which network a deviceis currently connected. Among other information, the HLRholds the IMSI of the SIM card connected to the network.Several HLR lookup services, such as [31], are available tothird-parties.

While our client prototype implementation is tailored to-wards a device using Android OS, similar functionalities areeasily done on other smartphone platforms.

VIII. EXPERIMENTAL EVALUATION

The previous section shows that context switching be-tween the two TrustZone execution states (i.e., normal andsecure world) and cryptographic operations to produce locationstatements, require only a few milliseconds. Network delays,therefore, account for the majority of the time required toverify the location of the user’s device by the card issuer. In thissection we analyze the time to complete location verificationand present the experimental evaluation of our client-serverprototype.

We focus on the location verification protocol as the enroll-ment procedure is a one-time operation and its performance isless critical. The client prototype is installed on a SamsungGalaxy S3 smartphone with the latest software updates (as ofthe time of writing), after a factory reset. The server is runningon a standard laptop and shares a service key with the client.We provide results for both static tests run with the phonein a fixed location (office environment) and a field study runin a scenario close to actual deployment. Table I provides anoverview of our results which we elaborate below.

A. Static Tests

During static tests, the client device is in a fixed position,on a desk in our office environment. We run tests for Edge(GSM only mode), 3G (WCDMA only), and WiFi (mobiledata turned off) connections. For each connection setting, wemeasure the completion time, i.e., how long it takes fromthe moment the server issues a request, until the moment itreceives the location statement and verifies its authenticity.The experiment is repeated 100 times (the server issues onerequest per second), and Figure 7a shows the completion timefor each location verification. Results show longer completiontimes during the first runs, for Edge and 3G connections.This behavior is presumably caused by the time it takes to“activate” the radio on the phone. To validate our hypothesis,we set the interval of two consecutive server requests to 30seconds, allowing the radio of the phone to “deactivate” aftereach request. Results are shown in Figure 7b. Confirming

8

0 1000 2000 3000 4000 5000 6000 7000 8000

0 20 40 60 80 100

Com

plet

ion

Tim

e (m

s)

Location Request Number

WiFi3GEdge

(a)

0 1000 2000 3000 4000 5000 6000

0 20 40 60 80 100

Com

plet

ion

Tim

e (m

s)

Location Request Number

WiFi3GEdge

(b)

Fig. 7: Completion time for 100 location verifications. In Figure (a) the server initiates one request per second. In Figure (b) theserver waits 30 seconds before issuing each request.

0 500

1000 1500 2000 2500 3000

Edge 3G WiFi

Com

plet

ion

Tim

e (m

s)

Connection Type

Fig. 8: Average time and standard deviation required to com-plete a location verification, for different connection types.

our hypothesis, completion time in this scenario has greatervariance, especially when using Edge or 3G networks.

Finally, Figure 8 shows the average and the standarddeviation for the measurements of Figure 7b. The completiontime for our solution is, on average, 2.2 seconds with anEdge connection, 1.82 seconds with a 3G connection, and 0.6seconds with a WiFi connection, respectively.

B. Field Study

To test our solution in a setting close to the actual paymentscenario, we use two client devices and carry out a two-dayfield study with two subjects in Zurich. Each subject carriesa client device and a triggering device. The two clients haveSIM cards issued by different operators (Orange and Sunrise).

The triggering device initiates a server request. The serverruns on a standard laptop and listens for incoming triggers. Weuse a separate trigger device to make sure that, at the time of alocation verification, the radio on the client device is not active.In an actual deployment, if the radio happens to be active whena location verification request is received, completion time isexpected to be smaller than the ones reported below.

For two days, each subject uses the triggering device toinitiate a location verification each time he is close to a pay-

GPS accuracy (m) GPS fix delay (ms)average max min average max min17.40 48.0 4.0 256.83 3430.00 0.00

TABLE II: Location accuracy results during the field study.

ment terminal in, for example, shops, cafes, museums, parkinglots, etc. Completion time, for the device with the OrangeSIM card, is 2.54 seconds on average (standard deviation 0.78seconds). The smartphone with the Sunrise SIM card showsslightly worse performance as the completion time raises to3.68 seconds on average (standard deviation 1.45 seconds).

Table II shows the accuracy of the location information andthe elapsed time between the server request and the actual GPSfix on the client. The reported accuracy is within an acceptablerange to distinguish shops next to each other (17.40 meters onaverage), and the location fix is available with a very shortdelay (less than 257 milliseconds on average).

IX. DISCUSSION

This section further discusses the proposed mechanisms interms of integration with current payment systems, deploymentconsiderations, and privacy issues. Finally, we discuss theapplicability of our solution to other scenarios.

A. Integration with Payment Systems

Our protocols can increase the security of any payment cardtransaction (either “chip and PIN” or “swipe and sign”) wherethe card issuer is contacted by the terminal to authorize or denythe payment. We now detail the integration of our solution withdeployed payment systems and, in particular, with the EMVpayment standards [32].

An EMV transaction involves the card, the terminal, thecard issuer and an acquirer. The acquirer is a banking in-stitution that processes credit and debit card payments formerchants. Third-party payment processors may be also in-volved, or the issuer and the acquirer may be the samebanking institution. EMV specifications for transactions with

9

User%smartphone%

Payment%card%

Point%of%sale%terminal%

1. ARQC

3. location verification request

4. location statement

Card%issuer%

2. ARQC 5. ARPC

Acquirer%

3. merchant ID 4. merchant location

6. ARPC

Fig. 9: Integration of the location verification protocol withinthe EMV payment standards. Dashed lines indicate the addi-tional messages required for our solution.

online authorization dictate two cryptograms (authenticatedmessages) exchanged between the card and its issuer. Thecryptogram sent by the card is denoted as the ApplicationRequest Cryptogram (ARQC) and accounts for a number offields that are supplied either by the card or by the terminal.Mandatory fields for ARQC include the transaction amount,the transaction date, and a random nonce generated by theterminal. EMV also defines optional fields that individualpayment systems (e.g., Mastercard M/Chip or Visa VSDC)may require. The card issuer replies with an ApplicationReply Cryptogram (ARPC) that notifies the card whetherthe transaction has been approved. Figure 9 illustrates themessages defined in the EMV standards; dashed arrows showthe additional messages required to implement our solution.

Our solution requires the card issuer to know the physicallocation of the terminal used for a transaction. In the EMVstandards an acquirer ID globally identifies a banking insti-tution, while a merchant ID identifies a merchant within abanking institution. Either the card or the terminal can requestthat these elements are included in the ARQC message. Oncethe card issuer learns the acquirer and merchant identifiersof a transaction, it can contact the acquirer with the purportedmerchant ID in order to retrieve the merchant location. Popularpayment systems are already providing merchant information,such as location, through standardized APIs [33], [34].

In current EMV payment systems, the acquirer ID andthe merchant ID fields are defined by the standard but arenot mandatory for ARQC messages. Through card softwareupdates it is possible to include these fields in ARQC messagesof every transaction. The EMV standards allow for remoteupdate of payment card software through issuer scripts thatmay be included in the ARPC cryptogram.

A noteworthy benefit of our solution is that it enablesgradual and secure deployment for selected users. A cardissuer can enable location verification for a subset of itscustomers, for example, by updating the payment cards ofcustomers that decide to opt-in. Once location verification

is enabled for these users, an adversary that has obtained apayment card of any such user cannot circumvent the system.In comparison, solutions that require gradual terminal updatesdo not provide similar protection, as the adversary can alwaysbypass the added security mechanisms by utilizing not yetupdated terminals.

B. Deployment Considerations

Even though fraud reduction is a clear incentive for banksor payment card issuers to adopt our solution, it is the useradoption that will be the driving factor. The proposed schemesdo not change the user experience at point of sales, but they doconsume internet bandwidth and battery on the user’s device.Since payment card issuers are currently covering the costsof frauds, it is an open question whether users would pay theadditional costs in terms of bandwidth and battery on theirmobile devices, without any apparent benefit. To boost the useradoption, the card issuer may offer lower fees to users whoopt-in, just like car insurance companies do for customers whoinstall anti-theft mechanisms on their cars.

Our solution assumes the user’s smartphone to have In-ternet connectivity at the time of a transaction. This maynot hold for two reasons. First, high roaming charges inducemany users to turn Internet access off while traveling abroad.International regulatory bodies have started to forbid excessiveroaming charges. For example, the EU has recently decided tocompletely remove roaming charges within its member coun-tries by 2015 [35]. A cost-effective alternative to avoid currentroaming charges is to use SMS messages for communicationbetween the user’s device and the card issuer. SMS-basedcommunication, can however experience high delays (SMSmessage delivery is based on a best-effort basis and can takeup to 12 seconds in normal load conditions [36]). Second,Internet connectivity might not be available in remote areas orunderground locations (although many underground shoppingcenters or transport stations have cellular coverage).

Card issuers can handle lack of connectivity based ontransaction value, merchant location or user specific policies.For example, high-value transactions in areas where Internetconnectivity is expected to be available may only be autho-rized after a successful location verification with the user’ssmartphone. A possible solution to handle temporary lack ofconnectivity for low-value transactions could be to keep, onthe device, an authenticated log of timestamped locations andreport the one that is closest to the transaction time, onceInternet connectivity is again available. While this solutiondoes not allow for real-time fraud prevention, it allows cardissuers to perform offline fraud detection.

C. Privacy Considerations

The card issuer can ask the user’s device for location state-ments and track the user over time. However, if the protocolis triggered at times of genuine transactions, our solution doesnot leak extra information, since the card-terminal transactionalready reveals the user location to the card issuer. The cardissuer may also abuse the system and query the user’s devicefor a location statement when the card is not involved in atransaction. We argue that the system abuse can be preventedthrough precise terms of agreement; card issuers that break

10

those terms will damage their reputation and lose customers.Another solution is to let the card issuer send the locationof the point of sale terminal to the device and let the devicecompare it against its current location, as done in [3].

With respect to third-parties (i.e., law-enforcement author-ities), location statements issued by the user’s device can bedenied. Since the (symmetric) service key used to authenticatelocation statements is shared with the card issuer, no third-party can identify who produced a location statement (eitherthe user’s device or the card issuer). Finally, we remark that anadversary in control of the mobile OS on the victim’s devicecan query the GPS unit at will and track the user, independentlyof the solution presented in this paper.

D. Other Application Scenarios

Our protocols can be applied to other application scenariosbeside payments at points of sale. In particular, they canbe used in any scenario where the verifying party (e.g., aservice provider) knows the user’s phone number and thelocation of the infrastructure used to perform transactions.Two prominent examples are public transportation ticketingand building access.

In the public transportation scenario the user holds atransport ticket (e.g., an NFC card) that is used at dedicatedmachines to access the transportation network (e.g., at theentrance of metro stations). Our solution can provide assuranceto the public transportation authority that a lost or stolentransport ticket is not used by any party but the rightful owner.

Similarly, building access control systems require a userto carry an access token with a short-range wireless interface.Entry is granted if the token is presented to a dedicated readerand the valid PIN is entered by the user. Location statementscan increase the security of such access control systems. Uponpresenting the access token to the reader, the user phone isqueried for its location; if the purported location matches theone of the reader, the building access authority can grantaccess.

As part of our field study (described in Section VIII), wetested completion time and accuracy of our location verifi-cation protocol in public transportation and building entrancescenarios. Results are summarized in Table III and Table IV.

Completion time at public transport stations takes 3.03seconds on average, using a 3G connection, for the deviceusing Orange, and 3.39 seconds on average for the smartphoneusing Sunrise. We argue that three seconds to grant accessto the transportation network may be an undesirable delay.Nevertheless, our solution could be used for offline ticket abusemonitoring. The public transportation authority could disable aticket after witnessing a number of consecutive fraudulent uses.In this scenario, the measured location accuracy (see Table IV)is around 14 meters on average. In most public transportationapplications this accuracy is sufficient to distinguish entrancesto the transportation network from one another.

We also test the time it takes to run our protocol whenentering buildings in two campuses of ETH Zurich, one inthe city center and the other in the city suburbs. Completiontime takes 2.31 and 4.40 seconds on average, depending onthe network operator used as shown in Table III. The location

Building access Public transportOrange Sunrise Orange Sunrise(n=59) (n=40) (n=43) (n=63)

average (sec) 2.31 4.40 3.03 3.39std dev (sec) 0.57 1.74 0.66 1.33

TABLE III: Completion time for location verification forpublic transport and building access tests. n denotes the numberof samples in each scenario.

Scenario GPS accuracy (m) GPS fix delay (ms)avg max min avg max min

Building access 14.04 48.0 4.0 139.31 3087.00 0.00Public transport 15.47 48.0 6.0 210.52 4035 0.00

TABLE IV: Location accuracy for public transport and build-ing access tests.

accuracy in this scenario is around 15 meters, which is enoughto differentiate building doors from each other in most cases.

X. ALTERNATIVE APPROACHES

In this section we discuss alternative ways in whichsmartphones could provide a second authentication factor forpayments at points of sale, and conclude that location verifi-cation provides a practical means for card issuers to identifyfraudulent transactions. We also analyze commonly suggestedenrollment schemes and show how they fail to provide secureuser-to-device binding, given our realistic attacker model.Finally, we describe alternative TEEs available on currentsmartphones and their shortcomings, compared to system-wideTEEs such as ARM TrustZone.

A. Second-factor Authentication Approaches

In a typical transaction at a point of sale, the user entersor swipes his payment card into a terminal and optionallytypes its PIN code. The card runs a protocol with the terminalthat contacts the card issuer for online transaction verification.Figure 10 illustrates common second-factor authentication ap-proaches: (1) Authentication token replacement (Figure 10a).The smartphone acts as a dedicated authentication token anddisplays one-time passcodes that the user must type into theterminal. Google 2-Step Verification [5] is a prominent exam-ple of this approach in the context of web login authentication.A similar approach can be applied to payments at points ofsale. (2) User confirmation device (Figure 10b). The card issuercontacts the user’s device which presents a confirmation dialogto the user. The confirmation result is sent back to the cardissuer. Authentication solutions like this one have already beendeployed for online banking [37]. (3) Distance-verificationdevice (Figure 10c). The user places his smartphone next to thepayment terminal, which starts a distance-verification protocolover a short-range wireless connection, such as NFC [38].

The given approaches require additional user interaction atthe time of the transaction. Changes to established user inter-action models hinder the introduction of new security mecha-nisms [12]. Additionally, the majority of point of sale terminals

11

Payment(card(

Point(of(sale(terminal(

User(

Card(issuer(User(

smartphone(

1. read passcode

2. enter passcode

payment protocol

payment protocol

(a) Smartphone as an authentication tokenreplacement: the user reads a passcode offhis smartphone and enters it into the paymentterminal.

Payment(card(

Point(of(sale(terminal(User(

Card(issuer(User(

smartphone(

2. confirm transaction

1. confirmation request

payment protocol

payment protocol

3. result

(b) Smartphone as a user confirmation de-vice: the user confirms the transaction usinghis smartphone; the devices delivers the user’sdecision to card issuer.

Payment(card(

Point(of(sale(terminal(

User(

Card(issuer(User(

smartphone(

1. place device 2. verify

proximity

payment protocol

payment protocol

(c) Smartphone as a distance verification de-vice: the user positions the phone next to theterminal; the terminal verifies the proximityof the phone over short-range wireless con-nection (e.g, NFC).

Fig. 10: Common smartphone second-factor authentication approaches applied to payment systems. Solid arrows representstandard transaction messages, while dashed arrows show additional messages for second-factor authentication.

do not have the required software components for passcode en-try (Figure 10a) or hardware interfaces for distance-verification(Figure 10c). The replacement of deployed terminals would begradual and optional, which allows the adversary to target theterminals that have not been updated yet.

B. Common Enrollment Solutions

We now explain why commonly suggested enrollmentschemes are not secure or feasible to deploy, assuming anadversary that controls the mobile OS on the victim’s device.

Device Identifier Enrollment

A simple way to bind a user identity to the device key ofhis TEE, is to leverage the device’s IMEI, typically includedin the device certificate. The IMEI is available on the device’spackage or displayed on-screen. During enrollment, the userprovides the IMEI of his device to the card issuer using areliable out-of-band channel, for example, visiting a branchof the card issuer in person. The card issuer then verifies thedevice certificate with respect to the IMEI provided by theuser.

Communicating the IMEI to the card issuer in a trustworthyway is more complicated than it seems. Device sales packagesare not always available. Also, if the mobile OS is compro-mised, the adversary controls the IMEI shown on the devicescreen. Additionally, IMEI-based enrollment does not provideflexible device migration: every time the user changes devices,he must provide the IMEI of the new device to the card issuer,using an out-of-band channel.

Password Enrollment

The user-to-device binding can also be implemented byasking the user to enter a password or a similar initializationsecret, known by the card issuer, in his device. A trustedapplication can authenticate itself to the card issuer, using thecertified device key and the user-provided password.

The user should type in the password only when a trustedapplication can securely receive it. The compromised mobileOS can otherwise intercept and forward the password to theadversary, who can then launch an impoersonation attack. Areliable communication interface from the user to a trustedapplication is called trusted path [39], [40]. The device hard-ware and software resources used for user interaction (e.g.,the display buffer or the touchscreen input events) can betemporarily reserved for system-wide TEEs such as ARMTrustZone. A security indicator, such as a colored bar onthe top of the screen [41] or a dedicated LED [42] can beused to inform the user about the type of application he iscommunicating with (trusted or untrusted). However, currentsmartphones do not support this division of user interfaceresources, nor do they provide dedicated security indicators.Furthermore, several academic studies, and a few decades ofpractical experience, have shown that users tend to ignoresecurity indicators [43], [44], [45].

Previous work assumes that password-based enrollment issecure if the enrollment is done early in the device life cycle,before the adversary has the opportunity to compromise themobile OS [14], [46]. This assumption is hard to justify sincenot every service enrollment happens at the beginning of adevice life time.

SMS Enrollment

If the user provides his phone number during registration,the card issuer can send an SMS message that will be receivedby the device in which the user’s SIM card is installed.Similarly to our solution, the SMS message could carry aninitialization secret to bootstrap security services. The problemwith this approach is that SMS messages provide a trustworthychannel to the the baseband OS of the device where the SIMcard is installed, but not to the secure world on that device.In current mobile device architectures, the baseband OS isaccessible by both the mobile OS in the normal word and bythe trusted applications running in the secure world. Therefore,

12

Normal world (NW)

Mobile'OS'

Secure world (SW)

Trusted'OS'

Mobile device

'Applica4on'processor'' 'Baseband'processor''

Touchscreen'peripheral'

Service'provider'

User'

SMS message

password

password

Baseband'OS'

Fig. 11: Commonly suggested user enrollment schemes. Solidarrows illustrate trustworthy communication channels. Dashedarrows illustrate communication channels in which one of theend points can be either the normal world or the secure world.

when the baseband OS receives an SMS message, it notifies themobile OS, which can read any initialization secret and leakit to the attacker. Assuming a mobile device architecture inwhich the baseband OS interacts only with the secure worldis not feasible, as the mobile OS needs to interact with thebaseband for, e.g., phone calls. To overcome this limitations,the baseband-assisted enrollment scheme uses an enhancedbaseband OS to achieve secure enrollment.

Enrollment Using Initialization Secrets

Figure 11 illustrates the user enrollment problem whenusing initialization secrets. Any channel to the secure worldcan be intercepted by the mobile OS in the normal world, be itthe baseband OS, the user-interface, or any other interface suchas NFC or Bluetooth. For example, the baseband OS cannotpass the initialization secret received over SMS messages tothe application processor because it does not know whichprocessor state (normal world or secure world) is active.

C. Alternative Trusted Execution Environments

In addition to ARM TrustZone, SIM cards are TEEswidely available on smartphones. A SIM card can store secretsand execute small pieces of code (often referred to as SIMapplications) in isolation from the mobile OS. Therefore,one could argue that the location verification mechanism canbe implemented as a SIM application within the SIM cardprocessing environment. This approach has two drawbacks.First, provisioning of SIM applications to a SIM card requiresthe service provider to negotiate with the network operator thatissued that SIM card. Providers who target global applicationsmust negotiate with a large number of network operatorsseparately. Second, in current architectures, SIM cards cannotdirectly access the device peripherals, such as the GPS unit.When the SIM card needs location information, the applicationprocessor must read the coordinates from the GPS unit andprovide them to the SIM card. The SIM application hasno means of knowing whether these coordinates have been

tampered with. Some recent device configurations support adedicated connection between the SIM card and the deviceNFC unit [47]. Similar dedicated lines could be added forsecure access to the GPS unit. However, targeted hardwarechanges to allow for specific security services based on SIMapplications are costly and hard to justify for widespreadadoption.

Some mobile devices are equipped with a slot for SD cards.The latter may be used as a TEE to run code in isolationfrom the mobile OS or to securely store credentials [48],[49]. However, just like SIM cards, SD cards do not havedirect access to the device peripherals, such as the GPS unit,and remote provisioning of applications by third-parties to SDcards is not currently available.

XI. RELATED WORK

Secure payments with location data. Similar to our approach,the authors of [3] propose to mitigate fraud in paymentsat points of sale, using the phone location as an additionalevidence to distinguish between legitimate and fraudulenttransactions. In [3], the bank sends a message to the user phonewith the details of the transactions (including the location ofthe merchant and the one of the phone, as provided by thenetwork operator) and asks the user to confirm the payment.This solution requires changes to (i) the GSM infrastructureto provide the user with the current location of his phone,(ii) the points of sale to handle extra messages and additionalcryptographic operations, and ultimately (iii) the overall userexperience. Furthermore, the protocols in [3] do not accountfor a compromised mobile OS, nor they address enrollment.The authors do assume an adversary who can intercept anycommunication channel and require that the bank shares pair-wise keys with the phone, the mobile network operator, andthe point of sale.

Recently, MasterCard has proposed to use the locationof the card-holder’s smartphone to improve fraud detectionin payments at points of sale [2]. However, the proposal,neither addresses mobile OS compromise, nor enrollment, normigration.

Secure payments with other approaches. Securing online pay-ments with multi-factor authentication is the focus of a numberof work that leverage hardware and software tokens to generateone-time passwords [4], [50], [51], biometric scanners [52],[53], or simply user-remembered passwords [54]. Financialinstitutions are deploying systems that leverage modern smart-phones to replace traditional payment cards and using NFC-enabled point of sale terminals [38], [55]. Such solutions canonly be used at selected stores or face large investments forhardware upgrades at merchants. Other systems that enhancethe security of payment card transactions, require the userto confirm the payment through SMS messages or phonecalls [37].

Secure Enrollment. Secure enrollment for trusted plat-forms [56] and TEEs on mobile devices [11] is a challengingresearch problem. Both deployed systems [4], [5] and aca-demic work [3], [10], [57] have overlooked it or assume anon-compromised OS at enrollment time [14], [46].

Trusted Sensors. Saroiu and Wolman [9] put forward theproblem of trustworthy sensor readings on mobile phones.

13

They propose to leverage virtualization to handle sensorsreadings and provide signed measurements to applications thatrun in guest VMs. A similar approach is considered in [58]where the authors consider participatory sensing scenarios andstudy how to protect user privacy and how to allow for localdata processing while providing (TPM) signed sensor read-ings. Trustworthy participatory sensing applications are alsoconsidered in [59], where the authors design and implement atrusted sensing platform. The latter is a board equipped withsensors and a TPM that communicates with the mobile deviceover Bluetooth and provides signed sensor measurements.

Liu et al. [10] build on top of Credo [60] and TrustZoneto propose software abstractions that expose trusted sensorservices to mobile applications. In particular, [10] focuses onscenarios where trustworthy reading must be processed locallyby applications (e.g., blurring people’s faces from a phototaken by the phone’s camera) before being sent. Thereforethe framework in [10] aims at protecting the integrity of asensor reading as well as the local code that must processit. The authors provide a sample application scenario wheresensor readings account for GPS traces, while data processingapplies noise to the aggregated outcome in order to achievedifferential privacy [61].

Plug-n-Trust [62] focuses on mHealth scenarios and pro-vides a system to protect integrity and confidentiality of datacollected by body-area network of sensors. Their approachleverages a smart card that plugs into a phone’s microSD slotand creates a trusted computing environment for collecting andprocessing data provided by surrounding sensors. Security restsupon tamper resistance of both the smart card and the sensornodes where encryption/authentication keys are stored.

YouProve [57] addresses scenarios where sensor readingsmust be modified by local applications for, e.g., privacy issues.The authors of [57] propose a framework to verify that amodified data item preserves the meaning of the originalsensor reading. YouProve uses TaintDroid [63] to track themeasurement from the moment it is produced by the sensor,until the moment it is uploaded to a service provider. Eachmodification is tracked, and a summary of all changes is signedusing the secret key of the phone’s TPM.

To the best of our knowledge, all previous work ontrusted sensors focuses on designing or developing a trustedcomputing environment on a mobile device, to sign sensorreadings. However, it does not address secure deploymentaspects, including secure enrollment and device migration.To the best of our knowledge, we are the first to proposea complete and deployable solution that allows a number ofapplication scenarios to leverage on-smartphone trusted sensormeasurements.

XII. CONCLUSION

In this paper we proposed a practical solution that adds therequired security to recently proposed location-based second-factor authentication mechanisms for payments at points ofsale. We have identified the necessary requirements for a de-ployable solution, including no changes to the user experienceand to the deployed infrastructure. We have further proposedtwo novel enrollment schemes that enable secure enrollmentand convenient device migration despite a compromised OS.

Through prototype implementations we have shown deploy-ment feasibility of our solution; a location verification opera-tion causes an acceptable delay during a payment transactionand requires only minimal software changes to mobile devices.As future work we plan to integrate the changes we proposedto TrustZone and the baseband OS in a smartphone device, inorder to better assess the performance of our solution.

ACKNOWLEDGMENTS

The authors would like to thank Ramya Jayaram Mastiand Mario Strasser for the useful discussions while writingthis paper. This work was partially supported by the ZurichInformation Security Center (ZISC). It represents the views ofthe authors.

REFERENCES

[1] European Central Bank, “Report on card fraud,” July 2012, http://www.ecb.int/pub/pdf/other/cardfraudreport201207en.pdf.

[2] P. Fourez and Mastercard International Inc., “Location controlson payment card transactions,” http://patentscope.wipo.int/search/en/WO2011022062, 2011, Patent No. WO/2011/022062.

[3] F. S. Park, C. Gangakhedkar, and P. Traynor, “Leveraging cellularinfrastructure to improve fraud prevention,” in Proceedings of the 25thAnnual Computer Security Applications Conference, ser. ACSAC ’09,2009, pp. 350–359.

[4] Barclays, “Mobile PINsentry,” http://goo.gl/pcuGo, last access 2013.[5] Google Inc., “Google 2-Step Verification,” http://www.google.com/

landing/2step/, last access 2013.[6] A. P. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, “A survey

of mobile malware in the wild,” in ACM workshop on Security andprivacy in smartphones and mobile devices, ser. SPSM’11, 2011.

[7] Y. Zhou and X. Jiang, “Dissecting android malware: Characterizationand evolution,” in IEEE Symposium on Security and Privacy, ser. SP’12,2012.

[8] ARM, “Building a Secure System using TrustZone Technology,” http://www.arm.com, 2009.

[9] S. Saroiu and A. Wolman, “I am a sensor, and i approve this message,”in Proceedings of ACM International Workshop on Mobile ComputingSystems and Applications (HotMobile), 2010.

[10] H. Liu, S. Saroiu, A. Wolman, and H. Raj, “Software abstractionsfor trusted sensors,” in The 10th International Conference on MobileSystems, Applications, and Services (MobiSys), 2012.

[11] C. Marforio, N. Karapanos, C. Soriente, K. Kostiainen, and S. Capkun,“Secure enrollment and practical migration for mobile trusted executionenvironments,” in Proceedings of the third ACM workshop on Securityand privacy in smartphones and mobile devices, ser. SPSM’13, 2013.

[12] J. Bonneau, C. Herley, P. C. van Oorschot, and F. Stajano, “The Questto Replace Passwords: A Framework for Comparative Evaluation ofWeb Authentication Schemes,” in 2012 IEEE Symposium on Securityand Privacy, May 2012. [Online]. Available: http://www.cl.cam.ac.uk/⇠jcb82/doc/BHOS12-IEEESP-quest to replace passwords.pdf

[13] R. Guida, R. Stahl, T. Bunt, G. Secrest, and J. Moorcones, “Deployingand using public key technology: lessons learned in real life,” IEEESecurity Privacy, vol. 2, no. 4, 2004.

[14] A. Czeskis, M. Dietz, T. Kohno, D. S. Wallach, and D. Balfanz,“Strengthening user authentication through opportunistic cryptographicidentity assertions,” in Proceedings of the 19th ACM Conference onComputer and Communications Security, ser. CCS’12, 2012, pp. 404–414.

[15] M. Mannan, B. H. Kim, A. Ganjali, and D. Lie, “Unicorn: two-factorattestation for data security,” in Proceedings of the 18th ACM conferenceon Computer and communications security, ser. CCS ’11, 2011, pp. 17–28.

[16] K. Kostiainen, E. Reshetova, J.-E. Ekberg, and N. Asokan, “Old, new,borrowed, blue – a perspective on the evolution of mobile platformsecurity architectures,” in ACM conference on Data and applicationsecurity and privacy, ser. CODASPY’11, 2011.

14

[17] K. Kostiainen, J.-E. Ekberg, N. Asokan, and A. Rantala, “On-boardcredentials with open provisioning,” in International Symposium on In-formation, Computer, and Communications Security, ser. ASIACCS’09,2009.

[18] GlobalPlatform, “Device specifications,” available at: http://www.globalplatform.org/specificationsdevice.asp.

[19] osmocomBB, http://bb.osmocom.org, last access 2013.[20] 3GPP, “3GPP TS 23.040 - Technical realization of the Short Mes-

sage Service (SMS),” http://www.3gpp.org/ftp/Specs/html-info/23040.htm, last access 2013.

[21] Offspark B.V., “PolarSSL,” https://polarssl.org/, last access 2013.[22] ARM, “ARM Motherboard Express,” http://www.arm.com/products/

tools/development-boards/versatile-express/motherboard-express.php.[23] ——, “ARM Coretile Express,” http://www.arm.com/products/tools/

development-boards/versatile-express/coretile-express.php.[24] Sierraware, “Open Virtualization - ARM TrustZone and ARM Hyper-

visor Open Source Software,” http://www.openvirtualization.org/.[25] GlobalPlatform, “GlobalPlatform Device Specifications,” http://www.

globalplatform.org/specificationsdevice.asp, last access 2013.[26] Android Development Team, “Android 4.1 APIs - Jelly Bean,” http:

//developer.android.com/about/versions/jelly-bean.html, 2013.[27] Bouncy Castle Crypto APIs, http://www.bouncycastle.org, last access

2013.[28] G. Inc., “Google Cloud Messaging for Android,” http://developer.

android.com/google/gcm/index.html, last access 2013.[29] CherryPy Team, “CherryPy - A Minimalistic Python Web Framework,”

http://www.cherrypy.org/, 2013.[30] SQLite Development Team, “SQLite,” http://www.sqlite.org, last access

2013.[31] Comcetera Ltd., “Number Portability Lookup,” http://www.

numberportabilitylookup.com/, 2013.[32] EMV, “Integrated Circuit Card Specifications for Payment Systems,

Book 1-4, Version 4.3,” 2011. [Online]. Available: http://www.emvco.com/

[33] Mastercard, “Mastercard Developer Zone,” 2013. [Online]. Available:https://developer.mastercard.com/

[34] VISA, “Visa Developer Program,” 2013. [Online]. Available: https://developer.visa.com/

[35] Telegraph, “EU to end mobile roaming charges nextyear,” June 2013, http://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/telecoms/10119159/EU-to-end-mobile-roaming-charges-next-year.html.

[36] R. Pries, T. Hobfeld, and P. Tran-Gia, “On the suitability of the shortmessage service for emergency warning systems,” in Proceedings of the63rd Vehicular Technology Conference, ser. VTC 2006-Spring, vol. 2,2006, pp. 991–995.

[37] ValidSoft, “ValidPOS,” 2013. [Online]. Available: http://www.validsoft.com/

[38] Google Inc., “Google wallet,” http://www.google.com/wallet/, last ac-cess 2013.

[39] K.-P. Yee, “User interaction design for secure systems,” in InternationalConference on Information and Communications Security, ser. ICICS’02, 2002.

[40] Z. Ye, S. W. Smith, and D. Anthony, “Trusted paths for browsers,” ACMTrans. Inf. Syst. Secur., vol. 8, no. 2, pp. 153–186, 2005.

[41] M. Selhorst, C. Stuble, F. Feldmann, and U. Gnaida, “Towards a trustedmobile desktop,” in International conference on Trust and trustworthycomputing, ser. TRUST’10, 2010.

[42] ARM, “Securing the system with trustzone ready program,” http://www.arm.com/files/pdf/Tech seminar TrustZone v7 PUBLIC.pdf, lastaccess 2013.

[43] S. E. Schechter, R. Dhamija, A. Ozment, and I. Fischer, “The emperor’snew security indicators,” in IEEE Symposium on Security and Privacy,ser. SP’07, 2007.

[44] S. Egelman, L. F. Cranor, and J. Hong, “You’ve been warned: anempirical study of the effectiveness of web browser phishing warnings,”in SIGCHI Conference on Human Factors in Computing Systems, ser.CHI’08, 2008, pp. 1065–1074.

[45] C. Jackson, D. R. Simon, D. S. Tan, and A. Barth, “An evaluationof extended validation and picture-in-picture phishing attacks,” inInternational Conference on Financial cryptography and Internationalconference on Usable Security, ser. FC’07/USEC’07, 2007, pp. 281–293.

[46] K. Kostiainen and N. Asokan, “Credential life cycle management inopen credential platforms (short paper),” in ACM workshop on Scalabletrusted computing, ser. STC’11, 2011, pp. 65–70.

[47] GSM Association, “Requirements for Single Wire Protocol NFC Hand-sets,” http://www.gsma.com/mobilenfc/, 2011.

[48] Giesecke & Devrient GmbH, “G&D Makes Mobile Terminal DevicesEven More Secure with New Version of Smart Card in MicroSDFormat,” http://www.gi-de.com/en/about g d/press/press releases/G%26D-Makes-Mobile-Terminal-Devices-Secure-with-New-MicroSD%E2%84%A2-Card-g3592.jsp, last access 2013.

[49] SD Association, “smartSD Memory Cards,” hhttps://www.sdcard.org/developers/overview/ASSD/smartsd/, last access 2013.

[50] PayPal, “PayPal Security Key,” https://www.paypal.com/securitykey/.[51] RSA, “RSA SecurID,” http://www.emc.com/security/rsa-securid.htm/.[52] “United Bankers’ Bank Authenticates Customers Online,” Biometric

Technology Today, vol. 12, no. 6, p. 4, 2004.[53] “Bank of Utah Adopts Keystroke Dynamics,” Biometric Technology

Today, vol. 15, no. 5, p. 5, 2007.[54] VISA, “Verified by VISA,” http://www.visaeurope.com/en/cardholders/

verified by visa.aspx.[55] JVL Ventures, LLC, “ISIS,” https://www.paywithisis.com/.[56] B. Parno, “Bootstrapping trust in a “trusted” platform,” in Proceedings

of the third Conference on Hot Topics in Security, ser. HOTSEC’08,2008, pp. 9:1–9:6.

[57] P. Gilbert, J. Jung, K. Lee, H. Qin, D. Sharkey, A. Sheth, and L. P.Cox, “Youprove: authenticity and fidelity in mobile sensing,” in SenSys,J. Liu, P. Levis, and K. Romer, Eds. ACM, 2011, pp. 176–189.

[58] P. Gilbert, L. P. Cox, J. Jung, and D. Wetherall, “Toward trustworthymobile sensing,” in Proceedings of ACM International Workshop onMobile Computing Systems and Applications (HotMobile), 2010.

[59] A. Dua, N. Bulusu, and W. chang Feng, “Towards trustworthy partic-ipatory sensing,” in 4th USENIX Workshop on Hot Topics in Security(HotSec), 2009, pp. 1–6.

[60] H. Raj, D. Robinson, T. Tariq, P. England, S. Saroiu, and A. Wolman,“Credo: Trusted computing for guest vms with a commodity hypervi-sor,” Microsoft Research, Tech. Rep. MSR-TR-2011-130, 2011.

[61] C. Dwork, “Differential privacy,” in ICALP (2), ser. Lecture Notes inComputer Science, M. Bugliesi, B. Preneel, V. Sassone, and I. Wegener,Eds., vol. 4052. Springer, 2006, pp. 1–12.

[62] J. Sorber, M. Shin, R. A. Peterson, and D. Kotz, “Plug-n-trust: practicaltrusted sensing for mhealth,” in International Conference on MobileSystems, Applications, and Services, ser. MobiSys’12, 2012.

[63] W. Enck, P. Gilbert, B. gon Chun, L. P. Cox, J. Jung, P. McDaniel, andA. Sheth, “Taintdroid: An information-flow tracking system for realtimeprivacy monitoring on smartphones,” in OSDI, 2010, pp. 393–407.

15