- TF-M - lists.trustedfirmware.org

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

Hi, I have merged these patches so they took place now. For lv1 and lv2 users, they don’t need the linker script template any more. The next step is syncing lv3 with lv1/lv2. This change may miss verification on some platforms, please report the build & run issue if you have, thanks. BR /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, January 14, 2021 9:49 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation I think the link needs to be updated into: https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta… This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 9 months

1
0
0 0

Re: [TF-M] Musca-A platform deprecation announcement

by Thomas Törnblom

Hi Anton, The Musca-A is my first choice for testing new things with TF-M, mainly because that’s the simplest Arm board I have access to. What alternative do you recommend? Cheers, Thomas 18 jan. 2021 kl. 18:01 skrev Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>: Hello, I would like to propose the deprecation of Musca-A platform. With whole respect to the first HW platform supported TF-M, it became quite old and difficult to access. The current plan is to remove Musca-A from support and TF-M master code in the next release v1.3.0. Please reply to this mail until Feb 16 (in 4 weeks) having any objection for deprecation. Thanks and Best regards Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 9 months

2
1
0 0

Musca-A platform deprecation announcement

by Anton Komlev

Hello, I would like to propose the deprecation of Musca-A platform. With whole respect to the first HW platform supported TF-M, it became quite old and difficult to access. The current plan is to remove Musca-A from support and TF-M master code in the next release v1.3.0. Please reply to this mail until Feb 16 (in 4 weeks) having any objection for deprecation. Thanks and Best regards Anton Komlev

4 years, 9 months

1
0
0 0

Review on Firmware Update service in TF-M

by Sherry Zhang

Hi, I created the patchset of adding the Firmware Update service in TF-M feature branch. I would like to ask you to review this patchset if you are interested in it. Top of the patchset: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7883 Regards, Sherry Zhang

4 years, 9 months

1
0
0 0

Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Andrew Thoelke

Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to arm.psa-feedback(a)arm.com, or discuss the proposals here in the TF-M mailing list. Regards, Andrew

4 years, 9 months

1
0
0 0

Re: [TF-M] Technical Forum call - Jan 7

by Kevin Peng

I'd like give a proposal on how to manage the version of tf-m-tests repo in auto-download mode of the build system. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, January 4, 2021 5:33 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - Jan 7 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<mailto:tf-m-bounces@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<mailto:tf-m@lists.trustedfirmware.org>> Cc: nd <nd(a)arm.com<mailto:nd@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

4 years, 9 months

2
3
0 0

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

I think the link needs to be updated into: https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta… This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 9 months

1
0
0 0

Technical Forum call - January 21

by Anton Komlev

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

[RFC] Static linker scripts for level 1 and 2 isolation

by Raef Coles

Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef

4 years, 9 months

1
0
0 0

[RFC] Variable naming refinement in manifest tool

by Kevin Peng

Hi all, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7817> to refine the variable naming in manifest tooling, specifically the "manifest.manifest" in templates. I'm changing it to "partition.manifest" which should be more accurate and easy understanding. Broadcasting here for anyone has out-of-tree templates. And any comments are welcome. Best Regards, Kevin

4 years, 9 months

1
0
0 0

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

by David Hu

Hi Antonio, Thanks a lot for reviewing the threat model and bringing up this topic. To fully mitigate the threat you mentioned, NSPE shall enforce NS tasks isolation and assign/manage NS identifications. IMHO, It mainly relies on non-secure side implementation. Therefore that threat can be covered in the scope of another threat model against NS side. TF-M is trying to figure out how to assist NSPE to manage and transfer NS identifications. Any suggestion or comment is welcome and helpful! 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M Sent: Wednesday, December 30, 2020 7:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M generic threat model 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/

4 years, 10 months

2
2
0 0

Re: [TF-M] Technical Forum call - Jan 7

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

4 years, 10 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

4 years, 10 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

4 years, 10 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/

4 years, 10 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

4 years, 10 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

4 years, 10 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

4 years, 10 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. =====================================================================

4 years, 10 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

4 years, 10 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. =====================================================================

4 years, 10 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. =====================================================================

4 years, 10 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

4 years, 10 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

4 years, 10 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. =====================================================================

4 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M