HSM issue

[DC]

Dear All,

I have some issue with HSM, After refering to my HSM vendor, I need a
second opinion.

Sorry. this is not related to jPOS, but I think a lot of people here
have experiences with HSM.

If I may ask,

I'm using safeNet's software HSM simulator. In my case, It's as good
as the real hardware HSM. The other party is using HP Atalla HSM. I
know that if for thales (as I have read some pages on Andy Orrock' s
blog), I will need to enable the ANSI X9.17 mode to send data to the
Atalla HSM.

Accordig to my vendor, SafeNet does not require such configuration.
Can anyone confirm this fact from my vendor?

Thanks a lot,
DC.

[Mark Salter]

DC wrote:

> If I may ask,
>
> I'm using safeNet's software HSM simulator. In my case, It's as good
> as the real hardware HSM.

Good for testing 8).

> The other party is using HP Atalla HSM. I
> know that if for thales (as I have read some pages on Andy Orrock' s
> blog), I will need to enable the ANSI X9.17 mode to send data to the
> Atalla HSM.

You you going to be moving to use the Atalla HSM *instead* of your
software HSM; and you are trying to set your code in preparation for the
migration?

>
> Accordig to my vendor, SafeNet does not require such configuration.
> Can anyone confirm this fact from my vendor?

I would think you could confirm this by exchanging some relevant test
data and trying out the decode/recode/validation on it?

Do you think your software HSM vendor gave you the wrong answer, or was
it just not the one you were expecting as you have already had problems?

--
Mark

[DC]

Mark, thanks for replying

> You you going to be moving to use the Atalla HSM *instead* of your
> software HSM; and you are trying to set your code in preparation for the
> migration?

No, we plan to use safenet's hsm. right now we are connecting to a
party that is using atalla.

> I would think you could confirm this by exchanging some relevant test
> data and trying out the decode/recode/validation on it?

Yeah, we're working on this too... but they are having hard time doing
their part, they are still on it..

> Do you think your software HSM vendor gave you the wrong answer, or was
> it just not the one you were expecting as you have already had problems?

Yeah we're having trouble. Our encrypted PIN block is wrong according
to Atalla side.


So it would be great if someone have experience with Atalla or SafeNet
or both :) and can shed the light on this issue :D

[Mark Salter]

DC wrote:

>> You you going to be moving to use the Atalla HSM *instead* of your
>> software HSM; and you are trying to set your code in preparation for the
>> migration?
> No, we plan to use safenet's hsm. right now we are connecting to a
> party that is using atalla.

This feels wrong, but I will have to assume you are satisfying PCI
compliance - although I'm sorry to say I have my doubts that you can.

>> Do you think your software HSM vendor gave you the wrong answer, or was
>> it just not the one you were expecting as you have already had problems?
> Yeah we're having trouble. Our encrypted PIN block is wrong according
> to Atalla side.

You have checked the keys in use (including their parity if relevant)?
How about going the other way, get Atalla to build a PIN block you
decrypt - perhaps outside of any HSM?
I'm sure you are using test keys, so if you can share some data and
keys, perhaps we could take a look.

>
>
> So it would be great if someone have experience with Atalla or SafeNet
> or both :) and can shed the light on this issue :D

Oh indeed, but I fear this is unlikely.

I think we have asked before; can you share your solutions/company name
at all?

--
Mark

[Mark Salter]

Mark Salter wrote:
> DC wrote:
>
>>> You you going to be moving to use the Atalla HSM *instead* of your
>>> software HSM; and you are trying to set your code in preparation for the
>>> migration?
>> No, we plan to use safenet's hsm. right now we are connecting to a
>> party that is using atalla.
> This feels wrong, but I will have to assume you are satisfying PCI
> compliance - although I'm sorry to say I have my doubts that you can.

Unless (of course) you mean you will use a SafeNet *hardware* HSM in
your production environment and are using a SafeNet HSM simulator for
testing?

--
Mark

[Andy Orrock]

Where you say "According to my vendor, SafeNet does not require such
configuration." I can't speak authoritatively about the Safenet, but it may
be that they're telling you that X9.17 is the default.

