Allow transparent drivers to have custom key representations

[gilles-peskine-arm]

Background

Currently, the same key representation format is used when importing or exporting a key through the crypto API (psa_import_key(), psa_export_key(), psa_export_public_key()), and when passing or obtaining a key from a transparent driver (key input to all transparent driver entry points, and output from "export_key" ). There is no specification of the storage format for transparent keys, but using the same representation in storage is a very natural choice, since the key has to be converted from the storage representation to the standard representation every time it is loaded.

The rationale here was simplicity: mandating the same format meant that we didn't have to worry about converting between different representations. If a driver wants to convert from the standard representation to a more efficient representation, it can keep this more efficient representation fully proprietary, and just do the conversion internally. This has the downside that the driver needs to perform the conversion each time it's called, which can be a performance bottleneck. But so far we didn't have a business case where it was a performance bottleneck.

Business case

Arm now has a business case where we have a persistent key and we need to verify a signature (and possibly in the future make a signature) with a tight performance deadline. This happens during boot, so there is no way to amortize the performance with a cache: we need the first use of the key after power-up to be fast. As a consequence, we would like to store the key in its optimized representation, and to pass this optimized representation to the relevant driver.

Proposal overview

I propose to allow transparent drivers to define a custom key format. This is optional: by default, the transparent key format is identical to the export format.

• All entry points that consume a key will receive this custom format as input.
• All entry points that create a key will produce this format as output.
• This entails a change to the "import_key" entry point. Currently, this entry point is about custom import formats, for example allowing a driver to support compressed points when importing ECC public keys on a Weierstrass curve. It is limited to asymmetric keys since symmetric keys are simple byte strings that only have one straightforward representation. With this proposal, the "import_key" entry point would be generalized to potentially any key type.
• This entails a change to the "export_key" entry point since it will now be needed for all exports, to convert from the driver representation to the export format.

Limitations

It is currently technically possible to have multiple transparent drivers implementing different algorithms or different key sizes for the same key type. I am not aware of a business case for this, it's just an unintended bit of flexibility in the design. So I propose to allow only one transparent driver to claim support for each key type.

Design details

I haven't fully worked through the design. Some open questions:

• How will buffer sizes be conveyed?
• Should import and export each remain a single function, or should the standard format be an intermediate step when converting between the export representation and the driver representation?