I have a question, for BLE experts, regarding the IRK exchanged when bonding occurs between two BLE devices with public address. I don't remember where I saw the statement that if during exchange keys a device "A" got IRK from a peer device "B" that has public address, the device "A" keep the received IRK as zeros.
Could somebody confirm or deny this statement?
Thank you in advance
Searching in the spec5.3 I found nothing about keeping the IRK that received from device with public address.
Every device must have either a Public Address or a Static Random Address that is used as the Identity Address.
When a device advertises, connects or sends a scan request, it can either choose to use this Identity address as its own address or use a Resolvable Private Address derived from its own IRK (if the device has an IRK). If the device does not have an IRK, it must use its Identity Address (or possibly a non-resolvable private address).
Whenever the IdKey bit is set in the Pairing Request and Pairing Response messages for the central or the peripheral, respectively, the IRK and Identity Address shall be distributed. If a device does not have an IRK, it sets the IRK field to 16 zero bytes in the SMP Identity Information packet during the key distribution phase during the pairing, per Bluetooth Core specification v5.3, Vol 3, Part H (SMP), section 3.6.4:
Note: An all zero Identity Resolving Key data field indicates that a device does not have a valid resolvable private address.
I think you have misunderstood something, because there is nothing that says that a device receiving a valid IRK or no IRK at all shall "set it to zeros" if the same remote device happens to have a Public Address (either as the address used during the connection or as its Identity Address). In fact, an all-zero IRK is not even valid, since such a one could not be sent over the SMP protocol (since an all-zero IRK would mean a non-existing IRK).
Note that it's perfectly fine for a device that "has a public address" to also have an IRK. It might for one connection use the public address and for another connection use a Resolvable Private Address derived from its IRK.
It is however common that devices have a public address as Identity Address and no IRK. In that case the bonding storage representing this device will store the public address and no IRK, (since it receives an all-zero IRK during key distribution).
Related
I have experimenting with Bluez 5.50 Bluetooth Stack, Here i have some confusion about procedure Auto-connection using Whitelist.
Suppose,
Device A - Advertiser
Device B - Scanner
Add Advertisers(Device A) Bluetooth address as white list in Scanner(Device B)
Device A will advertise with "Connectable Un-directed" adv type & default adv params
Device B will start scanning with "Accept only PDUs from device in white list" configuration
If B scans A's address, than explicitly B will send connection request to A(Without sending Connection create command)
What is basic difference between paired device & white listed device ?
The white list can be used both when just scanning as well as when connecting.
Note that the packet exchange during advertising is this, when the central device is just scanning:
Advertiser sends ADV_IND.
Scanner sends SCAN_REQ.
Advertiser sends SCAN_RSP.
When the central device has a pending initiation (i.e. connection attempt) to a peripheral, the packet exchange is this:
Advertiser sends ADV_IND.
Initiator sends CONNECT_IND.
The connection is now established.
Note the timing between between to packets in the flow above is 150 microseconds (T_IFS), which is quite quick. If the advertiser does not detect SCAN_REQ, it does not send SCAN_RSP. If it also does not detect CONNECT_IND, it does not enter the connection state, but continue to advertise. There is a need to have a white list because the host would not be quick enough to decide if the packet should be dropped or not. Therefore the white list is implemented directly in the Bluetooth controller hardware.
A central device using the white list, will simply drop any ADV_IND having an address that cannot be found in the white list. Therefore no SCAN_REQ or CONNECT_IND is sent in this case.
"Auto-connect" therefore refers to when the initiator is constantly looking for ADV_IND packets where the sender's address is in the white list. If one is found, a CONNECT_IND is sent and the connection gets established, resulting in an "LE Connection Complete" event. Using the white list is the only way to have two or more pending connections, since otherwise you need to specify exactly one target address when initiating a connection. (Although a workaround sometimes used when the white list cannot be used, for example if it is too small to contain all desired addresses, is to let the central first perform a scan, then initiate a connection to the target addrerss, with some short timeout. This introduces latency as at least two ADV_INDs must be sent.)
Paired/Bonded device is a completely different thing. It means that both devices have stored in its database, information about the remote device, such as encryption keys, client characteristic configuration descriptor state, gatt db cache. Bonded devices are usually listed in a user interface as well.
When the white list is used when establishing connections, you can have addresses in this list of non-bonded devices. You can also have bonded devices which you do not currently want to connect to, which are then not included in the white list.
What I've written above is general BLE without any specific Bluetooth stack in mind. BlueZ might have certain conditions/flows when the white list is used.
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 am porting some code from MacOS to Windows. MacOS always returns a non-empty local name in advertisement packets while Windows seems to always return an empty local name in an advertisement packet.
No, having a local name is not a requirement as part of sending out adverts. The requirements for BLE adverts depend on the type of advert, but for the simplest and most common advert type (ADV_IND, a.k.a scannable & connectable advert) the only requirement is the device's public or random address. None of the advert types require the local name to be part of the address. You can read more about this in the Bluetooth Specification v5.2, Vol 6, Part B, Section 2.3.1 (Advertising PDUs) [1].
You can also do a scan with nRF Connect on an Android/iOS device and you'll see that many devices don't have the name as part of advert, instead you get N/A as the device's name:-
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.
I am developing an application for peer-peer conversation in ad-hoc network. when a peer wants to communicate with other peer, it uses its ip address to connect.
Once devices connected with each other in an Ad-hoc network, a IP address is assigned to each one of them, but I need a smaller string(of 4-6 character) as a unique ID for each device in an ad-hoc network. Since this is a peer-peer network, there is no server(which can generate unique ID), so it is a responsibility of each peer itself to generate unique ID. I am searching for a mechanism or algorithm to generate the unique ID in java.
This is probably best solved by use of each device's interface specific MAC address. MAC addresses are, in standard implementation, unique to each network interface, so each one of your devices already has a unique number. You can use this address directly or as a seed value to create derived IDs.
Use the below code for generating random numbers with 6 characters
private static SecureRandom random = new SecureRandom();
public static String getUniqueId() {
return new BigInteger(130, random).toString(32).substring(0, 6);
}