CVV3: Demystifying credit card verification (part 2)

Completing an earlier post where we discussed CVV1 and CVV2, this second part looks at CVV3 or colloquially “dynamic CVV.”

One of the obvious security limitations of CVV1 and CVV2 is that they are constant for the life of a particular payment instrument. Because every transaction involves revealing these “secrets” to anther party, namely the merchant where the card-holder is making a payment, the odds are strongly against CVV1/CVV2 remaining secret for a very long time. Indeed card-holders have parted with their CVV via an array of impressive attack vectors over the years: from crude devices masquerading as fake card readers that skim entire magnetic stripes, to phishing attacks that brazenly ask unsuspecting users to input their card number CVV2 and plain incompetent ecommerce merchants that manage to get their entire customer database 0wned. PCI standards try to improve the situation by imposing restrictions against cavalier handling of card data– for example CVV2 can not be stored permanently, only used for authorizing the transaction in real time. But such measures are similar to devising incremental improvements for managing passwords, without fundamentally altering the limitations of a password based approach. Much of that is a limitation of the plastic card technology: the magnetic stripe is considered essentially a static, passive container for small amount of data; there are no “smarts” anywhere in the card.

(** Strictly speaking this is no longer true: several companies have introduced programmable magnetic stripes, where the information can be changed by a chip residing on the card. Similarly the printed CVV2 can be replaced by an LCD screen that flashes a code varying over time. Such cards have never seen widespread deployment.)

This is where EMV which stands for EuroPay, MasterCard and Visa enters into the picture. EMV defines a suite of protocols employing strong cryptography, where the card is not simply a glorified low-density storage medium but contains a chip capable of performing complex payment protocols including the series informally known as chip & PIN. Unfortunately as every engineer who ever proposed a new protocol soon realizes, breaking from the past is not that easy. Migration to EMV suite of protocols presents a formidable triad of challenges: nudge issuing banks to mail out new cards to their customers, convince merchants to replace their point-of-sale terminals with newer models that accept these cards,  and finally ensure that the payment processors those merchants connect to are aware of the improved protocols. Omit any of these steps and all the fraud risks inherent in a static secret return: this is what happens when an American customer travels overseas and hands over an old-fashioned magnetic stripe card to a merchant set up to process a chip & PIN transaction.

Backwards compatibility is a very appealing feature. Its promise is upgrading only part of the system at lower total cost, in such a way that the change remains transparent to other “legacy” components in place, while still attaining some of the benefits realized from a full upgrade. In the case of contactless payments, this takes the form of a “profile” of the original protocol that creates the appearance of having swiped an old-fashioned magnetic stripe card. Called mag-stripe profile appropriately enough, this variant of contactless payment protocols are distinguished by producing output that looks very similar to track-data obtained from plain plastic cards.

The main difference is a challenge-response step added to dynamically generate a different CVV value for each transaction. Instead of containing a fixed CVV1 for every swipe, this scheme instead computes the integrity check using cryptographic keys stored on the chip, as a function of card data as well as a challenge issued by the payment terminal. This constantly changing value is the CVV3 and it takes the place of CVV1 on the emulated track-data resulting from the transaction. (“Emulated” because it is assembled by the terminal from multiple individual card responses sent over NFC during a contactless payment.)

Backwards compatibility is served by keeping the remainder of the transaction identical, once the protocol exchange between card and NFC reader is complete. In that sense the changes required are minimal compared to full chip & PIN implementation. NFC reader is fully aware of the new protocol but beyond that point, there is only track-data returned to the point-of-sale terminal. This information is in exactly the same format as it appears on classic magnetic stripe cards. It is processed in the same manner, passed on to the payment processor for verification, who in turn will typically forward it to the issuer for final authorization. This level compatibility is what allows adding NFC-payments as bolt-on option to existing payment terminals configured for swipe transactions: at some level of abstraction, the new payment flow over NFC using the dynamic CVV3 merges with the existing flow for processing magnetic stripes with CVV1. That interchangeability has surprising security consequences, which will be explored in a subsequent post.

CP