Parsing a key and importing it into PSA may result in a policy that
specifies an algorithm that is not included in the build. This happens if
the key type is supported, but not the algorithm, e.g. in a build with
MBEDTLS_ECP_C but not MBEDTLS_ECDSA_C.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In some configurations (e.g. ECDH but no ECDSA or RSA), the PK module is
useful but cannot perform any signatures. Then modern GCC complains:
```
../source/tests/suites/test_suite_pk.function: In function ‘test_pk_sign_verify’:
../source/tests/suites/test_suite_pk.function:1136:12: error: array subscript 0 is outside array bounds of ‘unsigned char[0]’ [-Werror=array-bounds]
../source/tests/suites/test_suite_pk.function:1094:19: note: while referencing sig’
…
```
This fixes test-ref-configs.pl with a modern GCC (specifically with
config-thread.h).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Implement mbedtls_pk_import_into_psa for all PK types except RSA_ALT.
This covers importing a key pair, importing a public key and importing
the public part of a key pair.
Test mbedtls_pk_import_into_psa() with the output of
mbedtls_pk_get_psa_attributes(). Also unit-test mbedtls_pk_import_into_psa()
on its own to get extra coverage, mostly for negative cases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Make it clearer where the magic number chosen for entropy_len actually
comes from, and why we chose this value.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Normally, if an elliptic curve is enabled in the legacy API then it's also
enabled in the PSA API. In particular, if the legacy API has at least one
curve then that curve also works with PSA. There is an exception with
secp224k1 which PSA does not support. In a build with secp224k1 as the only
legacy curve, MBEDTLS_PK_HAVE_ECC_KEYS is enabled (because you can use the
curve through PK) but PSA does not support any elliptic curve, so we can't
run PK-PSA bridge tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The only real contraint on the raw buffer is that it is large
enough to contain 2 coordinates. Larger buffers are therefore
allowed and the extra data will simply be ignored.
Note = trying to impose a strict sizing on the raw buffer causes
several failures in test suites. This suggests that it is
quite common to use larger buffer to store raw signatures.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Use PSA_VENDOR_ECC_MAX_CURVE_BITS instead of a specific curve since
what we care about is only bit-size not the curve itself.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
These values are not mathematically valid as signature, but as
for what it concerns with ECDSA conversion functions, 0 values
in DER format should be translated to 0 values in raw format.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Allow the function to support DER buffers than what it is nominally
required by the provided coordinates. In other words let's ignore
padding zeros in the raw number.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Temporary workaround to not run the early data test
in Windows-2013 where there is an issue with
mbedtls_vsnprintf().
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
We'll test more fully by adding a call to mbedtls_pk_import_into_psa() once
that function is implemented.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test code to construct test keys and the implementation had matching
errors: both assumed that there was a PSA public key object. Fix this.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
2 scenarios are taken into account:
- syntactically valid extra data inside the SEQUENCE
- extra data outside the SEQUENCE
A single integer is used as extra data in both cases.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Output buffer is tested from being 1 single byte up to twice
what it is strictly required to contain the output data.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
