Don't try to use {sign,verify}_message on algorithms that only support
{sign_verify}_hash. Normally exercise_key() tries all usage that is
supported by policy, however PSA_KEY_USAGE_{SIGN,VERIFY}_MESSAGE is implied
by PSA_KEY_USAGE_{SIGN,VERIFY}_HASH so it's impossible for the test data to
omit the _MESSAGE policies with hash-only algorithms.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't re-code the logic to determine a valid nonce length.
This fixes exercise_key() for PSA_ALG_CHACHA20_POLY1305, which was trying to
use a 16-byte nonce.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The cipher module implements XTS, and the PSA API specifies XTS, but the PSA
implementation does not support XTS. It requires double-size keys, which
psa_crypto does not currently support.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Mbed TLS doesn't support certain block cipher mode combinations. This
limitation should probably be lifted, but for now, test them as unsupported.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reject algorithms of the form PSA_ALG_TRUNCATED_MAC(...) or
PSA_ALG_AEAD_WITH_SHORTENED_TAG(...) when the truncation length is invalid
or not accepted by policy in Mbed TLS.
This is done in KeyType.can_do, so in generate_psa_tests.py, keys will be
tested for operation failure with this algorithm if the algorithm is
rejected, and for storage if the algorithm is accepted.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The current macro collector only tried the minimum and maximum expressible
lengths for PSA_ALG_TRUNCATED_MAC and PSA_ALG_AEAD_WITH_DEFAULT_LENGTH_TAG.
This was good enough for psa_constant_names, but it's weak for exercising
keys, in particular because it doesn't include any valid AEAD tag length.
So cover more lengths.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Support ECB, which has no IV. The code also now supports arbitrary IV
lengths based on the algorithm and key type.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Only allow selected modes with 64-bit block ciphers (i.e. DES).
This removes some storage tests and creates corresponding op_fail tests.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In key read tests, add usage flags that are suitable for the key type and
algorithm. This way, the call to exercise_key() in the test not only checks
that exporting the key is possible, but also that operations on the key are
possible.
This triggers a number of failures in edge cases where the generator
generates combinations that are not valid, which will be fixed in subsequent
commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This currently makes all the descriptions unambiguous even when truncated at
66 characters, as the unit test framework does.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The output of generate_psa_tests.py is almost unchanged: the differences are
only spaces after commas (now consistently omitted).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When generating storage format tests, pass usage flags around as a list, and
format them as the last thing.
In Storagekey(), simplify the addition of implicit usage flags: this no
longer requires parsing.
The output is unchanged.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the generated storage format test cases, cover all supported
algorithms for each key type. This is a step towards exercising
the key with all the algorithms it supports; a subsequent commit
will generate a policy that permits the specified algorithms.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use the new generic is_public method.
Impact on generated cases: there are new HMAC test cases for SIGN_HASH. It
was a bug that these test cases were previously not generated.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Deduce MBEDTLS_PSA_ACCEL_KEY_TYPE_ARIA for the driver build from its value
from the core build, as is done for other key types. This had not been done
correctly when adding ARIA support to the PSA subsystem.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We don't yet support all combinations of configurations. With all.sh as it
currently stands, component_test_psa_crypto_config_accel_cipher results in a
build where PSA_WANT_ALG_CMAC is disabled but CMAC operations succeed
nonetheless, going via the driver. With the systematic testing of
not-supported operations, this now results in a test failure.
The code in all.sh does not respect the principle documented in
df885c052c:
> The PSA_WANT_* macros have to be the same as the ones
> used to build the Mbed TLS library the test driver
> library is supposed to be linked to as the PSA_WANT_*
> macros are used in the definition of structures and
> macros that are shared by the PSA crypto core,
> Mbed TLS drivers and the driver test library.
Disable PSA_WANT_ALG_CMAC completely in this test component. This is not
wrong and it makes the test component pass.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
time() is only needed to seed the PRNG non-deterministically. If it isn't
available, do seed it, but pick a static seed.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
The timing module might include time.h on its own when on
a suitable platform, even if MBEDTLS_HAVE_TIME is disabled.
Co-authored-by: Tom Cosgrove <tom.cosgrove@arm.com>
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Having such implementation might cause issues for those that
expect to have a working implementation.
Having a compile-time error is better in such case.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
It doesn't make sense for psa_mac_verify() to return
PSA_ERROR_BUFFER_TOO_SMALL since it doesn't have an output buffer. But this
was happening when requesting the verification of an unsupported algorithm
whose output size is larger than the maximum supported MAC size, e.g.
HMAC-SHA-512 when building with only SHA-256 support. Arrange to return
PSA_ERROR_NOT_SUPPORTED instead.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In some cases, a cipher operation for an unsupported algorithm could succeed
in psa_cipher_{encrypt,decrypt}_setup() and fail only when input is actually
fed. This is not a major bug, but it has several minor downsides: fail-late
is harder to diagnose for users than fail-early; some code size can be
gained; tests that expect failure for not-supported parameters would have to
be accommodated to also accept success.
This commit at least partially addresses the issue. The only completeness
goal in this commit is to pass our full CI, which discovered that disabling
only PSA_WANT_ALG_STREAM_CIPHER or PSA_WANT_ALG_ECB_NO_PADDING (but keeping
the relevant key type) allowed cipher setup to succeed, which caused
failures in test_suite_psa_crypto_op_fail.generated in
component_test_psa_crypto_config_accel_xxx.
Changes in this commit:
* mbedtls_cipher_info_from_psa() now returns NULL for unsupported cipher
algorithms. (No change related to key types.)
* Some code that is only relevant for ECB is no longer built if
PSA_WANT_ALG_ECB_NO_PADDING is disabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the error status can be PSA_ERROR_INVALID_SIGNATURE instead of the
expected PSA_ERROR_NOT_SUPPORTED in some configurations. For example, the
RSA verification code currently checks the signature size first whenever
PSA_KEY_TYPE_RSA_PUBLIC_KEY is enabled, and only gets into
algorithm-specific code if this passes, so it returns INVALID_SIGNATURE even
if the specific algorithm is not supported.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the systematically generated algorithm-not-supported tests
complain when they try to start an operation and succeed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Otherwise the systematically generated algorithm-not-supported tests
complain when they try to start an operation and succeed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
They're redundant with the automatically generated test cases, but it's
useful to have them when debugging issues with the test code.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The test suite test_suite_psa_crypto_op_fail now runs a large number
of automatically generated test cases which attempt to perform a
one-shot operation or to set up a multi-part operation with invalid
parameters. The following cases are fully covered (based on the
enumeration of valid algorithms and key types):
* An algorithm is not supported.
* The key type is not compatible with the algorithm (for operations
that use a key).
* The algorithm is not compatible for the operation.
Some test functions allow the library to return PSA_ERROR_NOT_SUPPORTED
where the test code generator expects PSA_ERROR_INVALID_ARGUMENT or vice
versa. This may be refined in the future.
Some corner cases with algorithms combining a key agreement with a key
derivation are not handled properly. This will be fixed in follow-up
commits.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Determine key types that are compatible with an algorithm based on
their names.
Key derivation and PAKE are not yet supported.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
