The PAKE interface does not work easily with the Mbed TLS driver design

[athoelke]

This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.

The suggested interface cannot be implemented in an opaque driver.

Opaque drivers are selected based on the key attributes provided. For a multi-part operation the driver is selected by the first function called. For PAKE this is psa_pake_setup(). However, no key is passed to this function. The only key involved is passed to the psa_pake_set_password_key() function which is called later and cannot be used for driver selection because the driver cannot be changed during a multi-part operation.

Unfortunately, the problem is not easy to solve. A change in the interface of the psa_pake_setup() function would work fine in most cases:

psa_status_t psa_pake_setup(
    psa_pake_operation_t *operation,
    const psa_pake_cipher_suite_t *cipher_suite,
    psa_key_id_t password,
    const uint8_t *user_id, size_t user_id_len,
    const uint8_t *peer_id, size_t peer_id_len,
    psa_pake_role_t role);

role, user_id, and peer_id are included because they are often needed to interpret the password value.

However, for some protocols the password hash cannot be calculated before some data is exchanged. For example, in a variant of SRP-6 the client first sends its public key to the server, the server then responds with the password salt and its own public key. The client therefore needs to calculate the public key before it receives the salt needed to calculate the password hash.

This issue is worth considering as part of the addition of support for SPAKE2+ to the PAKE API. See #73

[athoelke]

@gilles-peskine-arm responded:

This kind of multi-stage operation is hard to adapt to drivers. For key derivation, which has a similar problem, Mbed TLS is bundling all the inputs before choosing a driver. But as you note PAKE has the additional twist that it might require communication and accelerated operations before the secret key is known.

If the values are bundled in the driver interface but not in the outer interface, buffering of all provided values is needed in the core. Buffering the values in the core needs a potentially unbounded amount of memory which makes it difficult or impossible to make a memory efficient implementation. Using the same bundling on the outer interface would solve this.

It is not clear if an API change will resolve this, as some specific protocols make this problem difficult.

[athoelke]

For both KDF and PAKE, the secret input is provided as a key. An implementation is permitted to access a key parameter later in the operation, whereas buffer inputs must be fully consumed when the function returns.

Does this provide enough flexibility for the problematic variant of SRP to be workable with the suggested change to the PAKE setup? - i.e. the implementation stashes the key [material] during the setup call, and then hashes it later after the server salt is received and input to the operation. Or is it necessary for the application to do the password hashing, and provide the result to the PAKE operation as the password key?

[athoelke]

I am wondering if a simpler change is to just merge psa_pake_set_password_key() with psa_pake_setup(), so we have just:

psa_status_t psa_pake_setup(
    psa_pake_operation_t *operation,
    const psa_pake_cipher_suite_t *cipher_suite,
    psa_key_id_t password);

... which mimics the majority of other multi-part operations, that take the algorithm and key as part of setup, but other data later. Although it might not be possible to process the key data without the role and user/peer identities in some algorithms, it is not a problem to hold onto the key/key-material for the duration of the operation.

This would keep the role and user/peer identity API as is, so the implementation is likely to need to buffer these inputs for the majority of algorithms - but it would now only be buffered within the driver implementation, rather than in a dispatching 'core' layer of the implementation.

This reduces the complexity of the psa_pake_setup() function, and in particular eliminates the risk of a parameter mis-ordering being undetectable by the compiler (which is present in the originally suggested all-in-one setup function). It also enables the optional use of roles and identities without needing to define input values for their absence.

[oberon-sk]

We appreciate to work towards similar APIs in PSA Crypto API and Driver API.
Merging psa_pake_set_password_key() with psa_pake_setup() works fine for EC-JPAKE and SRP. However, for SPAKE2+, the role is required to process the key. Until the role is known, an unlimited buffer size for the key is required in the driver.

We see two variants to solve this for SPAKE2+:

1. Add the role parameter to psa_pake_setup() as well.
2. Define distinct algorithm ids for SPAKE2+ and SRP server and client roles and remove the role parameter completely.

We would favor the second.

(Please note that the key buffering problem is unsolved for key derivation too.)

[athoelke]

Merging psa_pake_set_password_key() with psa_pake_setup() works fine for EC-JPAKE and SRP. However, for SPAKE2+, the role is required to process the key. Until the role is known, an unlimited buffer size for the key is required in the driver.

@oberon-sk : Is this still the case with the Driver implementation when the key for setting up a SPAKE2+ PAKE operation would be an asymmetric key-pair or public-key? The application will have to use PBKDF2() (or some other KDF) to construct the SPAKE2+ key from a password, or import the SPAKE2+ public-key from received data, prior to setting up the PAKE operation.

[oberon-sk]

Agreed, using special key types for SPAKE2+ Prover and Verifier input keys as mentioned in #73 would solve the problem.

[athoelke]

Agreed, using special key types for SPAKE2+ Prover and Verifier input keys as mentioned in #73 would solve the problem.

Thanks, yes that is the plan.