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 I came 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 begin to discuss this topic 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 concept 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 your 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 reset, 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:







It is worth noting here that 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 two phones to the device with Android 4.4 (bluetooth 4.0) and Android 8.1 (bluetooth 4.1). Those. the first one is connected by MAC address, and the second one already uses 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.



There is a good article on the site that 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