Should One Create a Bond with a Bluetooth Le Device

Should one create a bond with a Bluetooth LE 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)

Can I bond a Bluetooth Low Energy device?

Android notwithstanding, BLE is a branch of Bluetooth 4.0 and, as such, should supporting pairing and bonding.

Technically, the "Just Works" method still implies bonding. However, in my experience it isn't necessary for both Android and iOS devices to connect and read from BLE devices that have authentication disabled.

Is Bonding required for BLE - Android, iOS device communication?

Based on what we got working and based on the answers to this question.

A1: Yes, it's possible if no MITM is set and the Security scheme is set to Just Works, which means no security at all.
A2: Bonding is not required for BLE communication. If the BLE device can't store the Bond information, it may lead to some issues as we got in our case. If the BLE device is able to store and use Bond information then it's recommended to Bond.
A3: The Connection will not be closed. The only downside we got is that now it takes a little more time to reconnect.
A4: The app is initiating the connection, but the dialog is shown only if the BLE device requests some type of security, it can be MITM, encryption, pin. Short answer, the pairing dialog can be avoided by changing the settings on the BLE device.
A5: When having the device with Just Works security protocol, with no bonding and no MITM protection the pairing dialog should not be presented. We got no pairing dialog experience on both iOS and Android.

Does BLE device generates new LTK, CSRK, and IRK every time it bonds with new device?

The IRK is always constant (the same IRK is shared in every pairing attempt) and is used to create random resolvable addresses. Devices that receive an IRK from a remote device can then figure out if a random resolvable address belongs to a particular IRK.

All other keys are unique for every bond.

The CSRK must in particular be unique for every bond since there is a counter associated with it, incremented on every packet write to avoid replay attacks. This would not work security wise if two bonds have the same CSRK, since an attacker could then replay packets from bond 1 when impersonating bond 2 (assuming the packet counter is less for bond 2).

The LTK, EDIV and RAND are used to derive a session key for encryption the next time a connection between the same pair of devices connect.

Thus the answer to Q1 is that the keys are reused for every new connection attempt between the same pair of devices, as long as the bond exists.

If you in particular copy the IRK from one central to another, then yes a connection between P1 and C2 can be made and all the other keys can be used during this connection, if C2 uses a random resolvable address. This is because P1 believes it talks to C1 due to the random resolvable address. After all, on the Link Layer it's impossible to tell C2 and C1 apart if random resolvable addresses are used with the same IRK.

If random resolvable addresses are not used, then it's usually not possible to copy a set of keys between devices. This is because the keys are associated with the Bluetooth device address (public or static random). If a central using a different address connects to a peripheral, the peripheral will look up bonding keys in its database to find out there are no LTK, EDIV, RAND, CSRK stored for this address. In some implementations though for encryption setup, the peripheral will look up the LTK based on EDIV and RAND instead of the address. In this case copying of keys will work, at least to establish encryption. The CSRK is always looked up from the address though. Note that for LE Secure Connections, EDIV and RAND are always 0 so in this case the LTK is always looked up from the address.

Note that the use of CSRK is not widespread at all. I have not seen any implementation use it in a real product. Since only the "Write Without Response" command can be used with CSRK and the fact that a counter must be stored persistently, normal authenticated encryption that covers every kind of packet is usually a better idea, since the few encryption setup packets can usually be tolerated.

Can I have an encrypted BLE connection without bonding? / Pairing BLE devices without bonding

This is totally possible according to the Bluetooth protocol specification. If at least one device sets "bonding flags" to "no bonding" in the AuthReq field of the Pairing Request or Pairing Response, no bonding information shall be permanently stored.

If you're using BlueZ, I'm not sure if it allows you to configure this though.

For Android, people report that Android does not respect this flag and creates a bond anyway (Why does Android bond even when asked not to bond?).

Should One Create a Bond with a Bluetooth Le Device