April 2022 - TF-M - lists.trustedfirmware.org

Re: [TF-M] Supporting encryption with ITS

by Sherry Zhang

Hi George, The ITS without encryption is not a compromised RoT. In the PSA Secure Storage API spec, the PSA Internal Trust Storage aims at providing a place for devices to store their most intimate secrets. Also “””””””””””””””””””” 1. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from read and modification by attackers with physical access to the device. 2. The storage underlying the PSA Internal Trusted Storage Service MUST be protected from direct read or write access from software partitions outside of the PSA Root of Trust (PRoT). “””””””””””””””””””” So, for internal trusted storage service, it requires the underlying storage itself should provide being read or write protection. The storage area should be a “trusted” area. Does the storage area on your device meet this requirement? Is the memory physically isolated? If not, I wonder why not uses the Protected Storage service instead? For the design of adding encryption in ITS, in the PS partition, the `iv` and the encrypted object data are stored with the object file while the tag of each object is stored with the object table file. So, if encrypt the PS object in the ITS file system, how the PS partition get the `tag` of each object? After a rough thought, I think probably a standalone encryption for ITS is more reasonable. As this is a relatively “big topic”, would you like to hold a discussion on the TF-M Tech forum if it is not limited by confidential information? The next Tech forum will be hold on this Thursday 3:00 PM UTC time. Regards, Sherry Zhang From: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Sent: Friday, September 24, 2021 8:52 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] Supporting encryption with ITS Hello Sherry, Thank you for your input! 1. Our threat model is more concerned about attacks which can happen very early in the boot process, I think. A completely compromised RoT is not in our threat model. 2. I see that, ITS is supposed to store small objects. The storage overhead of adding encryption will be probably bigger than 20 bytes I think but the intention is to have this only as a configuration, not as the default option. 3. Agreed, a HAL API should be used for this. Do you have any opinion on the design of it? Do you think that it adds value to do try to use a common design for the object handling of both PS and ITS or is it better to have it as a standalone thing for the ITS. Regards, George ________________________________ From: Sherry Zhang <Sherry.Zhang2(a)arm.com<mailto:Sherry.Zhang2@arm.com>> Sent: Friday, September 24, 2021 11:58 AM To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@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: RE: [TF-M] Supporting encryption with ITS Hi George, Some comments from my side: 1. Internal trusted storage is part of the Root of Trust domain. If ITS storage device is attacked, then the code flash where the PSA Rot SP locates may also be attacked. Does the thread model of your system require the encryption in ITS? 2. The ITS service is intended to be used to interface to a small piece of storage. Encryption would increase the context for each ITS file. For example, similarly to PS object context, the `IV` which is used in encryption as well as the generated `tag` should be added into each file context. They total together can be about more than 20 bytes. 3. If the encryption is mandatory/ necessary required by the thread model of your system, as discussed, the PSA crypto service should not be called to avoid the circular. I think a HAL API for encryption may be created in ITS for platform implementation defined encryption/decryption. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Thursday, September 23, 2021 10:47 PM To: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>>; Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hey Gyorgy, These are very valuable comments! I am aware of the circular dependency issue because the PSA apis are using the ITS as a storage backend. This, as you said, can be circumvented by using a software crypto library or an implementation specific API. So, for the encryption a flexible API can be used which can allow externals to use their own function calls. Regarding the key storage, this is what I had in mind as well, using derived keys from the HUK. So that we don't need to store anything but the crypto metadata. Adding another layer of storage will raise more issues, I think. ________________________________ From: Gyorgy Szing <Gyorgy.Szing(a)arm.com<mailto:Gyorgy.Szing@arm.com>> Sent: Thursday, September 23, 2021 4:30 PM To: Fabian Schmidt <fabian.schmidt(a)nxp.com<mailto:fabian.schmidt@nxp.com>>; Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: RE: [TF-M] Supporting encryption with ITS Hi, AFAIK the main reason for ITS not using encryption is the problem of circular dependency. ITS is used by crypto SP for key storage, so how will crypto fetch the key from ITS to decrypt ITS? You could use a software crypto implementation (another mbed-tls instance) in ITS, but where would you safely store the keys? If you have a two layer ITS, one for only storing the keys for the second instance, and a second, encrypted one, then you end up with something like ITS and PS. You may not need a full blown on-chip FLASH device for ITS. If you have a HUK available, you can derive the same SP specific keys from that at each boot, and store these in RAM backed ITS. You won’t be able to store other keys in ITS in a persistent way of course, but for that you can use PS. Well, something along these lines. Perhaps the TF-M team could help better if you could share some details on why your customer would need encrypted ITS. (A PSA for Cortex-A (TS) maintainer chiming in to a “not his business” discussion here 😉 ) /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Fabian Schmidt via TF-M Sent: September 23, 2021 15:51 To: Vasilakis, Georgios <georgios.vasilakis(a)nordicsemi.no<mailto:georgios.vasilakis@nordicsemi.no>> Cc: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] Supporting encryption with ITS Hi George, I’m wondering if that would add value. To my understanding, ITS was never designed to be encrypted because of the way it’s supposed to be set up. (It’s Internal Trusted Storage.) I believe best practice is to place it in a “trusted” location, one that is ideally only accessible from Secure world, and also ideally on-die. If you then restrict outside access to the internal flash (JTAG, flash programmer ports,…), you’re pretty golden, in that no unauthorized party should be able to read from or write to the ITS.* Let me know if I misunderstand anything about ITS or TrustZone, but that’s my view. Maybe I’m painting an idealized picture. Greetings, Fabian Schmidt * at least short of a sophisticated physical attack or finding some loophole in TrustZone… From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [EXT] [TF-M] Supporting encryption with ITS Caution: EXT Email Hey all, Lately the requirement for an encrypted ITS solution is being asked from our customers and I would like to have a discussion here on how we can design this in a reasonable way. The first thought that came to my mind was to add the functionality to the ITS flash-fs layer. This layer contains file metadata in the its_file_meta_t structure and it should be possible to expand this to include additional crypto metadata (conditionally). This seems to be the less invasive change to me, even though it will introduce some increased memory usage since supporting encryption will mean that we cannot read the data in chunks anymore, we will have to use static buffers. At the same time, I looked at the PS partition since I knew that it has support for encryption. I believe that some core concepts of both solutions have similarities even though the code is quite different. For example, a file in ITS is similar to an object in PS and the (linear) list of file metadata in ITS is similar to the concept of the object table in PS. So, I think that it should be possible to design some generic-enough APIs that we can use for both the ITS and PS. Even though this will require some major refactoring in both partitions, it will decrease the code of these services which will probably decrease maintenance later. What are your thoughts on this? Regards, George

