Rebonding (ENC_WITH_MITM) required after DFU upgrade with Android 5.1

[Clem Taylor]

I'm trying to figure out why I need to rebond after completing a DFU upgrade with Android 5.1.

My bootloader does not modify the device manager pstorage state, but I am passing the bonded connection state from the application side to the bootloader side. This works fine and the upgrade process is encrypted as confirmed with the sniffer. My bootloader has the option to erase the device manager pstorage parameters (via a flag in the init packet) but I am not setting that flag. I verified that I'm not corrupting the pstorage state by computing CRCs of the pstorage pages before and after the DFU process.

When I reconnect to the application after completing the DFU upgrade a new passkey bond is triggered. This doesn't seem to happen with iOS (but I have much less test coverage with iOS).

If I just switch to the bootloader and do a small number of encrypted IOs and then switch back to the application, I can reconnect without having to re-bond (enter a new passcode).

I thought the bond state was fairly stable (doesn't change from connection to connection) and the long-term state is only re-keyed after a fairly large number of packets (large relative to my 132K upgrade image).

Is my problem just that Android is doing something that changes the bond state (LTK rekey?) and because I'm not committing those changes. I would have thought a key was good for more then <8K packets.

Also, anyone know which specific bluetooth.org spec covers the encryption in detail, especially details on how the MIC and recommended practice for thing like re-keying? My google-foo failed me (or maybe it is covered in non-public docs, joy).

Any ideas?

[Hung Bui]

Hi Clem,

What you have seen usually happens when the bond information on the nRF51 is missing and the Android device receive a "Insufficient Authentication" error when trying to read an encrypted attribute. This happens after the Android device try to encrypt the link (with previous LTK) but got rejected on link layer. If you can capture a sniffer trace it should be possible to find out if it is the case. You can also check the device manager database (set a breakpoint and check the memory) after the DFU to see if the previous LTK is still retained after the DFU update.

I don't fully understand this part "If I just switch to the bootloader and do a small number of encrypted IOs and then switch back to the application, I can reconnect without having to re-bond (enter a new passcode)." What did you mean by "small number of encrypted IOs" ?

[Hung Bui]

Hi Clem,

I am sorry to hear that you are having trouble with the sniffer. I know, we had lots of report from people about this. Unfortunately, we ran out of resource to have someone to actually looking into this. The temporary solution is to unplug and plug the dongle back (several times). I found that it's actually more stable if I use the nRF51822 evaluation kit as the sniffer.

In your case if you don't use device manager, it would be possible to check when you receive BLE_GAP_EVT_SEC_PARAMS_REQUEST event, which LTK you are giving back in ble_gap_sec_keyset_t struct in sd_ble_gap_sec_params_reply(). You can check if it's the same key as before DFU or not. Just add a break point before you call sd_ble_gap_sec_params_reply()