High endurance encrypted storage using TF-M

[jeremyherbert]

Hi,

I am looking at using the nrf5340/nrf9160 in a device. In this device, I need to have high endurance storage of some data that must be kept secret, integrity checked and replay protected. It will be approximately one hundred bytes and writes will occur regularly (every ~30 sec). Total number of writes will be easily >1million over the lifetime of the product. I am currently evaluating using FRAM for this as the data would need to survive power off. I plan to use the nrfconnect zephyr sdk. SRAM backup via coin cell is possible, but I am trying to not do this for several reasons.

I have determined that the following options are available:

1. Do everything myself, storing a key in the zephyr NVS. This isn't all that secure, and I will still need a monotonic counter (nonce) to provide replay protection; am unsure where to store this nonce as I will quickly wear out internal flash I believe.

2. Use the TF-M Crypto implementation to store keys/perform the encryption, but otherwise write the data to the FRAM myself. This still requires that I store a nonce somewhere as far as I can tell.

3. Use the TF-M Protected Storage APIs (I don't believe I can use the Internal Protected Storage API as this will wear out the flash). As far as I can tell this handles the replay protection and nonce storage, but I cannot work out how to have this write to a specific storage medium like an I2C FRAM. Is there any information available on this?

4. Similar to 3, but using a fairly large NOR flash so that the writes are leveled across a large number of pages. But I am still unsure how to tie the PS APIs to a storage backend.

I would really prefer to go with option 3.

Could you please help me understand if there is some recommended way to store nonces on these devices and/or how I can add a storage backend to the TF-M PS API?

Thanks.

[Simon]

I got some feedback internally.

What you're trying to do is exactly what the TFM PS API is meant for. You need to write a driver for the external storage device, in the context of TFM (cannot rely on Zephyr code).

Our internal flash driver can be found at modules/tee/tfm/trusted-firmware-m/platform/ext/target/nordic_nrf/common/core/cmsis_drivers/Driver_Flash.c. Add your own driver in the same location and use Driver_Flash.c as reference of how to implement it. Make sure you map the functions from \modules\tee\tfm\trusted-firmware-m\platform\ext\driver\Driver_Flash.h to your custom functions, like it's done here: https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.2.99-ncs1/trusted-firmware-m/platform/ext/target/nordic_nrf/common/core/cmsis_drivers/Driver_Flash.c#L162-L174 

To use a separate driver modify TFM_HAL_PS_FLASH_DRIVER Driver_FLASH0 to be associated with your custom API.

Best regards,

Simon 

[jeremyherbert]

Thanks, that works great. Using this approach, is the nonce stored on the internal flash, or using the new driver I have written? Because if the nonce is stored externally, that will break the replay protection.

I can imagine a situation where one could write the nonce to an internal flash page sequentially until it is full, then do an erase and start again. This would give guaranteed 10 000 * 512 nonce increments (for a 64 bit nonce) per 4096 byte page until flash wearout. Is that how the ITS implements nonce storage?

[Simon]

Sorry for the delayed answer on this. Have you figured this out, or do you want me to look into it?

[jeremyherbert]

If you could have a look into it that would be good, I wasn't able to spend much time working this out myself

[Simon]

If you simply swap the functions in https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.2.99-ncs1/trusted-firmware-m/platform/ext/target/nordic_nrf/common/core/cmsis_drivers/Driver_Flash.c#L162-L174 with the external flash calls, the external flash will be used. But it hard to say without looking at your code and seeing exactly what you've done.