HKDF-Expand can produce at most 255 * hash_size bytes of key material,
so this limit applies to the TLS 1.3 key material exporter.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
Add the option MBEDTLS_SSL_KEYING_MATERIAL_EXPORT to mbedtls_config.h
to control if the function mbedtls_ssl_export_keying_material() should
be available. By default, the option is disabled.
This is because the exporter for TLS 1.2 requires client_random and
server_random need to be stored after the handshake is complete.
Signed-off-by: Max Fillinger <max@max-fillinger.net>
The TLS-Exporter in TLS 1.2 requires client_random and server_random.
Unless MBEDTLS_SSL_CONTEXT_SERIALIZATION is defined, these aren't stored
after the handshake is completed.
Therefore, mbedtls_ssl_export_keying_material() exists only if either
MBEDTLS_SSL_CONTEXT_SERIALIZATION is defined or MBEDTLS_SSL_PROTO_TLS1_2
is *not* defined.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
This way, it's not required that the label is null-terminated. This
allows us to avoid an allocation in
mbedtls_ssl_tls12_export_keying_material().
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
Previously, if MBEDTLS_SSL_CONTEXT_SERIALIZATION is not defined,
randbytes are not stored after the handshake is done, but they are
needed for TLS-Exporter in TLS 1.2.
This commit also saves randbytes if MBEDTLS_SSL_PROTO_TLS1_2 is defined.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The length of the generated key must fit into a uint16_t, so it must not
be larger than 0xffff.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
RFC 8446 made it look like we can't use Derive-Secret for the second
step, but actually, Transcript-Hash and Hash are the same thing, so we
can.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
The TLS-Exporter is a function to derive shared symmetric keys for the
server and client from the secrets generated during the handshake.
It is defined in RFC 8446, Section 7.5 for TLS 1.3 and in RFC 5705 for
TLS 1.2.
Signed-off-by: Max Fillinger <maximilian.fillinger@foxcrypto.com>
This should avoid running into a bug with printf format specifiers one
windows.
It's also a logical move for actual tests: I used the highest debug
level for discovery, but we don't need that all the time.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
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>
