Ch 9: Mobile Payments CNIT 128: - PowerPoint Presentation

1. Ch 9: Mobile PaymentsCNIT 128:Hacking Mobile Devices

2. Current Generation

3. ScenariosMobile banking appsNFC-based or barcode-based payment apps used by consumers to purchase goodsPremium-rated SMS messages to purchase virtual goods within games, or musicUsers are billed later via their telephone bill

4. Mobile Banking AppsBanking transactions using a phoneView account balancesTransfer moneyWeb applications designed to be viewed within the mobile browserOr a WebView inside a native mobile app

5. Mobile Banking AppsBack-end components are the same as for desktop online bankingSimilar vulnerabilitiesBut with mobile, must also consider device theftSensitive information may be stored on the device improperly

6. Contactless PaymentGoogle WalletStarted in 2011Supports all major credit cardsCard # stored in the cloudA virtual account number is sent to the contactless POS terminal via NFC

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

8. Android PayGoogle's new payment systemWill let developers use it in various ways through an API"will tokenize card numbers, in the same way that Apple Pay and Samsung Pay do, meaning it generates a one-time payment token...for each transaction"No timeline for release yet, more info. expected at Google I/OLink Ch 9g

9. Apple PayReleased on Oct 20, 2014With iPhone 6 and Apple WatchCustomer payment information is kept from retailercreates a "dynamic security code [...] generated for each transaction"Link Ch 9d

10. Market HistoryGoogle was first, but retailers didn't play alongOnly 2.4% of retailers had NFC in Oct, 2014Chip-and-PIN deadline is Oct. 2015Retailers must update POS systems or accept liability for credit card fraud (link Ch 9c)

11. Samsung PayTo be available in summer 2015Only on Samsung Galaxy S6Works with NFC or magstripe readers90% of merchants

12. CNN InfographicGo Through Link Ch 9f

13. CurrentCA group of merchants (MCX)Rite-Aid, CVS, Walmart, Target, etc.Saves merchants credit card processing feesGives stores access to consumer dataUnlike Apple PayLink Ch 9b, 9hDesigned for merchants, not end-users

14. How CurrentC WorksTied directly to your bank accountPay with QC code

15. Retailers Supporting CurrentC

16. CurrentC Collects Health Data

17. CurrentC Hacked in Oct. 2014Email addresses of early testers exposedLink Ch 9j

18. WocketSmart wallet, no phone requiredLink Ch 9i

19. SquareFree card reader or standPlugs into audio jack on iOS or Android phoneTakes credit card payments by reading the magstripeUsed by Starbucks and Whole FoodsBegan taking Bitcoin in 2014Will take Apple Pay in 2015

20. Contactless Smartcard Payments

21. Secure Element (SE)Core of the mobile payment platformSecure storage of sensitive informationEmbedded SE contained within the mobile deviceGalaxy NexusUICC aka SIM cardUniversal Integrated Circuit CardAnother SE form factorLink Ch 9m

22. microSD Cards with NFCAllowed early iPhones without NFC to use NFCNFC radio included in the microSD cardPioneered by DeviceFidelityPurchased by Kili in 2014Kili purchased by Square in 2015Links Ch 9o, p, q

23. Java Card Runtime Environment(JCRE)All SE's use this systemPayment applet stored on the cardApplet firewall keeps applets from accessing each others' informationRobust cryptography including AES and RSASE's are GlobalPlatform compliant

24. Security and interoperability standards for SE devicesOnly the owner of an SE can directly read or write to itMutual identification uses shared keysSE will lock after a number of failed attempts

25. Proximity Payment System Environment (PPSE)Registry of all payment apps in the SEApp names and standard Application IdentifierTells the payment terminal what apps are availableAllows terminal to select which app it wants to use

26. Payment AppsResponsible for making the actual contactless paymentContain sensitive information associated with a particular payment accountJava Card applets that are stored and run inside the SE

27. Payment AppsCryptographic capabilities of the JCRE allow banks to securely verify transactionsOne 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

28. Command Application Protocol Data Unit (C-APDU)

29. Large CommandsIf the amount of data to be transmitted to the applet is greater than 256 bytesMultiple C-APDUs can be chained together

