- use mbedtls_ecp_point_write_binary() instead mbedtls_mpi_write_binary().
- add check for ECDH curve type in server's certificate
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
The non-PSA path has a debug message here, so let's have a similar one
in the PSA case - just add the curve ID to be a bit more informative.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
There's no way currently (see below regarding the future) that ECC-based
key exchanges are enabled without ECP_C being defined. So, the #if was
fully redundant with the checks surrounding the function, as it always
evaluated to true.
The situation arose as, in the old days (before Mbed TLS 2.0),
mbedtls_ssl_conf_curves() (or ssl_set_curves() as it was called back
then) was optional, controlled by its own compile-time option
POLARSSL_SSL_SET_CURVES. So, in turn mbedtls_ssl_check_curve() depended
on POLARSSL_SSL_SET_CURVES too, and all calls to it were guarded by
that.
When it was made non-optional, a blind
s/POLARSSL_SSL_SET_CURVES/MBEDTLS_ECP_C/ was done, which resulted in
stupid situations like this with redundant checks for ECP_C.
Note regarding the future: at some point it will be possible to compile
with ECC-based key exchanges but without ECP_C. This doesn't change
anything to the reasoning above: mbedtls_ssl_check_curve() will be
available in all builds where ECC is used; it will just need a new
definition (with new guards), but that doesn't change anything for its
callers.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Initially this function was doing something because the output format of
psa_export_public() didn't match the ECPoint format that TLS wants.
Then it became a no-op then the output format of psa_export_public()
changed, but it made sense to still keep the function in case the format
changed again. Now that the PSA Crypto API has reached 1.0 status, this
is unlikely to happen, so the no-op function is no longer useful.
Removing it de-clutters the code a bit; while at it we can remove a
temporary stack buffer (that was up to 133 bytes).
It's OK to remove this function even if it was declared in a public
header, as there's a warning at the top of the file saying it's not part
of the public API.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The refactoring is needed for the group api to work
properly. Code is modified to use mbedtls_get_supported_groups
instead of direct access so that both deprecated and new api
are useable.
Signed-off-by: Brett Warren <brett.warren@arm.com>
exchange groups of the byte reading macros with MBEDTLS_PUT_UINTxyz
and then shift the pointer afterwards. Easier to read as you can
see how big the data is that you are putting in, and in the case of
UINT32 AND UINT64 it saves some vertical space.
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
minor changes, such as improving the documentation for the byte reading
macros, and using MBEDTLS_PUT_UINT16_xy in place of byte reading
macro combinations
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
byte shifting opertations throughout library/ were only replaced with
the byte reading macros when an 0xff mask was being used.
The byte reading macros are now more widley used, however they have not
been used in all cases of a byte shift operation, as it detracted from
the immediate readability or otherwise did not seem appropriate.
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
The CHAR macros casted to an unsigned char which in this project
is garunteed to be 8 bits - the same as uint8_t (which BYTE casts
to) therefore, instances of CHAR have been swapped with BYTE and
the number of macros have been cut down
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
These cast to an unsigned char rather than a uint8_t
like with MBEDTLS_BYTE_x
These save alot of space and will improve maintence by
replacing the appropriate code with MBEDTLS_CHAR_x
Signed-off-by: Joe Subbiani <joe.subbiani@arm.com>
Instances of `mbedtls_ssl_session` represent data enabling session resumption.
With the introduction of TLS 1.3, the format of this data changes. We therefore
need TLS-version field as part of `mbedtlsl_ssl_session` which allows distinguish
1.2 and 1.3 sessions.
This commit introduces such a TLS-version field to mbedtls_ssl_session.
The change has a few ramifications:
- Session serialization/deserialization routines need to be adjusted.
This is achieved by adding the TLS-version after the header of
Mbed TLS version+config, and by having the subsequent structure
of the serialized data depend on the value of this field.
The details are described in terms of the RFC 8446 presentation language.
The 1.2 session (de)serialization are moved into static helper functions,
while the top-level session (de)serialization only parses the Mbed TLS
version+config header and the TLS-version field, and dispatches according
to the found version.
This way, it will be easy to add support for TLS 1.3 sessions in the future.
- Tests for session serialization need to be adjusted
- Once we add support for TLS 1.3, with runtime negotiation of 1.2 vs. 1.3,
we will need to have some logic comparing the TLS version of the proposed session
to the negotiated TLS version. For now, however, we only support TLS 1.2,
and no such logic is needed. Instead, we just store the TLS version in the
session structure at the same point when we populate mbedtls_ssl_context.minor_ver.
The change introduces some overlap between `mbedtls_ssl_session.minor_ver` and
`mbedtls_ssl_context.minor_ver`, which should be studied and potentially resolved.
However, with both fields being private and explicitly marked so, this can happen
in a later change.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
