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.
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).
Related
From the Bluetooth client example at http://people.csail.mit.edu/albert/bluez-intro/x502.html, it seems I can simply connect to a remote Bluetooth socket as long as I have the Bluetooth MAC address of the device.
If I can simply connect to a remote Bluetooth device, I am wondering what exactly does Bluetooth pairing do. When is pairing really needed?
Update:
From How does Bluetooth pairing work?, it appears the final result of pairing is that an encryption key gets stored on both sides. I assume, when you open a remote socket connection, the call is intercepted by the local bluetooth daemon. In turn, the daemon encrypts the data and sends to the remote device. The daemon on the remote device decrypts the data and sends to the remote client application:
Device1Client-->Device1Daemon-->Device2Daemon-->Device2Client
Is this assumption correct?
Yes, your assumption is partially correct. Encryption is one of the uses of Passkey.
Bluetooth pairing is necessary whenever two Bluetooth devices connect to each other to share resources. A trusted relationship is established between the devices using a numerical password, commonly referred to as a passkey. Depending on how often one Bluetooth device connects to another, the user might opt to have the passkey saved for future connection attempts or prompt to enter the passkey each time the devices request communication with each other.
This is already explained on Stack Overflow please check- How does Bluetooth pairing work?
In the below answer, I will try to explain what is not mentioned in the above link or answers.
In Pairing process, when the initiating device sends a ‘Pairing Request” to the other device. The two devices then exchange I/O capabilities, authentication requirements, maximum link key size, and bonding requirements. Basically, all this phase consists of, is the two devices exchanging their capabilities and determining how they are going to go about setting up a secure connection. It is also important to note that all data being exchanged during this phase is unencrypted.
Now the question is why this Phase is needed?
As mentioned- “two devices exchanging their capabilities.” The pairing should happen between compatible device there is no point in Pairing you Mouse with a Headphone as Mouse capabilities are different than Headphone.
One more use of Pairing is – “determining how they are going to go about setting up a secure connection.” Here the frequency hopping pattern is determined for two reasons-
To avoid Middle Man Attack.
To avoid Collision
Bluetooth uses 79 radio frequency channels in the band starting at 2402 MHz and continuing every 1 MHz. It is these frequency channels that Bluetooth technology is "hopping" over. The signal switches carrier channels rapidly, at a rate of 1600 hops per second, over a determined pattern of channels. The hopping pattern is determined well during the pairing process so that no other device will know in which band of the frequency the data is being transferred at an instance. Its rare case that frequency hopping pattern can be the same for a couple of devices communicating hence collision is avoided.
Note: If any third device is able to capture the passkey then it can replicate the whole communication pattern and capture the data being transferred. This is how the BT Sniffers work.
I am not able to cover all the details as per SIG specs. I hope the above answers give you a clearer picture of the need for the Pairing process. Feel free to point out, if you want me to explain any specific point in detail.
Below are the reference Links for more information-
http://large.stanford.edu/courses/2012/ph250/roth1/
https://www.bluetooth.com/blog/bluetooth-pairing-part-1-pairing-feature-exchange/
I’m creating an IOT device with some unusual needs when compared with typical home automation. I wanted to ask if anyone knew of a mesh protocol (Zigbee, Thread, BLE Mesh), that might be able to achieve this user experience:
When someone turns on their device, it looks to connect to a mesh network, comprised of other devices they have previously “friended”.
If no network is found, it creates its own mesh network, available for other “friended” devices to connect to, when those devices turn on.
If the device creates its own mesh network (as in behaviour above), but no one connects to it – and then the device finds a different network with more than one friend on it, the device should kill its own network in favour of connecting to the other.
I’m expecting that there will not be a “master” node who has “friended” every possible device that wants to join the network – I’d like the possibility for “friends” to bring their “friends”, to also join the network.
If a partition in the network occurs (this is very likely to occur in my use case), the network should automatically re-form when the devices are close to each other again.
All devices are expected to be identical in function, size, software – so BLE Mesh is probably not suitable given it needs a “Provisioner”?
Messages transferred will be bespoke to this application – ruling out Zigbee’s Application Layer?
Messages will be small in size, so data transfer speed is not a big concern.
I believe from what I’ve read that Thread is probably the most suitable for this use case – but wanted some other opinions to see what the best choice might be?
Seems to be a bit of a mine field to fully understand the ins and outs of all of these mesh protocols!
I believe Thread/OpenThread addresses all of the use case items you listed above.
When I study Bluetooth, I am confused to understand Bluetooth connection and pairing, bonding, etc.
As far as I know, Bluetooth Connection has these steps:
Inquiry - discover
Paging - using the address in Inquiry process, process of forming a connection
Connection - device can participate actively(Active mode) or put into other mode(Sniff, Hold...)
When we use Bluetooth devices(e.g. Smartphone, Bluetooth Heaset)
it has these steps:
Discovery devices
Pairing(exchange other security information like address, PIN Code)
Connection start
I can't match paging to pairing. Is my understanding right below?
Inquiry = Discover Devices
Paging = Pairing
Connection = Connection start
How can I merge above two categories?
Not answered in 7-months! Oh, well for posterity...
Inquiry and Paging - Link Layer Connection
(Is there anyone out there? Hello!)
Inquiry and Paging are procedures and states of the Bluetooth Link Controller during the connection process.
The standard progression of states to a connection are as follows:
One device performs the Inquiry procedure, a request message for devices within 10-meters to respond, if they are in range. This device is the Master.
Devices that are discoverable, will respond with an Inquiry Response. Example: If you turn on the Bluetooth on your phone, it often states it is discoverable and then it will list a number of devices around you.
The Master device then will initiate a connection by paging a specific Slave device.
If the Slave device is amenable, it will respond with a Page response. Example: On your phone, you select the Bluetooth Headphones to connect with.
At that point lots of cool stuff happens so that the radios can match frequency hopping patterns and timing of radio packets. When it's over, and successful, you have a Link Layer connection.
Typically, there are two types of connection:
Asynchronous Connection-Less (ACL) - Packet data
Synchronous Connection Orientated (SCO) - Audio (or video) data, real-time.
Pairing
(security and remembering past lovers)
Bluetooth doesn't need any Security to do Service Discovery (the next stage) but all Bluetooth services need security, so pairing is nearly always done BEFORE Service Discovery BUT it doesn't have to be.
In the lowest level of pairing security, it 'just works'. Your phone says, it's connected and that's it. The link is encrypted but did you really connect to your headphones or your sister's down the hall?.
Once connected and encrypted like this, the phone may ask you if you want to stay paired with the headphones. If you select 'yes' or tick the box, your phone will remember the encryption and security keys for your headphones (as will your headphones for your phone). The next time they connect, they will recognise each other and just connect and encrypt the link without having to go through pairing again.
Now if your connecting your phone to your car by Bluetooth, you probably want better security. There are various options but typically it goes like this.
When it comes to pairing, your car system will display something like 'Pairing code 4753495' and your phone will display something similar like 'Verify pairing code 4753495 - Yes/No' - If they match, then you have a really secure connection and you absolutely know that your phone is paired with your car and not you're sister's rubbish Toyota out on the drive.
Bluetooth these days is really secure, the latest specs support US Secret Service levels of encryption and for that reason some Bluetooth firmware and devices have strict export restrictions. Older, legacy devices will still use 4-digit pin codes and are less secure.
Service Discovery
(What can you do?)
The Master will ask the Slave to tell it a little about itself and the Slave tells the Master all the cool things it can do. The Master will reciprocate too.
With our Headphones and mobile phone example, once you pressed on the Headphones in the list of devices, it will connect, pair and you will get a pop-up saying it supports things like 'Phone Media' (Handsfree / Headset Profiles) and 'Music Media' (Advance Audio Distribution Profile, Audio/Video Remote Control Profile, and some protocols under that).
Your car, in addition to Phone and Music Media, can probably do things like browse your Phone's contacts or even display text messages.
Profile/Service Connection
(Finally)
After all that, you're set up. Typically a profile/service level connection doesn't happen until you try and use it .e.g play music or make/receive a phone call but the Link Layer connection is there underneath.
So, you can start playing music on your phone and the sweet beats will magically come out of your headphones or car stereo...
Until your sister calls.
I'm not sure how to correctly phrase this question, as I'm just starting to learn Bluetooth and its ways, but... imagine holding in an iPhone or Android phone in your hand in a large building with many rooms. You pair your device with a Bluetooth master device via an antenna in that room. Then once you move from room to room, your device communicates with other antennas throughout the building, but the device treats it as one pairing.
Is this at all possible? Was Bluetooth developed with this in mind at all?
Would this still work if the antennas were wireless? My idea is for devices to communicate with nodes via Bluetooth, and nodes interact with central base via wi-fi/local router.
Also, third random question: how does using BLE affect any of this?
Please tell me if I'm crazy! Thanks!
Bluetooth 4.0 BLE allows for a slave to connect to one master. 4.1 BLE allows for more than one connection, but I don't know if anything implements that yet.
Either way, there's no sort of "roaming" method pairing devices like with wifi access points with the same SSID. BLE however doesn't require pairing like regular Bluetooth, so you could just connect to a new access point each time you lose a connection.
You can also communicate via advertising packets from the "antenna" in each room. This would facilitate information being passed from those rooms to the phone, but not the other way around. This is basically how you communicate with BLE when you don't pair/connect devices and is how iBeacons work.
If you're writing the software yourself, and installing it in the building and on the phone, then I think it should be totally possible. Bluetooth devices can detect the distance and direction of other bluetooth devices. So if both devices are running software that is designed to, and grants permission to do so, it should be no-big-deal to programmatically auto-reconnect to the new nearest antenna whenever one becomes significantly closer than the one that your phone is currently connected to. As for software that already does this that you wouldn't have to develop from scratch yourself, no idea.
Does anyone know how a bluetooth device could pick up the discoverable devices' device IDs in range?
I am ideally looking for the simplest solution that involves the smallest implimentation of the bluetooth protocols.
A starting point would be good, I just wish to create a device that can store all the device ids of nearby bluetooth devices with minimal power consumption, preferably just using radio frequencies and not SDP and whatever else.
If you can't help me with this, please can you help me find good reading material for low level bluetooth (step by step) communication. The reading online is so high level that I cant work out what is actually sent, when.
Laalto nailed the answer from the Bluetooth spec/stack POV, but your question implies your looking for a stand-alone Bluetooth device - not just a laptop app scanning surrounding devices.
I can only speak for the BT chips that the company I work for manufactures (Cambridge Silicon Radio - CSR) but our chips can do that pretty much out of the box. Our chips have an on-board Virtual Machine sandbox that allows access to the firmware functions and Bluetooth stack of the chip. You can easily write a C code app to run in the virtual machine sandbox, on chip, that periodically scans for discoverable devices around, grab their ids and then download them when connected via USB or Serial, or maybe over BT when a device connects to the listener directly.
www.csr.com and www.csrsupport.com for chips, dev-kits, design references, etc.. etc...
You probably want a module with the extra HW (UARTs, USB etc...) as well as just the chip but you could implement this with something the size of a BlueTooth USB or probably smaller.
It would really help to know more about what your trying to achieve, why you want something that just scans the surrounding bluetooth devices and how big the device needs to be.
Sorry if this sounds like advertising. For balance: Broadcom make BT chips too!
The Bluetooth specs from http://www.bluetooth.org are a good starting place for low-level information. You need an account to access the specs, but you can create one for free.
Basically what you need to do is to go into Inquiry mode periodically and grab the response packets as they arrive. The more time you spend in Inquiry mode, the more likely you will discover devices in range: discoverable devices enter the Inquiry Scan mode only relatively rarely; it takes some time (10.24s at least with older Bluetooth versions) to scan all the possible frequencies in the Inquiry/Inquiry Scan frequency hopping schemes. And even then you can have suboptimal radio conditions.
For implementation I suggest you at least start with existing Bluetooth libraries such as BlueZ and do not attempt to create your own from scratch.