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
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
Hi all,
Please be advised that the Mbed TLS GitHub migration is complete. The new home for Mbed TLS is:
https://github.com/Mbed-TLS
We recommend updating your project, checkouts, etc to point at the new repository, but it's not urgent as everything will continue to work for some time via automatic redirection.
Also please note that our project boards, which we use for planning upcoming work via epics, and tracking current activity, have moved. They are now available here:
Epics board: https://github.com/orgs/Mbed-TLS/projects/1
Current activity: https://github.com/orgs/Mbed-TLS/projects/2
Thanks
Dave Rodgman
On 22/03/2022, 14:52, "Dave Rodgman via Mbed-tls-announce" <mbed-tls-announce(a)lists.trustedfirmware.org> wrote:
Hi all,
Please note that in the next couple of weeks, we will migrate Mbed TLS to a new GitHub organisation. Your existing scripts, links etc for accessing Mbed TLS on GitHub should not be affected.
This will change the url from https://github.com/ARMmbed/mbedtls to https://github.com/Mbed-TLS/mbedtls . GitHub will redirect any accesses to the old URL for the foreseeable future, but we would recommend updating your links once the migration is complete.
All of the Mbed TLS repositories will migrate to this new organisation, i.e.:
mbedtls
mbedtls-docs
mbedtls-test
Thanks
Dave Rodgman
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org
Hi,
The next Technical Forum is planned on Thursday, March 31, 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
Hello,
Quite some time ago there was a proposal to move TF-M into GitHub. The main motivation is: more convenient review process, the Wiki for knowledge sharing and issue tracking facility.
This idea had been discussed multiple times in TSC. The following options were considered:
1. Hybrid: Add TF-M on GitHub with 2 ways synchronization between GitHub and existing Git/Gerrit
2. GitHub only: Move to GitHub completely and drop Gerrit.
3. Mirror: Create a read-only mirror on GitHub. TF-M review process stays in Gerrit but Wiki and issue tracking are on GitHub.
4. Nothing: Stay on Gerrit as good enough solution.
The options are ordered by complexity and cost each has pros and cons. The Mirror option (3) seeing as the best compromise and practically affordable in a short time.
Please share your opinion and comments on the topic with any dependencies or specific requirements to be considered.
Thanks,
Anton
Hi All,
Please find the link to the TrustedFirmware Community Code of Conduct here:
https://developer.trustedfirmware.org/w/collaboration/community_guidelines/…
Trusted Firmware has a very diverse and global developer community. It is
important that we adhere to the code of conduct in all our interactions.
For some of you all this may be new and for others just a gentle reminder.
In either case, if you have any questions, please feel free to reach out to
me directly.
And thanks to you all for your contributions to the TrustedFirmware
community!
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi.
I've been working on making an example on how an application can use the secure interrupts in a secure partition in TF-M.
During this I've encountered an issue where the secure partition will not be scheduled to process the secure interrupt signal in certain conditions.
I've compared it to the current SLIH and FLIH test cases to my observed behaviour and I could see that they did not have this problem.
I've created a test-case that triggers the problem [0].
In the mailing list I can see that this was actually discussed recently [1]
The summary is that secure partitions will not be scheduled to process a secure interrupt signal when the interrupt is interrupting the NSPE.
I could not find that this was documented anyway, but maybe I have overlooked.
In any case I find this behaviour very unexpected and I would like to know if this is indeed a design decision and the behaviour has to be this way?
If I wanted to do some processing in the secure partition context it would now mean that I have to get the NSPE to trigger this through a secure partition call.
This seems like a limitation to me .
I'd like to know what would be the issue with scheduling the partition once it now has the signal asserted.
I've done a quick test with scheduling the partition at this point with [2] and this now works as I expect it to.
I'd be happy to follow up with submitting a change to schedule the partition as done in [2] if that is an acceptable solution.
[0] https://github.com/joerchan/tf-m-tests/commit/d9f0a3a7653b594d0fa797d9e0bca…
[1] https://lists.trustedfirmware.org/archives/list/tf-m@lists.trustedfirmware.…
[2] https://github.com/joerchan/sdk-trusted-firmware-m/commit/e5512c6e8b2bad95c…
Hi,
Just a reminder that the MCUboot version has been upgraded to v1.9.0<https://github.com/mcu-tools/mcuboot/releases/tag/v1.9.0> in TF-M. If you are using the local MCUboot repo, then you need to update it to that version to avoid build error.
Regards,
Sherry Zhang