1 year

6
16
0 0

Documentation improvements

by Anton Komlev

Hello, The project documentation will never be ideal and we are continuing improving it. Let me ask you for reply to this email with the pain points you have experienced or suggestions for improvements to be considered in this phase. Your direct contribution with docs articles will be much appreciated too. For example: TF-M debugging technics and experience would be very helpful. Thank you in advance, Anton

1 year, 1 month

3
3
0 0

Library fetching improvements

by Bohdan.Hunko＠infineon.com

Hi, Recently I have been adding some new libraries to my TFM project and what I always end up doing is: go to some existing file which fetches the library, copy code from there, paste it to my file, change few links, versions and names. It is a bit annoying to copy-paste that code each time, also it is hard to maintain (if pattern for fetching libraries changes) and also copy pasting might lead to some code not being updated. My proposal is to have a function that can be used to fetch a library. This way it will be easier to add new libraries and this change will make code cleaner. Please let me know your thoughts on this proposal. Regards Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 2 months

5
8
0 0

Automatically copy RAM_VECTORS when using ARMClang and IAR

by Bohdan.Hunko＠infineon.com

Hi, When poking around some startup files I have found interesting place related to RAM_VECTORS support CMSIS have __PROGRAM_START macro which is different for each compiler. For GCC it uses __cmsis_start, for ARMClang - __main and for IAR - __iar_program_start Basically each of the functions should copy several sections (.TFM_DATA for example) from FLASH to RAM and zero out some parts of RAM (for .TFM_BSS for example) In current implementation GCC __cmsis_start function also copies the vector table from FLASH to SRAM (if RAM_VECTORS are enabled) But ARMClang and IAR equivalents of that function (__main, __iar_program_start) does not seem to take care of copying vector table, so platforms startup should do that I wonder if there is a way to change linker script in a way which will make copying of vector table automatic (by compiler dependent function). This will make platform startups a bit cleaner and will allow platform to just use __PROGRAM_START macro without any additional code to copy vector table. From what I see IAR has "initialize by copy" syntaxis so I think it may be used to tell IAR to automatically copy vector table. It is a bit more tricky with ARMClang as I have not found a way to do that there. I am not a big expert in ARMClang and IAR so maybe someone may help me here, give some directions or confirm that currently there is no way to make this idea work. Basically the intention is to simplify platform startup code and offload common operations to compiler specific platform independent functions. Regards, Bohdan Hunko Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko(a)infineon.com<mailto:Bohdan.Hunko@infineon.com>

