TLS1.3: Understanding HKDF calls

[kshitizvars]

Hi @simo5 @Jakuje

In p11prov_exch_hkdf_derive API, we are calling EVP_KDF_derive (openssl API) to perform HKDF derive, shouldn't it be like in below screenshot:-

Correct if I am wrong here.

@sahilnxp

[simo5]

We need to rework it to look like p11prov_ecdh_derive() more or less

[kshitizvars]

So, control will reach to token after calling EVP_KDF_derive?

[simo5]

I am not sure the current code works as it should

[simo5]

but eventually we should be calling pkcs11_DeriveKey()

[simo5]

Ok sorry looking at this more carefully I now remember how odd the code is around key derivation in openssl.

The key exchange providers "wrap" kdf providers, so in thie case calling EVP_KDF_derive(hkdfctx->kdfctx, secret, outlen, NULL) should be correct as this will do nothing more than simply end up calling the KDF provider with a KDF context for HKDF.

[simo5]

Also the context is guaranteed to be the PKCS#11 provider KDF context, see how kdfctx->kdfctx
is initialized in p11prov_exch_hkdf_newctx()

[kshitizvars]

So when EVP_KDF_derive() is called, we first go to OpenSSL and then from there we again come into provider which calls the C_DeriveKey(), Is my understanding correct?
I am not able to understand from where Token C_DeriveKey() will be called in this case?

[simo5]

Yes EVP_KDF_derive is given a context explicitly taken with provider=pkcs11 as property, so the only provider that will be selected in pkcs11.
EVP_KDF_derive() -> p11prov_hkdf_derive() -> p11prov_derive_key() -> p11prov_DeriveKey()

[kshitizvars]

I understand the flow now, since we are in the provider only, why we need to call EVP_KDF_derive(), can't we just directly call p11prov_hkdf_derive() without calling EVP_KDF_derive()?

[simo5]

To avoid special casing, there is no real gain in multiplying paths

[kshitizvars]

Hi @simo5 @Jakuje

We have added CKM_HKDF_DERIVE mechanism in our token, but we don't see p11prov_exch_hkdf_derive getting called when working with TLS1.3. Is there any config or any other option that we need to enable for offloading HKDF operation to provider.

[simo5]

and HKDF is still not use ?

[simo5]

note that there is a test in the testsuite that explicitly tests HKDF and I see in the generated p11prov-debug.log that the token's HKDF is used, so I am not sure why it does not work in your case.

See tests/thkdf

[kshitizvars]

Yes, I have taken the reference from tests/thkdf, these tests are for standalone HKDF testing, it is working fine, I am also able to see logs in debug log, but while we run TLS1.3 connection, we don't see any HKDF functionality getting called, and it is probably because of missing TLS13-KDF.

[simo5]

indeed if the name is not present the pkcs11 provider will never be used

[simo5]

Filed #445 to follow up on this