How can an NCS Central pair with an nRF5 SDK Peripheral that only supports Legacy Pairing?

[Ethan]

Environment

Central

• nRF54

• NCS v3.3.0 (Zephyr Bluetooth Host)

Peripheral

• nRF52

• nRF5 SDK v15.3.0

• Existing commercial product (cannot be modified)

Problem

My nRF54 Central connects successfully to an nRF52 Peripheral and then initiates bonding.

The Peripheral is an existing product that cannot be modified, so I can only change the Central configuration.

During pairing, the Central reports:

BT_SECURITY_ERR_AUTH_REQUIREMENT (4)
"The requested security level could not be reached."

If I disable Secure Connections Only mode by setting:

CONFIG_BT_SMP_SC_PAIR_ONLY=n

the error changes to:

BT_SECURITY_ERR_UNSPECIFIED (9)
"Pairing failed but the exact reason could not be specified."

Peripheral Security Configuration

The Peripheral uses nRF5 SDK 15.3.0 Peer Manager with the following security parameters:

sec_param.bond         = true;
sec_param.mitm         = false;
sec_param.lesc         = false;
sec_param.keypress     = false;
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;

Since this is an existing product, these settings cannot be changed.

Questions

• Is it possible for an NCS 3.3.0 Central to pair with a Peripheral that only supports Legacy Pairing?

• Besides setting CONFIG_BT_SMP_SC_PAIR_ONLY=n, are there any additional Kconfig options or API calls required on the Central?

• Does Zephyr/NCS disable Legacy Pairing by default in any other way?

• Has anyone successfully paired an NCS 3.3.0 Central with an nRF5 SDK Peripheral that has sec_param.lesc = false?

Any suggestions would be appreciated.

[tesc]

Hi,

Is it possible for an NCS 3.3.0 Central to pair with a Peripheral that only supports Legacy Pairing?

Yes, this should be possible.

Besides setting CONFIG_BT_SMP_SC_PAIR_ONLY=n, are there any additional Kconfig options or API calls required on the Central?

It looks like you also have to set CONFIG_BT_SMP_SC_ONLY=n.
(And possibly also ensure still that CONFIG_BT_SMP=y.)

Does Zephyr/NCS disable Legacy Pairing by default in any other way?

Not that I am aware of, no. The change is documented in the migration notes for nRF Connect SDK v3.0.0.

Has anyone successfully paired an NCS 3.3.0 Central with an nRF5 SDK Peripheral that has sec_param.lesc = false?

Others have experienced what looks like the same issue as you are seeing now, and they seem to have made it work with the correct configs.

Regards,
Terje

[Ethan]

Thank you for your reply.

I checked my Central configuration, and I already have the following settings:

CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_SETTINGS=y
CONFIG_BT_SCAN=y
CONFIG_BT_BONDABLE=y
CONFIG_BT_PRIVACY=y
CONFIG_BT_FILTER_ACCEPT_LIST=y
CONFIG_BT_SMP=y
CONFIG_BT_SMP_SC_ONLY=n
CONFIG_BT_SMP_SC_PAIR_ONLY=n
CONFIG_BT_SMP_ENFORCE_MITM=n
CONFIG_BT_SMP_APP_PAIRING_ACCEPT=y
CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y
After the connection is established, I request security with:

bt_conn_set_security(conn, BT_SECURITY_L2);
However, I still observe the same behavior:

With CONFIG_BT_SMP_SC_PAIR_ONLY=y (default), security_changed_cb reports:
BT_SECURITY_ERR_AUTH_REQUIREMENT (4).

After changing CONFIG_BT_SMP_SC_PAIR_ONLY=n, the error changes to:
BT_SECURITY_ERR_UNSPECIFIED (9).

Is there anything else on the Central side that could prevent Legacy Pairing, or is there any additional log you would recommend collecting to help identify the root cause?

Thank you.

[Hung Bui]

Hi Ethan, 

Could you show your full code / minimal code  ? 
I suspect that you may have a mismatch in the MITM configuration, meaning one side tried to do bonding with passkey or OOB. 
I did a quick test here and it seems to work. Please take a look 
NCS v3.3.0:
5543.central_hr.zip

nRF5 SDK v15.2: 
ble_app_hrs - Copy.zip

[Ethan]

Thank you for providing the example projects.

I tested again using the same security configuration, but pairing still fails in my project.

The central is based on NCS v3.3.0, and the peripheral is based on nRF5 SDK 15.3.0. The peripheral uses Legacy Pairing with bonding enabled, MITM disabled, OOB disabled.

However, the connection still remains at security level 1, and the pairing procedure eventually fails.

I noticed that the sample does not register `security_changed` or `bt_conn_auth_info_cb` callbacks. Could you explain why these callbacks are not required in the sample?

My understanding is that these callbacks are only used to receive pairing and security status notifications, and should not affect whether the SMP procedure itself succeeds. Is that correct?

One additional difference is that my peripheral provides the Nordic UART Service rather than the Heart Rate Service.

Could the presence of NUS affect the pairing procedure in any way, for example through characteristic permissions, automatic security requests, or the timing of GATT discovery?

As far as I understand, the GATT service type itself should not affect SMP pairing unless one of its attributes requires encryption or authentication. Please let me know whether this assumption is correct.

[Hung Bui]

Hi Ethan, 

Please confirm that my sample worked ? 

If it's the case could you try to change my sample to match your configuration, step by step until it stop working ? 

I don't see why `security_changed` or `bt_conn_auth_info_cb` would change the pairing result. 

NUS service shouldn't be the problem. But what security level did you set to your service ? Did you set it to open or with some encryption/authentication requirement ?