Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
"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." This is the part that I still need to know. How to I recreate the key based on the counter. –  Hyangelo Apr 2 '12 at 14:28
add comment

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.

share|improve this answer
    
I guess I should comment that I got the examples from the spec working using the OpenSSL 3DES routines. –  RC Bryan Apr 19 '12 at 5:34
1  
You're right, I took a quick peek and it looks daunting. In the annex that was describing the algorithm, the style and tone of the document isn't friendly. FYI, we decided to go with MagTek's Magensa service which offloads the key management and decryption workloads off our backs. –  Hyangelo Apr 19 '12 at 14:32
    
It sounds like that would save a lot of headaches. I kind of wish we had that as an option. –  RC Bryan Apr 20 '12 at 19:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.