Pairing on demand & Automatic bonding

RE: Pairing on demand & Automatic bonding

Simonr — Fri, 25 Jun 2021 12:38:05 GMT

Edvin is out of office for the time being. This case is also rather old, so if you have any further questions I would suggest making a new DevZone ticket and rather link to this one if relevant.

As for the question on whitelisting, it does indeed seem like you understand the behavior correctly. Devices that are not whitelisted will not be able to connect to a central that is scanning for specific whitelisted devices, and new devices must be added on the central side.

Best regards,

Simon

RE: Pairing on demand & Automatic bonding

Sebastien DRI — Wed, 23 Jun 2021 14:30:46 GMT

Hi Edvin,

Sorry for the late response.

Today I am back to close this chapter on bonding & Whitelist. So as far as I understand, once bonding is done, peer is automatically registered into whitelist as long as we do not remove it.

My concern was about ensuring when we advertise / scan with whitelist that no other device could be bonded (so added to the whitelist) when running in that mode.

Consequently I suppose no more bonding could be allowed while adverstising/scanning with whitelist since the purpose is to restrict new entrant.

Is it the normal behaviour? Do I understand well?

RE: Pairing on demand & Automatic bonding

Edvin — Tue, 06 Apr 2021 10:51:50 GMT

I suggest you look at how the examples implement this. Look at the ble_app_gls example from the SDK, and how it uses a button press to open for new bonds.

[quote user="sebastopolix"]

-I have a whitelist of 8 elements and for example one bonded and connected central in the whitelist.

How do I prevent from a new authorized peer (by the mean of LESC) to bond and thus registered into the current whitelist?

I want him to be bond once I manually open the whitelist to a new peer.

[/quote]

I don't understand what you mean. Do you want to differ between adding devices to the whitelist and bonding? In that case, that is not the typical use case, and you would have to change the implementation of the peer manager. But ask yourself what you really want to achieve by doing this and whether it is the intended behavior. I don't understand why you would want to do that. Are you really sure you need the whitelist at all in that case? Do you know what the whitelist is used for?

I asked you earlier, but I don't think you answered. Is the whitelist intended for advertising or scanning? And are you going to connect to the devices in the whitelist?

RE: Pairing on demand & Automatic bonding

Sebastien DRI — Wed, 31 Mar 2021 14:54:32 GMT

Hello,

Thank you.

Everything become more evident now.

One final question about advertising with whitelist:

-I have a whitelist of 8 elements and for example one bonded and connected central in the whitelist.

How do I prevent from a new authorized peer (by the mean of LESC) to bond and thus registered into the current whitelist?

I want him to be bond once I manually open the whitelist to a new peer.

Thank you again

RE: Pairing on demand & Automatic bonding

Edvin — Mon, 29 Mar 2021 13:26:07 GMT

[quote user="sebastopolix"]What happens if the central device static adress changes after an established connection? Does it delete the bond between the two? [/quote]

No, it doesn't. Not unless you tell it to, but then how would you know what device to delete from the whitelist if a new random address appears?

Either way, the nRF's come with a preprogrammed address, that doesn't change during the lifetime of the nRF. However, if you for some reason need to do so, you can change the address manually, but unless you do this, the address will not change.

[quote user="sebastopolix"]I do not plan to perform such a kind of scenario but it was just in the goal to better understand on which elements are based the bond information when random static addressing is used.[/quote]

The bonding information is built on the address. It is the address that is used in the whitelist, and paired with the peer ID.

BR,

Edvin

RE: Pairing on demand & Automatic bonding

Sebastien DRI — Mon, 29 Mar 2021 11:32:01 GMT

Hi Edvin,

Thank u again for your answer.

I am planning to connect on another embedded device. More precisely, I use a NUS central/peripheral implementation.

I am asking about private resolvable address since IRK is related to that concept but our actual need is to evaluate the best solution for securising the link between centrals and peripheral.

I understand the privacy concept behind this type of addressing and we do not need that so Random Static address will be convenient. My only concern was to check what information to store in Whitelist and in flash memory since we want to reconnect automatically upon new start up.

So in fact our needs is to set up various central static adresses that will remain unchanged with time and to keep bonding track on those adresses even if µC restart.

[quote userid="26071" url="~/f/nordic-q-a/73283/pairing-on-demand-automatic-bonding/302338#302338"]I suppose that bond must be ko if a central or peripheral random static adress changes.[/quote]

I was asking that question for a current alive connection between two paired devices. What happens if the central device static adress changes after an established connection? Does it delete the bond between the two?

I do not plan to perform such a kind of scenario but it was just in the goal to better understand on which elements are based the bond information when random static addressing is used.

Thank you again for your time.

RE: Pairing on demand & Automatic bonding

Edvin — Mon, 29 Mar 2021 10:23:58 GMT

[quote user="sebastopolix"]IRK adress is only existing for private static resolvable adress, not static, right?[/quote]

IRKs are used for Random Private Resolvable Addresses. "static" would indicate that the address is not changing. "resolvable" indicates that it is possible to use an IRK key to find the owner of the address. A private non-resolvable address would indicate that it is changing to completely random addresses.

Tell me, what are you actually trying to connect to? Is it a phone? Computer? Or another embedded device? The reason I ask is that typically, you don't have to think about these address types. I rarely see questions about it.

Or are you actually trying to implement a random private resolvable address on the nRF? If so, why?

Or did we just start barking up the address type tree for no apparent reason?

I just wanted to let you know that if you start changing your address on the nRF, which by default uses a random static address, then this will be considered a new unbonded device (to all previously bonded devices). The reason I pointed this out was that you wrote:

[quote user=""]I suppose that bond must be ko if a central or peripheral random static adress changes.[/quote]

What do you mean by this?

RE: Pairing on demand & Automatic bonding

Sebastien DRI — Fri, 26 Mar 2021 15:21:54 GMT

Thank you very much for your fast answer.

Could you please clarify the last point ?

IRK adress is only existing for private static resolvable adress, not static, right? Do you suggest to use private resolvable adressing?

So if I am changing a random static key after bonding, does it suppress automatically the bond, meaning I must perform a renew the pairing?

Thank you again Edvin

RE: Pairing on demand & Automatic bonding

Edvin — Fri, 26 Mar 2021 14:54:38 GMT

Hello,

You can initiate this on a hardware event. Usually, it is initiated by the connection event, but you can do it in any event. I believe the ble_app_hrs_c example initiates bonding, so you can look at that example for reference.

[quote user=""]Could you please me orientate toward sample code within SdK who do the job?[/quote]

You can check out the ble_app_gls, which has the passkey implementation.

[quote user=""]peripheral random static adress changes. Consequenly, I plan to keep both bond information in the whitelist & original random static keys in flash and reload them at start-up[/quote]

yes and no. If a device with a random static key changes the address, it will be seen as an unknown device. If a device has a resolvable address, it can change the address, because the IRK (Identity Resolution Key) can resolve the address, meaning it can check whether the address that is currently being used is one of the addresses in the whitelist "in disguise".

Best regards,

Edvin