DFU firmware encryption

[Jonathan]

Hi,

I would like to implement DFU with firmware encryption. I'm aware this isn't present in SDK 12 and would like to modify the secured bootloader to implement it.

As far as I understand, a DFU package is a zip file containing a manifest, and sets of 2 files, a .dat and a .bin . Is it right that the .bin is pure image, and .dat is the header/init packet?

My plan was to encrypt the .bin file, then, in the DFU bootloader, decrypt just before writing to flash. Does this sound like a good approach?

Thanks for your help!

[Hung Bui]

I don't see any problem with this.

And you are correct, .bin file is the pure image, and .data is the init packet.

If you going to encrypt the .bin file and decrypt it after you receive it on the bootloader, you need to modify the bootloader so that hash and signature is only validated after the image is decrypted.

[Jonathan]

@SRA, I can't post the code due to NDA, but if you take my last 2 posts, you have everything!

• Encrypt your .bin file (keeping it to the same size, changing it would have side effects I'm sure, requiring more changes)
• Decrypt received buffers in dfu_req_handling.c, in nrf_dfu_data_req(...), before the calls to nrf_dfu_flash_store(...) (2 calls). See my if above.
• In nrf_dfu_postvalidate(...), re-compute the CRC in "if (res_code == NRF_DFU_RES_CODE_SUCCESS)", in the DFU_FW_TYPE_APPLICATION branch of the switch. This is because so far, the CRC was computed on encrypted data transfered, and on next startup the CRC will be compared with CRC of the code actually written in flash, so we need CRC of the decrypted version. This could also be computed while receiving the code, after decrypting it, on the fly, but I'm not sure there's an advantage to do so.