Is NFC host card-emulation safe for payments? (part II)

[continued from part I]

(Full disclosure: This blogger worked on Google Wallet security)

Card security in perspective: curious case of chip & PIN

Not disturbing the precarious optimal risk equilibrium is one reason EMV adoption has been on a leisurely place in the US. For what seems like a decade, every year has been the year of chip & PIN, when the vaunted technology would finally hit the inflection point. (It may finally be happening in 2015 if the card networks do not blink and stick to their ultimatum for liability switch.) Target and similar large-scale data breaches deserve much of the credit for accelerating the schedule, thanks to negative publicity and decline in consumer confidence– so much that consumers have reported favoring cash in the aftermath of Target breach, a counterproductive reaction that may aggravate risks via theft and loss.

If one focuses on technology alone, it seems puzzling at first why card networks have not embarked on a crash-program to upgrade point-of-sale terminals and cards across the board. After all there is really no comparison in terms of security between swipe and chip transactions. Granted EMV payment protocols are far from perfect: several design flaws have been identified and published in the literature. But even with known (and difficult to fix) defects, chip & PIN represents a major improvement  over swipe transactions, mitigating entire classes of vulnerabilities. But that “puzzle” goes away once the full business impact of  taken into account. Rolling out EMV in a setting that has been used to swipe transactions has been a difficult task. Whatever gains are made locally in reducing fraud may be more than offset by the global cost of the massive undertaking required to upgrade merchants and reissue cards, not to mention user confusion caused by unfamiliar technology– which is another reason why the expected model in the US will involve chip & signature  as opposed to PIN entry, in keeping with the familiar ritual of signing pieces of paper.

HCE and risk management

The parallel with the interminable saga of US chip & PIN adoption is not entirely accurate for HCE/SE. In the first case, chip cards had the formidable problem of displacing a “good enough” installed base. By contrast NFC payments very much remain a green-field, and in principle there is no backwards compatibility problem holding back SE deployment. While merchants have to upgrade to NFC terminals and consumers need to purchase handsets equipped with NFC, once they have made that investment there is no reason to prefer HCE over SE.

In fact the technologically superior solution involving hardware secure elements was first on the scene. It even enjoyed a natural head-start: SE inside a phone represents an incremental evolution of existing standards, leveraging same tried-and-true hardware already deployed in chip & PIN cards, repackaging in slightly different configuration. (Of course reality is not quite that simple: surrounding that secure chip with an always-on, always-connected and highly exposed general purpose computer introduces all sorts of new risk such as remote relay attacks.) By contrast using host-card emulation payments calls for new tokenization standards, designed to compensate for lower security-assurance level of a mobile OS by leaning heavily on online connectivity instead.

So why the frenzy over HCE? Because for the first time it makes contactless payments broadly accessible to enterprising upstarts who were previously marginalized by the “cabal” of secure element manufacturers, TSM operators and wireless carriers. Barrier to entry is lowered to writing an ordinary Android app, along with meeting basic requirements from Visa/MasterCard/AmEx etc. That means more mobile applications developed to run on more mobile devices, carrying credit cards from a wide spectrum of issuers, all adding up to many more transactions by volume and frequency. In other words more interchange fees to go around for all participants in the ecosystem. By contrast the deployment of secure element solutions has been stalled by wireless carriers’ intransigence against Google Wallet, coupled with challenges at executing on their own rival project ISIS– now getting rebranded to avoid confusion with the Iraqi Al-Qaeda faction. (Jury is out on whether the Iraqi terrorist group should be more ashamed of sharing the same name.) As for Google Wallet, its install counts and user-ratings have sky-rocketed after switching to host card emulation. After all, an app that users can not run because of their wireless carrier has precious little utility, no matter how impressed the lucky few are.

What of the alleged decrease in security? By looking at the big picture, we can place the HCE risks in better perspective. First any fraud in question is constrained to card-present in-person transactions, which is quite a bit more difficult to scale than card-not-present transactions that can be conducted from anywhere around the world. (If issuers are careful, they can further constrain potential fraud to NFC transactions only, by blocking the by-design ability to replay NFC track data on a plain magnetic stripe.)  Second, attacks targeting the physical manifestation of the payment instrument– eg magnetic stripe, chip & PIN or mobile device– are only one subset of risks in the system. For example, HCE versus secure-element has no bearing on the safety of merchant terminals. Finally payment networks have defense-in-depth, additional security features designed to detect and prevent attacks that succeed in subverting card security. Most visibly each issuer operates a “back-end” risk engine capable of vetoing transactions even if all of the authorization data from the card looks correct. Defeating the security of the physical payment instrument– be it old-school magnetic stripe or mobile device with NFC– is only the first step: the enterprising fraudster also needs to run the gauntlet of statistical models optimized to detect anomalous spending.

So the argument over HCE amounts to splitting hairs over one very specific attack vector. Gemalto is getting wrapped around the axle over what will be at-worst a negligible increase in fraud. It may even result in a a net decrease by driving adoption of NFC, increasing the percentage of transactions not involving magnetic stripes. To the extent that any one can predict which of these scenarios is more likely to play out, it is the card networks.


2 thoughts on “Is NFC host card-emulation safe for payments? (part II)

  1. lexdabear says:

    Another issue I see with HCE is that one has to be always on-line with the mobile device, while with the SE it can be also offline. It is a nightmare scenario for consumers, ie I am in a hotel at night or in a subway turnstile and cannot connect in order to do the payment. With the data flatrates it probably won’t happen unless there is an RF issue to receive a mobile network signal. How to access online if ie on a business trip out of the country? I guess it is a trade-off between user experience and convenience.

    I agree that HCE from security point of view might play out with all the mechanisms around it. Even better, with one-time tokens it can’t be reused for online payments. On the other hand the user should have a choice, ie for paranoid SE and for convenience HCE.

    • Depending on the design, it is not always necessary to be online for HCE payments.

      For Google Wallet, the PIN entry is always an online operation– it is always checked against the cloud, not local instance.
      But after PIN validation, the app can make transactions for several minutes/hours (depending on time out) without connectivity. HCE specs from major card networks envision a similar design where the phone downloads credentials from the issuer that are only valid for a limited number of transactions. After they are downloaded there is no reason to be online during the purchase.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s