This is the case for all key creation in a secure element, but state it
explicitly where relevant.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This is the generic way of going adapting a psa_key_id_t argument in the
application interface to the driver interface. Thanks Hannes Lindström.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The new function psa_crypto_driver_key_derivation_get_input_type() allows
drivers to retrieve the effective type of each input step, and thus to call
the correct get-data function. This is simpler than the previous scheme
which required a somewhat contrived dance with get_key() and get_bytes() for
inputs that can be passed either as a key or as a byte buffer at the
application's choice.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Don't use “output” for an input of the KDF. It's correct in context (it's
the output of a function that copies the input of the KDF from core-owned
memory to driver-owned memory) but confusing.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Pass all the initial inputs in a single structure. It's impossible to pass
the inputs as soon as the application makes them available because the core
cannot know which driver to call until it receives the SECRET input.
Do support hiding the key material inside a secure element if the relevant
driver has all the requisite entry points.
Do cooked key derivation (i.e. derivation of non-raw keys) and key agreement
separately.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Specifically allow the driver to override the persistency level of a
builtin key in cases where the driver is persistency-aware.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
While builtin keys will often have a fixed-size context, this is not
necessarily the case, so the "get_builtin_key" entry point needs to
return the size of the actual key context.
Signed-off-by: Gilles Peskine <Gilles.Peskine@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>
