PAKE Driver Interface requires dynamic memory allocation.

[oberon-sk]

Suggested enhancement

Driver implementations should not require dynamic memory allocation.

Justification

The mismatch between the PAKE PSA API and the PAKE Driver Interface requires a PSA implementation which copies all data provided to the psa_pake_set_xxx functions to a temporary location in the operation object. There is no way around that without major changes to the PSA API. The PSA implementation in Mbed TLS 3.4, however, copies each of the values twice, once in the psa_pake_set_xxx functions and again in the psa_crypto_driver_pake_get_xxx callback functions. Is there a specific reason to do these seemingly redundant copies?

In addition, the memory space used to store the values after the second copy is allocated in the driver. It is very undesirable to require dynamic memory allocation in a driver because drivers should be universal and there should be no need to make assumptions about the execution environment of a driver.

According to the PSA Crypto API specification, chapter 6.4, the API is designed to allow an implementation to avoid dynamic memory allocation altogether. This is no longer feasible if memory allocation is needed in the core and in some drivers because the drivers are developed independently and it is not realistic to expect each driver developer to provide an alternate variant with conservative (i.e., static) memory management.

[gilles-peskine-arm]

For the key derivation and PAKE driver interfaces, we've hit some tension between several constraints:

• The application doesn't always pass the input in the order that the driver would want. (I'm not sure if it's a problem with PAKE. It is a problem with key derivation, and if I had realized it earlier I would have changed the application interface.)
• The core doesn't always know which inputs the driver can process immediately, and which ones need to be stored until other inputs are available or until more output is requested. There has to be a handover point where the ownership of the input data is transferred from the core to the driver (which might be never if the core memorizes the input until the end of the operation, but that's a waste of memory if the driver doesn't need it, e.g. for an input that the driver immediately feeds to a hash function and doesn't otherwise need).
• Drivers cannot store pointers to buffers stored by the core, because the addresses of buffers can change between API entry points if the core is running under a managed runtime (e.g. Rust).
• We want to make interfaces as simple as possible. This is especially true around memory management, since the slightest mistake with memory management tends to lead to exploitable bugs. This is usually easiest when each piece of memory has a clear owner at any time. Unfortunately, this tends to lead to copying to transfer ownership between different code bases.

I'm not sure we've done the best we could within those constraints. Suggestions welcome.

[oberon-sk]

We are working on a proposal.

[oberon-sk]

Thanks for listing all the constraints. We agree that changing the application interface would be best. Since this seems out of the question, how about the following trade-off:

1. Store all parameters from the psa_pake_set_xxx calls as it is done in the current solution.
2. Pass this group of parameters to driver_pake_setup in one go, i.e. extend driver_pake_setup's parameter list accordingly. Callbacks are not required.

In most cases, the driver can pre-process input values instead of storing them in full, for instance because the password hash can be stored instead of the password. Avoiding dynamic memory in the drivers will become much more practical.

BTW: A similar approach would be possible for key derivation, if the driver interface defined a driver_key_derivation_setup-function for each algorithm. This would work for opaque and transparent drivers. Again, in most cases, the driver can pre-process input values instead of storing them in full and avoiding dynamic memory in the drivers will become much more practical.

[oberon-sk]

Regarding SPAKE2+, the same approach would work. Support for the optional additional context information would also be possible by adding a PSA_PAKE_STEP_CONTEXT and to enforce calling psa_pake_input(op, PSA_PAKE_STEP_CONTEXT, ctx, ctx_len); immediately after the psa_pake_set_xxx(); block.