demystifying host card emulation security - best practices for implementing secure mobile payments
TRANSCRIPT
Next Presentation begins at 13:00
Demystifying Host Card Emulation Security - Best Practices for Implementing Secure
Mobile Payments
Slawomir Jasek Wojtek DworakowskiIT Security Expert IT Security Expert
Demystifying HCE Security -Best Practices for Secure
Mobile Payments
Slawomir Jasek Wojtek DworakowskiIT Security Expert IT Security Expert
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
• 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
Background brief
Mobile paymentsHow did we get here?
2008First concatlesspayment cards.
2009First pay-by-mobile service (UK)
2011Galaxy Nexus – Google Wallet, Secure Element
2012First HCE experiments(SimplyTapp, Blackberry)
2013Android 4.4 supports HCE
2014Visa, Mastercard HCE support, first commercialimplementations
2015Apple Payenters UK
2016Android Payenters UK
Image sources: Orange, http://www.storagenewsletter.com/, http://9to5mac.com/
Secure Element (SE)
API exposing only functions, not dataSimilar 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
Secure Element
OS
Mobile app
AppletNFC
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
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
Mobile paymentsMobile ticketsReward programsPhysical securityHotel room accessCar/bicycle rental…The sky is the limit!
Image sources: https://www.ximedes.com, http://www.ibonus.net/, http://www.frugalprototype.com/,
HCE uses
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
Mobile payments risksSelected attacks scenarios
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
Secure Element
• The NFC usually works also with the phone turned off (even dead battery).
• Easier to approach unsuspectingvictim'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 demandHCE: activate NFC antenna on screen unlock
• Communication delays due to proxing could be detected
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
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
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
Attack #3 – steal card data in transit
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
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
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
CDCVM + malware with root?
CDCVM – mobile app authorization instead of PIN.
Malware can intercept PIN and make fraud payment without limits.
Other vectors…
StealingAltering AID routing tableAttack on services in the cloudFake POS (e.g. PAN gathering + CNP fraud)Power analysisSocial engineeringApple Pay provisioning fraud…
HCE best practicesDetails and example vulnerabilities
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
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
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?
Code obfuscation
Good practice: even using free ProGuard you can alter default settings to make it more secure.
Original source:
ProGuard compression (most common)
Code obfuscation
Commercial obfuscator:
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.
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/
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
• ...
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/
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...
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.native:0,os.rooted.hiders:0,malware.any:0,total.risk.generic:0
Encrypted (more effort required to tamper):
9Jyx4xpeoK6VEZCCjQuW8vc5+xCktgPGjNIqhkgLeYZOtae9MDEKtc7OBUuL7ZO6GW6Z3yjcxKwQpglHqwrxvz+1JGMh/wv6R8U6S51+uA3tn+fqhcOxqGM4z7WP1/rLh9gDQPVFC8dOQ8/hLf3K+Q==
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 ;)
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 ;)
Transmission encryption - pinning
SSL vulnerability example #2 – hostnameVerifierSocketFactory 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.
Additional encryption layers
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
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
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!
Summary
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
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