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!

Parents
  • 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.

  • So far, I've done the following: encrypt .bin file, leave .dat file untouched. When transferring, I leave everything as is, however, just before write to flash (the 2 calls to nrf_dfu_flash_store()) I decrypt the data into a new buffer, and instead of writing what is in m_data_buf, I change the call to write the decrypted content from the buffer. This way, the CRC works fine (as you outlined, it's computed on the transfered data), so I can transfer 100% of the object. However, once transfer is finished, it doesn't start the firmware (I don't know the exact reason why yet). Regarding the transfer resume, I'm going to use AES CTR (so far I'm using a dumb XOR only), and it might be slightly annoying to program, but the idea is to determine the offset, compute the AES CTR blocks for the bytes to be written to flash, XOR my decryption buffer and I'm done.

Reply
  • So far, I've done the following: encrypt .bin file, leave .dat file untouched. When transferring, I leave everything as is, however, just before write to flash (the 2 calls to nrf_dfu_flash_store()) I decrypt the data into a new buffer, and instead of writing what is in m_data_buf, I change the call to write the decrypted content from the buffer. This way, the CRC works fine (as you outlined, it's computed on the transfered data), so I can transfer 100% of the object. However, once transfer is finished, it doesn't start the firmware (I don't know the exact reason why yet). Regarding the transfer resume, I'm going to use AES CTR (so far I'm using a dumb XOR only), and it might be slightly annoying to program, but the idea is to determine the offset, compute the AES CTR blocks for the bytes to be written to flash, XOR my decryption buffer and I'm done.

Children
No Data
Related