Decimalisation table attacks for PIN cracking

Abstract

We present an attack on hardware security modules used by retail banks for the secure storage and verification of customer PINs in ATM (cash machine) infrastruc­tures. By using adaptive decimalisation tables and guesses, the maximum amount of information is learnt about the true PIN upon each guess. It takes an average of 15 guesses to determine a four digit PIN using this technique, instead of the 5000 guesses intended. In a single 30 minute lunch-break, an attacker can thus discover approximately 7000 PINs rather than 24 with the brute force method. With a Ј300 withdrawal limit per card, the potential bounty is raised from Ј7200 to Ј2.1 million and a single motivated attacker could withdraw Ј30-50 thousand of this each day. This attack thus presents a serious threat to bank security.

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 mag­netic 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 off with about 25 PINs.

However, HSMs implementing several common PIN generation methods have a flaw. The first 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 first four digits taken. Each digit has a range of 'O'-'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 confirm that the PIN does not contain the number 7, thus eliminating over 10% of the possible combinations. We first 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 de­scribes PIN generation and verification 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.