Before you read this, consider checking out my first post on the Target breach.
Payment systems are complex. If you have ever assessed one or looked under the curtains going all the way back to the issuer, you know this. So it is not a surprise that there is a ton of misinformation flying around about the PIN data that Target admitted was taken. Before we get to far down the road here, I want to review a few items to make sure we’re all on the same page.
First, let’s talk about track data. The type of data in the magstripe on the back of your card is sensitive, which is why PCI Requirement 3.2 forbids storing it. I’ve taken the liberty of swiping one of my previously compromised credit cards so you can see what the data looks like (ignore the wrapping for formatting on your screen). I’ve altered the data slightly, so don’t even be tempted into trying to run this card.
- Track 1: %B5466111111111111^WILLIAMS/BRANDEN ^091210100000050601000000326000000?
- Track 2: ;5466111111111111=0912101506010326?
This is literally what is pushed to the terminal when a card is swiped through the system. Now, lets talk about the ISO/IEC 7813 format which specifically governs how the card must be coded for interoperability (pulled from this page). Track 1 is the longer track and may contain alphabetic text and is the only track where the cardholder’s name may appear.
- It typically starts with the ‘%’ character.
- Next is a format code ‘B’.
- Then the primary account number (or PAN) which can be up to 19 characters. It should match the numbers embossed on the front of the card which is why you can key in the last 4 digits as a security check when running a card-present transaction.
- Next, is a field separator because we have an variable length field, generally this is a ‘^’.
- Next is the cardholder name which can be from 2 to 26 characters.
- Next, another field separator of ‘^’.
- Expiration date, which is in the format of YYMM (meaning that the card above expired on December 2009). If there is no expiration, it may be just another field separator (‘^’).
- Then a service code. This is three numeric digits that tell a gateway how to process a card. You will find that prepaid cards have different characters than normal credit cards as well as cards that can be used internationally. If there is no service code, it may be just another field separator (‘^’).
- Next is discretionary data, which is another variable length field that can include a PIN Verification Key Indicator, PIN Verification Value (sometimes called PIN Offset), and Card Verification Value (or Card Verification Code for MasterCard). This is the CVV confusion that we saw last week where people equated these digits (typically three) with the CVV2/CVC2 numbers on the back of a Visa or MasterCard for card-not-present transactions. The PVV or PVKI are not the same as the PIN you use to run a transaction, but are used in conjunction with the PIN to create a set of ciphertext called a PIN Block. This PIN Block is then passed up to the issuer, and eventually decrypted to validate the PIN.
- Finally, a ‘?’ signifying the end of the track (which can only hold a maximum of 79 alphanumeric characters).
Track 2 is shorter and was typically used in unattended payment terminals like the ones that dispense fuel, but can be used by anyone wanting to process a transation. Here’s the format of that track:
- It typically starts with the ‘;’ character.
- Then the primary account number (or PAN) which can be up to 19 characters.
- Next, is a field separator, generally this is an ‘=’.
- Expiration date, which is in the format of YYMM, or ‘=’ if not present.
- Then the three-digit service code.
- Next is discretionary data, but typically more compact.
- Finally, a ‘?’ signifying the end of the track (which can only hold a maximum of 40 alphanumeric characters).
Keep in mind, you can run a transaction with EITHER Track 1 or Track 2, and elements of the tracks will match exactly (while others may be padded). Now, according to the Target release, the data stolen was actually encrypted PIN data, or that PIN block, which has been encrypted using the keys generated through the Derived Unique Key Per Transaction, or DUKPT (pronounced like Duck-Putt). Reversing this block back into a key becomes computationally infeasible on a large scale as each block is encrypted with a unique key (derived from the master).
So, what can we tell with this information? For one, your actual PIN number is probably safe. Rushing out to your bank to change your PIN number probably won’t stop any fraud from happening. Don’t forget, you can also run a debit transaction in a similar manner to a credit card through a SIGNATURE (offline transaction). I’ve never seen it implemented that way, but the system does theoretically allow for this to happen.
Next, we can tell that the breach probably occurred in either the POS terminal (not where the card is swiped, but the register itself), the POS controllers (easier to do on a mass scale, see this article about the Hannaford Bros. breach which alludes to IPS there), or the larger Target payment gateway that processes everything. Again, the details may never be released, but all three of those options are both feasible and probable sources.
Finally, a question we are getting quite a bit now is this: “Wouldn’t EMV stop this kind of breach?” It really depends on how it is implemented. That said, the same controls that would keep the data safe in an EMV world would also keep the data safe in a NON-EMV world. So, the stock answer is no, EMV by itself would not have prevented the Target breach. In fact, we know that EMV actually facilitates card-not-present fraud due to their handling of “routing information,” which is what we call “sensitive authentication information,” or the data that is typically known in the mag stripe as tracks data.
So there you have it. Hopefully this clears a few things up for you. If you have questions/comments, put them below!