Low-power-consumption Bluetooth link layer relay attack blocking method, system, device, medium, program product and application

Abstract

The invention belongs to the technical field of wireless communication security, and particularly relates to a low-power-consumption Bluetooth link layer relay attack blocking method, system, equipment, medium and program product and application, and the method comprises the following steps: initializing BLE channel selection parameters, synchronously calling CSA2, generating channel identification parameters and a channel remapping table based on a BLE access address and a channel mapping table, the method comprises the following steps: acquiring cryptographic disturbance input parameters for combination, performing hash operation by using a secure hash function, taking a result as a dynamic disturbance factor, generating a variable connection event count based on the dynamic disturbance factor, replacing a CSA2 native connection event count, and generating an unpredictable pseudo-random number in combination with a channel identification parameter; and finally, determining a next connection event communication channel which cannot be predicted by the attacker in combination with a channel mapping table (Channel Map) and a channel remapping table (Remapping Table). A BLE5. X for the use of CSA2; the system, the equipment and the medium are used for implementing the method. The program product comprises a computer program for implementing the method; and an attacker is prevented from implementing a relay attack.

Description

Technical Field

[0001] This invention belongs to the field of wireless communication security technology, specifically relating to a method, system, device, medium, program product, and application for blocking low-power Bluetooth link layer relay attacks. Background Technology

[0002] Bluetooth Low Energy (BLE) has been widely used in numerous scenarios, including smart locks, wearable devices, industrial sensors, vehicle-to-everything (V2X) terminals, and IoT sensing nodes, thanks to its low power consumption, low cost, and mature ecosystem compatibility. Its deployment has been particularly strong in security-sensitive scenarios such as keyless entry for vehicles and smart security authentication. However, with the expansion of its application scope, the security vulnerabilities of the BLE link layer have become increasingly prominent, posing a key bottleneck to its deep application in high-security scenarios.

[0003] In recent years, authoritative security research institutions such as the NCC Group have publicly disclosed an attack method called Bluetooth Low Energy (BLE) link layer relay attack (also known as distance extension attack). The main target of this attack is devices using Bluetooth Low Energy (BLE) 5.x series.

[0004] The existing defense solutions against Bluetooth Low Energy (BLE) link layer relay attacks have significant flaws and are difficult to meet the needs of practical applications. These flaws can be categorized into two types: (1) Secure ranging scheme based on time of flight (TOF) or ultra-wideband (UWB): Such schemes require additional dedicated hardware modules to be integrated into Bluetooth Low Energy (BLE) devices, which not only significantly increases the power consumption and hardware cost of the devices, but also has the problem of incompatibility with existing Bluetooth Low Energy (BLE) devices, and cannot be adapted to resource-constrained embedded Bluetooth Low Energy (BLE) terminals (such as mini BLE terminals, etc.), thus limiting their promotion and application; (2) Detection scheme based on Received Signal Strength Indicator (RSSI): This type of scheme relies on post-event analysis of the characteristics of communication signals to identify attacks. However, the Received Signal Strength Indicator (RSSI) value is easily affected by factors such as environmental obstruction and multipath effect, resulting in low detection accuracy and high false judgment rate. More importantly, this type of scheme is a "post-event response" mechanism, which can only identify attacks after they occur and cannot block the implementation of attacks from the source, resulting in poor defense timeliness.

[0005] Therefore, existing defense solutions have inherent defects such as "reliance on dedicated hardware, high power consumption and cost, poor compatibility" or "defense lag and low accuracy".

[0006] Patent application CN111766591A discloses a high-precision Bluetooth BLE ranging system based on a Time-of-Flight (TOF) sensor. However, most consumer-grade Bluetooth Low Energy (BLE) devices (such as wristbands, beacons, and basic Bluetooth Internet of Things (IoT) devices) do not have a TOF sensor. This patent requires the introduction of a TOF sensor, which has disadvantages such as the need to add additional supporting hardware modules, increased hardware costs and system complexity, increased difficulty in power supply design and overall power consumption, and poor device integration and miniaturization adaptability.

[0007] Patent application CN112291704A discloses a positioning system based on BLE and UWB technologies. However, the UWB module introduced in this patent is usually only used as an additional function in high-end flagship devices. Most Bluetooth Low Energy (BLE) devices do not have a UWB module. Therefore, it has the disadvantages of requiring additional UWB hardware modules, increasing hardware costs and system complexity, increasing the difficulty of power supply design and increasing overall power consumption, and poor device integration and miniaturization adaptability.

