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>
The new test hooks allow to check whether there was an unsafe call of an
optionally safe function in the codepath. For the sake of simplicity the
MBEDTLS_MPI_IS_* macros are reused for signalling safe/unsafe codepaths
here too.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The allocated size can be significantly larger than the actual size. In
the unsafe case we can use the actual size and gain some performance.
Signed-off-by: Janos Follath <janos.follath@arm.com>
It is easier to read if the parameter controlling constant timeness with
respect to a parameter is next to that parameter.
Signed-off-by: Janos Follath <janos.follath@arm.com>
In Thumb instructions, constant can be:
- any constant that can be produced by shifting an 8-bit value left by any
number of bits within a 32-bit word
- any constant of the form 0x00XY00XY
- any constant of the form 0xXY00XY00
- any constant of the form 0xXYXYXYXY.
Signed-off-by: Janos Follath <janos.follath@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 risk by isolating such code in
small functions with limited scope.
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>
