13

For a Bluetooth project with Xamarin (Android API 21 and up) I would like to know if it is common to create a bond with a Bluetooth device. The current requirements are:

  • The Bluetooth device is used frequently, but not continuously.
  • Reconnecting should happen as fast as possible
  • Bluetooth address changes randomly when the device is powered down
  • The device's name is unknown, null or random
  • The connection is encrypted
  • The connection uses an overlying API that requires a Bluetooth Device as parameter for connection.

Should one create a bond with this device for "better" recognition (as some sort of cache) or reconnect to the device "from scratch". What is common in this scenario? SO it is not a question of "Can I bond", but is it necessary to bond, or even better: what is a coorect and working, reliable scenario.

Currently I use code like this (result.Device.Name is for dev purposes):

  public override void OnScanResult([GeneratedEnum] ScanCallbackType callbackType, ScanResult result)
    {

        if (result.Device.Name == "��" &&

            !_discovered &&
          result.ScanRecord != null &&
          result.ScanRecord.ServiceUuids != null &&
          result.ScanRecord.ServiceUuids.Any(x => x.Uuid.ToString().ToUpper() == uuid))
        {
            lock (_locker)
            {
                _discovered = true;
                _deviceList.Add(result.Device);
                BluetoothDiscoverySucces?.Invoke(result.Device);
            }
        }
    }
Caspar Kleijne
  • 21,552
  • 13
  • 72
  • 102

1 Answers1

33

Short answer: the correct, common, and reliable scenario is to bond. Bonding means the connection is secure and the link is trusted. It means that your local device will usually find the remote device even if its address is changing. Pairing/bonding is recommended practice in Bluetooth for security and privacy reasons.

Long answer: since its introduction, incremental versions of the Bluetooth spec have added features to improve the security and privacy of Bluetooth devices. Many devices will not allow you to exchange data or properly track them unless you are paired/bonded (The difference between bonding and pairing is that with bonding, the exchanged keys are stored in the database.)

In Bluetooth Low Energy, the pairing/bonding process consists of three stages:-

Phase 1 - Pairing Feature Exchange

The two connected devices exchange their IO capabilities (e.g. does the device have a keyboard), authentication requirements (e.g. to bond or not to bond) and supported key sizes.

Phase 2 - Authentication and Encryption

Using encryption algorithms a key is generated and used to encrypt the link (this is different for legacy and LESC pairing, but it is beyond the scope of this question).

Phase 3 - Key distribution

Several keys are exchanged between the devices including the CSRK (Connection Signature Resolving Key), the IRK (Identity Resolving Key) and the static address.

Of particular importance to your question is the IRK and the address. Since Bluetooth v4.0, a feature known as LE Privacy allowed the device to continuously change its address to reduce its track-ability. Malicious devices would not be able to track the device implementing this feature, as it actually looks like a series of different devices. In order to resolve the address, the devices need to be previously paired/bonded. If the remote device contains the IRK then it can use that and the random resolvable address to derive the Bluetooth device's original address.

So, going over your criteria:-

  • The Bluetooth device is used frequently, but not continuously.

If you are going to disconnect/reconnect frequently, you can pair once with the device and store the keys (i.e. bond). Pairing is no longer needed afterwards as the same keys will be used to encrypt the connection upon disconnection/reconnection.

  • Reconnecting should happen as fast as possible

Connection and bonding are two different things. It will take the same amount of time to reconnect regardless of bonding being implemented. However, once the devices are reconnected, it will take some time for the connection to be re-encrypted.

  • Bluetooth address changes randomly when the device is powered down

This means that the device is utilising the LE privacy feature. Therefore your device should be bonded with it in order to resolve the private resolvable address.

  • The device's name is unknown, null or random

This is usually the case with BLE. The devices are usually identifiable via their address. As such if your devices have previously bonded you will be able to resolve the changing address and identify the remote device.

  • The connection is encrypted

You cannot achieve an encrypted connection without pairing first (as per the 3 phases above). With bonding you are storing the keys in your database, therefore ensuring that you can use them in the future to re-encrypt the connection without having to go over the pairing phases.

  • The connection uses an overlying API that requires a Bluetooth Device as parameter for connection.

I am not sure what this means, but is irrelevant to the requirement for bonding.

For further reading on the subject, I recommend visiting the Bluetooth Specification Version 5.0, Vol 3, Part H, Section 2 Security Manager (page 2295)

Youssif Saeed
  • 11,789
  • 4
  • 44
  • 72
  • 2
    If the peripheral has the Service Changed Characteristic and the devices are not bonded, the client is required to perform a service discovery upon each connection, which takes time. If the devices are bonded, the client does not need to perform a service discovery upon each new connection. – Emil Mar 21 '17 at 00:26
  • Very helpful: can you elaborate: This means that the device is utilising the LE privacy feature. Therefore your device should be bonded with it in order to resolve the private resolvable address.How to get that address? – Caspar Kleijne Mar 21 '17 at 12:29
  • If a device implements LE Privacy, then the address that it adds to the advert packets can be Private Resolvable or Private Unresolvable. As its name implies, if it is private unresolvable then there is no way to know the true address of the device. This is usually the case for beacons when connection/pairing or data transfer is not intended. – Youssif Saeed Mar 21 '17 at 14:44
  • 1
    If a device is using a private resolvable address, then that address is generated using the local IRK and the local device’s original address. When you pair with that device, in phase 3 of the process, you get both of these values (the IRK and local device address). So given you see the remote device's address in the advert packets, you can then use a process to find the original device address from the IRK and compare it against the address you have (more information can be found in Bluetooth Specification Version 5.0, Vol 6, Part B, Section 1.3.2.3 Private Device Address Resolution). – Youssif Saeed Mar 21 '17 at 14:44
  • 1
    Please note that track-ability is only one of the reasons that bonding should be used. As Emil stated, another reason would be to detect the Service Changed Characteristic. Furthermore, I believe some profiles mandate that pairing exists before data transfer is performed (e.g. The Health Thermometer Service). – Youssif Saeed Mar 21 '17 at 14:46
  • @YoussifSaeed, So you mean to say, not all BLE peripheral devices allows me to read/write without doing the bond or their implemented security protocol being completed? For eg, with some devices I can read/write just after 'connect' and for some devices we need to complete 'connect' and 'bond' inorder to read and write? – santhosh kumar Jun 23 '20 at 13:25