Prime Factors Blog

I Want [EMV] Chips with That Sandwich - the Jimmy Johns Data Breach

Posted by Mary Still on Sep 30, 2014 3:06:00 PM

Find me on:

News of the Jimmy Johns breach displays front and center the need for a quick and smooth adoption of EMV in the US. The reported subsequent fraud, using sensitive card data captured from the breach, would have been much less useful if EMV chip cards had been used. While we can’t predict that adoption of EMV will hasten because of such examples, we do know that EMV migration is the necessary preventative measure against counterfeiting and card present fraud. [Also, Tom Groenfeldt of Forbes magazine noted a spike in card present fraud in advance of the EMV liability shift date, as discussed in this prior post.]


I asked an expert, Dave Tushie, Product Manager for Prime Factors' BCSS, just why this is so. Here is some of that exchange.

Dave: This type of (reported) counterfeit card attack is exactly where the prevalent fraud from transaction cards occurs in this country.  Far and away.  Card not present fraud is growing faster but doesn’t even rank a close second to this (counterfeit) level of fraud loss.  And EMV is the anti-dote for such fraud.

Mary: The breach led to counterfeit mag-stripe cards being used for card present transactions. If the transactions had been EMV wouldn’t the card authentication data, if captured, be adequate to reconstruct the track data?

Dave: No, the iCVV or chip CVC would be used for chip transactions, not the static CVV1 from the track data. It is used as a means to ensure data integrity in an on-line transactions.

Mary: So the Chip Card Security Code is not the same value as the CVV. iCVV or chip CVC is calculated using a Service Code of ‘999’, as opposed to the issuer-assigned service code that is used for CVV calculation. This seems reasonable enough, but when authorizing a transaction, does the issuer know how the card was read?   Another way to say it is could the issuer verify an iCVV when they should be validating against a CVV? 

Dave: Yes, the Issuer knows in an on-line transaction if it was an EMV or mag stripe transaction.  And no, iCVV could not be obtained from a mag stripe swipe.  Remember, if the card has an EMV chip and it is swiped at POS with an EMV capable terminal, the terminal instructs the cardholder to insert the card into the POS so that it can perform an EMV transaction.  If the POS is not EMV capable, it will read the mag stripe just like it would a mag stripe card where only the CVV would be on the stripe.

Mary: What if the counterfeit card really was a chip card? How would the issuer know to decline the transaction? 

Dave: Remember, each EMV transaction is going to have a dynamic cryptogram, transaction-specific, that is going to be generated by the card.  This is stronger, cryptographically, than the iCVV.  This cryptogram changes for every transaction and can only be verified by the issuer through shared (diversified) 3DES key.

Mary: The pieces are coming together, but I have another question. Since Track1 and Track2 data is on chips, who's to say that a card reader can't be programmed to access and copy those? 

Dave: The reader can’t get to the chip data without knowing the keys (unique to each card) that allows such access.  And if they were able to infer such keys, using very sophisticated technology I might add, they would only have compromised that single card.  Hard work for little payoff.  Much easier to go after large databases of cards that have all the information they need to counterfeit (mag stripe) cards!


For a copy of Prime Factors' educational paper "How Card Issuers Can Reduce the Impacts of Retail Chain Data Breaches", please click on the image below:

New Call-to-action