This article mainly summarizes the link layer connection process during the secondary connection after BLE pairing and binding, and some security mechanisms implemented by Bluetooth 4.2 during this process, including Bluetooth whitelist and security mechanism LL Privacy. LL Privacy mainly It is to prevent the device address from being leaked, causing the device to be tracked. All contents of this article are summarized according to Bluetooth 4.2.
1 BLE address type
1.1 Bluetooth address type
There are two types of device addresses, public addresses and random addresses. The public address includes a 24-bit company identification code (organizationally unique identifier based on the IEEE802-2001 standard, referred to as OUI) and a 24-bit company allocation code (the number is different for each device).
There are two types of random device addresses: static addresses and private addresses.
A static address is a randomly generated 48-bit address with the two most significant bits set to '1'.
Public addresses are fixed. Static addresses are only modified when the computer is rebooted.
Peers can easily detect and connect to devices using one of these addresses.
The private address changes periodically to ensure that the BLE device is not tracked. The unresolvable private address changes every time you reconnect.
The peer cannot compute an unresolvable private address, so it needs to be provided to the peer before connecting.
A Resolvable Private Address ( RPA ) is modified periodically and can be calculated and used by confidentiality-enabled devices.
The LL Privacy security mechanism mainly uses RPA.
1.2 Generation of Resolvable Privacy Address (RPA)
The resolvable private address has a total of 48 bits and its format is as follows:
The device generates a 24-bit value (22 bits random, 2 bits fixed) called prand. The device will use prand to generate 24-bit
hash = e(IRKlocal, padding | prand), truncated to 24 bits
in:
- IRKlocal = 128-bit local IRK
- Padding = zero-pad prand 104 bits to get 128 bits
- prand = 24-bit random number (22 bits are random, the two most significant bits are set to 0b10)
- Security function 'e' is a 128-bit AES encryption function that is implemented in the link layer hardware of PSoC 4/PRoC BLE devices. It uses 128-bit key and 128-bit plaintextData to generate encryptedData, as defined in FIPS-1971: encryptedData = e(key, plaintextData)
- The random address (randomAddress) is obtained by combining the 24-bit hash and the 24-bit prand in the following way:
randomAddress = hash | prand
The generation process of RPA is shown in the figure below:
1.3 Resolution of Resolvable Private Address (RPA)
How a BLE Confidential Device resolves a peer device's RPA. The RPA provided by the peer device consists of a 24-bit random part (prand) and a 24-bit hash part (hash), as described in Section 7.2.3. When parsing or decoding an address, the least significant 24 bits of the RPA are treated as the peer's hash, and the most significant 24 bits of the address are treated as the prand. Use the Hash function above to generate the localHash value. Among them, the input parameters of the function are the IRK provided by the peer device (which will be exchanged by the master and slave when pairing and binding for the first time) and the prand extracted from the RPA.
localHash = e(IRKpeer, padding | prand), truncated to 24 bits
Compare the localHash with the hash extracted from the RPA. If the localHash matches the extracted hash, it means that the peer device's ID address has been
parse. The address resolution process is shown in the figure below.
2Bluetooth whitelist
The so-called whitelist is a set of Bluetooth addresses; through the whitelist, you can only allow specific Bluetooth devices (listed in the whitelist) to scan (Scan) and connect (connect) to us, or you can only scan and connect to specific Bluetooth devices. Devices (whitelisted).
For example, if a BLE device only needs to be scanned and connected by a few trusted devices, we can add the Bluetooth addresses of these trusted devices to the device's whitelist, which can effectively avoid other "rogue" devices. equipment" was harassed.
However, this mechanism only protects against gentlemen, not villains, because it relies on addresses to filter out "rogues". If some senior rogues disguise themselves and change their device addresses to the addresses of trusted devices, it will be a disaster. …
The whitelist is implemented at the LL layer, which includes: whitelist policy, device address type, device address, etc.
3 Security Mechanism-LL Privacy
Similar to the White List on the whitelist mechanism, if the device needs to use the LL Privacy mechanism, it needs to save a Resolving List on the Controller side. The idea is:
- The BLE device must configure and enable the whitelist mechanism as described in 2.2, add the addresses of trusted devices (here Identity Address) to its own whitelist, and adopt an appropriate whitelist strategy.
- If the device needs to use the LL Privacy policy to protect its own (and the other party's) address from being stolen, it needs to save its own (local) and the other party's (peer) addresses and encryption keys in a list called a Resolving List.
- Each entry in the Resolving List saves the key/address information of a pair of BLE devices, and its format is:
Local IRK | Peer IRK | Peer Device Identity Address | Address Type
When sending a data packet, determine whether the Resolving List has a non-zero Local IRK. If so, use the Local IRK to encrypt the Identity Address into a Resolvable Private Address and fill it in the corresponding address storage field in the data packet. Otherwise, fill in the Identity Address directly;
When receiving a data packet, if the addresses in the data packet are ordinary Identity Addresses, subsequent processing will be performed directly; if they are Resolvable Private Addresses, all "IRK | Identity Address" entries in the Resolving List will be traversed and IRK will be used to solve the problem. Compare the Identity Address and the entry. If they match, the address resolution is successful and further processing can be performed. If it does not match and the whitelist/LL Privacy policy is enabled, it will be discarded directly. If the whitelist is not enabled, the normal connection process will be followed.
In the third phase of the pairing process, the GAP center and GAP peripheral exchange IRK and ID addresses. These contents serve as the payload part of the pairing-related packets. The IRK, ID address, and local IRK of the peer device are stored in the resolution tables of both devices. At this stage, both devices contain information for resolving RPA, so they both have the RPA timeout parameter set and address resolution enabled. They can also optionally add peer device ID addresses to a whitelist for filtering devices. The whitelist is a set of Bluetooth device addresses used by the link layer of BLE devices to filter broadcasters, scanners, and connection initiators. Whitelisting is only used when device filtering is enabled. Devices exchange data on the BLE data channel. Because the device's resolution table has the information to resolve the peer device's RPA, the reconnection procedure uses the RPA. The image below shows two devices successfully connecting for the first time, being disconnected, and then reconnecting.
As shown above, this time, all packets sent by both devices on the broadcast channel use RPA. Therefore, communication between two devices on the broadcast channel is not tracked by any third device. Note that when reconnecting, GAP peripherals can use connectable undirected broadcasts or connectable directed broadcasts. Bluetooth 4.2 secure devices support connectable directed broadcasts. Scan requests and scan responses are only used when the GAP peripheral uses connectable undirected broadcasts. When a GAP peripheral uses connectable directed broadcasts, the GAP center can only respond by sending a connection request. Note that the privacy feature prevents tracking of BLE device communications on the broadcast channel. The access address used by the data channel's packets is modified every time it is connected, so it is the most difficult to track. The privacy feature has no impact on data channel packets.
References
Bluetooth core specification Core_v4.2.pdf
AN99209_-_PSoC_4_BLE_and_PRoC_BLE_Bluetooth_LE_4.2_Features_Chinese.pdf
Bluetooth protocol analysis (9)_LL Privacy of BLE security mechanism
Bluetooth protocol analysis (8)_White list of BLE security mechanism