The methods to import and generate a key in a secure element drivers
were written for an earlier version of the application-side interface.
Now that there is a psa_key_attributes_t structure that combines all
key metadata including its lifetime (location), type, size, policy and
extra type-specific data (domain parameters), pass that to drivers
instead of separate arguments for each piece of metadata. This makes
the interface less cluttered.
Update parameter names and descriptions to follow general conventions.
Document the public-key output on key generation more precisely.
Explain that it is optional in a driver, and when a driver would
implement it. Declare that it is optional in the core, too (which
means that a crypto core might not support drivers for secure elements
that do need this feature).
Update the implementation and the tests accordingly.
Register an existing key in a secure element.
Minimal implementation that doesn't call any driver method and just
lets the application declare whatever it wants.
Pass the key creation method (import/generate/derive/copy) to the
driver methods to allocate or validate a slot number. This allows
drivers to enforce policies such as "this key slot can only be used
for keys generated inside the secure element".
Add a slot_number field to psa_key_attributes_t and getter/setter
functions. Since slot numbers can have the value 0, indicate the
presence of the field via a separate flag.
In psa_get_key_attributes(), report the slot number if the key is in a
secure element.
When creating a key, for now, applications cannot choose a slot
number. A subsequent commit will add this capability in the secure
element HAL.
Add a parameter to the key import method of a secure element driver to
make it report the key size in bits. This is necessary (otherwise the
core has no idea what the bit-size is), and making import report it is
easier than adding a separate method (for other key creation methods,
this information is an input, not an output).
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.
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.
generate_key is a more classical name. The longer name was only
introduced to avoid confusion with getting a key from a generator,
which is key derivation, but we no longer use the generator
terminology so this reason no longer applies.
perl -i -pe 's/psa_generate_random_key/psa_generate_key/g' $(git ls-files)
“Tampering detected” was misleading because in the real world it can
also arise due to a software bug. “Corruption detected” is neutral and
more precisely reflects what can trigger the error.
perl -i -pe 's/PSA_ERROR_TAMPERING_DETECTED/PSA_ERROR_CORRUPTION_DETECTED/gi' $(git ls-files)
Split crypto_driver.h into 4:
* crypto_driver_common.h for common definitions, not meant to be
included directly by driver code.
* crypto_accel_driver.h for drivers that work with transparent
key material.
* crypto_se_driver.h for drivers that work with opaque key
material.
* crypto_entropy_driver.h for drivers of entropy sources.
There is no code change in this commit, I only moved some code around.
2018-12-21 18:17:10 +01:00
Renamed from include/psa/crypto_driver.h (Browse further)
