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>
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>
The driver interfaces described in crypto_accel_driver.h and
crypto_entropy_driver.h are no longer being worked on. We do not
intend to finish the design of these interfaces or to implement them
in Mbed TLS. They have been superseded by the unified driver
interface (docs/proposed/psa-driver-interface.md), which is being
actively worked on both to finalize the specification and to implement
it in Mbed TLS.
The partially implemented dynamic secure element interface is staying
for now.
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>
* Stores bits in psa_persistent_key_storage_format.
* psa_load_persistent_key_into_slot still imports plaintext keys which
ensures that the bits value gets set.
* Updates key specification to match new implementation.
* Expands persistent store and load tests with to check for bits
attribute.
* Removes bits storage from psa_se_key_data_storage_t.
Signed-off-by: Torstein Nesse <torstein.nesse@silabs.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>
