Move MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET
error code documentation to the documentation of
mbedtls_ssl_read() as we cannot have long error
descriptions because of a limitation in
generate_errors.pl.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
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>
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 removes the compatibility-breaking requirement from the
documentation.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These macros are not part of any public or internal API, ideally they
would be defined in the source files. The reason to put them in
bignum_core.h to avoid duplication as macros for this purpose are
needed in both bignum.c and bignum_core.c.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The complexity of having functions whose security properties depend on a
runtime argument can be dangerous. Limit misuse by making any such
functions local.
Signed-off-by: Janos Follath <janos.follath@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>
Don't formally deprecate them because we don't do that in a
long-time support branch. But do point readers away from them.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Replace references to the deprecated functions `psa_generate_key_ext()` and
`psa_key_derivation_output_key_ext()` by their replacements
Implement `psa_generate_key_custom()` and
`psa_key_derivation_output_key_custom()`.
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>
The description was misleading: setting the option doesn't “restrict” the
number of slots, that restriction exists anyway. Setting the option merely
determines the value of the limit.
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>
Make it possible, but not officially supported, to switch the CTR_DRBG
module to PSA mode even if MBEDTLS_AES_C is defined. This is not really
useful in practice, but is convenient to test the PSA mode without setting
up drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
PSA buffers and their length should follow a pattern for which
the latter is named after the former as <buffer_name>_length,
but this was not the case for psa_key_derivation_verify_bytes().
This makes life of crypto.h parsers (for automatic code generation)
harder. This commit aims at solving this problem.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Attempt to partially solve the performance regression in 3.6.0 without
adding too much code size.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Issue #9179 (MBEDTLS_SSL_CID_OUT_LEN_MAX changed to
MBEDTLS_SSL_CID_IN_LEN_MAX in library\ssl.h and library\ssl_tls.c)
Signed-off-by: Sam Berry <sam.berry@arm.com>
Some functions has input parameters which are erroneously
reported as "param[out]" in the documentation. This commit
fixes them.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
psa_crypto_mac.c uses mbedtls_cipher_xxx() functions to perform
CMAC operations. Therefore we need to enable CIPHER_C when
PSA CMAC is builtin.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
Some projects using Mbed TLS have migrated their configuration
file (config.h -> mbedtls_config.h, or MBEDTLS_CONFIG_FILE) from Mbed TLS
2.x, and kept including check_config.h. This is unnecessary since Mbed TLS
3.0, and increasingly in 3.x it may report spurious errors because the
configuration adjustments have not been done yet.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Some projects using Mbed TLS have migrated their configuration
file (config.h -> mbedtls_config.h, or MBEDTLS_CONFIG_FILE) from Mbed TLS
2.x, and kept including check_config.h. This is unnecessary since Mbed TLS
3.0, and increasingly in 3.x it may report spurious errors because the
configuration adjustments have not been done yet. This has led some
projects to include configuration adjustment headers manually, but only
partially or in the wrong order, which can result in silent inconsistencies.
Error out if this happens, with a message mentioning check_config.h since
that's the likely root cause.
```
perl -i -pe '$name = $ARGV; $name =~ s!include/!!; $name =~ s!_adjust_.*!_adjust_*.h!; $_ .= "\n#if !defined(MBEDTLS_CONFIG_FILES_READ)\n#error \"Do not include $name manually! This can lead to problems, \" \\\n \"up to and including runtime errors such as buffer overflows. \" \\\n \"If you're trying to fix a complaint from check_config.h, just remove it \" \\\n \"from your configuration file: since Mbed TLS 3.0, it is included \" \\\n \"automatically at the right time.\"\n#endif /* !MBEDTLS_CONFIG_FILES_READ */\n" if /^#define .*_H$/' include/*/*adjust*.h
```
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Including *adjust*.h directly is likely to cause them to be applied at the
wrong time, resulting in an invalid or unintended configuration.
Including check_config.h at the wrong time is likely to cause spurious
errors.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The Mbed TLS implementations of ALG_TLS12_PRF,
ALG_TLS12_PSK_TO_MS, ALG_HKDF, ALG_HKDF_EXTRACT,
ALG_HKDF_EXPAND and ALG_PBKDF2 rely on HMAC
operations through the driver interface. Thus
if one of these algorithms is enabled and not
accelerated, we need ALG_HMAC to be enabled
(PSA_WANT_ALG_HMAC and PSA_WANT_KEY_TYPE_HMAC
defined). As HMAC operations occur through
the driver interface, HMAC operations can be
accelerated even if the caller algorithm
is not.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
