When verifying the impact of a forced RNG failure, depend on the built-in
implementation of the algorithm that uses randomization, whether it's
because the algorithm is randomized or because our implementation uses
randomization for (e.g.) blinding. An external implementation could use
its own randomness source which is not affected by the forced failure of
the RNG driver.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Under MBEDTLS_ERR_RSA_RNG_FAILED, add tests where the random generator
failed. This commit tests the following operations:
* psa_generate_random()
* psa_generate_key() for a symmetric key
* Deterministic signatures that use blinding (RSA PKCS#1v1.5,
deterministic ECDSA).
* Randomized signatures (RSA PSS, randomized ECDSA).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_rsa_private() could return the sum of two RSA error codes
instead of a valid error code in some rare circumstances:
* If rsa_prepare_blinding() returned MBEDTLS_ERR_RSA_RNG_FAILED
(indicating a misbehaving or misconfigured RNG).
* If the comparison with the public value failed (typically indicating
a glitch attack).
Make sure not to add two high-level error codes.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
To reduce the risk of people accidentally using the test
implementation of mbedtls_psa_external_get_random(), which is
insecure, require the user to explicitly call
mbedtls_test_enable_insecure_external_rng() first.
Disabling the test implementation of mbedtls_psa_external_get_random()
will also allow negative testing for MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG,
which will be added in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Include psa_crypto_helpers.h automatically if MBEDTLS_PSA_CRYPTO_C is
enabled, like helpers.h is included automatically.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
psa_crypto_helpers.h no longer defines static functions, so it can be
included anywhere without worrying about unused functions.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
`tests/scripts/all.sh test_psa_collect_statuses` calls
`tests/scripts/psa_collect_statuses.py` which calls
`make -DRECORD_PSA_STATUS_COVERAGE_LOG` which must generate
`include/test/instrument_record_status.h`.
With the refactoring of `psa_crypto_helpers.{h,c}`, this now
needs to be done before building `psa_crypto_helpers.c`.
Also, remove `include/test/instrument_record_status.h` unconditionally
in `make clean`, which helps keep the build tree clean.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move function definitions from psa_crypto_helpers.h to
psa_crypto_helpers.c.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Refactor some PSA test helper functions and macros to avoid depending
on test_info and test_fail inside functions. These identifiers are
only defined in helpers.function, so they're only available in test
suites, and not in test helper modules (tests/src/*.c) which are also
linked into example programs.
This is in preparation for moving function definitions from
psa_crypto_helpers.h to psa_crypto_helpers.c.
No behavior change.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Since 349eadc58f, test_fail() reports
the first failure. So it's safe to call test_fail() again to report a
cleanup failure when we don't want to potentially erase information
about an earlier failure.
The behavior of mbedtls_test_helper_is_psa_pristine() changes if
test_info.result was neither TEST_RESULT_SUCCESS nor
TEST_RESULT_FAILED, but this should not matter since a skipped test
should not cause mbedtls_test_helper_is_psa_pristine() to fail.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Closing a wrapped key with the new SE driver interface while
MBEDTLS_PSA_CRYPTO_SE_C is also enabled leads to the key material not
being freed, even though an old SE driver is not in use, leading to a
memory leak. This is because a wrapped key is also considered external.
This commit extends the check for skipping by checking whether an
old-style SE driver is registered with the provided slot, in addition to
checking whether the key is external.
Signed-off-by: Fredrik Strupe <fredrik.strupe@silabs.com>
mbedtls_ssl_conf_dtls_srtp_protection_profiles stores the pointer to the
profiles in the configuration.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
Make it clear that this is an abstraction of the random generator
abstraction, and not an abstraction of the PSA random generator.
mbedtls_psa_get_random and MBEDTLS_PSA_RANDOM_STATE are public-facing
definitions and will be moved in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the external RNG case, don't make mbedtls_psa_get_random() a
static inline function: this would likely result in identical
instances of this function in every module that uses it. Instead, make
it a single function with external linkage.
In the non-external case, instead of a trivial wrapper function, make
mbedtls_psa_get_random a constant pointer to whichever DRBG function
is being used.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Hide the obtention of the pointer to the RNG state behind a macro.
To make it possible to use this macro in a module other than
psa_crypto.c, which will happen in the future, make sure that the
definition of the macro does not reference internal variables of
psa_crypto.c. For this purpose, in the internal-DRBG case, export a
symbol containing the address of the DRBG state.
When the RNG state is a pointer a DRBG state, just keep this pointer
in a variable: there's no need to store a pointer to a larger structure.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some of the material was originally the PSA specification, and
discusses how different implementations might behave. Replace such
statements by a description of how Mbed TLS behaves.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's about who has access to the key material in plaintext, not directly
where the operation is performed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These entries were for different aspects of a new, partially implemented
feature. Therefore we are consolidating them into a single entry for
clarity.
Signed-off-by: Janos Follath <janos.follath@arm.com>
