Hello,
The context: I'm currently working on a BLE device that is connected with Just Works connection type to its Master (android tablet).
Since :
Android devices with recent versions of Android do not use the public address when connecting. Rather, they use a random address. This is part of the BLE spec. For the purpose of privacy, in addition to the public device address there are random device addresses. New versions of Android uses a random address when connecting to peripherals. (source of that quote)
I understood that my Android tablet is using a random address. For that, i made a programme to verify this information and it actually works (fortunately).
So my BLE public addressed device can connect to the master by receiving its pairing ask.
The question: First of all, what exactly are BLE addresses (random, static, public(mac) it's a bit confusing from the docs) ?
The MAIN question: Can my master (android tablet) connect to my device when those two are private addressed ?
My specifications:
Using VisualStudio
Using VisualGDB and openOCD
BLE_lib.h and BlueNRG
Ask for more information
The answer: Public BLE address is given by Bluetooth SIG and is guaranteed to unique. Random BLE address does not have this property. In addition random address can be either static or public. Static address cannot be changed while the BT chip is on. Public is divided into resolvable and non-resolvable, both can change whenever and the basic difference is the amount of bytes that change.
The main answer: Yes but you will need a way to identify the device. You could broadcasting specific data (e.g. manufacturer data or a 128b service UUID) and have your tablet scan for it. Then you can connect to whatever address you find provided the device advertises correct data.
And recommendation: You can find a lot of stuff at Nordic semiconductor-related sites. Even if you do not use their stack, their tutorials and explanations are easy to understand and cover pretty much everything.
Edit: I could probably provide better answer if I knew what exactly you intend to do.
Related
According to the Bluetooth Specification, each Bluetooth (or more specifically BLE) device can have a public Bluetooth device address which corresponds to the IEEE-assigned MAC address (burned-in MAC address). A device manufacturer has to purchase a range of MAC addresses from IEEE and can then assign these MAC addresses to his devices. However, Bluetooth devices can also randomize their device address to tackle privacy issues. They can use either
a static random address,
a resolvable private random address, or
a non-resolvable private random address.
I am wondering whether it is actually necessary to purchase the Bluetooth device addresses from IEEE. In other words, what would be the benefit of doing so? Is it possible to simply not purchase public device addresses and instead just use random addresses in products in the market. Or would that lead to legal or licensing issues?
I appreciate your help very much!
It's definitely possible to use static random address instead of public address. I guess most people do that.
Theoretically the only down sides are that with a small probability two random addresses might be the same, and you can't benefit from having your device addresses in a certain range (which could sometimes be useful).
Technically, Bluetooth stacks that fail to expose a proper API for connecting to a BLE device using address without prior scanning/bond, can lack the address type bit (public/random) so that the connection attempt does to the wrong address. This issue is currently present on Android.
I have to write a BLE application on an embedded device and there are some features where I'm not sure if BLE supports that or whether I've to create some wrapper around everything or if it's maybe not possible at all. The gerenal descriptions of Bluetooth and BLE I found around the internet usually only cover the overall functionality but don't go in too much detail. If this post gets too complex I'll split it up into different smaller ones.
I use the STM32 BlueNRG-MS chip
1. Discoverability (resolved)
The user has to be able to disable the BLE function in case there are several devices in reach. I see that there are functions aci_gap_set_discoverable() or aci_gap_set_non_discoverable() but altough I set it to not discoverable I can still see it in the LightBlue App on my mobile. How would I correctly disable the BLE functionality of a device to make sure no one can see it or connect to it?
Update: Okay that has been a mistake from my end, if I call the aci_gap_set_non_discoverable() function it is actually undiscoverable. So that's fine.
2. Only accept connections of paired devices
I'd like to achieve a behavior such that, if you have an unpaired phone you have to set the BLE device into a pairing mode in order to connect. If the phone has already been paired, the BLE device shall accept the connection request regardless of whether it's currently in pairing mode or not. Is this what the whitelist should be there for or do I have to do this manually by saving the address of the device after successful pairing? If whitelist is the right approach, I read that newer phones cause issues with whitelisting because they change their address on a regular basis, how can I handle this? That's actually where I thought I'm gonna work with the "discoverability".
3. Automatically reconnect
I'm not sure if this topic has to be handled on the BLE device or on the mobile phone. E.g. my phone is paired with my car's radio, so whenever the phone is in the car it automatically connects - how is this done? It's still the phone that acts as central device I assume?
Does anybody know if there is a commercial BLE tag that cannot be copied and can communicate with a BLE HM-10 module.
So, programming it before, I can "install" on it a private key that can be read out by a Master BLE device and I can be sure there is nobody in the middle of communication or my tag has not been "copied".
For clarity, I explain the project: a BLE tag OR a mobile device (Android or iOS) should communicate, like a strong key and high security, with a HM-10 master.
There is nothing in the Bluetooth standard for this. You can of course implement some public key cryptography yourself, but that has nothing to do with BLE then. You probably want a certificate in all devices, signed by a "CA" (your company). Clients should then verify the authenticity using the public key of the CA. This is exactly what TLS does.
I'm not sure however if HM-10 restricts what you can do or not.
I bought one of these:
https://www.aliexpress.com/item/Smart-finder-Key-finder-Wireless-Bluetooth-Tracker-Anti-lost-alarm-Smart-Tag-Child-Bag-Pet-GPS/32806261079.html
As far as I can tell it is a BLE (Bluetooth Low Energy) location tag.
I downloaded the app for it onto my iphone, and the app instantly recognised it and connected to it. The iPhone app seems to know how far away the tag is - it has a little map of the local area and says how many feet away. I was able to set the device name via the app, but I'm not sure if that set it locally or on the tag itself. The iPhone app also has a "find" button - when you press it, the tag beeps.
So I want to know how I can program this thing myself. I want to be able to identify it when it is nearby, connect to it and make it beep. I've searched for quite a while but not come up with much.
I'm assuming (wrongly/rightly?) that there is some general standard or approach for talking to these BLE location devices and carrying out the basic functions with them - but what is that standard - where is the documentation?
Does anyone have any idea how to program these BLE location tag devices?
BLE devices typically communicate using GATT, either using standard GATT services, or custom ones. The command to make it beep is probably implemented using a custom GATT service.
For finding out the distance to the beacon, typically the RSSI is used. This is a measure of the received power. It needs to be compared to the output power at the emitter. Usually beacons will put their output power in advertisement data, so it can be used without connecting to them. Here since the app is also able to send commands to the beacon, chances are it keeps a connection to it and has a custom GATT protocol to retrieve the output power.
Here is what I would suggest:
Read up on BLE, especially advertising and GATT. For instance read this for advertising and this for GATT. The full BLE spec is available here but should be used for reference and not introduction
Sniff the communication between your device and your phone. You can see this other answer of mine to get started
Replicate the communication protocol in you own app. For that you'll need to use your target platform's BLE libraries. For instance for iOS it is CoreBluetooth
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
i.e. / eg
I have the ‘simple chat’ Arduino app on a RedBearLab Blend-Micro (which is for all intensive purposes the same as a Arduino Uno with a BLE shield) and I only want one single / unique phone to BE ABLE TO connect with it and therefore work with it.
My understanding is that the GAP handles security features during a BLE connection.
Therefore, is there some way to ‘code’ the peripheral device in / below one of the following includes:
spi.h ?
boards.h ?
EEPROM.h ?
RBL_nRF8001.h (or similar) ?
Other?
Didn't quite get an answer from Restricting the BLE peripheral device to connect to only one Master
OR
Am I stuck with EVERYTHING connecting but coding the peripheral in some other way in a GATT profile (I think) to ONLY do something with a predefined unique central/master (how/where to code?).
Many thanks for thoughts in advance
Being somewhat of a newbie I was wondering if there is a way to hard-code something on a peripheral that would only allow a single unique central/master to connect.....?
Theres the "Advertising Filter Policy" as specified in the Bluetooth Core V4.0 specification. Its a Byte in the Advertising Parameters as specified in Section 7.8.5 LE Set Advertising Parameters Command.
For example the value 0x02 reads Allow Scan Request from Any, Allow Connect Request from White List Only.
Then theres section 7.8.16 LE Add Device To White List Command.
That said, if your device confirms to the Bluetooth 4.0 specification, it should support these HCI commands. However there might be functions that simplify these procedures, wrapping those HCI commands for easier use. Check the Documentation of your device for such methods.
Good Luck!
I was asked to answer this question via email. It's been almost a year since I quit working on BLE. So I only answer this question based on my memories.
Basically #dominik has it right.
If the device is freshly new, it should advertise normally (without setting the whitelist only bit), then any central device could connect and bond. Once it is bonded, you should save this bonded flag and the bonded master's bd_addr to EEPROM. If the next time the master is lost, you will advertise with that white-list-only flag set. If a new central tries to connect, you could verify if its address is the same as your master.
I don't have the BLE spec at hand and I kind of forgot a lot about BLE already. Probably the spec says somewhere that if a central sees a peripheral device is broadcasting with white-list-only flag set, it wouldn't try to connect if it doesn't recognize that peripheral device. This saves both some effort.
But a master could always initiate a connection to your peripheral device regardless the white-list-only flag. So checking if the connecting central device's address is the same as your previously bonded master is the last resort.
[Update]
I used CSR1010 chips. I remembered that the BLE stack actually allows me to insert a list of bd_addr to the white-list data structure maintained by the stack. Then, with the white-list-only flag set, the lower-level stack layer will help you filter devices that are not in that white-list without your knowing.
However, you can always filter bd_addrs from your application code.