nRF AntiCloning methods

[optical]

Hello,

I'm wondering how you tackle the issues for manufacturing companies to prevent overproduction or firmware modification to remove anticloning features of the firmware. 

For the nRF91 and others, you have an immutable bootloader, which imposes a certification trust on the firmware on the chip. But how do you ensure that the immutable bootloader has not been altered by the manufacturing company to boot other firmware? Do the nRF91 and nRF52 series have some kind of firmware verification feature such as only signed immutable bootloaders are booted? So the integrity of the immutable bootloader is verified?

Do you plan such a feature for the next-gen nrf9161 and the smaller variant?

Do you provide services to pre-flash your chips and lock them so the manufacturer does not have access to the immutable firmware? Do you have any suggestions on how to go around this problem? We currently are using an ECC to place a signature in every chip based on the Uniq id of the chips and the firmware is verifying it. This provides us partial protection but it is not a bulletproof solution.

[Einar Thorsrud]

Hi,

Do the nRF91 and nRF52 series have some kind of firmware verification feature such as only signed immutable bootloaders are booted? So the integrity of the immutable bootloader is verified?

In the nRF52, nRF53 and nRF91 root of thrust is established by the immutable bootloader (in nRF53 and nRF91 there is also the use of the KMU but that is details in this regard). See An Introduction to Trusted Firmware-M (TF-M) for an introduction to this. These devices to not have a hardware root of trust. This will improve in coming products, but I cannot discuss non-public devices. I suggest you contact your Nordic regional sales manager about new features in new products.

Do you provide services to pre-flash your chips and lock them so the manufacturer does not have access to the immutable firmware?

We do not normally provide programming services, but I suggest you ask sales about that. Ignoring that, it is possible to protect the content of the flash from being read back using the Access port protection mechanism. So if the devices are programmed beforehand and that is enabled, the connect cannot be read back at a later stage (including on the manufacturing line). Note that it will also not be possible to write anything via SWD after this point. See CTRL-AP for details.

Do you have any suggestions on how to go around this problem?

If the devices are used together with something cloud connected, you can typically use that to validate the identity of a device. And if someone have been able to clone the device identity it may be possible to detect that on the cloud side during onboarding for instance. There are also approaches that can be used like generating identity keys on the device and never making those accessible from the outside world (this is possible with the nF5340 and nRF91 where symmetrical keys kan be stored in the KMU with permissions preventing them from being read out). I suggest having a look at the Securing IoT products with PSA Certified APIs blog post, as well as the TF-M: PSA template and accompanying TF-M: Provisioning image.