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
Hi everyone,
I have a few questions related to TF-M code:
1. Default implementation of tfm_hal_system_reset(void) from platform/ext/common/tfm_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> just calls NVIC_SystemReset(), but some ARM platform, take musca_b1 for example, reimplement it (platform/ext/target/arm/musca_b1/sse_200/tfm_hal_platform.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e…> ).
Custom implementations tend to also disable and clean IRQ and call mpc_revert_non_secure_to_secure_cfg();
Is there any benefits of doing that??? If so then what those benefits are?
1. tfm_core_panic() (secure_fw/spm/ffm/utilities.c<https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/secure_fw/…>) when TFM_FIH_PROFILE_ON is defined calls fih_delay() and tfm_hal_system_reset() twice. Is this done to ensure that tfm_hal_system_reset() will be called (even if first one was skipped there is second one)? And if so, can a comment be added there to highlight that intention?
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>
Hi,
The next Technical Forum is planned on Thursday, Feb 3, 7:00-8:00 UTC (Asia time zone).
Please reply on this email with your proposals for agenda topics.
This slot is in Chinese New Year celebration period so we can expect fewer participants from Asia.
Recording and slides of previous meetings are here:
https://www.trustedfirmware.org/meetings/tf-m-technical-forum/
Best regards,
Anton
Hi All,
Please do use the tf-m-tests version specified in TF-M CMake configs (TFM_TEST_REPO_VERSION in trusted-firmware-m/lib/ext/tf-m-tests/repo_config_default.cmake), otherwise there might be some unexpected build errors.
Please let us know if there is any problem.
Thanks,
Xinyu
Hi All,
TF-M Open CI is back to normal. Please feel free to use.
Thanks,
Xinyu
From: Xinyu Zhang
Sent: Monday, January 17, 2022 4:05 PM
To: TF-M mailing list <tf-m(a)lists.trustedfirmware.org>
Cc: nd <nd(a)arm.com>
Subject: TF-M Open CI Not Stable Right Now
Hi All,
Sorry to inform you that TF-M Open CI is not stable right now. Jobs are likely to come into unexpected failure.
I'll keep following up with the latest information.
Sorry for any inconvenience!
Thanks,
Xinyu
Hi,
The next Technical Forum is planned on Thursday, January 20, 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
This event has been changed.
Title: TF-M Tech forum
This is an open forum for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC.Feel free to forward it to colleagues.Details of previous meetings
are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…
Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic:
TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 18, 2021, 6 occurrence(s) Oct 29, 2020 03:00
PM Nov 26, 2020 03:00 PM
Dec 24, 2020 03:00 PM Jan 21, 2021 03:00
PM Feb 18, 2021 03:00 PM
Mar 18, 2021 03:00 PMPlease download and import the following
iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting
ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742#
US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your
location +1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose) +1 301 715
8592 US (Germantown) +1 312 626 6799 US
(Chicago) +1 646 558 8656 US (New York)
877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number:
https://linaro-org.zoom.us/u/abx3I7IoRq
When: Every 4 weeks from 8am to 9am on Thursday Mountain Standard Time -
Phoenix
Where:
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* tf-m(a)lists.trustedfirmware.org
* anton.komlev(a)arm.com
* abdelmalek.omar1(a)gmail.com
* kevin.townsend(a)linaro.org
* seth(a)nxmlabs.com
* leonardo.sandoval(a)linaro.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n…
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
This event has been changed.
Title: TF-M Tech forum
This is an open forum for anyone to participate and it is not restricted to
Trusted Firmware project members. It will operate under the guidance of the
TF TSC.Feel free to forward it to colleagues.Details of previous meetings
are
here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==…
Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic:
TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM
Greenwich Mean Time Every 4 weeks on Thu, until
Mar 18, 2021, 6 occurrence(s) Oct 29, 2020 03:00
PM Nov 26, 2020 03:00 PM
Dec 24, 2020 03:00 PM Jan 21, 2021 03:00
PM Feb 18, 2021 03:00 PM
Mar 18, 2021 03:00 PMPlease download and import the following
iCalendar (.ics) files to your calendar system.Weekly:
https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics…
Zoom
Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting
ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742#
US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your
location +1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
+1 669 900 9128 US (San Jose) +1 301 715
8592 US (Germantown) +1 312 626 6799 US
(Chicago) +1 646 558 8656 US (New York)
877 853 5247 US Toll-free
888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number:
https://linaro-org.zoom.us/u/abx3I7IoRq
When: Every 4 weeks from 8am to 9am on Thursday Mountain Standard Time -
Phoenix
Where:
https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz…
Calendar: tf-m(a)lists.trustedfirmware.org
Who:
* Don Harbin - creator
* tf-m(a)lists.trustedfirmware.org
* anton.komlev(a)arm.com
* abdelmalek.omar1(a)gmail.com
* kevin.townsend(a)linaro.org
* seth(a)nxmlabs.com
* leonardo.sandoval(a)linaro.org
Event details:
https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n…
Invitation from Google Calendar: https://calendar.google.com/calendar/
You are receiving this courtesy email at the account
tf-m(a)lists.trustedfirmware.org because you are an attendee of this event.
To stop receiving future updates for this event, decline this event.
Alternatively you can sign up for a Google account at
https://calendar.google.com/calendar/ and control your notification
settings for your entire calendar.
Forwarding this invitation could allow any recipient to send a response to
the organizer and be added to the guest list, or invite others regardless
of their own invitation status, or to modify your RSVP. Learn more at
https://support.google.com/calendar/answer/37135#forwarding
Hi All,
Sorry to inform you that TF-M Open CI is not stable right now. Jobs are likely to come into unexpected failure.
I'll keep following up with the latest information.
Sorry for any inconvenience!
Thanks,
Xinyu