I am using Bluez 5.50 stack on a Linux device which does not have a display. I want to pair my device with a Mobile device (Android or IOS) with secure pairing which requires a passkey to connect.
Every time I am trying to pair, an auto generated passkey is being generated. I want to set a default passkey which should be used during the pairing instead of auto-generated passkey.
How to resolve this issue?
The Bluetooth standard says that the passkey should be randomly generated and that a static key should not be used. There is a good reason for that: the ad-hoc protocol used in Bluetooth is insecure if the passkey is reused. If you don't have any input or output mechanism, you shall use "Just Works" pairing, which unfortunately does not give you any MITM protection. The security of this is technically more or less the same as when using a static passkey but without giving a false sense of security.
See https://stackoverflow.com/a/70479911/556495 for an answer to a similar question.
Related
I have a Bluetooth device, which pairs with an Android smartphone. This creates a link key that I want to change later on. Does the Bluetooth protocol support a method of regenerating it?
Link Key gets regenerated,if you delete and pair again. Bluetooth Specification does describe APIs to change link keys in Host Controller Interface Layer. But, it is up to the operating system/ third party stack to expose it, because of security issues.
Some Bluetooth stack, may provide an option to regenerate link keys[automatically] after every bluetooth session.
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 implemented the org.bluez.Agent1 interface using QDbus and I would like to set a fixed pin (that I will provide to the users) in order to authenticate all the pairing request and reject them if the pin is wrong. The agent capabilities should be "NoInputNoOutput" because the project will be deployed on the RaspberryPi 3 without keyboard or display. Is there a way to deal with this? Thank you
You should not initialize the capability as "NoInputOutput" for fixed key pairing. NoInputOutput means there is not display and there is no keyboard/UI possible for this device. Mentioning this capability for your Agent when registering with BlueZ means, instructing BlueZ (bluetoothd) not to call any Agent API for authentication.
This is typically useful to autopair without any manual intervention. You can see this sample code, which uses NoInputOutput capability to connect the device without any intervention.
What you need is "DisplayOnly" capability to instruct BlueZ to call "DisplayPinCode" or "DisplayPasskey" based on SSP support of your device.
You can implement DisplayPinCode/DisplayPasskey in your Agent to reply constant PIN always. So the Bluetooth device which tries to connect can use the same constant PIN for pairing.
Here Display Pin /Passkey is just the naming convention or hint to Agent developers to write wizard/UI or any form of display operations. But you can completely ignore the displaying operation and reply with static/constant 6 digit key for pairing.
Typically this Agent API is called by Bluez (in rasperry pi) when the device (iPhone/Android mobile/any bluetooth capable device) trying pair calls "RequestPasskey" or "RequestPinCode" from the device end.
We had the same issue in a project, and i moved on LE device do to the fact that apple device are only capable to connect to LE device for "safety" reasons.
I don't have that much ref to that but if this could help you in your researches.
I'm trying to make a BLE device that actually pairs securely. As far as I know the transport encryption (using AES) is secure in all versions of BLE, once the 'Long Term Key' has been exchanged.
BLE 4.1
BLE 4.1 and earlier use symmetric cryptography and the passkey (PIN) is only 6 digits so it is trivial to passively eavesdrop on the pairing, brute-force the passkey and derive the LTK from that. It seems that this was insecure by design because it was thought that low power BLE devices wouldn't have enough oomph to do asymmetric cryptography.
BLE 4.2
BLE 4.2 adds 'Secure Connections'. This is apparently also broken and what's more it was broken in 2008 when the same pairing method was used in Bluetooth 2.1!! It doesn't totally break pairing - only the passkey entry method - and you only learn the passkey, not the LTK. But it does allow an attacker to perform a MitM attack if the passkey isn't changed for every pairing attempt.
Out-of-Band pairing
The Out-of-Band pairing method would be an excellent choice, then I can use a QR code or something. However there are no public APIs to access the OOB method on either Android or iOS. Android supports OOB pairing via NFC but iOS doesn't, so that's out.
It seems the only option left is to implement a custom encryption scheme, but that is a ridiculous amount of work.
My questions are:
Why did the Bluetooth SIG specify a pairing method in BLE 4.2 that was already known to be insecure 6 years earlier?
Are there any existing encryption schemes for BLE that secure it? Ideally open source and well-tested, but could be commercial. Would I still be able to use GATT?
I am using a SPP Bluetooth module to send data between my Android phone app and the module. I stumbled upon an interesting thing today.
I pair to my module by entering a passkey
I can normally send data back and forth between my app and the module
From within my app I disconnect from the module and close my app.
On the module I change its passkey to a new value.
I reopen my app and can still exchange data. I do not need to go through pairing again. All security information exchanged by my phone and module when I first paired them (using the old passkey) seem to still be valid even after changing the PIN on the module.
I then close my app and unpair the device from Bluetooth settings.
After that I pair the two devices to make sure Passkey change was in fact accepted and surely enough it was. I can now only pair with the new PIN.
My surprise is that in point 5 above everything still worked even without updating the PIN also on my mobile phone. I plan on getting around this by calling removeBond() using reflection after I send the module a command to change PIN since this is enough for my particular use case. But if the PIN change could be triggered by something else then my phone this would not work.
My question is if this is normal. Bluetooth specs are quite long so I was hoping someone else knows this. I would imagine that after changing the passkey for a Bluetooth device all devices already paired with it will have to go through the pairing process again, this time with the new passkey. But steps above indicate this is not the case. Is this a bug on my Bluetooth module (Bluegiga WT12) or is this expected behaviour? Has Anyone encountered this before?
Thank you.
Cheers!
So, Bluetooth specs are more friendly than I thought. I found my answer in this paragraph:
The Bluetooth PIN is used to authenticate two Bluetooth devices (that have not
previously exchanged link keys) to each other and create a trusted relationship
between them. The PIN is used in the pairing procedure (see Section 11.2 on
page 241) to generate the initial link key that is used for further authentication.
So passkey is not like a password in a router. It is just a sequence which both devices need to know when connecting so that one authenticates the other. Once they are sure they can trust each other they exchange link keys and those are used for future communication. Passkeys/PINs are then irrelevant.
I hope I understand this right.
Terribly sorry for posting too soon.
Cheers!