[0008] Patent application CN115209416A discloses a method, device, vehicle, and medium for detecting relay attacks. However, because its core reliance on comparing the Received Signal Strength Indication (RSSI) value with a reference range to achieve attack detection, it suffers from extremely poor environmental adaptability, susceptibility to multipath effects and obstruction interference leading to high false alarm and false negative rates, and the inability to identify attacks only after the fact and block relay attacks at their source. Summary of the Invention

[0009] To overcome the shortcomings of the prior art, the present invention aims to provide a method, system, device, medium, program product, and application for blocking Bluetooth Low Energy (BLE) link layer relay attacks. The master and slave devices collect cryptographic perturbation input parameters, combine these parameters, and perform hash operations using a secure hash function. The hash result is used as a dynamic perturbation factor, and a mutated connection event count is generated based on this factor, replacing the native connection event count of Channel Selection Algorithm 2 (CSA2). The communication channel for the next connection event is determined based on the mutated connection event count. This pure protocol software layer BLE link layer relay attack blocking method, without introducing additional hardware modules, changing the BLE protocol frame format, or compromising existing protocol compatibility, enhances the randomness and unpredictability of the CSA2 frequency hopping sequence. This disrupts the "stable frequency tracking" prerequisite upon which relay attacks rely from the source of the attack, preventing attackers from completing frequency hopping tracking and data sniffing, thus achieving proactive and precise blocking of relay attacks.

[0010] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for blocking Bluetooth Low Energy link layer relay attacks includes the following steps: Step S1: Initialize the channel selection parameters of the Bluetooth Low Energy (BLE) master and slave devices, synchronously call Channel Selection Algorithm 2 (CSA2), and generate consistent channel identifier parameters and channel remapping table based on the access address and channel map negotiated by the master and slave devices. Step S2: The master and slave devices collect cryptographic perturbation input parameters; Step S3: The master device and the slave device combine the cryptographic perturbation input parameters collected in step S2, and perform hash operation using a secure hash function, using the hash result as a dynamic perturbation factor; Step S4: Based on the dynamic disturbance factor generated in step S3, generate a mutated connection event count and replace the original connection event count of Channel Selection Algorithm 2 (CSA2); Step S5: Based on the mutated connection event count generated in step S4, and combined with the channel identifier parameter generated in step S1, generate unpredictable pseudo-random numbers; Step S6: Based on the pseudo-random number generated in step S5, and combined with the channel map and remapping table in step S1, determine the communication channel of the next connection event that the attacker cannot predict, thereby blocking the attacker from carrying out a relay attack.

[0011] Step S2 specifically involves: During the current connection event cycle, the master device and the slave device synchronously collect the security key, Channel Selection Algorithm 2 (CSA2) native connection event count, and salt value, which are known only to the master device and the slave device. The entire collection process is completed at the Bluetooth Low Energy (BLE) protocol stack controller layer.

[0012] Step S3 specifically involves: The master and slave devices combine the cryptographic perturbation input parameters, perform hash operations using a keyed secure hash function, generate a fixed-length hash result, and use this hash result as a dynamic perturbation factor.

[0013] Step S4 specifically involves: The dynamic perturbation factor is compressed to obtain a mutated connection event count with the same number of bits as the original connection event count. This mutated connection event count is used to replace the original connection event count in Channel Selection Algorithm 2 (CSA2), thereby optimizing the core input of CSA2.

[0014] In step S5, the unpredictable pseudo-random number generation logic adopts the original pseudo-random number generation logic of Channel Selection Algorithm 2 (CSA2).

[0015] A low-power Bluetooth link layer relay attack blocking system employs a low-power Bluetooth link layer relay attack blocking method, comprising: The initialization module initializes the channel selection parameters for the Bluetooth Low Energy (BLE) master and slave devices, synchronously calls Channel Selection Algorithm 2 (CSA2), and generates consistent channel identifier parameters and channel remapping table based on the access address and channel map negotiated by the master and slave devices. The algorithm optimization module collects cryptographic perturbation input parameters from the master and slave devices, combines the cryptographic perturbation input parameters, performs hash operation using a secure hash function, uses the hash result as a dynamic perturbation factor, and finally generates a mutated connection event count based on the dynamic perturbation factor, replacing the native connection event count of Channel Selection Algorithm 2 (CSA2). The attack blocking module generates unpredictable pseudo-random numbers based on the count of mutated connection events and the channel identifier parameter. By combining the pseudo-random numbers, the channel map, and the remapping table, it determines the communication channel of the next connection event that the attacker cannot predict, thereby blocking the attacker from carrying out relay attacks.

