Pairing & Bonding happens even when the client's iocap is no_io_caps

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Fri, 01 Feb 2019 13:53:24 GMT

Here's the trace file.

devzone.nordicsemi.com/.../iphone_5F00_BLE_5F00_SC_5F00_Connect.pcapng

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Fri, 01 Feb 2019 11:27:57 GMT

IT IS WORKING!!! The following is what I did:

I already had PM_LESC_ENABLED set before. The extra few lines in idle_state_handle() fixes it. I am so glad that I do not have to deal with the key request myself.

The extra code for BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST & BLE_GAP_EVT_CONN_PARAM_UPDATE is unnecessary, as I believe the peer manager should already handle these.

For the initial pairing/bonding, it took over 10 seconds. Is that normal? Once bonded, connecting is fast.

Again, thanks for your amazing knowledge and patience. Nordic’s customer support is always exceptional.

I have attached the iPhone trace for your reference. I am not sure if it is really connecting using LE secure connection. It’s not something I care about anyway.

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

bjorn-spockeli — Fri, 01 Feb 2019 10:21:13 GMT

Hi Joseph,

Q1:there is a LESC module in the nRF5x SDK v15.2.0 that handles the LESC events for you and is integrated in the PM manager. I recommend taking a look at at the Experimental: LE Secure Connections Multirole Example in the SDK.

Add nRF5_SDK_15.2.0_9412b96\components\ble\peer_manager\nrf_ble_lesc.c to your project and include #include "nrf_ble_lesc.h" in main.c

You also need to set PM_LESC_ENABLED to 1 in sdk_config.h. If this isnt present in you sdk_config file, then simply add the following snippet to the Peer Manager section

// <q> PM_LESC_ENABLED  - Enable/disable LESC support in Peer Manager.
 

// <i> If set to true, you need to call nrf_ble_lesc_request_handler() in the main loop to respond to LESC-related BLE events. If LESC support is not required, set this to false to save code space.

#ifndef PM_LESC_ENABLED
#define PM_LESC_ENABLED 1
#endif

You also need to add nrf_ble_lesc_request_handler to the idle_state_handler() function in main.c

static void idle_state_handle(void)
{
    ret_code_t err_code;
    
    err_code = nrf_ble_lesc_request_handler();
    APP_ERROR_CHECK(err_code);
    
    if (NRF_LOG_PROCESS() == false)
    {
        nrf_pwr_mgmt_run();
    }
}

Q2: Could you attach the trace of the communication between your iPhone and the NRF52832? I would like to see if the pairing request sent from the iPhone sets the Secure Connection Flag. As stated previously both sides must state that they support LESC, otherwise the paring will be performed with the common denominator in terms of supported features.

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Thu, 31 Jan 2019 17:40:57 GMT

Thanks for the additional info. Added what you suggested, but it didn't help.

After further investigation, I now believe the problem is caused by ESP32 (i.e. BLE client)'s request for "DH Key Check", which translates to BLE_GAP_EVT_LESC_DHKEY_REQUEST in nRF. The process dies because nRF side didn't respond to this DH Key request.

A few questions:

1. Am I supposed to handle the request explicitly myself?

2. For comparison, I traced connection to the NRF using nRF connect from my iPhone. It worked fine. But strangely, I did not see any DHKEY Request during the handshake. Why is it different?

Based on the client about BLE_GAP_EVT_LESC_DHKEY_REQUEST, I found some code from one of the NFC examples that generates a reply to the DH Key request that look something like this:

        case BLE_GAP_EVT_LESC_DHKEY_REQUEST:
        {
            // Buffer peer Public Key because ECC module arguments must be word aligned.
            memcpy(&m_lesc_peer_pk.pk[0],
                   &p_ble_evt->evt.gap_evt.params.lesc_dhkey_request.p_pk_peer->pk[0],
                   BLE_GAP_LESC_P256_PK_LEN);

            // Compute D-H key.
            err_code = ecc_p256_shared_secret_compute(&m_lesc_sk.pk[0],
                                                      &m_lesc_peer_pk.pk[0],
                                                      &m_lesc_dhkey.key[0]);
            APP_ERROR_CHECK(err_code);

            // Reply with obtained result.
            err_code = sd_ble_gap_lesc_dhkey_reply(m_conn_handle, &m_lesc_dhkey);
            APP_ERROR_CHECK(err_code);
        } break;

However, I have yet to be able to try it yet, as it requires me to build the external micro-ecc library, which seems really complicated. It's getting late, I will probably try it more tomorrow. But, before I sink more time into this, I want to make sure I am on the right track.

Thanks,

Joseph

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

bjorn-spockeli — Wed, 30 Jan 2019 10:06:20 GMT

