CONFIG_TFM_ITS_ENCRYPTED=y seems broken on 2.6.x

[franchan]

Hello,

Using the sample PSA Protected Storage on the nrf5340 DK with NCS v2.6.1 (and v2.5.2). My prj.conf contains these settings:

#
# Copyright (c) 2021 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: Apache-2.0
#

CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=3

CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_MEDIUM=y
# this settings makes the nrf53 rebooting whole the time on NCS v2.6.x :-(
CONFIG_TFM_ITS_ENCRYPTED=y



CONFIG_TFM_LOG_LEVEL_SILENCE=n
CONFIG_TFM_SPM_LOG_LEVEL_DEBUG=y
CONFIG_TFM_EXCEPTION_INFO_DUMP=y

CONFIG_LOG_MODE_IMMEDIATE=y

I flash the sample provisioning_image first. Next I flash the PSA PS storage sample build with v2.6.x. With v.2.6.x I see TF-M logging indicating constant rebooting. Here's the output from TF-M, UART0. There's no logging on UART1:

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
The UICR->APPROTECT register is now configured to deny debugging access for the network core!
Success!
Writing random Hardware Unique Keys to the KMU.
Success
[Sec Thread] Secure image initializing!
TF-M isolation level is: 0x00000001
Booting TF-M v2.0.0
Creating an empty ITS flash layout.
Creating an empty PS flash layout.
[INF][Crypto] Provisioning entropy seed... [Sec Thread] Secure image initializing!
TF-M isolation level is: 0x00000001
Booting TF-M v2.0.0
[INF][Crypto] Provisioning entropy seed... [Sec Thread] Secure image initializing!
TF-M isolation level is: 0x00000001
Booting TF-M v2.0.0
... continues repeating like this ...

With NCS v2.5.2 I do not see any logging on UART0 but UART1 shows correct output from the application:

*** Booting nRF Connect SDK v3.5.99-ncs1-1 ***
[00:00:00.410,369] <inf> provisioning_image: Successfully verified PSA lifecycle state ASSEMBLY!
[00:00:00.410,430] <inf> provisioning_image: Successfully switched to PSA lifecycle state PROVISIONING!
[00:00:00.410,430] <inf> provisioning_image: Generating random HUK keys (including MKEK)
[00:00:00.473,571] <inf> provisioning_image: Writing the identity key to KMU
[00:00:00.473,602] <wrn> identity_key: WARNING: Using a dummy identity key not meant for production!
[00:00:00.474,700] <inf> provisioning_image: Success!
*** Booting nRF Connect SDK v2.5.2 ***
Protected Storage sample started.
PSA Protected Storage API Version 1.0
Writing data to UID1: The quick brown fox jumps over the lazy dog
Info on data stored in UID1:
- Size: 44
- Capacity: 0x 1
- Flags: 0x 0
Read and compare data stored in UID1
Data stored in UID1: The quick brown fox jumps over the lazy dog
Overwriting data stored in UID1: Lorem ipsum dolor sit amet
Writing data to UID2 with overwrite protection: The quick brown fox jumps over the lazy dog
Attempting to write 'Lorem ipsum dolor sit amet' to UID2
Got expected error (PSA_ERROR_NOT_PERMITTED) when writing to protected UID
Removing UID1

Should I add another setting(s) when building with v2.6.x to make CONFIG_TFM_ITS_ENCRYPTED work at runtime? I have been trying lots of different settings already last couple of days.

There likely is no release test case to verify the usage of CONFIG_TFM_ITS_ENCRYPTED at runtime on real hardware (if so, one should not have released v2.6.x). If there is no test case, how can one guarantee that CONFIG_TFM_ITS_ENCRYPTED is actually "encrypting" even in NCS v2.5.2? And that there will be no regression introduced in later versions? Might the test case be missing from the upstream TF-M project? I could add an issue in their github repo?

Thank you!

Kind regards,
francis

[dejans]

Hi,

Which board do you use?

Can you show logs after flashing provisioning_image sample (in both NCS v2.5.2 and NCS v2.6.1) to both nrf5340-dk and your custom board (if it is not nrf5340-dk)?

Best regards,
Dejan

[franchan]

Hello Dejan,

Could you verify the issue on your side as well? If so, is there a workaround or do you miss some information? Thanks.

Kind regards,
francis

[dejans]

Hi Francis,

I will get back to you by the end of next week.

Best regards,
Dejan

[franchan]

Thank you Dejan, looking forward to that!
Kind regards, francis

[dejans]

Hi Francis,

There is currently support only for TF-M profiles minimal and type not set, but you are trying to use profile type medium.

You could try to add the following configuration options:

CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_PSA_WANT_GENERATE_RANDOM=y
CONFIG_NRF_SECURITY=y

Best regards,
Dejan

[franchan]

Hello Dejan,

Many thanks! It was actually "CONFIG_PSA_WANT_GENERATE_RANDOM=y" that did the trick for v2.6.x!

Could you explain the need for "CONFIG_NRF_SECURITY=y"? Because it seems to also work without that setting as well.

I will use CONFIG_TFM_PROFILE_TYPE_NOT_SET=y (CONFIG_TFM_PROFILE_TYPE_MEDIUM also works but better to follow your guideline that this profile is not supported).
My reason for using MEDIUM originally is that the documentation explicitly explains it uses level 2. While there's no documentation on what level TYPE-NOT-SET uses ...

Kind regards,
francis

[dejans]

Hi Francis,

franchan said:

Could you explain the need for "CONFIG_NRF_SECURITY=y"? Because it seems to also work without that setting as well.

CONFIG_NRF_SECURITY is included together with CONFIG_BUILD_WITH_TFM. When they are both included as shown in Building with TF-M, TF-M secure image enables hardware acceleration of the CryptoCell and nRF Security Subsystem controls features enabled by TF-M.

Best regards,
Dejan