The current impelementation asserts if the user
sets MBEDTLS_PSA_KEY_SLOT_COUNT to one or if they
limit their builtin range to one key.
This removes the requirement and allows for only
one key volatile/builtin to be enabled.
Signed-off-by: Georgios Vasilakis <georgios.vasilakis@nordicsemi.no>
If the calc_finished function returns an error code, don't ignore it but
instead return the error code to stop the handshake as the Finished
message may be incorrect.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
The of m_bytes value isn't actually used when it's uninitialized,
because *data is null, but that's very fragile.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
A handshake record may contain multiple handshake messages, or multiple
fragments (there can be the final fragment of a pending message, then zero
or more whole messages, and an initial fragment of an incomplete message).
This was previously untested, but supported, so don't break it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Reassemble handshake fragments incrementally instead of all at the end. That
is, every time we receive a non-initial handshake fragment, append it to the
initial fragment. Since we only have to deal with at most two handshake
fragments at the same time, this simplifies the code (no re-parsing of a
record) and is a little more memory-efficient (no need to store one record
header per record).
This commit also fixes a bug. The previous code did not calculate offsets
correctly when records use an explicit IV, which is the case in TLS 1.2 with
CBC (encrypt-then-MAC or not), GCM and CCM encryption (i.e. all but null and
ChachaPoly). This led to the wrong data when an encrypted handshake message
was fragmented (Finished or renegotiation). The new code handles this
correctly.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Minor refactoring of the initial checks and preparation when receiving the
first fragment. Use `ssl->in_hsfraglen` to determine whether there is a
pending handshake fragment, for consistency, and possibly for more
robustness in case handshake fragments are mixed with non-handshake
records (although this is not currently supported anyway).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In preparation for reworking mbedtls_ssl_prepare_handshake_record(),
tweak the "handshake fragment:" log message.
This changes what information is displayed when a record contains data
beyond the expected end of the handshake message. This case is currently
untested and its handling will change in a subsequent commit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In preparation for reworking mbedtls_ssl_prepare_handshake_record(), tweak
the "waiting for more handshake fragments" log message in
ssl_consume_current_message(), and add a similar one in
mbedtls_ssl_prepare_handshake_record(). Assert both.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This allows any implementer of the PSA client interface to easily
include this header and therefore function's prototype.
Signed-off-by: Valerio Setti <valerio.setti@nordicsemi.no>
In the `mbedtls_ssl_context` structure, merge the field `in_hsfraglen` into
`badmac_seen_or_in_hsfraglen`. This restores the ABI of `libmbedtls` as it
was in Mbed TLS 3.6.0 through 3.6.2.
The field `badmac_seen_or_in_hsfraglen` (formerly `badmac_seen`) was only
used for DTLS (despite being present in non-DTLS builds), and the field
`in_hsfraglen` was only used in non-DTLS TLS. Therefore the two values can
be stored in the same field.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the `mbedtls_ssl_context` structure, change the type of `in_hsfraglen`
from `size_t` to `unsigned`. This is in preparation for merging
`in_hsfraglen` into `badmac_seen_or_in_hsfraglen`, which has the type
`unsigned` and cannot change since we do not want to change the ABI.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Prepare to unify two fields of the `mbedtls_ssl_context` structure:
`badmac_seen` (always present but only used in DTLS) and
`in_hsfraglen` (always present but only used in non-DTLS TLS).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The first fragment of a fragmented handshake message always starts at the beginning of the buffer so there's no need to store it.
Signed-off-by: Deomid rojer Ryabkov <rojer@rojer.me>
In a TLS client, when using certificate authentication, the client should
check that the certificate is valid for the server name that the client
expects. Otherwise, in most scenarios, a malicious server can impersonate
another server.
Normally, the application code should call mbedtls_ssl_set_hostname().
However, it's easy to forget. So raise an error if mandatory certificate
authentication is in effect and mbedtls_ssl_set_hostname() has not been
called. Raise the new error code
MBEDTLS_ERR_SSL_CERTIFICATE_VERIFICATION_WITHOUT_HOSTNAME, for easy
identification.
But don't raise the error if the backward compatibility option
MBEDTLS_SSL_CLI_ALLOW_WEAK_CERTIFICATE_VERIFICATION_WITHOUT_HOSTNAME is
enabled.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Use a special marker as ssl->hostname if mbedtls_ssl_set_hostname() has been
called with NULL. If mbedtls_ssl_set_hostname() has never been called, the
field is NULL, as before.
No behavior change apart from now emitting a different log message depending
on whether mbedtls_ssl_set_hostname() has been called with NULL or not at all.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
New abstractions to access ssl->hostname:
mbedtls_ssl_has_set_hostname_been_called() (only implemented approximatively
for now), mbedtls_ssl_get_hostname_pointer(), mbedtls_ssl_free_hostname().
Only access ssl->hostname directly in these functions and in
mbedtls_ssl_set_hostname().
Use these abstractions to access the hostname with the opportunity for
extra checks in mbedtls_ssl_verify_certificate().
No behavior change except for a new log message.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Check names is intended for public APIs. It doesn't matter if we call a
static function a non-namespaced name, so add an exception in the
invasive testing header file.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Previously, we were checking if the last padding byte was in the range
1-16 and returning early if not. This was to prevent an integer overflow
in the output length.
Instead, do the checks in constant-time and conditionally set the output
length based on whether the padding is correct or not, preventing both
the side-channel and the integer overflow.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
Detect attempts to do ECDSA with a Montgomery curve in psa_sign_hash_start()
and psa_verify_hash_start(), whereas before start() would succeed and
complete() would fail. This avoids an inconsistency between psa_sign_hash()
and psa_sign_hash_start() that would be annoying to handle in
test_suite_psa_crypto_op_fail.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't list mechanisms that are not implemented in
`include/psa/crypto_config.h`, even commented out. Uncommenting them
wouldn't help anyway: they don't work. Having them listed, even commented
out, causes `find_dependencies_not_implemented()` in `psa_test_case.py` to
consider those mechanisms to be implemented, and thus causes
`generate_psa_tests.py` to generate test cases that cannot be executed.
The affected mechanisms are:
* `PSA_ALG_CBC_MAC` (`PSA_WANT_ALG_CBC_MAC`)
* `PSA_ALG_XTS` (`PSA_WANT_ALG_XTS`)
* `PSA_ECC_FAMILY_SECP_K1` 224-bit (`PSA_WANT_ECC_SECP_K1_224`)
Also remove the affected mechanisms from configuration adjustment files,
since that is code that can never be triggered.
There were already no generated test cases for SECP224K1 because
`PSA_WANT_ECC_SECP_K1_224` was already detected as a dependency that cannot
be implemented, because that is not a valid size: PSA defines SECP224K1 as
225-bit, and `crypto_knowledge.py` follows suite, so `generate_psa_tests.py`
saw `PSA_WANT_ECC_SECP_K1_225` in its enumeration but skipped it because it
was never mentioned in `crypto_config.h`.
This causes generated PSA tests to no longer include positive test cases for
`PSA_ALG_CBC_MAC` and `PSA_ALG_XTS`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
