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.

[Arjun]

Hi Hung,

Thanks for your response and suggestions. Appreciate it!

The reason we don`t want to depend on BLE encryption is that we would like to distribute update package to users. Which essentially is a zip file with firmware hex file, .dat file and xml. So that it could work with Nordic app for now. Hence bonding would not protect our hex file as we it can be physically accessed by any user. Later when we develop our own app we will think of using BLE bonding and encryption.

As far as my first question was concerned, we don`t share AES key. We encrypt our firmware with a AES key (say based on ECC key) and share the update package with users. At no point we exchange keys. Both ECC and AES keys are stored in flash at time of manufacturing. Decryption will happen on devices during OTA irrespective of bonding.

Could you let me know what is different with signing from SDK 10?

[Arjun]

Also we would like to use the hardware on nordic chip so that we don`t have to depend on software and code size can be kept in check.

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

[Arjun]

Thanks Hung for your time. Very helpful and informative. :)