[0016] A low-power Bluetooth link layer relay attack blocking device, comprising: Memory: Used to store computer programs that implement methods for blocking Bluetooth Low Energy link layer relay attacks; Processor: Used to implement a method for blocking Bluetooth Low Energy link layer relay attacks when executing the computer program.

[0017] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a method for blocking Bluetooth Low Energy link layer relay attacks.

[0018] A computer program product includes a computer program that, when executed by a processor, implements a method for blocking Bluetooth Low Energy link layer relay attacks.

[0019] A method for blocking Bluetooth Low Energy link layer relay attacks is provided for master and slave devices of Bluetooth Low Energy (BLE) 5.x that employ Channel Selection Algorithm 2 (CSA2).

[0020] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention employs a master device and a slave device to collect cryptographic perturbation input parameters, combines the collected cryptographic perturbation input parameters, and uses a secure hash function to perform hash operations. The hash result is used as a dynamic perturbation factor to achieve secure and reliable generation of the dynamic perturbation factor. This provides unpredictable perturbation support for subsequent mutation connection event counting, and prevents attackers from cracking the perturbation logic and predicting frequency hopping patterns in advance.

[0021] 2. This invention adopts a method of generating mutated connection event counts based on dynamic perturbation factors and replacing the native connection event counts of Channel Selection Algorithm 2 (CSA2). This achieves dynamic optimization of the original channel calculation process of CSA2, which breaks the predictability of the native connection event counts and undermines the frequency hopping tracking foundation upon which relay attacks rely from the core algorithm level.

[0022] 3. This invention uses a method that generates unpredictable pseudo-random numbers based on the counting of mutated connection events combined with the channel identifier parameter, and then uses the channel map and the remapping table to determine the communication channel of the next connection event. This enables the generation of frequency hopping sequences that attackers cannot predict, and directly blocks attackers' frequency hopping tracking and data sniffing behaviors, achieving the effect of proactive and precise blocking of relay attacks.

[0023] In summary, the Bluetooth Low Energy link layer relay attack blocking method proposed in this invention achieves BLE link layer relay attack blocking through synchronous initialization, perturbation parameter acquisition and calculation, dynamic generation of frequency hopping sequence and determination of communication channel. It features a simple process, closed-loop logic, and is entirely based on the original architecture of the CSA2 algorithm with optimization. No additional steps are required, making it easy to implement and providing strong targeted defense. Attached Figure Description

[0024] Figure 1 This diagram illustrates the source code modification locations and defense module deployment in the Zephyr BLE protocol stack controller layer of this invention.

[0025] Figure 2 This is a flowchart illustrating the overall process of the technical solution of this invention.

[0026] Figure 3 This diagram illustrates a comparison between a Bluetooth Low Energy (BLE) link layer relay attack scenario and the defense logic of this invention. The left diagram represents the attack scenario, and the right diagram represents the defense scenario. Detailed Implementation

[0027] The technical solution of this invention will be described in detail below with reference to a specific engineering application scenario. This embodiment is based on the Zephyr operating system and the nRF52840-DK development board to build a Bluetooth Low Energy (BLE) 5.0 master and slave device communication system. The core objective is to verify the effectiveness of the HMAC-SHA256-based channel perturbation scheme in defending against Bluetooth Low Energy (BLE) link layer relay attacks disclosed by the NCC Group. At the same time, it verifies the low time and low storage overhead characteristics of the scheme, ensuring that the scheme can be directly ported to other Bluetooth Low Energy (BLE) 5.x devices that support Channel Selection Algorithm 2 (CSA2).

[0028] The channel perturbation implementation scheme based on HMAC-SHA256 of the present invention will be described in detail below with reference to the accompanying drawings.

