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 Fraud • 2010: 1.26b EUR total fraud in Single Euro Payments Area http://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-TwoFactor-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 timeslicing 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?