Target hackers: Woohoo, we're rich! Um. Guys? Anyone know how to break bank encryption? Underground cybercriminals are attempting to decrypt a 50GB dump of encrypted debit card PINs that security watchers reckon were lifted during last year's high profile breach against retail giant Target. Security intelligence firm IntelCrawler reports that a miscreant claiming to be in possession of 50GB of PIN data secured …
Why are they sending the PIN to the merchant gateway? Neither the merchant gateway nor the card-issuer needs to know that information - just that a duly validated card has been used. Surely all the PIN needs to do is verify to the card that it can activate - even the POS terminal doesn't need to know what the PIN is.
"Isn't the PIN held in the card itself?" No, not with 'merkin debit cards with a mag stripe. The PIN gets encrypted and gets verified by the issuing bank. This is why the crims are eager to get to the PINs, so they can create bogus mag-striped cards and do some ATM raids with their mules.
If they have the credit card PAN + Name + Expiry (from mag stripe) then these can be used for remote shopping excursions, sometimes without the CCV2 value, especially if in cahoots with a rogue merchant.
If it's stored on your card, how can you change it at your bank or by phone to your bank?
It's stored on your bank's computers.
So, the account number and PIN go to the transaction server. It verifies with your bank if your account number and PIN are correct, as well as attempts to debit the amount of the sale (OK, it's a *bit* more complicated than that, but that's the mile high view).
Here's the ATM side of how it works, the POS side only has a few more moving pieces.
http://sidekick.windforwings.com/2008/02/how-are-atm-pins-validated.html
Putting aside whether or not the terminal needs to communicate the PIN to the gateway, think about this: the malware used in this breach scraped RAM used by the POS software to capture data in-process. Since you have to enter your PIN into the terminal to use your debit or Redcard, the assumption is that the pad does not handle the PIN itself but rather hands that off to the POS terminal, thus putting that PIN into RAM. Seems they missed one minor detail and knowing this they will not make the same mistake next time.
I have popcorn waiting for the Great Reveal of how the malware got into the system in the first place.
Chip and PIN allows for the PIN to be held at the issuer and not on the card, it can be one of the options in the CVM list. Not all terminals support offline PIN validation so in those cases the PIN would be sent online to the acquirer (encrypted).
UK EMV cards support validation of the card between the terminal.
In the US the PIN pad is required to be a separate device from the one that handles the rest of the customer interaction (mag stripe reader, total verification, signature, etc...) and it has AFAIK no input capability. Even the original encryption keys can only be entered on the pad itself. The encryption keys are stored in the PIN pad and are used to encrypt the PIN before it ever leaves the pad. Most use 3DES. I saw no indication the pads themselves were compromised which is why all they have is encrypted PIN information. The CVV2 3-digit code on the back of the card(Except American Express, it's 4 digits and on the front) is not encoded in the mag stripe, however, it along with the PIN can be picked up with a camera if there is a skimming device.
The terminal, the merchant, the pad, and the card do not know what the PIN is. Only the pad handles it unencrypted. Only after it has been decrypted by the payment processor is it verified and the valid/invalid response sent back to the device.
Good info. Now I wonder how that pad interfaces with the POS. The pad is capable of displaying messages and advertisements, which means there is some kind of assertion from the POS terminal. If that data transfer can be abused it could be possible to break a few things.
The actual circuit board that captures the pin is almost always a separate piece than the display that shows the advertisements and messages. The PIN is encrypted before it ever leaves that piece, even within the same enclosure. There are a very few that input the PIN on the same device (such as the Verifone MX870 and I'm not sure what protections it uses) but the vast majority are completely segregated from the other functions of the terminal.
"Payment Card Industry standards call for salt..."
Which assumes you've implemented according to PCI-DSS standards and that the QSA who conducts the audit hasen't proven otherwise.
If you choose not to implement entirely to standard there is nothing stopping you - too many projects belive they can cut corners to make the design and build quicker and cheaper and simply take the risk you'll never be found out.
Because really, what auditor is going to check the salt exists in reality and not just in the paper design. (sarcasm)
I worked in crypto for a bank and have undergone one of these audits in the past (it's actually not PCI-DSS but PCI-PTS [PIN transaction security] which is a very different set of requirements)
The auditors are very thorough (slightly hampered by their own requirement that encrypted PIN blocks are never stored in log files). They will validate in configuration or code what PIN block format is used. In recent standards, the non compliant PIN block format must be disabled on the HSM. Implementing the proper PIN block is easy, it's just a flag sent to the HSM and configuration of the terminal. The requirements to be a transaction acquirer are very strict and well audited. Only the very largest merchants (and Target may be one) will go through it, most will let their bank do it.
Even though the credit card security standards are heaps weaker in the US than the rest of the world, it's very unlikely that the PIN block in this case is non compliant, which means it is made up from the PIN and card number at a minimum.
He meant there is the CVV, which is in the magstripe and was stolen, and the CVV2, different, which is on the back of the card, and cannot be read by a POS terminal. The latter is the one needed for "card not present" (ie, by phone, or online) transactions.
Which basically means that they have enough to duplicate the cards and use them to buy things in shops (with signature), but not get cash out of ATM's (PIN is needed, and crypted - so far) nor order online (no CVV2).
3DES is the global standard for PIN security. There is no defined standard for using AES in PIN transactions. You have to remember that these standards take a long time to be developed and an even longer time to be implemented as they need to be bilaterally agreed by the banks and the schemes, who are not the fastest at moving at the best of times. A transition to AES would be immensely complicated mainly because of the increase in block size (64 bits to 128 bits) which would affect the storage and transmission of PIN blocks in every transaction and card system and database the bank uses, which are usually 20 years old and written in COBOL.
As such, every single PIN you ever type into any terminal in the world is 3DES encrypted (except for those still using single DES, which are thankfully rare), and will be for many years to come.
NSA hacked DES ages ago.
External parties have won prizes breaking DES, the fastest being in a day in 2007.
All, of course, with dedicated hardware.
Now, 3DES is a bit more complicated. Which keying option is being used? What mode is being used? More than one block?
There is more than one moving part, making someone who hasn't a clue, which is obvious considering the call for help, isn't going to get in anytime soon.
But, they may well get help soon.
Help into a jail cell.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
