This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU firmware encryption

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!

  • Jonathan, would you consider posting your code/changes for the community?

  • @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.
  • For encryption of firmware image only:

    • Add a static boolean m_image_encryption
    • In dfu_handle_prevalidate(...), set this boolean to false, and in the swtich(p_init->type), in branch "DFU_FW_TYPE_APPLICATION", set it to true.
    • In your decryption code, decrypt only if this boolean is set. (Note I haven't tried encrypting anything else than firmware, encrypting bootloader might be of interest, and I would not encrypt the SD, obviously)
  • When you say keep the same size, did you pad your bins or while decrypting did you pad or did it just work out where that wasn't needed?

    And just checking but did you keep the private key signature in the SecureDFU?

  • I didn't do anything that would affect the bin file size. You can try but you may need to apply more changes for it to work [unsure]. One thing to keep in mind also is the transfer can be resumed, so unless you want to kill that feature, you'll need an encryption that makes this possible [my XOR one does, but it's not a proper encryption]. I did keep the private key signature, having it means during transfer I don't have to worry about malleability of the chosen encryption algorithm as any tampering will be detected at signature checking.

Related