Ch 9: Mobile Payments. CNIT 128: Hacking Mobile Devices. Updated

Transcription

1 Ch 9: Mobile Payments CNIT 128: Hacking Mobile Devices Updated

2 Current Generation

3 Scenarios Mobile banking apps NFC-based or barcode-based payment apps used by consumers to purchase goods Premium-rated SMS messages to purchase virtual goods within games, or music Users are billed later via their telephone bill

4 Mobile Banking Apps Banking transactions using a phone View account balances Transfer money Web applications designed to be viewed within the mobile browser Or a WebView inside a native mobile app

5 Mobile Banking Apps Back-end components are the same as for desktop online banking Similar vulnerabilities But with mobile, must also consider device theft Sensitive information may be stored on the device improperly

6 Started in 2011 Supports all major credit cards Card # stored in the cloud A virtual account number is sent to the contactless POS terminal via NFC Contactless Payment Google Wallet

7 Contactless Payment ISIS (now Softcard) Joint venture of Verizon, AT&T, and T-Mobile Began in 2012 Changed its name in 2014 because of the "Islamic State" (link Ch 9a) Purchased by Google in Feb., 2015 Google Wallet will be prominently preinstalled on U.S. Android phones that run KitKat (4.4) or later (link Ch 9e)

8 Android Pay Google's new payment system Replaced Google Wallet for most purposes in 2015 Google Wallet can no longer use NFC No app needed on most phones Android Pay is integrated into the OS Link Ch 9w

9 Security of Mobile Payments Links Ch 9y, 9z

10 Security of Mobile Payments Should be safer than magstripe cards, which are very insecure But customers are wary Link Ch 9x

11 Apple Pay Released on Oct 20, 2014 With iphone 6 and Apple Watch Customer payment information is kept from retailer creates a "dynamic security code [...] generated for each transaction" Link Ch 9d

12 Market History Google was first, but retailers didn't play along Only 2.4% of retailers had NFC in Oct, 2014 Chip-and-PIN deadline was Oct Retailers must update POS systems or accept liability for credit card fraud (link Ch 9c) But the USA actually uses Chip-without-PIN Security done on the server side

13 Only available on Samsung devices Works with NFC or magstripe readers 90% of merchants Samsung Pay

14 Samsung Pay

15 Link Ch 9z1 Samsung Pay

16 US Retailers Prefer Apple Pay Link Ch 9z2, from Feb., 2017

17 CurrentC A group of merchants (MCX) Rite-Aid, CVS, Walmart, Target, etc. Saves merchants credit card processing fees Gives stores access to consumer data Unlike Apple Pay Link Ch 9b, 9h Designed for merchants, not end-users

18 How CurrentC Works Tied directly to your bank account Pay with QC code

19 Retailers Supporting CurrentC

20 CurrentC Collects Health Data

21 CurrentC Hacked in Oct addresses of early testers exposed Link Ch 9j

22 Lin Ch 9z3 Current-C Died in 2016

23 Square Free card reader or stand Plugs into audio jack on ios or Android phone Takes credit card payments by reading the magstripe Used by Starbucks and Whole Foods Began taking Bitcoin in 2014 Will take Apple Pay in 2015

24 Contactless Smartcard Payments

25 Secure Element (SE) Core of the mobile payment platform Secure storage of sensitive information Embedded SE contained within the mobile device Galaxy Nexus UICC aka SIM card Universal Integrated Circuit Card Another SE form factor Link Ch 9m

26 microsd Cards with NFC Allowed early iphones without NFC to use NFC NFC radio included in the microsd card Pioneered by DeviceFidelity Purchased by Kili in 2014 Kili purchased by Square in 2015 Links Ch 9o, p, q

27 Java Card Runtime Environment (JCRE) All SE's use this system Payment applet stored on the card Applet firewall keeps applets from accessing each others' information Robust cryptography including AES and RSA SE's are GlobalPlatform compliant

28 Security and interoperability standards for SE devices Only the owner of an SE can directly read or write to it Mutual identification uses shared keys SE will lock after a number of failed attempts

29 Proximity Payment System Environment (PPSE) Registry of all payment apps in the SE App names and standard Application Identifier Tells the payment terminal what apps are available Allows terminal to select which app it wants to use

30 Payment Apps Responsible for making the actual contactless payment Contain sensitive information associated with a particular payment account Java Card applets that are stored and run inside the SE

31 Payment Apps Cryptographic capabilities of the JCRE allow banks to securely verify transactions One method is to generate a one-time Card Verification Value for each transaction, called a dynamic CVV (dcvv) Application Protocol Data Unit (APDU) Used to send instructions to applets on the SE

32 Command Application Protocol Data Unit (C-APDU)