I took a look at the trace and in terms of LESC support its all good, both sides states that they support LESC in the pairing request/response.

Which SDK version are you using ?

At least in SDK v15.2.0 you will need to respond to the BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event by adding the following snippet to ble_evt_handler

 case BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST:
{
    NRF_LOG_DEBUG("Received BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST");

    err_code = sd_ble_gap_conn_param_update(m_conn_handle,
        &p_gap->params.conn_param_update_request.conn_params);

    if (err_code != NRF_SUCCESS)
    {
        NRF_LOG_ERROR("Failure to update connection parameter request: 0x%x", err_code);
    }

    APP_ERROR_CHECK(err_code);
} break;

You can also add handling of the BLE_GAP_EVT_CONN_PARAM_UPDATE event, which is generated when the update is finished.

 case BLE_GAP_EVT_CONN_PARAM_UPDATE:
{
    NRF_LOG_DEBUG("Received BLE_GAP_EVT_CONN_PARAM_UPDATE");

    ble_gap_conn_params_t const * p_conn =
        &p_gap->params.conn_param_update.conn_params;

    NRF_LOG_DEBUG("max_conn_interval: %d", p_conn->max_conn_interval);
    NRF_LOG_DEBUG("min_conn_interval: %d", p_conn->min_conn_interval);
    NRF_LOG_DEBUG("slave_latency: %d",     p_conn->slave_latency);
    NRF_LOG_DEBUG("conn_sup_timeout: %d",  p_conn->conn_sup_timeout);
} break;

Best regards

Bjørn

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Wed, 30 Jan 2019 09:10:02 GMT

Regarding LESC connection, thanks for the useful suggestion of using nRF Sniffer to capture the connection. It looks like towards the end, after Key Exchange, the MASTER (i.e. ESP32 as client) sends a LL_CONNECTION_UPDATE_REQ. But, the nrf device (Server) doesn't respond with anything. Until 28 seconds later, the nrf sends a LL_TERMINATE_IND.

Is the nRF device supposed to respond to a LL_CONNECTION_UPDATE_REQ command, or not? Can you tell what the problem may be?

I have attached the capture from nRF Sniffer. You may use this as filter to see the essential packets:

btle.length!=0 && !btle.advertising_header

devzone.nordicsemi.com/.../LeSecureConnectFail.pcapng

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

bjorn-spockeli — Tue, 29 Jan 2019 14:25:42 GMT

Both sides must state that they support LESC, otherwise the paring will be performed with the common denominator in terms of supported features. So we need to verify if the ESP32 sets LESC as a suppported feature during the connection preocedure.

Could you use the nRF Sniffer v2 to capture a on-air-trace of the communication between the ESP32 and the nRF52?

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Tue, 29 Jan 2019 10:24:33 GMT

I am using an ESP32 as BLE client. Trying to get level 4 security (LE security) to work. Even though I set:

#define SEC_PARAM_LESC                  1

It seems like my ESP32 is still authenticated without LE SC. Using peer manager, are there some extra code I have to add to enable LE Secure Connection on NRF side?

Thanks again,

Joseph

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

bjorn-spockeli — Tue, 29 Jan 2019 09:28:10 GMT

Hi Joseph,

the 0x3002 error code is BLE_ERROR_INVALID_CONN_HANDLE, which is listed in the function brief of sd_ble_gap_disconnect() in ble_gap.h

/**@brief Disconnect (GAP Link Termination).
 *
 * @details This call initiates the disconnection procedure, and its completion will be communicated to the application
 *          with a @ref BLE_GAP_EVT_DISCONNECTED event.
 *
 * @events
 * @event{@ref BLE_GAP_EVT_DISCONNECTED, Generated when disconnection procedure is complete.}
 * @endevents
 *
 * @mscs
 * @mmsc{@ref BLE_GAP_CONN_MSC}
 * @endmscs
 *
 * @param[in] conn_handle Connection handle.
 * @param[in] hci_status_code HCI status code, see @ref BLE_HCI_STATUS_CODES (accepted values are @ref BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION and @ref BLE_HCI_CONN_INTERVAL_UNACCEPTABLE).
 *
 * @retval ::NRF_SUCCESS The disconnection procedure has been started successfully.
 * @retval ::NRF_ERROR_INVALID_PARAM Invalid parameter(s) supplied.
 * @retval ::BLE_ERROR_INVALID_CONN_HANDLE Invalid connection handle supplied.
 * @retval ::NRF_ERROR_INVALID_STATE Disconnection in progress or link has not been established.
 */
SVCALL(SD_BLE_GAP_DISCONNECT, uint32_t, sd_ble_gap_disconnect(uint16_t conn_handle, uint8_t hci_status_code));

