ANSI X9.42 and X9.63 KDFs for KAS-FFC and KAS-EEC

[jvdsn]

What type of change is being proposed? New capabilities for KAS-FFC and KAS-ECC.

Details on suggestion Please consider adding ANSI X9.42 and X9.63 as integrated KDF functions to the KAS-FFC and KAS-ECC schemes. Currently, these schemes as defined by ACVP only support the SP 800-56Cr2 key derivation functions. However, per SP 800-135r1, there are many other key derivation functions that are also approved. In particular, ANSI X9.42 and X9.63 KDF are approved when used in the context of an ANSI X9.42 resp. X9.63 key agreement scheme (which actually map to the schemes listed in SP 800-56Ar3).

Additional information This addition could increase the test coverage of several cryptographic modules that implement the Diffie-Hellman or EC Diffie-Hellman primitives.

OpenSSL OpenSSL 3 implements the dhEphem and Ephemeral Unified schemes. Currently, ACVP testing of these API functions focuses on the "SSC" variant, that is, without KDF computation (FIPS 140-3 IG D.F, Scenario 2, Pah 1). However, these functions also accept a "kdf-type" parameter which would, at first sight, allow the vendor to claim the more powerful, "full" KAS variant.

Unfortunately, looking at the source code (the MAN page is very unclear in this regard) reveals that only the ANSI X9.42 (DH) and X9.63 (ECDH) KDFs are supported. Moreover, the following comment implies that there are currently no plans from OpenSSL to change this:

 * This type is only really used to handle some legacy related functionality.
 * If you need to use other KDF's (such as SSKDF) just use PROV_DH_KDF_NONE
 * here and then create and run a KDF after the key is derived.

ACVP doesn't support the ANSI X9.42 and X9.63 KDFs, thus the vendor is stuck with KAS-FFC-SSC and KAS-ECC-SSC.

NSS

Network Security Services (NSS) implements a PKCS#11 token as defined in the standard. This standard contains many different DH and ECDH "mechanisms", but in particular NSS implements the CKM_ECDH1_COFACTOR_DERIVE algorithm. This corresponds to the Ephemeral Unified scheme in SP 800-56Ar3. Again, NSS accepts a kdf parameter. Looking at the source code, we see that NSS automatically applies the X9.63 KDF if this parameter is not null. No other KDFs are currently supported.

Once more, NSS is stuck with the SSC variant for KAS-ECC. In fact, even though ACVP supports testing of standalone ANS X9.63 KDFs, this particular implementation cannot be ACVP tested at all. It is not accessible standalone through a "mechanism", as defined in the PKCS#11 standard. As a result, if ACVP would support testing the X9.63 KDF as part of the KAS-ECC scheme, two NSS algorithms could be tested in one go.

[livebe01]

Thank you for submitting this request. We're looking into it and will get back to you with an answer.

[livebe01]

Hi @jvdsn, I spoke with @celic to get the back story on the state of the KAS Sp800-56Ar3 testing. There was quite a bit of discussion around including the SP 800-135r1 KDFs in the KAS Sp800-56Ar3 testing, but this was something that the NIST Cryptographic Technologies group did not want and the CAVP followed their wishes. As Chris explained it to me, the 135 KDFs are only allowed within their specific protocols and those protocols do not necessarily match up exactly with KAS Sp800-56Ar3.

[jvdsn]

Hi, @livebe01. That's unfortunate. I can understand not wanting to add all SP 800-135r1 KDFs, but I am specifically looking for the ANSI X9.42 and X9.63 KDFs. Those KDFs aren't used by a protocol per se, but rather a specific Diffie-Hellman scheme, which is protocol-agnostic. As far as I can tell, the schemes described in X9.42 and X9.63 actually map to the schemes in SP 800-56Ar3.

[livebe01]

Thanks @jvdsn. What you're saying makes sense. From a testing perspective, if X9.42 and X9.63 do conform to SP 800-56Ar3, then end-to-end KAS tests would be the stronger/better tests. That said, I don't expect this is something we'll get to.

Best,

Ben