Credit card authorization: compatibility of CVC1 and CVC3Posted: September 16, 2012
As discussed in the second post in the series, the magnetic-stripe profile of certain EMV payment protocols such as Paypass produces data in a format similar to what swiping a traditional plastic card might yield. This backwards compatibility has undeniable advantages for transitioning to the more advanced protocols. For example, point-of-sale terminals can have an NFC capability added as bolt-on accessory, without altering the transaction further downstream.
The downside of this seamless transition is that there is no strict firewall separating NFC payments with dynamic CVV3 from swipe-transactions that rely on static CVV1 for authorization. It is possible, albeit inconvenient, to encode NFC transaction data on a plain card and use it at a regular point-of-sale terminal. This explains the replay demonstration that Kristin Padgett performed at Shmoocon in January in 2012. Intended to prove the ease of skimming information from contactless credit cards, this stunt actually serves as an unintended proof of the interchangeability of CVV1 and CVV3. The researcher executed one round of the payment protocol between a hypothetical victim’s contactless plastic card and an NFC reader controlled by the researcher. This transaction does not actually cause any money to exchange hands. It is never reported to the payment network. It is only used to record the transcript of the protocol. (This is the often hyped “skimming” part: in the US many cards have no additional protection such as PIN required to complete the transaction, unlike in Europe where it is common to have PIN entry above certain transaction threshold.) The transcript is then used to construct track data, encoded on a plastic card and swiped through a Square reader, to conduct the actual “fraudulent” transaction.
To be more precise, and this is where details of the protocol become important, it is not the case that a CVV3 can be substituted whenever the CVV1 appears on track data. The individual fields are not identical between the standard plastic card and emulated stripe from a contactless payment. (Among other things, a contactless payment include a transaction counter or ATC that is echoed in track data, incrementing for each transaction.) Rather the complete, unaltered track-data containing one-time generated CVV3 can to be substituted in place of static track data containing CVV1. The Shmoocon demonstration was a beautiful example of how the entire payment stack, starting with the custom hardware of the Square reader, the payment processing backend of Square and the acquiring bank involved (Chase Paymentech, for all Square transactions) were oblivious to the change in form factor. The whole point of backwards compatibility is that at some point far enough downstream from the terminal, everything looks identical. Square is likely not alone in creating this type of avenue for contactless payments to be tunneled over plain magnetic stripes via swipe transactions.
That is not to say that the discrepancy could not have been detected along the way by one of the participants in the chain. Backwards compatibility is same as indistinguishability. Specifically the track-data format includes a service code with different values defined for cards containing chips, designated as “integrated circuit” in the standards. Track data containing this value arriving over a magnetic stripe reader is immediately suspect. In principle either the Square hardware or if track data is visible at all within the application, the associated mobile app could have rejected it right away. Even further upstream, the payment processor often knows exactly what type of point-of-sale terminal exists at a merchant location– because the hardware is provisioned as part of a packaged offering from the processor. Arrival of track-data containing CVV3 from that merchant would then serve as strong signal of a problem if the merchant is known to be not capable of contactless payments. (One complication is whether card issuers have taken care to define different service codes for cards that have both traditional magnetic-stripe and IC component. If the standard magnetic stripe on the card has same service code as the one emulated by the chip, this heuristic fails. In that case additional heuristics can be used, such as presence of ATC or the appearance of CVV on two tracks, as opposed to track #2 only.)
One final point about replaying CVV3 track data: each protocol execution can only be used to create one valid magnetic-stripe. This is because of the ATC or transaction counter, which is incremented for each time the payment protocol is run. In principle that means the enterprising criminal has to capture multiple transactions when in the vicinity of the contactless card, and then go through the trouble of re-encoding the magnetic stripe with different track data between purchases. This is independent of any other restrictions the issuing bank may have around ATC that creates additional defenses against fraud. For example if the victim uses their card after skimming but before the attacker has gotten around to conducting a transaction. In that case all of the track-data captured by the attacker sports a counter less than the most recent one the bank has observed in a succesful transaction.