Previously we were looping in one case but not even checking the other.
Let's check both cases and error out immediately. The error path should
never be taken in pratice anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In library source files, the order of things should be:
1. Define macros that affect the behavior of system headers, such as
`_POSIX_C_SOURCE` and `_GNU_SOURCE`.
2. Include the library's common header: `common.h`.
It takes care of many things, including defining the library
configuration, granting access to private fields in structures, and
activating platform-specific hacks.
3. Possibly a few header inclusions and macro definitions.
4. Guard everything else by `#if defined(MBEDTLS_XXX_C)` or some such.
Enforce this order in files that previously did things they shouldn't have
before including `common.h`. To locate the potentially
problematic files:
```
grep -m1 '^#' library/*.c | grep -v -F common.h
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
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>
