Driver is now responsible for creating its own copy of the password in the setup function.
After calling pake setup driver entry point core frees memory for password.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
- Add `alg` and `computation_stage` to `psa_pake_operation_s`.
Now when logic is moved to core information about `alg` is required.
`computation_stage` is a structure that provides a union of computation stages for pake algorithms.
- Move the jpake operation logic from driver to core. This requires changing driver entry points for `psa_pake_output`/`psa_pake_input` functions and adding a `computation_stage` parameter. I'm not sure if this solution is correct. Now the driver can check the current computation stage and perform some action. For jpake drivers `step` parameter is now not used, but I think it needs to stay as it might be needed for other pake algorithms.
- Removed test that seems to be redundant as we can't be sure that operation is aborted after failure.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
In this way, in case of error, it is not possible to continue using
the same psa_pake_operation_t without reinitializing it.
This should make the PSA pake's behavior closer to what expected by
the specification
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Additionally use psa_get_and_lock_key_slot_with_policy() to obtain key.
This requires making this function public. This will have to be solved while adding driver dipatch for EC-JPAKE.
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
We're not strictly required to abort, but at least to leave the context
is an invalid state. For "late" functions like input() and output(),
calling abort() is the easiest way to do that. Do it systematically for
input() and output() by using a wrapper. psa_pake_get_implicit_key() was
already doing it. For "early" function, we can just leave the operation
in its current state which is already invalid.
Restore previous tests about that. Not adding systematic tests, though,
just test the two functions that are the most important, and more likely
to return errors.
Since we now abort in more cases, we need to make sure we don't
invalidate the operation that's going to be re-used later in the test.
For that reason, use a copy of the operation for calls to input() and
output() that are expected to return errors.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There was a check against the remaining size of the buffer, which used
to be correct, but was broken two commits ago when we started not just
copying the input but also adding to it.
Replace it with a check that the input length is not greater that what's
expected for this step. This guarantees we won't overflow the internal
buffer.
While at it, add an explicit cast to uint8_t when writing the length to
the buffer, so silence an MSVC warning. This cast is safe because we
checked that the length is no larger than 65 or 32 (depending on the
step), so in any case is fits in one byte.
This was found because some lengths had not been adjusted in the test
suite, and instead of failing cleanly, library code performed buffer
overflows. I'll fix the tests in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This macro is specific to the Mbed TLS implementation and not part of
the public API, so it shouldn't used the PSA_ namespace.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The format used by the mbedtls_ecjpake_xxx() APIs and that defined by
the PSA Crypto PAKE extension are quite different; the former is
tailored to the needs of TLS while the later is quite generic and plain.
Previously we only addressed some part of this impedance mismatch: the
different number of I/O rounds, but failed to address the part where the
legacy API adds some extras (length bytes, ECParameters) that shouldn't
be present in the PSA Crypto version. See comments in the code.
Add some length testing as well; would have caught the issue.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
