1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link

[snowuyl]

I use nRF Connect to connect to nRF52832 device. 1st connection is bonded authenticated encrypted link, but 2nd connection becomes not bonded unencrypted link. Why 1st and 2nd connection are different?

The following is log message of nRF52832 device.

00> <info> app: POWER_ON.
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 185 bytes on connection 0x0.
00> <info> app: BLE_GAP_EVT_CONNECTED (1st connection)
00> <debug> app: state=1
00> <debug> nrf_ble_gatt: ATT MTU updated to 185 bytes on connection 0x0 (response).
00> <debug> app: _securityRequestHandler
00> <info> app: BLE_GAP_EVT_SEC_PARAMS_REQUEST
00> <info> app: PM_EVT_CONN_SEC_SUCCEEDED
00> <info> app: Connection secured: role: 1, conn_handle: 0x0, procedure: 1.
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 185 bytes on connection 0x0.
00> <info> app: PM_EVT_BONDED_PEER_CONNECTED
00> <info> app: BLE_GAP_EVT_CONNECTED (2nd connection)
00> <debug> app: state=1
00> <debug> nrf_ble_gatt: ATT MTU updated to 185 bytes on connection 0x0 (response).

[Einar Thorsrud]

Hi,

That is odd. I tested now with the ANCS example form SDK 17.0.2 and nRF Connect for desktop BLE, and after bonding the link is automatically encrypted upon reconnection (as expected). Which SDK version are you using, and do you see this with the ANCS example, or only your custom firmware? If only your custom firmware, can you explain the changes you have made? Also, can you explain in detailed steps how you reproduce this?

[snowuyl]

I am using nRF5 SDK v16.0.0. I am testing my custom firmware. Which example can I reference for bonding the link is automatically encrypted upon reconnection?

[snowuyl]

I test ble_app_ancs_c example. But nRF Connect shows "Not bonded, Unencrypted link". But what I need to do is  encrypted link.

[snowuyl]

[snowuyl]

ble_app_ancs_c.rar

[Einar Thorsrud]

It does not bond automatically with nRF Connect by default. First connect, like you did and then:

1. Click the gears icon on the device
2. Click "Pair..."
3. Check the "Bonding" checkbox
4. Click the "Pair" button

Now the devices are bonded.

If you now disconnect and reconnect again the link will be automatically encrypted as the devices was bonded from before.

(You can also change the nRF Connect configuration by clicking the gears icon on the device close to the right, which is the one used for connectivity. There select "Security parameters..." and check the "Perform bonding" box. This is used by default if the peripheral request security, which is the case here, and then bonding will be automatic".)

Both of the above procedures works with any Bluetooth LE device that supports bonding, like for instance the ANCS example in the SDK. However, if you look at the log from nRF while pairing/bonding you get a timeout, and that is because of your main loop where you wait for RTT etc, so your idle state handler with the here important app_sched_execute() does not run. So I fixed it simply by removing everything in your main loop except for the call to idle_state_handle().

In a nutshell, the root cause of the issue you are seeing is that you block in your main loop, preventing the app scheduler from running.

[snowuyl]

Thanks for your reply! I have another question that is how can I modify nRF52832 firmware to reject unencrypted link connecting?

[Einar Thorsrud]

Hi,

It depends a bit on what you mean. Do you want to only allow already bonded peers to connect? If so, advertising with whitelisting is what you want, and in that case you add the bonded peer(s) to the whitelist, an ignore connections from any non-whitelisted device. This is commonly done, and you can see an example of this in the ANCS example that you are using (search for "whitelist").

If you on the other hand want to allow any device to connect, but disconnect if the link is not encrypted there is no standard way to do this. You could achieve it by for instance starting a timer when you get the BLE_GAP_EVT_CONNECTED event, and stop the timer if you get the PM_EVT_CONN_SEC_SUCCEEDED event. If not, and the timer runs out, disconnect.

In any case though, you can configure security restrictions on each characteristic to prevent a peer from accessing them without having the right level of security (for instance minimum just works legacy pairing, or minimum LESC with authentication), etc.