Hi Georgios,

 

> The spec states clearly in the requirements that ITS may or may not provide confidentiality/integrity (section 2.2, p 4,5). Since this is not a strict requirement, I don't believe that we can say that PSA is not "secure enough". Being secure enough, in my opinion, requires fulfilling the minimum set of requirements and these do not include any cryptography. This is the reason that currently we can say that the current implementation is compliant with the spec even though it does not provide any encryption/integrity features. Still, we need to be careful to avoid confusion for the users.

 

I need to clarify what the spec (https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Implement/IHI0087-PSA_Storage_API-1.0.0.pdf) does and does not say (or intend to say) are the requirements of ITS.

 

Section §2.2 PSA Internal Trusted Storage Requirements agrees with §1.4 The PSA Internal Trusted Storage API, in requiring that all data stored by ITS is protected from disclosure and tampering. The last paragraph in §1.4 says

 

As the Internal Storage is implicitly confidential and protected from replay …

 

Requirements 1 and 2 in §2.2 state this explicitly:

 

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).

 

The optionality that is expressed by requirements 4 and 5 in §2.2 is specifically about the use of cryptography to provide or enhance the protection required by 1 and 2:

 

4. The PSA Internal Trusted Storage Service MAY provide confidentiality using cryptographic ciphers.

5. The PSA Internal Trusted Storage Service MAY provide integrity protection using cryptographic Message Authentication Codes (MAC) or signatures.

 

Perhaps these requirements should be rewritten to ensure that they are unambiguous. They are intended to be read as “MAY provide (confidentiality using cryptographic ciphers)” rather than “(MAY provide confidentiality) (using cryptographic ciphers)”. The latter obviously contradicts requirement 1, but potentially ambiguous requirements are never a good idea.

 

> In my opinion what we need in the PSA level is a configurable flag which states the supported features of ITS which platforms must include in their configuration file. This will make the ITS supported features clear to the users independently of how we will decide to do it in the end. 

 

Given the intention of the specification of ITS, this is not required at the PSA API level – ITS needs to provide this protection. However, configurability might be a good way to make the existing ITS service implementation code be capable of using completely secure flash when available (the current assumption of this code I believe), or using cryptographic protection when the underlying storage hardware does not provide sufficient security for ITS.

 

> Regarding the proposed solutions:

> 1.      Encrypt each ITS object using platform specific APIs: this solution is fairly like the proposed one, as you stated, with the main disadvantage being that will result in dual encryption for the PS in some cases.

 

The ‘double encryption’ depends on the implementation of PS. A trivial implementation that maps all calls to PS onto calls to ITS, but encrypts data on the way, doesn’t make much sense from a security perspective: if PS is directly using ITS for storage, then ITS already has the security properties required by PS. I wouldn’t expect this implementation to be used in devices with larger NS flash memories, as ITS is expected to be very limited in capacity. I am not familiar with the TF-M implementation of PS, so cannot comment on this issue with regards to what happens in TF-M.

 

> 2.      Implement the ITS and Crypto services in a single partition: This solution breaks the separation of concern of these two services. They are both in the PRoT, but I think it is preferable not to merge them. They have clearly different scopes and merging them can be confusing.

 

I agree from an ideal architecture point of view, and from a reliable/robust software engineering perspective – separation of the services makes for cleaner code, which is more easily tested and audited, and can expose implementation errors more easily or quickly. However, for small footprint devices, the additional separation (suggested by solution 1) adds cost, particularly when considering a possible need to duplicate parts of the cryptographic library, or try and share this code (and data?) without undermining the separation of the services. So for some systems, this might be the most appropriate design solution (this might not be your system).

 

> 3.      Renaming the underlying storage service: This solution I am not sure that I understand fully. If we decouple the ITS backend as a storage solution and the PSA keystore uses the storage it will not be possible to have encrypted key storage if the hardware backend does not support, it, right? So, what is the advantage of having an encrypted ITS if the PSA keystore does not use it?

 

Let me try and describe this more clearly then:

 

 

I am happy if solution 1 is the best fit for your platform, but it is worth considering that this might not be an optimal solution for all systems that do not have the security properties required by ITS in the hardware itself.

 

Regards,

Andrew

 

From: Vasilakis, Georgios <georgios.vasilakis@nordicsemi.no>
Sent: 22 October 2021 13:13
To: Andrew Thoelke <Andrew.Thoelke@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: Re: [TF-M] Supporting encryption with ITS

 

Hello Andrew,

 

Thank you for the useful considerations! 

I agree with you that we have a benefit to have ITS with clearly defined security requirements. So, I see the benefit of not including the encryption scheme in the key storage itself since it can result in confusion for the users. 

The spec states clearly in the requirements that ITS may or may not provide confidentiality/integrity (section 2.2, p 4,5). Since this is not a strict requirement, I don't believe that we can say that PSA is not "secure enough". Being secure enough, in my opinion, requires fulfilling the minimum set of requirements and these do not include any cryptography. This is the reason that currently we can say that the current implementation is compliant with the spec even though it does not provide any encryption/integrity features. Still, we need to be careful to avoid confusion for the users. 

 

In my opinion what we need in the PSA level is a configurable flag which states the supported features of ITS which platforms must include in their configuration file. This will make the ITS supported features clear to the users independently of how we will decide to do it in the end. 

 

Now regarding the implementations, you made a valuable comment which I think that it needs to be more highlighted. The storage used for ITS may or may not provide confidentiality/integrity in the hardware level (I am assuming that secure elements might be added later). This means that we need to have a way to inform the ITS service of which optional features are supported in the hardware level (in the "flash" folder of the ITS partition). Then the ITS codebase can decide if it needs to add encryption in the software level or not.

 

 

