static (clear) BDK?

Dec 19, 2013 at 4:26 AM
Edited Dec 19, 2013 at 4:37 AM
We generate a BDK using BI command, and console shows:
 
Request: 1234BI;UU0
MAJOR>>>Parsing header and code of message 1234BI;UU0...
MAJOR>>>Searching for implementor of BI...
MAJOR>>>Found implementor ThalesSim.Core.HostCommands.BuildIn.GenerateBDK_BI, instantiating...
MINOR>>>=== [BI], starts 13:30:54.738 =======
MAJOR>>>Calling AcceptMessage()...
MINOR>>>[Key,Value]=[Delimiter,;]
[Key,Value]=[Key Scheme LMK,U]
[Key,Value]=[Reserved,U]
[Key,Value]=[Reserved 2,0]

MAJOR>>>Calling ConstructResponse()...
MINOR>>>New BDK (clear): EF3D7A252AA8EAF82919E6C4D99EC86B
MINOR>>>New BDK (LMK): U243095316AC1757907565118B441BB31
MAJOR>>>Calling ConstructResponseAfterOperationComplete()...
MAJOR>>>Attaching header/response code to response...
MAJOR>>>Sending: 1234BJ00U243095316AC1757907565118B441BB31
MINOR>>>=== [BI], ends 13:30:54.748 =======
 
In our implementation, we use this clear BDK in pin pad and an initial KSN to generate per device IPEK.

Pin pad sends 3DES encyrpted pinblock in Ansi9.8 ISO-0 to server with KSN, and we pass to Thales using command CI which translates successfully:
MAJOR>>>Calling AcceptMessage()...
MINOR>>>[Key,Value]=[Account Number,999999999999]
[Key,Value]=[BDK,243095316AC1757907565118B441BB31]
[Key,Value]=[BDK Scheme,U]
[Key,Value]=[Destination PIN Block Format Code,01]
[Key,Value]=[Encrypted Block,7C6E2C03F30AADBF]
[Key,Value]=[Key Serial Number,FFFF0123456789E00002]
[Key,Value]=[KSN Descriptor,605]
[Key,Value]=[ZPK,450CF23F70F182EB]

MAJOR>>>Calling ConstructResponse()...
MINOR>>>Clear source BDK: UEF3D7A252AA8EAF82919E6C4D99EC86B
MINOR>>>Clear target ZPK: 5E752CA43194A8F4
MINOR>>>Clear PIN Block: 04551E6666666666
MINOR>>>Clear PIN: 5587
MINOR>>>New clear PIN Block: 04551E6666666666
MINOR>>>New crypt PIN Block: 4A2D6BFA62BB9866
MAJOR>>>Calling ConstructResponseAfterOperationComplete()...
MAJOR>>>Attaching header/response code to response...
MAJOR>>>Sending: 0004CJ00044A2D6BFA62BB986601
MINOR>>>=== [CI], ends 13:31:46.154 =======
 
However, if we restart server calling BI again, it generates a new clear BDK and the translation of pin block fails:
MAJOR>>>Parsing header and code of message 0004CIU90AB1164E510816161D4D74C312A83C41CC5DB1D37156A0B605FFFF0123456789E000027C6E2C03F30AADBF01999999999999...
MAJOR>>>Searching for implementor of CI...
MAJOR>>>Found implementor ThalesSim.Core.HostCommands.BuildIn.TranslatePINFromDUKPTToZPK_CI, instantiating...
MINOR>>>=== [CI], starts 13:32:27.154 =======
MAJOR>>>Calling AcceptMessage()...
MINOR>>>[Key,Value]=[Account Number,999999999999]
[Key,Value]=[BDK,90AB1164E510816161D4D74C312A83C4]
[Key,Value]=[BDK Scheme,U]
[Key,Value]=[Destination PIN Block Format Code,01]
[Key,Value]=[Encrypted Block,7C6E2C03F30AADBF]
[Key,Value]=[Key Serial Number,FFFF0123456789E00002]
[Key,Value]=[KSN Descriptor,605]
[Key,Value]=[ZPK,1CC5DB1D37156A0B]

