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/
Related
I'm working on a BLE device and trying to understand pairing. Say a device has yet to be paired for the first time, can it be set to pairing mode indefinitely? By this I mean, can the device stay in pairing mode as long as it needs to (1 day, 1 week, 1 month, etc.)
Assume the following:
1.Battery power is unlimited
2.The device can only pair to a specified target
Yes, the BLE standard doesn't even mention "pairing mode". A device decides in every specific situation when receiving a pairing request or security request how and if it should continue.
It also decides itself when and if it should advertise to make itself connectable, or scan to find other devices to connect to.
I know that bluetooth uses hoping, and because of this difficult to intercept traffic.
Сan i put my dong into monitoring mode?
If for example are 30 devices nearby, and i will always listen just one bluetooth channel, and my dongle works in monitor mode, should i get sometimes some data?
Can i use for these purposes Hcidump or tcpdump?
If I understand correctly, if bluetooth device does not have a password, i can directly interact with its services(with hcitool and tmux).?
I read that i can watch the battery level, device name, and other information.
PS: sorry for bad english.
It is possible to monitor traffic between Bluetooth devices but I am quite sure that your default laptop dongle is not capable of doing that.
Before establishing connection between two Bluetooth devices, they send connection request/response packets on primary advertising channels (37th, 38th, 39th channel). You need to capture these packets to learn hopping pattern, connection interval and etc. After receiving packets, you can monitor insecure Bluetooth connections. However it is hard to monitor 30 device simultaneously because you need to make time division between each connection.
Let's answer your questions.
It might be possible but you need to write driver level code.
It might be possible. As I mentioned, it is good approach to capture connection request/response packets before monitoring devices.
I have no idea about these tools.
To manipulate services, you need to know service handle and duplicate GATT client's mac address. I am not sure that, this method will work.
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).
I am looking for a way to scan a device I own and discover "what it can do".
In other words, I'd like to know if a device is able to describe the way you have to communicate with it in order to build some application around it.
In my case it is a simple Christmas light that I'd like to play with but this could be used in different situations.
For classic bluetooth (BR/EDR):
When scanning for bluetooth devices (Inquiry), the bluetooth device will send an inquiry response (if it wants to be discovered) and maybe also an extended inquiry response (EIR). This EIR may already contain a list of services, the devices supports. This is a very fast way to get a picture of a remote device.
Moreover, the service discovery protocol (SDP) gives more information on a device. This takes some more steps. In SDP two devices can exchange their capabilites in kind of ping pong process.
For BLE:
After connecting a BLE device usually a service discovery takes place. The BLE peripheral (e.g. headset or a light) reports its capabilities to the central (e.g. smart phone). Some of these services have predefines functionalities. Additionally, it is free to the manufacturer to add custom services.
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.