The signature of a dummy hash for which no pre-image is know is probably
not sensitive, but zeroize it anyway.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In mbedtls_x509_string_to_names() we were not checking for allocation
failures. An allocation failure would lead to a memcpy() to a null
pointer address.
Fix this by checking the result of the call to mbedtls_calloc() and
returning MBEDTLS_ERR_X509_ALLOC_FAILED in the error case.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Document when this is not used. This was the case in TF-PSA-Crypto 1.0.0,
but not yet in Mbed TLS 3.6.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Instead of unconditionally using `/dev/urandom`, make the device path
configurable at compile time through `MBEDTLS_PLATFORM_DEV_RANDOM` or
at run time through `mbedtls_platform_dev_random`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In DTLS fragmenting tests, do not check for
ServerKeyExchange message fragmentation as
depending on the configuration and consequently
the chosen ciphersuite the server may not
send the message.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
As done in component_test_tls1_2_ccm_psk_dtls_legacy
enable MBEDTLS_HAVE_TIME in
component_test_tls1_2_ccm_psk_dtls_psa.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
In ssl_tls12_server.c:ssl_parse_client_hello(), remove
the code that directly reads the received data to read
the record expected to contain the ClientHello message.
The function already supported handling a ClientHello
read via mbedtls_ssl_read_record() in the following
cases:
- when the ClientHello was read as a post-handshake
message (renegotiation).
- when the ClientHello was read by
ssl_tls13_process_client_hello() during TLS 1.3 or
TLS 1.2 version negotiation.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Relax the dependencies of the tests about handshake
message defragmentation/reassembly on server side.
TLS 1.3 does not need to be enable anymore for this
to work for TLS 1.2 handshake messages.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The original macro was accounting for the size of public FFDH keys,
which are not a concern for PK. Use sizes for key types supported by PK,
this brings the size of the buffer from 1kB to 528 bytes in the default
config.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In all.sh component test_psa_crypto_config_accel_rsa_crypto, where RSA
is provided only by a drivers, we were using a stack buffer. However
that was not correct, as "opaque" (PSA-held) RSA keys are still
possible. This was pointed by failing test cases in test_suite_pk, such
as "PSA import into PSA: opaque RSA, EXPORT (ok)".
As usual with 3.6, we need more complicated pre-processor conditions.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The type was validated near the end of the function when importing, but
if makes more sense to validate upfront before we possibly allocate a
buffer, export the key to it etc.
This also guarantees a sensible error value without requiring a special
case when exporting on the stack.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This makes test_suite_pk pass again, but beyond that I think it's the
right thing to do.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This fixes 2 out of the 3 tests cases that were failing in
test_suite_pk. The last failure will be adressed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
But still retain the ability to function without a heap when only ECC is
enabled.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
