Some of the material was originally the PSA specification, and
discusses how different implementations might behave. Replace such
statements by a description of how Mbed TLS behaves.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's about who has access to the key material in plaintext, not directly
where the operation is performed.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
These entries were for different aspects of a new, partially implemented
feature. Therefore we are consolidating them into a single entry for
clarity.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Executed ./scripts/bump_version.sh --version 2.25.0 --so-crypto 6
Increasing the SO version of the crypto library, because the openless
API improvement came with API/ABI incompatibilities. For example
- the size of psa_key_handle_t changed
- the type of a parameter in 18 public functions has changed from
psa_key_handle_t to mbedtls_svc_key_id_t
Signed-off-by: Janos Follath <janos.follath@arm.com>
This algorithm replaces the pre-existing stream cipher algorithms.
The underlying stream cipher is determined by the key type.
Signed-off-by: Bence Szépkúti <bence.szepkuti@arm.com>
If a random driver has a built-in entropy source and doesn't need an
external entropy source, make the driver author declare this
explicitly, rather than it being a less secure default.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The get_random entry point was allowed to return partial data on both
PSA_SUCCESS and PSA_ERROR_INSUFFICIENT_ENTROPY, but there was no
meaningful difference between the two. Keep it simple: PSA_SUCCESS is
success but can be partial, and PSA_ERROR_INSUFFICIENT_ENTROPY is an
error with no output.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Explicitly recommend that the driver accounts for environmental
conditions that can affect the amount of entropy.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
A random generation driver does not need to support entropy injection.
This will limit it to platforms where the RNG peripheral is the sole
entropy source and without an RNG seed saved into persistent storage.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
If an RNG peripheral includes an entropy source, it would presumably
declare "initial_entropy_size" and "reseed_entropy_size" to be 0. In
this case, don't require the core to call "add_entropy".
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The `get_entropy` entry point can be provided by multiple transparent
drivers, and the core will call all of them. But apart from that,
`get_entropy` doesn't involve an opaque key or a location, so it can
be in a transparent driver.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Transparent drivers may provide a DRBG interface through "add_entropy"
and "get_random" entry points. This interface may also be used with a
non-deterministic generator, for chips that include a TRNG.
Opaque driver may provide a "get_entropy" entry point.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In order to remove large buffers from the stack, the der data is written
into the same buffer that the pem is eventually written into, however
although the pem data is zero terminated, there is now data left in the
buffer after the zero termination, which can cause
mbedtls_x509_crt_parse to fail to parse the same buffer if passed back
in. Patches also applied to mbedtls_pk_write_pubkey_pem, and
mbedtls_pk_write_key_pem, which use similar methods of writing der data
to the same buffer, and tests modified to hopefully catch any future
regression on this.
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
