How to reject bonding requests, and only allow pairing requests?

[jerome.sc]

I've noticed on the nRF Connect phone app that there is a bond button. If I'm in just works pairing no bonding mode (settings below), and click the bond button a bond still appears to be done. However, when sniffing the packets I know that the phone acknowledges my security parameters, where I say bonding is not allowed. However it seems like a bond still happens on the phone, but not on the nRF chip. I assume the nRF does not save any keys, which is why when trying to connect again I have to re-pair. I would guess it's the phone's operating system (Android/IOS) that is still trying to make a bond.

sec_param.bond = false;
sec_param.mitm = false;
sec_param.lesc = 0;
sec_param.keypress = 0;
sec_param.io_caps = BLE_GAP_IO_CAPS_NONE;
sec_param.oob = false;
sec_param.min_key_size = 7;
sec_param.max_key_size = 16;
sec_param.kdist_own.enc = 0;
sec_param.kdist_own.id = 0;
sec_param.kdist_peer.enc = 0;
sec_param.kdist_peer.id = 0;

If what I am saying makes sense, is there any way to stop bonding requests, but still allow pairing?  I know that setting the sec_param.bond = false" won't make a bond, but I want if someone tries to bond reject it completely, as opposed to don't allowing the bond but still allow pairing, i.e if it's a bond request reject it completely, if it's a pairing request pass it through.

I know this article shows how to stop bonding, but this also stops pairing as it uses the BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP parameter, which as expected stops pairing.
https://jimmywongiot.com/2021/06/29/how-to-allow-reject-the-ble-bonding-request-from-central/

[Hung Bui]

Hi Jerome, 

You can find the peer pairing parameters in BLE_GAP_EVT_SEC_PARAMS_REQUEST event. See here.

You will either have to handle the pairing yourself and reject the pairing request in your code or you would need to modify the peer_manager to do that in sec_params_request_process().

But I'm not so sure that you have the ability to turn off bonding on the phone or not. As far as I know it's not possible for the app to request only pairing. But you may need to check with Android regarding that. 

I agree that the phone is doing a little bit wrong to still "remember" the peer when they only do pairing and no LTK exchanged. 

[jerome.sc]

Yes I thought it was weird as well that even though I'm doing just works pairing no bonding, the phone keeps the keys but the nRF doesn't. I've only used the nRF Connect phone app, so I'm not sure if it can only bond and not pair only. In addition, I based my application on the Heart Rate Example (ble_app_hrs).

Could it be that this example changed parameters in the application that's ignoring my peer manager sec_param settings, more specifically setting sec_param.bond = false?

[Hung Bui]

Hi Jerome, 
No I have verified the behavior with a sniffer. You can see the trace here: 

The peripheral clearly say no bonding. And then after the connection is encrypted, no key distributing happen (no LTK). The phone should have forget the device after the connection is terminated as there is no LTK. 

[jerome.sc]

Yes, that trace looks similar to mine. Does your device (phone) still keep the bond information? As in going into your Bluetooth settings, does it say the device is bonded?

[Hung Bui]

Yes, correct. But of course if you try to read a characteristic that require authentication and get rejected it will send a Pairing Request instead of Encryption Request, showing that it doesn't have any key stored. Thiis is what I get when I connect again to a "bonded" device and try to read encrypt required characteristic: 

[jerome.sc]

Do you know where in the code, if possible to not send the pairing request? So for example, if someone tries to write/read to the characteristic, in this case, disconnect/reject the request as they don't have proper authentication.

[Hung Bui]

I assume you say to reject pairing request ? Normally the peripheral doesn't send pairing request, it's the phone does that. 
The rejection when peer trying to access an attribute that requires higher security is handled by the softdevice. 
But what you can do is to set up the characteristic with authorization permission so that when it's read/write you will have a callback in the application. 
See here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.3.0/group___b_l_e___g_a_t_t_s___r_e_a_d___r_e_q___a_u_t_h___m_s_c.html?cp=5_7_3_1_2_4_3_13