What about the issues of the Atalla Variant? Have you specified that? Did
the other side give you information on the Variant to be used?

For example, here's what the Thales documentation has to say about
communicating with an Atalla:

"The HSM can be used in systems where there may be Atalla security equipment
at other network nodes. This is achieved by the inclusion of an Atalla
variant in those commands that translate a key from/to encryption under a
ZMK. This has the effect of modifying the ZMK before it is used to
decrypt/encrypt in accordance with the method used by the Atalla equipment.
The HSM can support 1 or 2 digit Atalla variants."

Andy Orrock

[DC]

> Unless (of course) you mean you will use a SafeNet *hardware* HSM in
> your production environment and are using a SafeNet HSM simulator for
> testing?

Yes, that's the plan.

> You have checked the keys in use (including their parity if relevant)?

I have not look into parity issue. Ok i will do this.

> How about going the other way, get Atalla to build a PIN block you
> decrypt - perhaps outside of any HSM?

Yup, this is also another thing I'm planning to do.

> I'm sure you are using test keys, so if you can share some data and
> keys, perhaps we could take a look.

Ok, here goes

The component of the KEK
First Left: 2222222222222222
First Right: 4444444444444444
Second Left: 6666666666666666
Second Right: 8888888888888888
Check Digit: D8EBBD

we have verified that the check digit is same for both HSMs. Just that
the Atalla HSM can only show the first 4.

Encryption using DESede/ECB/NoPadding

The keys are double length

here's a sample simulation using safenet's HSM (soft HSM)

PPK raw in hex (session key): 11111111222222223333333344444444
Decrypted (now is PPK clean): B5FCDFA20F537677780EABC78940C602
Encrypted (now is PPK raw again): 11111111222222223333333344444444
(proves the decrypt process is OK)

PIN: 111111
ANSI 0 PIN Block: 061111036FFFFFDE
DESede PIN block, encrypted using PPK clean: 34CB8BCAFB6C0B22

But as it turns out, every time we attempt 0200, we got 05.

So running out of factors to blame, The Atalla side mentioned for
Thales, they will have to use the ANSI X9.17 setting before they can
get 00.

I'm sorry I can't reveal the company name here but the solutions we
are working on is
to process with a national ATM network switch. like when you need to
withdraw money from bank B's ATM while you are actually holding ATM
card from bank A.
We will use safeNet's HSM. The national switch is using Atalla.

Thanks,
DC.

[DC]

> Where you say "According to my vendor, SafeNet does not require such
> configuration."  I can't speak authoritatively about the Safenet, but it may
> be that they're telling you that X9.17 is the default.

Yes, I meant to say, the vendor said: its already supported

> What about the issues of the Atalla Variant?  Have you specified that? Did
> the other side give you information on the Variant to be used?
>
> For example, here's what the Thales documentation has to say about
> communicating with an Atalla:

> "The HSM can be used in systems where there may be Atalla security equipment
> at other network nodes. This is achieved by the inclusion of an Atalla
> variant in those commands that translate a key from/to encryption under a
> ZMK. This has the effect of modifying the ZMK before it is used to
> decrypt/encrypt in accordance with the method used by the Atalla equipment.
> The HSM can support 1 or 2 digit Atalla variants."

Atalla variant eh, I will check on this, Thanks!

[Mark Salter]

DC wrote:
>> Unless (of course) you mean you will use a SafeNet *hardware* HSM in
>> your production environment and are using a SafeNet HSM simulator for
>> testing?
> Yes, that's the plan.

Phew, good.

>> I'm sure you are using test keys, so if you can share some data and
>> keys, perhaps we could take a look.
> Ok, here goes
>
> The component of the KEK
> First Left: 2222222222222222
> First Right: 4444444444444444
> Second Left: 6666666666666666
> Second Right: 8888888888888888
> Check Digit: D8EBBD

I don't get this KCV, encrypting 16 bytes of x'00' bytes of zeros under
this key gives me 5611AC13D98BDF6F5611AC13D98BDF6F.
Are we using the same approach to generate our Key Check Value?

