- TF-M - lists.trustedfirmware.org

by David Hu

Hi Anton, I'd like to give a brief introduction to TF-M generic threat model. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, January 4, 2021 5:30 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Jan 7 Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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

5 years, 2 months

1
0
0 0

Technical Forum call - Jan 7

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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

5 years, 2 months

1
0
0 0

[RFC] Remove unused section 'TFM_UNPRIV_DATA'

by Ken Liu

Hi, The existing section 'TFM_UNPRIV_DATA' now holds nothing - it was designed for holding some data belong to the unprivileged code block, while now the unprivileged code is required as read-only and no place for its read-write data. Remove this section as it is unused; also remove those code objects exists in the unprivileged code section but has read-write data: 'platform_retarget_dev.o' and 'device_definition.o'. This patch changes some sources inside the platforms, so the platform owner please help to check if that matters: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7754 Thanks. /Ken

5 years, 2 months

1
1
0 0

Re: [TF-M] TF-M generic threat model

by Antonio Ken IANNILLO

Hi Hu, I read the threat model and I have a question regarding a potential threat. I’m not sure it should belong to this generic threat model or it is already included in one of those presented. The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem. Can this be considered a threat in this model or should it belong to another model/TOE? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 https://akiannillo.github.io/

5 years, 2 months

1
0
0 0

Re: [TF-M] RFC on changes to install directory structure

by Xinyu Zhang

Hi Raef, Please merge this patch for CI together with your patches. https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/7755 BR, Xinyu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Tuesday, December 29, 2020 7:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] RFC on changes to install directory structure Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

1
0
0 0

RFC on changes to install directory structure

by Raef Coles

Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef

5 years, 2 months

1
0
0 0

Changes to TF-M NS interface build

by David Hu

Hi all, Happy holiday! I'd like to let you know that non-secure interface build has been moved from TF-M to tf-m-tests in following patches: TF-M: https://review.trustedfirmware.org/q/topic:%22move-ns-api%22+(status:open%2… Tf-m-tests: https://review.trustedfirmware.org/q/topic:%22add-ns-api%22+(status:open%20… After that change, the .c files under TF-M interface/src are built during non-secure side build. It aligns with the actual process of NS integration with TF-M. Moreover, non-secure specific flags, which control TF-M NS interface, can be configured and managed in non-secure side build, without affecting TF-M secure part. Please modify tf-m-tests app/CMakeLists.txt for future changes to non-secure interface build. Thanks. Best regards, Hu Ziji

5 years, 2 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by David Hu

Hi Poppy, Some rough ideas about secure Flash support in TF-M. IMHO, there can be two options: 1. Based on ITS service Secure Flash acts as the flash driver at the backend of ITS service. The secure Flash driver can invoke Crypto secure service instead of mbedTLS to avoid building two duplicates of mbedTLS library. The cryptographic operation and key management are implemented in secure Flash driver and can be transparent to ITS service while some initialization can be necessary. But it cannot support persistent keys otherwise it will generate a circular dependency between ITS and Crypto services. 1. Based on PS service With PS service, the cryptographic operations can be implemented by PS crypto steps, such as encryption and authentication. Secure Flash driver only covers communication with remote device. We don’t have to worry about the circular dependency with Crypto service. However, there are some limitations of PS service currently: * PS service cannot support multiple asset keys for cryptography. * PS service cannot work alone without ITS service. Best regards, Hu Ziji 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 Sent: Monday, December 21, 2020 1:22 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Cc: Julien Su <juliensu(a)mxic.com.tw<mailto:juliensu@mxic.com.tw>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Aaron Zhu <AaronZhu(a)mxic.com.cn<mailto:AaronZhu@mxic.com.cn>>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Discuss how to support secure Flash in TF-M Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink<Notes://cnmail01/482583DD001E2E02/DABA975B9FB113EB852564B5001283EA/6BDCE39917970ADF4825863F00689523> Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc nd <nd(a)arm.com<mailto:nd@arm.com>>, "tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie 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 Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D91C.DAC89B20] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 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 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 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. =====================================================================

5 years, 2 months

1
0
0 0

Re: [TF-M] TF-M generic threat model

by David Hu

Hi all, I’d like to merge the generic threat model by the end of this week if no further comment. I’m also going to give a brief introduction to TF-M threat modeling in future technical forum. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, December 10, 2020 9:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M generic threat model Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

5 years, 2 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 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 ============================================================================ 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. =====================================================================

5 years, 2 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 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 ============================================================================ 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. =====================================================================

5 years, 3 months

2
1
0 0

[CANCELLED] TF-M Technical Forum - December 24

by Anton Komlev

Hello, Probably the next Technical Forum will not be very popular, planned on Thursday, Dec 24 (US friendly time zone). Let's cancel this slot to meet again in January 7. Wish you pleasant holidays and Happy New Year. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 3 months

1
0
0 0

Tiny update on the code review guidelines

by Ken Liu

