Hi, We have some feedback to the proposed PSA PAKE interface, see below. Regards Beat
Reference: "PSA Cryptography API 1.1 PAKE Extension" 10/02/2022. https://armmbed.github.io/mbed-crypto/1.1_PAKE_Extension.0-bet.0/psa_crypto_...
Issue 1 It is impossible to derive multiple keys from the common secret. The suggested PAKE interface passes the resulting raw common secret directly to a key derivation operation. This is good to avoid direct usage of the secret but it makes it impossible to derive more than one key from the secret because the key derivation operation can only be used once. Deriving multiple keys is mandatory for some protocols for instance to get a session key for the rest of the pairing phase and in addition a long term key to establish further sessions. It would be better to return the raw secret as a key which can only be used as input to a key derivation operation. This would be easy to use and allows for multiple derived keys. The same problem exists for the key agreement interface which is also directly coupled to a key derivation operation. Again there exists protocols where multiple keys are needed, for instance one for outgoing and one for incoming messages. In the case of key agreement, the psa_raw_key_agreement() function can often be used as a workaround but returning a derivation only key instead of the coupling to a key derivation operation would be a more general and cleaner solution.
Issue 2 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 has to be 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. In a variant of SRP-6 for instance 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.
Issue 3 Missing support for 'out of band' setup calculations. The suggested PAKE interface deliberately does not contain functions for setup calculation not directly involved in the PAKE protocol. This might be a good idea to keep things simple and easy to use. However, there must be a way to do calculations like the password hash somehow. Otherwise the whole PAKE interface turns out to be useless in many situations. In most PAKE protocols a password hash or password verifier is not just a hash but needs field or group calculations related to the main PAKE operation. To allow an implementation of all parts of a PAKE key exchange without relying on a second crypto library, it is mandatory to provide these functions somehow in PSA, in special PAKE functions or in another interface.
Issue 4 PAKE SIZE macros need more arguments. The PAKE input and output size macro are defined with the argument list (alg, primitive, output_step). However, some input/output values depend on the digest size of the selected hash algorithm. This holds for instance for a SPAKE2+ confirmation key or the SRP client/server proofs. It is therefore mandatory to include either the hash algorithm or the hash size in the argument list of the two macros.