Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Demystifying Host Card Emulation Security - Best Practices for Implementing Secure Mobile Payments

2,236 views

Published on

Host Card Emulation - the ability to emulate payment card on a mobile device without dependency on special Secure Element hardware - opens a whole new chapter for mobile payment applications, which are recently springing out like mushrooms after the rain of HCE. But will these "mushrooms" turn out to be delicious, barely edible, or maybe rather poisonous? Does the security assured by vendor always reflect actual implementation? What could possibly go wrong? How these applications could be attacked? Based on several assessments, we will answer these questions, and leave the audience with best practices on how to mitigate the risks.

Understand what Host Card Emulation is, how the technology works and what the limitations are
Determine what security features are ensured by OS level, and what is left for the mobile application developers
Identify possibilities to attack mobile payment applications, attack conditions and risks
Analyse implementation shortcomings captured during assessments
Identify security mechanisms possible to implement in order to mitigate the risk, guidelines and best practice

Published in: Technology

Demystifying Host Card Emulation Security - Best Practices for Implementing Secure Mobile Payments

  1. 1. Next Presentation begins at 13:00 Demystifying Host Card Emulation Security - Best Practices for Implementing Secure Mobile Payments Slawomir Jasek Wojtek Dworakowski IT Security Expert IT Security Expert
  2. 2. Demystifying HCE Security - Best Practices for Secure Mobile Payments Slawomir Jasek Wojtek Dworakowski IT Security Expert IT Security Expert
  3. 3. Wojtek Dworakowski - SecuRing CEO (since 2003) - OWASP Poland Chapter Leader $ login Slawomir Jasek - IT Security Expert at SecuRing - since 2005, and still loves this job
  4. 4. • Background info • History, uses of SE/HCE, Secure Element operation, HCE intro • Risks • Possible attacks • HCE vs SE • Best practices, example vulnerabilities • Summary • Q&A Agenda
  5. 5. Background brief
  6. 6. Mobile payments How did we get here? 2008 First concatless payment cards. 2009 First pay-by-mobile service (UK) 2011 Galaxy Nexus – Google Wallet, Secure Element 2012 First HCE experiments (SimplyTapp, Blackberry) 2013 Android 4.4 supports HCE 2014 Visa, Mastercard HCE support, first commercial implementations 2015 Apple Pay enters UK 2016 Android Pay enters UK
  7. 7. Image sources: Orange, http://www.storagenewsletter.com/, http://9to5mac.com/ Secure Element (SE) API exposing only functions, not data Similar to physical contactless card • Memory • Processor • Applet (javacard) „Tamper-resistant platform (typically a one-chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g., key management) in accordance with the rules and security requirements set forth by a set of well-identified trusted authorities.” globalplatform.org • SIM card • Built in • SD card
  8. 8. Secure Element OS Mobile app Applet NFC Antena Secure Element Card data, payment services • Apps and OS have no access to card data and to communication during payment. • User-land application are only for configuration, monitoring, payment initiation SE communicates directly with NFC module
  9. 9. Android >=4.4, Blackberry OS, Windows Phone Software can emulate any contactless smart card • No direct communication between app and NFC • NFC communication implemented in OS API Host-based Card Emulation (HCE) No API nor requirements for storing card data and for secure transmission Security should be explicitly implemented by app OS Payment app
  10. 10. Mobile payments Mobile tickets Reward programs Physical security Hotel room access Car/bicycle rental … The sky is the limit! Image sources: https://www.ximedes.com, http://www.ibonus.net/, http://www.frugalprototype.com/, HCE uses
  11. 11. HCE vs app developer The most important security aspects are fully dependent on programmer Payment companies defined sets of security rules and validation process • The requirements "state minimum level of security", • They do not introduce technical details of available options, best practices, risk vs cost analysis... • Connected servers and back-end systems are not in scope of security assessment
  12. 12. Mobile payments risks Selected attacks scenarios
  13. 13. Attack #1 – relay Graphics source: https://sourceforge.net/p/nfcproxy/wiki/Home/ • Same risk profile as for any contactless card • Very close proximity (mostly will not work through the bag) • Short window of oportunityNFC Proxy
  14. 14. Secure Element • The NFC usually works also with the phone turned off (even dead battery). • Easier to approach unsuspecting victim's phone. Host Card Emulation • NFC works only with the screen turned on (and – optionally – unlocked). • More difficult to attack without the victim's notice. Attack #1 – relay Additional risk mitigations • Business/UX decisions: enforce PIN for every transaction, SE: activate NFC antenna only on demand HCE: activate NFC antenna on screen unlock • Communication delays due to proxing could be detected
  15. 15. Attack #2 – EMV downgrade • Attacker simulates old, "magstripe" card reader mode to victim's card. • Pre-plays all possible "challenge" values from terminal, and forces the card to compute valid responses. • Use matching response with the actual terminal. Risk mitigations, attack conditions • Requires physical contact with the victim's card for longer amount of time (at least several minutes) • Possible to invoke one transaction only, the victim cannot use the card in the meantime • Depends on terminal configuration and generation of "unpredictable numbers" • Attack possible to detect on the issuer's side https://www.blackhat.com/docs/us-15/materials/us-15-Fillmore-Crash-Pay-How- To-Own-And-Clone-Contactless-Payment-Devices.pdf
  16. 16. Attack #3 – steal card data in transit Mobile wallet app Payment processorBank Third party HCE LIB NFC Contactless Card reader "Secure Element in the cloud" server Online payment processing system Google Cloud Messaging Mobile wallet server Bank's Card management system
  17. 17. Secure Element on SIM • Card data transmitted OTA by GSM network. • Theoretical possibility to intercept GSM communication. Risk: low • The card data is transmitted only once to mobile device. • Intercepting GSM is still not trivial Host Card Emulation • Usually tokenized card data pushed to device from the "cloud", e.g. by Google Cloud Messaging Risk: depends on implementation details • Encryption layers • Authentication, device fingerprinting... • Various application features (more on this later) Attack #3 – steal card data in transit
  18. 18. Attack #4 – popular malware (no root) Most popular mobile malware at this moment does not utilize "root" access. Attack involves displaying overlay on top of targeted mobile app to steal credentials. Secure Element • Mobile application does not have access to card data. Stealing app credentials will not reveal card data. • Malware will not be able to invoke applet API, as it verifies the mobile application signing key. Host Card Emulation • Depending on implementation, stealing mobile app credentials may help with access to card data • Mobile application vulnerabilities (e.g. IPC, data storage) can be exploited by other applications on the same device
  19. 19. Secure Element • Card data is not accessible for mobile operating system. Root access does not help to steal the PAN. • Malware as "proxy" between SE and NFC? Rather not possible, applet should verify source of communication (OS vs NFC antenna). Attack #5 – malware with root access OS Mobile app Card data OS Mobile app Applet Host Card Emulation • Root can access mobile application storage, including card data. • The attacker has all the information necessary to "clone" the card on a different physical device. root > Device Administrator
  20. 20. Malware with root – is it real? https://www.bluecoat.com/security-blog/2016-04- 25/android-exploit-delivers-dogspectus-ransomware • Works on almost all Android 2.x – 6.0 devices • Root exploit deployed from cloud, based on device model and ROM version
  21. 21. CDCVM + malware with root? CDCVM – mobile app authorization instead of PIN. Malware can intercept PIN and make fraud payment without limits.
  22. 22. Other vectors… Stealing Altering AID routing table Attack on services in the cloud Fake POS (e.g. PAN gathering + CNP fraud) Power analysis Social engineering Apple Pay provisioning fraud …
  23. 23. HCE best practices Details and example vulnerabilities
  24. 24. Image:http://www.smartcardalliance.org/downloads/EMV- Tokenization-Encryption-WP-FINAL.pdf Tokenization • Many one-time random "surrogate" card numbers (tokens) replacing single static PAN • Generated server-side, distributed to mobile application ("secure element in the cloud") • Mobile application stores several consecutive values (for offline use) • The token can be limited – specific merchant or channel – time – capped to max amount
  25. 25. Typical architecture Mobile wallet app Payment processorBank Third party HCE LIB NFC Contactless Card reader "Secure Element in the cloud" server Online payment processing system Google Cloud Messaging Mobile wallet server Bank's Card management system
  26. 26. Tokenization - questions • How are the card tokens transmitted? • Google Cloud Messaging push, third party servers? • How is the data encrypted? What is the key? • What is required to renew the tokens? • Does this operation involve user authorization, or is handled automatically by the background service? • What comprises the authentication key to get the tokens?
  27. 27. Code obfuscation Good practice: even using free ProGuard you can alter default settings to make it more secure. Original source: ProGuard compression (most common)
  28. 28. Code obfuscation Commercial obfuscator:
  29. 29. Data at rest encryption Several encryption options: • Static key hardcoded in application code • Individual device-specific key (generated from e.g. deviceid) • Individual per-installation key • Key has to be unlocked with additional user authorization (e.g. fingerprint, password). Lower risk, worse UX. Risk Compliance requirement: Sensitive data at rest must be securely protected. Card data is stored in application private folder.
  30. 30. Data at rest – example vulnerabilities Data stored on the device (2011) SQLite databases including credit card balance, limits, expiration date, name on card, last 4 card digits, email account, transaction dates, locations and more: https://www.nowsecure.com/blog/2011/12/12/forensic- security-analysis-of-google-wallet/ Offline brute-force (2012) PIN stored as SHA-1 hash on the device. The PIN can only be a 4-digit numeric value, so offline brute-force attack would only require calculating, at most, 10,000 SHA256 hashes: https://zvelo.com/google-wallet-security-pin-exposure- vulnerability/
  31. 31. Integrity protections • Was the application installed from official Play Store? • Is the application signed by proper developer's key? • Is the debug mode on? • Does it work on emulator or real device? • Mechanisms to enforce upgrade, do not allow rollback to earlier versions • Deactivation and wipe on compromise detection • Notifications, reporting • ...
  32. 32. Integrity protections – details matter How are the protections implemented? Simple boolean to switch in binary (Xposed modules) vs Google Safetynet. https://www.cigital.com/blog/using-safetynet-api/
  33. 33. Image: CC lendingmemo.com Fraud detection Device risk scoring, compromise indicators: • Root detection • List of installed apps • User-added CA Certificates • Android version, patchlevel • Tampering attempts? Additional indicators: location, device uptime, behavioral patterns, other...
  34. 34. Device scoring – details What, when and how is reported to the server? Cleartext (easy to intercept and tamper): devicekey:AD407F0797FDDEC0F5F5A3CA7ABB97E9BA7D5BA464DA0095DBAFFD3, config_update:1000,os.ver_up_to_date:0,os.rooted:0,os.rooted.nativ e:0,os.rooted.hiders:0,malware.any:0,total.risk.generic:0 Encrypted (more effort required to tamper): 9Jyx4xpeoK6VEZCCjQuW8vc5+xCktgPGjNIqhkgLeYZOtae9MDEKtc7OBUuL7ZO6GW 6Z3yjcxKwQpglHqwrxvz+1JGMh/wv6R8U6S51+uA3tn+fqhcOxqGM4z7WP1/rLh9gD QPVFC8dOQ8/hLf3K+Q==
  35. 35. Transmission encryption - pinning Good practice: SSL certificate pinning. • Hardcode server's certificate details in the mobile application. • Goal: it will be more difficult to conduct Man-in-the-Middle attacks Unfortunatelly, pinning implementation is problematic for developers, and often introduces vulnerabilities ;)
  36. 36. Transmission encryption - pinning SSL vulnerability example #1 – empty trustManager sslcontext = SSLContext.getInstance("TLS"); atrustmanager = new TrustManager[1]; atrustmanager[0] = new EasyX509TrustManager(null); sslcontext.init(null, atrustmanager, null); The application accepts ALL the possible certificates ;)
  37. 37. Transmission encryption - pinning SSL vulnerability example #2 – hostnameVerifier SocketFactory sf = SSLSocketFactory.getDefault(); SSLSocket socket = (SSLSocket) sf.createSocket("mail.google.com", 443); SSLSession s = socket.getSession(); HostnameVerifier hv = HttpsURLConnection.getDefaultHostnameVerifier(); if (!hv.verify("mail.google.com", s)) { throw new SSLHandshakeException("Expected mail.google.com, found " + s.getPeerPrincipal()); } socket.close(); https://developer.android.com/training/articles/security-ssl.html#WarningsSslSocket The application accepts all the certificates signed by the specific CA.
  38. 38. Additional encryption layers
  39. 39. How it works? Public key Session key sent to server (encrypted by server's public key) Data encrypted by session key random session key Server API
  40. 40. How to attack it? The transmitted data must be at some point in clear-text form on the device, but it is difficult to tamper. Our approach: • Patch the app to generate static encryption key instead of random one. • Develop Burp intercepting proxy extension to decrypt the traffic using the static key
  41. 41. How to attack it? The transmitted data must be at some point in clear-text form on the device, but it is difficult to tamper. Our approach: • Patch the app to generate static encryption key instead of random one. • Develop Burp intercepting proxy extension to decrypt the traffic using the static key And of course the server-side vulnerabilities were still there!
  42. 42. Summary
  43. 43. Wrap-up • Rethink your decisions Technology is complex and bad assumptions are in the roots of poor security • Future proof your plan Risk depends on many factors, and may change in time (mobile malware development) • Use available options It is possible to enforce many additional layers of security, which render the attacks more difficult and mitigate the risk. • Implementation details matters! Bad implementation could introduce vulnerabilities even if the project is correct • Perfom analysis and deep testing if you are planning to use HCE or similar technologies
  44. 44. Q&A Whitepaper Meet us at our UK partner stand T80 Wojciech.Dworakowski@securing.pl @wojdwo Slawomir.Jasek@securing.pl @securingpl
  45. 45. Hope to meet you also at... Internet banking safeguards vulnerabilities Wojtek Dworakowski GATTacking Bluetooth Smart devices – introducing a new BLE MITM proxy tool Sławomir Jasek

×