Pairing on demand & Automatic bonding

[Sebastien DRI]

Hi Folks,

I am just asking general information (explanation and/or code samples examples) to set up a secured BLE connection between multiple centrals towards one peripheral working as BLE uart.

Her are my concerns for the moment:

I plan to use preconfigured random static adresses for each central stored in flash memory but also for the peripheral one.

-At this stage, I am asking to myself if I can launch a pairing on demand I mean on a specific hardware action I want to launch the pairing process which store the bond info in peripheral whitelist. I only see pairing at BLE initialisation. Could we launch a pairing on demand when BLE is already active?

-I also want to secure the bond creation during the first pairing phase to avoid an unknow device to bond on a sapre whitelist element so I understand there are many ways like presharing keys , LESC with passkey so that the ones which have the pass can proceed the pairing. Could you please me orientate toward sample code within SdK who do the job?

-Once pairing is ok, I understand that a peripheral whitelist must be fullfilled with the bond information freshly created. Seems perfect. I suppose that bond must be ko if a central or 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.

Is it a proper way to work? I mean in a secure way.

Thank u again for all your advices.

The best.

Sebastien

[Edvin]

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.

 

Could you please me orientate toward sample code within SdK who do the job?

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

 

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

 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

[Sebastien DRI]

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

[Edvin]

Sebastien DRI said:

IRK adress is only existing for private static resolvable adress, not static, right?

 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:

 

I suppose that bond must be ko if a central or peripheral random static adress changes.

 What do you mean by this?

[Sebastien DRI]

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.

Edvin said:

I suppose that bond must be ko if a central or peripheral random static adress changes.

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.

[Edvin]

Sebastien DRI said:

What happens if the central device static adress changes after an established connection? Does it delete the bond between the two? 

 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. 

 

Sebastien DRI said:

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.

 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

[Sebastien DRI]

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 

[Edvin]

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. 

 

Sebastien DRI said:

-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.

 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?

[Sebastien DRI]

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?