Line Encryption

Jun 23, 2012 at 3:36 PM


Need urgent help of yours. We are currently trying to implement Line Encryption on THALES HSM 9000. We have a MSR Encrypted Card Reader which reads clear Track 2 & using BDK/IPEK burned on the MSR it encrypts the same. The BDK has been configured into HSM.

When we send M2 command to HSM to decrypt the encrypted Track 2, we are getting incorrect decrypted value though M3 returned with error code 00. Below is the trace of HSM for your perusal -

[Feb 04 18h11:54.194] - [M2] Tx Request to: Thales at
[None       ans 004 M] : 'Message Header' = [0004]
[None       an  002 M] : 'Command Code' = [M2]
[None       n   002 M] : 'Mode Flag' = [00]
[None       n   001 M] : 'Input Format Flag' = [1]
[None       n   001 M] : 'Output Format Flag' = [1]
[None       Hex 003 M] : 'Key Type' = [009]
[16H/1A+32H/1A+48H  M] : 'Key' = 'U235D25D832677241B53ADE6A4F078F05'
[None       Hex 003 M] : 'KSN Descriptor' = [605]
[None       Hex 160 M] : 'Key Serial Number' = '3231373035393135'
[LLLLVAR:   b   000 M] : 'Encrypted Message' = *[4636303239373442324437434536443434354141343735373743363833453839333033303842333939354336373733363834443443353431393543333346463039303244353634303343374532323544]


[Feb 04 18h11:54.204] - [M3] Rx Response from: Thales at
[None       ans 004 M] : 'Message Header' = [0004]
[None       an  002 M] : 'Response Code' = [M3]
[None       an  002 M] : 'Error Code' = [00]
[LLLLVAR:   b   000 M] : 'Decrypted Message' = *[4143443537463030354237324137304135304230423135363538394234333642373744364234393434313936353434434238453741443646393636444535454145464331383431313335313446324144]


Thanks in advance.

Jun 26, 2012 at 10:01 AM

I'm not sure what exactly is the question. Can you be a bit more specific?

Is this a Postilion trace BTW?

Jun 26, 2012 at 10:23 AM

Yes it is Postilion Trace. We have installed Line Encryption on Thales HSM 9000 to decrypt Track 2 data.

The Track 2 is read by a Mobile Card Reader which encrypts Track 2 using IPEK generated from BDK burned on it. The same BDK we have also configured in HSM.

When we send M2 command alongwith encrypted Track 2 data (Hex)of size 80bytes, we get M3 message from HSM with response code as 00 alongwith decrypted value. But the decrypted value isn't the same that we are expecting, instead its sending some garbage value.

Please help.

Jun 26, 2012 at 11:32 AM

I'm not sure it's easy for someone to say what exactly is wrong given this data only. The only thing that is definitely OK is the format of the BDK...but that doesn't mean much anyway. Several other problems might exist, with the following being a few possibilities:

  1. The card reader might have the wrong BDK burned on it.
  2. The card reader might have been initialized with an incorrect KSN.
  3. The card reader might not calculate the derived key correctly, hence the data would be encrypted with a different key than the one expected.

(1) and (2) hint at incorrect sync between Postilion and card reader cryptography (a configuration issue). (3) is an implementation issue. I don't know what the correct way to chase this problem should be. Personally, I would be very keen to have some kind of debug/trace visibility on the encryption process as that is performed by the card reader but that's not always easy....unless of course there is a simulator of sorts for the card reader itself.

In any event, you should probably talk to your card reader vendor to get some assistance. I'm not sure how ACI would respond to a related query, but they might require professional services to assist you with such an issue that might very well not be a Postilion issue.

Jun 26, 2012 at 12:32 PM


Below is the encryption method the vendor shared with us -

Track 1 and Track 2 Encrypted
This field is the encrypted Track data, using either TDES-CBC or AES-CBC with initial vector of 0. If the original data is not a multiple of 8 bytes for TDES or a multiple of 16
bytes for AES, the reader right pads the data with 0. The key management scheme is DUKPT. The key used for encrypting data is called the Data Key. Data Key is generated by first taking the DUKPT Derived Key exclusive or’ed with 0000000000FF0000 0000000000FF0000 to get the resulting intermediate variant key. The left side of the intermediate variant key is then TDES encrypted with the entire 16-byte variant as the key. After the same steps are preformed for the right side of the key, combine the two key parts to create the Data Key.

Also, if lets say is any of the 3 scenarios given by you is true, then how HSM is returning M3 Response Code 00 ?

Please help.

Jun 26, 2012 at 2:12 PM

To answer your question, a DES decrypt operation does not generate errors by default. For example, when I encrypt 0000000000000000 with key 0123456789ABCDEF I get D5D44FF720683D0D. But if I use the key 0123456789ABCDFF to decrypt D5D44FF720683D0D I get E096727D3DD34859 instead of 0000000000000000 - however, no error occurs. That is something that no Thales command can catch.

The rest of the text describes how your encrypt scheme (DUKPT) works. It's pretty much what is implemented in Thales simulator. I don't see how the description would help though.

Oct 31, 2012 at 10:52 AM
Edited Oct 31, 2012 at 11:17 AM


I'm having the same issue as SagarGoswami. We are currently using a Magtek SCRA with a our own BDK with a Thales HSM8000 loaded with the same key. However, m3 response doesn't correct decrypted data.

Our encryption method is 3DES CBC mode, it also contains an IV

We send the following to the HSM:

getKSN:xxxxxxxxxxxxxxxxxxxx <20-bits where BDK is 7-bits, Device Serial is 8-bits, Transaction Counter is 5-bits>

getTrack2:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx <80-bits>

What command codes do we need to send to the HSM?

Our country is not very familiar with setting up HSMs for DUKPT(3DES). The Thales guys here have no clue what they  are doing here, so they are calling other offices to get the answers.

Please help.