Secure DFU with bonded BLE, corner case resulting in unrunnable app?

[Austin]

I've been using secure DFU over a bonded BLE connection with the following configuration:

• S140 6.0.0
• nRF5 SDK 15.0.0
• nRF Connect for Android
• #define NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS 1    // In application sdk_config.h
• #define NRF_DFU_BLE_REQUIRES_BONDS 1               // In bootloader sdk_config.h

This has been working well. Once the application has stored bonding information for a peer, entry to DFU bootloader can occur and I've been able to update the app individually or bootloader+SoftDevice+app.

However, I'm concerned that if the peer performing the upgrade loses its bonding information during specific circumstances during an upgrade process, that the device will no longer be able to run an application. Bonding information on a smartphone could be lost by user error such as a user closing nRF Connect during and upgrae and requesting to 'Forget this device' in Bluetooth settings.

The specific failures that I hypothesise would result in a bricked unit are:

• During an app upgrade where dual bank update is not possible (eg. application is too big to support dual bank update). If the upgrade process was interrupted near the end of the app download, then bonding keys were deleted from the peer, the bootloader would eventually time out and reset.  As there is no longer valid runnable application due to having been overwritten by the upgrade process, the bootloader enters DFU mode without running any application.  No further DFU updates via BLE would be possible due to there being missing bonding keys from one side of the link.
• During a bootloader+SoftDevice+application upgrade. These upgrades occur in two steps, bootloader+SoftDevice first, then application. In this type of upgrade, it is likely that the original application is incompatible with the updated SoftDevice due to SoftDevice API changes, forcing an upgrade to a new application rather than being able to retain the existing app.  Similar to the case above, if bonding keys are deleted from the peer after the bootloader+SoftDevice part of the upgrade, there is no longer a valid runnable app (existing app is incompatible with new SoftDevice) and no further DFU upgrades are possible due to missing BLE keys on the peer.

Now for my questions.

Are the situations I have proposed plausible, and so effectively result in an unusable device which will be stuck in bootloader mode where no further upgrades can be performed due to missing pairing information on the bonded peer?

If yes, what are some possible mitigation for these scenarios?

Would any of the following ideas for fixing this work?

1. An sdk_config.h option which would allow repairing within the bootloader on pairing failures. This is likely application specific and would require the ability to set re-pairing options such as IO capabilities.
2. An sdk_config.h option which would allow unsecured communications if remote bonds are detected as missing for a connection. As the downloaded packages are typically signed, an attacker could use this insecure feature to download an unwanted application but the upgrade would fail if the downloaded application was not signed with correct keys.

[tesc]

Hi,

Yes, there are situations where loosing the bonding data leaves you with an "unupgradeable" device, namely any situation where you no longer have a valid application. The main advice, therefore, is to avoid such situations. That means to set NRF_DFU_FORCE_DUAL_BANK_APP_UPDATES to 1, in order to avoid your first scenario, and to not do SD major updates, in order to avoid your second scenario.

I am afraid your ideas for fixing the issue will not work particularly well, as there is no way for the DFU Target to confirm that the bonding data is indeed lost from the peer. A failed attempt at reestablishing encryption may just as well be an attacker.

I talked to the developers and the following potential solution emerged: A setting that lets the bootloader accept unbonded DFU if there is no valid application present. Perhaps after a cooldown period, in order to avoid hijacking of the DFU process in the situation where SD+BL are updated and one has to reconnect in order to update the application. They might decide to implement that for a future release.

Regards,
Terje

[Austin]

Thank you for your suggestions.

In practice, forcing dual bank updates may be impractical depending on the size of the application, however this does seem like a reasonable option where the application is small and unlikely to grow to a size where dual bank updates become impossible.

Similarly for SoftDevice upgrades, not having an upgrade path through a major SoftDevice version is not ideal, since it's possible that bugs and vulnerabilities may only be fixed in newer SoftDevices.

This is a difficult problem to solve and solutions are likely application specific.  The suggestions from your developers seem like a reasonable enhancement.  It may be that a new event could be introduced which notifies the bootloader app of pairing failures, the app could then decide how to handle this situation.  eg. A bootloader app could implement a cool down timer, or it could decide to use other means of indicating fallback to unbonded mode such as a button being depressed.

Providing an API to switch from bonded to unbonded mode, perhaps with persistence in bootloader settings,  would allow a custom bootloader to implement a policy of when this switch occurs.

[Luke Galea]

To further clarify your concern, if the bonding keys were deleted during upgrade and the device enters DFU mode (assuming that the ble_secure_bootloader is being used), wouldn't the bootloader start advertising and be open to new connections once again?

[Austin]

Yes, the BLE device would start advertising again and be open to new connections.  However, without the presence of pre-shared keys at both ends of the link (e.g. presence of keys created during a prior bonding session), the security level of the connection cannot be raised, allowing access to DFU services.