[0029] (1) Implementation environment and preset parameters In this embodiment, the hardware / software environment and core parameters of the master device and the slave device are strictly kept consistent to ensure channel synchronization and defense logic coordination, as detailed below: 1) Hardware environment: Both the master and slave devices use the nRF52840-DK development board, which integrates a Bluetooth Low Energy (BLE) 5.0 radio transceiver module and natively supports the Channel Selection Algorithm 2 (CSA2) of the Bluetooth Low Energy (BLE) standard. 2) Software Environment: The development environment is based on the Zephyr operating system, and the supporting development environment configuration includes: cmake 4.2.1 configuration tool, ninja build tool, zephyr-sdk-0.17.0 cross-compilation toolchain, Python runtime environment (version ≥ 3.8) and dependent libraries (west, pylftools, pyyaml, jsonschema, packaging); the Bluetooth Low Energy (BLE) protocol stack uses the Zephyr built-in Bluetooth subsystem, where the core implementation source code of Channel Selection Algorithm 2 (CSA2) is located at: zephyr / subsys / Bluetooth / controller / ll_sw / lll_chan.c, as shown below. Figure 1 As shown, the defense logic of this invention is to modify the lll_chan.c source code file of the Bluetooth Low Energy (BLE) controller layer and recompile the modified file into the firmware file; 3) Core parameters include: A security key known only to the master and slave devices: a 32-byte security key. The master and slave devices synchronize during the pairing phase through the Bluetooth Low Energy (BLE) standard key negotiation process (in this embodiment, through the BLE Secure Connections protocol) to ensure the uniqueness and security of the key. System timestamp: Local minute-level timestamps of the master and slave devices. The core purpose of choosing this precision is to balance synchronization stability and disturbance randomness. It avoids inconsistencies in disturbance factors caused by minute clock deviations between the master and slave devices due to microsecond-level precision, while ensuring that a new disturbance factor is generated every minute to meet the anti-prediction requirements. Hash Algorithm: Employs the HMAC-SHA256 keyed secure hash function, which is collision resistant and one-way; Bit-width compression rule: The hash result is compressed into a 16-bit mutated connection event count, which fully matches the native counting bit width of Channel Selection Algorithm 2 (CSA2) to ensure compatibility with the original algorithm framework.

[0030] (2) Specific implementation steps like Figure 2 As shown in the flowchart, a method for blocking Bluetooth Low Energy (BLE) link layer relay attacks includes the following steps: Step S1: Initialize the channel selection parameters for Bluetooth Low Energy (BLE) master and slave devices; The master device sends a connection request frame to the slave device through the BLE standard broadcast channel. The master and slave devices negotiate the access address and channel map (37 data channels, channel number range 0-36). At the same time, the master and slave devices synchronously call the Channel Selection Algorithm 2 (CSA2) lll_chan_sel_2 function in the lll_chan.c file. Based on the access address and channel map, they jointly generate the channel identifier parameter and the channel remapping table to ensure that the initial channel parameters of the master and slave devices are completely synchronized, laying the foundation for subsequent channel cooperative handover.

[0031] Step S2: The master and slave devices collect cryptographic perturbation input parameters; When each Bluetooth Low Energy (BLE) connection event is triggered (in this embodiment, the trigger period is 50 milliseconds), the master device and the slave device synchronously complete the acquisition of three types of cryptographic perturbation input parameters at the Bluetooth Low Energy (BLE) protocol stack controller layer. The entire process does not call application layer interfaces or involve application layer interaction, thus avoiding additional computing power overhead. The three types of cryptographic perturbation input parameters include: a security key known only to the master device and the slave device (a 32-byte security key, which can be expanded to 32 bytes if less than 32 bytes), a salt value (a local minute-level system timestamp of the master device and the slave device), and a native connection event count of Channel Selection Algorithm 2 (CSA2) (the value ranges from 0 to 65535, and increases linearly in a cyclic manner).

[0032] Step S3: The master device and the slave device combine the cryptographic perturbation input parameters collected in step S2 to generate a dynamic perturbation factor; The master and slave devices concatenate the system timestamp and the native connection event count (in this embodiment, the concatenation order is "timestamp" first, "native connection event count" second) to form a fixed-length combined data (4 bytes for the timestamp + 2 bytes for the native connection event count, totaling 6 bytes). Using a 32-byte security key as the key, the HMAC-SHA256 keyed secure hash function is called to perform an encrypted hash operation on the combined data, generating a 32-byte hash result. This hash result is the dynamic perturbation factor of this connection event. Due to the dual randomness of the key and the timestamp, it is ensured that the perturbation factor cannot be reproduced by attackers.

[0033] In other embodiments, step S3: The master device and the slave device combine the cryptographic perturbation input parameters collected in step S2 to generate a dynamic perturbation factor; The master and slave devices concatenate the system timestamp and the native connection event count (in this embodiment, the concatenation order is "timestamp" first, followed by "native connection event count") to form a fixed-length combined data (4 bytes for the timestamp + 2 bytes for the native connection event count, totaling 6 bytes). Using a 32-byte security key as the key, one of the keyed secure hash functions HMAC-SHA512, HMAC-SHA3, HMAC-BLAKE2, and HMAC-BLAKE3 is called to perform an encrypted hash operation on the combined data, generating a 32- or 64-byte hash result. This hash result is the dynamic perturbation factor of this connection event. Due to the dual randomness of the key and the timestamp, it is ensured that the perturbation factor cannot be reproduced by attackers.

