2

As I understand it, Bluetooth Low Energy communication can be established with or without pairing. This is in the context of mobile development, Android more specifically but I believe iOS is more or less the same.

Are there instances where one would choose one over the other? And what would be the purpose? What is technically considered paired communication and what is considered unpaired communication?

I've dabbled around for a bit on the differences and have even made a few demo only apps related to BLE but I haven't found a clear explanation if what I am doing is actually considered paired or not.

Edit:

The reason I ask the question is that I believe I am looking to encrypt unpaired BLE connections. In some cases, and essentially my main use case, a mobile device may want to connect to several different peripherals randomly at different times throughout the day and the process of physically accepting a pair request seems unnecessary and quite time consuming. By 'randomly' I mean I am walking by one if I have a dozen scattered around my apartment and I personally don't know exactly which one without physically checking. I don't what to walk in the room the first time and have to manually pair each device, that would be insane if I had 100 devices. Note that these devices don't necessarily have to be connected at the same time, but could. Also note that I understand this isn't generally the main use case of the typical peripheral to mobile use case.

luckyging3r
  • 3,047
  • 3
  • 18
  • 37
  • 3
    In addition to Emil's answer, see this post:- https://stackoverflow.com/questions/42862560/should-one-create-a-bond-with-a-bluetooth-le-device – StRiDeR Mar 19 '19 at 09:16

1 Answers1

5

Here are a few differences:

If you bond the devices, the link will become encrypted, so it becomes more secure. So "paired" communication basically means the link is encrypted plus the device "knows" what it talks to.

The remote device also learns your phone's IRK (identity resolving key), which can be used to identify the phone later on. By default, the phone rotates the Bluetooth Device Address every 15 minutes or so. Without knowing the IRK, the peripheral can't identify the phone.

A good thing if the devices are bonded, is that the GATT db of the remote device gets cached, which means upon next connection, you don't have to wait a long time for service discovery to complete.

On Android, connecting by Bluetooth Device Address without first scanning is broken since the API lacks the "address type" bit (public/random address). If Android "guesses" wrong, you will connect to the wrong device and therefore fail. However if devices are bonded, the address type is stored and looked up based upon Bluetooth Device Address, which makes it work as expected. So if you plan to automatically connect to your peripherals in the background upon boot for example, it's a good idea to bond the devices.

A small detail is that Client Characteristic Configuration Descriptor values should also be stored by the GATT server and restored once the bonded device reconnects so it doesn't have to rewrite the descriptor value.

Some Bluetooth profiles needs bonding, for example HID (at least on iOS and Android).

Emil
  • 16,784
  • 2
  • 41
  • 52
  • So the only way for the peripheral to communicate with the Android unpaired would be if the Android via some app were to explicitly communicate to that specific device? It could only do so if it were periodically scanning for devices then it seems or if it could store the mac address and connect later if it was in range maybe. Where as paired, the android phone itself would know who the previously paired device is and would be able to bond all without communicating through an app? – luckyging3r Mar 19 '19 at 01:21
  • You normally need an app to communicate with BLE devices. There are some exceptions, for example HID devices, which you can bond and connect to from the Bluetooth settings. – Emil Mar 21 '19 at 17:45
  • HOGP (HID over GATT profile) specifications requires bonding. Specifications (HOGP 1.0, 6.1) says: *"HID Devices shall bond and use LE Security Mode 1, Security Level 2 or 3, both of which require an encrypted link."* – ouah Mar 24 '19 at 17:06
  • @ouah is it possible to add security to "Just works" connections? I've been doing a lot of research trying to figure out a solution. "Just works" seems to be the method I need to use however there is no/little encryption support it seems. Would I have to provide the support in the application layer above the actual ble communication or is there something that I have missed that could provide this support natively with ble? – luckyging3r Mar 28 '19 at 17:24
  • What do you mean with "add security to Just Works"? After pairing has been done with Just Works, the link automatically gets encrypted. – Emil Mar 28 '19 at 22:09
  • @Emil Sorry, I was under the impression that Just Works was a legacy method of pairing and that the security for it is poor/not recommended. Do you know of any documentation as to the encryption it is utilizing? – luckyging3r Apr 01 '19 at 22:09
  • Double sorry, at the time of writing my previous (Mar 28) comment I thought that Just Works was an unpaired method of communication but I have come to understand this is incorrect and is in fact paired – luckyging3r Apr 01 '19 at 22:18