>
> we have verified that the check digit is same for both HSMs. Just that
> the Atalla HSM can only show the first 4.

So my approach must be different, hmmmm.

> here's a sample simulation using safenet's HSM (soft HSM)
>
> PPK raw in hex (session key): 11111111222222223333333344444444

This looks like a clear test key to me, but if you are sure...

> Decrypted (now is PPK clean): B5FCDFA20F537677780EABC78940C602

So you decrypted 11111111222222223333333344444444 using key
22222222444444446666666688888888 and got B5FCDFA20F537677780EABC78940C602?

I can't replicate this decryption...

...I get A56A0AA97C78D9B42946F8D9783BAD44

> Encrypted (now is PPK raw again): 11111111222222223333333344444444
> (proves the decrypt process is OK)

It certainly proves you have a symmetrical algorithm 8).

>
> PIN: 111111
> ANSI 0 PIN Block: 061111036FFFFFDE

Although our KCV doesn't match, I continued on...

So working back the XOR this gives a card number containing:-

nnn001290000021n

Is this what you have?

> DESede PIN block, encrypted using PPK clean: 34CB8BCAFB6C0B22

I do get this value using a PPK of B5FCDFA20F537677780EABC78940C602; but
we do know (I think) that this is bad - as far as the Issuer system
(Atalla end) is concerned anyway.

Could you try the exchange - or check - using a clear PPK of
11111111222222223333333344444444 please?

This gives me a encrypted PIN block of E6A7EE81E0A4221B.

Has your Issuer end given you the encrypted PIN block value they are
expecting - is this (E6A7EE81E0A4221B) it perhaps?

It seems impossible that our PIN Blocks can match but our decrypt of PPK
under KEY don't seem to?

>
> But as it turns out, every time we attempt 0200, we got 05.

'05' doesn't sound very 'invalid PIN' or 'System Malfunction' like, but
I guess they told you what the problem was (HSM function failed
indicating data error)?

>
> So running out of factors to blame, The Atalla side mentioned for
> Thales, they will have to use the ANSI X9.17 setting before they can
> get 00.

So they can get a correct validation by changing their call to their HSM
for your provided PIN Block?

Is any other system translating the PIN block before it hits the Atalla
system?

> I'm sorry I can't reveal the company name here but the solutions we
> are working on is
> to process with a national ATM network switch. like when you need to
> withdraw money from bank B's ATM while you are actually holding ATM
> card from bank A.

So you are doing (or will be) PIN translation.

> We will use safeNet's HSM. The national switch is using Atalla.

I was interested in the product/company *if* you were using software
HSMs in production as you are not I am less worried.

In a commercial concern though you must check the jPOS license you are
using. Someone in this setup very likely need to be purchasing a
commercial license.

--
Mark

[Andy Orrock]

Great. Let us know how your research turns out.

Andy

[DC]

Dear all,

we're still finding out but most likely (i think), as andy pointed
out, its because of variant.

Guys, any idea what is X'08' in hex ?

Thanks,
DC.

[Chhil]

X'08 itselft is telling you it's hex 8.

Hexa and decimal are same 0 to 9.
Decimal 10 is hex A
11 = x'B
12 = x'C
So on and so forth till 15.

Decimal 15 is F

-Chhil

[Alejandro Revilla]

>
> Guys, any idea what is X'08' in hex ?
>

That one blows my mind. I'll check Wolfram Alpha.

[Mark Salter]

Alejandro Revilla wrote:
>> Guys, any idea what is X'08' in hex ?
>>
> That one blows my mind. I'll check Wolfram Alpha.

8)

The case of a bad question...

... I think DC meant what does a value of x'08' mean as an Atalla
Variant. Time to RTFM 8).

--
Mark

[Alejandro Revilla]

>
> ... I think DC meant what does a value of x'08' mean as an Atalla
> Variant. Time to RTFM 8).
>

Good point.

[DC]

Thanks all for the infos.

What happened actually is that, now I need to know what is the exact
value for 'atalla variant 1'. Atalla's manual does not show the value.
The party that is using Atalla also yet to come back with the answer.

