Danie Schutte (CEO of Erlang Financial Systems) stumbled upon my blog recently (thanks for reading, Danie). I'm thankful for this happenstance, because Danie is super-sharp on data encryption and other matters pertaining to the implementation of financial payment systems. Danie mentioned that my post about Creating an IPEK from a given KSN and BDK would pertain specifically to situations in which a Single DES PIN Encrypting Key is in play. For situations in which a Triple DES PIN Encrpyting Key is in play, Danie passes along the following methodology:
-----------------
Just for interest sake - the process of deriving the initial key (KEK) for the pos according to the ANSI specifications (This is for TDES)
Derivation of Initial Key (IPEK) from Base Derivation Key (BDK) The initial PIN Entry Device key (the key initially loaded into the PIN Entry
Device) is generated by the following process:
- Copy the entire key serial number, including the 21-bit encryption counter, right-justified into a 10-byte register. If the key serial number is less than 10 bytes, pad to the left with hex “FF” bytes.
- Set the 21 least-significant bits of this 10-byte register to zero.
- Take the eight most-significant bytes of this 10-byte register, and encrypt/decrypt/encrypt these eight bytes using the double-length derivation key.
- Use the ciphertext produced by Step 3 as the left half of the Initial Key.
- Take the 8 most-significant bytes from the 10-byte register of Step 2 and encrypt/decrypt/encrypt these 8 bytes using as the key the double-length derivation key XORed with hexadecimal C0C0 C0C0 0000 0000 C0C0 C0C0 0000 0000.
- Use the ciphertext produced by Step 5 as the right half of the Initial Key.
------------------
That also brings up a corresponding clarification required on my earlier piece entitled Doing PIN Translation (DUKPT to Triple DES). That post did a field-by-field breakdown of the CI/CJ command exchange with the Thales HSM. The Thales Host Command Reference Manual then follows that up with the G0/GI. [Note that it's G-zero, not G-Oh.] It's this second command exchange that should be employed should you be working with Triple DES DUKPT. The CI/CJ is for Single DES DUKPT only.
Hi Andy, I have a question regarding Danie's process above. Here's what I have:
BDK=04F415A7916E0EC7C42A62CD088F808F
KSN=FFFF1A1E120000100000(padded with FF's)
In step 3, do I really use the *SAME* BDK to encrypt, decrypt and encrypt the most significant 8 byte (FFFF1A1E12000010)? Wouldn't it produce the same result as just encrypting FFFF1A1E12000010 with the BDK once?
By the way, is Initial PIN Encryption Key (IPEK) equivalent to DUKPT Initial Key (DIK)?
Thanks a bunch!
Posted by: steve | Wednesday, December 27, 2006 at 14:11
A further clarification on the Triple DES version of the PIN Translation command (i.e, where you're going from DUKPT to Interchange Key encryption). This small point tripped me up, so I'm passing it along: The command exchange is G0/G1. The Thales manual uses a sans serif font, making it appear that the command exchange is 'G Oh, G Eye'. It's not. It's 'G Zero, G One'.
Posted by: Andy Orrock | Saturday, May 19, 2007 at 11:01
I try to apply the TDES DUKPT procedure to verify the DUKPT test sample data provided in Annex A.4, X9.24-2002, but the result (initial PED-key) is different. Can anyone help to validate the test sample data below? Thank you.
Here are the test sample data:
Derivation Key: 0123456789ABCDEFFEDCBA9876543210
Initially Loaded Key Serial Number (KSN): FFFF9876543210E00000
Initially Loaded PIN Entry Device Key: 6AC292FAA1315B4D 50731AE1601A2431
My Initially Loaded PIN Entry Device Key: 6AC292FAA1315B4D 858AB3A3D7D5933A
Posted by: KC | Monday, August 13, 2007 at 01:16
I tried the test data Andy posted and get the same results:
6AC292FAA1315B4D 858AB3A3D7D5933A
Has anyone found a resolution?
Are the procedures described above correct for deriving the right half of the IPEK?
Posted by: Chris Walashek | Thursday, August 16, 2007 at 13:36
Sorry, I am referring to the post by KC above, not Andy.
Posted by: Chris W | Thursday, August 16, 2007 at 13:40
KC, the test data you have from Annex A.4 is incorrect. The example IPEK that I have from X9.24-2004 is 6AC292FAA1315B4D 858AB3A3D7D5933A, which is the results we have calculated.
Posted by: Chris W | Monday, August 20, 2007 at 14:30
Andy, first of all it is very useful the information you have posted.
I am trying to understand DUKPT so I need more examples. According to the IPEK of the example, what are the next Pin Encryption Keys?.
The Thales command CI implies the use of ANSI X9.8 for the PIN Block, does it mean that the Pin Encryption Keys are DES keys? Could you post an example that shows the Pin Encryption Key and the encrypting Pin Block?.
Posted by: Franc | Sunday, February 03, 2008 at 23:53
what is ksn & KSN descriptor,how we find it?
is ther any hsm command through which, can able to find it.
kindly help me on this account.
Posted by: ZAIM RAZA | Saturday, March 22, 2008 at 08:12
how we encrypt the format 01 PIN Block?
thanks in advance :)
Posted by: ZAIM RAZA | Saturday, March 22, 2008 at 08:14
Hi Zaim,
Take a look at this post (both the main body of the post and the extensive commentary afterwards):
http://www.andyorrock.com/2006/04/doing_pin_trans.html
Posted by: Andy Orrock | Monday, March 24, 2008 at 11:21
Hi everybody!
I have the TIK value... but if I want the next derived key (for example the transaction counter of the KSN is 1), what is the algorithm to get the next key??
Thanks!
Posted by: jonef | Thursday, September 16, 2010 at 10:48
I am assuming that the ANSI Test Key the manufacturer of my device talks about is this 0123456789ABCDEFFEDCBA9876543210 BDK that everyone seems to use in examples. Is this correct?
Posted by: Travis Hoffman | Thursday, April 03, 2014 at 16:08