[0034] Step S4: Core Connection Event Parameters of Mutant Channel Selection Algorithm 2 (CSA2) The specific process of 32-byte dynamic perturbation factor bit width compression is as follows: Segmented XOR 1: Divide the 32-byte perturbation factor into four 8-byte segments, perform an XOR operation on the four 8-byte segments in sequence, and obtain one 8-byte intermediate result; Segmented XOR 2: Divide the 8-byte intermediate result into two 4-byte (32-bit) segments, perform an XOR operation on the two 4-byte segments, and obtain a 32-bit result; Low-order truncation: Take the lower 16 bits of the 32-bit result as the final mutation connection event count; Finally, at the call to the native connection event count in the Channel Selection Algorithm 2 (CSA2) file in lll_chan.c, the mutated connection event count is used instead of the native connection event count to complete the optimization of the input parameters of the Channel Selection Algorithm 2 (CSA2).

[0035] In other embodiments, the specific process of step S4: 64-byte dynamic perturbation factor bit-width compression is as follows: Segmented XOR 1: Divide the 64-byte perturbation factor into eight equal segments of 8 bytes each, and perform an XOR operation on each of the eight segments in sequence to obtain one 8-byte intermediate result. Segmented XOR 2: Divide the 8-byte intermediate result into two 4-byte (32-bit) segments, perform an XOR operation on the two 4-byte segments, and obtain a 32-bit result; Low-order truncation: Take the lower 16 bits of the 32-bit result as the final mutation connection event count; Finally, at the call to the native connection event count in the Channel Selection Algorithm 2 (CSA2) file in lll_chan.c, the mutated connection event count is used instead of the native connection event count to complete the optimization of the input parameters of the Channel Selection Algorithm 2 (CSA2).

[0036] Step S5: Calculate unpredictable pseudo-random numbers The master device and the slave device synchronously call the pseudo-random number generation function (chan_prn_e) of the channel selection algorithm 2 (CSA2). Taking the mutated connection event count obtained in step S4 and the channel identifier parameter (ChannelIdentifier) ​​generated in step S1 as input, the pseudo-random number generation logic of the channel selection algorithm 2 (CSA2) is used to obtain an unpredictable pseudo-random number. This pseudo-random number directly determines the selection of the subsequent communication channel.

[0037] Step S6: Determine the communication channel for the next connection event. The master and slave devices take the remainder of the pseudo-random number generated in step S5 modulo 37 (since there are 37 valid BLE data communication channels, numbered 0-36). The remainder result is used as a channel index. The device then checks the channel mapping table (Channel Map) in step S1 to see if the corresponding channel is available. If available, the channel number is used as the physical channel number for the next connection event. If unavailable, the device multiplies the number of available channels N in the Channel Map by the pseudo-random number generated in step S5, divides the result by 65536, and rounds down to use the new channel index. Based on this new channel index, the device queries the remapping table (Remapping Table) generated in step S1 to determine the physical channel number for the next connection event. During the connection event interval, the master and slave devices synchronously switch to this channel, completing a dynamic channel allocation and ensuring complete consistency of communication channels between the two devices.

[0038] Through the above steps, Bluetooth Low Energy (BLE) master and slave devices, while being fully compatible with the existing Bluetooth Low Energy (BLE) protocol stack and communication process, generate frequency hopping sequences that attackers cannot predict, blocking attackers' frequency hopping tracking and data sniffing behaviors from the source, thereby achieving proactive blocking of Bluetooth Low Energy (BLE) link layer relay attacks.

[0039] A low-power Bluetooth link layer relay attack blocking system employs a low-power Bluetooth link layer relay attack blocking method, comprising: The initialization module initializes the channel selection parameters for the Bluetooth Low Energy (BLE) master and slave devices, synchronously calls Channel Selection Algorithm 2 (CSA2), and generates consistent channel identifier parameters and a channel remapping table based on the access address and channel map negotiated by the master and slave devices, in order to implement step 1 of the method described in this invention; The algorithm optimization module collects cryptographic perturbation input parameters from the master and slave devices, combines the cryptographic perturbation input parameters, performs hash operation using a secure hash function, uses the hash result as a dynamic perturbation factor, and finally generates a mutated connection event count based on the dynamic perturbation factor, replacing the native connection event count of Channel Selection Algorithm 2 (CSA2), to implement steps 2-4 of the method described in this invention; The attack blocking module generates unpredictable pseudo-random numbers based on the mutated connection event count and the channel identifier parameter. It then uses the pseudo-random numbers, the channel map, and the remapping table to determine the communication channel of the next connection event that the attacker cannot predict, thereby blocking the attacker from carrying out relay attacks. This is used to implement steps 5 and 6 of the method described in this invention.

