NFC payments on personal machines: PCI versus innovation (part II)

[continued from part I]

In this follow-up we look at the missing pieces for enabling ecommerce with tap-and-pay  from end-user devices.

Integration with web-browsers

The first problem is that neither the NFC reader hardware or higher-level APIs leveraging that (such as PC/SC for smart cards) are directly exposed to web sites. This is good for security– it is dangerous to give websites access to smart cards that happen to be attached to the system, considering those cards may contain valuable credentials. “Directly exposed” in this case refers to being accessible from the standard web platform of HTML5 and JavaScript. It is certainly possible to execute arbitrary code and go direct to operating system APIs via various extension mechanisms such as ActiveX and NPAPI. But these are not portable, strongly discouraged for security reasons, not to mention impractical for each website to rewrite from scratch.

Not to worry: from their humble beginnings, web browsers have been getting increasingly bloated with random APIs over time. W3C recently standardized a basic cryptography API. (There is even a proposal for  secure element API in the same vein being promoted by Gemalto. But that proposal operates at too low a level, exposing raw APDU communications to cards instead of encapsulating a payment transaction.) It is not too much of a stretch to imagine some payments API can be introduced either by industry consensus or by one of the players such as Google or MSFT deciding to field their proprietary design. Such an API could abstract away the logistics of stepping through the payment protocol and communicating with the card. It would function identically for contact-based chip & PIN as well as contactless cards with NFC readers. Implementation of the API would also handle critical user-interface elements such as collecting PIN from the user, which can not be entrusted to websites.

Integration with payment processors

After the protocol is executed, the online merchant ends up with some “proof” of authorization generated by the card and conveyed by the web browser. The contents of this proof  are partially dependent on inputs chosen by the website itself. For example in certain EMV protocols, the amount being charged is itself an input authenticated by the card. The next challenge is for the website to use that proof and somehow get paid.

This is an interoperability concern. Typically websites are working with a payment processor which expects to receive specific inputs to pass upstream: credit card number, expiration date, cardholder name and optionally CVC2. Depending on the exact protocol variant used, a contactless transaction will not produce all of these. For example the card-holder name is redacted from the emulated “magnetic stripe” for Paypass transactions. That problem is  easily solved by asking the user– chances are the merchant is interested in customer name for other reasons already. But others are more difficult to work around. Contactless payments use a dynamic CVC, also known as CVC3. (By the way: that applies only for the simplest case of EMV protocols run in backwards compatible-mode with swipe-transactions. This is the “mag-stripe profile” intentionally designed to produce output that looks like track data coming from a plain plastic card. Pure EMV has far more elaborate schemes for authorizing transactions with nothing resembling a CVC in sight.) That value is not static; it is computed as a function of challenge from the reader and incrementing sequence counter maintained by the card. On the surface CVC3 has the same format as CVC2: typically three digits, although this is a configurable parameter. However they are not interchangeable; CVC3 values can not be used to make a card-not-present transaction.

At this point one can fallback to the strategy of simply asking the user for other fields.  The problem is that defeats the point of using a contactless payment protocol such as NFC: having a stronger assurance that the card is indeed present, and resisting some class of attacks that involve copying cardholder data. Receiving a fresh CVC3 response based on a challenge chosen by the website provides guarantees that are not present in using a static CVC2, which could have been captured from the user in a different context. Put another way, retrieving only the card number and other static data from the card is only “tap-and-pay” in spirit; it amounts to using NFC as glorified numeric keypad, without leveraging the higher security level possible for contactless payments.

Better solution is to allow the upstream payment processor to accept output format generated by EMV protocols. Luckily the mag-stripe profiles provide an easy transition path for this, since they were designed for backwards compatibility with “legacy” swipe-transactions using CVC1. While POS transactions are card-present (as opposed to card-not-present mode used in online purchases) processors typically have capability for processing these if they are also facilitating in-store transactions. In other words, one approach to interop is treating tap-and-pay transaction from end-user as a card-present transaction conducted at POS terminal, returning track data with CVC3. This emulated track-data will be relayed to the merchant and passed through to the payment processor, who in turn forwards it to the network.



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