Hi Poppy Wu

 

> the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot?

Yes, this is a pointer to a HUK, provisioned in a secure memory region.

 

Best regards,

 

Andrej Butok

SW Tech Lead

Edge Processing

NXP Semiconductors

 

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent: Thursday, June 3, 2021 12:13 PM
To: tf-m@lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2@arm.com>
Subject: Re: [TF-M] Questions about psa crypto persistent key

 


Hi Sherry,

Thanks a lot for your reply,it's a big help.

So with current tf-m crypto service implementation,if I want to use psa_aead_encrypt() to do encryption with a persistent key which is provisioned before the reset,I need to use psa_open_key() as a temporary method.


Besides,the implementation of key derivation from HUK on NXP platform,I suppose in actual development ,the macro TFM_HUK_KEY_ADDR below may be a pointer to the shared HUK data(stored in secure RAM) from secure boot?

+#ifndef TFM_HUK_KEY_ADDR
+static const uint8_t sample_tfm_key[] =
+ {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, \
+ 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};
+
+#define TFM_HUK_KEY_ADDR sample_tfm_key
+#endif

status = psa_import_key(&attributes, (const uint8_t *)TFM_HUK_KEY_ADDR, TFM_HUK_KEY_LEN, &base_key);




Best Regards,
Poppy Wu


Macronix Microelectronics (Suzhou) Co.,Ltd
http://www.mxic.com.cn

Sherry Zhang via TF-M <tf-m@lists.trustedfirmware.org>
Sent by: "TF-M" <tf-m-bounces@lists.trustedfirmware.org>

2021/06/03 14:23

Please respond to
Sherry Zhang <Sherry.Zhang2@arm.com>

To

Edward Yang <EdwardYang@mxic.com.cn>, "tf-m@lists.trustedfirmware.org" <tf-m@lists.trustedfirmware.org>

cc

nd <nd@arm.com>

Subject

Re: [TF-M] Questions about psa crypto persistent key

 




Hi Poppy,
 
The updated PSA crypto spec supports calling psa_aead_encrypt to do encryption with a persistent key which is provisioned before the reset. But currently, the TF-M crypto service has not been updated to the updated PSA crypto spec version in which the psa_open_key is removed. Currently, in TFM, the persistent key should be opened by calling psa_open_key before using this key to do crypto operations which follows the older version of spec. The tfm_crypto_check_handle_owner() API is used for the isolation between the clients. When aligning to the new PSA crypto spec, the isolation implementation should be updated accordingly.
 
 
Regards,
Sherry Zhang
 
From: Edward Yang <EdwardYang@mxic.com.cn>
Sent:
Thursday, June 3, 2021 11:03 AM
To:
tf-m@lists.trustedfirmware.org; Sherry Zhang <Sherry.Zhang2@arm.com>
Subject:
Re: [TF-M] Questions about psa crypto persistent key

 

Hi Sherry,



Import persistent key with a specified key_id is indeed supported in the updated crypto spec..


I mean,if a key created by derivation functions,and this key is imported as a persistent key with s specific key id such as KEY_ID_EXAMPLE,then this key is stored in internal Flash with its service.


After the reset,this persistent key still exists,but this persisten key cannot be used to do encryption directly,for example,call psa_aead_encrypt(KEY_ID_EXAMPLE,alg,nonce,...),unless import this key with psa_import() once again.


Call psa_aead_encrypt(SSKEY_ID,alg,nonce,...) without calling psa_import_key() in advance is not allowed,because in tfm_crypto_check_handle_owner()(why this API is needed?)it will check this key_id with handle_owner[] array.


So I am wondering what's the intended use of persistent keys? After creation, this persistent keys can only be used to derive other encryption keys,rather than used to encrypt data with themselves?


Best Regards,
Poppy Wu

Macronix Microelectronics (Suzhou) Co.,Ltd

http://www.mxic.com.cn

Sherry Zhang via TF-M <tf-m@lists.trustedfirmware.org>
Sent by: "TF-M" <
tf-m-bounces@lists.trustedfirmware.org>

2021/06/02 17:37

 

Please respond to
Sherry Zhang <
Sherry.Zhang2@arm.com>

 

To

"tf-m@lists.trustedfirmware.org" <tf-m@lists.trustedfirmware.org>

cc

nd <nd@arm.com>

Subject

Re: [TF-M] Questions about psa crypto persistent key


 

 





Hi
Poppy,
 
Some feedback from my understanding on the first question.

 
1.        
Import persistent key with a key_id is still supported in the updated PSA crypto spec.
 
In the version of PSA crypto spec in which psa_open_key is supported, the persistent key can be opened after the reset with the key_id which is specified in the key attributes in key creation. This is not very friendly. The reason is that each time the user calls the psa_open_key, the crypto service loads the key material from slot to running area(ram or flash) thus a new associated resources is allocated. The application must eventually call psa_close_key to release the allocated associated resources. It can happen that multiple applications call psa_open_key multile times as they may do not know whether the key is opened by other applications. So it can happen that multiple copies of associated resources are allocated for the same key. This is not user friendly.

 
In the updated PSA crypto spec, the key material management strategy is changed. The user does not need to call the psa_open_key to load the key from slot to ram/flash. See the section of “9.4 Key identifies” of the spec:

```

Key identifiers are output from a successful call to one of the key creation functions. For persistent keys,

this is the same identifier as the one specified in the key attributes used to create the key. The key

indenter remains valid until it is invalidated by passing it to psa_destroy_key(). A volatile key identifier

must not be used after it has been invalidated.

```

             So I think the user can use the key_id directly to call crypto operations, such as
means encrypt, decrypt.
 
Regards,

Sherry Zhang

 
 
From:
TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M
Sent:
Wednesday, June 2, 2021 1:30 PM
To:
tf-m@lists.trustedfirmware.org
Subject:
[TF-M] Questions about psa crypto persistent key
 

Hi Experts,

I have some questions about crypto persisten keys.


1. psa_open_key() is removed in psa crypto spec,so it is impossible to import a persistent key into key slot with key_id,which means encrypt/decrypt data directly with a persistent key is not allowed,these persistent keys can only be

used to derive volatile keys which will be used for encryption/decryption, I am not sure if I understand correctly.


2. Besides,HUK can be used to derive the other crypto keys,such as ps crypto key.HUK may be stored in OTP area of MCU(without crypto element such as cc312),then what's intended flow to derive crypto keys from HUK via calling PSA crypto service?There is no reference implementation in tf-m code.  



tfm_plat_get_huk_derived_key(){


get HUK from OTP

   ||

   ||

   \/

how to derive crypto key from HUK with calling crypto service?

}



3. BTW,HUK has a persistent key id
TFM_CRYPTO_KEY_ID_HUK  defined in tfm_crypto_defs.h,but I haven't seen any reference to this macro. What's the intended use of this key id?And what's the key owner of HUK?


Best Regards,
Poppy Wu


Macronix Microelectronics (Suzhou) Co.,Ltd

http://www.mxic.com.cn

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=====================================================================--
TF-M mailing list
TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m--
TF-M mailing list
TF-M@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-m