(The PSA cryptoprocessor driver interface currently omits key derivation because it is complicated. This is a proposal to support one specific use case, which may be extended or reworked in the future.)

Use case:

• The secret input is an opaque key. (Not a transparent key, a direct buffer, or the result of a key agreement.)
• The other inputs are input buffers. (Not key objects.)
• The output is a single key (not a byte buffer or multiple keys).

The rationale for focusing on the opaque case is that it's the most useful case, as it allows a non-exportable key to be derived from a non-exportable key without exposing any intermediate key material outside the secure element. Acceleration is not particularly useful in the transparent case (except for key agreement, which will be treated separately) for the algorithms that are currently defined in the PSA specification (as of version 1.0.0) since those algorithms are simple constructs over a hash (or HMAC).

Driver interface

typedef struct {
    const uint8_t *data;
    size_t length;
    psa_key_derivation_input_step_t step;
} psa_key_derivation_input_buffer_t;

psa_status_t acme_opaque_key_derivation_oneshot(
    psa_algorithm_t alg,
    const psa_key_attributes_t *secret_key_attributes, const uint8_t *secret_key_buffer, size_t secret_key_size,
    const psa_key_derivation_input_buffer_t *input_array, size_t input_count,
    const psa_key_attributes_t *output_key_attributes, uint8_t *output_key_buffer, size_t output_key_size, size_t *output_key_length
);

Semantics:

• The algorithm is guaranteed to be a key derivation algorithm. For now it will not have a key agreement component, but this may be added later.
• The secret_key_xxx parameters describe the opaque key which is the secret input.
• The type of the secret key is guaranteed to be PSA_KEY_TYPE_DERIVE (for now: if support for key agreement is added, if the algorithm has a key agreement component, the key will be guaranteed to be a valid type for this key agreement).
• The other inputs are in the input_array array.
• input_count is the number of elements in the input_array array.
• If the core supports the algorithm, the elements of input_array are guaranteed to be valid input for the given algorithm.
  • No invalid input step.
  • No SECRET input. (This is guaranteed even for algorithms that the core does not support.)
  • No repeated input steps, unless an algorithm allows a repeated step (none currently does).
  • All steps that are supported by the algorithm are guaranteed to be present, even ones that are optional in the API. For example, for HKDF, the core will supply an empty INFO if the application doesn't pass one.
  • The steps are passed in a canonical order. For example, for HKDF, SALT will be before INFO.
• The output_xxx parameters describe the derived key that the driver must calculate.

Implementation hints

• struct psa_key_derivation_s: add a union field to support just storing references to the input (note that input buffers must be copied). Add a one-bit field to say that this field is in use.
• psa_key_derivation_input_key: if the key is opaque, use the “just storing references” part of the union and don't call psa_key_derivation_input_internal. Note: SECRET might not be the first input step, e.g. INFO might already be present for HKDF. It may be necessary to rearrange the KDF structures accordingly.
• psa_key_derivation_output_key: in the opaque case, call the driver, then set the operation capacity to 0.
• psa_key_derivation_output_bytes: call the opaque case of psa_key_derivation_output_key with a temporary exportable key, then export the key.