derive unique key per transaction

Hello everyone....
It has been a long time since I have written anything on my blog. I always wanted to write some useful information on my blogs that I learn hard way...but got carried away by other tasks

In his blog I will talk about how unique key per transaction works in ATM transaction environment.

What is derive unique key per transaction  (DUKPT)?

1. This method ensures that in each ATM transaction a unique key (theoretically) is used to encrypt your PIN or data when you do any transaction on ATM/POS device.
2. The unique key used in a transaction must not disclose any information about a previous key or future key used in the previous or future transactions. (It should be infeasible to get any other key out of it)


 Entities involved:
1. Acquirer : This is the acquirer of the ATM typically a bank which has control over the ATM and can initialize the ATM.
2.  ATM device/PIN pad on ATM : This is the device that encrypt the PIN/data.

both the above devices must have a TRSM (Tamper resistant security module) to store any keys.

In the core of DUKPT lies the BDK (Base derivation key) that is used to derive any key used in DUKPT scheme. BDK is only stored in a HSM (Hardware security module) / TRSM or out of HSM encrypted using a key stored on HSM (KM/LMK) at acquirer end. It is never stored on ATM devices.

If BDK is stored in acquirer end, a unique Initial key (IPEK) is stored on each ATM which is derived from a particular BDK. Each ATM device (I will use ATM, PIN entry device oe POS device interchangeably ) will have a initial serial number fixed for the lifetime of that device. This ISN has information about the BDK used to derive IPEK for that ATM.

IPEK derivation

Initial key (aka IPEK) is derived using a 10 byte field called KSN (Key serial number). This field contains information about the BDK, ATM id (unique for each ATM of a particular acquirer) and transaction counter (set to all zeros for IPEK derivation). Using these fields IPEK is derived that is used to initialize that HSM. Since each ATM has a unique ATM id this IPEK is also unique for each ATM.Different methods can be employed to initialize an ATM. e.g. Manual loading of key, key loading using a key loading device, using symmetric key techniques, using asymmetric key techniques etc). IPEK generation is always done using an HSM at acquirer side.

Unique key per transaction: 

Once ATM is initialized with IPEK, this IPEK is used to derive a unique key for each transaction. Unique key is derived for each transaction using IPEK, KSN (consisting BDK, ATM id, counter value). Each time a  new transaction is initiated counter value at the  ATM is increased (changed). Since BDK id and ATM id always remain same for a ATM, this transaction counter changes for each transaction and new transaction key is generated for each transaction at ATM. This unique key can be used to encrypt PIN, any other data (PAN etc) or calculate MAC. Of course a different variant is used for each purpose. Those who know about the key variants is fine. those who doesn't know a key variant is used to functionally separate key used for different purposes.

The KSN mentioned above is not a secret data and passed by ATM device to the acquired along with encrypted data.

At the acquirer end HSM is used to first generates IPEK(using KSN but taking counter as 0) and then generated transaction key using IPEK and KSN using the same algorithm that were used at ATM. I have mentioned in the previous post that PIN never resides in clear form outside an HSM therefore HSMs must provide a functionality to verify PIN encrypted under DUKPT transaction key. HSM generally take encrypted PIN (or data), KSN and BDK id as input. They then generate transaction key then decrypt PIN or data (after applying appropriate variant) and verify (PIN) or decrypt (data) it.

In the next blog I will describe how chip cards work... They are the future anyways.. I also wanted to talk about HSMs and there working but it might have to wait..

Feel free to write to me for any queries..