Add tests for key import-export and key import followed by public-key
export when the output buffer is too small. Add these tests for the
following curves:
* p256 as an example of a Weierstrass curve
* Curve25519
* Curve448
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This testcase calls psa_export_public_key() on an FFDH key with an
output buffer that is too small. Since the size is calculated based on
the required key size but not checked against the available buffer size,
we overflow the buffer.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
With e.g. `CLOCK_BOOTTIME`, it's plausible that less than 1 second has
passed since the boot reference time.
Only assert that the returned time is nonzero (because all-bits-zero is
highly implausible as an actual clock value, but likely indicates that the
intended value was not copied out correctly).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
MinGW uses a legacy printf by default which doesn't support the `z` modifier
for `size_t`. Skip these test cases on MinGW.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In particular, test `"%zu"` for `size_t` and `"%lld"` for `long long`, which
older Windows runtimes do not support, but which Mbed TLS uses.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The goal isn't to do any functional testing, but to have a simple diagnostic
if some Unix platform function isn't available, and to have a record of
success in the outcome file.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In `test_suite_debug`, test `mbedtls_debug_snprintf()`, which uses
`mbedtls_vsnprintf()` like `mbedtls_debug_print_msg()`. Do this instead of
testing `mbedtls_snprintf()`, which might be subtly different (older
Windows runtimes had slightly different behavior for vsnprintf() vs
snprintf(); TF-PSA-Crypto might pick up a different function if the
platform configuration is different in TF-PSA-Crypto and Mbed TLS).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is not only convenient, but now necessary, because if the content of
the generated files changes due to changes in Python files in the framework,
`all.sh check_generated_files` will fail in the framework CI.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Improve DTLS proxy 3d tests with OpenSSL and
GnuTLS servers. Have a better control of which
message is fragmented and verify it is the
case.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Improve DTLS reassembly tests with OpenSSL
and GnuTLS server. Check that some messages
have been reassembled.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
We are about to have full support for TLS 1.2
CH reassembly on server side. The equivalent
positive test would be a duplicate of one of
the tests generated by generate_tls_handshake_tests.py.
Thus just removing the negative test.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This is meant to test a bug found on:
- Little endian platforms other than x86 or ARM (these have specific
optimizations available);
- GCC versions from 10 to 14.2 (below and above are fine);
- Optimization level "-O3" (lower levels are fine).
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
The generated unit tests have the input parameters in large stack
buffers and therefore ASan doesn't notice under or overflows in them.
Copy the input parameter into a locally allocated buffer to trigger ASan
if something goes wrong.
Signed-off-by: Janos Follath <janos.follath@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>
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>
