BLE under the microscope 4
BLE under the microscope. Part 4
A few words about whitelist.
It so happened that I moved away from the BLE topic for a long time. But here I am back :-) Today I want to touch on the topic of whitelist. What is it for? If we want only certain phones to work with our gadget, while others could not, then whitelist is what we need.
In order to start discussing this topic you will have to go back a little. In order for the devices to begin the exchange of data, it is necessary to undergo the procedure of connection. I wrote about it in previous articles. And here it is very important not to confuse the concepts of joining and mating. In the case of joining, after breaking the connection, we forget about who we communicated with. In the case of mating - we remember the partner. So, for example, we connect our phone with bluetooth headphones. Such devices are now called bound. Now, when scanning the air, the connection to the associated device will occur without human intervention.
Why am I talking about all this? The fact is that whitelist is formed from a list of related devices. This is the first thing to remember. Secondly, it is necessary to understand how device binding is formed. There are two ways. The first is by the MAC address, the second using keys. Why is everything so difficult? The fact is that at first it was only supposed to bind by MAC address. But, when transmitting packets over the air, it is visible to everyone. Because of this, by scanning the air and using special programs, an attacker can easily replace the MAC address on his phone. As a result, even when using whitelist-a, he can access your device. To prevent this, another device binding method is used - using the irk-keys (Identity Resolving Key). Unlike the MAC address, the key length is 16 bytes, and with standard data exchange, they are not visible on the air. They are exchanged in a safe place, excluding audition. In addition, the BLE4.2 specification describes another feature. Here it is literally:
6.1 PRIVATE ADDRESS GENERATION INTERVAL
A private address shall be generated using the Resolvable Private Address Generation (see Section 1.3.2.2). A new private addressshall be generated when the timer expires. If the link has been selected, it has been reset.
Note: If the private address is generated frequently, connection may be affected. It is recommended to set the timer to 15 minutes.
In short, the BLE device can broadcast not its own public address, but a private private address, which is recommended to be changed every 15 minutes. Therefore, it does not make sense to memorize them. You only need to remember the public and random static address. In the debugger, it looks like this:
Here it is worth noting that the value of the addr_count counter in the picture on the left is 0x01, and the irk_count counter in the picture on the right is 0x02. The fact is that I tied to the device two phones with Android 4.4 (bluetooth 4.0) and Android 8.1 (bluetooth 4.1). Those. the first is connected by MAC address, and the second is already using irk-keys. Moreover, I tied the phone with android 8.1 twice. My device did not recognize it and saw them as two different phones.
The site has a good article., which decodes abbreviations and gives a general overview of the BLE technology. In addition, I want to note that there may be inaccuracies in the text, because I do not deal with this topic as much as I would like. Therefore, constructive comments are accepted and welcome.
Pecherskikh Vladimir