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>
The support for the PSA crypto driver interface
is not optional anymore as the implementation of
the PSA cryptography interface has been restructured
around the PSA crypto driver interface (see
psa-crypto-implementation-structure.md). There is
thus no purpose for the configuration options
MBEDTLS_PSA_CRYPTO_DRIVERS anymore.
Signed-off-by: Ronald Cron <ronald.cron@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>
Moved python script generate_driver_wrappers.py under scripts and
corresponding template file under script/data_files.
Signed-off-by: Archana <archana.madhavan@silabs.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>
Time stamps are useful when the document gets shared around, but they
tend to lead to merge conflicts.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.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>
Allow the core to call the "get_builtin_key" entry point to retrieve
the attributes of a built-in key. This is useful to implement
psa_get_key_attributes(), and also when the key data buffer's size
depends on the key type and size.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Having a time stamp identifying each revision of the document is
useful, but it's also a pain because it creates a conflict whenever
there are multiple pending changes at the same time. The gain isn't
worth the pain, so I'm removing the time stamp.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Rework the section describing key import, in particular to clarify key
size determination and checking. There is no intended semantic change.
Note an open question around support for implementation-specific
import formats.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
