October 2021 - 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

2 years, 3 months

6
16
0 0

[ATTENTION REQUIRED] Manifest Tool being aware of Secure Partition enabled status when building

by Kevin Peng

Hi, I worked out a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/12025> to make the Manifest Tool (tfm_parse_manifest_list.py) aware of the Secure Partition status when building. Currently, the tool generates everything and then the Build System picks up the files needed. With the development of FF-M 1.1 feature, we need the tool to be aware of the Secure Partition enabled status to generate SPM configurations. The patch make use of the feature of CMake command configure_file which substitutes variable values referenced as @VAR@ or ${VAR}. It requires the "conditional" attributes in manifest lists to be surrounded by "@" for "${}". Then when you disable some Partition for building, the tool will not generate anything for that Partition such as PID/SID and TF-M Partition load info. So please out of tree Secure Partition manifest lists do the corresponding change to make the tool aware of that any Partitions are DISABLED. The tool currently only takes conditional value "OFF" or "FALSE" as Partitions being disabled, all other values are treated as enabled. This means if you do not make the change in the manifest list, the tool treats all the partitions as enabled always. Best Regards, Kevin

3 years, 1 month

1
1
0 0

fce78aef breaks psoc64 console output with IARARM and ARMCLANG toolchain

by Thomas Törnblom

The current version breaks console output for the secure partition on psoc64 with IAR or ARMCLANG. Appears to work with GNUARM. It appears that this commit is the culprit: fce78aef Platform: Duplicate the tfm_hal_platform_init The console starts out good, then during tests only garbage is seen. Linker script issues? /Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

3 years, 1 month

4
4
0 0

BL2 builds, no "PYTHON_EXECUTABLE" defined

by Thomas Törnblom

While attempting to build for the musca_s1, with mcuboot, on Windows, the build failed very late and brought up a Code Writer window on my screen. I nailed it down to no "PYTHON_EXECUTABLE" being defined while processing bl2/ext/mcuboot/CMakeLists.txt, which caused the build line to just attempt to run wrapper.py, with no interpreter, and windows brought up the appropriate tools to write python code. Adding "-DPYTHON_EXECUTABLE=python" to the cmake line fixed that, but it seems that this shouldn't be needed. The build tools should handle this, or? There is a line: #! /usr/bin/env python3 in wrapper.py, and I assume linux will handle this appropriately, but it doesn't seem windows does. Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

3 years, 1 month

2
1
0 0

Flash definitions usage

by Bohdan.Hunko＠infineon.com

Hi everyone, I was trying to understand usage of TOTAL_ROM_SIZE and FLASH_TOTAL_SIZE from musca_b1/sse_200/partitions/flash_layout.h file. I haven't found any usage of these definitions. Does anyone know what is the reason to have them defined? 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>

3 years, 1 month

1
0
0 0

Inline asm syntax unified and symbol reference in IAR toolchain

by Ken Liu

Hi Thomas and all, I noticed there are some #if !defined(__ICCARM__) ".syntax unified \n" #endif In source code, looks like ".syntax unified" is not support in IAR, is that true? If it could not be supported in a short term, we can define some wrapper such as: #ifdef __ICCARM__ #define CLAIM_SYNTAX_UNIFIED "\n" #else #define CLAIM_SYNTAX_UNIFIED ".syntax unified \n" #endif Another question is about the: #if defined(__ICCARM__) #pragma required = do_schedule #endif If we claim do_schedule in the constraints, is the above "#pragma required" still needed? __asm (".... :: "i"(do_schedule)); We can create a patch to test this - using a constraint looks more proper. Thanks. /Ken

3 years, 1 month

2
5
0 0

Re: [TF-M] System reset

by Andrew Thoelke

