Part III in this series sketched a picture of how the most basic EMV protocol over NFC– backwards compatible with the ubiquitous magnetic stripes– can resist passive attacks taking place at the point-of-sale. If the miscreants’ strategy involves capturing transaction data as it is passing through a compromised POS and trying to stash it away for future use, card issuers can combat such fraud by checking for replay indicators. What about more sophisticated attacks when the POS attempts to influence the exchange between NFC reader and card, or try to monetize the stolen data immediately?
The price is always right
Looking back at how track-data and CVC3 are computed during NFC payments, there are two inputs conspicuously absent from the exchange: price and merchant identifier. That means the emulated magnetic stripe is not in any way bound to a particular purchase or even a specific merchant. In fact it is relatively easy to verify the first part experimentally. When paying with Google Wallet in-store for a purchase having multiple items, you can initiate the tap & pay before the cashier has finished ringing up all of them– exactly as one could with traditional plastic cards. The POS will typically display an interim message indicating that it is still waiting for the final amount, but the buyers will not have to tap again or otherwise confirm the details of the transaction.
That suggests a new avenue of attack:
- Trick the cardholder into performing multiple NFC transactions.
- Use one of the resulting track-data to complete the intended purchase at the specific merchant whose POS devices have been compromised
- Stash track-data from others, encode them on plain magnetic-stripe cards and rely on backwards compatibility to monetize them via swipe transactions at other merchants. There is nothing in the track-data per se limiting its use to the original merchant or identical transaction amount.
- Profit. Granted, fraud detection by the issuer can still flag transactions as suspicious based on merchant/amount patterns but that is based on statistical models of cardholder behavior. There is nothing in the track-data itself that indicates an attempt to divert captured track-data from a different merchant.
What is the feasibility of carrying out such an attack? First note that the multiple transactions are required for this plan. As noted earlier, each emulated track-data contains an incrementing counter, the ATC which is authenticated by the CVC3 and allows the issuer to detect replay attempts. At least one transaction is required for the cardholder to complete the legitimate purchase and that can not be reused by the miscreants. Racing the merchant to using that data first requires that attackers already have a purchase lined up, greatly limiting their options– good for our defensive position. More significantly it means that the card-holder gets a declined transaction and the issuer sees a repeated ATC value raising suspicion about what is going on. With full control over POS, the bad guys can try more subtle options where the compromised POS pretends that an authorization succeeded and prints out a receipt, without submitting anything to the payment processor. But such an attack equally risks being found-out quickly, due to accounting discrepancies; the merchant does not get paid.
Step #1 turns out not to be a major obstacle. As long as the card is in the induction field of the NFC reader, the reader can likely repeat payment protocol without additional user action required. Plastic-cards with NFC have no built-in clock or other means of detecting that a terminal is requesting multiple transactions in quick succession. Once the field is removed– powering off the chip inside the card which draws its current from that external field– and reintroduced, the card has no way to know whether it has been days or milliseconds since last activation.
Smartphone-based implementations do have access to an actual clock and could in principle detect such rapid-burst attempts.** Yet they are typically configured to only require PIN or other user explicit user confirmation based on time intervals, rather than transaction count. As long as the user has “primed” the application in the last 15 minutes or other interval configured, there is no additional confirmation required for individual transactions to proceed. This is partially driven by a desire to optimize for usability and handle flaky readers: in case a transaction failed, consumers can try again by holding the phone against the reader, without fiddling with the screen yet again.
Instead what stops this attack from working is the way ATC (application-transaction counter) frustrates steps #2 and #3.
** Even this part is tricky when a mobile wallet operates in NFC card-emulation mode with a secure element directly talking to the reader, by-passing the host operating system. SE has no concept of wall-clock either and can only limit transactions based on a signal received from the host device. Mobile versions of NFC payment protocols such as Paypass make provisions for host to grant single-shot approval to the SE, instead of the more common model of allowing them indefinitely until the host revokes such permission.