connecting, bonding, pairing, and whitelists

RE: connecting, bonding, pairing, and whitelists

Igor Ganapolsky — Tue, 04 Apr 2017 23:36:03 GMT

@EinarThorsrud So if I just pair, and NOT bond, can the connection still be encrypted?

RE: connecting, bonding, pairing, and whitelists

Einar Thorsrud — Thu, 25 Feb 2016 06:27:42 GMT

You are right. Most phone (at least iOS devices and for Android devices with Lollipop or newer) use a random private resolvables address, that changes at regular intervals, but can be calculated from the IRK. And as you write, this makes whitelisting not usable unless they are paired or bonded. This post has some more info on the subject.

RE: connecting, bonding, pairing, and whitelists

GlennEngel — Thu, 25 Feb 2016 05:45:18 GMT

Just to recap my understanding - A device can be connected to a master and communicate via configured characteristic. If they exchange encryption keys they can become bonded if the keys are stored for the next connection. This somehow allows a whitelist to be used as the stored keys allow the device to recognize a previously connected master even if it has a new mac address. It sounds like whitelisting is not usable with most phones unless they are paired and bonded.

RE: connecting, bonding, pairing, and whitelists

Einar Thorsrud — Thu, 18 Feb 2016 07:58:42 GMT

@awneil: Of course it should be 4 s. The "m" snuck in somehow, but I have updated the post now. Thanks for noticing!

@GlennEngel: In principle you can use the whitelisting support in the SoftDevice without pairing or bonding. The whitelist is supplied to the SoftDevice in the call to sd_ble_gap_adv_start()`. However, that means that you need to use a non-standard way to retrieve the IRK from the peer initially, as it is used for whitelisting. In the unlikely case that your central does not use a private resolvable address (this rules out most phones etc.), you do not need the IRK, but can just use the static address instead.

RE: connecting, bonding, pairing, and whitelists

GlennEngel — Wed, 17 Feb 2016 17:32:31 GMT

Thanks for the great definitions and links. Is pairing an automatic part of the android gat connection or do I need to initiate this with an explicit api call? At this point I'm just connecting and things are working fine but of course I want to trigger saving of the central into the white list when a connection occurs. Is there a way to use the whitelist capability without requiring the app to explicitly pair and/or bond?

RE: connecting, bonding, pairing, and whitelists

GlennEngel — Wed, 17 Feb 2016 17:25:03 GMT

Yikes, First i read about bond_manager and discovered via a post on this board that device_manager was recommended. Now I learn that even that post is out of date and the peer_manager is now the solution of choice! It would be good to mark those old posts and api documents with deprecated messages.

RE: connecting, bonding, pairing, and whitelists

awneil — Wed, 17 Feb 2016 15:45:36 GMT

You mean, "connection interval can be between 7.5 ms and 4 s" - ie, the maximum is four seconds (4000 ms)

RE: connecting, bonding, pairing, and whitelists

Einar Thorsrud — Wed, 17 Feb 2016 14:50:02 GMT

This is a short description of the terms, and how they are linked together:

Connection: A central (master) can connect to a peripheral (slave). While the connection is active the master and slave will communicate regularly at a determined interval. This connection interval can be between 7.5 ms and 4 s.
Pairing: Devices that are initially connected can exchange encryption keys and encrypt the link. When they have, the link is secure and they are paired.
Bonding: Paired devices can be bonded. This means that they store the keys that have already been exchanged when they paired and use those again the next time they connect.
Whitelisting: The whitelist is used to restrict connection or scanning from any other than predetermined (known) devices.

The SDK provides libraries in order to assist in bonding and whitelisting: The older device manager and the new (currently experimental) peer manager. You can reset all the bonding information and disable the whitelist when desierd. E.g. with the peer manager you can delete all bonds with pm_peer_delete_all() and create a new empty whitelist (pm_wlist_create())and set it (pm_wlist_set()).