Transcript Slides

Smartphones as Practical and Secure
Location Verification Tokens for Payment
Claudio M., Nikolaos K., Claudio S., Kari K., Srdjan Č.
Slides by: Kyle Wallace
• 2010: 1.26b EUR total fraud in Single Euro Payments Area
Two Factor Authentication
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-based 2FA solution for payments at PoS
• Construction of two enrollment schemes
• Demonstrate solution is easily deployed
• Survey and analyze current 2FA schemes
• 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
• State swapping in timeslicing manner
• Both OSes have access to
hardware peripherals
• Can restrict access to some
• 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 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
• Compares GPS
location with PoS
• 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
• 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
• 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
• Location-based 2FA is both practical and feasible
• Implementation requires no change in user experience or deployed
• Enrollment in location-based 2FA is both flexible and requires few
• Experiments show minimal delay overhead
Thank you!