[continued from part IV]
First problem is that attackers are still limited in the number of purchases they can make with captured data. Each simulated track-data contains a counter known as ATC which is unique to a transaction, limiting this scam by the number of “extra” transaction performed at the malicious POS. Given that a full transaction requires on the order of ~100 milliseconds minimum– due to limited processing capabilities of smart card hardware, particularly for contactless transactions when all power required for computing must be drawn from the induction field– we are looking at not more than a dozen spurious protocol executions before either the checkout delays become suspicious or customers tire of holding their cards against the reader. Granted this may not be too much of a problem for the crooks interested in perpetrating fraud. Between issuer back-ends searching for anomalous spending patterns and card-holders noticing strange charges on their card, even old-school plastic card fraud may not get much far farther than a handful of unauthorized uses before it is caught.
When counters jump around
But the same transaction counter presents a different problem for attackers. To pick a concrete example, suppose that the card starts out with ATC at 10. The compromised POS carries out 5 NFC transactions, receiving track-data with ATC=11, 12, 13, 14, 15. One of these must be used to authorize the current purchase, with others saved for future fraudulent transactions.
Suppose the attacker submits ATC=15 to the issuer. The issuer will notice a gap, a sudden jump in ATC from the last seen value of 10 without any intervening values observed. This is often explained by incomplete or failed transactions where the card/terminal only complete some of the protocol steps. (ATC is incremented fairly on, typically during the execution of GET PROCESSING OPTIONS command) But when the remaining track-data samples are used in fraudulent transaction, the issuer will observe something even more strange: ATC out-of-order, with lower values of the counter such as 11 and 12 appearing at a later date than higher values. By itself this is not sufficient to deem the transaction fraudulent. Occasionally transactions get submitted in one large “batch” after a delay, instead of being submitted incrementally in real-time, especially when charge amounts are small. That could explain isolated instances of ATC appearing to jump back-and-forth over short periods, until missing values in the sequence are finally submitted to the payment processor. But the same pattern repeated over a longer stretch, with low ATC values continuing to appear after higher ones have been observed could be either a signal for flagging the transaction as suspicious or outright rejecting it as a processing error. In other words, the useful lifetime of information captured by the malicious POS has been bounded.
Exact same pattern occurs if the attacker chooses to submit ATC=10 to complete the original purchase at the compromised POS. In this case, remaining track-data can be used for fraudulent transactions in correct order, as strictly monotone increasing counter 11, 12 etc. But there is a catch: if the card-holder herself starts making additional purchases, the issuer will receive higher ATC values starting at 16, giving rise to the same out-of-sequence ATC signal. This creates a race-condition between the crooks and legitimate user: they need to quickly monetize the stolen information before actions by the card-holder renders that information useless because the ATC has advanced too far for the issuer to honor lower values. That does not render the attack impossible per se, but like all good mitigations, it raises costs for the attacker and blocks certain avenues for exploit. Much like a stolen OTP in attacks against two-factor authentication systems, captured track-data from NFC must be cashed in quickly or it may become worthless. Squirreling it away to resell on the black-market days or weeks later is no longer a viable strategy. (Note the extreme case of trying to win the race is a real-time relay attack. The attacker can have an accomplice stand in front of another NFC reader with a mobile device and simply relay APDUs to the victim card via the compromised POS. The unauthorized transaction takes place almost simultaneously or even before the intended one.)