Smartphones as Practical and Secure Location Verification Tokens for Payment

Smartphones as Practical and Secure Location Verification Tokens for

Payment

Claudio M., Nikolaos K., Claudio S., Kari K., Srdjan Č.

Slides by: Kyle Wallace

Fraud

• 2010: 1.26b EUR total fraud in Single Euro Payments Areahttp://www.thehiddenwiki.net/wp-content/uploads/2013/08/credit-cards_2007247b.jpg

Two Factor Authentication

http://www.hanselman.com/blog/content/binary/Windows-Live-Writer/Setting-up-Two-Factor-Authentication-for_9835/image_3.png

http://www.snsbankcard.com/images/hypercom4220.png

Issues with Traditional 2FA

• Adds unnecessary delay at PoS

• Payment terminal at PoS hard to universally modify

• Interrupts/complicates user experience

• Mobile OS not always trustworthy

Proposal: Location-Based 2FA

Card Issuer

Location Verification

Contributions

• Location-based 2FA solution for payments at PoS

• Construction of two enrollment schemes

• Demonstrate solution is easily deployed

• Survey and analyze current 2FA schemes

Goals

• Implementation must not change user interaction or PoS• Changing user interaction makes adoption difficult• Changing PoS is difficult due to scale

• Solution must be secure even if mobile OS is compromised• Assuming mobile OS is trustworthy is infeasible, platform too complex

• Enrollment scheme must bind user identity to a device• Solution must support device migration

Mobile Architecture

• Two OSes: Normal and trusted• State swapping in time-

slicing manner

• Both OSes have access to hardware peripherals• Can restrict access to

some peripherals

• Code in SW must be signed by trusted authority

Proposed Solution

• Requires two applications• NW: Companion application• SW: Trusted application• Completed enrollment

scheme

• Location data utilized by card issuer to verify payment• Location is fairly ubiquitous• Any sensor could be used

User Enrollment

• Verifier must bind user identity to TEE on user’s device• Device and issuer share a secret service key after enrollment

• Two schemes:• Signed-IMSI enrollment:

• Easier to deploy • Only withstands software attackers

• Baseband-Assisted enrollment: • Withstands hardware attackers as well• Requires minor changes to baseband OS

• Both schemes support device migration

Signed-IMSI Enrollment

• Utilizes the SIM identifier (IMSI) and mobile network infrastructure to verify

• Baseband verifies connection to mobile network (no fake SIM/IMSI)

• Sealed key can be stored in the normal world

Broadband-Assisted Enrollment

• Utilizes a specially crafted SMS, decoded in the baseband• Baseband OS must be

changed to compute authentication tag

• SMS enrollment key is used to authenticate device IMEI

• Device and card issuer now share service key

Location Verification

• Challenge-response mechanism

• Compares GPS location with PoS location

• Nonce (arbitrary number) protects against replay attacks

Alternative Approaches

• Three traditional 2FA approaches to compare to:• Smartphone as an authentication token• Smartphone as a user confirmation device• Smartphone as a distance verification device

• Three traditional enrollment schemes to compare to:• Device Identifier Enrollment• Password Enrollment• SMS Enrollment

User Authentication Token

• User reads a passcode and enters it into the PoS terminal

• Requires additional software and user interactions

User Confirmation Device

• User confirms the transaction on device

• Requires additional software and user interaction

Distance Verification Device

• User places device next to the terminal to verify (NFC)

• Requires additional hardware at PoS, user interaction

Enrollment Schemes

• Device Identifier: Provide the card issuer IMEI out-of-band• Does not facilitate device

migration

• Password: User enters secret password to enroll• Password easily intercepted in

compromised OS

• SMS: Send special SMS to user containing secret code• Baseband OS accessible to both

secure and normal world

Adversarial Model

• Attacker has access to:• Victim’s payment card (or clone thereof)• PIN number (if any)

• Different modes of attack have different access:• Software attacker has access to mobile OS on victim’s device• Hardware attacker has similar hardware to the victim’s device

• Attacker can never touch the cell network or spoof GPS

• Adversary must convince card issuer that victim’s phone is at PoS

Signed-IMSI Security

• Strategy a: Encrypt service key on adversary device• Start enrollment scheme on own device with target’s UID• Must use custom SIM to spoof the IMSI • Custom SIM will not authenticate with network

• Strategy b: Encrypt service key under public, attacker knows private• Attacker does not have access to TrustZone secrets• Attacker does not have a certified by device manufacturer public key

Baseband-Assisted Security

• Strategies a & b:

• Intercept the SMS and extract enrollment key• Adversary does not control cell networks, SMS cannot be intercepted

• Provide a crafted IMEI to the OS• IMEI is stored in read-only memory – cannot be faked

Implementation

• Three implementation avenues

• Modification of open-source baseband OS

• Implement trusted application on TrustZone development board

• Client-server prototype using Android smartphone

Baseband Implementation

• Augmented the osmocomBB (only available open source baseband)

• For special SMS, utilized SMS Protocol Data Unit mode• Enrollment key encoded in the Information Element Data field

• Baseband augmented with logic to parse special SMS message• HMAC-SHA1 implementation for authentication tag

• Implemented in 523 lines of code (451 in SHA1 implementation)

TrustZone Implementation

• Trusted application implemented on TrustZone board• Application generates location statements• Trusted application accounts for 150 lines of code

• Location verification generated in secure world by trusted application• GPS emulated via custom system call to return coordinates

• Enrollment scheme not implemented due to lack of baseband processor• Signed-IMEI requires only GET_SIM_STATUS and GET_IMSI• Baseband enrollment has no communication between baseband and secure

world

Client-Server Implementations

• Client prototype implements both normal and secure world apps• Developed on Android 4.1 “Jelly Bean”

• Provides functionalities for signed-IMSI enrollment and location verification

• Server side implemented in python (CherryPy + SQLite)• API provides enrollment and location verification operations

Experimental Evaluation

• Focused mainly on location verification• Enrollment is a one-time operation

• Client prototype: Samsung Galaxy S3

• Static Tests: Phone is in fixed scenario (measured completion time)

• Field Study: Phone is in a scenario close to actual deployment

Static Test

• Client device is fixed on a desk in an office environment• Test for Edge (GSM), 3G (WCDMA), and WiFi

One second delay

Thirty second delay

Static Test

Field Study

• Two test devices, each on different carriers (Orange, Sunrise)

• Triggering device to act as a PoS terminal

• Results• Accuracy good enough to distinguish adjacent shops• Average delay is very short, max is tolerable

Integration of Solution

• Acquirer: Banking institution

• ARQC: Application Request Cryptogram• Transaction amount & Date• Random nonce

• ARPC: Application Reply Cryptogram• Approval message

• Solution facilitates gradual deployment to users without service interruption

Other Concerns

• Solution assumes internet connectivity at time of transaction• SMS communication (high delay)• Track low-value transactions with a log

• Card issuer can ask for user’s device location, track user• If protocol is used as intended, will only tack purchase locations• Have issuer send location of PoS, compare locations on device

Other Applications

• Framework can be used in any scenario where verifying party knows the user’s phone number and infrastructure

• Ex1: Public Transportation• Lost/stolen tickets are verified against location• Delay may be too long for public transportation

• Ex2: Building Access• Unique token + location verification at point of entry• Accuracy high enough to differentiate between doors

Conclusion

• Location-based 2FA is both practical and feasible

• Implementation requires no change in user experience or deployed infrastructure

• Enrollment in location-based 2FA is both flexible and requires few changes

• Experiments show minimal delay overhead

Thank you!

Questions?