Monthly Archives: August 2014

Thales Key Exchange Examples and Troubleshooting

Judging from the searches done to locate this blog, it’s clear many of us share the following opinion: although Thales (formerly RACAL) is a market leader with its 7000 and 8000 series of HSM devices, their documentation falls painfully short in two areas: there are NO COMMAND EXAMPLES (!!!) in the manuals (an appalling omission); and the troubleshooting assistance is also distressingly thin. As a result, we had to lean heavily on our local Thales distributor for guidance on how commands really get pieced together. And, man, is it ever esoteric….see my earlier posts regarding the ‘KSN Descriptor’ for evidence of that. Moreover, our distributor provided us with some outstanding troubleshooting support to get us through the all important FA/FB key exhange. So, I’ll post our experience here in hopes that others can benefit from it.

The FA/FB is the command exchange to “Translate a ZPK from ZMK to LMK Encryption.” We had this working internally with some simulated stuff, but once we tried this command ‘for real’ with our Debit/EBT gateway partner , we consistently received parity errors back from our Thales 8000 HSM (i.e., the FB returned with some result code != 0).

There are three possible issues / resolution paths to explore in these situations:

Your switching partner has employed an Atalla HSM and you’ve not taken it into account. When a Thales/RACAL HSM ‘talks’ to an Atalla, your box commands must specify an Atalla Variant.

Your switching partner didn’t specify a Key Scheme in its ZPK creation, and the default is X9.17 (‘X’). If you specify the RACAL Scheme (‘U’) in your ‘FA’ and the ZPK under ZMK provided to the box was created via the X9.17 scheme, you’ll get a parity error.

You created the ZMK cryptogram internally using one key scheme and now are trying to employ it in the FA command specifying (inadvertantly) the other variant scheme.

You want to try to resolve each of these in turn.

The “test solution” path for Item #1 is as follows…

Let’s assume your FA command is constructed like so:

FAU2D775BFD****************FABE0D7CU6C0FDE16D22FF2D95273E3741AF4E187

[NOTE: I’ve obscured the ZMK Cryptogram here for blogging purposes only. The actual value is a 32-position hexidecimal string.]

If you discover that the other side is using an Atalla, you need to specify an “Atalla Variant,” which you do by specifying a ‘1’ at the end of the ‘FA’ command string:

FAU2D775BFD****************FABE0D7CU6C0FDE16D22FF2D95273E3741AF4E1871

The “test solution” path for Item #2 is as follows…

We find some endpoint partners have no idea which Key Scheme (X9.17 or Racal Native) they employed to create their keys. So, you may have to experiment. This FA command string says that the ZMK and ZPK were created using the RACAL native scheme (‘U’):

FAU2D775BFD****************FABE0D7CU6C0FDE16D22FF2D95273E3741AF4E187

To specify that the ZPK was created using the X9.17 scheme, you’d do the following:

FAU2D775BFD****************FABE0D7CX6C0FDE16D22FF2D95273E3741AF4E187

The “test solution” path for Item #3 is as follows…

When you created your ZMK (probably during a key ceremony involving a reconstitution of key parts provided by your endpoint gateway), you specify (or otherwise let default) your ZMK Key Scheme. Again, this can be either the RACAL Native Scheme (‘U’) or X9.17 (‘X’). [I believe the default is X9.17.] For example, if you created the ZMK using the ‘X’ approach, and then submitted an ‘FA’ command that looks like this:

FAU2D775BFD****************FABE0D7CU6C0FDE16D22FF2D95273E3741AF4E187

…it’s gonna fail. You absolutely must maintain consistency from the creation of the ZMK cryptogram through its subsequent usage. So, the command would change to look like this:

FAX2D775BFD****************FABE0D7CU6C0FDE16D22FF2D95273E3741AF4E187

[NOTE: I’m not advocating ‘X’ over ‘U’ here…just showing you an example. In a recent concluded project, we assumed the incoming ZPK was of the RACAL native variety, but it arrived from the remote partner as created under the X9.17 scheme. Thing is, the gateway team had no idea they had done that and could not articulate the difference. So, be prepared to experiment with every permutation of what I’ve described herein before ‘unlocking’ the solution.]

Advertisement

Testing DUKPT

As an acquirer, you can validate that your PIN translation command is working correctly even if you haven’t yet established connectivity to your Debit/EBT endpoint (or if you’ve established connectivity but don’t yet have your test key parts).

Typically when we’re pressed into this situation, this is what we do if we’re working with the Key-Up II HSM from Ian Donnelly Systems (‘IDS’):

For simplicity’s sake, we use a weak double-length key part.

We enter it as a single part (again, at this point, we want to keep things simple).
Typically, we use 0123456789ABCDEFFEDCBA9876543210.

We take the Cryptogram obtained out of that exercise and we use that as our Key Exchange Key (“KEK”) input.

Now, in my reading of the Thales manuals, performing this exercise with the Thales device is quite a bit more complicated.

[I’ll use Thales language here so we’re all on the same page…]

GOAL: What you need to test PIN translation is a ZPK encrypted under your LMK. [Refer to my previous post for details on the CI/CJ PIN transalation request/response.]

Note specifically where I describe “PIN Length” on the CJ command output I say:

“Although this field is not used to build the 0200 message formatted for the processor gateway, a value like ‘04’ or ‘05’ here is a pretty good indication that the translation occurred successfully.”

So, we can validate the workability of this command without a working endpoint or ‘real’ key parts from them, but – in order to do so – we need to construct a valid ZPK under LMK cryptogram. This value will allow you to create a completely valid CI command, assuming that:

You’ve got one or more valid BDK cryptograms loaded in your encryption database.

You can generate PIN-enabled Debit purchases from a test point-of-sale location.

You have addressibility from your test server to the Thales.

STEPS: My reading of the Thales manual is that you’ll need to execute the following steps (this is sort of ugly – numbers refer to specific sections in the Operations and Installation manual):

6.1 to create at least two 32-positions ZMK components (or, alternatively, 6.3 if you want to use components of your own chosing).

6.4 to get a 32-position ZMK under LMK.

7.1 to generate random ZPK (uses 6.4 ZMK under LMK output as input here) and encrypt under ZMK and LMK. The goal is that second cryptogram that comes back, the one oddly named “ZPK encrypted for bank” in the Thales document. That’s the ZPK under the LMK that you need for your tests.

Obtaining this information should allow you to validate the critical part of your encryption infrastructure prior to getting connectivity to your Debit/EBT gateway partner. Of course, once formal inter-system testing is established you still need to transport the encrypted PIN block in an 0200 request to your endpoint. But doing the exercise I describe above here first will allow you to eliminate any self-doubt you may have about your internal PIN translation activities prior to getting an external party involved in the testing