-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add APIs to support wrapped keys #50
Comments
Some related internal discussions on the topic: |
An old proposal, which I don't have time to work on right now: ARMmbed/mbed-crypto#364 |
This link above are not working. They are probably to old and no more accessible for the public. |
@cneveux Indeed the |
Wrapping with a device-specific secret keyAn API proposed in Mbed-TLS/mbedtls#7910, enables the import of keys in other formats. As currently proposed, this only covers formats where the key material is in cleartext. However, if we add the equivalent This is sufficient for use cases that do not involve an application choice of algorithm or key-wrapping key. |
Wrapping using a standard algorithm and application-selected key-wrapping keyDefining an API for this use case is more challenging, as there are a lack of standards defining key-wrapping algorithms and formats for the wrapped material. However:
API proposalA simple API design could just implement the wrapping algorithm on data provided by the application. This requires that the application export the key material to the application and then encrypt it, exposing the key material within the application memory. In keeping with the design goals of the Crypto API, I would prefer to define an API that enabled the cleartext key material to be kept within a cryptoprocessor implementation, providing better assurance of the key confidentiality and integrity for application developers. Note that this improvement is a reduction in risk: the application is capable of decrypting the wrapped key as it knows the key and algorithm used to wrap it; but an attacker requires more than application-memory-read capability to disclose the key. Building on the format specifier additions for
Conceptually,
.. except that the cleartext is not visible to the application, and the format might be dictated by the wrapping algorithm. For For For both functions, the format of the key material must be compatible with the algorithm - for example, AES-KW requires cleartext that is An 'unspecified' key format, perhaps |
I now plan to progress this to a draft PR, given interest in finalizing this API for some implementors. Reviewing the proposal, I have a question about the parameter ordering for
Where the wrapping-key, wrap-algorithm, and intermediate-format-specifier are the control/operational inputs. This is the first true 2-key-input functions (compare with key agreement, which takes the peer key as a data buffer) However, this makes it look/read differently to APIs such as Is there a preference for one parameter order over the other? |
Thanks for promoting this PR! Regarding the signature: the parameter ordering of the original proposal above is consistent with the ordering in #149 for
(copied from above) |
Thank you for the feedback @oberon-sk. After some discussion with @gilles-peskine-arm, we think that we want to use the alternate ordering because (a) it treats the key-to-be-wrapped as an input parameter, and (b) it does not have two identically typed parameters next to each other which probably has a higher risk of key mis-ordering in application code. We could also tweak the function names to be a bit more like other cryptographic operations (and less like the key management functions), by using Also, following the development of the formatted key import and export functions, we probably (to be discussed) need to add export format options to key wrapping, and import policy options to key unwrapping. Might we also need the interactive policy construction described in this comment? I don't think we need to be able to wrap the public-key part of a key-pair, so we would not need a wrapping equivalent of So the updated proposed API would be something like:
|
Many secure elements and crypto accelerators require the use of wrapped keys and will not accept importing clear-text keys to their key store. The existing
psa_import_key
function could be augmented to support wrapped keys, but that puts the burden of identifying wrapping and associated parameters on the underlying implementation. A new function should be proposed to support wrapped key imports.As there is no standard for key wrapping data formats and associated algorithms, this should be made generic enough to be adaptable to any such key stores.
Same need for exporting wrapped keys.
The text was updated successfully, but these errors were encountered: