Force central to only use OOB for pairing

[Skara]

Hello All,

I'm currently working on an application with a central and peripheral devices both using nrf52832 with SDK 15.3 and S132.
I'd like for the central to be only trying to connect and attempt pairing/bonding to known peripheral devices.

Since both sides don't have keypad/display, I thought of using Legacy OOB for the pairing.
The same key will be provisioned on the central and one or many peripherals. The central in addition will get the address(es) of the peripheral(s) which it will try to connect to.

That is all fine and seems to be working properly, but my problem is that the central tries to pair (and succeeds) to the peripheral even if it does not have the OOB flag set.

How can I make sure that the central only uses Legacy OOB for pairing?

Here are my security settings on the central:

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

And with these parameters on the peripheral the central got successfully paired:

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

[Amanda Hsieh]

Hi, 

Have a look at MSC: Bonding: Passkey Entry, User Inputs on Central or OOB and Bonding: Just Works. When Central gets BLE_GAP_EVT_AUTH_KEY_REQUEST event, it start OOB. Otherwise, it will do bonding. Therefore, I would suggest you consider scan or advertise with whitelist to avoid unknown device connecting. 

Regards,
Amanda

[Skara]

Hi Amanda,

Thank you for your response.

Yes, I am already using a filter in the central device to only try and connect to devices for which the central has OOB and address stored locally.

The problem is that if an attacker knows the address of any of the peripherals that were not yet bonded to the central, it might start advertising with that address. The central will see it and since its a known address will connect to it. After the connection is established, the central starts the pairing/bonding procedure. Now if the attackers security configuration has no capabilities and the OOB flag not set, then the central will proceed with the Just Works bonding. And this is what Id like to prevent somehow.

I know that this behavior is all in accordance to the Bluetooth specification, but I'd still like for the central to terminate the connection if the peripheral does not support/use OOB. Is that somehow possible?

Thanks,
Skara

[Amanda Hsieh]

Hi Skara, 

If you require MITM, then you should increase the security level on the characteristics to require it. The pairing capabilities is like the name implies, just the capability. It does not impose a certain security level. 

-Amanda 

[Skara]

Hey Amanda,

my problem is on the central side and not on the peripheral. I don't want the central to pair to untrusted peripherals. From the central point of view, all devices that do not use OOB for pairing are untrusted.

Is there a way on the central side, after it initiates the connection to a peripheral, to make sure that the only way to secure the connection will be using OOB?

Thanks,
Skara

[run_ar]

Hi,

Did you figure out how to solve this? Problem is the spec requires the security parameters to be negotiated, so the highest common factor will be used for bonding. The application can decide what level is required to access various attributes, so you have to make sure you set the security level to highest level if that is what you require. Then the application can choose to disconnect in case the peer doesn't meet this requirement. It could also be possible to check the supported parameters in the ble_gap_evt_sec_params_request_t event. But afraid that requires some modifications to the peer manager.