OOB DHkey request failure

[Mateusz]

Hi,

I am trying to implement OOB pairing via USB. I have the USB portion sorted out. The idea is for a peripheral device to send over OOB data over this medium, which then can be used by central during the pairing process.

My security parameters are:

#define SEC_PARAM_BOND                  1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                  1                                       /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC                  1                                       /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS              0                                       /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_NONE                    /**< No I/O capabilities. */
#define SEC_PARAM_OOB                   1                                       /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                                       /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16                                      /**< Maximum encryption key size. */

In my main function I am generating an LESC keypair and generating OOB data:

    ret = nrf_ble_lesc_keypair_generate();
    APP_ERROR_CHECK(ret);

    ret = nrf_ble_lesc_own_oob_data_generate();
    APP_ERROR_CHECK(ret);

During the pairing process, on BLE_GAP_EVT_LESC_DHKEY_REQUEST event, sd_ble_gap_lesc_oob_data_set() fails with error code 0x07 / NRF_ERROR_INVALID_PARAM. OOB own key is passed into this function, while the peer key is NULL.

This issue seems related:

https://devzone.nordicsemi.com/f/nordic-q-a/37702/lesc-oob---nrf_error_invalid_param-on-sd_ble_gap_lesc_oob_data_set

One odd thing that I don't quite understand is the following comment in the nfc_ble_pair_lib.c:

        case NFC_PAIRING_MODE_LESC_OOB:
        case NFC_PAIRING_MODE_LESC_JUST_WORKS:
            // Enable LESC pairing - OOB and MITM flags are cleared because it is the central device
            // who decides if the connection will be authorized with LESC OOB data.
            m_sec_param.mitm  = 0;
            m_sec_param.oob   = 0;
            m_sec_param.lesc  = 1;
            break;

So, the central has to have an OOB flag set to on, but the peripheral does not?

Reading through this Bluetooth OOB article, it states the following:

• Both devices MUST set their OOB data flag if they want to use OOB for pairing;
• If one of device sets OOB data flag, but the other does not, both devices will check MITM flag which is in“AutheReq” field, Table 1, marked in green. If any device sets its MITM flag, the pairing method will be selected by the mapping of IO Capabilities to pairing method. Please refer to Bluetooth Core Specification v5.0, Vol3, Part H, Table 2.8 for the mapping detail.
• Otherwise, use “Just Works” as pairing method.

However, the above is regarding to LE Legacy pairing, so it might not apply.

[Vidar Berg]

Hi,

I'd recommend using the nrf_ble_lesc module from SDK 15.3.0 or SDK 16.0.0. if you aren't doing it already. It should make it easier to set up custom OOB channels according to the release notes:

nrf_ble_lesc (part of the Peer Manager) now supports the LESC OOB pairing mode.
The ble_nfc_pairing_reference_c example demonstrates how to pass the OOB data to the module.

So, the central has to have an OOB flag set to on, but the peripheral does not?

The initiator can decide which pairing algorithm to use when using secure connections OOB pairing and when OOB and MITM flag are both set to 0 on the peripheral. Decision tables can be found in core spec 5.0, vol3, part H, section 2.3.5.1, table 2.6 and 2.7.

But have you considered passkey or numeric comparison pairing as an alternative? They also provide MITM protection. Maybe you can "display" the passkey through the USB as the Glucose Application does over UART. I think it's easier to implement.