[0040] A low-power Bluetooth link layer relay attack blocking device, comprising: Memory: Used to store computer programs that implement methods for blocking Bluetooth Low Energy link layer relay attacks; Processor: Used to implement a method for blocking Bluetooth Low Energy link layer relay attacks when executing the computer program.

[0041] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a method for blocking Bluetooth Low Energy link layer relay attacks.

[0042] A computer program product includes a computer program that, when executed by a processor, implements a method for blocking Bluetooth Low Energy link layer relay attacks.

[0043] A method for blocking Bluetooth Low Energy link layer relay attacks is provided for master and slave devices of Bluetooth Low Energy (BLE) 5.x that employ Channel Selection Algorithm 2 (CSA2).

[0044] (3) Verification of the synchronization mechanism and overhead between master and slave devices This embodiment ensures the synchronization reliability between the master and slave devices through a dual mechanism to avoid channel synchronization failure: Static parameter synchronization: The security key, HMAC-SHA256 hash algorithm, and "bit width compression" rules, which are known only to the master and slave devices, are kept consistent between the master and slave devices; Dynamic parameter synchronization: Minute-level timestamps ensure that the timing of the master and slave devices is consistent through the synchronization clock calibration mechanism of the Bluetooth Low Energy (BLE) link layer (based on the clock synchronization field of the Bluetooth Low Energy (BLE) 5.0 standard), effectively avoiding parameter acquisition differences caused by device local clock deviations.

[0045] Based on actual testing (test environment: room temperature 25℃, no strong electromagnetic interference), the core performance indicators of this solution are as follows: Time overhead: The entire channel calculation process for a single connection event (including parameter acquisition, HMAC-SHA256 operation, mapping mutation, and pseudo-random number generation) has a time overhead of only 3.5μs, which is far lower than the 50-millisecond connection event period and has no impact on the normal communication timing of Bluetooth Low Energy (BLE). Storage overhead: The new storage overhead is only 70 bytes, specifically allocated as 32 bytes of security key cache, 6 bytes of timestamp and connection event count concatenation data cache, and 32 bytes of perturbation factor cache, which is far below the hardware resource limit of the nRF52840-DK development board (1 MB Flash, 256 KB RAM), making it fully compatible with resource-constrained Bluetooth Low Energy (BLE) devices.

[0046] (4) Security certification This embodiment, through a combination of "key + secure hash + dynamic timestamp + nonlinear mutation," fundamentally ensures the unpredictability of mutation connection event counting and frequency hopping sequences, while effectively resisting typical attack methods such as known plaintext attacks. Its security can be rigorously proven from the following four aspects: 1) Protection against irreversibility of the key and HMAC-SHA256 hash function This embodiment uses a 32-byte security key with a key space of 2². 56 The entropy value is extremely high, far exceeding the current computing power's ability to crack it. Simultaneously, relying on the one-wayness and collision resistance of the HMAC-SHA256 keyed secure hash function, the perturbation factor is generated. HAMC-SHA256 can only calculate a unique 32-byte hash result (perturbation factor) from the input combination of "key + timestamp + native connection event count," and cannot deduce any input parameters from the hash result. Even if an attacker obtains the mutated connection event count (16 bits, only the lower 16 bits of the hash result) through wireless sniffing, they cannot deduce the 32-byte key from this information, thus ensuring that the core key is not leaked and fundamentally preventing attackers from reproducing the mutated connection event count generation logic.

[0047] 2) Protection against known-plaintext attacks using dynamic timestamp factors The core function of timestamps is to mitigate the vulnerability of known-plaintext attacks without dynamic factors: Without timestamps, the initial native connection event count for each new connection increases linearly from 0, and the key remains unchanged after pairing. This results in the combination of "native connection event count + key" being completely repeated in each new connection, generating a fixed hash value sequence and a mutated connection event count sequence. If the access address and channel map remain unchanged, the final frequency hopping sequence will also be completely fixed. Attackers can carry out known-plaintext attacks by capturing the connection process multiple times, and after obtaining the fixed frequency hopping sequence, they can achieve precise frequency tracking.

[0048] This embodiment introduces minute-level timestamps as a dynamic factor, ensuring that the input combination of "key + timestamp + native connection event count" is updated every minute. Even the same native connection event count (e.g., 0, 1, 2…) will correspond to different input combinations at different minutes due to different timestamps, generating different hash results and mutated connection event counts. This prevents attackers from obtaining fixed "input-output" sample pairs, completely negating the prerequisite for known-plaintext attacks (a large amount of repetitive sample data), effectively resisting such attacks.