33 Large Commands If the amount of data to be transmitted to the applet is greater than 256 bytes Multiple C-APDUs can be chained together

34 Response Application Protocol Data Unit (R-APDU)

35 Contact and Contactless Interfaces These are the two ways to send APDUs to the SE Contact Interface Connects the SE to the phone itself Contactless Interface Connected to the NFC radio Used to communicate with Point-of-Sale (POS) terminals Not available to applications on the phone

36 Simplified Contactless Transaction

37

38 Secure Element API Restricted to Google Wallet on Android Introduced in (Gingerbread) Required system-level permissions through 4.0 (Ice Cream Sandwich) In 4.04, allows apps with a signature in /etc/nfcee_access.xml The only signature in that file is Google Wallet Requires root access to update

39 SE API Limitations Very basic allows application to open a channel to the SE and transmit APDUs Works for embedded SE's But not for the UICC or microsd SE's used in some phones For microsd SE's, you need the open-source Secure Element Evaluation Kit (SEEK) UICC SE's is not directly connected to the application processor and must be reached through the proprietary code and the Radio Interface Layer

40 Access Control for SE's Embedded SE's use a whitelist /etc/nfcee_access.xml SEEK uses GlobalPayment An additional app on the SE with a list of application signatures and applets Smartcard API contains Access Control Enforcer Compares signature of calling application to signature stored in the SE card to see if application has permission for the chosen applet

41 Mobile Application Consumers see this part User selects which card to use for a payment Google Wallet requires the user to enter a four-digit PIN to make a payment Protects against device theft Better than contactless credit cards

42 Google Wallet Vulnerabilities

43 PIN Storage Vulnerability PIN entry required for transactions Only six tries permitted But an attacker who steals a device and then roots it can extract the PIN from the salted hash Because it's not stored on the SE Storing it on the SE would make banks liable for breaches due to stolen PINs Links Ch 9s, 9t

44 Link Ch 9t (2012)

45 PIN Storage PIN is salted with a 64-bit random value and hashed with one round of SHA-256

46 Storage of Hash Salt and hash stored in a SQLite database in Google Wallet's /data directory /data/data/ com.google.android.apps.walletnfcrel/ databases/walletdatastore "Wallet Cracker" simply tries all 10,000 four-digit PINs to find PIN from the hash

47 Google's Response Don't run Google Wallet on rooted phones Not very reassuring since the thief can root your phone Much better to perform PIN storage and verification on the SE Also store the PIN try counter on the SE

48 Countermeasures for Google Wallet Cracker Don't root your device Enable Android lock screen Disable ADB debugging Keep up-to-date with patches

49 Relay Attacks (MITM) "Mole" reader gets close to target mobile device Attacker's mobile gets near POS terminal APDUs are passed via TCP/IP

50 Relay Attack Limitations Target's mobile payment app must be unlocked Google Wallet requires entry of a PIN to unlock

51 Relay Through a Malicious App Works against Google Wallet Because it exposes payment credentials to the contact interface Requires root privileges to bypass SE API signature authentication

52 Relay Attack Countermeasures Contactless POS terminals should enforce a timeout on all transactions Relay attack requires network communications which slows it down Not very practical because errors can cause delays in legitimate transactions Use location information to flag suspicious transactions Target mobile is not really near the POS Requires target GPS to be active and consumer's consent

53 Relay Attack Countermeasures Google Wallet is no longer vulnerable to the second attack It no longer exposes payment applets over the contact interface

54 Square Vulnerabilities

55 Square Square Register Mobile app Magnetic stripe reader Plugs into audio jack Free Allows anyone to take credit card transactions Charging 2.75% of each transaction

56 EMV (Europay, MasterCard and Visa) aka Chip-and-PIN Square reader has two slots Can use magstripe or chip

57 Skimming Any app that can receive audio data can steal the magnetic data from the Square device VeriFone released an app to do this In order to compete with Square

58 Link Ch 9u Verifone v. Square

59 Skimming Countermeasures Manual skimming requires the card Same as skimmers that have been used for years A software attack against the reader could do more harm In 2012, Square modified their reader to encrypt the audio stream Encrypted data is sent to Square's servers and decrypted there Prevents rogue apps getting the credit card #

60 Replay Attack Malicious app could record audio stream and replay is back to make another purchase Demonstrated by Adam Laurie and Zac Franken at Black Hat in 2011 Also reverse-engineered the format Square reader uses for data from credit card They could manufacture correct audio streams from magnetic Track 2 data, which can be purchased on the black market

61 Replay Attack They could therefore use Square to perform mass fraud Instead of manufacturing fake credit cards

62 Replay Attack Countermeasures Square's encryption prevents this Textbook author verified that replaying an encrypted audio stream is not accepted as a valid Square transaction anymore So Square is changing the key, or using a nonce, or something similar