Can’t get rid of bear hug bonding of Nrf52840

RE: Can’t get rid of bear hug bonding of Nrf52840

Einar Thorsrud — Thu, 07 Jan 2021 13:11:02 GMT

Hi,

[quote user="BE"]

Anyway, I’m not sure about the SEC_PARAM_LESC functionality. The inline documentation says”

define SEC_PARAM_LESC 1 /**< LE Secure Connections enabled. */

So what is secured by all those nrf_Crypto’s: the process of the connection, the data transmitted or both? Doe’s it contributes to the safe operation of the whitelist?

[/quote]

LE Secure Connections is a Bluetooth features that increases the security during the parigin stage. With legacy pairing, the key is exchanged on air so that an attacker can listen in. With LE Secure Connections, a shared secret is established using Diffie–Hellman key exchange. This is more complex, but is handled for you by the nRF libraries. As long as both the central and peripheral supports it, it will be used

After the pairing procedure, everything is the same, so the way the link is encrypted, whitelisting etc. is all the same. But you would have a higher degree of security as you have a much higher confidence that the key has not been compromised - that is it.

RE: Can’t get rid of bear hug bonding of Nrf52840

BE — Wed, 06 Jan 2021 21:51:14 GMT

Hello Einar,

Thank you for your helpful answer. Your insistence “to ensure that you delete the bonds on both sides” led me to re-debug this part and I found that pressing KEY_0 on the central side didn’t called scanning_start(true) thus pm_peers_delete() didn’t erased the central side, just as you said.

So now it works as expected, as far as I can test: currently I have just one peripheral board and some centrals. Changing centrals for the same peripheral is possible only by pressing KEY_0 on both side. I hope that this will be the case with more peripheral boards as well.

Regarding your note about the security concern in my product:

The product consist of several sets of boards: Central_1/Peripheral_1, Central_2/Peripheral_2 …. Central_n/Peripheral_n. These sets are operated by User_1, User_2 etc. and each user can shut down each part of his set separately, just the Central_n, or just Peripheral_n. Security means total grantee for no mismatch of set members, in any case. Data interception by hackers is less relevant.

Anyway, I’m not sure about the SEC_PARAM_LESC functionality. The inline documentation says”

define SEC_PARAM_LESC 1 /**< LE Secure Connections enabled. */

So what is secured by all those nrf_Crypto’s: the process of the connection, the data transmitted or both? Doe’s it contributes to the safe operation of the whitelist?

Please advice.

Thanks.

RE: Can’t get rid of bear hug bonding of Nrf52840

Einar Thorsrud — Tue, 05 Jan 2021 13:11:29 GMT

Hi,

I do not see enough of you code to know how you handle it, but you cannot do whitelisting with no existing bonds (well, technically you can, but then you would need to keep the whitelist separately, and it is not what you want to do). However, assuming your whitelist_set() function is similar to that of a few SDK examples, it should be good and no whitelist would be set when there are no bonded peers.

There is one important point, though. I was to quick reading the error code you get in the original post, as my first thought was whitelisting, which would give you a disconnect reason 0x3E = BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED on the central side if peripheral use whitelisting and the central is not in the whitelist. However you wrote you get, 4102 = 0x1006 = PM_CONN_SEC_ERROR_PIN_OR_KEY_MISSING, so that indicates that bonding information is only deleted in one side. So you need to ensure that you delete the bonds on both sides. Alternatively, if that is not a security concern in your product, you could consider allowing repairing by adding this snippet to your peer manager event handler:

        case PM_EVT_CONN_SEC_CONFIG_REQ: 
             {
                  pm_conn_sec_config_t config = {.allow_repairing = true};
                   pm_conn_sec_config_reply(p_evt->conn_handle, &config);
             }

RE: Can’t get rid of bear hug bonding of Nrf52840

BE — Mon, 04 Jan 2021 23:16:26 GMT

Hello Einar

The process of erasing the bonding is as following:

By pressing key_0 advertising_start(true) is called;

void bsp_event_handler(bsp_event_t event)
{
…
    switch (event)
    {
     …

        case  BSP_EVENT_KEY_0:             //   BSP_EVENT_CLEAR_BONDING_DATA:
          advertising_start(true);
        break;
  }
…
}

advertising_start(true) calls delete_bonds();

void advertising_start(bool erase_bonds)
{
    if (erase_bonds == true)
    {
        delete_bonds();
       // Advertising is started by PM_EVT_PEERS_DELETE_SUCCEEDED event.
    }
    else
    {
       whitelist_set(PM_PEER_ID_LIST_SKIP_NO_ID_ADDR);
       ret_code_t ret = ble_advertising_start(&m_advertising, BLE_ADV_MODE_DIRECTED);
        
        APP_ERROR_CHECK(ret);
    }
}

delete_bonds() calls pm_peers_delete();

static void delete_bonds(void)
{
    ret_code_t err_code;
    NRF_LOG_INFO("Erase bonds!");
    err_code = pm_peers_delete();
    APP_ERROR_CHECK(err_code);
}

- When the pear manager successfully deleted the bond, it sends the PM_EVT_PEERS_DELETE_SUCCEEDED event to the pm_evt_handler. On that event the NVIC_SystemReset() is invoked in the following way:

static void pm_evt_handler(pm_evt_t const * p_evt)
{
    pm_handler_on_pm_evt(p_evt);
    pm_handler_flash_clean(p_evt);

    switch (p_evt->evt_id)
    {
      ………..
        case PM_EVT_PEERS_DELETE_SUCCEEDED:        

             NRF_LOG_INFO("PM_EVT_PEERS_DELETE_SUCCEEDED, restarting  ");
             WaitCnt = 0;
             app_restart_flg = true;
             break;
   }
}


int main(void)
{
 ..
 ..
 advertising_start(false);

    for (;;)
    { 
      if(Connected_flg == true)
        {
         app_main_handler();
        }
      if(app_restart_flg == true) 
       {
        Connected_flg = false;
        app_restart();
       idle_state_handle();
      }
    }
}


void app_restart(void)
 {
   if(WaitCnt == 0)
     { 
      NVIC_SystemReset();
     }
 }

So after NVIC_SystemReset() is executed advertising_start(false) is called, i.e. with whitelist!

RE: Can’t get rid of bear hug bonding of Nrf52840

Einar Thorsrud — Mon, 04 Jan 2021 13:59:07 GMT

Hi,

I wonder if the whitelist is related here. You write that you erase bonds, but you do not write if you perform a reset of some sort (like power cycle or soft reset), or explicitly start advertising and/or scan without the whitelist? If you do not restart scanning or advertising then the old whitelist would still be used even though the bonds have been deleted.