search

ARM-software / psa-api

Documentation source and development of the PSA Certified API
https://arm-software.github.io/psa-api/
Other
59 stars 27 forks source link

DRAFT: Support for key wrapping #215

Open athoelke opened 2 months ago

athoelke commented 2 months ago

[Added 24/10/24] Superseded by #224 - which provides just the simplified key wrapping and unwrapping functionality. The wrapped-key format support will be represented in a later PR.

Building on the key formats in #207, this PR defines an API for wrapping and unwrapping keys.

The first attempt explores an approach which extends the psa_import_formatted_key() and psa_export_formatted_key() APIs, and adds a key wrapping key and algorithm to the process. The idea is that it could support wrapping keys using a general key-wrapping algorithm (such as AES-KW) with existing clear-text key formats, and wrapping keys in wrapped-key data formats, such as EncryptedPrivateKeyInfo.

I am publishing this as an initial draft to provoke discussion around the challenges and undecided issues with this approach, including the policy integration issue that affects import of formatted keys.

The first commit specific to this PR (not in #207) is https://github.com/ARM-software/psa-api/pull/215/commits/192eb55088b13b4b3bda07eff978762849b44d61

Fixes #50.

athoelke commented 2 months ago

This approach does not handle non-standard approaches for wrapping keys: e.g. using an application-specific format for key meta-data with a standard AEAD algorithm. Ideas for handling such scenarios:

  1. Left to the application: export the key data and drive AEAD from the application. This has the key material in plaintext (for a time) in the application memory.
  2. Handled as a custom wrapped-key format: the implementation has to provide built-in support for the application design.
  3. Use a different (or additional) Crypto API design. For example, add an input function to an AEAD multi-part operation that updates the operation with a formatted key.
athoelke commented 2 months ago

I think we need to identify a representative set of use cases to cover the important ways in which the API needs to support key wrapping. And ensure we consider agility for future key types (PAKE, PQC, etc.) as part of the process.

It may be that we need more than one API to handle standard wrapped-key formats that are self-describing (in terms of wrapping algorithm(s)); general purpose key wrapping algorithms (typically specialized AEAD algorithms); and applications that use AEAD algorithms to create non-standard key-wrapping schemes.

athoelke commented 1 month ago

I'm thinking about a change of plan here. See my comment in Issue #50.