Thank you both for the input!

Andrej, you are correct that right now PS == Encrypted ITS but my understanding of the spec tells me that this will not always be the case. They do refer to platforms that will use external storage for PS (even though they still require ITS even in this case indeed).

And just to clarify, I don't propose creating yet another ITS. The second thought that I had regarding the refactoring is mainly a common library that both ITS and PS can use for object handling.

Fabian, I also understand it similarly, the ITS is supposed to be trusted on-chip storage which is more protected than PS. And the isolation from TrustZone in normal circumstances should be adequate (at the moment). But physical attacks these days are not that sophisticated anymore, and I think that this is the main driving force for this requirement.

Regards, George

________________________________ From: Fabian Schmidt Sent: Thursday, September 23, 2021 3:50 PM To: Vasilakis, Georgios Cc: 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@lists.trustedfirmware.org On Behalf Of Vasilakis, Georgios via TF-M Sent: Donnerstag, 23. September 2021 15:28 To: 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