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>
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>
With PSA crypto v1.0.0, a volatile key identifier may
contain a owner identifier but no file is associated
to it. Thus rename the type psa_key_file_id_t to
mbedtls_svc_key_id_t to avoid a direct link with a
file when a key identifier involves an owner
identifier.
The new type name is prefixed by mbedtls to highlight
that the type is specific to Mbed TLS implementation
and not defined in the PSA Cryptography API
specification.
The svc in the type name stands for service as this
is the key identifier type from the point of view of
the service providing the Cryptography services.
The service can be completely provided by the present
library or partially in case of a multi-client service.
As a consequence rename as well:
. MBEDTLS_PSA_CRYPTO_KEY_FILE_ID_ENCODES_OWNER to
MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER
. PSA_KEY_ID_INIT to MBEDTLS_SVC_KEY_ID_INIT
. PSA_KEY_FILE_GET_KEY_ID to MBEDTLS_SVC_KEY_ID_GET_KEY_ID
. psa_key_file_id_make to mbedtls_svc_key_id_make
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
