samples: bluetooth: Set CONFIG_BT_SMP_SC_PAIR_ONLY=n when needed

[RobertDaleSmith]

I banged my head against this one for a week. 🫠

After erasing my board, the central_hids and central_uart samples suddenly refused to pair successfully. I started my project on SDK v2.2 and had paired successfully once before with the board I was using. So I had a cached bond on my board prior to updating to v3.1.0 and restarting my project with central_hids as the base. Everything worked fine until I decided to totally erase my board to fix a bootloader issue. After this I was plagued with the following error on my firmware and even these two basic samples I based my firmware on:

Security failed: 1A:B2:3C:D4:5E:F6 (random) level 1 err 4
Pairing failed conn: 1A:B2:3C:D4:5E:F6 (random), reason 4

After trying everything I could think of. I stumbled on this fix that was applied to some of the other samples:

2b1be2d LE legacy pairing is no longer enabled by default. Samples that use it, need to disable the BT_SMP_SC_PAIR_ONLY Kconfig option. See Zephyr PR 73217.

Without this CONFIG_BT_SMP_SC_PAIR_ONLY=n I could not pair to a simple bluetooth mouse. But if i had paired/bonded with an older firmware on v2.2, then flashed these samples, it would pair no problem. It was only the initial bond without cached bonds or without CONFIG_BT_SMP_SC_PAIR_ONLY=n set, that throws the reason 4 error log I posted above.

I'm pushing this PR to save some other poor developer the same fate and because I actually tested/verified these two samples work with this config fix.

[CLAassistant]

All committers have signed the CLA.

[NordicBuilder]

Thank you for your contribution!
It seems you are not a member of the nrfconnect GitHub organization. External contributions are handled as follows:
Large contributions, affecting multiple subsystems for example, may be rejected if they are complex, may introduce regressions due to lack of test coverage, or if they are not consistent with the architecture of nRF Connect SDK.
PRs will be run in our continuous integration (CI) test system.
If CI passes, PRs will be tagged for review and merged on successful completion of review. You may be asked to make some modifications to your contribution during review.
If CI fails, PRs may be rejected or may be tagged for review and rework.
PRs that become outdated due to other changes in the repository may be rejected or rework requested.
External contributions will be prioritized for review based on the relevance to current development efforts in nRF Connect SDK. Bug fix PRs will be prioritized.
You may raise issues or ask for help from our Technical Support team by visiting https://devzone.nordicsemi.com/.

Note: This comment is automatically posted and updated by the Contribs GitHub Action.

[MarekPieta]

The reason why the option was enabled:

Support for Bluetooth LE legacy pairing is no longer enabled by default, because it is not secure.
Using Bluetooth LE legacy pairing introduces, among others, a risk of passive eavesdropping.
Supporting Bluetooth LE legacy pairing makes devices vulnerable to downgrade attacks.
The CONFIG_BT_SMP_SC_PAIR_ONLY Kconfig option is enabled by default in Zephyr.
If you still need to support the Bluetooth LE legacy pairing, you need to disable the option in the configuration.

Ref: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/releases/release-notes-3.0.0.html

You could accept the security risk and disable the CONFIG_BT_SMP_SC_PAIR_ONLY option locally in your configuration, but I am worried that we should not keep it disabled in the sample (preferring security over interoperability).

[MarekPieta]

The initial pairing failures that you replicate might be caused by the fact that pairing with devices that do not support secure connections pairing will not be supported if CONFIG_BT_SMP_SC_PAIR_ONLY is enabled.

[RobertDaleSmith]

The initial pairing failures that you replicate might be caused by the fact that pairing with devices that do not support secure connections pairing will not be supported if CONFIG_BT_SMP_SC_PAIR_ONLY is enabled.

Correct. As a new commer, there was no clear indicator when I updated from 2.2 to 3.1.0 why my simple HID mouse would no longer pair suddenly. I wasted a week troubleshooting before I discovered randomly, a commit where this option was added to other bluetooth/central_* samples. Commit -> 2b1be2d

At the very least, this should be included but commented out with a note?

[MarekPieta]

It was documented, but only in the release notes (as it was changed for NCS 3.0.0 release) - it might not be visible enough. Generally we discourage using BLE legacy pairing as it's not secure and most of the BLE devices already support BLE secure connection pairing (unfortunately it seems that still not all of the users' devices support it).

I will think how could we improve documentation to avoid confusing users (keeping in mind that this could affect multiple samples).

[MarekPieta]

I discussed with tech-writers. We can add a migration guide entry to improve visibility of the information.
@RobertDaleSmith Would this approach be acceptable for you?