Support secure keys with token specific token_specific_ecdh_pkcs_derive() function

[ifranzki]

As of today, function ckm_ecdh_pkcs_derive() in mech_ec.c extracts the private key (CKA_VALUE) from the base key, and passes it to the token specific token_specific_ecdh_pkcs_derive() function.

This works fine for clear key tokens, such as the Soft token, but will not work for secure key tokens, since CKA_VALUE does not contain the opaque secure key blob required for secure key derivation.

Pass the base key as such to token_specific_ecdh_pkcs_derive() and let the token extract the required key information.

This is required to support CKM_ECDH1_DERIVE for the CCA token.

Note: The EP11 token does support CKM_ECDH1_DERIVE, but does not use common code, so it can support CKM_ECDH1_DERIVE without a change.

[ifranzki]

Function ecdh_pkcs_derive() is already not prepared for secure key tokens. It calls ckm_ecdh_pkcs_derive() and expects the derived secret Z to be passed back in clear. It the applies a KDF to it (if desired) to create the final secret key. For secure key tokens, the token must perform not only the derivation but also the KDF itself, it can't return the derived secret Z in clear.

We might need a new/separate token specific ECDH derive function that includes the KDF handling, e.g. t_ecdh_pkcs_derive_kdf. This function would get the mechanism parameter as well as the to-be-derived key object. Function ecdh_pkcs_derive() should first check if the token supplied the t_ecdh_pkcs_derive_kdf function. If so then call it and skip further handling. In case the token does not specify the t_ecdh_pkcs_derive_kdf function, continue with the existing handling that calls ckm_ecdh_pkcs_derive() and applies the KDF afterwards.

A secure key token would need to supply t_ecdh_pkcs_derive_kdf to be able to perform a secure key derivation.

[jschmidb]

What about dh_pkcs_derive? This is currently only supported by the softtoken, which is no real secure token. But from a pkcs11 point of view it's the same ...

[ifranzki]

Correct. That would need the same changes to allow a secure key token to support DH derive.

The only thing is, that CCA as far as I know does not support DH, only ECDH. And for EP11 we already support both, but it does not go through common code. Therefore, if we want to support ECDH for CCA, we need this change in the ECDH path, while for the DH path it would be nice to have but we currently would have no exploiter.