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);
}
}
}
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)