Regarding the proposed solutions: 

  1. Encrypt each ITS object using platform specific APIs: this solution is fairly like the proposed one, as you stated, with the main disadvantage being that will result in dual encryption for the PS in some cases.
  2. Implement the ITS and Crypto services in a single partition: This solution breaks the separation of concern of these two services. They are both in the PRoT, but I think it is preferable not to merge them. They have clearly different scopes and merging them can be confusing.
  3. Renaming the underlying storage service: This solution I am not sure that I understand fully. If we decouple the ITS backend as a storage solution and the PSA keystore uses the storage it will not be possible to have encrypted key storage if the hardware backend does not support, it, right? So, what is the advantage of having an encrypted ITS if the PSA keystore does not use it? 

 

In my opinion option 1 along with the addition of some headers with the supported features of the ITS backends is a clean solution which follows the security requirements of the spec. 

 

Regards,

Georgios

 

From: Andrew Thoelke <Andrew.Thoelke@arm.com>
Sent: Thursday, October 21, 2021 4:40 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 Georgios,

 

Thanks for the illustration of your proposal.

 

From a PSA architectural perspective, the concern with this design is that:

  • The key store does not consider that PSA ITS is secure enough to store key material without additional cryptographic protection
  • Other clients of the PSA ITS service assume that it already provides confidentiality, integrity and rollback protection for its contents.

 

So either the ITS service provides the required security properties, and then the key store does not need to do additional cryptographic protection; OR the ITS service does not meet the PSA ITS security requirements, and should not be using the PSA ITS API.

 

[I realise that this is a fairly long post, but I wanted to try and provide an outline of some possible design solutions that do not result in an inadequate ITS service.]

 

If the storage used for ITS in a system does not provide the required security properties, then ideally, we do not redefine the security of ITS. Instead, either (a) we add the cryptographic protection within the ITS service (so ITS now matches the security requirements), or (b) we rename the storage service used by the key store for this platform (i.e. not psa_its_*), make the key store encrypt data before storage, and then provide a compliant ITS service that also encrypts before using the underlying not-secure-enough storage service.

 

Option (a) involves breaking the Crypto-key-store -> ITS -> Crypto dependency cycle by removing the ITS->PSA Crypto link. Some techniques have already been suggested:

  1. Have the ITS implementation use its own [copy of the] cryptographic algorithms that are needed
  2. Implement the ITS and Crypto services in a single partition: have the key load and store operations use an internal ITS interface (not the psa_its_*() functions that dispatch through the SPM), and the ITS read and write operations use an internal Crypto API for encryption and decryption (not the PSA Crypto API that dispatches through the SPM)

 

Option (b) breaks the Crypto->ITS->Crypto cycle a third way:

  1. Renaming the underlying storage service, and removing the Crypto->ITS dependency, replacing it with Crypto->Storage, and ITS->Crypto and ITS->Storage dependencies. This requires changes to the key store load/unload functions, and not just introducing an extra (optional) call

 

These options impact the existing TF-M service code in different ways:

 

Option 1 only requires changes in the ITS service implementation. Depending on the cryptographic protection required this might just be encryption and decryption of each data item content, but not ITS metadata protection (this is equivalent to the proposed change to the key load/store functions), cryptographic protection of storage metadata requires a solution that looks more like the PS use of cryptography.

Option 2 requires flexibility in the partition assignment of services, and the ability to use internal APIs between the services (for this configuration) instead of the normal PSA APIs.

Option 3 requires the ability to change the key load and store functions at the back-end of the PSA Crypto service, to not use PSA ITS. It might also benefit from an ability to split ITS into a back-end storage engine (may not be secure enough), and the service API front-end.

 

All of the options need some cryptography design to decide how to manage and store or derive the keys used for encryption.

 

None of these appear as simple as the encryption hooks in the encrypted-key-storage graphic, but that design fails to provide an ITS service that meets the security requirements.

 

Regards,

Andrew

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M
Sent: 20 October 2021 14:11
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

 

Hey Sherry,

 

Sure, let me explain a bit further. 

 

Right now the PSA APIs use the ITS as a backend for the storage of persistent keys.   When someone calls a cryptographic function using a persistent key they will end up calling  ITS APIs to fetch the info and the data of the key (as done in the  psa_load_persistent_key). What I am proposing is to have an encryption abstraction implemented(optionally) in this level. An encryption abstraction will only define the encryption functions signatures and each provider will have to provide their own custom crypto implementation in this scope.  Then the encryption/decryption of the key material will be done to the PSA funtions (like the psa_load_persistent_key) and the ITS will be unaware of the whole operation. 

 

So to answer the first question, we will not call PSA crypto from inside of the PSA crypto. We will call a different crypto abstraction which will be implemented by each platform. The encryption will be transparent to the users. Also the ITS will not have to know anything about it, all the logic can be implemented in the PSA APIs. 

 

To make the scheme more clear I uploaded an image with the current and the proposed method here: 
https://ibb.co/Bgrq1K3

Image removed by sender.

Image encrypted-key-storage hosted in ImgBB

ibb.co

 

 

Regards,

George

 

From: Sherry Zhang <Sherry.Zhang2@arm.com>
Sent: Wednesday, October 20, 2021 5:45 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,

 

Sorry I didn’t fully understand solution 2. How can the crypto partition call itself to do encryption? And does ITS partition need to call crypto partition to do the encryption or the user should call the crypto partition to encrypt the data before calling the ITS service to store it? Can you explain more on solution 2?

 

Thanks,

 

Regards,

Sherry

 

 

 

From: TF-M <tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Vasilakis, Georgios via TF-M
Sent: Tuesday, October 19, 2021 9:31 PM
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!

  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@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:

 

  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@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