You solve the issue by wrapping the code in the PM_EVT_CONN_SEC_FAILED case in a if statment that checks if the conn_handle is valid, i.e.

if(m_conn_handle !=BLE_CONN_HANDLE_INVALID)
{
    err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
    if (err_code != NRF_ERROR_INVALID_STATE)
    {
        APP_ERROR_CHECK(err_code);
    }
}

It is possible to block connection requests at the Link Layer, i.e. that the SoftDevice rejects connection request, but this requires that a white-list is used, see sd_ble_gap_whitelist_set in the SD API doc.

As for the security level, as stated in the comments Security Level 4 requires support for LESC (LE Secure Connections)on both sides of the link, i.e. both sides must be Bluetooth v4.2 or higher. So if you set the security level requirement to 4 for the characteristics, then a smartphone with a BLE v4.1 stack or below will not be able to access the characteristics. Level 4 is of course more secure, but the con is that not all smartphones support it. With level 3 you should not have any issues with the Bluetooth version.

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Tue, 29 Jan 2019 04:39:10 GMT

And, about security permission of the characteristics, would you not recommend level 4 instead of level 3? What is the difference?

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

joeyh — Tue, 29 Jan 2019 04:23:34 GMT

Great. This is exactly the answer I am looking for.

But, there is still a problem. Even though I replied to the client with BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, the client may still choose to ignore the rejection, and continue retrieving services and characteristics, etc. Wouldn't it be better if I close the connection immediately at the point of replying to secure parameters?

I tried adding these lines immediately after the reply:

            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);

            APP_ERROR_CHECK(err_code);

This closes the connection fine, but after that, the pm event handler gets a PM_EVT_CONN_SEC_FAILED event. And, the firmware dies in the "if" statement below:

            err_code = sd_ble_gap_disconnect(m_conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            if (err_code != NRF_ERROR_INVALID_STATE)
            {
                APP_ERROR_CHECK(err_code);
            }

It return an error code of 0x3002. I guess you are not supposed to call sd_ble_gap_disconnect() when we don't have a connection. I could probably ignore this error. But, it would be good to know the proper way to handle this.

Thanks,

Joseph

RE: Pairing & Bonding happens even when the client's iocap is no_io_caps

bjorn-spockeli — Mon, 28 Jan 2019 09:34:41 GMT

Hi Joseph,

Yes, if one of the peers do not have IO capabilities, then Just Works pairing will be used, see table 2.8 in the BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part H, page 2313.

When the Central ( Link Master) initiates the Pairing process by sending a Pairing request, you will receive a BLE_GAP_EVT_SEC_PARAMS_REQUEST event on the Peripheral side. With this event you will get an ble_gap_sec_params_t event struct that contains the IO caps of the central .

So you could examine the io_caps field upon receiving the event in the the BLE event handler in main.c and see it its set to BLE_GAP_IO_CAPS_NONE. If the IO caps are set to BLE_GAP_IO_CAPS_NONE, then you can reject pairing by calling sd_ble_gap_sec_params_reply with sec_status set to BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP.

I would also like to add that you can set the a security level requirement for each characteristic to security level 3 so that even though a device is able to pair and bond using Just works (Security Level 2), the central will not be able to write /read the characeristics unless it re-pairs with the appropriate security level. See BLUETOOTH SPECIFICATION Version 5.0 | Vol 3, Part C, page 2019 , table 5.8.

In the nRF5x SDK, this is done by setting the ble_gap_conn_sec_mode_t read_perm/ write_perm fields in the ble_gatts_attr_md_t struct that is passed to sd_ble_gatts_characteristic_add() to the desired security level

/**@brief GAP connection security modes.
 *
 * Security Mode 0 Level 0: No access permissions at all (this level is not defined by the Bluetooth Core specification).\n
 * Security Mode 1 Level 1: No security is needed (aka open link).\n
 * Security Mode 1 Level 2: Encrypted link required, MITM protection not necessary.\n
 * Security Mode 1 Level 3: MITM protected encrypted link required.\n
 * Security Mode 1 Level 4: LESC MITM protected encrypted link using a 128-bit strength encryption key required.\n
 * Security Mode 2 Level 1: Signing or encryption required, MITM protection not necessary.\n
 * Security Mode 2 Level 2: MITM protected signing required, unless link is MITM protected encrypted.\n
 */
typedef struct
{
  uint8_t sm : 4;                     /**< Security Mode (1 or 2), 0 for no permissions at all. */
  uint8_t lv : 4;                     /**< Level (1, 2, 3 or 4), 0 for no permissions at all. */

} ble_gap_conn_sec_mode_t;

Best regards
Bjørn