Doing PIN Translation (DUKPT to Triple DES)

On PIN-enabled Debit/EBT transactions sent in from an acquirer's point-of-sale location, your payment switch application must perform a PIN translation, typically transforming an incoming DUKPT PIN block from the POS device-initiated request into a outgoing Triple DES-encrypted PIN block that makes use of an established Zone PIN Key ("ZPK") which would have been previously established via a dynamic key exchange with your Debit/EBT gateway provider.

[The remainder of this example assumes you're using a Thales (formerly Racal) Hardware Security Module ("HSM")....]

Using strict Thales parlance, this variant of a PIN translation request is a request to “translate a PIN from *BDK encryption to interchange key encryption.”  This topic is covered in Section 27.2 (page 2-185) of the Thales reference document entitled “Host Security Module RG7000 Programmer’s Manual” (Thales reference number 1270A514 Issue 5).

The CI/CJ exchange should be handled as follows:

--- CI ---

Message header - You can use as you see fit. Value is echoed back in CJ.  Note that the length is constant and must be configured in HSM by administrator.

Command code - CI

BDK - The Base Derivation Key “in play” for this transaction.  In my installations we've set this up as follows...

• Selected the “1A + 32H” option, where the ‘1A’ value should be set to ‘U’
• Configured such that the first six positions of the KSN represent the “key name” of the BDK injected into the PIN Pad at the transaction origination point (an acquirer can use a number of BDKs in their terminal population).

ZPK - Your current ZPK Cryptogram (obtained dynamically via a key exchange with your Debit/EBT  gateway partner) and stored under your Local Master Key ("LMK").  In my installations, we've used the “1A + 32H” option, where the ‘1A’ value should be set to ‘U’.

KSN Descriptor - This value is a bit esoteric and refers directly to the make-up of the KSN which follows.  So to understand the descriptor, it's first necessary to talk a bit about the KSN (the next field in the CI command layout).  Here's a typical KSN implementation where the acquirer has chosen a 16-position scheme:

• Positions 1 – 6: The name of the BDK injected into this device
• Positions 7 – 11:  The device ID
• Positions 12 – 16: The transaction counter

[Note that the KSN implementation has to be in synch between the PIN pad and your host-side implementations in order for this to work.]

The 'rules' for a KSN construction are as follows (reading from left to right in the KSN):

a. The 'base derivation key identifier,' which is mandatory and five to nine (Hex) positions in length.

b. A 'sub-key identifier,' which Thales says is 'optional' but in practice is 'reserved for future use' (and therefore always set to zero).

c. A 'device identifier' (mandatory), which is two to five Hex digits in length.

d. A 'transaction counter' (mandatory) which essentially is the part "left over".

So, in the example here, the client with a 6, 0, 5, 5 implementation.

With this information in hand, the KSN Descriptor (a three-position value) is better described as XYZ, where:

X = base derivation key identifier length

Y = sub-key identifier key length (will be zero)

Z = device identifier length

So, in this context, the '605' submitted in my example is better visualized. '605' says that the 16-digit KSN consists of a 6-position BDK ID, a 0-position sub-key, a 5-position device ID, **AND** (what's remaining basically) a 5-position transaction counter.

[NOTE: Remember that this post applies *specifically* to the Thales/RACAL implementation of PIN translation]

Now, with this informatation in hand, we can introduce the next field, the KSN itself...

KSN - Using the layout from the descriptor, a typical KSN at this acquirer might be 123456000A8001D4 where: ‘123456’ is the BDK indentifier; '000A8' is the Device ID; and ‘001D4’ is the transaction counter.
   
The BDK name embedded in a particular KSN string must find a match within your BDK cryptogram list (which you need to keep loaded into your payment switch's encryption database).  If a match is not found in the encryption database, then set your Internal Result Code to "Invalid BDK" and end the transaction.  If found, the value you retrieve goes into the BDK field (as described above).

Source encrypted block - The PIN block plucked from the POS device request (this is a 16H value; no ‘1A’ indicator is required).

Destination PIN block - In my installations, we typically use ANSI format, so we set this to ‘01’ to signify ANSI format code

Account Number - Right-most 12 positions of the PAN excluding the check digit

Typically, that is the END of the required CI request message (remainder of the fields in the Thales spec are not mandatory).

--- CJ ---

Message header - Echoed back from CI usage.

Response code - CJ

Error Code - Only ‘00’ should be accepted as an exchange that “worked.”

PIN length - Although this field is not used to build the 0200 message formatted for your Debit/EBT gateway, a value like ‘04’ or ‘05’ here are a pretty good indication that the translation occurred successfully.   

Encrypted PIN - The PIN block that will be used to build the 0200 message formatted for your Debit/EBT gateway (this is a 16H value; no ‘1A’ indicator is required).

Destination PIN block - Echoed back from the device as ’01’ format code

Typically, that is the END of the response message (remainder of list in the vendor spec would only be present if they were provided in the CI command request).

Comments

[paresh]

Please HELP......Can you explain the KSN descriptor value in another way other that the way you have done it above....i'm totaly confused.....

[Andy Orrock]

Paresh -

I can understand the confusion here because it baffled me, too, when it was first presented to me by the Thales distributor. But I appreciate you posting the question, because I've got better information on hand now (vs. when I originally posted this note) and as a result I think I can clarify this for you. In retrospect, it was described poorly to me to begin with. I have a better handle on it now:

The KSN itself is composed of (from left to right)...

a. The 'base derivation key identifier,' which is mandatory and five to nine (Hex) positions in length.

b. A 'sub-key identifier,' which Thales says is 'optional' but in practice is 'reserved for future use' (and therefore always set to zero).

c. A 'device identifier' (mandatory), which is two to five Hex digits in length.

d. A 'transaction counter' (mandatory) which essentially is the part "left over".

With this information in hand, the KSN Descriptor (a three-position value) is better described as XYZ, where:

X = base derivation key identifier length

Y = sub-key identifier key length (will be zero)

Z = device identifier length

So, in this context, the '605' submitted in my example is better visualized. '605' says that the 16-digit KSN consists of a 6-position BDK ID, a 0-position sub-key, a 5-position device ID, **AND** (what's remaining basically) a 5-position transaction counter.

[NOTE: Remember that this post applies *specifically* to the Thales/RACAL implementation of PIN translation]

[retr0]

Hallo!
Don't know if you can assist me in getting the information on Derived Unique Key Per Transaction (DUKPT) architecture in the POS environment, which is described in the determined ANSI version. Mainly, don't understand what is the KSN descriptor and how it gets in the POS-terminal. Is it a functionality of the special software installed in a POS-terminal? And what exactly encrypts the DUKPT- pin block? If so, what is the purpose to use PIN encryption key? The requested info is needed for the production processes on my job. Thank you for the help, in advance!

[Andy Orrock]

You have to work in conjunction with a PIN Pad vendor. It's their responsibility to help you (and/or your client) inject the Base Derivation Key in the device and adopt a KSN scheme that is in alignment with your set-up on the host. So, while the KSN Descriptor doesn't actually go *into* the POS device, the vendor will have a way to set up a scheme whereby they construct a KSN in a manner in which you're expecting it. So, you'd work with that vendor to, for example, adopt a scheme in which you use six-digit BDK Descriptors and five-digit Transaction Counters. If so, you'd get a KSN that looked like this:

aaaaaabbbbbccccc

...where:

aaaaaa - The BDK Identifer
bbbbb - The Device (PIN Pad, that is) ID
ccccc - The Transaction Counter

Then, you'd feed the HSM that KSN along with '605' as the KSN Descriptor (assumes you're using a Thales here).

[Francisco Su Wong]

Hello!!, Now i am working in an enterprise that gives solutions for financial business, and right now we dont know so much about duktp, first we dont know how to get a KSN, if our supplier (SAGEM) have to give us or we have to take for another place. I would be delighted that you can help me.

[Andy Orrock]

Hi, Francisco.

As stated in the piece:

"Note that the KSN implementation has to be in synch between the PIN pad and your host-side implementations in order for this to work."

Then, in the earlier comments I say:

"You have to work in conjunction with a PIN Pad vendor. It's their responsibility to help you (and/or your client) inject the Base Derivation Key in the device and adopt a KSN scheme that is in alignment with your set-up on the host. So, while the KSN Descriptor doesn't actually go *into* the POS device, the vendor will have a way to set up a scheme whereby they construct a KSN in a manner in which you're expecting it."

[Nathan Erenthal]

i looking for help how DUKPT work why i can't take this information one's i get from the pin pad if i have the account number and the Encrypted PIN why can't i reused it
thanks in advance

[Andy Orrock]

I'm not sure I totally understand your question, as the piece clearly points out that you need the KSN + the BDK in addition to the PAN and PIN Block in order to decrypt or translate a DUKPT-encrypted PIN Block.

The KSN prevents the re-use of a PIN block.

[Buck]

Hello Andy. In your article you have described the values, which hsm sends to host.We use Thales RG7000. In logs it do not show full track2 number, only 12 digits from PAN.How can we turn on track2 logging? What do we need to do?Best Regards.

[Andy Orrock]

Are you referring to the log showing the command formatted and sent to the Thales? It would not show the full Track II, only the last 12 positions of the PAN. Track II logging on the HSM side wouldn't apply - the Thales has no knowledge of a full Track II, only the last 12 of the PAN, which your app must pluck out of the Track II in play when constructing the command.

[Buck]

"Thales RG7000 message sent to 192.168.1.27,9990"
So i understand. What do i need to do to get them? We must look for any other ways. May be get them from network traffic ? I think hsm must receive(and send?) them for further processing but simply do not show them in log.
Regards

[Buck]

Andy, are there any commands to show them in log?

[Andy Orrock]

Whose log? Your application controls that, not the HSM. You can log what your application is sending, but that's an application setting, not the HSM. the Thales has Error and Audit logs, not command logs.

Also, you're not going to find the Track II anywhere on the app-to-HSM side. And you'll be hard-pressed to find it on any app log as well. If it's there, the application is in violation of all Visa security standards.

[yinka]

Andy, please can you help me out with this- the base derivation key identifier, is it supposed to be the index to BDK on the HSM or on the PIN PAD? I will appreciate your prompt comments as this is confusing me on the implementation of DUKPT key Translation.

Thanks

[FIkri]

Im working on Thales RG7000. For the executions of CI it responded with CJ20. I have no idea what kind of respond code is that ? Thanks

[Andy Orrock]

Hi Fikri –

The 20 on the CI/CJ is due to a bad PIN block. The Thales doc is spotty at best…it doesn’t list all the possible codes in the places it should. Still, error usage is consistent across commands and the ‘20’ is defined elsewhere in the Host Command manual as a PIN Block Error.

Can you send me a trace so I can review it?

I don’t have a method to construct DUKPT-enabled PIN blocks. [You asked this elsewhere.] Like you, my perspective is the Host side and reliant on my store systems partners to do the needful on the terminal side to do proper injections and PIN block construction.

Regarding the card track…many of our customers have needed to devise Triple DES-enabled schemes to encrypt the PAN and track. Without this scheme in placed, they have failed their PCI Audit.

Andy

[Andy Orrock]

See related post:

http://www.andyorrock.com/2007/05/implementing_a_.html

That references the code required to implement:

CI/CJ:

Translate a PIN from *BDK Encryption to Interchange Key Encryption

That's SINGLE DES on the DUKPT side!!]

*** and ***

G0/G1:

Translate a PIN from *BDK Encryption to Interchange Key Encryption (Triple-DES
DUKPT)

Andy

[Rog]

Hi Andy...
I am trying to implement DUKPT using the example advised KSN format as specified in the ANSI DUKPT standard.

- 3 Bytes - Issuer Identification Number
- 1 Byte - Customer ID
- 1 Byte - Group ID
- 19 Bit Device ID
- 21 Bit Transaction Counter

This of course only makes the construction of the KSN descriptor even more confusing.

In the ANSII document we have a KSN of...

FFFF9876543210EFF800

So if we break this down we have..
FFFF98 --> 3 Bytes - Issuer Identification Number
76 --> 1 Byte - Customer ID
54 --> 1 Byte - Group ID
3210E00001 --> 19 Bit Device ID AND 21 Bit Transaction Counter

So how the hell does that map to the wonderful Thales KSN descriptor? Clearly it does not.

The base derivation key identifier length I assume must be '08' as it can not be '10' as it exceeds the limit of '9'. But then we have the 'Group ID' that has length of '02' left over and we can not set the 'sub-key identifier key length' to anything other than '00'. All that confusion before we even move on to the 'device identifier length'.

I have to wonder if Thales HSMs can actually support the ANSI Example.

Any comments or words of advice on cracking this secret Thales code?

Rog

[Rog]

BTW... the KSN descriptor of 080007 works with the test data from the ANSI documentation.

But that would imply that the device identifier includes the 'Group ID' which is not the case, so in practice I still have my doubts.

So, as I asked before... do you have any insight on this on this?

[Andy Orrock]

Hi Rog -

Thanks for questions.

Take a look at what Wikipedia has to say here:

http://en.wikipedia.org/wiki/Derived_unique_key_per_transaction

Read the part on "Practical Matters (KSN scheme". Specifically, this sentence addresses your question:

It should be noted that this notational scheme is not strictly accurate, because the transaction counter is 21 bits, which is not an even multiple of 4 (the number of bits in a hex digit). Consequently, the transaction counter actually consumes one bit of the field that is the TRSM ID (in this example that means that the TRSM ID field can accommodate 2(5*4-1) devices, instead of 2(5*4), or about half a million).

-- Andy

[Andy Orrock]

Rog passes along the following additional information - info received directly from Thales. Good clarifications here about restrictions that make the 21 bit thing work...

-----------

The KSN is comprised of three parts, the KSI (Key Set Identifier), DID (Device ID eg Ser. No) and a 21 bit counter.

KSI - Used to identify the BDK (Base Derivation Key) 5 Numeric Characters

DID - Should be unique to each POS Device. Last character must be even (0 2 4 6 8 A C E). The reason is that the high order digit of the 21 bit counter will overlay the low order bit of the DID and will always be 0.

Counter - A 21 bit value. The initial value is all nulls for the Initial PIN Encrypting Key (IPEK). After injection, the counter is incremented by 1. The algorithm for transactions will insure that only 10 consecutive 1 bits are set in the counter. This decreases the over 2 million possible keys that could be used to 1,048,575. The POS Device should cease operation when all keys have been expended

The combination of KSI+DID is restricted to a maximum of 15 hex characters. The counter is 5 hex characters plus 1 bit. The minimum KSN must be 12 Hex including the counter.

The Command reference is the CI command, to translate a PIN Block from encryption under a BDK (session key) to encryption under a Zone PIN Key (ZPK), needs some explanation. The 'KSN descriptor field' defines the number of hex character in the following field less the counter (last five digits in the KSN). That is it defines the hex characters that comprise the KSI and DID only. For a 20 (hex) digit KSN, the KSN descriptor could be A05, 906 or any other combination that produces 15 when the first and last digits are added. The 0 in the middle is for expansion.
--------------

NOTE: The example provided by Thales here for Rog describes the mechanics of a 20-position KSN. The main body of my post discusses mechanics of a 16-position KSN.

-- Andy

[Randy Wicks]

I am specifically looking for information on what type of information and what APIs I should write in order to perform the following:

1. Receive DKUPT encrypted string from PIN pad device
2. Encrypt via triple DES to send via OpenSSL for authorization and later settlement
3. Create keys? The ansi standard is extremely vague, and would prefer some rather straight forward information on exactly what I need to do.

I am new to financial software coding, but have done a lot of work in security infrastructure using Linux, which really does not apply here. :/

[Dhanya]

could you explain the concept of a Dynamic Key Exchange?

[Andy]

I discuss DKE here:

http://www.andyorrock.com/2007/04/dynamic_key_exc.html

[John]

Hi, could you please explain how in the (ANSI-X9.24-2004) doc, how to do the 3-DES enc. with the derived key to get the actual encrypted PIN block?

I believe its called "Triple-DEA Encrypt". The doc's explanation seems simple but I don seem to be getting it right.

According to the doc all my other key's and clear block is ok, but my 3DEA Encryption function.

Also, the code I'm working on is just an test app, any help would be appreciated.

Using jpos in java

Thanks

John