Is there a way to store a secure-boot public key in OTP / non-erasable memory to survive ERASEALL / recover in NRF54L15?

[darav]

We are using nRF54L15 devices and have enabled secure boot.
Our current setup is:

• Firmware images are signed with a private key

• The corresponding public key is provisioned into the device (via KMU)

• Unsigned firmware is rejected during FOTA, and rollback works as expected

This provides protection against unauthorized FOTA updates.

However, we observe that using ERASEALL or the nrfutil device recover command erases the KMU contents, including the provisioned public key. After recovery, the device can be flashed with a new firmware image, which will then run.

• We want to store the public key in one-time programmable (OTP / eFuse) memory

• Once provisioned, the key must not be erasable, changeable, or replaceable, even after ERASEALL or recovery

• Only firmware correctly signed with the corresponding private key should ever boot

• If verification fails, the device should remain locked / unusable

Is there any such facility available in the NRF54L15 device along with NRF SDK

[Vidar Berg]

Hello,

In production devices you can enable the APPROTECT and ERASE protection (https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/ctrl-ap.html#d574e139) to prevent the device from being erased or re-programmed again through the debug interface.

Best regards,

Vidar

[darav]

After enabling the APPROTECT and ERASE protection, can the "nrfutil device recover" command erase all the memories of the device?
https://docs.nordicsemi.com/bundle/nrfutil/page/nrfutil-device/guides/programming_recovery.html
The above mentioned documentation mentions -> "The nrfutil device recover triggers CTRL-AP.ERASEALL, which is available regardless of the AP-Protect status."

[Vidar Berg]

From the doc link I posted in my first reply:

[darav]

Okay, so enabling the  TAMPC.PROTECT.ERASEPROTECT and UICR.ERASEPROTECT will mitigate the possiblity for any unauthorized access to erase the device memory by any means. Is that correct?

I'm assuming the right way to enable these bits are using the "nrfutil device write --address <ADDRESS> --value <VALUE>"

By enabling this, we will be able to flash new firmware to the device normally with no issues, just that the complete memory wont be erased, right?

And for disabling this, the article mentions -:
"When erase protection is enabled, both the debugger and on-board firmware are required to disable it. The same non-zero 32-bit KEY value must be written to the debugger register ERASEPROTECT.DISABLE and CPU register ERASEPROTECT.DISABLE to disable erase protection. When both registers have been written with the same non-zero 32-bit KEY value, the device is automatically erased as described in Erase all. The access ports will be re-enabled on the next reset once the secure erase sequence has completed."

Here which key is supposed to be used? How should it be written from the firmware and debugger?
And disabling it will reset the device to function afresh -- can normally erase the full device, use nrfutil device recover and so on, right?

Thanks in advance.

[Vidar Berg]

It must be used in combination with APPROTECT if you want to prevent the re-programming of the device. Also, accessing the debug registers is not supported by nrftuil device so it cant unlock the device if ERASEAPROTECT and APPROTECT have both been been enabled (Note: this may leave the device "bricked" if not handled correctly). Instead you must use Jlink commander or some other debugger tool that gives you low level access to these registers. Here is another relevant forum thread on this topic:   RE: How to enable APPPROTECT, SECUREAPPROTECT and ERASEPROTECT on nRF5340?