[0049] 3) Proof of the unpredictability of mutated connection event counting The native connection event count is a linearly increasing sequence from 0 to 65535, possessing 100% predictability. However, the mutated connection event count in this embodiment is generated through a "32-byte perturbation factor + two segmented XOR operations + low-order truncation," making it unpredictable not only in its generation logic but also in the infeasibility of real-time, precise brute-force attacks by attackers. The specific arguments are as follows: On the one hand, the generation logic of the mutated connection event count determines its randomness: Randomness of the perturbation factor: Due to the unknown key and dynamic changes in the timestamp, the 32-byte perturbation factor is a completely random sequence and is updated every minute; The nonlinearity of the mutation rule: The two piecewise XOR operations further disrupt the bit distribution of the perturbation factor, causing the final 16-bit mutation count to completely deviate from the linear increasing pattern and exhibit random characteristics without any statistical regularity. Even if an attacker knows the linear sequence of the original connection event count, they cannot predict the subsequent values ​​of the mutated connection event count.

[0050] On the other hand, it is completely infeasible for attackers to brute-force the 16-bit mutated connection event count in real time: the exhaustive space of the 16-bit mutated connection event count is 65,536 possible values, while the connection event period of BLE communication is usually only tens of milliseconds (for example, iOS defaults to 30 ms, Android defaults to 48.75 ms, and the minimum connection event period is 7.5 ms). In order to achieve accurate frequency tracking, attackers must complete the entire process of "exhaustively enumerating the single mutated connection event count, substituting it into Channel Selection Algorithm 2 (CSA2) to calculate the next-hop channel, controlling the RF module to hop to that channel, and listening to verify whether it is the target channel" within a connection event period. According to the Bluetooth Special Interest Group (SIG) Bluetooth Low Energy (BLE) core specification definition and the technical parameters of mainstream Bluetooth Low Energy (BLE) RF modules, even with top-tier RF equipment, the minimum latency for a single exhaustive verification is 100μs (including 50μs for frequency hopping and 50μs for frame sensing). This latency parameter has clear and authoritative basis: Firstly, the 50μs frequency hopping is based on the official technical documentation (Nordic) of the nRF52840-DK RF module used in this embodiment. DevZone explicitly states that the core reserved time for RF link switching can be as low as hundreds of microseconds, and top-tier devices can achieve 50μs after optimization, consistent with the industry's typical switching latency range (40μs~80μs). Secondly, the basis for the 50μs frame listening detection is that the Bluetooth Special Interest Group (SIG) Bluetooth Low Energy (BLE) core specification defines the Bluetooth Low Energy (BLE) 1M physical layer preamble as 1 byte (8 bits) with a symbol rate of 1Msym / s. The preamble transmission alone requires 8μs. Adding the minimum time for receiver signal synchronization and phase calibration (30μs~40μs), the minimum detection latency is derived to be approximately 50μs. This result perfectly matches the minimum response latency (50μs level) for receiver signal detection officially marked by the nRF52840-DK module. Based on the above, completing a brute-force search of 65,536 values ​​would take 65,536 × 100 μs = 6.5536 seconds. Taking a 10ms connection event period as an example, this time is 655 times longer than a 10ms connection event period. In other words, before an attacker can complete a full brute-force search, the master and slave devices will have already completed 655 channel switches, rendering the brute-force attack completely ineffective. Furthermore, considering the dynamic update characteristic of minute-level timestamps, an attacker would need to restart a full brute-force search every minute, making it completely impractical from an engineering implementation perspective.

[0051] (5) Verification of defensive effectiveness An attack environment was built using Sniffle v1.11.0, a Bluetooth Low Energy (BLE) link layer relay attack tool publicly available from NCC Group. The attacker deployed two relay nodes, one near the master device and the other near the slave device, attempting to predict the communication channel between the master and slave devices and launch a relay attack by sniffing the access address, channel map, and native connection event counts. Figure 3 As shown in the attack scenarios and the defense scenarios of this invention, the final experimental verification results are as follows: 1) Attackers can only obtain the access address and channel map through wireless sniffing, but cannot obtain the 32-byte security key, so they cannot reproduce the generation process of the dynamic perturbation factor; 2) The mutated connection event count is a non-linear random sequence, completely deviating from the linear increasing pattern of the original Channel Selection Algorithm 2 (CSA2), which attackers cannot predict based on the original algorithm logic; 3) Attackers continued to try to track the frequency hopping sequence but were unable to locate the real-time communication channel between the master and slave devices, and were unable to capture any link layer data packets. The relay attack was completely blocked at the source. 4) The normal communication link between the master device and the slave device remained stable, and no problems such as packet loss or sudden increase in latency were found.

