nRF52832 SDK15.3.0 how to force paring/bonding after connection

[breaker]

nRF52832

SDK15.3.0

ble_app_gls

ble_app_gls(SDK15.3.0) works perfectly and I want to port this "request pairing immediately feature" to my own project.

I referred a project from ble_app_uart_bonding_static_passkey_SDK_15.2.0  as my own project.

but this project does not start a pairing request after connection established. I have not found much difference between referred project and ble_app_gls.

Question:

ble_app_gls will start a pairing request with passkey method after connection established.

I want to find out where this paring request starts?

I tried:

1. in services_init(), modify SEC_JUST_WORKS to SEC_OPEN, but it still starts paring request after connection.

    // Here the sec level for the Glucose Service can be changed/increased.
    gls_init.gl_meas_cccd_wr_sec = SEC_JUST_WORKS;
    gls_init.gl_feature_rd_sec   = SEC_JUST_WORKS;
    gls_init.racp_cccd_wr_sec    = SEC_JUST_WORKS;
    gls_init.racp_wr_sec         = SEC_JUST_WORKS;

2. modify SEC_PARAM_LESC from 1 to 0, but it still starts paring request after connection

3. modify ble_app_uart_bonding_static_passkey_SDK_15.2.0 ble_nus_init(), make add_char_params.read_access/write_access/cccd_write_access to SEC_JUST_WORKS(just like ble_app_gls), it still does not start paring

Here I attach my test project on SDK15.2.0

ble_app_uart_bonding_static_passkey_SDK_15.2.0.7z

[Einar Thorsrud]

Hi,

Reding your question I am a bit confused about what the goal is. At the beginning of the question, it seems like you want to somehow force a rapid pairing/bonding after connection. Reading furhter it looks like you don't want to pair at all. Can you clarify what you want to achieve

Generally, it is always central who initiates pairing by issuing a pairing request. The peripheral can support pairing or not and support a subset of features (MITM depending on I/O capabilities, LESC, etc.). It can also require pairing for certain characteristics, like when you use SEC_JUST_WORKS or SEC_OPEN. This will limit if the peer can access the characteristics, depending on the security level. However, it is still the central who actually initiates the pairing. (For instance, iOS will only initiate pairing after getting access  denied one a characteristic).

[breaker]

Hi Einar,

My goal is: force rapid paring/bonding after connection. and ble_app_gls works just like what I want. I tried to implement the same QUICK pairing/bonding behavior on my own project.

My question is: but my own project does not pairing/bonding immediately after connection. I need to find out why? 

[breaker]

Hi Einar,

More details:

Android 9, with nRFconnect4.22.3

I try at my own project to modify  ble_app_uart in ble_nus_init(), I modified all read/write/cccd_write access to SEC_SEC_MITM. It only pops out pairing indication at the phone after I read/write NUS characteristics.

(which means, it never pops out pairing indication after connection if I don't access characteristics).

But the behavior of ble_app_gls is: It always pops out pairing indication at phone immediately just after connection established.

So I want to find out what I missed in my project. meanwhile, I want to find out how does ble_app_gls start a pairing/bonding request just after connection even before I try to access any characteristics.

[Einar Thorsrud]

Hi,

I see.

breaker said:

I try at my own project to modify  ble_app_uart in ble_nus_init(), I modified all read/write/cccd_write access to SEC_SEC_MITM. It only pops out pairing indication at the phone after I read/write NUS characteristics.

(which means, it never pops out pairing indication after connection if I don't access characteristics).

This is expected and is also how iOS handles things (to an even larger extent). There normal approach when accessing GATT characteristics is to try to read or write, and see if it is allowed. If it is not allowed due to a too low security level, then the central will typically initiate pairing.

breaker said:

So I want to find out what I missed in my project. meanwhile, I want to find out how does ble_app_gls start a pairing/bonding request just after connection even before I try to access any characteristics.

I suspect that the reason for the Android phone to pair with the GLS example initially is that it uses a standard profile with standard services, and Android is implemented so that it will automatically pair after service discovery if a certain service is present. This is still something that is decided by the Android (central) device though and cannot be dictated by the peripheral.

It is generally not advised for the peripheral to initiate peering, as described in this post. However, the peripheral can send a security request to the central at any time, but it is up to the central to decide whether it will initiate pairing or ignore the request. See Peripheral Security Request MSC for details. If you want to do this, then in practice you should use pm_conn_secure() in most cases, which in turn calls sd_ble_gap_authenticate().

[breaker]

Hi Einar, Thank you for your response.

I think I resolved this request. In short words: I copied all related code from ble_app_gls, including pm_evt_handler() ble_evt_handler() peer_manager_init().

Now ble_app_uart works just like ble_app_gls, will start a pairing request after connection immediately. And I will look at these handlers deeply.

Now another question comes out:

I am working on how to enable SEC_PARAM_LESC 1. If I simply set SEC_PARAM_LESC as 1, pairing result in a fetal error. I think this is about ECDH public key or crypto things. similar ticket

Do you have any suggestions? or should I open a new ticket?

[breaker]

thank you for your suggestion. I will do more test to see if there is any side effect on current implementation.