Whitelisting with resolvable random address

[vuanh-minh]

Hello,

I am working on a BLE device ( ESP32 ) with a pairing process, which allows only previously bonded device to connect back using C++ BLE library. For that, i use whitelisting to memorize the address, and only advertise to these addresses. The problem i have, is that the address of Android and iOs are randomly generated, and changes. In consequence, the device cannot advertise to previously address when the address has changed.

How can my ESP32 memorize the real address of my application to advertise correctly to target device ?

Thank you

[chegewara]

In bluetooth there is something like RPA its resolvable private address:

The Resolvable Private Address (RPA) is the backbone for privacy in BLE devices. An RPA is an address that’s generated using a random number and the secret Identity Resolving Key (IRK). This IRK is shared between two devices at the time of pairing and stored in the device’s internal memory during bonding.

When devices are paired they exchange keys, one of them is IRK, that allows to resolve RPA when peer device is trying to connect. In this library you can use this function to control what devices can request for scan response and connect to esp32:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEAdvertising.cpp#L110

When i find some time i will try to help you with this if you find it hard to use.

[vuanh-minh]

Hello, thank you very much for you answer @chegewara

I tried the bonding process with the SampleServer_authentification_passkey, and SampleClient_authentification_passkey, but it seems that once the authentification is completed, the random address is showed, but i don't know if the real one is stored in the whitelist ?

Another thing i don't really understand is, if i add the real address with BLEDevice::whitelistadd(), will the advertising work for the resolvable random address ?

[chegewara]

With RPA it does not matter which address is stored, because at the end the device is recognized or not as whitelisted device. Its all happening under hood.
Its some sort of encrypting mac address using IRK key. Each time device is trying to connect its address and IRK is checked against whitelisted devices.

I really dont know if real mac address added with whitelistadd() will be recognized later when it is RPA, but as far as i understand it should work.

[chegewara]

Hi, i did few tests and i am confused now. With pAdvertising->setScanFilter(true, true); only whitelisted devices should be able to scan for and connect to esp32. And here is why i am confused:

• android device cant scan esp32 if is not whitelisted and cant connect even if is whitelisted (probably because of random mac address),
• windows 10 laptop can scan even if its not whitelisted and can connect if it is whitelisted (its weird, because with android i see laptop mac is random, but esp32 is bonding always the same mac and is consistent with bluetooth radio address)

[MehmetCagriK]

@chegewara To solve the confusion, I must ask some questions. By scanning, you mean "scanning the area and recognizing device's advertisement data on your app" or "sending a scan request to a device which you recognized with its advertisement data"

[chegewara]

scanning the area and recognizing device's advertisement data on your app.

When i set scan filter to whitelisted only then i cant see esp32 with android smartphone at all, but i still can see it with laptop.

[MehmetCagriK]

OK. I am assuming there is a misunderstanding with scan filter. The function setScanFilter has these comments;

/**
 * @brief Set the filtering for the scan filter.
 * @param [in] scanRequestWhitelistOnly If true, only allow scan requests from those on the white list.
 * @param [in] connectWhitelistOnly If true, only allow connections from those on the white list.
 */
void BLEAdvertising::setScanFilter(bool scanRequestWhitelistOnly,	bool connectWhitelistOnly) {
...
}

There is a concept of scan request. When a device broadcasts a data with their advertisement packets, they are heard by some other ble nodes. There is also another way of sharing data without connection that is built on advertisement mechanism that is called scan response. Scan response data is prepared along with advertisement data with advertisement type set scannable. This scan response data is not broadcasted with advertisement however, it is sent after advertiser device receives scan request.. To summarize, for scan response data to work, you need the conditions below;

1. Advertiser puts data into scan response data buffer
2. Advertiser sets its advertising type to ADV_SCAN_IND
3. The devices that are interested in scan response data sets their scanning type to active scanning.

If the nodes who heard the broadcasted advertisement are interested about more specific data which is not in advertisement package, they sent a scan request to obtain that extra data(remember that advertisement type was set to scannable, so the devices know which advertisers can also provide scan response data).

So setScanFilter() function does not make your advertiser device invisible to outside world. First argument allows which devices can ask for extra data that is held in scan response data buffer. Second argument is clear, so I won't explain it. So, correct me if I am wrong but setScanFilter does not work as you assumed.

Another thing about seeing devices or not might be connected to implementation of the apps. For example, I have not seen a single app that implements advertisement and scan response correctly. They are written with assumption that scan response overwrites advertisement data which is false. Scan response data is asked by devices after they receive advertisement data first. Maybe your app was poorly implemented, developer mistook the function as you did(my assumption,correct me if I am wrong on this).

[chegewara]

So setScanFilter() function does not make your advertiser device invisible to outside world.

In theory you are right, i think the same way. The problem is i am performing those tests now, i am changing only one parameter from true to false and back, and this is how it looks like with my android smarthones (two samsungs - s4 and s9+) and laptop with windows 10.

Test app are:

• on android its nRF connect,
• on windows is system bluetooth scan.

[chegewara]

Ive been doing some tests with direct advertising and probably it is not working. I cant set peer_addr_type to other value than BLE_ADDR_TYPE_PUBLIC. Also setting adv_type to ADV_TYPE_DIRECT_IND_HIGH does not work. I am awaiting response from esp-idf devs.
espressif/esp-idf#2469

[MehmetCagriK]

I suspect ESP-32' s BLE API is incomplete and rushed. They provided the most common and wanted interfaces but current API does not allow fine tuning of all parameters, therefore you can not do what BLE brings to the table. For that reason, I switched to Texas Instruments BLE boards. They provide really good documentation and more complete API.

[simfero]

@chegewara @MehmetCagriK @vuanh-minh Guys, have you had any luck whitelisting and filtering random MAC addresses since your last exchange back in October? I figured out how to resolve the static address from the random address after bonding, but whitelisting that static address still won't work with filtering since Android device connects with new a new random address that doesn't match the whitelist.

[chegewara]

Hi, since esp-idf issue is still open and i am suspecting it can be hardware issue, i dont even try to do anything with whitilisting, sorry.