Zephyr ITS on settings/nvs, data does not persist through reset

[Anthony Ambuehl]

I'm working on an application using ITS.  Since I'm currently having difficulty getting non-minimal TFM to work on the nrf9160, I have temporarily switched to not use TF-M with the 9160.

I'm using NCS 2.3.0 with Zephyr ITS with Settings/NVS underneath.

Here are the conf settings:

ONFIG_PSA_NATIVE_ITS=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

(I can provide complete project build privately)

I am finding 2 issues:

1) The data saved in the first call to psa_its_set  is not the same when I read it back with psa_its_get.  All the operations succeed, but the data is changed.  I have bypassed the issue by always calling psa_its_get immediately after psa_its_set and if the data doesn't match I retry the operation. 

2) I'm finding after a reset that the data is no saved.  During the boot-up I see the following messages:

[00:00:00.258,544] <inf> fs_nvs: No GC Done marker found: restarting gc
[00:00:00.434,448] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.434,478] <inf> fs_nvs: alloc wra: 0, fe8
[00:00:00.434,478] <inf> fs_nvs: data wra: 0, 0

Is there some sort of NVS initialization that is necessary to make the zephyr ITS on Settings/NVS work?

[Sigurd Hellesvik]

Hi,

I will continue to help in this case.

Are you sure that you want to use ITS and not Protected Storage?

Give  Persistent storage of keys and data using the nRF Connect SDK a read and let me know if your questions still apply. (I have not read your question in depth yet, so I might have missed things)

Regards,
Sigurd Hellesvik

[Anthony Ambuehl]

Since this application is very concerned with the security of this data, the preference was to apply as much protection to the keys and data as possible.  Ideally it would be stored internally in the KMU and only accessed by an ARoT secure partition from TF-M.  Unfortunately I was not able to use the cc3xx libraries from within an ARoT so the second best choice was to store the data in an ARoT secure partition using ITS, which is working for nrf5340 on NCS v2.3.0.  Alas, this also requires non-minimal TF-M which I have been unable to fit into nrf9160 along with mcuboot/NSIB. 

The client wants to move forward, so they requested I temporarily proceed on v2.3.0 without TF-M for the nrf9160.  Since the code was already written for ITS and PSA Crypto, and since encrypted internal storage is more secure than encrypted external storage, I went down the path of using ITS without TF-M.  which is an available configuration.  Also, the PSA crypto library expects to use ITS.

I can look into switching the code between Protected Storage and Internal Trusted Storage for the nrf9160 non-TF-M implementation, but it is further degrading the security which is the second highest priority.  (The higher priority now being time-to-market)  I will have to forego use of persistent keys since PSA Crypto persistent keys are also stored  ITS.

Alternatively is it possible to use Nordic's customized/encrypted ITS without TF-M?

Also it does seem like there are bugs in the Zephyr implementation of ITS, its seems like it should be reported upstream?  Maybe it should be deprecated if is not supported?

[Sigurd Hellesvik]

Anthony Ambuehl said:

I can look into switching the code between Protected Storage and Internal Trusted Storage for the nrf9160 non-TF-M implementation, but it is further degrading the security which is the second highest priority.  (The higher priority now being time-to-market)  I will have to forego use of persistent keys since PSA Crypto persistent keys are also stored  ITS.

PSA Protected Storage uses ITS, so you can still use ITS for PSA Crypto persistent keys.
Talking to our crypto team, they say that users are adviced to use PSA Protected Storage instead of ITS, also from the SPE.

Anthony Ambuehl said:

Alternatively is it possible to use Nordic's customized/encrypted ITS without TF-M?

No, ITS is just available for TF-M.

Anthony Ambuehl said:

Alas, this also requires non-minimal TF-M which I have been unable to fit into nrf9160 along with mcuboot/NSIB. 

How small have you managed to get TF-M?

Anthony Ambuehl said:

so they requested I temporarily proceed on v2.3.0 without TF-M for the nrf9160.

Don't you need TF-M for non_secure to operate the modem?

[Anthony Ambuehl]

Your answer is confusing..

