You've heard of the F-Bomb, the H-Bomb and the F-Word. With the recent rash of Hack's (Heartland, RBS WorldPay and more coming) there's a new one...I call it the H-Word. It's Black Hat slang for Hack You!Heartland knows what it feels like when a Black Hat says "Hack You!" Suffice it to say their stock symbol might be HPY, but shareholders are not. Why? Again...two words. Hack You! So what's the safer approach to protecting your Online Debit (PIN) number?
A PCI 2.0 PED "certified" approach...or a soft(ware is the PVV?) approach? What's more readily hackable? Hardware or Software. It's not "hard" to make the "Hack-You"-Lynk...
Although the answer is an obvious one, never underestimate the impact of good marketing prowess. The EFT Networks may have fallen for a good sales pitch Hook, Line and Sinker, but they should know better. They'll know soon enough...why a software only approach to protecting a consumer's PIN is soft. My biggest concern is a breach, not competition. I don't want to see peoples PIN's hacked because it will affect the industry as a whole, and we are part of that industry. The writing is SO CLEARLY on the wall. I'd like to see it encrypted...
Since data is what's at stake here, we'll provide some.
What follows are some excerpts from a paper called "Breaking VISA PIN" written by Luis Padilla Visdómine. If you're not a tekkie, you'll have to read it a little bit more slowly in order for it to properly digest. In the meantime, here's the meat and potatoes: A software approach WILL BE HACKED, PERIOD, END OF STORY, GUARANTEED. Many prominent industry insiders agree. HomeATM's CEO guarantees it will happen within 30 days of it going live. If it takes 60 or 90 days, don't hold it against him...he's only trying to help.
HomeATM reached the summit or PINNACLE of security with it's recent PCI 2.0 certification.(Click any picture to enlarge) What does this mean?
It means that HomeATM's "SAFE-T-PIN™" solution encrypts the entire transaction, beginning to end which should thus remove participating merchants from the scope of the PCI DSS as NO CARDHOLDER DATA is transmitted during the transaction. What does THAT mean?
Considering the fact that PCI DSS compliance is a costly process, that fact alone should result in considerable interest. Instead of paying tens of thousands, in some cases hundreds of thousands of dollars, an e-merchant could employ HomeATM's payment platform and be in like Flynt.
Additionally, since the HomeATM SAFE-T-PIN™ provides a "card present" environment, interchange morphs from the significantly higher "Card NOT Present" rates into a significantly lower "Card Present" rate. But we're not done yet. In addition to our solution removing our clients from the PCI DSS scope and lowering interchange to Card Present rates, we ALSO further reduce interchange by providing a true PIN based transaction.
PIN based transactions, because of their inherent dual-authentication processing (What you have/Card and What you Know/PIN) enjoy a reduced interchange rate on top of the CP rate. In effect, HomeATM could save giant e-tailers tens of millions of dollars on Interchange. "Annually!"
On the flip side, considering that a "software" approach requires the card holder to "type" their PAN (Primary Account Number) into a browser, e-tailers will still have to pay a "card not present" rate. So even if it isn't H'd in the first 90 days, Internet Retailers would still be paying a higher rate in return for the convenience of not having good security. But since the Internet Retailer is the one who is going to be liable when it is dot.hacked, they'll quickly learn they've been had. Here are the excerpts: To read his entire paper, click here
VISA PVV algorithm
One of the most common PIN algorithms is the VISA PIN Verification Value (PVV). The customer is given a PIN and a magnetic stripe card. Encoded in the magnetic stripe is a four digit number, called PVV. This number is a cryptographic signature of the PIN and other data related to the card. When a user enters his/her PIN the ATM reads the magnetic stripe, encrypts and sends all this information to a central computer.
There a trial PVV is computed using the customer entered PIN and the card information with a cryptographic algorithm. The trial PVV is compared with the PVV stored in the card, if they match the central computer returns to the ATM authorization for the transaction. See in more detail.
Preparing the attack
A brute force attack consists in encrypting a TSP with known PVV using all possible encrypting keys and compare each obtained PVV with the known PVV. When a match is found we have a candidate key. But how many keys we have to try? As we said above the key is 64 bit long, this would mean we have to try 2^64 keys. However this is not true. Actually only 56 bits are effective in DES keys because one bit (the least significant) out of each octet was historically reserved as a checksum for the others; in practice those 8 bits (one for each of the 8 octets) are ignored.
Therefore the DES key space consists of 2^56 keys. If we try all these keys will we find one and only one match, corresponding to the bank secret key? Certainly not. We will obtain many matching keys. This is because the PVV is only a small part (one fourth) of the DES output. Furthermore the PVV is degenerated because some of the digits (those between 0 and 5 after the last, seen from left to right, digit between 6 and 9) may come from a decimal digit or from a decimalized hexadecimal digit of the DES output. Thus many keys will produce a DES output which yields to the same matching PVV.
The attack
Once we know we need five TSP-PVV pairs, how do we get them? Of course we need at least one card with known PIN, and due to the nature of the PVV algorithm, that's the only thing we need. With other PIN systems, such as IBM, we would need five cards, however this is not necessary with VISA PVV algorithm. We just have to read the magnetic stripe and then change the PIN four times but reading the card after each change.
It is necessary to read the magnetic stripe of the card to get the PVV and the encrypting key selector. You can buy a commercial magnetic stripe reader or make one yourself following the instructions you can find in the previous page and links therein. Once you have a reader see this description of standard magnetic tracks to find out how to get the PVV from the data read. In that document the PVV field in tracks 1 and 2 is said to be five character long, but actually the true PVV consists of the last four digits. The first of the five digits is the key selector. I have only seen cards with a value of 1 in this digit, which is consistent with the standard and with the secret key never being compromised (and therefore they did not need to move to another key changing the selector).
I did a simple C program, getpvvkey.c, to perform the attack. It consists of a loop to try all possible keys to encrypt the first TSP, if the derived PVV matches the true PVV a new TSP is tried, and so on until there is a mismatch, in which case the key is discarded and a new one is tried, or the five derived PVVs match the corresponding true PVVs, in which case we can assume we got the bank secret key, however the loop goes on until it exhausts the key space. This is done to assure we find the true key because there is a chance (although very low) the first key found is a false positive.
It is expected the program would take a very long time to finish and to minimize the risks of a power cut, computer hang out, etc. it does checkpoints into the file getpvvkey.dat from time to time (the exact time depends on the speed of the computer, it's around one hour for the fastest computers now in use). For the same reason if a positive key is found it is written on the file getpvvkey.key. The program only displays one message at the beginning, the starting position taken from the checkpoint file if any, after that nothing more is displayed.
The DES algorithm is a key point in the program, it is therefore very important to optimize its speed. I tested several implementations: libdes, SSLeay, openssl, cryptlib, nss, libgcrypt, catacomb, libtomcrypt, cryptopp, ufc-crypt.
The DES functions of the first four are based on the same code by Eric Young and is the one which performed best (includes optimized C and x86 assembler code). Thus I chose libdes which was the original implementation and condensed all relevant code in the files encrypt.c (C version) and x86encrypt.s (x86 assembler version). The code is slightly modified to achieve some enhancements in a brute force attack: the initial permutation is a fixed common steep in each TSP encryption and therefore can be made just one time at the beginning. Another improvement is that I wrote a completely new setkey function (I called it nextkey) which is optimum for a brute force loop.
To get the program working you just have to type in the corresponding place five TSPs and their PVVs and then compile it. I have tested it only in UNIX platforms, using the makefile Makegetpvvkey to compile (use the command "make -f Makegetpvvkey"). It may compile on other systems but you may need to fix some things. Be sure that the definition of the type long64 corresponds to a 64 bit integer. In principle there is no dependence on the endianness of the processor. I have successfully compiled and run it on Pentium-Linux, Alpha-Tru64, Mips-Irix and Sparc-Solaris. If you do not have and do not want to install Linux (you don't know what you are missing ;-) you still have the choice to run Linux on CD and use my program, see my page running Linux without installing it.
![Reblog this post [with Zemanta]](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_t8qwbqML9kkL5TtPh1jssi1sqoxXCQKlJY0o_wDqckveUB92VLsCzkVgM2esy1_jblAlauhhqJrFlDwxyLMdraSo8AzKBVAJunk5eCVPLV-78sg-S-aRwWAZd9_jgjxspaVy8y0Nua6ROCexRJKtLK=s0-d)
