NFC payments and powered-by-the-field mode (part II)

[continued from part I]

The security problem with running NFC payments in PBTF mode is that it takes user consent out of the picture. This defeats one of the main security improvements mobile wallets have over traditional plastic NFC cards: better control over when and which payments are authorized. In addition to the physical proximity requirement created by short-range of NFC, a number of additional pure software checks exist in the mobile application to guarantee that any payment taking place is one the user fully intended. For example:

  • Most implementations require that the screen is on
  • Correct PIN must have been entered “recently” in to the mobile application, based on a configurable time window. For example the original Google Wallet designed using secure-elements capped this at a conservative 5 minutes. (Interesting enough the more recent host-card emulation release defaults to 24 hours, effectively removing this control.)
  • Some implementations display a confirmation dialog with the requested amount/currency. Consumer must acknowledge this before the transaction is finalized.

Key observation is that such controls are implemented partly or completely by the mobile Android/iOS application. For example the PIN time-out in Google Wallet uses Android timers set to kick-in after the configured time elapses. Why can’t this logic reside in the SE applet itself? The first is a hardware limitation: SE can not maintain a true “wall” clock because it has no power source of its own and is only powered up for brief periods to perform specific tasks such as payments or authentication. The second is a usability/complexity trade-off: in theory payment applets could revert back to “unauthenticated” state after every transaction, requiring a new PIN entry. But that would make it difficult to deal with two common scenarios. First is retrying the same transaction that did not go through– common problem, as consumers not used to interacting with NFC readers. Second is completing several purchases in succession, for example in the case of large shopping centers with multiple merchants. In order to avoid manual PIN re-entry in these situations, the mobile application would have to cache the PIN outside the secure element for the same duration, create a more risky situation than just relying on a timer to issue some command to the SE.

Even if time-outs and deactivation could be implemented reliably with future hardware changes, there is still one fundamental problem with PBTF: the consumer has no inkling when a transaction is taking place or for that matter what exactly happened. Recall that PBTF can only generate enough juice to power up the secure element and NFC controller chips; the small burst of electricity supplied by the reader is not enough to power up the far-more resource hungry mobile device itself. (Inductive charging exists for mobile devices such as Nexus 4 from 2012. Even if point-of-sale terminals supplied that much power, it would take around half-minute for a phone to boot-up and reach the point of running the payments application, far too long to be useful for tap payments where deadlines are measured in fractions of a second.) With the main processor powered off, there is no way to inform user with a beep/vibration that a transaction has taken place, much less ask them for confirmation ahead of time. Given those constraints, the secure element applet responsible for payments must fend for itself when deciding whether to proceed. Imagine the code waking up to find itself powered by the external field and faced with a request for payment. (By the way, neither NXP or Broadcom/Oberthur chips at the time provided any means to distinguish that from regular powered-by-host mode but let’s assume future hardware will solve that.) Is that because the consumer is holding up their phone against a real point-of-sale terminal at a store to checkout? Or is this an unauthorized person holding a rogue NFC-reader while that same person is standing on a bus with their phone in their pocket, oblivious to the virtual pick-pocketing? PBTF takes away one of the main advantages of having dual-interface secure element coupled to smartphone: trusted user-interface for communicating user intent.

That determination can not be made without the host OS participating– which it can not while powered off. One can imagine various heuristics to permit “low-risk” transactions: authorize a maximum of 10 transactions, approve only if the requested payment amount is small (but don’t forget about currency in addition to numeric amount as this paper demonstrates) or approve if the merchant is recognized. The problem is that only the first of these can be implemented reliably. Merchant authentication is rudimentary at best in EMV. Meanwhile the mag-stripe profile of EMV employed for backwards compatibility does not authenticate purchase amounts at all. In fact there is not even a provision to send the payment amount to the phone. Amusingly MasterCard MMPP added that capability but this is window dressing: the amount/currency does not factor into the calculation of CVV3. POS can claim to charge 5¢ while interacting with the phone but then authorize $1000.

Finally there is the principle of least surprise: consumer do not expect their phones to be capable of doing anything— much less spending money— when they are powered off. (Contrary to claims that NSA can continue tracking phones when powered off.) That argues for making PBTF an opt-in choice for users to enable once they are familiar with the technology. This fact was impressed on a blogger’s colleague during the early days of Google Wallet. While trying to demonstrate that how new technology is perfectly safe by tapping a powered-off Nexus S against a Vivotech 4500, the engineer was shocked to hear the familiar beep of a successful transaction emitted from the reader. It turned out that he powered off the phone by yanking the battery. Because of that abrupt shutdown, the NFC stack never had a chance to disable card-emulation mode. With NFC controller set to card-emulation and PBTF enabled by-default in early NFC controller firmware, that left the secure element “armed” to conduct payments. (Luckily the reader was not connected to any POS, so no actual money changed hands during this instructive, if somewhat unexpected demonstration.) That experience promptly inspired a firmware update to disable PBTF by default for Android devices.


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