Thanks to Eshya have sucessfully derived an AES token using DEVIV01. However this requires both parties to use a 'PARTYID' of the same value. However in my situation I don't want to use a 'PARTYID'. So for now I'm using PASSTHRU and then using CSNBSKI2 service to create the 01 AES token.

I noticed in HCR77C0 that there is a new keyword for CSNDEDH called DERIV02. And you don't have to specify a 'PARTYID'. IE you can specify length of zero. Could I use this instead to generate my AES key?

Thanks,

Rob

Hi Rob,

The difference between the DERIV01 and DERIV02 rules is mainly the key derivation function (KDF) that is used.
The DERIV01 rule uses the Concatenation KDF as specified in section 5.8 of NIST SP800-56A.
The DERIV02 rule uses ANSI-9.63-KDF as specified in section 5.6.3 of ANSI X9.63-2011.
ANSI-9.63-KDF has the shared data listed as optional, hence the allowed length of 0 for the party_identifier in the CSNDEDH verb.

Which rule you use may depend on who you are exchanging keys with.
What KDF does the other party support? If they use ANSI-9.63-KDF with no shared data then you can use the DERIV02 rule with no party_identifier.

The DERIV02 rule does, however, require the private_key_identifier to contain a key-derivation section, type X'23'. Described in table 486 here: http://publibfp.dhe.ibm.com/epubs/pdf/csf2c414.pdf.

- Mike

Hi Mike.

Thanks for the quick reply and clarification....  Currently were playing with a JavaScript implementation of ECDH. As well, a bouncy castle implementation of ECDH on windows.  I really don't know which ANSI standard they are using.

In either case they generate a clear secret key.  If I use PASSTHRU, I get the same derived secret key as the forementioned remote party's. So which ANSI  implementaion does PASSTHRU use to generate the secret key?

Thanks,

Rob

Hi Rob,

The PASSTHRU rule returns the shared secret value that is the output of the Elliptic Curve Diffie-Hellman (ECDH) primitive operation.
This is really just the x coordinate of a point on the curve. See "Standards for Efficient Cryptography
SEC 1: Elliptic Curve Cryptography" section 3.3.1 here: http://www.secg.org/sec1-v2.pdf for more details.

There is no KDF involved here.
On page 37 of the ICSF Application Programmer's Guide (http://publibfp.dhe.ibm.com/epubs/pdf/csf2c414.pdf) there is a brief discussion of this.
Here is the first part of that discussion:
"Obtaining the Raw "Z" value
To use a key agreement scheme that differs from the above [DERIV01], one may obtain the raw shared secret "Z" and skip the key derivation step.
The caller must then derive the final key material using a method of their choice."

The raw "Z" value is input to all of the KDFs. See section 3.6.1 of the SEC 1 document mentioned in the first paragraph for implementation
details of the ANSI-9.63-KDF.

The JavaScript and bouncy castle implementations you are using must just do the ECDH primitive operation.

-Mike

Thanks Mike.

Understood...

I guess I just wanted the "Z" material  to be imported and outputed as an 01 token and have this done in the HSM... However, this key will be single use and hence short lived. So this shouldn't be a problem.

I will continue with PASSTHRU and CSNBSKI2 to get my 01 token.

Thanks for all your help 

Rob

Rob, something you said worried me.  Are you saying you want to use the shared secret "Z" as a key?  If so, I need to point out that you are not supposed to do that.  Z is not a key.  It is a shared secret value that is to be used with a Key Derivation Function (KDF) to derive a key.  For example, the methods in X9.63 have a step like this at the end:

- Todd Arnold

Hey Todd. Thanks for the post..

Not sure why I cannot use the "Z" material as a key. In fact it works quite well. I'm able to decrypt data encrypted at the browser level quite nicely.

Initially I did this with PKCS11 using CSFDVK (to derive secret key, in fact the resulting object is just the raw Z)  and then CSFPSKD (secret key decrypt). This also works well and in fact was initially recommended by yourself in a call we had some time ago with Mr. Sweeney I believe.

BTW, you can pull the Z material right from the pkcs11 secret key object as it's not secure using CSFPGAV...

Rob

That's just the way the algorithms work - and the security is based partly on use of a KDF.  Here is a paragraph from the NIST standard that covers EC Diffie-Hellman (SP 800-56A) - it's very clear that Z is not to be used as a key, and that a KDF must be used.

So using the PKCS11 implementation is acceptable? What KDF do they use so that CSFPSKD and CSFPSKE can decrypt/encrypt data.

I get same result if I use the other method with PASSTHRU. I'm very confused....

Rob

You might find the discussion on this page interesting:  How random is the shared secret in the Diffie Hellman key agreement