Decimalisation Table Attacks For PIN Cracking.pdf

Technical Report

UCAM-CL-TR-560

ISSN 1476-2986

Number 560

Computer Laboratory

Decimalisation table attacks for PIN

cracking

Mike Bond, Piotr Zieli nski

February 2003

15 JJ Thomson Avenue

Cambridge CB3 0FD

United Kingdom

phone +44 1223 763500

http://www.cl.cam.ac.uk/

2003 Mike Bond, Piotr Zieli nski

Technical reports published by the University of Cambridge

Computer Laboratory are freely available via the Internet:

http://www.cl.cam.ac.uk/TechReports/

Series editor: Markus Kuhn

ISSN 1476-2986

Decimalisation table attacks for PIN cracking

Mike Bond, Piotr Zielinski

Abstract

We present an attack on hardware security modules used by retail banks for the

secure storage and verication 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 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

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 conrm 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 de-

scribes PIN generation and verication 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 accom-

panied by sucient 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 expo-

sure of a given aw, which could be an isolated incident or the tip of a huge iceberg. This

sort of risk management conicts directly with modern security design practice where ro-

bustness is crucial. There are useful analogues in the design of cryptographic algorithms.

Designers who make \just-strong-enough" algorithms and trade robustness for speed or

export approval play a dangerous game. The cracking of the GSM mobile phone cipher

A5 is but one example [3].

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 signicant

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 identied 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 camouaged within the banks audit trails. PIN verications 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 condential from programmers.

So as the economics of security aws 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 con-

tinually reshape the landscape over which legal disputes between bank and customer are

fought.

3 PIN Generation & Verication Techniques

There are a number of techniques for PIN generation and verication, each proprietary

to a particular consortium of banks who commissioned a PIN processing system from a

dierent manufacturer. The IBM CCA supports a representative sample, shown in Figure

2. We IBM 3624-Oset method in more detail as it is typical of decimalisation table use.

3.1 The IBM 3624-Oset PIN Derivation Method

The IBM 3624-Oset method was developed to support the rst generation of ATMs and

has thus been widely adopted and mimicked. The method was designed so that oine

ATMs would be able to verify customer PINs without needing the processing power and

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: