NRF5340 network core updates built with 3.4.0 not backwards compatible and don't work with both encryption and downgrade prevention enabled

[grifcjrkly]

I ran into a couple issues with network core updates on NRF5340 when updating from 3.1.0 to 3.4.0 SDK.

Problem 1) Network core updates are not backwards compatible with 3.1.0 bootloaders with downgrade prevention

NCS 3.4.0 now encrypts the controller firmware (when encryption key specified) and sets --rom-fixed to the appropriate slot address on network core, which populates the load address of the MCUboot header.

Setting the load address causes issues with a prior bug in the 3.1.0 SDK, which was corrected by commit 8d3b38e224835f1a96c5567104b19d6383d75c6f "modules: mcuboot: hooks: nrf53_hooks: Fix invalid offset". However, the old bootloader has the bug, and that is what is flashed to my fielded devices. So the fw_info search now fails with the new images. 

Assuming load address is corrected for, the firmware is now also encrypted, so the search for fw_info also fails for that reason, because the data is now encrypted.

I was able to patch b0_mcuboot_signing.cmake to create another signed bin after the build which is not encrypted and has rom fixed set to zero. It appears to be accepted by both the 3.1.0 and 3.4.0 bootloaders. I think that is probably what I'll have to go with for already fielded bootloaders.

Problem 2) Network core updates with encryption are not compatible with downgrade prevention on 3.4.0 bootloaders

The new bootloaders have the fix for the load address problem, but the controller updates are now encrypted, so the fw_info search fails. 

Ultimately, I'd like to have simultaneous secure update of the application and network cores with downgrade protection. I'll take encryption of the controller, but it's not a must. I'm wondering if there is some configuration that is expected to support this on the NRF5340 without patching SDK that I should have migrated to as part of the SDK update process, but missed it in the documentation.

I haven't tried (or investigated much) the hardware based downgrade protection, but given I think it might use TLVs to communicate the counters, it might circumvent the encryption issue.

[Vidar Berg]

Hello,

I agree that the HW downgrade protection mechanism should work with encryption, since the counter value will be stored in the unencrypted TLV area as you said. However, there do not appear to be any tests covering this exact configuration in SDK. But since this would not be compatible with existing devices in the field anyway, I wonder if it might be better to rely on the existing SW based protection (wth FW info struct embedded in the image) and keep the netcore image unencrypted to keep the bootloader behavior consistent across all devices. Continuing to ship new devices with the SDK v3.1.0 based bootloader could also be an option.

I was able to patch b0_mcuboot_signing.cmake to create another signed bin after the build which is not encrypted and has rom fixed set to zero. It appears to be accepted by both the 3.1.0 and 3.4.0 bootloaders.

The signed unencrypted version may not be included in the application .zip package, but it should be included in the build output (zephyr.signed.encrypted.bin vs. zephyr.signed.bin), or is that not the case? It also looks like you may be able to avoid removing the --rom-fixed if you instead disable the CONFIG_MCUBOOT_CHECK_HEADER_LOAD_ADDRESS Kconfig option in your v3.4.0 bootloader.

Best regards,

Vidar

[grifcjrkly]

Update of the application core works. My issues have to do with updating the network core.

With old bootloader, network core image needs to be unencrypted and zeroed load address. When new bootloader, network core image just needs to be unencrypted. Problem is that SDK 3.4.0 doesn't generate unencrypted image by default as far as I can tell, only signed_by_mcuboot_and_b0_hci_ipc.bin, which is encrypted. So network core updates are broken in the SDK as it currently exists if CONFIG_NRF53_MULTI_IMAGE_UPDATE and CONFIG_PCD_READ_NETCORE_APP_VERSION are enabled.

I looked more into the hardware based protection for the network core, i.e. enable CONFIG_SB_MONOTONIC_COUNTER_ROLLBACK_PROTECTION for b0n (nrf/samples/nrf5340/netboot). b0n doesn't increment the monotonic counter, so that would presumably need to change, but otherwise rest of the support seems there. The security counter value in this context is fw_info.version, which would be available to b0n by the time it was evaluating it.

To fix the software based downgrade check on MCUBoot side, it probably needs to move the version check to the boot_copy_region_post_hook. It could do the same version check right before doing a network core update I would think, but this would ensure image was decrypted.

There is also this function boot_validated_swap_type that I haven't quite figured out which attempts a network core update under some circumstances. Given that would execute prior to any copy operation, not sure how that would work under any circumstances, because the RAM partition used for the PCD copy would not yet be populated. The function header indicates its purpose is to determine the swap type, but it also seems to be doing version checks, cid/vid checks, and trigging an actual network core update. It doesn't execute in practice during my normal update path, perhaps meant to handle some interrupted update cases.