are you saying TF-M is REQUIRED for nrf9160?  That seems strange.  I assume there are examples of using nrf9160 modem without TF-M.  When running without TF-M in the build the application is in the secure domain so it should be able to access the modem without problems.  To be clear, I have adapted my application so that when I build for nrf9160, I build nrf9160dk_nrf9160 instead of nrf9160dk_nrf9160_ns so it completely removes TF-M.

Also BTW, Zephyr does include an implementation of ITS separate from TF-M, however it seems to be incomplete/buggy.

[Sigurd Hellesvik]

Anthony Ambuehl said:

are you saying TF-M is REQUIRED for nrf9160?  That seems strange.  I assume there are examples of using nrf9160 modem without TF-M. 

If I add CONFIG_NRF_MODEM_LIB and CONFIG_BOOTLOADER_MCUBOOT (for partition manager) to the hello world example and build for nrf9160dk_nrf9160, I get the following error:

home/sihe/ncs/nrf/lib/nrf_modem_lib/nrf_modem_lib.c:20:2: error: #error nrf_modem_lib must be run as non-secure firmware. Are you building for the correct board ?

This is from https://github.com/nrfconnect/sdk-nrf/blob/main/lib/nrf_modem_lib/nrf_modem_lib.c#L20-L21

Also documented in Modem lib docs:

"

To use the Modem library, you must make sure that the following requirements are met:

• The application using the Modem library is run in Non-Secure Processing Environment (NSPE).

• The IPC and FPU peripherals are available in NSPE.

• The shared memory resides in the lower 128 KB of RAM.

• The application provides an implementation of the OS interface in the nrf_modem_os.h file.

• The library depends on the nrfx IPC driver or equivalent IPC driver.

"

So you need non-secure firmware (which is done either by the old SPM or the new TF-M) to use our Modem Lib, which is our default and recommended method for using the modem.

Anthony Ambuehl said:

Also BTW, Zephyr does include an implementation of ITS separate from TF-M, however it seems to be incomplete/buggy.

From what I know about ITS, it leverages the Isolation from TF-M from storage.
So other that easy changing between TF-M and non-TF-M builds, I do not see the advantage of this feature.
That being said, Zephyr developers probably know more than me, so might be some good reasons here that I do not see yet.

[Anthony Ambuehl]

My only intention with using PSA Crypto with Zephyr ITS was to have a consistent API and not need to test and maintain 2 different versions of the code.  

With the requirement to have a NSPE for the modem library, I suppose I will need to resume my effort to fit NSIB/Mcuboot/TF-M (experimental) into the nrf9160, that is ultimately the preferred environment for this effort anyway.

[Sigurd Hellesvik]

Anthony Ambuehl said:

My only intention with using PSA Crypto with Zephyr ITS was to have a consistent API and not need to test and maintain 2 different versions of the code.  

The PSA Crypto API is as you say available for both with and without TF-M.
The PSA Crypto API will use ITS as a storage backend if it is available (TF-M active)
If TF-M is not enabled, the PSA Crypto API will not use ITS for key storage, and instead other methods.

So while you can not use ITS as such a consistent API, I think you should be able to use the PSA Crypto API as such.

[Anthony Ambuehl]

We have additional data that we need to securely store that is not a key.  While I could subvert the persistent key interface by importing and exporting data as persistent keys, that seems like a bad design choice.  The persistent storage feature does not store in internal flash which would add other security risks.

Either way I have been able to get my TF-M/PSA based approach to fit into nrf9160 on NCS 2.3.0 so i will close this ticket.

It seems the answers are:

* Zephyr ITS is broken and not officially supported.

* TF-M with ITS requires experimental support since its not included in the minimal configuration... therefore not officially supported 

* TF-M with ITS does seem to work including encryption but it requires a great deal of trial and error to get TF-M size reduced. 

* When reducing TF-M, from my experience, I recommend re-testing all important features after every KConfig change, I found that although sometimes I was able to compile I still sometimes encountered TF-M crashes or encountered certain errors only when a certain capability was tried at run time.

* TF-M crashes are really a pain to debug, there are no logs, and the debugger does not work if main of the non-secure app is not reached.