my vendor gave me a manual that has the following table

The variant bytes used for the Atalla variant scheme are listed in the
following table.

KIS/KIR variant | Variant Byte | Used to Protect
1 | X'08' | PPK
2 | X'10' | DPK
3 | X'18' | MPK


the X'08', X'10', X'18' is meaningless to me.

Normally, (i think), HSM has the value precompiled. The HSM user just
need to use correct commands and maybe just have to set Attala Variant
= 1 in order to integrate with the Atalla HSM. Our HSM, on the other
hand, does not have such function or value precompiled. So we need to
do it manually, hence we must know what's the value of variant 1
exactly.

So guys, Humbly, by any chance, would you know the exact hex value of
the variants especially variant 1, Please let me know.

Regards,
DC.

P/S: If only they teach about HSMs at school instead of High School
Musicles...

[chhil]

I believe its the variant value followed by all 0's to match the length of the key.

You can look at the .NET code here thalessim.codeplex.com/ to see how it is used by HSMS.

-chhil

[Victor Salaman]

I would assume that what your document means to say is:

X'08' = 0800000000000000 on single length key, and 08000000000000000800000000000000 on a double length key.
X'10' = 1000000000000000 on single length key, and 10000000000000001000000000000000 on a double length key.
X'18' = 1800000000000000 on single length key, and 18000000000000001800000000000000 on a double length key.

So your HSM would take the clear value of your base key and XOR the variant, and that value would be used to protect your PPK,DPK, or MPK as shown in your table. Now the question is wether your HSM will support using custom variant values (I'd assume that the Mark-II firmware would supports this).

/V

[DC]

Guys,


Thanks for all the replies..

Now, for Atalla, we found out that there is a command - command 1A
which will generate working keys for non-AKB HSMs.

I think we can live with this for now.. Just need to find a way to
automate the process in the future.
(Now someone will manually run the command and sends a new PPK for us)

Regards,
DC.

[DC]

Hi Guys,

some update on this,

actually the atalla was not on akb. but it has the variant mechanism
turned ON.

so, to work with this, we just need to XOR the KEK with the variant
and take the XORed value to decrypt session key and move on with the
process


Regards,
DC.

[paulac]

Dear All,

Hi I am deveolping a credit card authorization app, using a SafeNet HSM, but
our client didn't buy the API, so we are programming from scratch the
protocol.
We are using TCP/IP, setting the 6 byte header that communication's Manual
says, but each time we try (even a simple HSM_STATUS) we receive no response
plus, the socket is closed.
Do you have any idea about this?

Thanks in advance!

Paula

--
View this message in context: http://www.nabble.com/HSM-issue-tp23555753p24524030.html
Sent from the jPOS - Users mailing list archive at Nabble.com.

[Mark Salter]

To end the day nicely...

This question has *nothing* to do with the thread you have added it to.
Having a 'useful' subject text does not mean you should hijack it; do
use a new message thread for each *new* question.

paulac wrote:
>
> Hi I am deveolping a credit card authorization app, using a SafeNet HSM, but
> our client didn't buy the API, so we are programming from scratch the
> protocol.

Boy they are cheap eh.

Was it more expensive then paying you to sort if for them?

Odd that.

> We are using TCP/IP, setting the 6 byte header that communication's Manual
> says, but each time we try (even a simple HSM_STATUS) we receive no response
> plus, the socket is closed.

Have you get the right message length format and encoding?

If the HSM sees rubbish arriving, I would expect it to close the channel.

> Do you have any idea about this?

Check the communications manual for message structure - length and
format. Then check you are using a matching channel.

Check your license conformity too!

--
Mark

[Victor Salaman]

Hi:

Why not ask for support from SafeNet? They have really good support, try it.

/V

[David Bergert]

The client didn't buy a support agreement either ?

David Bergert, CISSP, CISA, CPISM/A
www.paymentsystemsblog.com

[jay fegade]

which software safenet HSM simulatorare you are using

where it is available?

[Victor Salaman]

Thank you for reviving an 8 year old thread!!

:)

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/49a46222-b684-4a1e-824a-42cb5ac43a28%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.