Hi,
Note that, by specification, ITS must provide confidentiality, integrity and replay protection for the data stored within it. However, if the platform already provides that protection via isolation/logical/physical mechanisms, then adding cryptographic protection provides some defence in depth, or may mitigate some forms of physical attack. In this case, it is not obvious what forms of cryptographic protection are needed, as cryptography is not providing the primary security properties for the ITS data.
As a result, I think the best design for this requirement will depend on the details of the protection that is required.
In this use case, which of the following types of cryptographic protection are needed:
Per-key confidentiality, or confidentiality+integrity would be reasonably straight-forward to implement in a layer over the simple ITS storage – but would probably add IV or nonce+tag data to each key stored (assuming a HUK-derived encryption key is used). For just encryption, given the pseudo-random nature of secret keys – it might be possible to drop the need for random IV (and just use the client id + key id as an IV/nonce).
Full key store confidentiality or confidentiality+integrity requires much more complex design, as this aims to conceal and protect the identity of the keys that are stored, not just the key material and/or key metadata.
Regards,
Andrew
From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M
Sent: 19 October 2021 14:31
To: tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello again, sorry for the second email by my formatting got lost in the first one unfortunately. Let me include the formatted context below:
Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting.
1)Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch)
2)Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them.
3)Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level.
The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer.
I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific.
Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design.
From: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>
Sent: Tuesday, October 19, 2021 3:18 PM
To: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello all,
Following the discussion regarding the encryption with ITS let's discuss a bit further the ideas discussed in the meeting.
Allow the protected storage to be used as a storage backend for persistent key storage in PSA crypto: This introduces the problem of reentrance that we discussed before. We cannot call crypto from the inside the PSA storage partition (either ITS of PS if we wanted to switch)
Do the encryption in the crypto partition instead of the ITS: This will require to create some platform specific encryption abstraction since we cannot have reentrance in PSA crypto as well. Meaning that we cannot call PSA crypto from PSA crypto. The main thing that needs to be solved in this solution is where can we store the metadata. The key itself can be derived from the HUK and does not need to be stored but the metadata need to be stored. These metadata can be stored by expanding the psa_storage_info_t struct or by introducing a new struct. The crypto storage apis will need to be modified to be aware of the extra information and handle them.
Put a frontend to ITS so that we select specific keys that need to be derived by the HUK. This is like the idea 2 I think in a concept level.
The previous two designs described in the mailing list was to refactor the ITS and the PS partitions to have a common "encryption" library and the idea of refactoring the ITS itself to have an encryption layer.
I personally prefer the solution 2 more than the other solutions. Moving the encryption in a higher level and using the ITS as a simple storage solution seems a cleaner approach. This will introduce a crypto abstraction layer (different than PS) but I don't consider it as a major disadvantage since all the crypto implementations in this scope will be very platform specific.
Let me know about your opinions on this, if there are no major objections, I am willing to design a solution and some header files to elaborate more on this design.
Regards,
George
From: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>
Sent: Wednesday, September 29, 2021 2:04 PM
To: Sherry Zhang <Sherry.Zhang2@arm.com>;
tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello Sherry,
Thank you for the feedback!
Does the storage area on your device meet this requirement?
Yes, our devices can secure against read and write access through the dedicated peripherals (SPU + MPU).
Is the memory physically isolated?
If by that you mean if they are located outside of the chip then it is not. It is part of the package.
If not, I wonder why not uses the Protected Storage service instead?
The reason that we cannot use the protected storage service is that it is not supported as a storage backend by the PSA crypto APIs. Storing non-volatile keys right now using the PSA APIs uses ITS as a storage backend.
Your comments regarding storing the IV and the TAG in Protected Storage are, of course, valid. If we decide to use a common code base we will have to do changes in the design of both services to overcome these issues.
Overall, the motivation for encrypted ITS is based on the raising popularity of hardware-based attacks. The fact that right now we provide all the security measures needed does not mean that nothing will get compromised in the future. A security in depth approach seems more reasonable for such sensitive data.
I am happy to join the TF-M Tech forum this Thursday and discuss it further, yes!
Regards,
George
From: Sherry Zhang <Sherry.Zhang2@arm.com>
Sent: Tuesday, September 28, 2021 12:20 PM
To: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>;
tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: RE: [TF-M] Supporting encryption with ITS
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@nordicsemi.no>
Sent: Friday, September 24, 2021 8:52 PM
To: Sherry Zhang <Sherry.Zhang2@arm.com>;
tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS
Hello Sherry,
Thank you for your input!
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@arm.com>
Sent: Friday, September 24, 2021 11:58 AM
To: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>;
tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: RE: [TF-M] Supporting encryption with ITS
Hi George,
Some comments from my side:
Regards,
Sherry Zhang
From: TF-M <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@arm.com>; Fabian Schmidt <fabian.schmidt@nxp.com>
Cc: nd <nd@arm.com>;
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@arm.com>
Sent: Thursday, September 23, 2021 4:30 PM
To: Fabian Schmidt <fabian.schmidt@nxp.com>; Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>
Cc: tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.org>; nd <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@lists.trustedfirmware.org>
On Behalf Of Fabian Schmidt via TF-M
Sent: September 23, 2021 15:51
To: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>
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