Can’t get rid of bear hug bonding of Nrf52840

[BE]

Hello,

My environment info:

Nrf52840-DK, PCA10059, MDBT50Q-DB

SDK 16.0.0

Win10, SES, nRF Connect v3.6.1

My project comprises a peripheral board connected to some sensors and a central board connected to a PC via USB. The boards exchange data using Nordics UART Service (NUS). To ensure safe operation of several Central/peripheral sets in the same place, the connection is bonded, secured and whitelisted in both sides.

The first-time secure bonding is really time consuming but that is the small problem because once bonded the process is much shorter. The real problem is that it’s a “bear hug” bonding, and as suggested in many links (1 , 2 ,  3 ), only after performing a “nrfjprog –eraseall” I can connect to another peer.

After calling “pm_peers_delete()”, (by pressing KEY1), new connections trials ends up with error 4102 and only performing “nrfjprog –eraseall” in both sides helps me out.

This is O.K. in my lab, but what should be the solution in the field, for the end user (Costumer)?

The Central is a dongle that can be lost, an option of easy replacement is needed.  

Also, I assume that nrfjprog –eraseall removes the bootloader so how to reprogram the application on the field. ICE/Nrf52840-DK are not available for field service in FOTA era.

(Why  --eraseall  is needed albeit calling pm_peers_delete()  ends up with the event PM_EVT_PEERS_DELETE_SUCCEEDED generated by   pear manager ?).

Does SDK 17.0.0 solves this problem ?

Thanks in advance.

[Einar Thorsrud]

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.

[BE]

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!

 

[Einar Thorsrud]

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);
             }

[BE]

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.

[Einar Thorsrud]

Hi,

BE said:

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?

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.