I would like to be able to pre-pair bluetooth devices, to save the step of user confusion when using the app. I have discovered that there is a patent for
System, method and apparatus for pre-pairing bluetooth enabled devices.
I am looking at pairing an array of android devices with an array of embedded devices, so when the android device is set up, I can pre-pair it with the devices it needs to communicate with. I have considered maintaining a list of MAC-addresses that can be downloaded and updated by the app.
Is there a way to pair two devices without having to bring them into contact?
My memory is not exact, it's a while ago I poked around in the Bluetooth stack, however, I don't think this is possible.
Basically there is a white list (text file pretty much) which is kept by the system with devices that may connect to your phone, in order to access that white list outside of the Bluetooth api you need to be platform manufacturer. The Bluetooth Api is strongly guarded (by the specification), if you don't fulfill it you can't say your device supports Bluetooth. Pairing is an important part of the Bluetooth security model, I doubt even an oem would be allowed to do this.
One thing you could look into are Bluetooth low energy devices, those don't require pairing prior to connection (you should be able to connect if you have the MAC address), only Bluetooth classic requires pairing.
More info:
https://developer.android.com/guide/topics/connectivity/bluetooth-le.html
No its not possible unless you make changes to the ROM.
If the use-case supports,you can have ble devices advertising data in a pre-defined format so that the app detect your devices.Once you have recognized your devices,you can internally send a pairing request.
Related
I'm trying to implement a Bluetooth (BLE) gateway into a project to transfer data between hardware and a mobile device with an application. The hardware is not unique, it could be mass produced with the controller having the same program flashed into it.
If 100 of the hardware product is made, powered up sitting side by side, what is the best way to set up the information that the BLE broadcasts to advertise so that it can be received by a mobile device, and only 1 hardware and mobile device can be connected at any time.
For example, if you have 3 of the same fitness tracking watches side by side, and you only want to connect to 1 of them, how do you distinguish which is which on say the phones bluetooth pairing menu.
Does each of the manufactured hardware need to have a unique ID that shows on the mobile device (eg ABC11, ABC112, ABC113 etc), and how do you program 100 unique programs into the hardware quickly.
On the other hand, should each of the hardware have the same ID broadcast, and then the user just hopes for the best if the correct hardware is paired.
(BTW, the hardware is an arduino based microcontroller using a BM70 BLE module. neither of which are intended to be modified by the user)
Assistance appreciated.
Thanks. Nunya
You do not have to manually program a different MAC addresses for each device, the BM70 module is the one that provides the BLE MAC address and they are supposed to have unique ones. Sometimes manufacturer recycle (reuse) the addresses, but I think the chance to hit a MAC twice with 100 devies is pretty low.
If your devices are all the same and use the same program they all offer and advertise the same BLE service. The service and containing characteristics are the feature that distinguishes your devices from other BLE devices. A true BLE device that does not also use Bluetooth Classic will not show up in your phones bluetooth settings or pairing menu. BLE requires a dedicated app where you scan for BLE devices and idealy filter for the special service you are using to only find your own devices.
To distinguish between 100 devices placed next to each other (if this even matters since they are all the same) you need to either read the MAC address and prit it on a label for each device or use some status LEDs to show the connection status on your arduino. If you connect to one device the LEDs could start blinking to show which device you are connected to.
I have been doing a ton of research on this project I want to do, probably read every SO post (bluejacking, RFCOMM, beacons, etc...) and my head is spinning.
I want to create a system at home, using Arduino (with bluetooth le) that will scan bluetooth and detect when my phone or any of my family members phones are in proximity. Whether this is a MAC scanner or simply getting the friendly name. I would also like to get the RSSI. I dont need to do accurate distance measurement but I would like to know approximately how close they are. Does anybody have any suggestions for this approach? I know I can create an app on the phone and have it become a beacon and this may be an option but I am concerned with Android, it would have to be Marshmallow 5.0 at a minimum. I would like support to be a little lower than that, like JB or KK. So, it seems like there should be a simple scan, just looking for the MAC or name. That is all I really need.
That said, the main question I have is, can you scan for and see bluetooth devices in range if they are already paired to something? Like a Bluetooth headset? I understand bluetooth is point to point but does it allow multiple connections or at least broadcast the mac or name when paired?
This question, along with any general suggestions will help me out tremendously!
Thanks!
Bluetooth Discovery from the Listener involves Listening for Bluetooth Inquiry packets(RX) and inquiry response (TX).if done continuously this will deplete the battery. Hence most devices (including Mobile Phones and Headsets) has a policy of when to be discover-able and connectable. Headsets in particular are discoverable only when they are instructed and connectable until one device is connected to it ( There are probably exceptions where the headset has the capability to be connected to multiple phones at the same time). Most Mobile Phones are discoverable only when they are in settings screen ( Android,IOS and Windows Phones), but unlike the headset case they are connectable.
so one option with the MobilePhone is to see if it is possible to connect to them after pairing once ( for example by trying a service search on the remote device and see if it returns the service attributes, this internally makes a connection and indirectly ensures the presence of the device).
if you are specific about a mobile phone which is already paired then you might need to establish a higherlayer connection ( such as SPP) with Authentication and encryption. This would force a two way check between devices to see whether they are already paired. other less secure option is to rely on the Phone (Android and IOS phones doesn't generally Allow a higher layer connection without encryption/pairing) and try to establish an SPP connection to the phone.
Another option is to use Bluetooth-LowEnergy. But Note that security in BT was superior to BLE till BTv4.1 and same on BTv4.2.
I have made an app on iOS and Android that can connect to a BLE device. I connect to the "device by service" and things work well.
A customer is asking me why the device is not showing in the list of bonded bluetooth devices. I didn't need pairing to connect because I found code that didn't require it, but now that I think, I wonder :
What would be the benefits to have a paired device ?
Would it connect faster ? Hold connection better ? ...
Security, mainly.
Sending data to a non-paired device requires that the device be discoverable and open to receiving data from random devices. This isn't always the case for reasons of security, and so many devices ship with both disabled.
The attack vector is something like this: you'll always have to pick a device in the list of discovered devices. It's not too difficult to create a device with "<CEO>'s iPhone" as the name and wait until he tries to send the secret memorandum to his iPhone, then intercept it.
Additionally, bluetooth stacks have been known to have vulnerabilities that can be exploited by sending data to the device, which was made more problematic by devices auto-accepting data without confirmation.
Paired devices create a pre-existing relationship between the two, allowing your user to be notified when something out of the ordinary happens. This is always a good thing.
It is indeed also true that not having to go through device discovery (which may take up to a few seconds) improves performance when doing the initial connection setup, but I wouldn't see that as the major reason.
I'm a little bit confused with BLE. I read that the BLE pairing process has three options and the one I'm interested in is the Passkey Entry.
My goal is to have a sensor on the field and the Android App will scan and find this sensor then it will request to pair with the sensor before they can exchange data. The user app is either running on a cell phone or tablet.
Is the BLE pairing the same as Bluetooth Classic? I mean is the Android API BluetoothDevice.setPin used for both BLE and Classic and the driver will do the rest under the hood?
I'm confused because I read somewhere that for BLE I can set a PIN or a Passphrase but BT Classic only accepts a 4 digit PIN.
Pairing in BLE is just a way of setting up an encrypted link. The devices need to agree on an encryption key and they do this either by just works (which set the key to all zeroes), passkey entry (up to six digits) or out of band (keys distributed over NFC or some other channel).
If you use passkey that means a "snooper" cannot pair with your sensor unless he can see the pass key on the device. (Either printed or on a display)
You can also combine a pairing with bonding where the devices distribute keys after encrypting the link making it possible to reconnect with the same device without having to renter a key.
You then want to set up your database on the sensor to only allow reading the sensor data over an encrypted link. (You don't want your snooper to simple connect to the device and read out the data himself).
The one problem with this approach is that the pass key entry only uses 6 digits. That is not enough entropy to really protect you against someone eavesdropping. The key generated after a passkey entry can be brute forced in milliseconds and all the commercial Bluetooth sniffers does this as part of their normal operation. They do however have to sniff the pairing procedure to do this, so if nobody was eavesdropping when the devices was bonded your usually good.
Also using out of band data is safe, since you cannot easily brute force a random 128 bit AES key.
A PIN type of passkey is not used in BTLE as far as I understand the specification. Legacy Bluetooth devices used a fixed PIN passkey that was hardcoded into the device or entered by the application. This method of pairing was replaced by SSP (Secure Simple Pairing) in the next round of Bluetooth. BTLE came later and uses only SSP. The passkeys in SSP (when man-in-the-middle protection is enabled) are generated randomly by the Bluetooth software usually at pretty low levels. One SSP option is 'just works' and the entire passkey generation is internal. Great for the user but it is possible for Man-In-The-Middle (MITM) attacks. So in the end, for your Bluetooth LE application you will never use the 4-digit PIN.
So pairing with BTLE devices on the Android can be done in exactly the same way as one pairs standard Bluetooth devices. If the BTLE device is using an SSP option beyond 'just works', you will get a popup menu asking for you to either
verify a number displayed on the device and/or provide a number
that you must verify on the device (yes-no and display-only combos)
require that you enter a number that it displayed on the device
and/or display a number that you must enter on the device (keyboard)
The built-in pairing feature works for both BTLE and BT devices in spite of the fact under the hood the mechanisms are very different. BTLE devices transmit advertisements that client devices scan for (BTLE 'discovery') whereas BT devices scan for transmissions from the client (BT discovery) when it is looking for devices.
Alternatively one can use the BluetoothAdapter.startLeScan(LeScanCallback callback) method to scan for BTLE-only devices. This method will give you a list of BTLE devices that one can then select and attempt to connect to. In this scenario, your application will need to take care of pairing when it is required. Usually pairing is not required on BTLE devices until one attempts to enable notifications or indications. Service discovery, reading the Device Information Service and other tidbits often do not require pairing and if memory serves me right one can never require pairing for service discovery.
So to make life easier for my application I link to the standard Android provided tool for the discovery/pairing of any device that requires pairing and for those BTLE devices that do not require pairing (and there are a number of such devices) I use the startLeScan() APIs and do a BluetoothDevice.connectGatt() to one of the 'discovered' devices. If I use this approach and the device actually requires pairing I will get a security error. In theory I should be able to use the pairing APIs provided by Android to then pair with the device. Unfortunately my inept programming skills have led to the fact that I have yet to succeed in implementing it correctly.
I have the bluetooth mac-id of the target device. The bluetooth however is in hidden/not visible mode.
Both phones are android. (Non-root).
I did my research and I * know * that I can CONNECT to a device (in most cases) if I know the mac-id, however I want to just scan for proximity and NOT connect i.e. if the target device is in bluetooth range and I know its mac-id, can I * just * know if its in proximity (or in loose terms, scan for it?)
The short answer is no, you cannot discover undiscoverable Bluetooth devices.
Having a device in undiscoverable mode is a security measure implemented by manufacturers to prevent abuses such as device tracking. This make a standard bluetooth adapter (such as yours) completely unable to state whether an invisible/undiscoverable device is close or not.
However, it turns out this kind of security is not optimum and has been broken recently. You can find here Michael Ossmann's work on Ubertooth, a small Bluetooth adapter able to detect undiscoverable devices. You can find here a great presentation of what this is, build this dongle using open source plans and even buy his dongle.
EDIT :
It is possible to know whether a bluetooth device is around, even if he is in an undiscoverable mode, by knowing his full MAC address in the first place.
The technique is to try a PAGE request, sending all the 6 bytes that are composing the seeked Bluetooth host MAC identifier. A PAGE request allows one to connect with a Bluetooth slave when knowing his BT ADDR. Devices that are in undiscoverable mode does not respond to inquiry scan (device discovery intent), but they do respond to page scan which is used by a device wanting to connect to an another previously known device.
You might be able to do what you intend by using Bluesniff, a security proof of concept allowing you to discover hidden devices. It might support page scanning.
Note that this is to be taken as an educational resource, and I do not encourage this kind of practice in a commercial application.