DFU firmware encryption

RE: DFU firmware encryption

Jonathan — Fri, 16 Jun 2017 04:47:36 GMT

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.

RE: DFU firmware encryption

SRA — Thu, 15 Jun 2017 19:36:11 GMT

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?

RE: DFU firmware encryption

Jonathan — Thu, 15 Jun 2017 16:17:45 GMT

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)

RE: DFU firmware encryption

Jonathan — Thu, 15 Jun 2017 16:13:51 GMT

@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.

RE: DFU firmware encryption

SRA — Thu, 15 Jun 2017 15:53:55 GMT

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

RE: DFU firmware encryption

Jonathan — Wed, 31 May 2017 13:15:41 GMT

So this is it, thank you so much guys!

One more thin I did (and you're welcome to tell me there's a better way): in prevalidate, I set a global variable m_image_encryption depending on the type of image.

And for reference here's my great encryption/decryption code:

        if (m_image_encryption)
        {
            for (int i = 0; i < m_data_buf_pos; i++)
            {
                m_data_buf[m_current_data_buffer][i] ^= 0x5A;
            }
        }

It is to be inserted in nrf_dfu_data_req() before each of the 2 calls to nrf_dfu_flash_store(). (And no, don't consider xoring with any key safe)

Additional tips to whoever would like to do something similar: when using nRF Connect on Android, if something seems to not work, kill the app and restart it.

RE: DFU firmware encryption

Jonathan — Wed, 31 May 2017 12:41:39 GMT

I added:

s_dfu_settings.progress.firmware_image_crc = crc32_compute((uint8_t*)m_firmware_start_addr, m_firmware_size_req, NULL);

in the switch that sets NRF_DFU_VALID_APP

RE: DFU firmware encryption

Vidar Berg — Wed, 31 May 2017 12:07:32 GMT

You're right, forgot that CRC was checked on startup. Suggest to compute the CRC in the post-validate step instead (image is already validated by the hash).

In post validate:

Replace:

    p_bank->image_crc = s_dfu_settings.progress.firmware_image_crc;

with something like this:

switch (p_init->type)
{
    case DFU_FW_TYPE_APPLICATION:
        // s_dfu_settings.progress.firmware_image_crc 
        p_bank->image_crc = crc32_compute((uint8_t *)MAIN_APPLICATION_START_ADDR, m_firmware_size_req, NULL);
        break;
    ...
}

RE: DFU firmware encryption

Jonathan — Wed, 31 May 2017 11:54:39 GMT

I'm almost there. nrf_dfu_app_is_valid() fails, the CRC stored in s_dfu_settings.bank_0.image_crc is the CRC of the encrypted image (ie the one computed on the fly during image transfer).

RE: DFU firmware encryption

Vidar Berg — Wed, 31 May 2017 09:33:30 GMT

Note that you can extend the init packet to include IV/nounce if needed (to avoid reuse). More about that here: infocenter.nordicsemi.com/.../nrfutil_customizing.html

RE: DFU firmware encryption

Vidar Berg — Wed, 31 May 2017 09:24:35 GMT

Forgot to point out that you need to generate the init packet first, as you said. This should work.

RE: DFU firmware encryption

Jonathan — Wed, 31 May 2017 09:22:28 GMT

Ok there's just one thing I think I need to clear... When checking the image hash, what does the bootloader use? Does it compute new firmware hash by reading it from the flash? That's how I understand it. And then it seems to me I could leave .dat file intact, encrypt .bin after generating .dat, and decrypt data just before writing to the flash memory. CRC is always computed on encrypted data, SHA2 is always computed on the decrypted data. Am I wrong? I'm gonna flash again my firmware and put a breakpoint in nrf_dfu_postvalidate. Thank you guys!

RE: DFU firmware encryption

Jonathan — Wed, 31 May 2017 09:18:17 GMT

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.

RE: DFU firmware encryption

Hung Bui — Wed, 31 May 2017 09:15:45 GMT

I agree with Vidar. You can encrypt the .bin file and then generate init packet base on the encrypted binary. Then you don't need to modify the .dat file. If you stil want to read/modify the .dat file manually you can have a look here.

RE: DFU firmware encryption

Vidar Berg — Wed, 31 May 2017 07:23:01 GMT

Response was too long for one comment:

Something to be aware of, the bootloader stores DFU progress in bootloader settings to allow DFU to continue in case of power loss, which will need to be modified if you are using a stream cipher for decryption (i.e., include decryption state in progress data). This feature can be disabled by making the following change in dfu_req_handling:

case NRF_DFU_OBJECT_OP_SELECT:
            NRF_LOG_INFO("Valid Command: NRF_DFU_OBJECT_OP_SELECT\r\n");
            p_res->crc = 0; //s_dfu_settings.progress.command_crc;
            p_res->offset = 0;  //s_dfu_settings.progress.command_offset;
            p_res->max_size = INIT_COMMAND_MAX_SIZE;
            break;

Also, in case you are not aware of it, nrfutil has an option for viewing init packets in a more readable format:

nrfutil pkg display app_dfu_package.zip

RE: DFU firmware encryption

Vidar Berg — Wed, 31 May 2017 07:22:01 GMT

The bootloader uses the hash from the init packet to verify the authenticity and integrity of the FW image in the post validation step, while the checksum values (sent upon request) are only used by the dfu controller to verify that the data is received correctly during the transfer. For instance, to verify that a data object is valid before issuing the EXECUTE command. In other words, the bootloader must compute the CRC on encrypted data.

RE: DFU firmware encryption

Jonathan — Tue, 30 May 2017 18:06:35 GMT

Thank you very much for the suggestion! I'm now looking at changing the CRC in my update package, but something puzzles me... I can't find the CRC inside the DAT file. I was under the impression it would follow struct dfu_init_command_t (or dfu-cc.proto). The first 16 bytes are 12 84 01 0A 3E 08 01 12 3A 08 01 10 33 1A 02 87, 87 could match with SD requirement, but 12 (first one) certainly doesn't look like a boolean!

RE: DFU firmware encryption

Hung Bui — Tue, 30 May 2017 14:44:59 GMT

CRC is calculated and checked after each object is received. Have a look here. You can consider to check CRC for the encrypted packet instead of decrypted packet. This is to ensure the object is received properly over the air. Also, doing this you don't have to modify the bootloader on that part.

You can use the hash of the decrypted image to do the final validation of the image integrity.

RE: DFU firmware encryption

Jonathan — Tue, 30 May 2017 12:22:54 GMT

Thanks for the confirmation, I've figured I had to change the CRC computation, so far I've failed, but I'll keep trying! (If I got it right, CRC is computed on the flight as data is received, I've tried to change to "compute CRC on decrypted data", but getting glitches)

RE: DFU firmware encryption

Hung Bui — Tue, 30 May 2017 10:20:01 GMT

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.