Note: limitations of opaque PSKs changed from "TLS 1.2 only" to "none"
since TLS 1.3 does not support PSK at all so far, and it is expected to
support opaque PSKs as soon as it gains PSK support, it will be just a
matter of selecting between psa_key_derivation_input_bytes() and
psa_key_derivation_input_key() - and testing obviously.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The scope of the option has been expanded, now it makes more sense to
describe it as "everything except ...".
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
It was initially motivated by the fact that the PSA Crypto APIs
themselves were not stable. In the meantime, PSA Crypto has reached
1.0.0 so this no longer applies.
If we want user to be able to fully benefit from PSA in order to
isolate long-term secrets, they need to be able to use the new APIs with
confidence. There is no reason to think those APIs are any more likely
to change than any of our other APIs, and if they do, we'll follow the
normal process (deprecated in favour of a new variant).
For reference, the APIs in question are:
mbedtls_pk_setup_opaque() // to use PSA-held ECDSA/RSA keys in TLS
mbedtls_ssl_conf_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_ssl_set_hs_psk_opaque() // for PSA-held PSKs in TLS
mbedtls_cipher_setup_psa() (deprecated in 3.2)
mbedtls_pk_wrap_as_opaque() (documented internal, to be removed in 3.2)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
- misc updates about on-going/recent work
- removal of the section about mixed-PSK: being done in #5762
- clarifications in some places
- some typo fixes
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Setbuf() is currently not guarded by MBEDTLS_FS_IO, nor can it easily be
so. Raised a seperate issue to cover this, and removed the mention of
MBEDTLS_FS_IO from the Changelog.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
* Security: we're improving a countermeasure.
* Requirement change: the library will no longer compile on a platform
without setbuf().
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
After opening a file containing sensitive data, call mbedtls_setbuf() to
disable buffering. This way, we don't expose sensitive data to a memory
disclosure vulnerability in a buffer outside our control.
This commit adds a call to mbedtls_setbuf() after each call to fopen(),
but only in sample programs that were calling mbedtls_platform_zeroize().
Don't bother protecting stdio buffers in programs where application buffers
weren't protected.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
After opening a file containing sensitive data, call mbedtls_setbuf() to
disable buffering. This way, we don't expose sensitive data to a memory
disclosure vulnerability in a buffer outside our control.
This commit adds a call to mbedtls_setbuf() after each call to fopen(),
except:
* In ctr_drbg.c, in load_file(), because this is only used for DH parameters
and they are not confidential data.
* In psa_its_file.c, in psa_its_remove(), because the file is only opened
to check its existence, we don't read data from it.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a platform function mbedtls_setbuf(), defaulting to setbuf().
The intent is to allow disabling stdio buffering when reading or writing
files with sensitive data, because this exposes the sensitive data to a
subsequent memory disclosure vulnerability.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Document that MBEDTLS_SSL_KEEP_PEER_CERTIFICATE is required by MBEDTLS_SSL_PROTO_TLS1_3
Fully validated by the internal CI. No need to wait for the open one.
