Check out the new USENIX Web site. next up previous
Next: The Resilient On-line Transaction Up: A Resilient Access Control Previous: Introduction

Analysis of Needham's Example

Needham's PIN code management system differs from current ATM systems in the generation and handling of the PIN code. Most ATM systems use encryption to protect customers' PINs. The details vary from one bank to another, but many use variants of a system originally developed by IBM, in which the PIN is derived from the account number by encryption. That is, PINs are generated by banks. This makes it difficult to resolve disputes between banks and their customers [And94].

In Needham's proposal, banks do not know customers' PINs. A PIN code is generated by a customer herself, and is not stored by the bank. From the bank's point of view, this feature liberates it from the responsibility for internal leakage of PINs and assurance of their fair and truly random generation. Banks thus have a defence against an allegation that they negligently permitted the PIN to become known. For customers, they can obtain more privacy by generating and keeping their own PINs for themselves.

Needham's scheme is described under the assumption that a customer has a personal computer and a card writer. Let H be a one-way hash function. To initialise the scheme, the customer writes on the card a random number r and a hash H(n,b) of her name n and date of birth b. She writes H(n,b) and H(r,pin) on a floppy disk, where the pin is chosen by herself. She then takes the floppy to the bank and says ``Please connect H(r,pin) to my personal details H(n,b) and my account number 401608 80614874".

When a cash machine accepts her card, it reads H(n,b) and r, works out H(r,pin) where pin is the PIN as entered, and sends the value H(n,b) and H(r,pin) to the bank. Note that the PIN is never sent to the bank and as r is random it cannot be recovered from H(r,pin). The bank looks up H(r,pin) and if it is found, the table yields H(n,b) for checking as well as the account number.

In this example, there are two principals and one intermediate: a customer and a bank are principals and an ATM is an intermediate. A banking transaction is performed between a customer and a bank, and authentication procedures are done by an ATM and a bank. The ATM checks the validity of a card holder by PIN entered, the bank checks a customer's information and her account number by H(r,pin).

The separation of capability between principals is well defined, but there is no such separation between the customer and the ATM. The assumption that the PIN is never sent to the bank even in encrypted form requires the customer trusts the ATM and its operator. The role of the ATM is more important than at present and a false-terminal attack using a corrupted ATM is still possible. However this is inherent in the use of magnetic strip technology.

A replay attack for the pair of hash values (H(n,b),H(r,pin)) is possible on a communication line between an ATM and a bank. If an attacker takes the hash pair from the line, he can replay this pair on the same line and be authorised as a valid customer by a bank. Since the two values are always the same, they can be used at any time by attackers. We could prevent such attacks, of course, by installing a time-varying encryption or authentication mechanism on the line between the bank and ATMs. However, the bank would then join the ATM inside the customer's trust perimeter, and the value of the scheme would be lost. Against replay attacks, we use a nonce for each transaction in our payment scheme.


next up previous
Next: The Resilient On-line Transaction Up: A Resilient Access Control Previous: Introduction

Jong-Hyeon Lee, Computer Laboratory, University of Cambridge, 1998.