The new test hooks allow to check whether there was an unsafe call of an
optionally safe function in the codepath. For the sake of simplicity the
MBEDTLS_MPI_IS_* macros are reused for signalling safe/unsafe codepaths
here too.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Add a practical way to fill the dynamic key store by artificially limiting
the slice length through a test hook.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's impractical to fill the key store when it can grow to accommodate
millions of keys.
A later commit will restore those tests in test configurations with the
dynamic key store.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Create a new compilation option for a dynamically resized key store. The
implementation will follow in subsequent commits.
This option is off by default with custom configuration files, which is best
for typical deployments on highly constrained platforms. This option is on
by default with the provided configuration file, which is best for typical
deployments on relatively high-end platforms.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We know it's a thin wrapper around psa_generate_key_custom, so we just need
to check that it's passing the information through, we don't need coverage
of the parameter interpretation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Implement `psa_generate_key_custom()` and
`psa_key_derivation_output_key_custom()`. These functions replace
`psa_generate_key_ext()` and `psa_key_derivation_output_key_ext()`.
They have the same functionality, but a slightly different interface:
the `ext` functions use a structure with a flexible array member to pass
variable-length data, while the `custom` functions use a separate parameter.
Keep the `ext` functions for backward compatibility with Mbed TLS 3.6.0.
But make them a thin wrapper around the new `custom` functions.
Duplicate the test code and data. The test cases have to be duplicated
anyway, and the test functions are individually more readable this way.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When PSA uses CTR_DRBG for its random generator and CTR_DRBG uses PSA for
AES, as currently implemented, there is one volatile key in permanent use
for the CTR_DRBG instance. Account for that in tests that want to know
exactly how many volatile keys are in use, or how many volatile keys can be
created.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When the PSA RNG uses AES through a PSA driver, it consumes one volatile key
identifier. When MBEDTLS_PSA_KEY_SLOT_DYNAMIC is enabled, that identifier
happens to coincide with the key ID value that the test case assumes not to
exist. Use a different value that avoids this coincidence.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Split the "many transient keys" test function in two: one that expects to
successfully create many keys, and one that expects to fill the key store.
This will make things easier when we add a dynamic key store where filling
the key store is not practical unless artificially limited.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
PSA_KEY_ID_VOLATILE_MIN-1 is now in the persistent key ID range, so it's no
longer an invalid key ID for registration.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Restricting the built-in key range would be an API break since applications
can hard-code a built-in key value and expect that it won't clash with
anything else. Make it harder to accidentally break the API.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_psa_register_se_key() is not usable with volatile keys, since there
is no way to return the implementation-chosen key identifier which would be
needed to use the key. Document this limitation. Reject an attempt to create
such an unusable key. Fixes#9253.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a test suite intended to report configuration options in the outcome
file: we're only interested in SKIP vs PASS.
Add a few test cases for some interesting combinations of options. The
selection here is just for illustration purposes, more will be added later.
A subsequent commit will automatically generate test cases for single options.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When trying to decrypt data with an invalid key, we found that `mbedtls`
returned `0x6200` (`-25088`), which means "_CIPHER - Input data contains
invalid padding and is rejected_" from `mbedtls_cipher_finish`, but it also
set the output len as `18446744073709551516`.
In case we detect an error with padding, we leave the output len zero'ed
and return `MBEDTLS_ERR_CIPHER_INVALID_PADDING`.
Here's a reference for the way `openssl` checks the padding length:
- 1848c561ec/crypto/evp/evp_enc.c (L1023)
- b554eef43b
So add a check ensuring output is set to the least-harmful value in the
error cases.
With the robustness fix:
`PASSED (125 suites, 26644 tests run)`
Without the robustness fix:
`FAILED (125 suites, 26644 tests run)`
Signed-off-by: Andre Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Andre Goddard Rosa <agoddardrosa@roku.com>
When PSA is available, we exercise the parsed RSA key with PKCS#1v1.5
signature, which requires the modulus size in bytes to be at least
tLen + 11 (per RFC 8017 §9.2) where tLen = hLen + oidLen + 6 and
hLen = 32, oidLen = 9 for SHA-512 or SHA3-512. 10 is the DER overhead
(3 ASN.1 type-length headers with lengths <128). Replace 512-bit test
cases (good enough for SHA-256 but not SHA-384 and up) by 768-bit and
up (good enough for SHA-512).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