Hi Sebastian, The section in the Platform Security Model is describing the behavior of a system reset – the recommendation is that any preceding runtime state (in volatile memory, or in CPU or peripheral registers) does not influence the execution of the reboot. This is except for an optional suspend or hibernate state, which explicitly maintains runtime state while powering off most or all of the system and will resume via a CPU reset. System security requirements might require explicit clearing of volatile memory on reset to prevent cold-boot style attacks that could allow an attacker to read any residual RAM contents – although software-based attacks of this kind are partly mitigated by trusted boot, which prevents an attacker from running arbitrary code at reset (unlike devices that boot from untrusted flash memory). The specific bullet list in the PSA Firmware Framework for M (in §3.5.1 on Panics) is describing the challenges for an implementation that does NOT do the recommended action of resetting the system when a Secure Partition panics, which justifies the recommendation to reset the system. If the SPM does reset the system, then the challenges in that bullet list are avoided. The issues listed are: > * An individual Secure Partition cannot be reset and restarted in isolation. > * A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service. There is no mechanism to re-synchronize the clients. > * It is not possible to determine at the point of panic how much corruption has occurred within the Secure Partition and elsewhere in the SPE. If the SPM only restarted the Secure Partition that panicked, then any previous runtime state within that Secure Partition is lost, including any ongoing connections with clients of services within that partition, or any resources that those services were managing for their clients. FF-M does not provide a specified mechanism for such clients to be informed that the connections are broken, and there is no way to provide a general strategy that allows a client to recover from a service failure. This is what is meant by “There is no mechanism to re-synchronize the clients.”. I have just realized that in FF-M 1.1, there may be scenarios in which restarting a Secure Partition could be justified and technically feasible. If a Secure Partition with only Stateless services maintains no client state or resources, and also maintains no connections to other RoT Services (so there are no RoT Services maintaining state for this Secure Partition) – then restarting this Secure Partition might not suffer from the first two complications listed in §3.5.1. The third issue is harder to control: the risks from the data corruption that lead up to the panic depends partly on the SPE isolation policies, and on what this Secure Partition was responsible for. Reset remains the recommended response to a Secure Partition panic in v1.1.0. Regards, Andrew Thoelke Arm Ltd. From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 26 October 2021 10:51 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] System reset Hi Sebastian, The specification writer looks not here these two days, let me try to explain it based on my understanding. I think two specs both recommend clearing general runtime data while resetting. If the booting runtime clearing code can clear the RAM data for a specific platform, the memory clearing in the 'tfm_spm_hal_system_reset ' can be skipped. Basically, simple hardware reset triggering is just fine. The special-purpose memory to be retained during resetting is not a generic runtime memory, hence they need to be treated specially, such as putting them in a special bank or region and skipping clearing them during booting. This special region can be treated as a private asset of one service, which could NOT be shared between components for direct access. The owner service provides the functionality around this asset. Please put more comments or corrections, thanks. /Ken From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Sebastian Bøe via TF-M Sent: Monday, October 25, 2021 3:16 PM To: mailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] System reset Hi, I would like some clarification about system reset. There are these two statements about it in the PSM and PSA-FF: "No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22. "A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47. Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure? I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ? PSM - Platform Security Model. https://developer.arm.com/documentation/den0128/0100/ PSA-FF PSA Firmware Framework https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityA… Sebastian Bøe Nordic Semiconductor

3 years, 1 month

2
1
0 0

[PLATFORM ATTENTION REQUIRED] Unify the HAL APIs for IPC Model

by Kevin Peng

Hi all, I'm been working to unify the HAL APIs for IPC Model. The IPC Model currently uses two different sets of HAL APIs: * tfm_spm_hal_* - This is mainly used by the Library Model and IPC Model re-uses some of them * tfm_hal_* - This is introduced for IPC Model and some are shared to Library Model This might be confusing for platform vendors. So I'm trying to make it clear for IPC Model by: * Duplicating the shared APIs and rename the IPC copy to tfm_hal_* * Combining several platform init APIs to a single tfm_platform_init for IPC Model * tfm_spm_hal_enable_fault_handlers * tfm_spm_hal_system_reset_cfg * tfm_spm_hal_init_debug * tfm_spm_hal_nvic_interrupt_target_state_cfg * tfm_spm_hal_nvic_interrupt_enable With these changes, IPC Model will use tfm_hal_* APIs only. Please platform owners review these patches<https://review.trustedfirmware.org/q/topic:%22decouple_legacy_hal_for_ipc%2…> to see if any mistakes (the patches mainly move codes around) or any platforms missed in the patches. Plan to have them merged before the end of October. Thanks. Best Regards, Kevin

3 years, 1 month

1
1
0 0

System reset

by Sebastian Bøe

Hi, I would like some clarification about system reset. There are these two statements about it in the PSM and PSA-FF: "No run-time state from before the reset should be retained or used, except where necessary if suspend or hibernate are supported, see section 4.6." -- PSM page 22. "A Secure Partition may have state maintained on behalf of clients that will be destroyed when restarting the service." -- PSA-FF page 47. Is it the responsibility of tfm_spm_hal_system_reset to destroy this state or is it OK to destroy it after reset as a part of the C runtime startup procedure? I assume for instance that PRoT .bss is cleared as a part of the C runtime startup procedure, but should it also have been destroyed as a part of tfm_spm_hal_system_reset ? PSM - Platform Security Model. https://developer.arm.com/documentation/den0128/0100/ PSA-FF PSA Firmware Framework https://armkeil.blob.core.windows.net/developer/Files/pdf/PlatformSecurityA… Sebastian Bøe Nordic Semiconductor

3 years, 1 month

2
1
0 0

ITS File System Enhancement

by Sherry Zhang

Hi, I created patches to add the XOR checksum of the whole metadata into the ITS metadata_block header. This is to check the possible error in the flash. It can happen that the ITS file system is upgraded to the new one while the ITS assets are maintained with the current ITS file system. To support compatibility with the current ITS filesystem version, at the initialization of the file system, the file metadata and the block metadata, together with the metadata_block_header are updated to the new ITS file system. The patches are: https://review.trustedfirmware.org/q/topic:%22ITS_FILESYSTEM%22+(status:ope… Would you like to review the patches? Any comments are welcomed! Regards, Sherry Z

3 years, 1 month

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

TF-M October 2021