Connection problem deleting binding information from Slave

[stars]

Hi，

There are two things that can happen when I test paired bindings:(Test environment SDK_17.1,nrf52832, Android system，Add a paired binding in the ble_app_uart example，keil development)

The first kind: after binding, the host deletes the binding, and the slave machine does not delete, so the test has no problem

Type 2: After binding, delete the binding from the host.

#define SEC_PARAM_BOND                  1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                  0                                       /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC                  0                                       /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS              0                                       /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_NONE                    /**< No I/O capabilities. */
#define SEC_PARAM_OOB                   0                                       /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                                       /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16 
static void peer_manager_init(void)
{
  ret_code_t           err_code;

	err_code = pm_init();
  APP_ERROR_CHECK(err_code);

   memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));
   sec_param.bond           = SEC_PARAM_BOND;		
   sec_param.mitm           = SEC_PARAM_MITM;		
   sec_param.lesc           = SEC_PARAM_LESC;	
   sec_param.keypress       = SEC_PARAM_KEYPRESS;	/* */
   sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;
   sec_param.oob            = SEC_PARAM_OOB;			
   sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;		/* */
   sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;		/* */
   sec_param.kdist_own.enc  = 1;
   sec_param.kdist_own.id   = 1;
   sec_param.kdist_peer.enc = 1;
   sec_param.kdist_peer.id  = 1;

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

Steps:

1.Add the slave key loss handler to pm_evt_handler

			case PM_EVT_CONN_SEC_FAILED:
				{
            if (p_evt->params.conn_sec_failed.procedure == PM_CONN_SEC_PROCEDURE_ENCRYPTION &&

                p_evt->params.conn_sec_failed.error == PM_CONN_SEC_ERROR_PIN_OR_KEY_MISSING)
							{
                // Local device lost bond info, don't disconnect and wait for re-bond
								NRF_LOG_INFO("Loss of binding information\n");
                NRF_LOG_INFO("The connection failed because the slave lost its LTK\r\n");
								err_code = pm_conn_secure(p_evt->conn_handle,true);									
								if(err_code != NRF_ERROR_BUSY)
								{

									NRF_LOG_ERROR("Re-pairing failed due to: %d",err_code);
								}
								NRF_LOG_INFO("The security connection is re-established\n");
            }
            else
            {				
              sd_ble_gap_disconnect(p_evt->conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            }
					}					
					break;

2.Download the program and bind it to your phone

3.Long press button 4 of nrf52832_DK to delete the binding information. 

4.After deleting the binding information of the slave machine, for the first time, the mobile phone clicked on the connection and was directly connected, and the NUS service could be used to send and receive data.

5.After disconnecting. The second time, clicking Connect triggers the pairing binding process

nrf connect test symptom:

I would like to ask how the first connection after the binding is removed from the machine will be reminded of the pairing message instead of the direct connection. Is this possible? If so, how should I add the code?

The following is my project, the protocol stack is s132, using KEIL for development, if necessary can be copied to SDK_17.1 directly run.

8875.ble_app_uart.zip

Looking forward to your reply!

Best regards, stars

[Einar Thorsrud]

Hi,

I am not entirely sure I understand what is going on there. Looking at your code, you have a clien_delete define, and with that in place, the nRF allows repairing (so if bonding information is lost on the central/phone, the nRF/peripheral will allow the pone to pair again). However the I am not sure why you have your mater_delete define and the code associated with that? If the problem is that you keep the bonding information on the phone, you need to delete the bonding information on the phone. That can be done either from Bluetooth settings, or (on Android), directly from nRF Connect. If you do not, re-pairing should not work on the phone.

(Phones generally do not allow repairing silently like you can on the nRF side, as that is a security problem, where an attacker can spoof the address of the peer and replace it's bond).

[stars]

Hi,

Thank you very much for your reply.

This macro definition of mater_delete and the associated code allow you to delete the matching information from the machine, but the host does not delete the matching information and wants to re-match the handler code (should be changed to slave_delete).

What I want to accomplish is for the nrf device to unilaterally delete the binding information, and when it reconnects, it immediately deletes the binding information, rather than having to disconnect and reconnect as in my test video to trigger the pairing process again. Want to have a better user experience.

According to the answer:"(Phones generally do not allow repairing silently like you can on the nRF side, as that is a security problem, where an attacker can spoof the address of the peer and replace it's bond).”

Is it possible to start the pairing process again without deleting it on the device and not on the phone? But here's my puzzle: After the device deletes the pairing information, it initiates a security request on the second connection, which allows the phone to be paired again on the second connection. (Should there be no security problem in needing to be paired again?) ; Only the first time he connected it himself (there is a safety problem, can it be improved)

[Einar Thorsrud]

stars said:

Is it possible to start the pairing process again without deleting it on the device and not on the phone?

Do you here ask about not deleting it on the phone and not on the device, so both peers have the bonding information? If so, then things are good, and the existing bond can be used. So should be no need to pair again?

Generally though, on the nRF, you are free to implement what you want. Delete bonds as you see fit, and you can also allow repairing (for instance as suggested in this post). Modern phones never allow this, though. You need to delete the bond on the phone in order to pair/bond again if the bond has been deleted on the nRF. This makes sense, and is how it should be, but regardless if we like it or not, this is enforced by iOS and Android, so we cannot do anything about it (on Android you could implement bond deletion in a custom app though, but on iOS you would need to go to Settings in order to do it regardless).

[stars]

hi,

Thank you very much for your reply.

I understand your answer is: For the mobile phone as the host, the two devices have been bound, if the nrf device deletes the binding information, then the connection is related to the processing of the mobile phone, the nrf device can do nothing.

If both devices (host and slave) are nrf devices, my previous question can be solved, right? If so, are there any relevant examples for my reference and testing.

Best regards, stars

[Einar Thorsrud]

Hi,

Yes, if you have nRF devices in both ends you have full freedom to do what you want. In this case, you could allow repairing on both ends (as shown in this post) and delete the peer in case of encryption failed. With that, if you try to establish an encrypted link and both have the bond, the old bond will be used. If one or both of the peers have lost/deleted the bond, a new pairing procedure will occur.

I tested this with the RSCS samples for both central and peripheral and that worked. In short, add this to the pm_evt_handler:

        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);
            break;
        case PM_EVT_CONN_SEC_FAILED:
            pm_peer_delete(p_evt->peer_id);
            break;