Decimalisation table attacks for PIN cracking

1 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 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 0123456789ABCDE
0123456789012345 000000100000000

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.


2 Banking Security

Banks have traditionally led the way in ghting fraud from both insiders and outsiders. They have developed protection methods against insider fraud including double-entry book-keeping, functional separation, and compulsory holiday periods for sta , and they recognise the need for regular security audits. These methods successfully reduce fraud to an acceptable level for banks, and in conjunction with an appropriate legal framework for liability, they can also protect customers against the consequences of fraud.

However, the increasing complexity of bank computer systems has not been accompanied by suffcient development in understanding of fraud prevention methods. The introduction of HSMs to protect customer PINs was a step in the right direction, but even in 2002 these devices have not been universally adopted, and those that are used have been shown time and time again not to be impervious to attack [1, 2, 5]. Typical banking practice seeks only to reduce fraud to an acceptable level, but this translates poorly into security requirements; it is impossible to accurately assess the security exposure of a given
aw, which could be an isolated incident or the tip of a huge iceberg. This sort of risk management con icts directly with modern security design practice where robustness
is crucial. There are useful analogues in the design of cryptographic algorithms. Designers who make \just-strong-enough" algorithms and trade robustness for speed orexport approval play a dangerous game. The cracking of the GSM mobile phone cipher A5 is but one example

And as \just-strong-enough" cryptographic algorithms continue to be used, the risk of fraud from brute force PIN guessing is still considered acceptable, as it should take at least 10 minutes to guess a single PIN at the maximum transaction rate of typical modules deployed in the 80s. Customers are expected to notice the phantom withdrawals and report them before the attacker could capture enough PINs to generate a signi cant liability for the banks. Even with the latest HSMs that support a transaction rate ten times higher, the sums of money an attacker could steal are small from the perspective of a bank.

But now that the PIN decimalisation table has been identi ed as an security relevant data item, and the attacks described in this paper show how to exploit uncontrolled access to it, brute force guessing is over two orders of magnitude faster. Enough PINs to unlock access to over $2 million can be stolen in one lunch break!

A more sinister threat is the perpetration of a smaller theft, where the necessary transactions are well camouflaged within the banks audit trails. PIN veri cations are not necessarily centrally audited at all, and if we assume that they are, the 15 or so transactions required will be hard for an auditor to spot amongst a stream of millions. Intrusion detection systems do not fare much better { suppose a bank has an extremely strict audit system that tracks the number of failed guesses for each account, raising an alarm if there are three failures in a row. The attacker can discover a PIN without
raising the alarm by inserting the attack transactions just before genuine transactions from the customer which will reset the count. No matter what the policies of the intrusion detection system it is impossible to keep them secret, thus a competent programmer could evade them. The very reason that HSMs were introduced into banks was that mainframe operating systems only satisfactorily protected data integrity, and could not be trusted to keep data con dential from programmers.

So as the economics of security flaws like these develops into a mature eld, it seems that banks need to update their risk management strategies to take account of the volatile nature of the security industry. They also have a responsibility to their customers to reassess liability for fraud in individual cases, as developments in computer security continually reshape the landscape over which legal disputes between bank and customer are fought.