Recommendations for Encrypting firmware

[Arjun]

Hi,

We are using the Experimental Bootloader example from nordic SDK 10. The project is a good example on how to check for authenticity and integrity of the update package provided. Although, my other concern is sharing the binary file that is not encrypted. Is there are way that I can protect my bin file - say using AES encryption to encrypt the whole firmware. If this approach was to be followed I have couple of questions.

1.) Can AES key be generated using the shared secret keys of ECDS algorithm? 2.) If I do use AES for decrypting the binary stream on the devices would it possible given that soft device uses encryption module. Does that also mean reinitializing AES block for every packet received.

Thanks in Advance, Arjun

[Hung Bui]

Hi Arjun,

You are correct that the image is sent without encryption, only signing is implemented (note that we have the official secure (signing) bootloader from SDK v12 that we recommend).

However, if your connection is encrypted with Bluetooth bonding, your image is encrypted when sending over the air. The image when sending by the app is still not encrypted, but you can do something with that on the app to put another layer of encryption there.

If you are not confident with the BLE encryption (which is already AES 128) you can use AES hardware on the device for decrypting.

1. I think it's OK. ECC and AES have different encryption algorithm so it shouldn't be a big problem to reuse the case. But you will reduce the encryption level of ECC down to AES as you expose the key in AES. I don't see a big advantage of sharing the key here.

2. AES module is restricted when the softdevice is active. But you can use the API provided by the softdevice to do encryption (and decryption with counter mode or similar). This will of course slow down the DFU process. The size of the bootloader will also be increased for the encryption/decryption code.

This is just a suggestion, we actually haven't tested it ourselves.

[Hung Bui]

Hi Arjun,

I understand that you don't want to allow user to have access the binary image also you don't want to exchange the encryption key.

I was thinking that you can still use an encrypted image and use the app to decrypt it before you send the packets via BLE (with a bonded BLE link). However, there would be an easier way to get the HCI log of the BLE activity on the phone. So it's maybe not an option.

Regarding the difference between the experimental bootloader from SDK v10 and the Secure bootloader in SDK v12, the fundamental is the same we use public-private key scheme to do digital signing based on micro-ecc library. Beside moving the example from experimental to production, the bootloader has also been refactored and it's not compatible with the previous version of the bootloader (from SDK v11 and earlier), the protocol changed.

For a future proofing, we suggest to continue with the new bootloader.

Yes, you can use the encryption hardware peripheral on Nordic chip, as I suggested that you need to call the API provided by the softdevice to access the peripheral.