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

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. Demystifying HCE Security -
Best Practices for Secure
Mobile Payments
Slawomir Jasek Wojtek Dworakowski
IT Security Expert IT Security Expert

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. • 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. Background brief

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. 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. 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. 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. 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. 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. Mobile payments risks
Selected attacks scenarios

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. 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. 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. 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. 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. 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. 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. 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. CDCVM + malware with root?
CDCVM – mobile app
authorization instead
of PIN.
Malware can
intercept PIN and
make fraud payment
without limits.

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. HCE best practices
Details and example vulnerabilities

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. 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. 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. 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. Code obfuscation
Commercial obfuscator:

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. 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. 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. 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. 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. 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. 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. 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. 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. Additional encryption layers

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

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. Q&A
Whitepaper
Meet us at our UK partner stand T80
Wojciech.Dworakowski@securing.pl @wojdwo
Slawomir.Jasek@securing.pl @securingpl

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