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 98a4029d5169e8f18f3a0c2864794000c9641876)
Signed-off-by: Minos Galanakis <minos.galanakis@arm.com>
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>
The combination of the multi-byte loop with the single byte loop
confuses GCC 14.3's array bounds checker. When the loop size is
constant, check to see if it is a multiple of the multi-byte size and
bail early. As this will be evaluated at compile time, there should be
no run-time cost.
This change uses the __builtin_constant_p compile-time operation. To
check if that is supported, the change uses the existing
MBEDTLS_HAS_BUILTIN macro. That macro was defined later in
library/common.h than is needed for this change, so it was moved up to
join some other macros that looked similar.
Signed-off-by: Keith Packard <keithp@keithp.com>
Partial backport of "Update all except "Asymmetric cryptography" for
TF-PSA-Crypto", including only clarifications and the extra information
about migrating to `MBEDTLS_PSA_CRYPTO_CONFIG` that are also relevant in
3.6.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The program uses atoi() unconditionally, so it should include stdlib.h
unconditionally. Previously this happened to be indirectly included by
some other header (via pk.h via ssl.h) but we should not rely on that.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
