Question: Rationale for not exposing HUK-derived keys through PKCS#11 mechanisms

[bashadarsi]

Hi Everyone,

I am exploring support for vendor-defined PKCS#11 mechanisms based on a device Hardware Unique Key (HUK).

While working on this, I noticed that OP-TEE already relies on the HUK for secure storage key derivation and encryption. However, I could not
find any support for creating PKCS#11 key objects derived from the HUK and using them for standard cryptographic operations such as encryption,
decryption, signing, or verification.

Before proposing any design or upstream contribution, I would like to understand whether this omission is intentional and if there are
security, architectural, or portability concerns behind it.

Some questions I had are:

• Is the HUK intentionally restricted to internal OP-TEE services such as secure storage?
• Are there security concerns with allowing PKCS#11 applications to use HUK-derived keys for cryptographic operations?
• Are there portability concerns due to platform-specific HUK implementations?
• Has a HUK-backed PKCS#11 key mechanism been discussed previously?

My motivation is to enable device-specific keys derived from the HUK to be used through standard PKCS#11 operations while ensuring that the actual key material is never exposed, imported, exported, or stored outside the secure environment.

I would appreciate any background on previous discussions or design decisions around this area.

Thanks.

[jenswikl]

There's an API provided for TAs to derive a TA unique key from the HUK (PTA_SYSTEM_DERIVE_TA_UNIQUE_KEY in butee/include/pta_system.h).
I don't know about the PKCS#11 part though.

[bashadarsi]

I did see the PTA_SYSTEM_DERIVE_TA_UNIQUE_KEY API and the HUK-based derivation support available for TAs.
However, from what I found, this is currently used by internal TAs such as the Trusted Keys TA for seal/unseal use cases.

My interest is specifically in the PKCS#11 TA. I could not find a mechanism to generate a PKCS#11 key object derived from the HUK and use it through standard PKCS#11 operations.
I'm trying to understand whether this is an intentional design choice or functionality that has not been implemented yet.