How to make sense of the address(es) returned in aci_gap_get_bonded_devices

[SBukh.1]

When a central device bonds with my peripheral, I check the public address of the connecting/bonding device and store it for later use. I was expecting that aci_gap_get_bonded_devices would return the address of any bonded devices, but the address(es) retrieved by aci_gap_get_bonded_devices do not match the address values of connecting devices.

How are you supposed to make sense of the address(es) returned via aci_gap_get_bonded_devices?

How can I compare a connecting device's address against the address(es) returned via aci_gap_get_bonded_devices?

[Winfred LU]

Could it be an issue for the BLE private (resolvable) address?

May you please check if public addresses are used?

BLE_Security project in DK shall be interested. (located in path to BlueNRG-1_2 DK 3.2.1\Project\BLE_Examples\BLE_Security)

[DEdwi.1]

Can you post the actual contents of the aci_gap_get_bonded devices and your expected addresses (need the 49 bit numbers, 48 address bits and 1 address type bit)

You must remember that addresses can be spoofed, so using the addresses to remember the identity of a device is a bit insecure, one way to verify identity would be connect to the device and wait for the successfully encrypted event, that will verify the address and the identity.

Typically in the encryption database the encryption information is not indexed by the address but would be indexed by the EDIV and RAND, sometimes depending on implementation only EDIV is used. Addresses are not identity information and are usually not stored (they can be stored but not needed). The addresses are likely to be stored for the whitelisting.

In your case if your central is an iOS device, it is likely using a private resolvable address (as @Winfred LU​ mentioned) rotating every 15 minutes, so you can get a lot of addresses different from the one that you connected to even when the central is identical. It should be possible for you to resolve the identity of the central device if you have access to the encryption information (IRK), this will allow you to get a hint on the identity of the central before connecting to it,

A bit longish post and I hope it helps.