HSM issue

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HSM issue

DC-28

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Mark Salter-5

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Mark Salter-5

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Mark Salter-5

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

AAO
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: HSM issue

AAO
In reply to this post by DC-28

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

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of DC
Sent: Friday, May 15, 2009 5:34 AM
To: jPOS Users
Subject: Re: HSM issue


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



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28
In reply to this post by Mark Salter-5

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28
In reply to this post by AAO

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




> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
>
> Behalf Of DC
> Sent: Friday, May 15, 2009 5:34 AM
> To: jPOS Users
> Subject: Re: HSM issue
>
> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Mark Salter-5
In reply to this post by DC-28

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

AAO
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: HSM issue

AAO
In reply to this post by DC-28

Great.  Let us know how your research turns out.

Andy

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of DC
Sent: Sunday, May 17, 2009 2:41 AM
To: jPOS Users
Subject: Re: HSM issue


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




> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
>
> Behalf Of DC
> Sent: Friday, May 15, 2009 5:34 AM
> To: jPOS Users
> Subject: Re: HSM issue
>
> 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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28

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.

On May 18, 5:27 am, "Andy Orrock" <[hidden email]> wrote:

> Great.  Let us know how your research turns out.
>
> Andy
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
>
> Behalf Of DC
> Sent: Sunday, May 17, 2009 2:41 AM
> To: jPOS Users
> Subject: Re: HSM issue
>
> > 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!
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On
>
> > Behalf Of DC
> > Sent: Friday, May 15, 2009 5:34 AM
> > To: jPOS Users
> > Subject: Re: HSM issue
>
> > 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

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

On May 22, 2009, at 6:57 PM, DC <[hidden email]> wrote:

>
> 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.
>
> On May 18, 5:27 am, "Andy Orrock" <[hidden email]> wrote:
>> Great.  Let us know how your research turns out.
>>
>> Andy
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:jpos-
>> [hidden email]] On
>>
>> Behalf Of DC
>> Sent: Sunday, May 17, 2009 2:41 AM
>> To: jPOS Users
>> Subject: Re: HSM issue
>>
>>> 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!
>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]
>>> ] On
>>
>>> Behalf Of DC
>>> Sent: Friday, May 15, 2009 5:34 AM
>>> To: jPOS Users
>>> Subject: Re: HSM issue
>>
>>> 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
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Alejandro Revilla
In reply to this post by DC-28

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



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Mark Salter-5

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Alejandro Revilla

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


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

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

On Wed, May 27, 2009 at 4:14 PM, DC <[hidden email]> wrote:

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




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

Victor Salaman-Medina
In reply to this post by DC-28
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

On Wed, May 27, 2009 at 6:44 AM, DC <[hidden email]> wrote:

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




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HSM issue

DC-28

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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

12
Loading...