BLE pairing vs. bonding

Hi all,

Just a quick writeup on the difference between pairing and bonding, since these terms get used interchangeably. I think this has to do with the usage of ‘pairing’ in Bluetooth Classic, or BR/EDR.

As far as Bluetooth LE is concerned, pairing and bonding are two very distinct things. The short explanations are that pairing is the exchange of security features each device has, and creating temporary encryption. Bonding is the exchange of long term keys AFTER PAIRING HAS OCCURRED, and STORING THOSE KEYS FOR LATER USE. Pairing is not the creation of permanent security between devices, that  is called bonding. Pairing is the mechanism that allows bonding to occur.

Pairing

Pairing is the exchange of security features. This includes things like i/o capabilities, requirement for man-in-the-middle protection, etc. The client side begins this exchange. The client essentially says ‘hey, i’d like it if you had these features’. The server replies, ‘yeah, well, this is what I can do’. Once this exchange is made, the security that will be used has been determed. For example, if a server supports just noInput/noOutput for i/o capabilities, the Just Works pairing mechanism is going to be used.

Once the pairing feature exchange is complete, a temporary security key is exchanged and the connection is encrypted, but only using the temporary key. In this encrypted connection, long term keys are exchanged. These keys are things like the (long term) encryption key to encrypt a connection, and also things like a digital signature key. The exact keys exchanged are determined by the security features of each device.

Bonding

This really just means that after the pairing features exchange and the connection has been encrypted (these two together are called ‘pairing’), and keys have been exchanged, the devices STORE and USE those keys the next time they connect. Keys can be exchanged using the bonding procedure, but that does not mean they are bonded if the keys are not stored and used the next time.

If a device is bonded with another device, like a heart rate monitor and a smartphone, they can encrypt the connection without exchanging any sensitive security information. When the smartphone connects to the heart rate monitor, it can just issue a ‘turn on encryption’ request, and both sides will use the keys already stored, so nobody snooping can see a key exchange and therefore decode the messages being sent, as is done when pairing.

Hope that clarifies!

Bluetooth LE Security Across Platforms

Hello all,

Bluetooth LE devices that connect to a Client (e.g. computer, smartphone) have several ways they can configure their security that is valid, but different platforms (windows 8, android, iOS) handle security differently. A device with good security may not be able to use it effectively on one platform where it is perfectly fine on another.

The (spoiler alert) truth is that none of them turn encryption on automatically, so if your device has the ability to use encryption, it might not necessarily be getting used. The easy work around is to have your device send a slave security request on each connection. The more ‘correct’ way is to limit access to an individual characteristic value per its security requirements, and if a platform tries to connect to a device and read its value, at that time an insufficient authentication message should be sent. This is at least how Apple’s BLE guidelines go.

This post contains information about some of the differences between platforms.

Windows 8

General Notes

Where most other platforms search for and connect to BLE devices within an application, windows 8 adds them to its device list through the operating system. When adding the new BLE device, windows will pair with the device. If the device has no security, it will add the device. If the device is bondable, windows will bond with the device and thus enable encryption for exchange of long term keys. If the device can pair but does not support bonding, windows will fail adding the device. It appears that windows does not allow encryption without bonding.

Once the device has been added, it will stay connected until the device disconnects or an application uses the connection with the device, then disconnects from that BLE connection. And other stuff like a reboot will cause a disconnect, of course.

Another thing windows does when adding the device to its devices list is read the GATT database of the device, and store it. When writing an application, be aware that until a live value is actually needed from the device, windows does not connect to it. So, for example, if you want to read a characteristic descriptor, which is an unchanging string that describes a characteristic like “Temperature Reading”, windows 8 will have stored that information in its registry and will not actually connect to the device to read this. When reading the actual temperature, which changes, windows will then connect to the device to get this value. However, the API uses the same call to do both things.

Windows communicates to BLE devices using an API that is written in C++, so if you are developing in C# you will have to work with C++’s unmanaged functions. I don’t know a ton about windows programming, so I will just stop here before I get out of my element.

Security Considerations

As far as security is concerned, be aware that though windows sets up encryption when adding the device, it does not automatically enable it later, when an application connects to it. From the windows side, pairing or enabling encryption can be forced when the windows API GATT functions include a flags field. To enable encryption and such, use the flag BLUETOOTH_GATT_FLAG_CONNECTION_ENCRYPTED and/or BLUETOOTH_GATT_FLAG_CONNECTION_AUTHENTICATED.

I have not (as of dec 2013) seen a comprehensive guide for how windows 8 ‘does’ BLE. So far, it seems like the information on MSDN here is about all there is, and you have to already know a lot about how windows uses Bluetooth, because they only fill you in on the BLE parts. Find a demo application, and go from there is what I suggest.

Apple

Apple publishes BLE guidelines here. There are really two main things to say:

1) Apple expects that the device is being developed to talk to them alone, so it can be impractical to design a device for all platforms and follow all their guidelines. Fortunately, you can basically ignore these guidelines and Apple devices will still talk to you.

2) There is absolutely no way to get iOS (at least, iOS7 as of dec 2013) to request that a device bond, or encrypt a bonded connection. This only happens when the device sends it an insufficient authentication message after iOS tries to interact with a characteristic (I think just characteristic value, but I’m not sure). Several manufacturers just use the slave security request instead, which will cause pairing to start or encryption to be turned on if the devices are bonded.

Android

Android provides several functions to handle managing a bond (e.g. createBond()). I cannot tell you if that is how encryption is enabled once already bonded. I know the least about working with Android.

I hope these notes have been useful!