« Handling Acquirer-side Reversals in a Payment Switch | Main | Testing DUKPT --> Triple DES PIN Translation »

Sunday, April 09, 2006

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

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.....

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]

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!

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).

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.

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."

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

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.

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.

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.

"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

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

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.

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

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

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

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

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

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?

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

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

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. :/

could you explain the concept of a Dynamic Key Exchange?

I discuss DKE here:

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

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

The comments to this entry are closed.

AddThis Social Bookmark Button

Resources

  • Alejandro's jPOS Project
    Faced with payment systems challenges? Start here to learn more about Alejandro Revilla's jPOS project.
  • Dave Bergert's Blog
    Insights from my OLS colleague, Dave Bergert, CISSP, CISA, CompTIA Security+, and former Visa-certified QSA.
  • Glenbrook's Blog List
    Glenbrook Partners has compiled "a current summary of the latest content from some of our favorite payments and banking blogs." Dave, Alejandro and I are on the list.
  • soliSYSTEMS
    My friend Roque Solis is our go-to guy for RFID, smart cards, chip cards, integrated circuit cards, HSMs, cryptographic accelerators and public-key cryptography.
  • Specs Online - AMEX
    American Express puts its acquirer specs online for public retrieval.
  • Specs Online - FDMS
    First Data Merchant Services puts its acquirer specs online for public retrieval.
    [NOTE: This repository is accessible only via IE; this link will not work with Firefox or other browsers.]

Documents

  • The PCI Split
    Depicts how we split an implementation into PCI and non-PCI halves.
  • The Virtuous Spiral
    A good payment system unleashes customer creativity. Does yours?
Blog Widget by LinkWithin

  • Your attention to detail is a great asset. Use it wisely.