DFU package encryption

SDK:v17.1.0

SOC:NRF52840
SoftDevice: v7.2.0

Do we need to encrypt the DFU package when we have enabled LESC in the configuration and we are using Just works mode with bonds?
Isn't the encryption provided by BLE stack with above mentioned configuration sufficient ?
if not Do we have any working example in the SDK ?

Parents
  • Hi Pavan, 

    One of the reason why we don't offer example of encrypted DFU is that when doing so you would need to either hardcode an encryption key into your bootloader or you would need to have a secure way to distribute such key. The problem of having one single encryption key for all device is that if one device get hacked or if the key is leaked all devices will be exposed.

     If you choose to distribute the key then you will face the same challenge as when you do BLE bonding (LESC for example). With Bluetooth LESC, after the key has been exchanged, the link is encrypted with AES-128. This is considered secured. The data transferring after the link is encrypted is protected. 

    The challenge is to securely exchange the encryption key. If you do LESC with just work it doesn't protect you from MITM attack. Meaning there is no way for the devices to verify that they are talking to the correct peer. 

    Our DFU example already comes with the bond flavour, please take a look at the DFU example documentation. 

Reply
  • Hi Pavan, 

    One of the reason why we don't offer example of encrypted DFU is that when doing so you would need to either hardcode an encryption key into your bootloader or you would need to have a secure way to distribute such key. The problem of having one single encryption key for all device is that if one device get hacked or if the key is leaked all devices will be exposed.

     If you choose to distribute the key then you will face the same challenge as when you do BLE bonding (LESC for example). With Bluetooth LESC, after the key has been exchanged, the link is encrypted with AES-128. This is considered secured. The data transferring after the link is encrypted is protected. 

    The challenge is to securely exchange the encryption key. If you do LESC with just work it doesn't protect you from MITM attack. Meaning there is no way for the devices to verify that they are talking to the correct peer. 

    Our DFU example already comes with the bond flavour, please take a look at the DFU example documentation. 

Children
No Data
Related