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>
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>
PSA_WANT_xxx is useful regardless of how the symbols are defined:
explicitly (with MBEDTLS_PSA_CRYPTO_CONFIG) or implicitly (without
MBEDTLS_PSA_CRYPTO_CONFIG).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Move all the PSA crypto APIs using key handles
to use key identifiers but psa_key_open() and
psa_key_close(). This is done without modifying
any test as key handles and key identifiers are
now the same.
Update the library modules using PSA crypto APIs
to get rid of key handles.
Programs and unit tests are updated to not use
key handles in subsequent commits, not in this
one.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
Now that transparent drivers have an "import_key" entry point, the key
creation interfaces for transparent drivers and opaque drivers are
very similar. Unify the sections that describe their behavior,
including key validation and key size determination.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When importing a transparent key, the key needs to be not only
validated, but also possibly converted, if it is not already in the
canonical representation. So change the validate_key entry point to an
import_key entry point.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Without MBEDTLS_PSA_CRYPTO_CONFIG, PSA_WANT_xxx needs to be defined,
for the sake of code that calls the PSA API (TLS code, tests, sample
apps).
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When importing a key, the code that parses the input needs to
determine the key size ("bits" attribute). This is specific to import
since other key creation methods require the caller to supply a size.
Therefore, add an extra output parameter `bits` to the "import_key"
entry point for opaque drivers. Likewise, add a `bits` output
parameter to the "validate_key" entry point for transparent drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Proposed specification for conditional inclusion of cryptographic
mechanism through the PSA API in Mbed TLS.
The inclusion of a mechanism is based on a declaration of boolean
symbols by the application. There is a symbol for each key type or
parametrized key type constructor, and for each algorithm or
parametrized algorithm constructor.
This is work in progress, presented for a first design discussion.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
There is little point in leaving the order in which drivers are
considered unspecified. This gives flexibility to the implementation
for a process that is generally performed at build time, not in a
constrained environment. Having a well-defined order is especially
useful with fallback.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
It's ok if they map to the same function names and an error otherwise.
It's an error to have multiple opaque drivers for the same location.
If multiple transparent drivers apply, which one applies is unspecified.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
