security in a mobile app world - a payments perspective james sellwood 6 th sept 2014
TRANSCRIPT
About Me
Electronic Payments Consultant
Credit Cards Terminals Contactless /
NFC / HCE Security Consultant
Payment Systems Mobile
RHUL ISG
Alumni (MSc '12)
Part-time Student (PhD '1x)
Information Security Research
Android Access Control
Presentation Overview
Payments' use of software Past, present and imminent
The mobile app world's impact on: Requirements Development Testing Risk Security
What this is
My personal view & understanding Example based Generalised & simplified Comparative UK biased (but not UK specific)
What this is NOT
Employer or client endorsed Comment (+/-) about any brand shown Providing answers The entire story
Historically Technologically Geographically
Usage of Payment Cards & Banking Services
A selective history, highlighting changes in: usability, risks & security
Embossing
http://www.theukcardsassociation.org.uk/cards-transactions/card-present-transactions.asp
static data
Magnetic Stripe
Improve speed of transaction Degradation (slow) Automated Entry
No mistyping / miscopying of card details No carbon paper copy of card details
ATM
Greater availability Outside bank opening hours Unattended locations
Cardholder attacks Isolated system Two-factor authentication
Online PIN
Contact Chip
https://www.cibc.com/ca/credit-cards/dividend-one-mastercard.html
software
dynamic data
secure chip
Contact Chip
Active participation in transaction Dynamic data creation Offline transaction approval Offline PIN verification Issuer scripting at POS
Hardware-based secure storage & processing protects
Application logic Cryptographic keys
Online Banking
Greater availability Any physical location
Variety of PC-specific threats Device fingerprinting Authentication
Passwords Two-factor authentication
Contactless Chip
http://www.bluestarinc.com/us-en/solutions/security/news/single/news/detail/News/chip-and-pin-the-future-of-credit-cards.html
software
dynamic data
secure chip
contactless
Contactless Chip
Improve speed of transaction No dip Faster data exchange No PIN verification (low-value)
Proximal data access Privacy
Should remain in control of cardholder
Dual Interface Chip
http://www.kinodesign.com/featured-work/barclaycard/07-Card-design-for-life
software
dynamic data
secure chip
contactless
Dual Interface Chip
Flexibility of both contactless and contact Speed and convenience Issuer scripting at POS
Amount and velocity limits...then revert to contact, reset counters and then carry on as before
Stickers
http://allaboutwindowsphone.com/flow/item/14658_Barclaycard_PayTag_sticks_NFC_.php
software
dynamic data
secure chip
contactless
Stickers
No need to carry a card Stick it to what you like
(e.g. something you carry regularly) Limited ways to update counters Amount and velocity limits...
then decline
Mobile Banking (App)
http://www.computerweekly.com/news/2240105562/RBS-and-Natwest-launch-native-Blackberry-app-for-bank-transfers
software
softwareprotection
opendistribution
dataconnection
Mobile Banking (App)
No need to have access to a PC You already carry a smartphone –
apparently Variety of mobile-specific threats Device fingerprinting as well as user
authentication
Mobile (NFC)
http://www.engadget.com/2014/03/14/google-wallets-tap-to-pay-feature-will-require-android-4-4-kitk/
software
dynamic data
secure chip
contactless
dataconnection
Mobile (NFC)
No need to carry a card Do need NFC capable smartphone
(even more attractive target) Mobile network provides non POS-based
communications channel Issuer scripting wherever data available
User interface allows user control Activate / deactivate Passcode: every transaction / high-value
Mobile (HCE)
http://nfctimes.com/news/capital-one-reveals-reasons-quitting-isis-early-role-promoting-hce
contactless
opendistribution
software
dynamic data
softwareprotection
dataconnection
Mobile (HCE)
Wider availability Easier (cheaper) issuance Less interoperability restrictions
No hardware-based secure element Limited transaction data on device with
limited validity period Short-lived keys Risk informed approach
Mobile App Requirements
Identification (device / app / customer) Authentication (device / customer) Authorization (request) Confidentiality (customer data / keys) Integrity (request) Availability (service) Auditing (everything)
Development(mobile versus pre-mobile)
Less niche knowledge required Less technological constraints Wider choice of supporting libraries Significant volume of information available
online Demand for fast paced, iterative product
improvement Frequent API change
Testing(mobile versus pre-mobile)
Generic testing frameworks available More features to test More security frameworks now part of the
product (rather than underlying architecture)
More iterations to be tested Cannot now test all the possible
component combinations
Risk(mobile versus pre-mobile)
More information available to inform decision making
Cardholder owned device with no provenance
Base security architecture may be weaker Less experienced development teams and
proliferation of “code by Google”
Security(mobile versus pre-mobile)
Modern interfaces Graded responses or temporary restrictions More information-driven More reliant on active monitoring Application code open to malicious
evaluation Many more endpoints, particularly ones
accessed by untrusted nodes
Closing Thoughts
Risk landscapes change Good / Bad Advancement / Bug Business / Outsider
Not (as) secure versus secure enough Financial versus reputational loss More data is only useful if you can interpret
and act on it