When MBEDTLS_HARDWARE_GCM is enabled, we ALT all the GCM functions that are
declared in mbedtls/gcm.h with our H/W port functions, due to which even
if non-AES ciphers such as ARIA, CAMELLIA, BLOWFISH, etc. are selected
for a GCM operation, we perform an AES-GCM operation, thus resulting into
an incorrect calculation.
Thus in such cases we need to fallback to the software definitions of
GCM.
Currently, it is not directly possible to pull in software definitions of GCM
related functions directly due to gcm_alt.h, but this commit renames the
functions by appending `_soft` to their names, thus making them look different
functions in all and thus they are made available to pull in during compilation.
The change is configrable using the config MBEDTLS_GCM_NON_AES_CIPHER_SOFT_FALLBACK.
As this config is enabled by default, building the mbedtls crypto library
(libmbedcrypto.a) with this change increases its size by ~2.5KB.
- ESP32C2 has a hardware ECC accelerator that supports NIST P-192 and NIST P-256 curves,
which can increase the performance of the point multiplication and point
verification operation.
- Provision is also added to fallback to software implementation in
case the curve is not from the supported curves
- Override ecp_mul_restartable_internal with accelerator
- Many ECC operations use the internal API ecp_mul_restartable_internal
instead of the public API mbedtls_ecp_mul for point multiplication.
This will improve the performance of all those parent operations as
well
(cherry picked from commit 0ecb27b9d88059e8980c8ae6e111283f5f2859f8)
For exponential mod (API mbedtls_mpi_exp_mod) operation, some ESP target
chips needs to have ability for both hardware and software implementation.
Hardware implementation provided performance advantage but it can only
support upto 3072 bit operations (e.g., ESP32-C3) and hence we fallback
to software implementation in such cases (e.g., 4096 bit operations).
Earlier this was handled using linker "--wrap" flag but that does not
work in all scenarios as API `mbedtls_mpi_exp_mod` is being used in
same tranlation (compilation unit).
This approach was found to be next best option with minimal changes in
mbedTLS library.
(cherry picked from commit ab3a845107377c6cdf148f86015cad94434a1f2e)
Add mbedtls_ssl_conf_enable_new_session_tickets() API
to be able to enable and disable the handling of TLS 1.3
NewSessionTicket messages.
The TLS 1.2 equivalent function is named
mbedtls_ssl_conf_session_tickets() thus the most
natural name would have been
mbedtls_ssl_conf_new_session_tickets() but it is
already used on server side thus rather
mbedtls_ssl_conf_enable_new_session_tickets().
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
This reduces the workflows where psa_crypto_init is called when not
necessary: it won't be called when a dual-version server receives a 1.2-only
ClientHello.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
For backward compatibility with Mbed TLS <=3.5.x, applications must be able
to make a TLS connection with a peer that supports both TLS 1.2 and TLS 1.3,
regardless of whether they call psa_crypto_init(). Since Mbed TLS 3.6.0,
we enable TLS 1.3 in the default configuration, so we must take care of
calling psa_crypto_init() if needed. This is a change from TLS 1.3 in
previous versions, where enabling MBEDTLS_SSL_PROTO_TLS1_3 was a user
choice and could have additional requirement.
This commit makes the library call psa_crypto_init() when it needs PSA
crypto in a situation where the application might not have called it,
namely, when starting a TLS 1.3 connection.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
We are technically allowed to use all possible values of key slice index
that will fit into the bit width we have allocated, so allow all values.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The persistent key cache slice is the last slice (not the first as
previously stated). Update the numbering-related comments accordingly.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Actually moved the function rather than trying to edit guards around it,
because the relevant guards are not nearby, the function was part of
larger blocks, so it seemed risky.
Also, that seems logically correct: the function is no longer part of
the "TLS 1.2 handshake functions common to server and client" section,
it's part of the "helper functions common to 1.2 and 1.3 server and
client" block. Ideally in the future perhaps the file structure should
reflect that (`ssl_generic.c` vs `ssl_tls12_generic.c`?) but that's out
of scope here.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Rename as there was a name collision with a static function in another
file: ssl_parse_certificate_verify in ssl_tls12_server.c is the function
that parses the CertificateVerify message, which seems appropriate. Here
it meant "the 'verify' step after parsing the Certificate message".
Use a name that focuses on what it does: verify, not parse.
Also, take ciphersuite_info as an argument: when TLS 1.3 calls this
function, it can pass NULL as the ciphersuite has no influence there.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In particular, make sure pointer variables are initialized right after
being declared.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
This is for compatibility, for people transitioning from 1.2 to 1.3.
See https://github.com/Mbed-TLS/mbedtls/issues/9223 "Mandatory server
authentication" and reports linked from there.
In the future we're likely to make server authentication mandatory in
both 1.2 and 1.3. See https://github.com/Mbed-TLS/mbedtls/issues/7080
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We don't check the non-standard nsCertType extension, so this flag can't
be set, so checking if it's set is useless.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The comments were about the time we were using mbedtls_pk_ec(), which
can return NULL, which we don't want to propagate to other functions.
Now we're using mbedtls_pk_get_ec_group_id() with is a safer interface
(and works even when EC is provided by drivers).
The check for GROUP_NONE was an heritage from the previous NULL check.
However it's actually useless: if NONE were returned (which can't happen
or parsing of the certificate would have failed and we wouldn't be
here), then mbedtls_ssl_check_curve() would work and just say that the
curve wasn't valid, which is OK.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>