• State Verified Answer
  • Replies 2 replies
  • Subscribers 75 subscribers
  • Views 438 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 326975
Options

Migration SDK 2.4.2 to 2.6.1: CONFIG_PSA_NATIVE_ITS -> CONFIG_TRUSTED_STORAGE

ProfNocturne

Hello,

my application is running without TF-M and I store a password persistently in trusted memory using "psa_import_key()".
This works with SDK 2.4.2. After that I made a new firmware using 2.6.1. and changed CONFIG_PSA_NATIVE_ITS to CONFIG_TRUSTED_STORAGE. After the firmware update (No mass erase!) the application doesn't find the password anymore.

For SDK 2.6.x there is a migration guide which explains this behavior:

Migration guide for nRF Connect SDK v2.6.0 (nordicsemi.com)

"The Kconfig option ``CONFIG_PSA_NATIVE_ITS`` is replaced by the Kconfig option :kconfig:option:`CONFIG_TRUSTED_STORAGE`, which enables the new :ref:`trusted_storage_readme` library.
The :ref:`trusted_storage_readme` library provides the PSA Internal Trusted Storage (ITS) API for build targets without TF-M.
It is not backward compatible with the previous PSA ITS implementation.
Migrating from the PSA ITS implementation, enabled by the ``CONFIG_PSA_NATIVE_ITS`` option, to the new :ref:`trusted_storage_readme` library requires manual data migration."

So, is my understanding right: If I do use TF-M with 2.4.2 and update to 2.6.1 the password could be still accessed without manual data migration?

Currently my application is in the development phase. So the lost of the password (without manual data migration) is not a big problem.
Due to secure development life cycle in production phase there is the need to update the application regularly by the customer with the newest SDK. So I cannot use this SDK version forever.
Is it in future guaranteed that there are no more migrations / changes to the "persistent security data" - API?
Or is there another way to store the password secure independently from API changes?


Do you have a example how to manually migrate the data?

Best regards,

Jan

Parents
  • +1

    Hi Jan,

    We do not have any example of how to manually migrate the data. If you were to choose to do so, it would be up to you. It seems thi sis not a reqiuerment in this case though, as you are in development?

    Regarding always sticking with the newest SDK thatoften makes sense when making new products, and generally, selecting the latest SDK when going to production is normally sensible. But once a device is in the most will prefer to stick with the SDK they are using as it is working in the product, and only apply critical fixes to that SDK. This reduces risk and work related to migration, which is in some cases (like this) not trivial for devices in the field. I should note thogh that as the nRF Connect SDK and the nF5340 are becoming more mature, you can expect less breaking changes between SDK versions going forward. But I cannot make any guarantees that any specific APIs will never change sometime in the future.

    Br,

    Einar

Reply
  • +1

    Hi Jan,

    We do not have any example of how to manually migrate the data. If you were to choose to do so, it would be up to you. It seems thi sis not a reqiuerment in this case though, as you are in development?

    Regarding always sticking with the newest SDK thatoften makes sense when making new products, and generally, selecting the latest SDK when going to production is normally sensible. But once a device is in the most will prefer to stick with the SDK they are using as it is working in the product, and only apply critical fixes to that SDK. This reduces risk and work related to migration, which is in some cases (like this) not trivial for devices in the field. I should note thogh that as the nRF Connect SDK and the nF5340 are becoming more mature, you can expect less breaking changes between SDK versions going forward. But I cannot make any guarantees that any specific APIs will never change sometime in the future.

    Br,

    Einar

Children
Related
Terms of service