Secure DFU signature check wrong

[nevi]

Hi,

I tried the SDK_DIR\examples\dfu\secure_bootloader\pca10040_s132_ble example from nRF5_SDK_16.0.0 with my custom board with nrf52832 mcu.

I followed this guide: 

https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

The DFU process worked well with nRF Connect app.

I tried that I modified one byte in the private key and then regenerate application zip with this wrong key to verify the signature checking. The bootloader is the same of course with the public key belongs to the original private key.

But the bootloader upload this zip without any error and the application is started and run well. So the signature check not works. This is the case if I modify 2 bytes randomly in the private key base64 encoded flie.

But if I generate a totally different key with nrfutil, the DFU process interrupted at the beginning (ble disconnected without any transmission). The same thing happens when I set lower version number than the current. So the version check and the signature check seems to work in these cases.

But I don't understand how can the bootloader check the signature before the data transferred, and why not reject the update if the signature is different (2 byte modified randomly in the private key).

Could anyone explain these?

Thanks,

nevi

[nevi]

I figured out the problem. When I modified some bytes in the private.key file, I actually did not modify the private key itself, just some other fields in the PEM file. I check this with nrfutil keys display --key sk --format hex private.key command. And the 256 bit keys are the same even though the private.key files are different.

And I found the reason why the bootloader able to decide the app firmware validity without all of the firmware data. It checks the signature that received in the first packet (init). And during the post validation it checks the calculated hash against the hash received in the init packet.