Adding encryption to secure DFU

[mrono]

Hello.

I'm trying to add encryption to the secure DFU bootloader. I'm using SDK v15. I know this topic has been discussed on this forum before. In particular I have found this blog post and this thread very helpful. I haven't yet been able to build a working solution though.

My first question is mainly about the general approach I should take on this: As I'm using the nRF52840, the secure booltoader in SDK 15 uses the CC310_BL crypto backend (not micro-ecc). This is a stripped down version of the full CC310 backend that only supports the signing used by the secure DFU. The logical thing to do would be to switch to the full CC310, which provides support for AES. However the full CC310 doesn't support the signing used in secure DFU out of the box. As far as I understand at least the byte order of the public key would need to be changed. But something else seems to be needed as well, as I can't get even the init packet hash to match with the CC310. I keep getting an internal error (NRF_ERROR_CRYPTO_INTERNAL).

So to summarize the previous paragraph: If I would like to use secure DFU as is but with the CC310 backend, what do I need to change? If I could get that part working then adding something like AES-CTR should be straightforward (I hope).

If the simplest way is to change the way nrfutil generates the keys, that would a good way in my opinion, as I'll need to eventually change the init packet anyway to add an IV-value.

The other option I see is to keep using the CC310_BL backend, and add support for AES-CTR (or similar). The blog post I linked to above does this using the ECB peripheral. I have tried to implement this as well. The basic DFU operation works. If I try to update the softdevice the whole process is successful as I'm not encrypting/decrypting the softdevice. For application updates I can get the data transfer working. The init packet hash passes and so do the CRC checks during transfer. The correct amount of bytes gets written to flash. But the bytes don't match the original binary, so I get a hash verification failure during the postvalidate step. I can read out the flash using nrfjprog, and the flash contents are completely different to the original. My first suspicion is that my encryption method doesn't match the decryption. 

My decryption code is a copy of the one in the blog post above (Intro to Application-level Security Using the ECB Peripheral). The only thing I added was a length parameter to be able to extract less than the key length of bytes, so that padding shouldn't be needed if the binary isn't an exact multiple of the key size. I'm using openssl for the encryption with aes-128-ctr cipher. For now I'm hard-coding the key and IV. I've even tried a key and IV of all ones and all zeros to avoid any byte order issues.

My question here is: If you implement decryption as in the blog post "Intro to Application-level Security Using the ECB Peripheral", how should you do the encryption using openssl? If I could verify that my encryption parameters are correct that would narrow the problem down considerably.

Best Regards,

Markku

[Hung Bui]

Hi Markku, 

To be honest I'm don't have much experience with crypto library, but I can try to help. 

From my point of view adding AES into CC310_bl could be a good idea. The main reason we didn't use CC310 in our bootloader was the limit of ROM size that we don't want to add the full big library in. 

My suggestion is, 

1) First you test inside your application, just encrypt and decrypt some dummy test data, doesn't need to try with a big image first.

2)After that you test on the real image, just write a blinky binary image into flash, and then use your application (not the bootloader) to encrypt and decrypt.

3) After you have above steps done, I don't see any problem using that encrypted image to create the .zip file and send it to the bootloader where you add the decrypting code. Note that there a tricky part with CRC. So on the fly CRC calculation for each packet is calculated on the encrypted data received. However, at the end, when we need to check the hash of the image, to verify the signature we should use the decrypted image. Same applied with the CRC calculation at post-validate, this is the CRC to be stored in flash so each time the device starts the bootloader will check if the application image still matches with the stored CRC. So this CRC has to be calculated on the decrypted image. 

 

But most important is to have the test image encrypt and decrypt correctly  (step 2), I think. 

 

 

[mrono]

Thank you. I'll try those steps.

[Mathew]

Hi Markku,

I'm also attempting to add encryption to the SDK v15 secure DFU bootloader.

I am interested in how you got on and whether you have any tips on how to implement a working solution.

Cheers,

Mathew

[mrono]

Other things came up, so I haven't had a chance to work on this for a while.

My plan is to proceed like this: First try to encrypt and decrypt some data (probably a text string) on the target and verify that it works. Then send the encrypted data out through RTT, and try to recreate the same encrypted data with openssl. (I still suspect my issue is that I'm not invoking openssl with the correct parameters.)