30. Response Application Protocol Data Unit (R-APDU)

31. Contact and Contactless Interfaces These are the two ways to send APDUs to the SEContact InterfaceConnects the SE to the phone itselfContactless InterfaceConnected to the NFC radioUsed to communicate with Point-of-Sale (POS) terminalsNot available to applications on the phone

32. Simplified Contactless Transaction

33.

34. Secure Element APIRestricted to Google Wallet on AndroidIntroduced in 2.3.4 (Gingerbread)Required system-level permissions through 4.0 (Ice Cream Sandwich)In 4.04, allows apps with a signature in /etc/nfcee_access.xmlThe only signature in that file is Google WalletRequires root access to update

35. SE API LimitationsVery basic—allows application to open a channel to the SE and transmit APDUsWorks for embedded SE'sBut not for the UICC or microSD SE's used in some phonesFor 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

36. Access Control for SE'sEmbedded SE's use a whitelist /etc/nfcee_access.xmlSEEK uses GlobalPaymentAn additional app on the SE with a list of application signatures and appletsSmartcard API contains Access Control EnforcerCompares signature of calling application to signature stored in the SE card to see if application has permission for the chosen applet

37. Mobile ApplicationConsumers see this partUser selects which card to use for a paymentGoogle Wallet requires the user to enter a four-digit PIN to make a paymentProtects against device theftBetter than contactless credit cards

38. Google Wallet Vulnerabilities

39. PIN Storage VulnerabilityPIN entry required for transactionsOnly six tries permittedBut an attacker who steals a device and then roots it can extract the PIN from the salted hashBecause it's not stored on the SEStoring it on the SE would make banks liable for breaches due to stolen PINsLinks Ch 9s, 9t

40. PIN StoragePIN is salted with a 64-bit random value and hashed with one round of SHA-256

41. Storage of HashSalt 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

42. Google's ResponseDon't run Google Wallet on rooted phonesNot very reassuring since the thief can root your phoneMuch better to perform PIN storage and verification on the SEAlso store the PIN try counter on the SE

43. Countermeasures for Google Wallet CrackerDon't root your deviceEnable Android lock screenDisable ADB debuggingKeep up-to-date with patches

44. Relay Attacks (MITM)"Mole" reader gets close to target mobile deviceAttacker's mobile gets near POS terminalAPDUs are passed via TCP/IP

45. Relay Attack LimitationsTarget's mobile payment app must be unlockedGoogle Wallet requires entry of a PIN to unlock

46. Relay Through a Malicious AppWorks against Google WalletBecause it exposes payment credentials to the contact interfaceRequires root privileges to bypass SE API signature authentication

47. Relay Attack CountermeasuresContactless POS terminals should enforce a time-out on all transactionsRelay attack requires network communications which slows it downNot very practical because errors can cause delays in legitimate transactionsUse location information to flag suspicious transactionsTarget mobile is not really near the POSRequires target GPS to be active and consumer's consent

48. Relay Attack CountermeasuresGoogle Wallet is no longer vulnerable to the second attackIt no longer exposes payment applets over the contact interface

49. Square Vulnerabilities

50. SquareSquare RegisterMobile appMagnetic stripe readerPlugs into audio jackFreeAllows anyone to take credit card transactionsCharging 2.75% of each transaction

51. EMV (Europay, MasterCard and Visa) aka Chip-and-PINMuch saferNew Square reader coming out in Oct. 2015Link Ch 9u

52. SkimmingAny app that can receive audio data can steal the magnetic data from the Square deviceVeriFone released an app to do thisIn order to compete with Square

53. Verifone v. SquareLink Ch 9u

54. Skimming CountermeasuresManual skimming requires the cardSame as skimmers that have been used for yearsA software attack against the reader could do more harmIn 2012, Square modified their reader to encrypt the audio streamEncrypted data is sent to Square's servers and decrypted therePrevents rogue apps getting the credit card #

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

56. Replay AttackThey could therefore use Square to perform mass fraudInstead of manufacturing fake credit cards

57. Replay Attack CountermeasuresSquare's encryption prevents thisTextbook author verified that replaying an encrypted audio stream is not accepted as a valid Square transaction anymoreSo Square is changing the key, or using a nonce, or something similar