Document Text Contents
Page 7
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.
Encrypted_PIN_Verify(
A_RETRES , A_ED , // return codes 0,0=yes 4,19=no
trial_pin_kek_in , pinver_key , // encryption keys for enc inputs
(UCHAR*)"3624 " "NONE " // PIN block format
" F" // PIN block pad digit
(UCHAR*)" " ,
trial_pin , // encrypted_PIN_block
I_LONG(2) ,
(UCHAR*)"IBM-PINO" "PADDIGIT" , // PIN verification method
I_LONG(4) , // # of PIN digits = 4
"0123456789012345" // decimalisation table
"123456789012 " // PAN_data (account number)
"0000 " // offset data
);
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.
7
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.
Encrypted_PIN_Verify(
A_RETRES , A_ED , // return codes 0,0=yes 4,19=no
trial_pin_kek_in , pinver_key , // encryption keys for enc inputs
(UCHAR*)"3624 " "NONE " // PIN block format
" F" // PIN block pad digit
(UCHAR*)" " ,
trial_pin , // encrypted_PIN_block
I_LONG(2) ,
(UCHAR*)"IBM-PINO" "PADDIGIT" , // PIN verification method
I_LONG(4) , // # of PIN digits = 4
"0123456789012345" // decimalisation table
"123456789012 " // PAN_data (account number)
"0000 " // offset data
);
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.
7
