Smartphones as Practical and Secure Location Verification Tokens for Payment

1. Smartphones as Practical and Secure Location Verification Tokens for Payment Claudio M., Nikolaos K., Claudio S., Kari K., Srdjan Č. Slides by: Kyle Wallace

2. 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

3. 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

4. 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

5. Proposal: Location-Based 2FA Card Issuer Location Verification

6. 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

7. 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

8. 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

9. 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

10. 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-IMSIenrollment: • 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

11. 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

12. 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

13. Location Verification • Challenge-response mechanism • Compares GPS location with PoS location • Nonce (arbitrary number) protects against replay attacks

14. 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

15. User Authentication Token • User reads a passcode and enters it into the PoS terminal • Requires additional software and user interactions

16. User Confirmation Device • User confirms the transaction on device • Requires additional software and user interaction

17. Distance Verification Device • User places device next to the terminal to verify (NFC) • Requires additional hardware at PoS, user interaction

18. 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

19. 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

20. 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

21. 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

22. Implementation • Three implementation avenues • Modification of open-source baseband OS • Implement trusted application on TrustZone development board • Client-server prototype using Android smartphone

23. 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)

24. 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

25. 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

26. 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

27. 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

28. Static Test

29. 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

30. 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

31. 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

32. 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

33. 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

34. Thank you! Questions?