[nrf noup] Add built-in key support to psa_copy_key #32
Conversation
tomi-font
left a comment
tomi-font
left a comment
There was a problem hiding this comment.
FYI: ARM-software/psa-api#261
It's not yet implemented in Mbed TLS but will it cover your use case?
Interesting, thanks! It's hard to say. As far as I can see, |
|
I'll let @frkv have a look as he's more involved (and opinionated) with this. |
|
Just a generic comment. Attaching keys leads to much more memory management, which is seen as a negative. We are talking about a generic routing of calls with keys, which are supposed to be owned by a certain component in the system (here it is implemented as a driver) The topic of domain ownership as well as driver support is raised in the ongoing effort to standardize the PSA crypto driver API (multiple vendors cooperating with Arm). We have expressed a wish from Nordics side to make it possible to map e.g. a storage location (in lifetime) to a fully opaque PSA crypto driver. If this is supported it is easy to handle generic keys without complex key ID mapping. We will discuss relevant topics offline with @57300 on the follow-through on this, as there is an expectancy that the driver API will change due to driver spec standardization.... |
If the target key ID is in the built-in range, then creation of the key should be handled by a driver. Otherwise, there's no way for the key to be persisted. I don't know if this is acceptable upstream, since Mbed TLS and Oberon openly state that they don't support creating built-in keys through the PSA Crypto API, even though there are ways around this limitation. At first, out of abundance of caution, this change will only be applied for a single platform: Haltium (nRF54H, nRF92). Signed-off-by: Grzegorz Swiderski <[email protected]>
57300
force-pushed
the
copy_builtin_key
branch
from
e7f3c3b to
5feb2cf
Compare
tomi-font
left a comment
tomi-font
left a comment
There was a problem hiding this comment.
Maybe add the ref at the bottom of the commit message?
frkv
left a comment
frkv
left a comment
There was a problem hiding this comment.
LGTM
(Note that this pattern will be nRF54H-specific as nRF54L devices classify KMU keys as external meaning copying is disallowed already)
4 participants
If the target key ID is in the built-in range, then creation of the key should be handled by a driver. Otherwise, there's no way for the key to be persisted.
I don't know if this is acceptable upstream, since Mbed TLS and Oberon openly state that they don't support creating built-in keys through the PSA Crypto API, even though there are ways around this limitation.
manifest-pr-skip