This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Pairing on demand & Automatic bonding

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

  • 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 

  • 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?

  • 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?

  • Hi

    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

Related