Deriving ECC keys from HUK with TF-M

RE: Deriving ECC keys from HUK with TF-M

Oskar — Mon, 21 Nov 2022 15:16:52 GMT

Okay, that cleared it up! Thank you very much!

RE: Deriving ECC keys from HUK with TF-M

Hakon — Mon, 21 Nov 2022 14:39:58 GMT

[quote user="Oskar"]I am not sure if I understand why the derived bytes would not correspond to a private key. Why is this the case?[/quote]

The derived bytes command just returns you some random bytes. The ECC private keys depending on the curve will have some requirements. Meaning that you need to follow some characteristics, like for example that if you perform a scalar multiplication with the private ECC key and the base point of the curve then the result (public key) need to be a point inside the curve (defined by the algorithm that you choose). The important thing is that a random number may or may not be a private key, that's why we need the psa_import_key to confirm this.

[quote user="Oskar"]Another, perhaps unrelated question, is protected storage and the key psa_crypto interfaces experimental using NCS? this seems to indicate so, but I am not entirely sure what parts of TF-M that is considered experimental and not.[/quote]

Only the minimal profile of TF-M is in production stage. Everything else is experimental, the minimal profile doesn't have the protected storage AFAIK.

RE: Deriving ECC keys from HUK with TF-M

Oskar — Mon, 21 Nov 2022 07:31:06 GMT

I am not sure if I understand why the derived bytes would not correspond to a private key. Why is this the case?

To add a little context, this whole operation would be a part of a device provisioning on the assembly line.

Another possible solution for me could be to generate the ECC key, export the public key, then use the secondary, provisioned public key to generate a symmetric key and store that. Though it would be nice to keep the ECC key as well.

Perhaps it would be a good idea to store the key in the protected storage provided by TF-M.

Another, perhaps unrelated question, is protected storage and the key psa_crypto interfaces experimental using NCS? this seems to indicate so, but I am not entirely sure what parts of TF-M that is considered experimental and not.

And thanks for the note on the key usage, it feels a bit convoluted to figure out which parameters to set as of now.

RE: Deriving ECC keys from HUK with TF-M

Hakon — Fri, 18 Nov 2022 15:46:14 GMT

Hello,

Generating asymmetric keys using huk derivation directly is not currently supported. Ideally you can use the psa_generate_key to create a random private key. In case you necessarily wants the key to be derived from HUK then they can use the psa_key_derivation_output_bytes function and try to do a psa_import_key. The issue with this solution is that there is a chance that psa_import_key will fail since the derived bytes don't necessarily correspond to a private key. So the solution with HUK will have to try multiple calls of the psa_key_derivation_output_bytes until psa_import_key succeeds.

Also as a note, which is not relevant based on the answer above:

armmbed.github.io/.../kdf.html

Ths key_derivation_output_key does as attributes expects the new key attributes. So for example for an ECC key it will expect usage attributes such as: PSA_KEY_USAGE_SIGN_HASH