2. What is mobile payment?
Mobile payment generally refer to payment services operated under
financial regulation and performed from or via a mobile device,Instead of
paying with cash, cheque (or check), or credit cards, a consumer can use
a mobile phone to pay for a wide range of services and digital or hard
goods.
3. Mobile Payment Models
• Mobile wallets
• Card-based payments
• Carrier billing (Premium SMS or direct carrier billing)
• Contactless payments NFC (Near Field Communication)
• Direct transfers P2P
4. Classification of Mobile Payments
Based on
Value
Micro
Payments
Based on
Charging
method
Based on
Location
Based on the
validation of the
tokens exchanged
Macro
Payments
Mini
Payments Proximity
Payments
Remote
Payments
Pre-paid
Post-paid Online
Payments
Offline
Payments
(ex: e-coins
in P2P
transfers)
6. Services
1. Person – to – Person transfer using mobile device
2. Mobile banking (including deposits and bill payment)
3. POS purchases processed using a mobile device
4. POS purchases made using a mobile device
5. Purchases over the internet using mobile device
14. Legal Landscape
• Responsibility for privacy and data security of transaction information are
typically set by contract.
Payment Card Industry Data Standard (“PCI DSS”)
15. PCI Mobile Payment Acceptance
Security Guidelines
Objectives and Guidance for the Security of a Payment Transaction
⚫Objective 1: Prevent account data from being intercepted when entered into a mobile device.
⚫Objective 2: Prevent account data from compromise while processed or stored within the mobile
device.
⚫Objective 3: Prevent account data from interception upon transmission out of the mobile device.
Guidance for Securing the Mobile Device
⚫Prevent unauthorized physical device access
⚫Prevent unauthorized logical device access
⚫Protect the mobile device from malware
⚫Ensure the mobile device is in a secure state
⚫Disable unnecessary device functions
⚫Detect loss or theft
⚫Ensure the secure disposal of old devices
16. Contact and Contactless Interfaces
• 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
17. EMV chip cards
EMV stands for Europay, MasterCard and Visa, a global standard for
inter-operation of integrated circuit cards (IC cards or "chip cards")
and IC card capable point of sale (POS) terminals and automated
teller machines (ATMs), for authenticating credit and debit
card transactions.
Key Security Advantages:
▪ Information stored in a more secure microprocessor chip
– Instead of a less secure magnetic stripe
▪ Personalization of EMV cards is done using issuer-specific keys
▪ Card creates unique transaction data
– Any captured data cannot be used to execute new transactions
(prevents card skimming and card cloning)
▪ Cardholder verification
– Terminal will prompt the customer to sign or enter a PIN to validate
their identity.
– Also supports other cardholder verification methods: offline PIN,
online PIN, signature, or no cardholder verification method.
18. NFC
• Near-field communication (NFC) is a set of communication protocols that enable
two electronic devices, one of which is usually a portable device such as a
smartphone, to establish communication by bringing them within 4 cm (1.6 in) of
each other.
Electromagnetic fields can be used
to transmit data or induce electrical
currents in a receiving device.
Passive NFC devices draw power
from the fields produced by active
devices, but the range is only short
20. 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
API exposing only functions, not data Similar to physical contactless card
• Memory
• Processor
• Applet (javacard)
21. Host-based Card Emulation (HCE)
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
No API nor requirements for storing
card data and for secure transmission
Security should be explicitly
implemented by app
23. NFC Relay attack
Same risk profile as for
any contactless card
• Very close proximity
(mostly will not work
through the bag)
• Short window of
NFC Proxy opportunity
24. NFC Relay attack
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
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
26. Steal card data in transit
Secure Element on SIM
• Card data transmitted OTA by GSM
network.
• Theoretical possibility to intercept GSM
communication.
Host Card Emulation
• Usually tokenized card data pushed to
device from the "cloud",
e.g. by Google Cloud Messaging
Risk: low
• The card data is transmitted only once
to mobile device.
• Intercepting GSM is still not trivial
Risk: depends on implementation details
• Encryption layers
• Authentication, device fingerprinting...
• Various application features
27. 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
28. Malware with root access
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
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
29. 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
31. 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
32. PIN Storage
• PIN is salted with a 64-bit random value and
hashed with one round of SHA-256
33. 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
34. Relay Attacks (MITM)
• "Mole" reader gets close to target mobile device
• Attacker's mobile gets near POS terminal
• APDUs are passed via TCP/IP
35. Relay Attack Limitations
• Target's mobile payment app must be unlocked
• Google Wallet requires entry of a PIN to unlock
36. 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
37. Relay Attack Countermeasures
• Contactless POS terminals should enforce a time-out 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
• Google Wallet is no longer vulnerable to the second
attack
⚫It no longer exposes payment applets over the contact
interface
39. 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
40. 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
41. 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 #
42. 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
• They could therefore use Square to perform mass fraud
– Instead of manufacturing fake credit cards
43. 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
