Good afternoon.
We have an issue which we'd like to prevent, but suspect it may entail changing the out-of-the-box MCU Boot / SMP BLE code / process.
If we flash our firmware with a custom key (i.e.: mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE), and then attempt to perform an OTA DFU using the Nordic Device Manager mobile application on iOS of a firmware built with the development (i.e.: non-custom) key, the device resets, but MCU boot will correctly not boot into the devkey-signed firmware. We then perform an OTA DFU of firmware that is custom-key signed, but is Test only and never confirms. MCU boot correctly boots into the firmware, executes the code, encounters a system restart and then rolls back to the original firmware that was in Slot 0. If we reset the device, MCU boot will correctly boot into the confirmed image in Slot 0. So now we have two custom-key signed images: a confirmed image in Slot 0 and the unconfirmed image swapped back by MCU boot in Slot 1.
Where it gets odd is if we then perform an OTA DFU of the firmware signed with the out-of-the-box development key. First, the DFU process doesn't actually result in a firmware image transfer (we noticed that the Hash reported by Device Manager was the same between the otherwise-identical custom-key signed and devkey-signed firmware images). Instead, the out-of-the-box SMP DFU process (enabled with CONFIG_MCUMGR_SMP_BT=y) reboots the device and re-executes the unconfirmed image in Slot 1. The security implication is that if you have a custom signed, unconfirmed image in Slot 1, an OTA DFU of a devkey signed image can trigger its execution by the bootloader, even though the image involved in the DFU lacks a signature that would otherwise be required by mcuboot.
It "feels" like DFU is setting a flag indicating to MCU boot to try to boot the image in Slot 1 and that it is doing so based upon the app core image hashes being the same, since, presumably, the hashes do not include the digital signature?
