Re: [pkcs11] ECDH key derivation function

[Valerie Fenwick <valerie.fenwick@oracle.com>]

Hi Dieter

Of course, given that one of these standards is a private standard that costs 
money to look at, does make this more challenging. But I imagine there are 
enough people in this group that have access to the standard that we should be 
able to discuss this.

I ran this by some folks in my team that work on algorithm implementations, and 
this was the advice that came out of there:

 First, fix the CKD_SHA[224|256|384|512]_KDF description in
2.3.8 EC mechanism parameters, that is, change

" The key derivation function CKD_NULL produces a raw shared secret
value without applying any key derivation function whereas the key
derivation function CKD_SHA1_KDF, which is based on SHA-1, derives
keying data from the shared secret value as defined in ANSI X9.63."

to

" The key derivation function CKD_NULL produces a raw shared secret
value without applying any key derivation function whereas the key
derivation functions CKD_SHA[1|224|256|384|512]_KDF which are based on
SHA-[1|224|256|384|512]derive keying data from the shared secret value
as defined in ANSI X9.63." .

Second, discuss whether introducing the NIST SP800-56A version of the
these functions would be useful and if so, add those, too. E.g. adding
the functions CKD_SHA[1|224|256|384|512]_NIST_KDF.

Would you be able to discuss this further in our next TC meeting? If not, would 
someone else like to bring this issue up? It seems like something we should 
address in 2.41.

Valerie


On 6/9/2015 12:41 AM, Dieter Bong wrote:
> All,
>
> we encountered the following issue w.r.t key derivation functions for ECDH:
>
> ·NIST SP800-56A section 5.8.1.1 specifies the following for derivation of a key:
> Compute K(i) = H(counter || Z || OtherInfo)
>
> ·ANSI X9.63 in contrast specifies Ki = Hash(Z || Counter || [SharedInfo])
>
> ANSI and NIST thus specify different orders for concatenation of ‘Z’ and
> ‘counter’. Has this been discussed in the TC before?
>
> The PKCS#11 standard explicitly references ANSI X.63 when using CKD_SHA1_KDF for
> derivation of keying data; there is no such explicit reference for
> CKD_SHA[224|256|384|512]_KDF. Yet I would assume they are also meant to be
> implemented according to ANSI X9.63. Is this assumption correct?
>
> One of our customers wants to implement key derivation according to NIST
> SP800-56A using PKCS#11 mechanism CKM_ECDH1_DERIVE. Strictly following the
> PKCS#11 standard this would not be possible resp. require implementation of a
> Vendor Defined Mechanism?
>
> Any thoughts or suggestion from your side?
>
> Thanks,
>
> Dieter
>
> Viele Grüße / With kind Regards
>
> Dieter Bong
>
> Product Manager HSM
>
> **
>
> Utimaco IS GmbH
>
> Germanusstr. 4
>
> DE-52080 Aachen
>
> Germany
>
> Fon: +49 241 1696 - 233
>
> Mobil: +49 173 9080381
>
> _www.utimaco.com <http://www.utimaco.com/>_
>
>
> --------------------------------------------------------------------------------
>
> Utimaco IS GmbH
>
> Seat: Aachen – Registergericht Aachen HRB 18922
> VAT ID No.: DE 815 496 496
> Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
>
> Wichtiger Hinweis:
> Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse oder sonstige vertrauliche
> Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist
> Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der
> E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie
> die E-Mail. Der Absender hat alle erdenklichen Vorsichtsmaßnahmen getroffen,
> dass die Anlagen dieser E-Mail frei von Computerviren o. Ä. sind. Gleichwohl
> schließen wir die Haftung für jeden Schaden aus, der durch Computerviren o. Ä.
> verursacht wurde, soweit wir nicht vorsätzlich oder grob fahrlässig gehandelt
> haben. Wir raten Ihnen, dass Sie in jedem Fall Ihre eigene Virenprüfung
> vornehmen, bevor Sie die Anlagen öffnen. Vielen Dank.
>
> Important Notice:
> The information contained in this email message may be confidential information.
> If you are not the intended recipient, any use, interference with, disclosure or
> copying of this material is unauthorised and prohibited. Please inform us
> immediately and destroy the email. We have taken every reasonable precaution to
> ensure that any attachment to this email has been swept for viruses. However, we
> cannot accept liability for any damage sustained as a result of software viruses
> and would advise that you carry out your own virus checks before opening any
> attachment. Thank you for your cooperation.

--
NOTE: Using voice recognition software, forgive typos/grammar mistakes!
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.