How to set identity key in tfm configuration?

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?

  • Hi,

    Please see the Provisioning image which demonstrate how to provision a device with an identity key.

  • Hi,

    The use case I am trying to work here is that I have a secure API in TFM mode that imports key using psa_key_import()

    The prj.conf file has below configs:

    # 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 persistance storage
    CONFIG_TFM_ITS_NUM_ASSETS_OVERRIDE=y
    CONFIG_TFM_ITS_NUM_ASSETS=32

    # Increasing size of stack, required for KPA
    CONFIG_MAIN_STACK_SIZE=2048

    Now from this secure API I want to call identity_key_write_key() API. I am unable to call this API successfully. When I enable CONFIG_IDENTITY_KEY, it has dependency to disable config CONFIG_BUILD_WITH_TFM. But that is needed for my implementation where I am using TFM for security.

    I referred to the  Provisioning image  sample but it does not have TFM configs.

    As I stated above, in the idenitytKey library documentation it is written that  " TF-M has access to the identity key using internal APIs and does not need to use this library."


    Is it so that with CONFIG_BUILD_WITH_TFM configuration, 
    CONFIG_IDENTITY_KEY config cannot be used?

  • Hi,

    skirti said:
    I referred to the  Provisioning image  sample but it does not have TFM configs.

    You are right that the provisioning image does not include TF-M. The idea is to use that first (during provisioning), and that will write keys to the KMU (UICR). Then these are accessed subsequently by the firmware running TF-M.

    skirti said:
    Is it so that with CONFIG_BUILD_WITH_TFM configuration, CONFIG_IDENTITY_KEY config cannot be used?

    Yes. Is it so that you want to write the identity key from your non-secure application while using TF-M? If so, that will not work directly, as the KMU and UICR is only accessible from secure mode. When using TF-M (or using a non-secure application in any way), you cannot do this from y our application. So if you want to do that for some reason, you would have to do this from TF-M. And if you would like to initiate it from the non-secure application you would have to make a secure sevice in TF-M that is accessible to the application. You can see an example of that in TF-M secure peripheral partition. This also use a HW peripheral, but you can ignore that part. Remember that TF-M is not a Zephyr application, so configuration etc is done differently.

    I do not have a full understanding of your goal so I cannot say if this approach makes sense in your case, though. It could make sense to back-track a bit to look at the end goals / what you really want to achieve, and then consider how this can be achieved in the best manner.

  • Hello, 
    Thanks for the explanation.

    Sharing complete scenarios for clarity on end goal.

    connectSDK version used: 2.1.0
    Development Board used: nrf5340
    Build command used: west build --build-dir ./build ./ --pristine --board nrf5340dk_nrf5340_cpuapp_ns

    We have build a nonsecure app which call the secure APIs.
    We have a secure API to provision the device and a few secure APIs to perform crypto operations using provisioned keys.
    These APIs we have implemented using TFM secure services.

    The provisioning API takes keys to provision as input. From secure Provisioning API we call psa_import_key() with a specific key_id.
    From other secure APIs we do crypto operations with the specific key_ids that are already provisioned. 

    The prj.conf file looks like below:

    # 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 
    

    This all implementation works fine.

    Problem:

    Now we want to add attestation process.
    We know that we have to use IdentityKey library API identity_key_write_key() 
    to set the attestation key and psa_initial_attest_get_token() to use it but as discussed before config CONFIG_BUILD_WITH_TFM is conflicting with CONFIG_IDENTITY_KEY. 

    Would you please suggest what would be better approach?

     

  • Hi,

    I see. This is the use case for which we have the provisioning image. This provisioning is a one time operation that you typically do in production, and due to the (deliberate) limitation that you can only write to the KMU from secure mode (with the added benefit that you don't include unnecessary code in the application code), we provide the provisioning image as a sample of an image you can run on the device during production to do provisioning, before you program the application firmware that will be used in the field. What is the reason this approach does not work for you?

    If you want to do this from the firmware that will run on the devices in the field, you need to address the problem that this must be done form TF-M (secure), as it cannot be done from your non-secure application. So if you really want to this the way I think you describe, you need to do as I suggest in my previous post and call identity_key_write_key() etc. from TF-M, in you custom secure service. There is absolutely no way you can do this from your non-secure application.

Related