Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Vidar Berg — Mon, 20 Dec 2021 08:22:33 GMT

Excellent! Thanks for the update, I'm glad to hear that it works now 🙂

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Thomas Hoppe — Fri, 17 Dec 2021 11:03:27 GMT

Solved it!

Not sure why, but I've called sd_ble_gap_encrypt() using the 'own' keyset instead of 'peer'. After fixing this, I'm now able to create a secure connection every time and subscribing to the DFU - Char is possible.

Many thanks for your support Vidar. Wish you all the best 🙂

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Thomas Hoppe — Fri, 17 Dec 2021 09:38:47 GMT

devzone.nordicsemi.com/.../ws_2D00_sniffs.7z

Of course. These are the sniffs used in the screenshots above.

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Vidar Berg — Fri, 17 Dec 2021 08:56:35 GMT

Hm, does all packets following encryption start in the first connection and subsequent connections have the wrong mic? The sniffer should be able to decrypt the packets when using legacy pairing: Sniffing a connection between bonded devices

Are you able to to upload the sniffer file here?

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Thomas Hoppe — Fri, 17 Dec 2021 08:38:01 GMT

I've sniffed both the initial bond and the reconnect case. When doing the initial bond, data is encrypted when I start to discover services (after calling sd_ble_gap_authenticate()), while in the reconnect case, the discovery part is unencrypted (as you mention).

The image below shows the section when I try to reconect. If I understand correctly, LL_ENC_REQ is triggered by the call to sd_ble_encrypt(). Comparing the information from VS debugger with the sniffed data, the master id is sent correctly (red arrows).

Following the response from the peripheral (LL_ENC_RSP).

For completeness, finally the log from the previous bonding:

I'm not sure if this is helpful.

Anyway, if the key that I use calling sd_ble_encrypt() would be corrupt, wouldn't this not totally fail? As said, I still got security_mode=1, level=1 from BLE_GAP_EVT_CONN_SEC_UPDATE. I expect this wouldn't be the case using a corrupted key.

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Vidar Berg — Thu, 16 Dec 2021 14:45:38 GMT

Level 1 means the link did not get encrypted or authenticated, which explains why you are unable to enable subscribe to the DFU characteristic. The question is why. I obviously can't tell if the encryption key is correct just by looking at it. The lesc and auth bits are set correctly at least.

Here is what I get for comparison when testing on a dev kit :

One way to troubleshoot this further is to capture a sniffer trace of the bonding exchange + the reconnect where you try to encrypt the link again. You can use our nRF Sniffer for Bluetooth LE if you have an extra devkit or nRF52840 Dongle laying around.

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Thomas Hoppe — Thu, 16 Dec 2021 12:50:06 GMT

Thanks again Vidar. I'm now a little bit further. In case I found a stored key to the newly connected device, I call sd_ble_gap_encrypt() using the keyset: own/p_enc_key pair (received from BLE_GAP_EVT_AUTH_STATUS after bonding).

But subscription to the DFU characteristic still fails in this case.

Not sure if this is important. When receiving BLE_GAP_EVT_CONN_SEC_UPDATE I got two different security levels:

Initial bond/sd_ble_gap_authenticate(): security_mode=1, level=2, key_size=16 -> DFU Char subscription success

Reconnect/sd_ble_gap_encrypt(): security_mode=1, level=1, key_size=0 -> DFU Char subscription fails (BLE_GATT_STATUS_ATTERR_INSUF_AUTHENTICATION)

Just in case this may be useful, here's the call to sd_ble_gap_encrypt() in the debugger. The key may be valid .. (it's a list not 0x00, 0x00, ..).

PS: I took another look into how pc-nrfutil is able to subscribe to this characteristic (https://github.com/NordicSemiconductor/pc-nrfutil/blob/af139f1fa2e511c9bf378eff00049d8bb69b8a15/nordicsemi/dfu/dfu_transport_ble.py)

After connecting and service discovery, and if the bonded DFU char is present, it jumps to jump_from_buttonless_mode_to_bootloader() (from line 164), where it calls bond() (line 199) in any case. In there, a call to sd_ble_gap_authenticate() (line 325) seems to be called every time, independent if a previous bonding was successfully done or not .. and this must be responed with success (line 334). After that, the char is subscribed (line 206). sd_ble_encrypt() (line 168) is started after the device has rebooted into DFU mode.

I'm still really confused :)

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Vidar Berg — Wed, 15 Dec 2021 15:12:56 GMT

Hello,

Sorry, I misread your description. My answer was based on the assumption that you also got the error on the first connection, even though you were pretty clear on this.

What you want to do on re-connect is to secure the connection with the previously exchanged encryption key by calling sd_ble_gap_encrypt() , not send a new bond request.

This procedure to encrypt the connection with an existing key is illustrated by the message sequence chart here: Encryption Establishment using stored keys

Best regards,

Vidar

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Thomas Hoppe — Wed, 15 Dec 2021 14:41:04 GMT

Hello Vidar,

thanks for your fast response.

Not sure, but I assume you talk about a different topic. My goal is not re-bonding using a new set of keys. I need a valid connection to be able to subscribe to the mentioned characteristic.

After closing the connection (with the initial bond) and connecting again (with just sd_ble_gap_connect()), my subscription fails. I didn't get any event to supply my previously stored key. So I assume I miss something to call after the connection is established.

My (simplified) call order (with initial bonding):

sd_ble_gap_connect() .. wait for event.
sd_ble_gap_authenticate(bond) .. wait for event.
sd_ble_gap_sec_params_reply() .. wait for event, got bonding keys, store them
[discover services, characteristics, desciptors ] ..
subscribe to BLE_DFU_BUTTONLESS_BONDED_CHAR_UUID -> success.
..
close connection

Do the same while without removing previous bonding information:

sd_ble_gap_connect() .. wait for event.
Got async BLE_GAP_EVT_SEC_REQUEST, how to respond?
?What to do at this point? How to supply my stored key? Calls to sd_ble_gap_authenticate() fail, so I assume they are wrong here, but I don't wan't to re-bond, just get a 'bonded' connection as required by this characteristic -> https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/service_dfu.html.
[discover services, characteristics, desciptors ] ..
subscribe to BLE_DFU_BUTTONLESS_BONDED_CHAR_UUID -> fails. Bonding/Pairing not active?

I hope you understand my problem.

Thank you again,

Thomas

RE: Legacy Pairing/Bonding problem, pc-ble-driver, NRF52, central

Vidar Berg — Wed, 15 Dec 2021 12:51:23 GMT

Hello Thomas,

The peer manager on the peripheral will by default reject bonding requests from a previously bonded peer, so this is likely why you get the BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP status in response to your request. I explained how you can configure the Peer manager to accept bond updates in my post here: https://devzone.nordicsemi.com/f/nordic-q-a/51965/pairing-and-bonding-after-deleting-synchronization/208927#208927. The other option is to delete the bond on the DFU target before you initiate DFU.

[quote user=""]A second question: Does the connectivity firmware store the bonding keys on device site too? This question is centered about the usability. If I connect my central device to a different host PC and try to connect to an already bonded peripheral, does the central know the bonding keys (e.g. stored in flash) or do I have to copy my host site keystore to the new host (and supply them when receiving BLE_GAP_EVT_SEC_REQUEST)?[/quote]

The host (pc-ble-driver app in this case) is responsible for the key storage. The connectivity FW does not store anything to flash.

If anything is unclear, let me know.

Best regards,

Vidar