As per my understanding, identity key can be set using idenitytKey library.
But as the documentation says, " TF-M has access to the identity key using internal APIs and does not need to use this library."
I would like to know how to set identitykey in TFM configuration?
Hello,
Thanks for the quick response.
We are not calling identity_key_write_key() from nonsecure directly. Below is the sequence of calls:
1. From nonsecure App -> Call Provisioning API
2. Custom TFM secure services are implemented
3. Call goes to secure Provisioning API -> Here trying to call identity_key_write_key() API <PROBLEM>
Building with below command:
west build --build-dir ./build ./ --pristine --board nrf5340dk_nrf5340_cpuapp_ns
prj.conf: at path(project root directory)
# TFM config
CONFIG_BUILD_WITH_TFM=y
CONFIG_TFM_PROFILE_TYPE_NOT_SET=y
CONFIG_TFM_IPC=y
# PSA crypto config
CONFIG_PSA_CRYPTO_DRIVER_CC3XX=y
CONFIG_PSA_CRYPTO_DRIVER_OBERON=n
# Increased TFM partition size from 0x50000(Default) to 0x60000
CONFIG_PM_PARTITION_SIZE_TFM=0x60000
# Increased max number of assets that can be used for persistence storage
CONFIG_TFM_ITS_NUM_ASSETS_OVERRIDE=y
CONFIG_TFM_ITS_NUM_ASSETS=32
As per our understanding, config CONFIG_BUILD_WITH_TFM instructs the Zephyr build process to additionally generate a TF-M image for the Secure Execution environment, along with the Zephyr image. Finally we get a merged.hex which has both TF-M image and Zephyr image, that we are using to flash the device.
So, here the call to identity_key_write_key() is from a secure API implemented through TFM custom secure services.
So I did not understand, are you suggesting something different that I missed?
Or there is some other build method that we should follow?
Hi,
skirti said:As per our understanding, config CONFIG_BUILD_WITH_TFM instructs the Zephyr build process to additionally generate a TF-M image for the Secure Execution environment, along with the Zephyr image. Finally we get a merged.hex which has both TF-M image and Zephyr image, that we are using to flash the device.
That is correct.
skirti said:So, here the call to identity_key_write_key() is from a secure API implemented through TFM custom secure services.
Not unless you have added a secure service that does this? The library we provide (and use in the provisioning sample) is designed to run in secure code, and we do not provide any secure service for calling this via TF-M.
skirti said:So I did not understand, are you suggesting something different that I missed?
I think so. We do not have any code for doing provisioning via TF-M. The way we intended for this to be done, and what we recomend, is to do provisioning as you see in the provisioning image sample, that goes hand in hand with the TF-M: PSA template. The latter use TF-M, but not the former.
skirti said:Or there is some other build method that we should follow?
What you are describing is not supports out of the box. So if you really want to support doing provisioning while using TF-M (and not before), you must add support for it like I have outlined briefly before, by making a secure service that does it (essentially exposing identity_key_write_key or a similar function) to the non-secure application via a secure service implemented in TF-M.
Okay, understood. Thanks. So we will add secure service for calling identity_key API via TF-M.
But how we will overcome the configuration issue.
As said before, when I add config CONFIG_IDENTITY_KEY in prj.conf it conflicts with CONFIG_BUILD_WITH_TFM.
You cannot overcome it. When you use CONFIG_BUILD_WITH_TFM that means your application must be non-secure, and the KMU (which you need access to in order to use CONFIG_IDENTITY_KEY) is only accessible from secure-mode. That is why that needs to be doen in TF-M if you want to do it like this (though the recommendation is to use a separate binary to do provisioning before you program your application).
So in other words, using CONFIG_IDENTITY_KEY with your non-secure application cannot and will not work. (And to use this library or another way to access the KMU to write the identity key from TF-M you also cannot use this config with TF-M, as this is a Zephyr configuration, and TF-M is not a Zephyr application).
Okay understood.
Would like to confirm one more point.
I was able to call API nrf_cc3xx_platform_identity_key_store(NRF_KMU_SLOT_KIDENT, <key>) to save the key and use psa_initial_attest_get_token() with the saved key.
With this I need not to enable any config. Saw below in ./nrfxlib/nrf_security/tfm/CMakeLists.txt file:
# Platform cannot be selected when building for TF-M, because TF-M itself has
# control of the CryptoCell. Therefore, specifically for building TF-M we
# enable it manually.
set(CONFIG_NRF_CC3XX_PLATFORM True)
As per my understanding due to availability of this API in TFM we are able to call nrf_cc3xx_platform_identity_key_store() from a custom secure service.
Do you see any security risk in this approach?