KDF Driver interface proposal

[oberon-sk]

Description

• Use same KDF driver interface functions as high level PSA Certified Crypto API but add key-attribute parameter to driver’s setup function.
• When KDF PSA API is called, buffer all arguments in the core until main key is passed.
• Then call KDF driver's setup function with main key’s attributes and pass all the arguments we buffered in a predefined order.
• Pass main key to KDF driver.
• Pass any further arguments directly to KDF driver without buffering.

Advantages

• Only few arguments must be buffered, and dynamic memory can be avoided. (We estimate a fixed buffer of 300 bytes would be sufficient.)
• Opaque drivers can be selected based on main key’s location passed in setup function.
• We can avoid get_data calls for buffered arguments.
• Future-proof, if future KDF extensions avoid sending size-unbounded arguments before main key.

Corresponding KDF Driver Wrapper interface

psa_status_t psa_driver_wrapper_key_derivation_setup(
    psa_key_derivation_operation_t *operation,
    const psa_key_attributes_t *key_attributes,
    psa_algorithm_t alg);
 
psa_status_t psa_driver_wrapper_key_derivation_set_capacity(
    psa_key_derivation_operation_t *operation,
    size_t capacity);
 
psa_status_t psa_driver_wrapper_key_derivation_input_bytes(
    psa_key_derivation_operation_t *operation,
    psa_key_derivation_step_t step,
    const uint8_t *data, size_t data_length);
 
psa_status_t psa_driver_wrapper_key_derivation_input_key(
   psa_key_derivation_operation_t *operation,
    psa_key_derivation_step_t step,
    const psa_key_attributes_t *key_attributes,
    const uint8_t *key, size_t key_length);
   
psa_status_t psa_driver_wrapper_key_derivation_input_integer(
    psa_key_derivation_operation_t *operation,
    psa_key_derivation_step_t step,
    uint64_t value);
 
psa_status_t psa_driver_wrapper_key_derivation_output_bytes(
    psa_key_derivation_operation_t *operation,
    uint8_t *output, size_t output_length);
 
psa_status_t psa_driver_wrapper_key_derivation_output_key(
    psa_key_derivation_operation_t *operation,
    const psa_key_attributes_t *key_attributes,
    uint8_t *key, size_t key_size, size_t *key_length);
 
psa_status_t psa_driver_wrapper_key_derivation_abort(
    psa_key_derivation_operation_t *operation);

The driver interface would be analog.

[athoelke]

Thank you very much - we will plan to work these changes into the specification.

[oberon-sk]

Further thoughts regarding the efficient implementation of KDF in core and driver:

The new KDF driver interface needs to buffer the following values:

• INPUT_SALT (HKDF, WPA3, PBKDF2)
• INPUT_INFO (SRP, HKDF)
• INPUT_SEED (TLS12)

So HKDF is the only algorithm where two values need to be stored (INPUT_SALT & INPUT_INFO). It would be easy to avoid buffering INPUT_INFO because it is usually provided after the INPUT_SECRET. Unfortunately, the specification of PSA_ALG_HKDF allows to provide it "at any time".

Changing the specification to enforce providing INPUT_INFO after the INPUT_SECRET would be a small, seamless change:

• The related algorithm PSA_ALG_HKDF_EXPAND already enforces INPUT_INFO after INPUT_SECRET.
• All client code in mbedTLS and TF-M use INPUT_INFO after INPUT_SECRET.
• All available samples and tutorials about HKDF show INPUT_INFO after INPUT_SECRET.
      for instance:
  • PSA Crypto API: 3.3.3. Example of the symmetric cryptography API
  • Mbed TLS doc: Deriving a new key from an existing key
  • TF-PSA-Crypto: Transitioning to the PSA API: HKDF