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" ?

[Clem Taylor]

I would have collected a sniffer trace, but I tend to have a large pain getting the sniffer to work reliably. It sees the advertisements but has a very high failure rate switching to a connection. It often will see the advertisement and scan packets, along with the 'connection req', but it doesn't manage to make the transition to sniffing the connection. In the DFU case it will sometimes work for the application connection, but the sniffer will fail to make the switch to DFU mode (it only sees the advertisements and the CONNECT_REQ).

I do have slightly better luck with the newer rev 3 dongle (with the PCB usb connector) vs the older rev 2 dongle. And I have tried it with several different instances of our custom hardware. I have a new Android phone on order (was testing with a Nexus 4) so maybe that will help. I also have better success sniffing traffic from an ipad, but that maybe helped by the longer connection intervals.

--

As to my question, the 'small number of encrypted IOs' is me just manually reading some parameters via Android MCP and then disconnecting and waiting for my bootloader to timeout, reboot back into the app and then me reconnecting. This process work, it goes from encrypted app to encrypted bootloader and back to encrypted app without triggering a re-bond.

My problem is after a full firmware upgrade, I end up having to rebond when I return to the application.

I am hoping that the problem is just that Android is re-keying while in DFU mode and that new bond data is lost (I don't have device manager in my bootloader) and not some other issue. However I wouldn't imagine that ~8K packets would be enough to trigger a rekey (not exactly long term).

If I could sniff reliably I would be able to prove that, but...