Firmware protection

Hello,
I would like to get a few info concerning the protection of my firmware on a nRF910 custom board.

#1 - Is image encryption supported ? While I found some info concerning encryption (docs.nordicsemi.com/.../encrypted_images.html) , I was unable to find any details/examples on theimplementation. I also found DevZone thread from ~2 years ago that clearly state that this feature was not supported at that time.

#2 - I am using nRFCloud. The FOTA process works great with the dedicated library ... that also hides a lot of details. Does the HTTP download uses any encryption ?

#3 - How can I enable read protection. Even if the image encryption is used, the firmware in the primary slot will always be not-encrypted. This means that anyone having physical access to the SWD pin can read back the firmware ... unless it's protected.
I am looking for a way to prevent reading the memory, but not writing (I want to be able to re-program the device if needed).

Thanks

Vincent

  • Thanks for your help.

    I found a way to enable readback protection using the following console command:

    nrfjprog --rbp ALL -f nrf91

    It seems to work as expected.

    I am still interested in "built in" way to enable readback protection, as this nrfjprog is an extra step during the production process, which can be easilly forgotten.

    That would be either a KCONFIG, a piece of code to run at startup, a compilation parameter, ...

  • Hi Vincent,

    My apology for another long waiting time.

    In a secure by separation setup, TF-M is in the Secure Processing Environment (SPE), and the application is in the Non-secure Processing Environment. This separation is enforced by the SPU.

    The APPROTECT and SECUREAPPROTECT bits in the UICR registers control readback protection. However, all of the UICR registers can only be accessed from the SPE.

    To allow the application to set the APPROTECT bit, there has to be a trust service provided by TF-M to do this. However, this service doesn't exist yet. I have found a feature request for it registered internally, but it hasn't been worked upon, and I cannot comment about when it would be.

    For the time being, you can create a custom trust service following this sample: TF-M secure peripheral partition.

    Note that in the PSA Template sample mentioned in my last reply, the disabling of debugging is done by TF-M. This is done entirely in the SPE.
    This solution also requires that the device is first provisioned with the TF-M: Provisioning image, which is another step done during production.
    If you already have this step in your production process, then it would not be an additional step. However, the opposite is true.

    Once again, my apology for the delay.

    Hieu


    Please be informed that our team is currently having reduced availability due to the Easter holiday. There will be some delays in our response during this time, but we will respond to you at the earliest opportunity. Our apologies for the inconvenience.

Related