MAJOR>>>Calling ConstructResponse()...
MAJOR>>>Exception while processing message
System.ArgumentOutOfRangeException: Index and length must refer to a location within the string.
Parameter name: length
at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
at ThalesSim.Core.PIN.PINBlockFormat.ToPIN(String PINBlock, String AccountNumber_Or_PaddingString, PIN_Block_Format Format) in C:\Users\Documents\ThalesSim.Src.0.9.6\ThalesCore\PIN\PINBlockFormat.vb:line 177
at ThalesSim.Core.HostCommands.BuildIn.TranslatePINFromDUKPTToZPK_CI.ConstructResponse() in C:\Users\Documents\ThalesSim.Src.0.9.6\ThalesCore\HostCommands\BuildIn\TranslatePINFromDUKTPToZPK_CI.vb:line 108
at ThalesSim.Core.ThalesMain.WCMessageArrived(WorkerClient sender, Byte[]& b, Int32 len) in C:\Users\Documents\ThalesSim.Src.0.9.6\ThalesCore\ThalesMain.vb:line 778
MAJOR>>>Disconnecting client.
 
Our work suggests pin pad is initialised with static clear BDK, and BSK should not change.

Why does the simulator create a new clear BDK each time, and does a production Thales HSM also demonstrate this behaviour? Or, is there a BDK under LMK that should be used for IPEK generation?

Many thanks!
Dec 19, 2013 at 1:29 PM
Hi tozzi21

my understanding is that the BDK should be used to generate an IPEK on the HSM based on the KSN. the IPEK is then loaded on the terminal

the IKEY can be exported under a previously agreed transport key

on the terminal, a new key is generated based on the IPEK and KSN to encrypt a PIN block. the original, encrypted BDK, the KSN and encrypted PIN block can then be supplied to an HSM to translate

NB: in production, you'd never have access to a clear BDK
Dec 19, 2013 at 3:43 PM
Hello hexdrill

online reading e.g. http://stackoverflow.com/questions/17362567/how-ciphertext-was-generated-in-card-reader-using-dukpt-encryption discusses the process though never specifies where BDK/KSN/IPEK generation actually takes place.

interestingly, my reader expects me to provide a BDK and initial KSN, and will then generate the IPEK itself. it therefore assumes we have access to the clear BDK. now it sense that we will not have access to clear BDK, and we might need to change the firmware.

does command OC (or A2) print clear BDK to an attached printer, or is BDK only ever exposed under LMK 28-29?

i've been unable to find any reference on generating IPEK on HSM. any experience or guidance?

many thanks!
Dec 20, 2013 at 4:46 PM
going over Thales 9000 documentation shows command A0 with ability to derive key IPEK (IKEY). it allows selection of type of BDK (type 1 bidirectional vs 2 unidirectional), and specifying the KSN.

simulator does not support this A0 function for IPEK when sending: 0000A0A302U01... seems to be expecting ZMK even though not needed (only required if mode = '1' or 'B').

yet, our production system employs only Thales 8000.

any guidance on generating IPEK/IKEY?
Dec 20, 2013 at 7:27 PM
unfortunately, i'm away from my desk for a couple of weeks so won't be able to help for a bit

i do know that significant changes were introduced recently on the 9000 for generation and export of IPEKs, so i don't know how successful you'll be on the 8000

i'll try to have a look in the new year

H
Dec 21, 2013 at 3:57 AM
Edited Dec 21, 2013 at 4:28 AM
thanks hexdrill

ive gone over the HSM operations and installation manual (of RG7000) which provides GC command (generate key component). interestingly, it suggests output will be displayed in plain and encrypted form:
Connected - Type in commands followed by ENTER.
GC
Key length [1,2,3]: 2
Key Type: 009
Key Scheme: U
Clear Component: FB7F 07C7 61F8 A82A 0ECD 6B19 E3C8 97BF
Encrypted Component: U D85D 2C6C E7D0 9064 EA43 26A6 57AC 0784
Key check value: E7CF C1
 
 
The clear component is the BDK, while encrypted component is BDK under LMK 28-29. Keys worked in simulated code, will now test on actual hardware HSM.

Will post an update with next findings.