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>
Restore the optimization done in
HEAD^{/Speed up the generation of storage format test cases}
which was lost during refactoring made when adding support for
implicit usage flags.
There are still more than one call to the C compiler, but the extra
calls are only for some key usage test cases.
This is an internal refactoring. This commit does not change the
output of generate_psa_tests.py
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Update maybe_requires_ciphersuite_enabled so that it will not skip the
ciphersuite requirement when running a test case where the test expects
a ciphersuite mismatch
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
Modify tests to test mbedtls_psa_cipher_operation_t,
mbedtls_transparent_test_driver_cipher_operation_t and
mbedtls_opaque_test_driver_cipher_operation_t struct initialization macros.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Tests for psa_cipher_encrypt and psa_cipher_decrypt functions.
The psa_cipher_encrypt function takes no parameter for IV and always generates
it therefore there will be a randomness in the calculation and cannot be
validated by comparing the actual output with the expected output.
The function is tested by:
- doing a prtially randomized test with an encryption then a decryption
and validating the input with output of the decryption
- validating against the multipart encryption
The combination of this two methods provides enough coverage like a
known answer test.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
It is enough only one test case for a key type, algorithm pair when
testing the implicit usage flags.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Add test cases validating that if a stored key only had the hash policy,
then after loading it psa_get_key_attributes reports that it also has the
message policy, and the key can be used with message functions.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
