As we close out this series on the EMV migration and changes in the payment industry, we are adding a section on mobile payments to clarify the big picture. Mobile usage is invalidating some long-held assumptions behind payment security, so we also offer tips to help merchants and issuing banks deal with the changing threat landscape.

Some of you reading about this for the first time will wonder why we are talking about mobile device payments, when the EMV migration discussion has largely centered on chipped payment cards supplant the magstripe cards in your wallet today. The answer is that it’s not a question of whether users will have smart cards or smartphones in the coming years – many will have both. At least in the short term. American Express has already rolled out chipped cards to customers, and Visa has stated they expect 525 million chipped cards to be in circulation at the end of 2015. But while chipped cards form a nice bridge to the future, a recurring theme during conversations with industry insiders was that they see the industry inexorably headed toward mobile devices. The transition is being driven by a combination of advantages including reduced deployment costs, better consumer experience, and increased security both at endpoint devices and within the payment system. Let’s dig into some reasons:

• Cost: Issuers have told us chipped cards cost them $5-12 per card issued. Multiplied by hundreds of millions of cards in circulation, the switch will cost acquirers a huge quantity of money. A mobile wallet app is easier and cheaper than a physical card with chip, and can be upgraded. And customers select and purchase the type of device they are comfortable with.
• User Experience: Historically, the advantage of credit cards over cash was ease of use. Consumer are essentially provided a small loan for their purchase, avoiding impediments from cash shortfalls or visceral unwillingness to hand over hard-earned cash. This is why credit cards are called financial lubricant. Now mobile devices hold a similar advantage over credit cards. One device may hold all of your cards, and you won’t even have to fumble with a wallet to use one. When EMVCo tested smart cards — as they function slightly differently than mag stripe — one in four customers had trouble on first use. Whether they inserted the card into the reader wrong, or removed it before the reader and chip had completed their negotiaton, the transaction failed. Holding a phone near a terminal is easier and more intuitive, and less error-prone – especially with familiar feedback on the customer’s phone.
• Endpoint Protection: The key security advantage of smart cards is that they are very difficult to counterfeit. Payment terminals can cryptographically verify that the chip in the card is valid and belongs to you, and actively protect secret data from attackers. That said, modern mobile phones have either a “Secure Element” (a secure bit of hardware, much like in a smart card) or “Host Card Emulation” (a software virtual secure element). But a mobile device can also validate its state, provide geolocation information, ask the user for additional verification such as a PIN or thumbprint for high-value transactions, and perform additional checks as appropriate for the transaction/device/user. And features can be tailored to the requirements of the mobile wallet provider.
• Systemic Security: We discussed tokenization in a previous post: under ideal conditions the PAN itself is never transmitted. Instead the credit card number on the face of the card is only known to the consumer and the issuing bank – everybody else only uses a token. The degree to which smart cards support tokenization is unclear from the specification, and it is also unclear whether they can support the PAR. But we know mobile wallets can supply both a payment token and a customer account token (PAR), and completely remove the PAN from the consumer-to-merchant transaction. This is a huge security advance, and should reduce merchants’ PCI compliance burden.

The claims of EMVCo that the EMV migration will increase security only make sense with a mobile device endpoint. If you reread the EMVCo tokenization specification and the PAR token proposal with mobile in mind, the documents fully make sense and many lingering questions are address. For example, why are all the use cases in the specification documents for mobile and none for smart cards? Why incur the cost of issuing PINs, and re-issuing them when customers forget, when authentication can be safely delegated to a mobile device instead? And why is there not a discussion about “card not present” fraud – which costs more than forged “card present” transactions. The answer is mobile, by facilitating two-factor authentication (2FA). A consumer can validate a web transaction to their bank via 2FA on their registered mobile device.

How does this information help you? Our goal for this post is to outline our research findings on the industry’s embrace of smartphones and mobile devices, and additionally to warn those embracing mobile apps and offering them to customers. The underlying infrastructure may be secure, but adoption of mobile payments may shift some fraud liability back onto the merchants and issuing banks. There are attacks on mobile payment applications which many banks and mobile app providers have not yet considered.

Account Proofing

When provisioning a payment instrument to mobile devices, it is essential to validate both the user and the payment instrument. If a hacker can access an account they can associate themself and their mobile device with a user’s credit card. A failure in the issuing bank’s customer Identification and Verification (ID&V) process can enable hackers to link their devices to user cards, and then used to make payments. This threat was highlighted this year in what the press called the “Apple Pay Hack”. Fraud rates for Apple Pay were roughly 6% of transactions in early 2015 (highly dependent on the specifics of issuing bank processes), compared to approximately 0.1% of card swipe transactions. The real issue was not in the Apple Pay system, but instead that banks allowed attackers to link stolen credit cards to arbitrary mobile devices. Merchants who attempt to tie credit cards, debit cards, or other payment instruments to their own mobile apps will suffer the same problem unless they secure their adjudication process.

Account Limits and Behavioral Monitoring

Merchants have historically been lax with customer data – including account numbers, customer emails, password data, and related items. So when merchants begin to tie mobile applications to debit cards, gift cards, and other monetary instruments for mobile payments, they need to be aware that their apps will become targets. Attackers will use information they already have to attack customer accounts, and leverage payment information to siphon funds out of customer accounts. This was highlighted by false reports claiming Starbucks’ mobile app had been hacked. The real issue was that customer accounts were accessed by attackers guessing credentials, and those accounts were leveraged for purchases. It was exacerbated by ‘auto-replenishment’ of account funds from the consumers bank account, giving the hackers a new source of funds on a regular basis. The user authentication and validation process remains important, but additional controls are needed to limit damage and detect misuse. Account limits can help reduce total damage, risk-based reauthorization can deter stolen device use, and behavioral analytics can detect misuse before fraud can occur. The raw capabilities are present, but apps and application need to leverage those capabilities.

Replay Attacks

Tokens should not be able to initiate new financial transactions. The PAR token is intended to represent an account and a payment token should represent a transaction. The problem is that as tokens replace PANs in many systems, old business logic assumes a token surrogate is a real credit card number. Logic flaws may allow attackers to replay transactions, and/or to use tokens for ‘repayment’ to move money from one account to another. Many merchants need to verify that their systems will not initiate payment based on a transaction token or PAR value without additional screening. Tokens have been used to fraudulently initiate payment in the past, and this will continue in out-of-date vendor systems.

Summary

As analysts we at Securosis have a track record of criticizing most recommendations from the major card brands and their Payment Card Industry Security Standards council. Right or wrong, we considered past recommendations and requirements thinly-veiled attempts to shift liability to merchants while protecting card brands and issuing banks. At a first impression, the shift to EMV-compliant card swipe terminals again looks good for everyone but merchants. But when we consider the whole picture, the EMV migration is a major step forward. Technical and operational changes can make the use of EMV compliant terminals a win for all parties – merchants included. The switch is being sold to merchants as a liability reduction, but we do not expect most merchants to find the liability shift sufficiently compelling to justify the cost of new terminals, software updates, and training. On the other hand we consider the improved consumer experience, improved token security, and reduced audit costs, along with the liability shift, ample motivation for most merchants to switch.

This concludes our series on EMV and the changing payment landscape. As with all our research projects, the content we have posted was the result of dozens of conversations with people in the industry: merchants, card brands, gateways, processors, hardware manufacturers, and security practitioners all offered varied perspectives. We have covered a lot of ground and very complicated subject matter, so we strongly encourage comments and questions on any areas that are not totally clear. Your participation makes this research better, so please let us know what you think.