Hi, The purpose of code review guidelines is trying to provide some reference for reviewers. It is still in the evaluation stage. After it gets matured then we can pointer to this document as a required reference. I updated some part of it, the main changes: - The private symbol (static inside a source file) can have a prefix for easier source viewing, a reader would know it is a symbol in the file he/she is viewing which can avoid cross-files 'find reference' operation in the editor. - Clarifies the header file types and the usage: A 'interface' header file is for abstraction, and a typical 'include' header contains exported functionalities for external module usage. Please help to take a look if you have time - as this is one of the upcoming updates, I will treat the review contents out of the changed lines into a new patch if it is possible. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7577 Thanks. /Ken

5 years, 3 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by Jamie Fox

Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D313.1B0E4E10] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 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 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. =====================================================================

5 years, 3 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 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. =====================================================================

5 years, 3 months

1
0
0 0

ITS and PS HALs pushed for review

by Jamie Fox

Hi all, I have pushed for review the new Internal Trusted Storage and Protected Storage HAL designs, as well as an initial implementation for AN521. I will update the change for all other platforms once the design has settled down. It expands the ITS and PS HALs to cover all flash and filesystem configuration parameters required from the platform. The CMSIS Flash Driver is exposed to abstract the flash device itself. ITS is updated to use the new HALs, with its_flash_info_external.c, its_flash_info_internal.c and its_flash.c removed. The ITS filesystem is updated to take a configuration struct as an initialisation parameter, which is filled using values from the HAL. The gerrit reviews are: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4781 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7598 Kind regards, Jamie

5 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

😉 No response got yet, as it is closing to Xmas, plan to merge them before end of this week (18th Dec) if there is no more voice. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, December 7, 2020 3:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Moving partition stack into partition BSS/ZI. Hi, We are now allocating partition’s stack inside linker script file, and there are two external patches trying to move these stack definitions into partition’s BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other – actually we don’t apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

5 years, 3 months

1
0
0 0

Proposal to fix the version of tf-m-tests for auto-downloading in build system

by Kevin Peng

Hi all, The build system currently fetches the latest "master" of tf-m-tests repo for building, if auto-download dependencies mode is used (which is the default). This would break the building when: * TF-M and tf-m-tests have dependency changes got merged * A developer is working with a local copy of TF-M that has not been updated to the latest. * The developer does a clean build with auto-downloading * The build system fetch the latest tf-m-tests repo which is not compatible with the local copy of TF-M We've seen this kind of issue reported in mailing list. To solve this problem, the proposal<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7550> of fixing the "TFM_TEST_REPO_VERSION" to a hash or tag is raised. With this change, the build system would download a compatible version always. The version of the test repo is not required to be updated for every commit in the test repo. (Guide line on when to update the version is required and it's still under discussion - welcome for ideas.) Developers want a different version can always override "TFM_TEST_REPO_PATH" to a local copy to build. Best Regards, Kevin

5 years, 3 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M + New path for Musca-B1 platform

by Mark Horvath

Dear All, The Secure Enclave patches have been merged and caused a minor source structure change. The platform so far named musca_b1 became musca_b1/sse_200, because we added support to the other subsystem on the Musca-B1 board, musca_b1/secure_enclave. So to build onto the old Musca-B1 platform the -DTFM_PLATFORM=musca_b1/sse_200 flag will be needed. All information about the Secure Enclave topic can be found in these rsts: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/desig… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 09 December 2020 10:11 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

5 years, 3 months

1
0
0 0

TF-M generic threat model

by David Hu

Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Anton Komlev

Hi All The agenda for the forum: 1. PSA FF-M v1.1 alpha specification overview. Do not miss it! 2. AOB Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: 09 December 2020 15:42 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - December 10 Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 02 December 2020 15:45 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M Technical Forum call - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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

5 years, 3 months

1
0
0 0

SW countermeasure against physical attacks in SPE

by Tamas Ban

Hi, PSA Level 3 certification mandates protection against physical attack at a certain extent. MCUboot v1.7.0 release already contains SW countermeasures against fault injection attacks. These can be used at device boot-up time. But fault injection attacks are not targeting only the device boot-up time, instead they could be applied against the runtime firmware. The following design proposal is addressing this threat: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Prototype implementation on AN521 and Musca-B1 target (top of the patch set): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7475/1 Review and comments are welcome! BR, Tamas Ban

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Andrew Thoelke

Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 02 December 2020 15:45 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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

5 years, 3 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

5 years, 3 months

1
0
0 0

TF-M openCI nightly notification mail list is ready to subscribe

by Karl Zhang

Hi, There is a CI notification mail list enabled, it aims to send the failure info of TF-M nightly job to the subscribers without spam to a big group. If you are interested in the master branch nightly verification status, feel free to add your email to the list. Subscribing: https://lists.trustedfirmware.org/mailman/listinfo/tf-m-ci-notifications The notification only triggers a notification when CI build or test fail occur from the nightly job. Thanks Karl

5 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M