Security failed on central_uart and peripheral_uart example

Hi,

At first I've succesfully managed to get the central_uart and peripheral_uart example running on 2 custom boards with nRF5340. Both are connecting and pairing fine, I see that they are switching to security level 2 as expected.

But after a while, after doing nothing special I get security failed error's. I have tried these examples both in nrf 1.9.1 and nrf 2.3.0. Same result: at first it worked but after a while I got the security error's.

A lot of experiments, such as going back to the original examples without changing any code (other then some minimum changes (3 lines) in the board files to get it running) did not fix the problem. Trying to unbond by using the bt_unpair() function did not help.

The only situation I can reproduce that works is to put use the central_uart example from nrf2.3.0 in combination with the peripheral_uart example from nrf 1.9.1. as can be seen in the top picture.

Can somebody please give me some pointers on what is going on?

Any help greatly appreciated,

Arno

Parents
  • Hi,

    Small update, after doing bt_unpair() on the peripheral_uart example from nrf 1.9.1. I got the same security failed error. So it has to do with pairing information that is lost. However the samples worked fine the first time, how can that be? How can I erase settings to go to a pristine situation that works out of the box? Is there some more simple example code for pairing other then the sample with nrf?

    Kind regards,

    Arno

  • Hi Arno, 

    You would need to call bt_unpair() on both sides of the connection, the central and the peripheral. 

    The reason for that is that for security reason, a new pair can't be automatically created if one side of the connection lose bond information. 

    Another option is to do a full erase of the chip on both side. Then they will start fresh. You can do a full erase by using nrfjprog.exe --eraseall. 

    Or if you use Visual Studio Code, you click on double arrows button when flashing: 

  • Hi,

    I have tried your suggestions (erase and unpair() ), but both fail. Please see the attached picture.

    I was able to trace the -22 error on the central_uart example back to not having the .passkey_display nor 

    .passkey_confirm callback functions. This seems to make sense because in connected() we are going to 
    err = bt_conn_set_security(conn, BT_SECURITY_L2); So we need a display and a keyboard to show security code and confirm the verification code on the central as well? Please correct me if I'm missing something.
    After this we also need something to push a button, so the button_changed() and num_comp_reply() functions
    from the peripheral_uart example ported towards the central_uart. And now it works and we get the following result:
    It is my impression that the flash erase all is helping a lot, however it is my impressing that unpair() does not remove the bonds from from settings flash. I have now unpair() standard in the code but now after a reset the bonding still is present. Only a full erase of the flash removes the bond.
    Another suggestion I would like to give is to update the central_uart example because in my opinion it is far from complete. This problem has taken me a lot of time to figure out.
    I have attached the sources, in the hope that somebody else benefits from this. For completeness I have
    added the following to the prj.conf of both the central and peripheral (but probably it does not matter):
    CONFIG_BT_SMP_SC_ONLY=y
    CONFIG_BT_TINYCRYPT_ECC=y
    Kind regards,
    Arno
    Code for the peripheral_uart:
    Code for the central_uart:
  • Hi,

    I have 2 more additional questions.

    1) Now I'm able to pair the 2 devices. Now I was expecting that after switch on the devices (reboot), that the pairing would be erased by 

    bt_unpair(BT_ID_DEFAULT, BT_ADDR_LE_ANY);

    However the devices stay paired as you can see in the picture. What I'm I forgetting?

    2) We are asking for security level 2 with 

    bt_conn_set_security(conn, BT_SECURITY_L2);
    However in the picture is indicated "Security changed: EF:25:86:3D:7B:F2 (random) level 4", where is this level 4 coming from? Maybe from the options: CONFIG_BT_SMP_SC_ONLY=y or maybe does Bluetooth LE does not permit level 2 nor level 3?
    Any help appreciated.
    Kind regards,
    Arno
Reply
  • Hi,

    I have 2 more additional questions.

    1) Now I'm able to pair the 2 devices. Now I was expecting that after switch on the devices (reboot), that the pairing would be erased by 

    bt_unpair(BT_ID_DEFAULT, BT_ADDR_LE_ANY);

    However the devices stay paired as you can see in the picture. What I'm I forgetting?

    2) We are asking for security level 2 with 

    bt_conn_set_security(conn, BT_SECURITY_L2);
    However in the picture is indicated "Security changed: EF:25:86:3D:7B:F2 (random) level 4", where is this level 4 coming from? Maybe from the options: CONFIG_BT_SMP_SC_ONLY=y or maybe does Bluetooth LE does not permit level 2 nor level 3?
    Any help appreciated.
    Kind regards,
    Arno
Children
  • Hi Arno, 

    Could you please double check if CONFIG_BT_NUS_AUTHEN is set to y ? 

    If it's set then the NUS service will require the connection to be at security level 3 or 4. Security level 2 (Just Work) will not work. 

    You can have a look here at this course to see the explanation on different security levels: https://academy.nordicsemi.com/topic/security-models/

    If you have passkey and LE Secure Connection, you will get security level 4, even if you only ask for security level 2 (it will try to get the highest security level). 

    However, if on one peer you don't define the callback for display or keyboard or confirm you will get only Just Work (level 2) . 

    So in theory it should still work with L2 if you don't have these callback. I'm not so sure why it didn't work for you. 

    You may want to try capture a sniffer trace. It will reveal how the communication is over the air and which side of the connection require higher security. 

  • Hi,

    For your information, I'm following exactly the central_uart and periheral_uart examples. In both examples

    CONFIG_BT_NUS_AUTHEN is not set the the prj.conf. So it remains a mystery why security level 4 comes out?

    Kind regards,

    Arno

  • Hi Arno, 
    Level 4 will automatically achieved if you have LESC and have MITM protection (passkey for example). 
    What I'm not so sure about is why it's failed when you don't have display callback for passkey and you only request L2.