What is the DUKPT Key Derivation Function?

Question

I'm tasked with decrypting ciphertext acquired from an encrypted card reader. The card reader utilizes DUKPT(derived unique key per transaction) scheme and 3DES encryption. I don't have a problem with the 3DES encryption as it is a common algorithm implemented by well known libraries like BouncyCastle and Java JCE.

Prior to this assignment, I have had no encounters with DUKPT at all so I am a complete newbie to this.

From what I have read so far, DUKPT utilizes a key derivation mechanism based on a Base Derivation Key(BDK) which is basically a shared secret key and Key Serial Numbers for the particular transaction. In the case of the card reader, each time I swipe(even with the same card), the cipher text would be different and the KSN would be different. Knowing the BDK, the KSN, the encryption algorithm(which in this case is 3DES) and the cipher text, how do I go about deriving the Key for the transaction based on this information? I would imagine there is some sort of key derivation function right?

Answer 1

It basically works like this: the server has a master key (the BDK) and each client device has a unique serial number and a counter (which when combined are the KSN).

To set up a new device you encrypt the KSN using the master key (the BDK, the process described in the link in Yoav's answer) and you get a new key (the IPEK). It's kind of like where you need two people (the server and the client) with two keys (the BDK and the KSN) to open a vault that contains another key. That other key is the IPEK and is what you install on the device itself.

The client device uses the IPEK to come up with a table of Future Keys and then discards the IPEK. So the client device now has it's original serial number, a counter (combined are the KSN) and a list of Future Keys.

To encrypt the data, the client device grabs the first Future Key from the list and uses that as the encryption key. It then sends the encrypted data and it's KSN (which contains the counter) to the server.

On the server end, the server knows it's own secret (the BDK) and now has the clent device's KSN. The server uses those two keys to produce the IPEK (open that vault again). With the IPEK the server can recreate the table of Future Keys and knowing the counter provided by the client (the last 5 characters of the KSN) it knows which key from the table to use.

As for all the technical details I would suggest looking around Andy Orrock's blog (linked to in Yoav's answer) and maybe getting a copy of ANSI X9.24 which has the full spec.

Answer 2

Couldn't find many resources online, but I imagine this should be spec'd quite comprehensively somewhere. What I did find out however is this description of the derivation process.

If I understand this correctly, the derivation function works roughly as follows:

1. The KSN is normalized using some form of padding
2. The normalized KSN is then encrypted with the BDK
3. The output of this process is the derived key for the transaction

Hope I'm not misleading you. This probably deserves an answer from someone more closely familiar with the actual specifications.

Answer 3

The details of how to create the future keys are quite horrible but they are contained in the ANSI spec. The spec is not officially available online but if you search in Google for "Baidu ansi x9.24" you will get a link to the 2004 version (the current is 2009). Reading it on the Baidu (the Chinese answer to Google) web site is unpleasant but the $140 that ANSI wants to charge is even more unpleasant. Having invested the money in the current version of the spec (after playing with Baidu for a few days), I can attest that the process is anything but obvious.