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.
Related
We've got a use case in which a BLE connection is used to do the basic configuration of an embedded device via an Android app (later also via an iPhone app). The embedded device runs Linux and thus uses BlueZ as Bluetooth stack.
Using the DBus-API of BlueZ, bonding is made possible by making the device pairable, discoverable, and activating advertising. After bonding the apps can access the GATT services and characteristics
(which require bonding to be read/written) on the embedded device.
After the setup is done the bonding of the device (running the app) that managed the setup process, is supposed to be removed. In order to do that we call RemoveDevice() of org.bluez.Adapter1.
The BlueZ documentation states the following
void RemoveDevice(object device)
This removes the remote device object at the given
path. It will remove also the pairing information.
Still the app is able to access the GATT characteristics afterwards.
If bluetoothctl is used to check the list of paired devices, the list is not containing that device anymore though. Before calling RemoveDevice() the bonded device was visible there.
If bluetootd is stopped and restarted the app is no longer able to read/write the GATT characteristics, but needs to re-bonded before doing so.
I can neither find any further information in the BlueZ documentation nor can I find anything about this topic searching anywhere else.
Is this intended behavior or is this a bug? Does "remove pairing information" also mean "remove bonding information"? If this is intended behavior, how do we properly terminate bonding with a device?
Should I use the BlueZ Management API instead of the BlueZ API? I'm not sure about this as multiple source state that the DBus-API is the way to go.
RemoveDevice() indeed removes the bonding information as well. So you have to disconnect first and then call RemoveDevice(). The next time you connect the bonding information will be gone.
However, note that if you only make use of encrypted characteristics, you can still connect and discover services. Only once you start reading/writing the encrypted characteristics will Bluez check if you are bonded.
I use esp-idf v3.0 and esp32 chip.
My esp32 is a gatt server and I communicate with a specific android app which is the gatt client.
In our system, there is a need for me to save some info for previous remote devices which were disconnected for future connection. For this reason I need some ID of the remote device, and for that I used the android bd address, but after experiments and some info from google, I understood that the bd address from android is unstable since it doesn't show the actual physical address.
Thus, I want to use the name of the android device as an ID (of course we will make sure to set our android machines to have a unique name).
But I can't find in the docs any option for reading the remote device name.
I would like to know if there is any function or example code for reading the connected devices name.
The common solution is to pair the devices. When you do that, you get the IRK (identity resolving key) which can be used to see if a given Bluetooth device address is derived using that particular IRK.
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!
I'm working with BlueZ 3.x. I have a linux embedded device and I need to send and receive files using the bluetooth technology, with Obex. (Note: BlueZ 4.x doesn't even compile on our specific platform.)
I don't need PIN authentication, I even don't want it. It must remain as simple as possible for the end user.
I tried to set security none in hcid.conf but it doesn't seem to work.
So my question is:
Is it possible to send &/ receive files using Obex on bluetooth?
How to do it?
Does bluetooth devices (e.g. mobile phone) requires authentication?
You can use the OBEX protocoll for that, but you will also need the FTP or OPP profile (And GOEP, SPP & GAP since they depend on them)
The documentation can be found on BT SIG bluetooth.org, but you will have to be a member. I think some of the documentation is available to non members as well, go there and have a look.
Yes (if we are only talking about mobile phones)
I need to connect to a Bluetooth device through virtual COM port created in Windows. It's easy when the port has been already created during manual pairing procedure. But I would like my application to relieve an user from the manual pairing of a device. I would like to present all devices in the range, allow user to chose one, and then create virtual COM port connected with the selected device. I'm not trying to avoid the pairing procedure itself, but rather I would like to invoke it by my application.
I started getting familiar with Microsoft Bluetooth API. And then some doubts arose. I've been wondering what happen if some user would use different (than Microsoft's) Bluetooth stack? Is the Microsoft's API the real Bluetooth API, which have to be implemented by any other Bluetooth stack provider? Or rather each provider has its own API, and the Microsoft's is only one of many other?
Thanks everyone for valuable input. I'd like to summarize what I've found so far. The Microsoft Bluetooth API is not operating system API. Application written against it will not cooperate correctly with any other Bluetooth stack. It seems that applications which are intended to cooperate with multiple stacks need to provide some stack abstraction layer, and stack specific code for all of them.The other solution is to allow user for manual pairing of the Bluetooth device, which eventually create some virtual device in the operating system (e.g., COM port). Then the application can use standard interface of such a device.
I can't speak for the Microsoft Bluetooth API, but there are multiple Bluetooth stacks available for the PC platform (even more for mobile devices).
The underlying API is defined by the Bluetooth Core Spec and so all stacks should be able to interact, in fact it is mandatory that they interop or they cannot use the Bluetooth name and logo.
As to pairing, your going to have a hard time getting devices to pair if they have default security, which requires a pin code.
Things might be simpler in the (near) future, as the Bluetooth standard has introduced a new security model, secure simple pairing, which has a 'just works' mode that requires no Pin code. This is still stronger then the current security, except against Man in the middle attacks. However, it could be a while before you see the chips with this feature in PCs.
If you can change to using .NET :-/ I can recommend our library 32feet.NET.
For explicit pairing there's BluetoothSecurity.PairDevice. We can also create the virtual port for you, for example:
BluetoothClient cli = new BluetoothClient();
BluetoothDeviceInfo[] list = cli.DiscoverDevices();
BluetoothDeviceInfo selected = GetUserToSelectOne(list);
BluetoothSecurity.PairDevice(selected, pin);
// Ask Win32 to create a virtual serial port
selected.SetServiceState(BluetoothService.SerialPort);
However I really don't like virtual serial ports so I always suggest that people use a normal sockets connection using our BluetoothClient class, it will automatically handle a pairing request if required.
On Win32 we support the stacks from Microsoft, Widcomm/Broadcom, and BlueSoleil. On Widcomm there's no support for SetServiceState there yet, and their API has no support for responding to pairing requests. BlueSoleil should support both.
A brief user's guide is at 32feet.NET — User’s Guide, and all the class documentation is available at the main site http://32feet.net, the Widcomm documentation is only in our code repository at the moment.