Command JE/JF

May 3, 2011 at 2:05 PM

Hi,

I recently gave up trying to implement the JE/JF command pair (Translate a PIN from ZPK to LMK) in our in-house HSM simulator, because I couldn't figure out what the so-called 'PIN under LMK' value really was. It's obviously not just the PIN block encrypted the LMK, though.

Using a real Thales, this value turns out to be a 13 digit decimal value: here is part of the trace:

[Apr 21 13h06:41.078] - Thales RG7000 message received from  
[None       ans 008 M] : 'Message Header' = [00000000]
[None       an  002 M] : 'Response Code' = [JF]
[None       an  002 M] : 'Error Code' = [00]
[5..13      Hex 013 M] : 'PIN under LMK' = [7917367771782]

The Thales simulator seems to work fine with this command - I can do PIN changes, etc. - but the trace file reveals that the value of the 'PIN under LMK' is actually the PIN in the clear, preceded by a 0.

[None       ans 008 M] : 'Message Header' = [00000000]
[None       an  002 M] : 'Response Code' = [JF]
[None       an  002 M] : 'Error Code' = [00]
[5..13      Hex 013 M] : 'PIN under LMK' = [00008]
Any idea what is going on here, and how this value is really calculated? The Thales documentation doesn't provide much insight.

Coordinator
May 3, 2011 at 2:21 PM
Edited May 3, 2011 at 2:26 PM
kevinr_za wrote: It's obviously not just the PIN block encrypted the LMK, though.

No, it is not. I don't know how that is encrypted internally by Thales, either. Since you've been down that road, you fully understand my frustration with this problem.

Very early in the project I made a decision regarding PINs encrypted under LMK: I would not try to encrypt them. Basically all I wanted to do was be able to "encrypt" and "decrypt" a PIN under LMK so that it produces a persistent and consistent result.

In Thales simulator, when you see a PIN encrypted under LMK you know it's the original PIN preceded by a '0', just as you noticed. That means that you can generate a random PIN and retrieve the PIN under LMK value returned by the simulator, then feed that value to another command (let's say a PVV generation command) and you can expect that the simulator will know how to interpret the "encrypted" PIN.

So in essence, we're talking semantics here. The idea is to have a simulation that can produce consistent end-to-end results when used for testing. Not correct.

May 3, 2011 at 3:04 PM

Ah, that's kind of what I was beginning to suspect. And being able to see PIN in the clear would actually be quite useful for my purposes.

Thanks for a great tool, too.