Connection to device (peripheral) after smartphone (central) erased its bonding data.

[Nathan O.]

Hi,

I am currently working on a product based on an nRF52832 (SDK 15.3, S112 6.1).

The firmware uses the Nordic UART Service to receive and send data from and to a smartphone.

I have added the Peer manager and set all characteristics access in ble_nus_init to SEC_JUST_WORKS.

When I connect to my device using nRF Connect mobile application, it works as expected : I can connect to the device and the bonding starts when I try to read of enable notification on a characteristic of the Nordic UART Service.

The problem is that if, on the smartphone side, I delete the bonding data, I am unable to connect again to the device. I see a popup on my Android smartphone requesting an "association with device null". If I click on the popup "Associate" button, I get connected, overwise there is a 30s timeout after which I get disconnected.

This is the logs I have when I try to connect after deleting the bonding data :

<debug> peer_manager_handler: Event PM_EVT_BONDED_PEER_CONNECTED<\r><\r><\n>
<debug> peer_manager_handler: Previously bonded peer connected: role: Peripheral, conn_handle: 0, peer_id: 0<\r><\r><\n>
<debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ<\r><\r><\n>
<debug> peer_manager_handler: Security parameter request<\r><\r><\n>
<debug> peer_manager_handler: Event PM_EVT_PEER_DATA_UPDATE_SUCCEEDED<\r><\r><\n>
<debug> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update<\r><\r><\n>
<debug> peer_manager_handler: Event PM_EVT_LOCAL_DB_CACHE_APPLIED<\r><\r><\n>
<debug> peer_manager_handler: Previously stored local DB applied: conn_handle: 0, peer_id: 0<\r><\r><\n>
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.<\r><\r><\n>
<info> app: Connected<\r><\r><\n>
<debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).<\r><\r><\n>
<info> app: Data len is set to 0xF4(244)<\r><\r><\n>
<debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7<\r><\r><\n>
<info> app: Fast mode advertising<\r><\r><\n>
<info> app: Disconnected<\r><\r><\n>

Is there a way for the device to detect that the central's bonding data is no longer valid and request a new bonding ? Why do you think the Android popup show "null" ? On the first bonding, I did not receive any popup on the smartphone side (Just works is used)...

Kind Regards.

[Marjeris Romero]

Hi,

When you erase the bonding information from the smartphone it is also recommended to erase the bonding information on the nRF device too.

The peer manager which handles pairing requests will for security reasons* reject new pairing requests from an already bonded peer device. It sounds like this may be the problem here.  

You may add the following event handling to the PM callback if you want to allow repairing:

      case PM_EVT_CONN_SEC_CONFIG_REQ: 
       {
            pm_conn_sec_config_t config = {.allow_repairing = true};
            pm_conn_sec_config_reply(p_evt->conn_handle, &config);
       }

The other alternative is to actually delete the bond from the nRF device. For the SDK examples, you can delete all bonds by pressing board button 2 while resetting the device.

NB:

* Note that this will enable a potential attacker to update an existing bond. So there is a trade-off between security and user-friendliness.

Best regards,

Marjeris

[Nathan O.]

Thanks for your response.

I actually already have this configuration for handling SEC_CONFIG_REQ events.

Is it an expected behavior that the smartphone shows a popup asking for association request when this happens ?

On the first bonding procedure, I do not have any popup (Just Works pairing is done). I would like to avoid having this smartphone popup if possible. It is especially an issue as on one of my smartphone, this popup show as "association request with null" but that's probably a smartphone side issue.

[Marjeris Romero]

Hi Nathan,

There is one catch with repairing. Repairing is not secure, I have now updated my original post to reflect that.

If repairing is allowed anyone can just pretend it has the same MAC address and read all the data by bonding again.

It's recommended to instead remove the pairing info on both sides. This can also be done "remotely", like with a "restore factory defaults" setting in your device, or with a button for example...

So as you see, it would be a trade-off between security and user-friendliness... If you choose to allow repairing anyways, the user data should at least be removed so no one can get access to them.

Anyways, I just tested a modified version of the glucose example in the SDK, adding the event handling for PM_EVT_CONN_SEC_CONFIG_REQ in the PM handler so I can handle repairing, using my Samsung Galaxy S9 without seeing any pop-up window... so it may be a manufacturer dependent issue...

To be sure, you can do the same  test I did, open the Glucose example from the SDK v16.0.0, add the 3 lines for repairing from the above post inside the pm_evt_handler() and test bonding and repairing with your phone to see if the issue still persists.

Best regards,

Marjeris

[Nathan O.]

Hi Marjeris,

I actually managed to get my hands on a Galaxy S9 and I can confirm I do not have any pop-up on this smartphone with my own project. So you are right, it's probably a specific issue of my smartphone (the pop-up actually changed content since the last time I checked with an OS update of the phone).

Regarding the security of the repairing I see what you mean. For now, my customer does not want to implement any kind of factory reset on the device. I'll have to explaing this situation and raise the concern about the repairing. The device's input capability is also very limited so not sure how we could really handle a request to delete bonding information.

[Marjeris Romero]

Yes, it will always a trade-off between user-friendliness and security, it will depend on what you are more concerned about. Let me know if you have any more questions.

BR,

Marjeris