• State Verified Answer
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 1562 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 121462
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bond information stored multiple times for same peer

Jebakumar

Hi,

Peer A is bonded to the device. Now device has Peer A bond information. For some reason, Peer A has un-bonded the device. As device doesn't know this it still keeps the Peer A info.

Here is the situation, later at some point of time Peer A bonding to the device again. But device couldn't identify it as the same peer which was bonded before from its stored bond information. So device identify the peer as a new one and store its bond info in the next available index.

I have checked the Flash Storage. the IRK and Address are same at both index location. but the remaining info are different at both index location.

  • Is there any API or settings provided in the SDK to avoid this duplicate storage? Or
  • Should application take care of checking IRK and Address info and deleting the previous storage?

I am using S110 SD and SDK V10.0.0.

Best Regards, Jebakumar.

  • +1

    Assuming that you are using the device manager (DM).
    When connecting DM will check if there is an IRK match. You will only get an IRK match if the whielist is used. If the whielist is not used it will call the function device_instance_find which will check if there is an address match. If the peer device uses a resolvable private address you will not get a match, thus you will get a duplicate (will typically happen with iOS or newer Android Phones)

    To resolve this issue you can add a check (e.g. im_address_resolve from the peer manager) to control the IRK. Then if you have a match you know you have already bonded to this peer and should disconnect and tell the user to manually delete the bond. It's possible to replace the old bond information at this stage as well, but I would not recommend it as it would be quite easy for an attacker to replicate the address and get an IRK match to replace the bond. Note that only the LTK (identified by EDIV and RAND) should be used to authenticate a known peer.

  • 0 in reply to run_ar

    thanks for the information. I haven't used whitelist feature. Did you mean that if whitelist is used then the duplication will not occur?

Related