[0052] In summary, this embodiment, through engineering implementation on the Zephyr+NRF52840-DK platform, fully verifies the feasibility, low-overhead characteristics, and precise defense against Bluetooth Low Energy (BLE) link layer relay attacks disclosed by the NCC Group. Since this solution only optimizes the core input parameters of the Channel Selection Algorithm 2 (CSA2) in the BLE protocol stack controller layer without altering the protocol frame format or communication process, it can be directly ported to other BLE 5.x devices and corresponding BLE protocol stacks that support CSA2, possessing significant engineering and promotional value.

Claims

1. A method for blocking Bluetooth Low Energy link layer relay attacks, characterized in that, Includes the following steps: Step S1: Initialize the channel selection parameters of the Bluetooth Low Energy (BLE) master and slave devices, synchronously call Channel Selection Algorithm 2 (CSA2), and generate consistent channel identifier parameters and channel remapping table based on the access address and channel map negotiated by the master and slave devices. Step S2: The master and slave devices collect cryptographic perturbation input parameters; Step S3: The master device and the slave device combine the cryptographic perturbation input parameters collected in step S2, and perform hash operation using a secure hash function, using the hash result as a dynamic perturbation factor; Step S4: Based on the dynamic disturbance factor generated in step S3, generate a mutated connection event count and replace the original connection event count of Channel Selection Algorithm 2 (CSA2); Step S5: Based on the mutated connection event count generated in step S4, and combined with the channel identifier parameter generated in step S1, generate unpredictable pseudo-random numbers; Step S6: Based on the pseudo-random number generated in step S5, and combined with the channel map and remapping table in step S1, determine the communication channel of the next connection event that the attacker cannot predict, thereby blocking the attacker from carrying out a relay attack.

2. The method according to claim 1, characterized in that, Step S2 specifically involves: During the current connection event cycle, the master device and the slave device synchronously collect the security key, Channel Selection Algorithm 2 (CSA2) native connection event count, and salt value, which are known only to the master device and the slave device. The entire collection process is completed at the Bluetooth Low Energy (BLE) protocol stack controller layer.

3. The method according to claim 1, characterized in that, Step S3 specifically involves: The master and slave devices combine the cryptographic perturbation input parameters, perform hash operations using a keyed secure hash function, generate a fixed-length hash result, and use this hash result as a dynamic perturbation factor.

4. The method according to claim 1, characterized in that, Step S4 specifically involves: The dynamic perturbation factor is compressed to obtain a mutated connection event count with the same number of bits as the original connection event count. This mutated connection event count is used to replace the original connection event count in Channel Selection Algorithm 2 (CSA2), thereby optimizing the core input of CSA2.

5. The method according to claim 1, characterized in that, In step S5, the unpredictable pseudo-random number generation logic adopts the original pseudo-random number generation logic of Channel Selection Algorithm 2 (CSA2).

6. A low-power Bluetooth link layer relay attack blocking system, characterized in that, The method described in any one of claims 1 to 5 includes: The initialization module initializes the channel selection parameters for the Bluetooth Low Energy (BLE) master and slave devices, synchronously calls Channel Selection Algorithm 2 (CSA2), and generates consistent channel identifier parameters and channel remapping table based on the access address and channel map negotiated by the master and slave devices. The algorithm optimization module collects cryptographic perturbation input parameters from the master and slave devices, combines the cryptographic perturbation input parameters, performs hash operation using a secure hash function, uses the hash result as a dynamic perturbation factor, and finally generates a mutated connection event count based on the dynamic perturbation factor, replacing the native connection event count of Channel Selection Algorithm 2 (CSA2). The attack blocking module generates unpredictable pseudo-random numbers based on the mutated connection event count and the channel identifier parameter. By combining the pseudo-random numbers, the channel map, and the remapping table, it determines the communication channel of the next connection event that the attacker cannot predict, thereby blocking the attacker from carrying out relay attacks.

7. A low-power Bluetooth link layer relay attack blocking device, characterized in that, include: Memory: for storing a computer program that implements the low-power Bluetooth link layer relay attack blocking method as described in any one of claims 1 to 5; Processor: Used to implement the low-power Bluetooth link layer relay attack blocking method as described in any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the Bluetooth Low Energy Link Layer Relay Attack Blocking Method as described in any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the low-power Bluetooth link layer relay attack blocking method as described in any one of claims 1 to 5.

10. An application of a method for blocking low-power Bluetooth link layer relay attacks, characterized in that, The steps of the method as described in any one of claims 1 to 5 are used for master and slave devices of Bluetooth Low Energy (BLE) 5.x employing Channel Selection Algorithm 2 (CSA2).

Images