RFC: Add HKDF Key Derivation to the PKCS11 TA

[Hussainity]

Hi all,

The OP-TEE PKCS#11 TA currently supports a small set of C_DeriveKey mechanisms: CKM_ECDH1_DERIVE and CKM_AES_{ECB,CBC}_ENCRYPT_DATA. HKDF (RFC 5869) is missing, even though:

• HKDF is a standard KDF for many modern protocols
• OP-TEE already implements HKDF in libutee as a GlobalPlatform extension (TEE_ALG_HKDF, TEE_ATTR_HKDF_{SALT,INFO}, plus the
  older per-hash TEE_ALG_HKDF__DERIVE_KEY family). The crypto is there; only the PKCS#11 surface is missing.
• PKCS#11 v3.0 standardized CKM_HKDF_DERIVE, CKM_HKDF_DATA, and CKM_HKDF_KEY_GEN with CK_HKDF_PARAMS.

Proposal

Add the standard PKCS#11 v3.0 HKDF surface to the PKCS#11 TA:

1. Mechanisms in ta/pkcs11/include/pkcs11_ta.h:
   - PKCS11_CKM_HKDF_DERIVE (0x402)
   - PKCS11_CKM_HKDF_DATA (0x403)
   - PKCS11_CKM_HKDF_KEY_GEN(0x401)
2. Parameters: serialize CK_HKDF_PARAMS (extract/expand flags, PRF hash, salt source — DATA/KEY/NULL, info) over the existing TA params-blob format.
3. Wiring: route PKCS11_FUNCTION_DERIVE for these mechanisms through a new derive_key_hkdf() in processing.c, backed by TEE_ALG_HKDF from libutee. Validate base-key type (CKK_GENERIC_SECRET / CKK_HKDF) and CKA_DERIVE.
4. Token capabilities / mechanism info: advertise the mechanisms with CKF_DERIVE in token_capabilities.c.
5. Tests: extend the optee_test xtest PKCS#11 suite with RFC 5869 test vectors (extract-only, expand-only, and combined; salt-as-key vs salt-as-data).

Open questions for upstream

1. Scope — all three mechanisms, or just CKM_HKDF_DERIVE? CKM_HKDF_DERIVE covers the protocol-KDF use case on its own. CKM_HKDF_DATA (output as raw data, not a key object) and CKM_HKDF_KEY_GEN (generate an HKDF base key) round out the v3.0 surface but aren't strictly required for the motivating use cases. Happy to land just CKM_HKDF_DERIVE first if that's acceptable.
2. Preferred mechanism numbering — adopt the v3.0 standard values (0x401–0x403) directly, as done for other v3.0-era mechanisms?
3. Should CKK_HKDF be added as a distinct key type, or is folding HKDF base keys onto CKK_GENERIC_SECRET (current practice for HMAC keys here) acceptable?
4. Any objection to depending on the OP-TEE TEE_ALG_HKDF extension rather than implementing HKDF inside the TA from the per-hash TEE_ALG_HKDF__DERIVE_KEY primitives?

If there's interest, I'll work on and submit the PRs.

[Hussainity]

Please note that I also have a parallel RFC for SoftHSM here: softhsm/SoftHSMv2#878

[jenswikl]

Hi, thanks for reaching out.
Your proposal looks good to me.

1: It's OK to start with only CKM_HKDF_DERIVE.

2: https://github.com/oasis-tcs/pkcs11/blob/48fa09240cc64ec1cd4c559b6af6642a2cdd13ae/published/3-00/pkcs11t.h#L1114
defines CKM_HKDF_DERIVE to 0x0000402aUL, so we should probably use that for PKCS11_CKM_HKDF_DERIVE.

3: I don't know PKCS#11 well enough to provide guidance on CKK_HKDF versus CKK_GENERIC_SECRET, but the latter sounds easier.

4: Please use TEE_ALG_HKDF, that's the GP standard.

@etienne-lms do you have any comments?

[Hussainity]

Awesome, glad to see the alignment, will have something for review in a week or so.

[Hussainity]

@jenswikl Would appreciate your thoughts and any corrections to my observations:

I tried TEE_ALG_HKDF first and there are some concrete blockers that pushed me off it.

1. It only does combined extract+expand.

core/tee/tee_svc_cryp.c always runs both phases inside tee_cryp_hkdf() with no attribute to skip either one. PKCS11's CK_HKDF_PARAMS has independent bExtract / bExpand booleans, so two of the three valid combinations aren't reachable through TEE_ALG_HKDF without extending the GP-extension surface in OP-TEE OS. If we want all three modes, either we extend TEE_ALG_HKDF upstream, or we use HMAC primitives for the modes it can't reach and TEE_ALG_HKDF for the one it can... which is messier than picking one path.

2. It's effectively unused in-tree.

No caller in optee_os or optee_test invokes TEE_ALG_HKDF (the existing HKDF xtest in regression_8000 uses the per-hash TEE_ALG_HKDF_*_DERIVE_KEY IDs). Building PKCS11 on a path that's never been exercised end to end made it the first real consumer.

3. Wiring it up surfaced (what appear to be) two bugs in OP-TEE OS:

• TEE_ALG_GET_KEY_TYPE(TEE_ALG_HKDF, false) returns 0xA00000C0, which isn't a registered key type.
• get_hkdf_params() defaulted hash_id to TEE_ALG_SHA256 (full algorithm form), but tee_cryp_hkdf() consumes it via TEE_ALG_HASH_ALGO() which expects the 4-bit "main hash" form. The mismatch makes crypto_mac_alloc_ctx fail with TEE_ERROR_NOT_SUPPORTED. The consolidated TEE_ALG_HKDF doesn't actually work on this branch right now afaik. Happy to send the one-line fix as a separate patch.

[jenswikl]

1: I assume it doesn't matter if you use TEE_ALG_HKDF or TEE_ALG_HKDF_*_DERIVE_KEY. The implementation looks simple enough that implementing it with HMAC primitives should be feasible. @jforissier, what do you think?

2: That's unfortunate, but something we'd like to have fixed.

3: Patches are welcome. :-)

[Hussainity]

OPTEE OS PR has been opened here: #7837