1 year, 2 months

2
5
0 0

TF-M v1.6.0 release

by Anton Komlev

Hello, I am pleased to announce the new v1.6.0 released of TF-M project. New major features are: * MCUboot updated to v1.9.0. * Mbed TLS updated to v3.1.0 (Support all required PSA Crypto APIs). * Enabled Secure Function (SFN) Model Partition compliance in IPC backend. * Interrupt support (both SLIH/FLIH) for the SFN backend. * MM-IOVEC Support for the SFN backend. * The following Secure Partitions are converted to SFN model: * Protected Storage * Internal Trusted Storage * Initial Attestation * FF-M v1.1 SFN Model supported in Profile Small. * HAL Separation of Library Model and IPC/SFN backend. * FP support for Armv8.1-M Mainline for IPC backend. * Simplified build output message and configurable output. * Halting instead of rebooting on panic in debug build type. * Automated testing of MCUboot BL2. * A new driver interface for the CC-312 runtime library as specified in the PSA Unified Driver spec [1]_. * Added reference bootloader stage 1 (BL1) bootloader for certain platforms. * A new CC312 ROM library for the BL1. * Updated documentation structure. The changes tagged by TF-Mv1.6.0 and located in the release/v1.6.x<https://review.trustedfirmware.org/q/project:TF-M%252Ftrusted-firmware-m+br…> branch at the moment. In short, they will be integrated with the main branch and be available from there. Thanks everyone for contribution, review and support this milestone. Anton

1 year, 4 months

1
0
0 0

Technical Forum call - April 28

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 28, 7:00-8:00 UTC (East 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

1 year, 4 months

1
1
0 0

Asking for review of external trusted secure storage partition implementation code

by Edward Yang

Hi everyone, We have discussed the design proposal of supporting secure Flash in tf-m framework via this mailing list before,now the implementation code of this external trusted secure storage partition has been uploaded to tf-m-extras repo for review： https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953 And the binary component of this patch has also been uploaded to tf-binaries repo： https://review.trustedfirmware.org/c/tf-binaries/+/14954 For easy understanding please refer to this document first: https://review.trustedfirmware.org/c/TF-M/tf-m-extras/+/14953/1/partitions/… Looking forward to your comments and suggestions. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

1 year, 4 months

1
0
0 0

Start of TF-M v1.6.0 release process

by Anton Komlev

Hello, The branch release/1.6.x<https://git.trustedfirmware.org/TF-M%2Ftrusted-firmware-m.git/log/?h=refs%2…> has been created, indicating the project feature's freeze and beginning the release process. Expecting to place RC1 tag asap, after successful run of the basic tests. Let me remind that the code is not frozen, and development can be continued on the main branch. Thanks, Anton

1 year, 5 months

1
4
0 0

TF-M Open CI Back to Normal

by Xinyu Zhang

Hi All, TF-M Open CI is back to normal now. Please feel free to use it. Thanks, Xinyu From: Xinyu Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Monday, April 18, 2022 12:06 PM To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] TF-M Open CI Down Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

1 year, 5 months

1
0
0 0

TF-M Open CI Down

by Xinyu Zhang

Hi All, Sorry to inform you that TF-M Open CI is down for the time being because of Jenkins upgrade. I'll let you know once it is back to normal. Apologize for any inconvenience! Thanks, Xinyu

1 year, 5 months

1
0
0 0

2023

2022

2021

2020

2019

2018

TF-M April 2022