PIN Generation & Verification Techniques

There are a number of techniques for PIN generation and verification, each proprietary to a particular consortium of banks who commissioned a PIN processing system from a different manufacturer. The IBM CCA supports a representative sample, shown in Figure 2. We IBM 3624-Offset method in more detail as it is typical of decimalisation table use.

3.1 The IBM 3624-Offset PIN Derivation Method

The IBM 3624-Offset method was developed to support the first generation of ATMs and has thus been widely adopted and mimicked. The method was designed so that offline ATMs would be able to verify customer PINs without needing the processing power and

Method	Uses Dectables
IBM 3624	yes
IBM 3624-Offset	yes
Netherlands PIN-1	yes
IBM German Bank Pool Institution
VISA PIN-Validation Value
Interbank PIN

Figure 2: Common PIN calculation methods

storage to manipulate an entire database of customer account records. Instead, a scheme was developed where the customer's PIN could be calculated from their account number by encryption with a secret key. The account number was made available on the magnetic stripe of the card, so the ATM only needed to securely store a single cryptographic key. An example PIN calculation is shown in Figure 4.

The account number is represented using ASCII digits, and then interpreted as a hexadecimal input to the DES block cipher. After encryption with the secret "PIN gen­eration" key, the output is converted to hexadecimal, and all but the first four digits are discarded. However, these four digits might contain the hexadecimal digits 'A'-'F', which are not available on a standard numeric keypad and would be confusing to cus­tomers, so they are mapped back to decimal digits using a "decimalisation table" (Figure 3).

0123456789ABCDEF 0123456789012345

Figure 3: A typical decimalisation table

Account Number 4556 2385 7753 2239

Encrypted Accno 3F7C 2201 00CA 8AB3

Shortened Enc Accno 3F7C

0123456789ABCDEF 0123456789012345

Decimalised PIN 3572 Public Offset 4344

Final PIN 7816

Figure 4: IBM 3624-Offset PIN Generation Method

The example PIN of 3F7C thus becomes 3572. Finally, to permit the cardholders to change their PINs, an offset is added which is stored in the mainframe database along with the account number. When an ATM verifies an entered PIN, it simply subtracts the offset from the card before checking the value against the decimalised result of the encryption.

3.2 Hardware Security Module APIs

Bank control centres and ATMs use Hardware Security Modules (HSMs), which are charged with protecting PIN derivation keys from corrupt employees and physical at­tackers. An HSM is a tamper-resistant coprocessor that runs software providing crypto­graphic and security related services. Its API is designed to protect the confidentiality and integrity of data while still permitting access according to a configurable usage policy. Typical financial APIs contain transactions to generate and verify PINs, translate guessed PINs between different encryption keys as they travel between banks, and support a whole host of key management functions.

The usage policy is typically set to allow anyone with access to the host computer to perform everyday commands such as PIN verification, but to ensure that sensitive functions such as loading new keys can only be performed with authorisation from multiple employees who are trusted not to collude.

IBM's "Common Cryptographic Architecture" [6] is a financial API implemented by a range of IBM HSMs, including the 4758, and the CMOS Cryptographic Coprocessor (for PCs and mainframes respectively). An example of the code for a CCA PIN verification is shown in Figure 5.

Figure 5: Sample code for PIN verification in CCA

The crucial inputs to Encrypted_PIN_Verify are the decimalisation table, the PAN_data, and the encrypted_PIN_block. The first two are supplied in the clear and are straightforward for the attacker to manipulate, but obtaining an encrypted_PIN_block that represents a chosen trial PIN is rather harder.

3.3 Obtaining chosen encrypted trial PINs

Some bank systems permit clear entry of trial PINs from the host software. For instance, this functionality may be required to input random PINs when generating PIN blocks for schemes that do not use decimalisation tables. The appropriate CCA command is Clear_PIN_Encrypt, which will prepare an encrypted PIN block from the chosen PIN. It should be noted that enabling this command carries other risks as well as permitting our attacks. If there is not randomised padding of PINs before they are encrypted, an attacker could make a table of known trial encrypted PINs, compare each arriving encrypted PIN against this list, and thus easily determine its value. If it is still necessary to enable clear PIN entry in the absence of randomised padding, some systems can enforce that the clear PINs are only encrypted under a key for transit to another bank - in which case the attacker cannot use these guesses as inputs to the local verification command.

So, under the assumption that clear PIN entry is not available to the attacker, his second option is to enter the required PIN guesses at a genuine ATM, and intercept the encrypted PIN block corresponding to each guess as it arrives at the bank. Our adaptive decimalisation table attack only requires five different trial PINs - 0000 , 0001 ,0010 , 0100 , 1000. However the attacker might only be able to acquire encrypted PINs under a block format such as ISO-0, where the account number is embedded within the block. This would require him to manually input the five trial PINs at an ATM for each account that could be attacked - a huge undertaking which totally defeats the strategy.

A third and more most robust course of action for the attacker is to make use of the PIN offset capability to convert a single known PIN into the required guesses. This known PIN might be discovered by brute force guessing, or simply opening an account at that bank.

Despite all these options for obtaining encrypted trial PINs it might be argued that the decimalisation table attack is not exploitable unless it can be performed without a single known trial PIN. To address these concerns, we created a third algorithm (described in the next section), which is of equivalent speed to the others, and does not require any known or chosen trial PINs.