Hey Bojan

We've been thinking about the same issue as well recently, in the context of RSE.

Fundamentally, ITS and PS have different hardware requirements, insofar as ITS is designed to have confidentiality, integrity and rollback-protection (CIRP) provided by its on-chip nature - It cannot be externally written with an ISP, it cannot be read except by secure firmware. PS on the other hand assumes an environment where CIRP must be provided entirely by software, and so has AEAD encryption and antirollback counters built in to the design.

What has gone wrong (IMO) is that we've provided separate APIs to each of them, so that in order to provide key storage to the crypto partition, it is required to implement ITS, even when there is no hardware to provide the required security properties. This makes sense in that it avoids the circular dependency issues where crypto uses storage to store keys and then storage uses crypto to encrypt the storage, but it only works in the case that internal flash is available.

If internal flash in unavailable, you end up in the scenario we are currently in, where we need to provide the ITS APIs, but can't use the ITS partition as-designed. The current direction of travel on this seems to be to implement more and more of the functionality of PS in ITS. Once we implement rollback-protection in ITS, it will inevitably end up looking exactly like PS.

IMO, a better alternative would be to alias the APIs between ITS and PS if one is disabled. Both would provide CIRP via their respective mechanisms, and we'd distinguish the data-source internally to avoid UID reuse.

So you'd end up with: * ITS enabled + PS enabled -> ITS data in internal flash, PS data in external flash, cryptography for PS provided by crypto partition * ITS enabled + PS disabled -> ITS data in internal flash, PS data stored in ITS, no cryptography needed for secure storage * ITS disabled + PS enabled -> ITS data stored in PS, PS data in external flash, PS (currently) uses separate crypto HAL as in current encrypted ITS.

This doesn't solve all of this issues - in particular it doesn't solve the circular dependency issue. In the short term, this could be solved with the existing ad-hoc crypto HAL which encrypted ITS uses. In the long-term, it would be better to implement some limited re-entrancy to the crypto partition, since we can't use exclusive mmio_region binding if the crypto accelerator is used by multiple partitions.

As an aside, part of this would involve removing encrypted ITS support (as it would no-longer be needed). I'm concerned about the current state of encrypted ITS support, in that because it doesn't provide rollback-protection it's vulnerable to a whole host of attacks, and so I don't believe should be considered secure in any practical sense.

Raef

________________________________________ From: Bojan Simoneta via TF-M tf-m@lists.trustedfirmware.org Sent: 03 October 2025 14:56 To: tf-m@lists.trustedfirmware.org Cc: Waqar Ali Tahir; Ruchika Gupta Subject: [TF-M] Rollback protection in Internal Trusted Storage

Dear TF-M Community,

I have a question regarding rollback protection in Internal Trusted Storage.

Scenario: Recently we are seeing an increasing number of products which will come to market without internal Flash; together with this, there is also the requirement to store permanent keys using PSA key management APIs as psa_import_key, which will then in turn use Internal Trusted Storage as place where keys will be written. Considering these requirements there is a necessity to implement the Internal Trusted Storage in external Flash, which brings with it security challenges: the keys stored in external Flash would require confidentiality but also rollback protection. The encryption of ITS encryption was recently enabled as you can see in the following Pull request https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/15096, but rollback protection is not yet implemented.

Proposal: Our proposal would be to: - Add ITS rollback protection as optional feature, since it is not desired feature for product where the ITS storage is internal - Add rollback protection mechanism to Internal Trusted Storage functions relying on the NV counters APIs called from the platform layer, similar as is already done for Protected Storage

Also, we are open to discuss any other proposal which would help us to fulfill the above requests (ITS in external Flash with still providing confidentiality and rollback protection).

Thanks in advance for the answer and further guidance on the topic.

KR, Bojan Simoneta

Bojan Simoneta (He / Him / His) Principal Embedded SW Engineer Phone: +433124 299160 Email: bojan.simoneta@nxp.commailto:bojan.simoneta@nxp.com

[cid:image006.png@01DC347E.50852920]

NXP Semiconductors Austria GmbH & Co KG | Mikronweg 1, 8101 Gratkorn | Austria | Sitz: Gratkorn, Österreich | Firmenbuchgericht: Landesgericht für ZRS Graz | Firmenbuchnummer: FN 541474 k | VAT: ATU76231908

Unless otherwise recorded in a signed, written agreement, all sales transactions by NXP are exclusively subject to NXP’s Terms and Conditions of Commercial Sale (“NXP Terms”) published at: www.nxp.com/profile/terms/index.htmlhttp://www.nxp.com/profile/terms/index.html. NXP explicitly rejects and disregards any terms and conditions of customer that add to, or differ from, NXP’s Terms irrespective of when customer raises its terms. The information contained in this message is confidential. The message is intended solely for the addressee(s). If you are not the intended recipient, any use, dissemination, or reproduction is strictly prohibited and may be unlawful and you are asked to please contact the sender by return e-mail and destroy all copies of the original message.