- TF-M - lists.trustedfirmware.org

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

by Sherry Zhang

Hi Poppy, Question 2 and 3: In the PSA crypto spec, the Key derivation function section describes the steps to perform a key derivation. Also I think you can take the implementation of the key generation based on HUK on NXP platform as a reference at https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…. TFM_CRYPTO_KEY_ID_HUK defined in tfm_crypto_defs.h is a temp work before persistent key APIs support in general. It should be removed now. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)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<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. =====================================================================

4 years, 9 months

1
0
0 0

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

by Edward Yang

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(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:37 Please respond to Sherry Zhang <Sherry.Zhang2(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)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(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)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(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ 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. =====================================================================

4 years, 9 months

2
1
0 0

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

by Edward Yang

Hi Andrew, “built-in keys with a pre-defined key_id” ,I take this to mean that HUK is a built-in key with the pre-defined key_id TFM_CRYPTO_KEY_ID_HUK,which can be stored in OTP,EEPROM or embedded Flash of MCU. There is no ownership of these built-in keys,however,application persisten keys are created by an application,so application persisten keys are owned by relevant applications. Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn Andrew Thoelke via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2021/06/02 17:33 Please respond to Andrew Thoelke <Andrew.Thoelke(a)arm.com> To "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org>, nd <nd(a)arm.com> cc Subject Re: [TF-M] Questions about psa crypto persistent key Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste… . An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: They cannot be destroyed by an application They might be accessible to multiple applications They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We’ll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)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(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ 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 its attachment(s) 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. =====================================================================

4 years, 9 months

1
0
0 0

Technical Forum call - June 10

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, June 10, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 9 months

1
0
0 0

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

by Sherry Zhang

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(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Wednesday, June 2, 2021 1:30 PM To: tf-m(a)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<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. =====================================================================

4 years, 9 months

1
0
0 0

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

by Andrew Thoelke

Hi Poppy Wu, In the v1.0.0 PSA Crypto spec, key handles were removed, and keys are now always referred to by a key identifier. After creating a persistent key with a key_id specified by the application (by import, generation or derivation), the key can be used in a cryptographic operation by passing the key_id to the operation function. No key handles are needed anymore. See https://armmbed.github.io/mbed-crypto/html/api/keys/lifetimes.html#persiste…. An implementation can provide some built-in keys with a pre-defined key_id. Depending on the key attributes and policy, these can be used by an application in appropriate cryptographic operations. Built-in keys can behave differently to application persistent keys: * They cannot be destroyed by an application * They might be accessible to multiple applications * They might have different values in different applications The implementation should provide documentation on the expected use of any built-in keys. We'll need one of the TF-M team to comment on the expected use for TFM_CRYPTO_KEY_ID_HUK. Regards, Andrew Thoelke Andrew Thoelke Software Systems Architect | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 June 2021 06:30 To: tf-m(a)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<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. =====================================================================

4 years, 9 months

1
0
0 0

PEM format is enabled in crypto service by default

by Sherry Zhang

Hi, I want to talk about whether TFM should support the PEM key format in crypto operation. In the PSA crypto spec, it describes: ``` This specification supports a single format for each key type. Implementations may support other formats as long as the standard format is supported. ``` The PEM format is not the standard format described in the spec. However, in the tfm_mbedcrypto_config_default.h, the MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C is defined which leads to that PEM key format operation is enabled in TFM crypto service. In isolation level1, about more than 2000 bytes code is introduced by this feature: .ER_TFM_CODE 0x2a01c // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C enabled .ER_TFM_CODE 0x29848 // MBEDTLS_PEM_PARSE_C and the MBEDTLS_PEM_WRITE_C disabled Is it necessary to support the PEM format in the key operation in crypto service at the cost of more than 2000 bytes? Any comments on that? Regards, Sherry Zhang

4 years, 9 months

1
0
0 0

Questions about psa crypto persistent key

by Edward Yang

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. =====================================================================

4 years, 9 months

1
0
0 0

Re: [TF-M] Technical Forum call - May 27

by Anton Komlev

Hi, The agenda for the forum: 1. Linker script/scatter file templating (Ken Liu) 2. Discussion on Non-Secure Client ID update (David Wang). 3. AOB Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, May 19, 2021 6:21 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - May 27 Hi, The next Technical Forum is planned on Thursday, May 27 , 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 9 months

1
0
0 0

Re: [TF-M] Firmware update API - MCUboot update

by Andrew Thoelke

Hi Suresh, > I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. Are you suggesting that the software stack might look like this: Update client application | | Function call V MCUBoot user API Shim layer | | Function call V FWU API | | TF-M psa_call() etc. V FWU Partition | | Function call V MCUBoot user API MCUBoot engine This looks like it has one more layer than it needs, as either: 1. The Update client application could Talk directly to the FWU API, or 2. The first MCUBoot user API could interact with an MCUBoot update partition (RoT Service), without having to tunnel the MCUBoot API over the FWU API. The latter might not be straightforward - I am not sure that anyone has reviewed the two APIs for this purpose. Are you only considering this software stack for a system where touching the update client application source code is not possible (needed for option #1 above)? - and you also cannot introduce a custom MCUBoot RoT Service partition (option #2 above) so you want to reuse TF-M's existing FWU API and partition? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: 25 May 2021 02:37 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Firmware update API - MCUboot update Hi Sherry, Thanks for the info. Wondering if there is some documentation or powerpoint explaining how the MCUBoot is changed to accommodate the FWU API. Details that would help: 1. How the MCUboot works without the FWU API - natively 2. How the MCUBoot needs to be modified to leverage from FWU API 3. What components are retained in MCUBoot ex: image format, signing, metadata, tools I am of the belief that MCUboot will be a very thin shim layer over the FWU API to provide the compatibility interface to legacy software and most of the work that was done earlier in MCUboot is pushed down into the FWU partition. The other way to look at it is: If somebody wants to replace MCUboot with a simple BL to integrate it tightly into TFM, what would that look like? thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Thursday, May 13, 2021 7:51 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The MCUboot update functionality is about validating the existing images on the device which is different from that of the firmware update service which follows mostly with the PSA Firmware Update API spec<https://developer.arm.com/documentation/ihi0093/latest/>. We designed a shim layer between the firmware update partition and bootloader. A specific bootloader can be ported into the firmware update partition via that shim layer. Please refer to the firmware update service document<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…>. In the MCUboot based shim layer implementation, it calls some user/public APIs provided by MCUboot to achieve its functionality. For example, the Firmware Update API spec describes that psa_fwu_install() API should validate the image or defer the validation to a system reboot. In the MCUboot shim layer implementation, it calls the boot_write_magic() API to mark the image as a candidate image for MCUboot and defers the image validation to a system reboot. Please refer to this link<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>. Can you please provide more specific suggestion or questions? Regards, Sherry Zhang From: Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com> <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>> Sent: Thursday, May 13, 2021 11:40 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Hi Sherry, Please take a closer look at the MCUboot and TFM might want to have a clear position/distinction between these two and how to transition from MCUboot update to this mechanism or it could be that they complement each other. thanks Suresh Marisetty Infineon Semiconductor Corporation From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Wednesday, May 12, 2021 8:55 PM To: Marisetty Suresh (CYSC CSS ICW SW SSE) <Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: Firmware update API - MCUboot update Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Firmware update API - MCUboot update Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 9 months

2
1
0 0

Re: [TF-M] Firmware update API - MCUboot update

by Sherry Zhang

Hi Suresh, The firmware update service APIs are for updating the firmware. The functionalities of these APIs includes loading the image into its target device(flash), verifying the image and installing it and so on. The user can call the these APIs to achieve update images. For example, in the integration of TF-M and the FreeRTOS OTA<https://github.com/Linaro/amazon-freertos/blob/tfm-fwu/libraries/abstractio…>, the OTA agent calls the firmware update service APIs to achieve an image update remotely. I guess that the "MCUboot update services" you mentioned refers to the functionality of MCUboot which acts as a bootloader. As a bootloader, it can verify the image which already exists on the device and chose the right image to start up. But it cannot, for example, load the image into device or control the image update process. The firmware update partition calls some user APIs provided by MCUboot to cooperate with it. You can refer to https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/techn…. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Thursday, May 13, 2021 11:09 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Firmware update API - MCUboot update Hi, I would like to see if there is any guidance/documentation on how to coordinate between the firmware update services API with that of MCUboot. Does the use of this API make the MCUboot update services redundant? thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 9 months

2
4
0 0

Re: [TF-M] A question on tfm its filesystem

by David Hu

Hi Poppy, SPRT requires the shared library shall not own static R/W data. ITS filesystem may not satisfy this requirement. Usually, a SP, for example Protected Storage, can rely on ITS service to access data in non-volatile memory. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Monday, May 24, 2021 12:54 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on tfm its filesystem Hi, I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm. Therefore,besides its partition, other extra secure partitions can also make use of this filesystem. 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 its attachment(s) 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. =====================================================================

4 years, 9 months

2
2
0 0

Wiki page sorting out

by Ken Liu

Hi, There are some out of sync contents in the wiki page (mainly the design chapter), which needs to be cleaned a bit. https://developer.trustedfirmware.org/w/tf_m/ As the first step, the following article would be removed (Would move to a recyclable place at first): Cooperative Scheduling Rules - content out of date. Non-Secure Interrupt Handling - covered in the design document. Secure Partition Interrupt Handling - covered in the interrupt handling document. Service IPC compatibility - Attestation - low priority, no need to be a standalone item. Service IPC compatibility - SST - same as above. Trusted Firmware-m Isolation Level 2 - covered by document 'FF-M isolation'. Uniform Secure Service Signature - out of date, as most of related files are changed. Any comments please feel free to ping me. Would do this on Thursday (27th May) this week. Thanks. /Ken

4 years, 9 months

1
0
0 0

A question on tfm its filesystem

by Edward Yang

Hi, I'd like to ask a question to see if the filesystem part of tf-m its partition can be moved to lib/sprt folder,to make this filesystem a shared library for PRoT part of tfm. Therefore,besides its partition, other extra secure partitions can also make use of this filesystem. 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 its attachment(s) 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. =====================================================================

4 years, 9 months

1
0
0 0

Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent

by Gyorgy Szing

Hi, Just a guess, but the "UNINIT" attribute described here [1] might be the one you are looking for. [1] https://developer.arm.com/documentation/100070/0612/scatter-file-syntax/exe… /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 21 May 2021 03:22 To: Suresh.Marisetty(a)infineon.com; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Hi Suresh, Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo… I believe they can provide a more comprehensive answer. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, May 21, 2021 12:13 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 10 months

1
0
0 0

Re: [TF-M] A question on Arm linker - GCC NOLOAD equivalent

by David Hu

Hi Suresh, Could you please forward the question to Arm complier forum (https://community.arm.com/developer/tools-software/tools/f/arm-compilers-fo… I believe they can provide a more comprehensive answer. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Suresh Marisetty via TF-M Sent: Friday, May 21, 2021 12:13 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] A question on Arm linker - GCC NOLOAD equivalent Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 10 months

1
0
0 0

A question on Arm linker - GCC NOLOAD equivalent

by Suresh.Marisetty＠infineon.com

Wondering if anybody can answer this (may not be the right forum): >>I need the equivalent of the gcc NOLOAD attribute with armlink linker thanks Suresh Marisetty Infineon Semiconductor Corporation Lead Member of Technical Staff CYSC CSS ICW SW SSE Mobile: +5103863997 Suresh.Marisetty(a)infineon.com<mailto:Suresh.Marisetty@infineon.com>

4 years, 10 months

1
0
0 0

Tentative future TF-M release dates

by Shebu Varghese Kuriakose

Hi All, As many might know, TF-M is now making release tags around every 4 months as defined here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…>. In order to help contributors and users of Trusted Firmware-M releases, the code freeze and release dates of the next 2 releases are published here<https://ci-builds.trustedfirmware.org/static-files/TZFdL484qZZgYcbWIGLS09zb…> (TF-M -> Docs -> Future release plans) Note that these dates are tentative and can shift if issues are identified leading upto the release. Regards, Shebu

4 years, 10 months

1
0
0 0

Technical Forum call - May 27

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, May 27 , 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 10 months

1
0
0 0

CMSIS_5 pack cloning issue in old TF-M version

by Anton Komlev

Hi, Some of you using TF-M v1.0 or earlier may have experienced build failures recently because of the CMSIS_5 repo git-lfs quota. To avoid this issue, it is recommended to either update to the latest TF-M version or to manually download the CMSIS_5 pack without using git-lfs. TF-M only uses a small part of the CMSIS_5 pack for testing purposes. To avoid cloning the entire CMSIS_5 pack, TF-M has been using a forked copy of the required RTX libraries in the tf-m-tests repo since v1.1 so updating to any TF-M version including and after v1.1 is fine. Hope that helps, Anton K.

4 years, 10 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Tamas Ban

Hi Poppy, There is no reference implementation for the case when only attest service can access to IAK, which is stored in on-chip flash. Attest code is part of PRoT code, they have the same privileged level. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 2021. május 18., kedd 6:07 To: David Wang <David.Wang(a)arm.com>; Raef Coles <Raef.Coles(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Factory provisioning with tf-m Hi Raef and David, Thanks for the detailed explanation. As I understand it,in the scenario without CC312 ,these keys(HUK,IAK,RoTPK) can be stored in secure-privileged area(using SAU and MPU) of embedded flash during factory provisioning,so these keys cannot be accessed by ARoT and non-secure code. But how to make IAK accessible only to the Initial Attestation Service？Is there any reference implementation? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn David Wang <David.Wang(a)arm.com<mailto:David.Wang@arm.com>> 2021/05/17 20:54 To "tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>, Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc nd <nd(a)arm.com<mailto:nd@arm.com>> Subject Re: [TF-M] Factory provisioning with tf-m Hi Poppy, One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document. And "To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service." In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 17 May 2021 16:50 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> Subject: Re: [TF-M] Factory provisioning with tf-m Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } 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 its attachment(s) 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(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by David Wang

Hi Poppy, One more thing about IAK, it's defined as one of the immutable PSA parameters in PSA security model document. And "To prevent cloning or spoofing, the IAK must be secret and accessible only to the Initial Attestation Service." In that case, for the product, you may need to consider how to ensure confidentiality/integrity and it's immutable based on the embedded flash solution. Regards, David Wang ARM Electronic Technology (Shanghai) Co., Ltd Phone: +86-21-6154 9142 (ext. 59142) ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Raef Coles via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 17 May 2021 16:50 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Edward Yang <EdwardYang(a)mxic.com.cn> Subject: Re: [TF-M] Factory provisioning with tf-m Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } 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 its attachment(s) 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(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 10 months

2
1
0 0

MbedTLS version updated to 2.26.0

by Maulik Patel

Hello All, TF-M has been updated to work with MbedTLS version 2.26.0. Best Regards Maulik Patel

4 years, 10 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Raef Coles

Hi Poppy. The current code we use for provisioning the CC312 OTP on the Musca reference platforms is under platform/ext/accelerator/cc312/cc312_provisioning.c, and the code for using keys from OTP is at platform/ext/target/musca_b1/sse_200/crypto_keys.c Note that because the Musca S1 has volatile OTP memory (I think it's a design choice that makes sense on a dev-board) a workaround is used, for the reference implementation it's best to look at the Musca B1. The basic flow is: * Build TF-M with -DCRYPTO_HW_ACCELERATOR_OTP_STATE=PROVISIONING, which will cause an ifdef in the bootloader to jump to the provisioning code instead of TF-M * TF-M then generates a 256 bit AES HUK and an ECC_P256 private key using the code in cc312_provisioning.c, and program these key into the OTP memory of the CC312 * Programming these keys into OTP causes the lifecycle state to be changed, so a reboot is needed between programming the keys to allow the new LCS to be used * The board is now provisioned - building TF-M with * -DCRYPTO_HW_ACCELERATOR_OTP_STATE=ON will cause TF-M to use the HUK, IAK and ROTPK from OTP, and will derive the SST/PS keys from the HUK on boot The general idea is that a platform can provide it's own implementation of the platform/ext/common/template/crypto_keys.c file, which could then load the keys from wherever they've been provisioned. I'd say it's reasonable to program keys into any NV storage region that is internal to the chip itself (and hence safe from tampering), which would include embedded flash. You'd then just need to load that data from flash in crypto_keys.c. Note that it would also be necessary to prevent secure partitions / non-secure code from directly accessing the flash where the keys are stored, probably by using an mpc/ppc to make it only accessible by secure-privileged code. Let me know if you have any other questions about the current CC312 provisioning flow. Raef ________________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Edward Yang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 14 May 2021 10:04 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } 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 its attachment(s) 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. =====================================================================

4 years, 10 months

1
0
0 0

Re: [TF-M] Factory provisioning with tf-m

by Edward Yang

Hi Shebu, Thanks for your reply.I would like to know is there any reference usage example of tf-m available now? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Http: //www.mxic.com.cn ----- Forwarded by Edward Yang/CHINA/MXIC on 2021/05/17 11:56 ----- Shebu Varghese Kuriakose <Shebu.VargheseKuriakose(a)arm.com> 2021/05/15 01:19 To Edward Yang <EdwardYang(a)mxic.com.cn>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> cc nd <nd(a)arm.com> Subject RE: [TF-M] Factory provisioning with tf-m Hi Poppy, In the roadmap, provisioning service is noted incase there is any standard provisioning mechanism that PSA defines in future. There is no plans around provisioning at this point. It is upto the platform to generate the keys and provision it securely on the device which TF-M can make use of. On Arm reference platforms, MuscaB1 and MuscaS1, the HUK, IAK are generated in Cryptocell-312. HUK, IAK private keys and ROTPK are provisioned in the OTP of CC-312. The hardcoding of keys in TF-M is just for development purposes and not to be used in production environment. Provisioning the attestation key in the secure region of the embedded flash might be acceptable. Experts in the list can comment. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: Friday, May 14, 2021 10:04 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Factory provisioning with tf-m Hi, I would like to know about how to use tf-m with factory provisioning,for example,HUK,IAK,ROTPK these ROT assets should be injected to device via factory provisioning,besides,application specific certificates and private keys can also be injected during this procedure,in tf-m roadmap,there is a provision service,what's the functionality of this service? In initial attestation service, attest_register_initial_attestation_key() calls tfm_plat_get_symmetric_iak() to get IAK, I found implementation template of tfm_plat_get_symmetric_iak() just copys hardcoded key value(for developer mode). I think this is not allowed in production mode.Is there any recommended implementation of this API? What if I stored IAK in a specific address of MCU embedded flash during factory provisioning, such as #define IAK_REGION IAK_base_addr in flash_layout.h,and then use flash.read get the key value？ tfm_plat_get_symmetric_iak( ) { TFM_HAL_ITS_FLASH_DRIVER.ReadData(IAK_REGION, buff, size); } 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 its attachment(s) 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. ===================================================================== ============================================================================ 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. =====================================================================

4 years, 10 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M