PSA protected storage, encryption keys and FOTA

[Tom01]

Dear Nordic team,

we are developing an application for a nRF9151 which will perform some HTTPS requests. For that purpose we want to encrypt and store an API key (string of max. 32 characters). We are working with the non-secure board target and SDK v3.3.0. Our application was initially based on the "https_client" sample which uses the minimal TF-M profile for the nRF9151 DK board. We are aware that PSA protected storage is only available for the non-minimal TF-M profile. Additionally, we are planning to implement a FOTA procedure using the available libraries. To plan ahead, we have some questions regarding the persistence of the protected storage, generated encryption keys and dependencies of the FOTA libraries. 

1. Are PSA protected storage's key-value pairs persistent across firmware updates (e.g. FOTA) as long as the TF-M layout and its profile remain unmodified? 
2. Are encryption keys (like the one generated in the "persistent_key" sample) persistent across firmware updates (e.g. FOTA) as long as the TF-M layout and its profile remain unmodified?
3. Is the PSA protected storage a valid place to store information like API keys? 
4. Does FOTA support directly rely on using the non-minimal TF-M profile or could we stick with the minimal profile?

Best regards,

Tom

[Nissanth]

Hi Tom, 

Q1 and Q2: Yes, just keep the flash addresses fixed with pm_static.yml and your keys survive firmware updates.
Q3: Yes, PSA protected storage is designed to store these kind of data.
Q4: No, FOTA does not require non-minimal profile, but protected storage does require it, so you need it anyway.

Regards,

Nissanth Karunanithy

[Tom01]

Hi Nissanth,

thanks for the quick response and the clarifications! After receiving your answer we've actually migrated the project to SDK v3.4.0, because that made the device tree setup of the TF-M partition much clearer for us. (We are new to Nordic chips and the partition manager of SDK v3.3.0 felt a bit "magical"...) Use of the PSA protected storage is incredibly seamless. Great work on that!

For anyone interested in what we've done:

We've started with the "https_client" sample, which uses the included "boards/nrf9151dk_nrf9151_ns.conf" Kconfig-overlay for the nRF9151. We've modified that file by removing "CONFIG_TFM_PROFILE_TYPE_MINIMAL=y", because PSA protected storage requires the non-minimal profile. Additionally, we've looked at the "persistent_key" sample for SDK v3.4.0, which has a devicetree overlay file "boards/nrf9151dk_nrf9151_ns.overlay" that includes two further overlay files:

#include <samples/cellular/nrf91_crypto_partitions.dtsi>

#include <samples/cellular/nrf91_sram_crypto_partitions.dtsi>

Those overlays define a fixed TF-M partition arrangement, basically answering question 1 and 2. Hence, we've included those overlays in our own project in the "boards/nrf9151dk_nrf9151_ns.overlay" file. In our project's "prj.conf" we've added 

CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_PARTITION_PROTECTED_STORAGE=y

which enables the PSA protected storage API.

Best,

Tom