[continued from part II]
Armed with the background from previous posts on NFC payment protocols and how the magnetic-stripe profiles for EMV protocols achieve backwards compatibility, we can now look at what would happen in a hypothetical Target-type attack. The threat model assumes that point-of-sale (POS) terminals at the retailer stores have been compromised by attackers. Consumers will be making payments at these registers using their contactless cards, using NFC instead of swiping.
NFC at point-of-sale
One important distinction: we have spoken of POS devices having NFC as an integrated capability. In practice these can be distinct pieces of hardware. For example tap-and-pay capability can be added to legacy terminals via an external accessory, connected to the POS over a serial link. This peripheral contains the NFC reader and has knowledge of the payment protocols. It is responsible for abstracting away differences and quirks between different card networks and emitting familiar track-data to the POS. This is part of the interoperability benefit of mag-stripe profile; the POS may not have been designed for NFC but the output from the attached peripheral is still looks indistinguishable from an old-school swipe reader.
One corollary is that the POS does not micro-manage the NFC protocol or specify what bits to transmit. Instead there is a higher-level command structure, with the POS signaling that is ready for payment and NFC reader handling all exchange with the card, returning track-data after completion. Compromising the POS software– as in the case of Target breach— does not automatically translate to running arbitrary code on the NFC reader or otherwise controlling NFC traffic. For the purposes of this discussion, we will assume the worst-case scenario and still consider attacks where NFC reader is behaving maliciously instead of following the expected protocol.
Simplest attack involves capturing the emulated magnetic stripe and trying to reuse this for another transaction. There are two reasons this is unlikely to work. As noted earlier, that track data incorporates a challenge issued by the NFC reader, the so-called “unpredictable number” generated randomly. Captured data from compromised POS contains a CVC3 corresponding to the choice of UN dictated by the attached reader for that particular transaction. Trying to reuse the same information at another reader will fail unless the exact same UN is chosen, which is unlikely when these are generated randomly. Granted there have been reports in the literature of catastrophic failures of the random number generator in EMV hardware [Anderson et al.] in the context of ATMs. Since attackers can choose which retailers to target as well as the where they will monetize the stolen information, they could carefully pick stores employing such flawed hardware in their NFC terminals, to maximize the chances that UN values involved will be repeated with high-probability.
But there is a secondary mechanism to prevent such misuse: the application transaction counter or ATC. This value also appears in track-data and can be optionally incorporated into the CVC3 calculation. If ATC were not included in CVC3, then a repeated UN would permit replay. Attackers could even try to repeat the protocol multiple times with the card and sample multiple CVC3 values corresponding to different values of the UN. Fortunately “sane” configurations include ATC in the CVC3 computation. But there is another security check that is left up to the issuer: enforcing that ATC is indeed acting as a unique counter.
Suppose that our enterprising crooks also observed that NFC track-data can be encoded on a plain magnetic-stripe and swiped, due to the lenient behavior of payment processors and issuers. Could they create a new credit-card using the data captured from compromised POS and use it repeatedly for purchases?
If the issuer is not paying attention to the payment mode and willing to apply CVC3 validation logic to a swipe transaction, the cryptographic check will be satisfied. But the issuer will observe something strange: a repeated ATC value. When the consumer made a purchase at Target, suppose their ATC was at 10. Since it is supposed to increment for each transaction, the next time the issuer receives an authorization request containing NFC track-data, they would expect to see a value greater than 10. It could be 11 but it could also be 12 or higher due to incomplete transactions which caused ATC to be incremented without ever resulting in an authorization request sent to the card issuer. But observing the same ATC twice for two different transactions? There is no legitimate scenario for that. Provided the issuer declines a second transaction using the same counter, attackers can not monetize track-data passively captured at the POS.
Passive being the operative word in the previous statement. So far we have focused on attacks where the adversary watches an ordinary tap-and-pay transaction taking place, waits for the simulated NFC “track-data” to arrive at the POS, copies this information and exfiltrates it for future use. But it is not useful to to hypothesize new defenses without also allowing for the presumed attackers to adopt their strategy in response. Knowing that they are dealing with contactless cards, the adversary could also adopt a different strategy such as sampling multiple transactions. For example they could program their POS malware to instruct the NFC reader to repeat the transaction five times, ending up with not just one but five samples of track-data with different UN/ATC/CVC3 combinations. The final post in this series will discuss how such attacks can be frustrated by proper issuer configuration.