credit card hacking

Introduction

Automatic Teller Machines (ATMs) are used by millions of customers every day to make cash withdrawals from their accounts. However, the wide deployment and sometimes secluded locations of ATMs make them ideal tools for criminals to turn traceable electronic money into clean cash.
The customer PIN is the primary security measure against fraud; forgery of the magnetic stripe on cards is trivial in comparison to PIN acquisition. A street criminal can easily steal a cash card, but unless he observes the customer enter the PIN at an ATM,
he can only have three guesses to match against a possible 10,000 PINs and would rarely strike it lucky. Even when successful, his theft still cannot exceed the daily withdrawal limit of around $300 . However, bank programmers have access to the computer systems
tasked with the secure storage of PINs, which normally consist of a mainframe connected to a \Hardware Security Module" (HSM) which is tamper-resistant and has a restricted API such that it will only respond to with a YES/NO answer to a customer's guess.
A crude method of attack is for a corrupt bank programmer to write a program that tries all PINs for a particular account, and with average luck this would require about 5000 transactions to discover each PIN. A typical HSM can check maybe 60 trial PINs
per second in addition to its normal load, thus a corrupt employee executing the program during a 30 minute lunch break could only make o with about 25 PINs.
However, HSMs implementing several common PIN generation methods have a aw.
The rst ATMs were IBM 3624s, introduced widely in the US in around 1980, and most PIN generation methods are based upon their approach. They calculate the customer's original PIN by encrypting the account number printed on the front of the customer's card with a secret DES key called a \PIN generation key". The resulting ciphertext 3 is converted into hexadecimal, and the rst four digits taken. Each digit has a range of
`0'-`F'. In order to convert this value into a PIN which can be typed on a decimal keypad, a \decimalisation table" is used, which is a many-to-one mapping between hexadecimal
digits and numeric digits. The left decimalisation table in Figure 1 is typical. 

0123456789ABCDEF 0123456789ABCDEF
0123456789012345 0000000100000000
Figure 1: Normal and attack decimalisation tables
This table is not considered a sensitive input by many HSMs, so an arbitrary table can be provided along with the account number and a trial PIN. But by manipulating
the contents of the table it becomes possible to learn much more about the value of the PIN than simply excluding a single combination. For example, if the right hand table is
used, a match with a trial pin of 0000 will con rm that the PIN does not contain the number 7, thus eliminating over 10% of the possible combinations. We rst present a simple scheme that can derive most PINs in around 24 guesses, and then an adaptive
scheme which maximises the amount of information learned from each guess, and takes an average of 15 guesses. Finally, a third scheme is presented which demonstrates that the attack is still viable even when the attacker cannot control the guess against which the PIN is matched.
Section 2 of the paper sets the attack in the context of a retail banking environment, and explains why it may not be spotted by typical security measures. Section 3 describes
PIN generation and veri cation methods, and section 4 describes the algorithms we have designed in detail. We present our results from genuine trials in section 5, discuss
preventative measures in section 6, and draw our conclusions in section 7.

 CHECK OUT PART 2