Secure element support is not yet usable in the real world. Only part
of the feature is implemented and the part that's implemented is not
sufficient for real-world uses. A lot of error handling is missing,
and there are no tests.
This commit should be reverted once the feature has stabilized.
Run all functions that take a key handle as input with a key that is
in a secure element. All calls are expected to error out one way or
another (not permitted by policy, invalid key type, method not
implemented in the secure element, ...). The goal of this test is to
ensure that nothing bad happens (e.g. invalid pointer dereference).
Run with various key types and algorithms to get good coverage.
Introduce a new function psa_get_transparent_key which returns
NOT_SUPPORTED if the key is in a secure element. Use this function in
functions that don't support keys in a secure element.
After this commit, all functions that access a key slot directly via
psa_get_key_slot or psa_get_key_from_slot rather than via
psa_get_transparent_key have at least enough support for secure
elements not to crash or otherwise cause undefined behavior. Lesser
bad behavior such as wrong results or resource leakage is still
possible in error cases.
Update the storage architecture with the new features introduced for
secure element support:
* Lifetime field in key files.
* Slot number in key files for keys in a secure element.
* Transaction file (name and format).
* Persistent storage for secure element drivers (name and format).
The version number is not determined yet.
Stored keys must contain lifetime information. The lifetime used to be
implied by the location of the key, back when applications supplied
the lifetime value when opening the key. Now that all keys' metadata
are stored in a central location, this location needs to store the
lifetime explicitly.
Pass information via a key attribute structure rather than as separate
parameters to psa_crypto_storage functions. This makes it easier to
maintain the code when the metadata of a key evolves.
This has negligible impact on code size (+4B with "gcc -Os" on x86_64).
Key creation and key destruction for a key in a secure element both
require updating three pieces of data: the key data in the secure
element, the key metadata in internal storage, and the SE driver's
persistent data. Perform these actions in a transaction so that
recovery is possible if the action is interrupted midway.
Implement a transaction record that can be used for actions that
modify more than one piece of persistent data (whether in the
persistent storage or elsewhere such as in a secure element).
While performing a transaction, the transaction file is present in
storage. If the system starts with an ongoing transaction, it must
complete the transaction (not implemented yet).
Most driver methods are not allowed to modify the persistent data, so
the driver context structure contains a const pointer to it. Pass a
non-const pointer to the persstent data to the driver methods that
need it: init, allocate, destroy.
Pass the driver context to all driver methods except the ones that
operate on an already-setup operation context.
Rename `p_context` arguments to `op_context` to avoid confusion
between contexts.
This slightly increases storage requirements, but works in more use
cases. In particular, it allows drivers to treat choose slot numbers
with a monotonic counter that is incremented each time a key is
created, without worrying about overflow in practice.
When creating a key with a lifetime that places it in a secure
element, retrieve the appropriate driver table entry.
This commit doesn't yet achieve behavior: so far the code only
retrieves the driver, it doesn't call the driver.
Instead of having one giant table containing all possible methods,
represent a driver's method table as a structure containing pointers
to substructures. This way a driver that doesn't implement a certain
class of operations can use NULL for this class as a whole instead of
storing NULL for each method.
Expose the type of an entry in the SE driver table as an opaque type
to other library modules. Soon, driver table entries will have state,
and callers will need to be able to access this state through
functions using this opaque type.
Provide functions to look up a driver by its lifetime and to retrieve
the method table from an entry.
