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>
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>
The storage test generator doesn't support JPAKE at this time. So write a
test case manually.
The key is not exercised, since `psa_exercise_key()` doesn't support PAKE at
this time. But at least we can use this test case to ensure that we know how
the key is represented in storage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
(cherry picked from commit 98a4029d51)
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
