• State Not Answered
  • Replies 1 reply
  • Subscribers 71 subscribers
  • Views 561 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 240297
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU security

sjerlhagen

1. I use buttonless DFU. As I understand it, at startup the bootloader checks CRC of the application, and if it is ok it jumps to it. So if I accidentally deploy an update which is correctly signed but crashes, the customer will not be able to enter the bootloader. The device will be bricked. Is this a problem which you have thought about ? One solution would be to always enter DFU-mode at boot with a short timeout, say 30 sec.

2. The current DFU operates on an unencrypted image. It would be nice to use an encrypted image. BLE security is not a solution to this since the image would still be unencrypted in the DFU source (phone app). The image should be encrypted by nrfutil in a secure environment, and decrypted by the bootloader. Best would be to use the private / public keys, but a simpler encryption scheme might suffice, e.g. AES CCM. Thoughts on this ?

Parents
  • 0
    1. I use buttonless DFU. As I understand it, at startup the bootloader checks CRC of the application, and if it is ok it jumps to it. So if I accidentally deploy an update which is correctly signed but crashes, the customer will not be able to enter the bootloader. The device will be bricked. Is this a problem which you have thought about ? One solution would be to always enter DFU-mode at boot with a short timeout, say 30 sec.

     That is true. If the application crashes before anything can connect and write to the Buttonless DFU Service, the device is bricked. You have to thoroughly test your application before sending out the DFU image to customers. It may lead to bricked devices. 

    The 30 sec timer is one possible solution, another is to use the button on startup for forcing the device to DFU mode. 

     

    2. The current DFU operates on an unencrypted image. It would be nice to use an encrypted image. BLE security is not a solution to this since the image would still be unencrypted in the DFU source (phone app). The image should be encrypted by nrfutil in a secure environment, and decrypted by the bootloader. Best would be to use the private / public keys, but a simpler encryption scheme might suffice, e.g. AES CCM. Thoughts on this ?

     That is correct. The image is not encrypted. It is signed. As far as I know, there are no plans to add encryption to the bootloader/nrfutil, but both of them are open source, so it is possible to do modifications. 

    I imagine that one of the reasons why it isn't included is to keep the size of the bootloader small. 

    I believe that some customers have added this kind of encryption. You can check out this tutorial from a DevZone user. It may be a good starting point.

    Best regards,

    Edvin

Reply
  • 0
    1. I use buttonless DFU. As I understand it, at startup the bootloader checks CRC of the application, and if it is ok it jumps to it. So if I accidentally deploy an update which is correctly signed but crashes, the customer will not be able to enter the bootloader. The device will be bricked. Is this a problem which you have thought about ? One solution would be to always enter DFU-mode at boot with a short timeout, say 30 sec.

     That is true. If the application crashes before anything can connect and write to the Buttonless DFU Service, the device is bricked. You have to thoroughly test your application before sending out the DFU image to customers. It may lead to bricked devices. 

    The 30 sec timer is one possible solution, another is to use the button on startup for forcing the device to DFU mode. 

     

    2. The current DFU operates on an unencrypted image. It would be nice to use an encrypted image. BLE security is not a solution to this since the image would still be unencrypted in the DFU source (phone app). The image should be encrypted by nrfutil in a secure environment, and decrypted by the bootloader. Best would be to use the private / public keys, but a simpler encryption scheme might suffice, e.g. AES CCM. Thoughts on this ?

     That is correct. The image is not encrypted. It is signed. As far as I know, there are no plans to add encryption to the bootloader/nrfutil, but both of them are open source, so it is possible to do modifications. 

    I imagine that one of the reasons why it isn't included is to keep the size of the bootloader small. 

    I believe that some customers have added this kind of encryption. You can check out this tutorial from a DevZone user. It may be a good starting point.

    Best regards,

    Edvin

Children
No Data
Related
Terms of service