Single-bank DFU bare metal - image verification

[tdfilip]

Hello

I played with the mcuboot_recovery_entry bare metal dfu sample. I noticed that if I sign an application image with an invalid key (invalid on purpose), the firmware loader still downloads the application and overwrites the old one. Then after a reboot, the MCUBoot verifies the image, rejects it and start the firmware loader again. 

Is there a possibility for firmware loader to verify the image signature before overwriting the current image? If no, isn't there a possibility that anyone could start dfu with an invalid image which would remove the current image?

Regards,
Filip

[Hung Bui]

Hi Filip, 

So the hash and signature is located at the image trailer. From what you described, seems that the trailer is not sent before the image is received. So you have a point here that one with an invalid image (and a way to put the device to DFU mode) can brick the device with an invalid image. 

However, even if the signature and hash is sent before the image, one can still spoof a valid signature and hash (copy from a valid DFU package) combine with an invalid image. If you want to have a secure authentication, I guess it has to be implemented before the device enter DFU mode. 

Anyway, I have forwarded your question internally to NCS Bare Metal team, let's see what their take on this. 

[tdfilip]

Hello, is there any update from the NCS Bare Metal team?

Regards,
Filip

[Hung Bui]

Hi Filip, 
Sorry for not getting back earlier. So on NCS baremetal the signature checking is done on the Bootloader/MCUboot side not on the FW loader . This explain why the original image is erased before signature is checked. 

But the device will not be bricked as the image will not be activated due to wrong signature when MCUBoot check that. It will stay in DFU mode and wait for a valid image. 

As mentioned earlier, it doesn't matter much if you check the signature before or after receiving the image, one can get a valid hash and signature combine with an invalid image to get the same effect. 

[PaKa]

So this is a logical limitation with single bank DFUs.

1: you check the signature to validate this is an update for you and it is signed correctly

2: you delete the original image to make space for the new

3: you download the new image

4: you validate that the new image is actually what you was promised to get

5a: image is OK, start using

5b: image is fake, restart in bootloader mode as original image is gone.

You can't validate the image before downloading as you don't have the space to store it. If this is a requrement then you have to use a dual bank solution. This is part of what you gain when giving away memory to the dual bank.

To improve resilience against spoofing you should restrict what devices can trigger an DFU, if you only allow this to happen from securely bonded devices then this means you won't be spoofed by non-connected devices.