Was only used in one place so far, but will be used in
rsa_gen_rand_with_inverse()'s upcoming CRT-based implementation.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Will gain a new implementation using the CRT, so we want to hide the
upcoming complexity in a dedicated function.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Previous tests were backported from tf-psa-crypto and they work fine there.
However the library implementation is not the same between 3.6 and
tf-psa-crypto: in 3.6 we only prevent loading of persistent keys if their
ID is within the volatile range, but the built-in one is still allowed.
Therefore this commit fix expected return values for the 3.6 branch
when built-in keys are accessed.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
When testing what happens with when accessing a key ID in the built-in or
volatile range and a file exists in storage, we were skipping the test case
when the key existed. When the volatile or built-in key exists, the
expectations on the test case are wrong, but the test case is still useful:
we should ensure that the existence of the file doesn't somehow prevent
access to the built-in or volatile key. So, instead of skipping, change the
test assertions on the fly to ensure that we are accessing the existing key.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Test what happens when the application tries to access a key and the storage
contains something invalid: either a corrupted file, or a key ID that's
outside the standard range for persistent keys.
Coverage of APIs in this commit:
* `psa_get_key_attributes()` (generally as a proxy for any key access);
* `psa_export_key()` (minor, but does provide some coverage of what happens
if only the key material is corrupted);
* `psa_destroy_key()`, which hopefully should work even for a corrupted file.
Coverage of key IDs in this commit:
* Key IDs in various ranges: user (i.e. the normal range for persistent
keys), builtin, volatile, reserved file ID, none of the above.
* Includes coverage for nonzero owner ID.
No coverage of corrupted files in this commit.
Assert the behavior that I think is the right thing. Subsequent commits will
reconcile the library behavior with the code as needed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add some assertions on the various ranges of key identifiers to ensure that
they're disjoint and they comply with documented guarantees.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Take also MAC's key types into account when computing the size of the
buffer to store key material in static key slot configuration.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
