This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Pairing and Bonding Method in nrf51822

Hi guys,

I am currently using nrf51822 with SDK 11. I use Peer Manage to deal with paring and bonding encryption in BLE connection.

Please correct me if I am wrong but in "Just Work" mode, the nrf51822 connect and bond with any device. For example, Smart Phone A connected and then bonded with nrf51822, then I disconnected the Smart Phone A, after that, I connect and bond the device with Smart Phone B, and it is connect and bond with Smart Phone B right away.

I wonder if there is any way I can do to change it in the way like this: as long as the device nrf51822 stay connected and bonded with Smart Phone A, it can not bond and transfer information to other smart phone unless the device delete bond information with the Smart Phone A first?

I am very sorry for my English.

Thank you for your support.

Parents
  • Yes, it is possible.

    First advertise without whitelist.

    Smart phone A connects and does just works bonding. (You have to do this in a safe environment to not be vulnerable to passive eavesdropping and MTIM attacks.)

    Then disable pairing/bonding.

    If you get disconnected, advertise with whitelist (to filter out connection requests from unfamiliar centrals).

    (Be aware that a hostile central can use the address of the trusted central to get through the whitelist and connect, but it will not be able to pair/bond (when this is disabled). However, you will have to detect this and disconnect.)

    If the bond is deleted, enable pairing/bonding and advertise without whitelist.

    On program startup check if a device is bonded, if it is, disable pairing/bonding and advertise with whitelist, if not advertise without whitelist.

  • Dear Petter, what is more meaningful to protect peripheral against hostile centrals: direct advertising or whitelist? Also could you kindly review pros and cons of both approaches? Use case is as above: peripheral is intended to be connected to the only central.

    About the same question for protecting a central against hostile peripherals: filter or whitelist?

    BTW you wrote "Then disable pairing/bonding". I guess this is done by pm_sec_params_set(bond = 0). Can it be called at any time?

Reply
  • Dear Petter, what is more meaningful to protect peripheral against hostile centrals: direct advertising or whitelist? Also could you kindly review pros and cons of both approaches? Use case is as above: peripheral is intended to be connected to the only central.

    About the same question for protecting a central against hostile peripherals: filter or whitelist?

    BTW you wrote "Then disable pairing/bonding". I guess this is done by pm_sec_params_set(bond = 0). Can it be called at any time?

Children
No Data
Related