Electric bicycle battery bluetooth broadcast data digital signature slice rotation, reorganization signature and frame counter anti-replay method

Abstract

The application relates to the technical field of electric bicycle battery safety communication, in particular to a digital signature fragmentation round of electric bicycle battery Bluetooth broadcast data, reorganization signature verification and a frame counter anti-replay method, which comprises the following steps: S100: receiving a Bluetooth broadcast packet sent by a battery end, and extracting device identification information, a health data field containing a complete frame counter, fragmentation control bytes and signature fragmentation data from the Bluetooth broadcast packet; S200: pre-checking the complete frame counter; taking the received complete frame counter as a frame counter reference value of a current period, adopting a broadcast channel public key bypass distribution strategy, and combining with extremely low signature operation frequency in a single period of the battery end, the application not only ensures the safety boundary of the device private key, but also takes into account the low-power-consumption, low-delay actual engineering landing demand of the receiving terminal for concurrent scanning and offline safety signature verification of multiple devices.

Description

Technical Field

[0001] This invention relates to the field of electric bicycle battery safety communication technology, specifically to a method for digital signature fragmented round-robin transmission, reassembly signature verification, and frame counter-based anti-replay of Bluetooth broadcast data from electric bicycle batteries. Background Technology

[0002] Electric bicycle batteries broadcasting health status data via Bluetooth Beacon is an effective means of monitoring battery safety. However, because the broadcast channel is an open, connectionless channel, any receiving device can receive the broadcast packets, which raises two core security issues:

[0003] Data forgery and tampering: Attackers can forge or tamper with health data in broadcast packets (such as fake voltage or temperature), causing the receiver to misjudge the data.

[0004] Replay attack: Attackers can record legitimate broadcast packets and replay them at any subsequent time, making the receiver mistakenly believe that the battery is currently in a normal state, thereby masking the real abnormality.

[0005] In existing technologies, some schemes use asymmetric signatures (such as ECDSA) to sign broadcast data, but the signature length is relatively large (usually 64 bytes), which cannot be placed in broadcast packets with limited space. Other schemes use symmetric key authentication, but face the problem of key distribution difficulties. In addition, against replay attacks, most schemes rely only on simple sequence numbers or timestamps, but the sequence number cycle is short, and the timestamp depends on precise clock synchronization, which is not effective in practical deployments. Summary of the Invention

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] This invention provides a method for digital signature fragmented round-robin transmission, reassembly signature verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries, including the following steps: S100: Receive Bluetooth broadcast packets sent by the battery end, and extract device identification information, a health data field containing a complete frame counter, fragmentation control bytes, and signature fragment data from them;

[0008] S200: Perform a pre-check on the complete frame counter: use the received complete frame counter as the frame counter reference value for the current period, compare it with the high water level of the corresponding device maintained locally, and if the preset forward jump condition is met, the pre-check is passed and the signature verification process is allowed; if it is determined to be replay data, it is discarded directly.

[0009] S300: Based on the device identification information and the fragment index in the fragment control byte, the received signature fragment data is cached and reassembled through round-by-round filling, and the complete digital signature is restored when all fragments are collected.

[0010] S400: Obtain the device public key corresponding to the battery terminal, and based on the digital signature and the reconstructed signature to be verified message, select a signature verification algorithm that matches the suite identifier in the fragmentation control byte to perform digital signature verification operation;

[0011] S500: After the digital signature verification is passed, a high-water mark final check is performed to confirm that the complete frame counter is within the valid forward window relative to the high-water mark. Then, the high-water mark is atomically updated to the value of the complete frame counter, and the health data in the Bluetooth broadcast packet is accepted.

[0012] Furthermore, the Bluetooth broadcast packet sent by the receiving battery terminal specifically includes:

[0013] Listen for Bluetooth broadcast packets sent by the battery via the Bluetooth Low Energy Unconnectable Broadcast Channel;

[0014] The receiving device supports one-to-many concurrent scanning and receiving of multiple batteries without needing to establish a Bluetooth connection with the battery.

[0015] The health data field containing the complete frame counter has the following data structure:

[0016] Within a data field space of a preset total byte length, the extracted complete frame counter is fixedly parsed at the last two consecutive bytes of the data field space using a mapping rule that prioritizes the most significant bit.

[0017] Furthermore, the maintenance mechanism for the frame counter is configured as follows:

[0018] A 16-bit unsigned integer is initialized inside the battery terminal as the frame counter, and its initial value is set to zero.

[0019] In response to the triggering of various Bluetooth broadcast events, the current count value of the frame counter is controlled to increase in increments of one step, and a reset is triggered after the count value reaches the maximum threshold.

[0020] The collected battery status data includes at least:

[0021] The microcontroller unit at the battery end acquires real-time voltage, signed current, temperature with bias coding, health percentage, number of charge / discharge cycles, and fault codes used to characterize abnormal states bit by bit.

[0022] Furthermore, the preset forward jump condition is specifically defined by the following mathematical judgment rule:

[0023] Calculate the difference between the frame counter reference value and the high water level line, and perform a modulo operation based on the maximum physical range span of the complete frame counter;

[0024] If the result of the modulo operation is greater than zero and less than or equal to the set legal forward window threshold, it is determined to be new data that meets the forward jump condition.

[0025] Furthermore, if the result of the modulo operation does not fall within the legal forward window threshold, the following anti-replay exception branch logic is executed:

[0026] If the difference is zero, or if the result of the modulo operation shows a rollback and the rollback span exceeds the preset rollback tolerance threshold, then it is determined that a substantial replay attack has been encountered, and the direct discard step is executed.

[0027] If the result of the modulo operation is a rollback and does not exceed the rollback tolerance threshold, it is determined that the counter at the battery end has been abnormally reset, triggering a resynchronization mechanism, and the currently received Bluetooth broadcast packet is temporarily marked as unverified, and the baseline is updated after subsequent continuous data packets are confirmed.

[0028] Furthermore, the collected status data is encoded into a health data field of a preset length, and the current frame counter is written as a reference value into a specified fixed byte of the health data field;

[0029] The collected status data is encoded into a health data field of a preset length, and a compact bit seamless splicing strategy is adopted, specifically including:

[0030] The extracted multi-dimensional battery state data is converted into unsigned or signed data types according to their respective set bit widths.

[0031] Discarding reserved bit stuffing, the converted state data are compactly assembled in the form of a continuous bit stream and compressed and encapsulated into a data block of fixed total byte length to form the health data field;

[0032] The encoding process for the state data also includes error prevention and fault tolerance mechanisms for unsupported items:

[0033] If it is detected that the cell type or control board of the battery terminal does not support the reporting of a certain status data, a preset sentinel value is filled into the bit segment allocated to that specific status data.

[0034] The sentinel value is configured as the maximum limit value that the corresponding bit segment can represent, in order to explicitly indicate to the receiving end the lack of corresponding state data.

[0035] Furthermore, the received signature fragment data is cached and reassembled across rounds using the following cache state management mechanism:

[0036] An independent reassembly cache is created for each identified device identifier, and the reassembly cache is divided into multiple consecutive slots corresponding to the shard index;

[0037] Within a preset repeated transmission window, the signature fragment data received in different rounds is dynamically filled into the corresponding empty slots according to its fragment index, so as to realize data filling across rounds.

[0038] In response to the detection of a substantial content change in the signature fragment data with the fragment index as the starting index, it is determined that a new signature cycle has started, triggering the clearing of the current reassembly cache and restarting the packet assembly process based on the current packet;

[0039] The process of reconstructing a complete digital signature by assembling all the complete fragments specifically includes:

[0040] Monitor the reorganized cache area, and when it is determined that all corresponding slots are filled with valid data, concatenate the data in each slot according to the natural order of the shard index.

[0041] Remove the zero-padding bits of a preset length from the last slot data, and extract the complete asymmetric digital signature composed of the first signature component and the second signature component.

[0042] Furthermore, the health data field, the device identification information of the battery terminal, and the algorithm suite identifier are assembled to form a message to be signed, and the device private key is used to perform an asymmetric signature operation on the message to be signed to generate a complete digital signature.

[0043] The process of forming the message to be signed employs a specific data frame concatenation structure, and its assembly format is as follows:

[0044] The preset exclusive header, the manufacturer's code, the material identifier representing the cell material properties, the device identification information, the health data field, and the algorithm suite identifier used to indicate the type of cryptographic algorithm are sequentially assembled to form a binary message sequence of fixed byte length;

[0045] The steps for generating a complete digital signature are as follows:

[0046] The algorithm suite identifier is parsed, and the algorithm is dynamically routed to the corresponding domestic cryptographic algorithm engine or elliptic curve digital signature algorithm engine based on the parsing result.

[0047] The device private key, which is pre-securely burned into the battery and prohibited from being exported, is invoked to perform a signature operation on the concatenated message to be signed using the corresponding engine, and outputs a complete digital signature containing a first signature component and a second signature component of a specific length.

[0048] Furthermore, the acquisition of the device public key corresponding to the battery terminal adopts a distribution mechanism without intra-channel key exchange, specifically including:

[0049] In the broadcast channel link that receives the Bluetooth broadcast packet, no symmetric session key or asymmetric key data is transmitted;

[0050] After extracting the device identification information, the receiving device sequentially queries the public key cache in its local memory, initiates a node query to the distributed hash network, calls the application programming interface of the centralized management platform, or parses the user's scanning command for the QR code physically attached to the battery side, in order to obtain the device public key through multiple bypass channels.

[0051] Furthermore, the execution of the high-water mark final check and atomic update of the high-water mark constitutes a dual-decision closed-loop mechanism to prevent concurrent state races, specifically configured as follows:

[0052] As a supplement to the pre-check before entering the signature verification process, after the time-consuming digital signature verification operation is completed, it is checked again whether the forward jump condition is still satisfied between the current complete frame counter and the locally maintained high watermark.

[0053] If it is detected that the high watermark has been updated by other concurrent legitimate data packets during the signature verification process, causing the current data to no longer meet the forward jump condition, or the digital signature verification fails, then the baseline update process is blocked and the Bluetooth broadcast packet is discarded.

[0054] Only when both the digital signature verification and the high-water mark final check are confirmed to be passed, the high-water mark is overwritten with the current value of the complete frame counter using an uninterrupted atomic operation.

[0055] Beneficial effects

[0056] This invention splits a complete high-strength asymmetric digital signature into multiple fixed-length fragments and sends them cyclically within a repeated round-robin window. While meeting the limited payload space constraints of Bluetooth single-connection-unreachable broadcast packets, this solution improves the packet assembly success rate of the receiving end in weak network environments by utilizing a cross-round gap-filling mechanism.

[0057] This invention explicitly embeds a complete 16-bit frame counter directly into the compact bit-encoded health data field, and introduces a forward jump pre-detection and atomic overwrite final detection mechanism based on high watermark difference modulo at the receiving end. This enables the system to accurately intercept multiple types of recording and replay attacks without establishing a Bluetooth connection and without relying on precise clock synchronization, and is compatible with handling non-malicious power-off reset states at the battery end.

[0058] This invention employs a public key bypass distribution strategy outside the broadcast channel, combined with the extremely low signature operation frequency within a single cycle at the battery end. This not only ensures the security boundary of the device's private key, but also takes into account the practical engineering requirements of low power consumption and low latency for receiving terminals to perform concurrent scanning and offline secure signature verification for multiple devices. Attached Figure Description

[0059] Figure 1 This is a flowchart illustrating the overall process of the method of the present invention.

[0060] Figure 2 This invention provides a flowchart of battery-side digital signature generation and sharding round-robin distribution.

[0061] Figure 3 The following is a flowchart of the receiving end fragmentation and reassembly, signature verification and replay prevention process provided by the present invention;

[0062] Figure 4 This is a schematic diagram of the high water level line anti-replay determination provided by the present invention;

[0063] Figure 5 This is a schematic diagram of the signature fragmentation round-robin timing provided by the present invention.

[0064] Figure 6 This is a schematic diagram of the device key system and public key distribution provided by the present invention. Detailed Implementation

[0065] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0066] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but includes other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0067] The present invention will now be described in further detail with reference to the accompanying drawings:

[0068] Example 1:

[0069] like Figure 1-6 As shown, the method for digital signature fragmentation, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries includes the following steps:

[0070] S100: Receives Bluetooth broadcast packets sent by the battery and extracts device identification information, a health data field containing a full frame counter, fragment control bytes, and signature fragment data from them;

[0071] S200: Pre-check the complete frame counter: Use the received complete frame counter as the frame counter reference value for the current period, compare it with the high water level of the corresponding device maintained locally, and if the preset forward jump condition is met, the pre-check is passed and the signature verification process is allowed; if it is determined to be replay data, it is discarded directly.

[0072] S300: Based on the device identification information and the fragment index in the fragment control byte, the received signature fragment data is cached and reassembled through round-by-round filling, and the complete digital signature is restored when all fragments are collected.

[0073] S400: Obtain the device public key corresponding to the battery terminal, and based on the digital signature and the reconstructed signature to be verified message, select the signature verification algorithm that matches the suite identifier in the fragment control byte to perform digital signature verification operation.

[0074] S500: After the digital signature verification is passed, a high-water mark final check is performed to confirm that the complete frame counter is within the valid forward window relative to the high-water mark. Then, the high-water mark is atomically updated to the value of the complete frame counter, and health data in the Bluetooth broadcast packet is accepted.

[0075] Furthermore, the specific implementation process of step S100 is as follows:

[0076] In the digital signature generation and fragmented round-robin method applied to battery-side devices, step S100 specifically embodies the maintenance logic of the frame counter by the microcontroller unit inside the battery side, as well as the data acquisition process of the multi-dimensional battery physical state at a specific time node.

[0077] In the frame counter maintenance mechanism, the battery-side microcontroller allocates a 16-bit unsigned integer storage space in its internal random access memory or dedicated register as the frame counter. Upon battery initialization and power-on or system reset, the microcontroller writes zero to the storage space, establishing the initial baseline for the frame counter. The battery-side Bluetooth Low Energy protocol stack periodically triggers broadcast events according to a preset underlying timer. Each time a broadcast event is sent, the Bluetooth underlying protocol stack sends a hardware interrupt signal to the microcontroller. Responding to the hardware interrupt signal, the microcontroller calls its internal adder to increment the frame counter's current count value by a fixed step size of one. After each addition operation, the microcontroller monitors the current count value using a comparator. When the current count value reaches the maximum threshold of 65535 and another interrupt signal is received, the microcontroller controls the arithmetic logic unit to cause an integer overflow, or forcibly overwrites the value in the storage space to zero using a conditional jump instruction, thus resetting the count and constructing a modulo-digital counter state machine that cyclically increments between 0 and 65535.

[0078] At the start of the current broadcast cycle, i.e., when a new digital signature cycle begins, the microcontroller initiates real-time acquisition of battery status data. This acquisition is jointly performed by the microcontroller's internal analog-to-digital converter and the external communication bus. Specifically:

[0079] The microcontroller unit (MCU) periodically quantizes the voltage at the output sampling points of the resistor divider circuit connected to the positive and negative terminals of the battery pack using an integrated multi-channel analog-to-digital converter (ADC), obtaining a digital voltage value reflecting the overall real-time voltage of the battery pack. The MCU acquires the signed current of the battery charging and discharging circuit via an instrumentation amplifier connected to the shunt in the battery circuit, or via a precision Hall current sensor. For data representation, the MCU's internal firmware stores the signed current value in two's complement form, defining the discharging state as positive and the charging state as negative. The MCU obtains the real-time analog temperature values ​​at multiple temperature measurement points of the battery cell using an external negative temperature coefficient thermistor array and a corresponding voltage divider sampling network, converting them into a digital temperature value with bias encoding using a conversion formula within the firmware. For battery-specific data such as manufacturing date, health percentage, and number of charge / discharge cycles, the MCU reads the corresponding historical static data and dynamic cumulative data from the electrically erasable programmable read-only memory (EROM) of the underlying fuel gauge chip or the battery management system protection board via the integrated circuit bus or controller area network (CLAN) bus. Meanwhile, the fault diagnosis state machine inside the microcontroller monitors the operating status of the battery system in real time. When abnormalities such as cell overvoltage, undervoltage, overtemperature, undertemperature, overcurrent, short circuit, or reduced insulation resistance occur, the diagnostic register inside the microcontroller will set the corresponding bit to form a fault code byte used to characterize the abnormal state bit by bit.

[0080] In the fragmentation and reassembly, signature verification, and frame counter anti-replay method applied to the receiving device, step S100 involves the receiving device concurrently listening to data packets of a specific format in an open wireless channel, and the structured unpacking and extraction process of message fields in memory space.

[0081] The main processor inside the receiving device (such as a law enforcement monitoring terminal or a smart handheld device) controls its integrated Bluetooth Low Energy (BLE) chip to start the radio frequency (RF) receiving front-end and configures the operating mode to passive listening mode. The RF front-end of the Bluetooth chip continuously performs frequency hopping scans on preset BLE non-connectable broadcast channels (such as physical channels 37, 38, and 39). In this state, the receiving device does not need to perform RF handshakes, pairing, or establish directional logical connections with any battery terminal in the air, but maintains a one-way listening state. When multiple battery terminals in the air simultaneously transmit RF signals in Beacon form, the Bluetooth chip of the receiving device restores the RF signals to the link layer data stream through the underlying demodulator, and writes the received 29-byte raw broadcast packet data stream into the physical memory buffer allocated by the main processor through the direct memory access controller, thereby realizing one-to-many concurrent scanning and reception of multiple battery terminals without establishing a Bluetooth connection.

[0082] The protocol parsing firmware module running inside the main processor performs structured decomposition and field extraction on the 29-byte raw broadcast packet stored in the physical memory buffer. The field extraction is strictly performed according to the preset byte offset for addressing and parsing.

[0083] The firmware module first extracts the first two bytes of the proprietary header data from the original broadcast packet, followed by the next two bytes of manufacturer code and one byte of material identifier. Then, the firmware module extracts the next six bytes and parses them into the battery's Media Access Control (MAC) address. The proprietary header, manufacturer code, material identifier, and MAC address are combined and defined in memory as device identification information uniquely identifying the sending source.

[0084] Subsequently, the firmware module locates bytes 11 to 21 of the original broadcast packet, continuously extracts these 11 bytes of data, and defines them as a whole as the health data field. When parsing the health data field, the firmware module, according to the most significant bit-first mapping rule, directly identifies the last two bytes of the health data field—bytes 20 and 21 of the entire packet—as the target field containing the complete frame counter. The firmware module left-shifts the data of byte 20 by 8 bits, and then performs a bitwise OR operation with the data of byte 21, thereby completely restoring a 16-bit unsigned integer in the main processor's register, which serves as the frame counter reference value used by the receiver to determine replay in the current cycle.

[0085] Finally, the firmware module locates byte 22 of the original broadcast packet, extracts this byte, and parses it into a fragmentation control byte. The high 4 bits of this byte are separated by the firmware module using a mask bitwise AND and shift operation, serving as a fragmentation index to identify the current fragmentation sequence position. The low 4 bits are separated as an algorithm suite identifier indicating the cipher suite type. Following this, the firmware module extracts the last six bytes (bytes 23 to 28) of the original broadcast packet and stores them as the current signature fragmentation data in a temporary variable. This completes the entire physical quantity extraction and protocol parsing process under step S100.

[0086] Furthermore, the specific implementation process of step S200 is as follows:

[0087] In the digital signature generation and fragmented round-robin method applied to battery-side devices, step S200 is specifically manifested as a sequence of compact bit seamless splicing and packing instruction writing executed by the battery-side microcontroller unit in memory.

[0088] The microcontroller allocates a contiguous 11-byte physical storage block in random access memory, defining it as the health data field. For the multi-dimensional state data acquired in step S100, the arithmetic logic unit within the microcontroller performs a series of shift and bitwise OR operations. Specifically, the microcontroller converts the acquired voltage quantization value into a 12-bit unsigned integer and stores it at the beginning of the block. Subsequently, the microcontroller converts the signed current quantization value into a 13-bit two's complement format and directly appends it compactly to the last bit of the voltage data using shift instructions, discarding all memory byte alignment boundary rules. For temperature data, the microcontroller adds a fixed bias constant of 40 to the actual temperature value, converts it into an 8-bit unsigned integer, and concatenates it. If the firmware detects that the current cell sensor hardware does not support temperature reporting, it stores the absolute value 255 as a sentinel value in the corresponding 8 bits. In turn, the microcontroller calls arithmetic instructions to convert the manufacturing date into a 10-bit format, the health percentage into a 7-bit format and configure the corresponding extreme value 127 as the sentinel value, the number of charge-discharge cycles into a 14-bit format and configure the extreme value 16383 as the sentinel value, and completely extract the 8-bit fault code representing the abnormal state bit by bit and push it into the data stream.

[0089] After completing the continuous encoding of the aforementioned 88 bits of health data without any reserved bits, the microcontroller unit calls the currently maintained full 16-bit frame counter reference value. According to the most significant bit-first mapping rule, the microcontroller unit issues an addressing write instruction to write the high 8 bits of the frame counter data to the absolute physical memory address of the 20th byte of the overall broadcast data packet structure, and at the same time writes the low 8 bits of the frame counter data to the absolute physical memory address of the 21st byte.

[0090] In the fragmentation and reassembly, signature verification, and frame counter anti-replay method applied to the receiving device, step S200 embodies the high-water mark anti-replay pre-detection arithmetic logic executed by the main processor based on the complete frame counter in memory.

[0091] When the main processor of the receiving device parses and extracts data, if it determines that the fragment index within the currently extracted fragment control byte is zero, it assigns the complete frame counter extracted from memory to the base value variable for the current signature period. Subsequently, the main processor retrieves the corresponding battery device high-water mark variable from the local non-volatile memory cache, calls the internal arithmetic logic unit to perform an unsigned integer subtraction operation, that is, subtracts the high-water mark variable from the base value variable, and executes a modulo instruction based on the maximum range value of 65536 on the output difference.

[0092] The main processor obtains the final calculation result of the modulo instruction and drives the conditional branch decision circuit to perform multi-path routing: When the modulo output result is strictly greater than zero and less than or equal to the preset forward jump valid window threshold of 32768, the main processor determines that the current data packet carries valid new data and controls the program execution pointer to jump to the subsequent reassembly and asymmetric signature verification physical memory address range. When the modulo output result is strictly equal to zero, or the modulo output result represents a negative backoff and the calculated actual backoff difference is greater than the preset 100 tolerance threshold, the main processor determines that the current wireless channel is encountering a same-value recording replay attack or a large-span replay attack. The main processor immediately triggers an abnormal interrupt instruction, clears the current receive buffer memory and discards the corresponding Bluetooth broadcast packet, and forcibly terminates all subsequent extremely time-consuming cryptographic asymmetric signature verification operations. When the modulo output result represents a negative backoff and the actual backoff difference is less than or equal to the preset 100 tolerance threshold, the main processor determines that the counter was not maliciously reset due to a hardware abnormality power failure reset of the battery-side microcontroller unit. The main processor then triggers the resynchronization protection mechanism, changes the memory status label of the data block corresponding to the current receive buffer to the unverified state, and suspends subsequent baseline update instructions, waiting for the frame counter of the confirmed data packet to show a stable increasing trend in multiple consecutive receive events before re-establishing a new high watermark baseline.

[0093] Furthermore, the specific implementation process of step S300 is as follows:

[0094] The microcontroller allocates a contiguous 23-byte physical memory space in random access memory. Using a direct memory access controller or assignment instruction, the microcontroller sequentially writes a 2-byte dedicated header, a 2-byte battery manufacturer code, and a 1-byte material identifier representing the cell material properties, all pre-stored in non-volatile memory, into the starting physical address range of the physical memory space. Next, the microcontroller appends a 6-byte media access control address read from read-only memory to the immediately following contiguous physical memory cell. Then, the microcontroller calls the 11-byte health data field, which has already undergone compact bit encoding in step S200, and pushes it into the sequence to be signed as a whole-block memory instruction copy. Finally, the microcontroller fills the physical address at the end of the sequence with a 1-byte algorithm suite identifier, thereby assembling a complete binary sequence of the message to be signed with a fixed length of 23 bytes in memory, strictly following the byte order.

[0095] After the message sequence to be signed is concatenated, the microcontroller unit parses the algorithm suite identifier bit at the end using a mask operation. The conditional jump instruction guides the execution pointer to the corresponding cryptographic engine based on the parsing result: if the identifier is hexadecimal 0x1, the national cryptographic SM2 algorithm engine is called; if the identifier is hexadecimal 0x2, the elliptic curve digital signature (ECDSA) algorithm engine is called.

[0096] The engine invokes the device's private key, pre-programmed into a one-time programmable hardware register and physically isolated from external read requests, to perform a high-strength digital signature operation on the sequence of messages to be signed in memory. The cryptographic engine outputs two signature components of a specific length, namely the r component and the s component. The microcontroller unit performs a concatenation operation on these two components, generating a complete digital signature of 64 bytes in total length in a separate memory buffer.

[0097] The main processor dynamically allocates a dedicated reassembly cache in the heap memory allocated by the operating system, based on the extracted media access control address. This reassembly cache is strictly divided into 11 consecutive memory addressing slots, each 6 bytes in length, with slot indices ranging from hexadecimal 0x0 to 0xA. A service thread running internally within the main processor monitors the fragmentation control bytes in the receive buffer queue in real time. When the main processor detects that the high 4 bits of the fragmentation control byte are 0x0, and the signature fragment data carried by the current packet has undergone a substantial byte change compared to the previously stored historical record, the main processor determines that a new signature transmission cycle has begun on the current radio broadcast channel. The main processor then triggers a physical memory zeroing instruction, resetting all bits in the reassembly cache to zero, and simultaneously anchoring the complete frame counter value extracted from the latest broadcast packet as the base value variable for the new cycle.

[0098] During the subsequent RF reception window, Bluetooth connectionless broadcasts may encounter unpredictable physical space RF fading or channel congestion in the same frequency band, leading to packet loss. The main processor precisely addresses and writes the extracted 6-byte signature fragment data into the corresponding empty memory slot based on the fragment index within each received broadcast packet. Given that the battery-side microcontroller will continuously send two identical fragment sequences within a recurring window of 22 broadcast events, if the main processor fails to collect all fragments in the first round, it retains the empty slot state. When a valid fragment with the corresponding index is received in the second round, it performs a cross-round data filling operation. Simultaneously, the main processor performs a memory consistency check before writing; if a byte conflict is detected in the same index slot, a security policy is triggered to execute a data discard instruction.

[0099] The loop state detection logic inside the main processor continuously traverses and reassembles the cache area. Once the logic determines that all 11 consecutive memory slots from 0x0 to 0xA have been completely filled with valid fragmented data, the main processor starts the memory address sequential splicing assembly instructions.

[0100] The main processor precisely locates the end of the 11th slot, truncates the 2 bytes of zero-value bits that were added to meet the fixed-length transmission format, and accurately extracts the 64-byte complete asymmetric digital signature composed of the r component and the s component from the contiguous memory.

[0101] Next, in another segment of working memory, the main processor reuses the exclusive header, manufacturer code, material identifier, media access control address, and algorithm suite identifier extracted in step S100, along with the health data field memory block anchored to the current cycle baseline value, and reassembles them in absolute physical byte order to form a 23-byte sequence of messages to be verified, which is then processed by the verification engine.

[0102] Furthermore, the specific implementation process of step S400 is as follows:

[0103] The microcontroller unit locates the starting physical address of the 64-byte complete digital signature generated in step S300 in the random access memory. The microcontroller unit invokes a loop fetch instruction to divide the 64 bytes of contiguous memory data into 11 independent data slices. The specific segmentation logic is as follows: the microcontroller unit, controlled by address offset, extracts the first 10 data slices in 6-byte increments; for the remaining 4 bytes of valid data, the microcontroller unit extracts them into the 11th data slice and appends 2 bytes of zero-value bits to its physical end for data alignment, ensuring that all 11 data slices have a strictly fixed length of 6 bytes.

[0104] After entering the Bluetooth broadcast packet assembly and transmission sequence, the microcontroller statically locks a snapshot of the memory block containing health data such as voltage, current, and temperature collected during the current signature cycle. During 22 consecutive broadcast events triggered by the underlying hardware timer, the microcontroller maintains the health data snapshot bytes in the memory block without any overwriting or refresh operations, only executing an event-by-event increment instruction on the frame counter memory addresses located at bytes 20 and 21 of the packet.

[0105] During the data link layer encapsulation phase of each single broadcast event, the microcontroller writes fragmented data to a fixed offset address in the preset 29-byte broadcast payload buffer. The microcontroller writes a 1-byte fragmentation control byte at a physical location with an absolute offset of 22 bytes. The high 4 bits of this byte are mapped from a loop variable to an incrementing hexadecimal fragmentation index from 0x0 to 0xA, while the low 4 bits are filled with the currently used algorithm suite identifier. Next, the microcontroller sequentially copies the 6-byte fragmented data block corresponding to the current fragmentation index to the physical range with offsets from 23 to 28 bytes. The microcontroller drives the Bluetooth Low Energy transceiver to transmit the assembled broadcast packet. The state machine within the microcontroller controls the fragmentation index to increment from 0x0 to 0xA, completing a full round of RF transmission of 11 events. After this, the control program execution pointer is called back, and another round of identical signed fragmented sequence transmission is executed in the same index order. This creates a repetitive transmission window on the timeline, continuously repeating for two rounds and covering a total of 22 broadcast events, achieving fading-resistant redundant transmission.

[0106] Before executing the signature verification logic, the main processor strictly isolates the Bluetooth radio frequency receiving link, and does not extract or receive any symmetric session key or asymmetric key data for decryption or signature verification from the wirelessly unconnectable broadcast channel. The main processor extracts the byte sequence of the Media Access Control address (i.e., MAC address) in the current broadcast packet to be verified as the retrieval key. The main processor first initiates a memory read request to retrieve the public key record matching the key in the locally pre-allocated public key cache hash table. When a cache miss interrupt occurs in the local memory, the main processor calls the network interface controller to encapsulate the retrieved key into a Hypertext Transfer Protocol request or a Remote Procedure Call request, and initiates a pull command to the application interface server of the cloud-centralized management platform, or initiates an addressing query to the distributed hash network node; the main processor can also respond to external hardware interrupts, call the image sensor module to perform optical character recognition decoding on the QR code pattern attached to the physical casing of the battery, and extract the public key string from it. The main processor loads the obtained device public key into the protected working memory area.

[0107] The main processor extracts the 1-byte fragment control byte stored in the register from the previous steps and executes bitwise AND mask instructions to separate the lower 4 bits of the algorithm suite identifier. The conditional branching circuit inside the main processor dynamically routes the execution path based on the separated identifier bits: if the identifier bits represent the SM2 national cryptographic algorithm, the main processor switches the execution environment context to the preset SM2 national cryptographic algorithm firmware library or calls a dedicated hardware encryption coprocessor; if the identifier bits represent the ECDSA algorithm, it switches to the elliptic curve digital signature algorithm operation unit.

[0108] The main processor sequentially passes three memory address pointers to the selected cryptographic operation unit or firmware library: the first pointer points to the starting memory address of the 23-byte message sequence to be verified reconstructed in step S300; the second pointer points to the starting memory address of the 64-byte complete digital signature restored through cross-round reconstruction; and the third pointer points to the device public key address loaded into the working memory above. The cryptographic operation unit performs asymmetric signature decoding and elliptic curve multiplication verification operations based on the passed parameters. Upon completion of the operation, the cryptographic operation unit outputs a Boolean result bit to the main processor's status register, explicitly providing feedback to the operating system on the final success or failure of the digital signature verification operation with a single bit of zero or one physical level.

[0109] Furthermore, the specific implementation process of step S500 is as follows:

[0110] After receiving the signature verification status bit from the cryptographic operation unit, the main processor initiates a final verification instruction stream to prevent concurrent state contention. Given the significant clock cycle delay in asymmetric signature verification operations, the main processor must execute a secondary verification closed-loop mechanism to prevent the high-water mark variable maintained in shared working memory from being preempted and updated by other parallel processing threads handling legitimate broadcast packets during this delay, which could lead to state logic corruption.

[0111] During the final inspection process, the main processor again sends an addressing and read request to the local non-volatile memory or shared system memory to obtain the latest high-water mark variable value. The main processor calls the internal arithmetic logic unit, reuses the subtraction and modulo execution architecture in step S200, calculates the difference between the current message complete frame counter base value previously resident in the register and the latest high-water mark variable just read, and strictly performs the modulo operation based on the maximum physical range span of 65536. The main processor uses the condition status register to determine whether the output result of the modulo operation still falls within the forward jump valid window threshold that is strictly greater than zero and less than or equal to 32768.

[0112] If the main processor's conditional branch circuit detects that the modulo operation output no longer satisfies the forward jump condition, or reads a verification status bit from the cryptographic operation unit indicating a verification failure, the main processor determines that the current data packet has encountered a state race failure on the timeline, or has been confirmed as maliciously forged or tampered with. The main processor then sends an interrupt signal to the operating system kernel, blocking any write / overwrite requests to the high-water mark variable's physical address at the hardware level, forcibly clearing the physical receive buffer occupied by the current broadcast packet using a memory release instruction, and recording a security alarm error code with the current timestamp and device identification information in the operating system's non-volatile log storage area, resolutely refraining from updating the high-water mark.

[0113] Conversely, if the main processor's conditional branch circuit confirms that the signature verification status bit is at a valid level representing success, and the second modulo result still fully satisfies the forward jump condition, the main processor officially enters the data trust and baseline state replacement process.

[0114] The main processor invokes synchronization primitives provided by the underlying hardware architecture, such as executing compare-and-swap machine language instructions or acquiring a bus-level exclusive spin mutex, to establish an absolutely exclusive memory access barrier that cannot be interrupted or suspended by external means. Within the strictly protected context of the aforementioned atomic operations, the main processor issues a memory overwrite instruction, directly hard-writing the complete frame counter value stored in the register into the absolute physical address block containing the high-water mark variable, completing the atomic replacement of the anti-replay baseline state. After the overwrite is complete, the main processor releases the hardware bus mutex to remove the memory access barrier and securely transfers and presents the starting address pointer of the memory region containing the rigorously verified health data snapshot block to the upper-layer monitoring application module for subsequent interface rendering and plaintext data storage.

[0115] like Figure 2 As shown, the battery terminal executes the following process according to the broadcast event cycle (approximately 1 time / second):

[0116] Step ①: The battery MCU collects real-time data on the current battery status, including voltage, current, temperature, state of health (SOH), cycle count, and fault codes.

[0117] Step 2: According to the compact bit encoding method of the present invention, the above health data is encoded into an 11-byte (88-bit) health data field D, and the complete 16-bit frame counter FC is written into the 20th to 21st bytes first according to the MSB (byte 20 = FC[15:8], byte 21 = FC[7:0]).

[0118] Step 3: Construct the reception signature message M_sig = exclusive header (2 bytes) || battery manufacturer code (2 bytes) || cell material (1 byte) || MAC address (6 bytes) || health data field D (11 bytes) || kit identifier (1 byte), totaling 23 bytes.

[0119] Step 4: The battery uses the device private key Pri_D to calculate the digital signature of M_sig (kit identifier 0x1 is SM2, 0x2 is ECDSA), and obtains a 64-byte signature value S=r||s.

[0120] Step 5: Divide the 64-byte signature S into 11 fragments of 6 bytes each, with the 11th fragment containing 4 bytes of valid data and padded with 2 bytes of 0 at the end.

[0121] Step 6: Each broadcast event is encapsulated into a 29-byte broadcast packet: dedicated header (2 bytes) || battery manufacturer code (2 bytes) || cell material (1 byte) || MAC address (6 bytes) || health data field D (11 bytes) || fragment field (7 bytes), where the first byte of the fragment field has the high 4 bits as the fragment index (0x0~0xA), the low 4 bits as the kit identifier, and the last 6 bytes as the fragment signature data.

[0122] Step 7: Send all 11 shards sequentially in 11 consecutive broadcast events according to the shard index, forming a signature cycle; after the shard sequence of the same signature is continuously sent in rounds for 2 rounds (a total of 22 broadcast events, called the repeated round window), a new signature cycle is started with the latest data snapshot; during the round, the health data field remains unchanged, only the FC field is incremented by 1 with each broadcast event, and the content of the same index shard is the same in each round.

[0123] Step 8: Send via Bluetooth BLE non-connectable broadcast channel; the frame counter covered by the signature is always the periodic reference value FC_epoch, so the same signature can be verified in each broadcast event within the window.

[0124] like Figure 3 As shown, after receiving the broadcast packet, the receiving end (law enforcement APP) performs the following steps:

[0125] Step 1: Receive 29-byte broadcast packets via Bluetooth BLE scanning.

[0126] Step 2: Extract the MAC address, health data field D (bytes 20-21 of which are the complete 16-bit frame counter FC), fragmentation control bytes (the high 4 bits are the fragmentation index and the low 4 bits are the package identifier) ​​and 6 bytes of signature fragmentation data from the broadcast packet.

[0127] Step 3: Frame counter pre-check. Using the FC field in the broadcast packet at fragment index 0 as FC_epoch, compare it with the local high watermark fc_hwm: if the forward distance is within (0, 32768], pass the pre-check; if the value is the same or there is a significant backtrack, it is considered a replay and discarded directly; if the backtrack is less than 100, trigger resynchronization and mark it as "unverified". The first device encountered has no fc_hwm, so establish a baseline first.

[0128] Step 4: Fragment Reassembly. Received fragments are cached according to their fragment indices; changes in the fragment data at fragment index 0 indicate the start of a new signature cycle, the reassembly buffer is reset, and the FC field of that packet is used as the new FC_epoch; after collecting all 11 fragments from 0x0 to 0xA, a 64-byte signature S=r||s is reassembled; the same signature is sent repeatedly in two rounds, and fragments from different rounds can be combined complementaryly according to their indices.

[0129] Step 5: Reconstruct the signature to be verified message. Replace the frame counter field in bytes 20-21 of the health data field D with the FC_epoch determined in step 3 to obtain the health data field snapshot D′; assemble the signature to be verified message M_sig = exclusive packet header || battery manufacturer code || cell material || MAC address || health data field snapshot D′ || package identifier, totaling 23 bytes. Since the frame counter covered by the battery-side signature is always the periodic base value FC_epoch, and the health data field, except for the frame counter field, retains the snapshot of the signature time within the same signature period, the signature to be verified message reconstructed with FC_epoch can be verified against any signature reconstructed from any broadcast event within the repeated round-robin window.

[0130] Step 6: Query the local cache, DHT network, and centralized API in sequence according to the MAC address to obtain the device public key Pub_D.

[0131] Step 7: Select the algorithm by the suite identifier and use Pub_D to perform SM2 or ECDSA verification on (M_sig,S).

[0132] Step 8: After the signature verification is successful, a high-water mark final check is performed. If the FC is confirmed to still be within the valid forward window, then fc_hwm=FC is updated and data is accepted. If the signature verification fails or the final check fails, it is determined to be forged, tampered with, or replayed. The packet is discarded and fc_hwm is not updated.

[0133] like Figure 4 As shown, the receiver maintains a high-water mark fc_hwm (the frame counter value of the most recently verified data packet) for each known device. When a new broadcast packet is received, the FC field in the broadcast packet with fragment index 0 is used as the baseline value FC_epoch for this period. (FC_epoch-fc_hwm)mod65536 is calculated: if the result falls within the range of (0,32768), it is considered valid forward new data; if the result is 0, it is considered a replay of the same value; if the result is greater than 32768, it is processed as a rollback. If the rollback difference does not exceed 100, resynchronization is triggered and marked as "unverified"; if it exceeds 100, it is considered a replay attack.

[0134] Specifically, assuming fc_hwm=0x1000, the valid forward window is (0x1001, 0x9000). If FC_epoch=0x1234, the difference 0x234 is within the window, the pre-check passes and the signature verification proceeds; if FC_epoch=0x1000 or FC_epoch=0x0F00 (backoff 256), the former is a replay with the same value and is directly rejected, and the latter is backoffed by more than 100 and is judged as an attack; if FC_epoch=0x0FD0 (backoff 48), it is judged as an abnormal reset of the counter and the resynchronization process begins.

[0135] After successful signature verification and final confirmation, the receiving end updates fc_hwm to the FC value of the packet. The first device encountered has no history, establishes a baseline with the FC of the first successfully verified packet and marks it as "unverified". After receiving an increasing number of packets with successful signature verification, it is marked as "verified".

[0136] In addition, if no broadcast is received from a device for more than 7 days, fc_hwm is reset according to the time decay rule and the baseline is re-established; the decay determination must be based on a trusted time source (such as NTP or platform server time) and must not rely on the device's local clock.

[0137] like Figure 5 As shown, after the battery generates a 64-byte signature, it is divided into 11 fragments (index 0x0~0xA) and sent sequentially in index order in 11 consecutive broadcast events; the same signature is repeated twice, for a total of 22 broadcast events, forming a repeated broadcast window.

[0138] During the broadcast cycle, the health data field D remains a snapshot of the signature time, while only the FC field is incremented by 1 for each broadcast event. The FC covered by the signature is always the periodic baseline value FC_epoch, so the same signature can be verified in each broadcast event. The fragment field for each event is 7 bytes, where the high 4 bits of byte 22 are the fragment index, the low 4 bits are the suite identifier, and bytes 23-28 are the 6 bytes of signature data for that fragment.

[0139] The receiving end caches each fragment according to its MAC address and fragment index. Once all 11 fragments are collected, the 64-byte signature S=r||s can be reassembled. Since the same signature round is sent in two rounds, fragments received in different rounds can be combined by complementary indexes: for example, if fragment 0x3 is lost in the first round, fragment 0x3 from the second round can be used to fill the gap, thus tolerating broadcast packet loss within a single round.

[0140] After the repeated transmission window ends, the battery updates its health data, re-signs the new M_sig using the device private key Pri_D, and enters the next transmission cycle.

[0141] Based on a broadcast frequency of approximately 1 time per second, a repetitive round-robin window is about 22 seconds. In extreme cases, the receiver can collect all the fragments after waiting for a maximum of 2 rounds. The dual-round-robin mechanism significantly improves the reassembly success rate when the single-round packet loss rate is 10%, meeting the reliable transmission requirements under open channels.

[0142] like Figure 6 As shown, the platform securely stores the root key K_root. During production, the device private key Pri_D is derived from K_root via HKDF and burned into the battery. The private key does not leave the device. The device public key Pub_D corresponding to Pri_D is distributed externally through the DHT distributed network, centralized API, and device QR code.

[0143] When the receiving end (APP) verifies the signature, it does not need to store or transmit any symmetric key. It only needs to obtain the corresponding public key according to the MAC address in the broadcast packet: firstly, it queries the local public key cache. If it does not match, it queries the DHT network and the centralized API in turn, or prompts the user to scan the device QR code to obtain it.

[0144] After obtaining Pub_D, the receiving end selects the signature verification algorithm (0x1 for SM2, 0x2 for ECDSA) according to the suite identifier in the fragmentation control byte, and performs signature verification operation on the reassembled (M_sig,S).

[0145] The security of this key system relies on the confidentiality of the device private key Pri_D and the platform root key K_root; the public distribution of the public key does not affect security, and any receiving end holding the public key can independently verify the signature, naturally supporting one-to-many concurrent reception and offline signature verification.

[0146] Example 2:

[0147] Normal visa verification scenario:

[0148] Assuming the battery terminal has the following characteristics: MAC address = AA:BB:CC:DD:EE:FF, battery manufacturer code = 0x0001, cell material = 0x03 (ternary lithium), kit identifier = 0x1 (SM2), and signature time frame counter base value FC_epoch = 0x1234. Health data is collected and encoded, resulting in the health data field D = 1E0F1F2088F7C1F4001234 (corresponding to voltage 48.0V, current -45.0A (charging status), temperature 25℃, manufacturing date December 2025, SOH 95%, 500 cycles, no faults, FC_epoch = 0x1234).

[0149] The battery-generated reception signature message M_sig=EEBB000103AABBCCDDEEFF1E0F1F2088F7C1F400123401 (23 bytes in total) is signed using the device private key Pri_D with SM2 signature, resulting in S=r||s, where r=BA80D90259A5D46D67E5550BB7EB455D6EBEFA62722745DB8EE2E56BF5E775E9 and s=9F6216C8C895877F2EAF9915E1AB010711F8924E2338DB5EF9662747D797B34A. S is divided into 11 pieces of 6 bytes each (with 2 bytes of 0 padded to the last piece), and is transmitted in two rounds within a repeated transmission window. During this period, the health data field remains a snapshot, and only the FC field is incremented by 1 with each broadcast event.

[0150] The receiving app locally caches the battery's fc_hwm=0x1000. After collecting 11 recombined S chips, the pre-check (0x1234-0x1000)=0x234, which falls within the valid window of (0,32768); according to the kit identifier 0x1, SM2 signature verification is performed using Pub_D and passes; after final verification, fc_hwm=0x1234 is updated, the data is marked as trustworthy and accepted.

[0151] Replay attack detection:

[0152] An attacker records a legitimate broadcast packet (FC_epoch=0x1234) from Example 1 and replays it after the receiver has updated fc_hwm to 0x1234. The receiver reads FC=0x1234, and the difference between FC_epoch and fc_hwm is 0, directly determining it as a replay with the same value, and discards it without signature verification. If the attacker replays an earlier packet (e.g., FC=0x1100), the backtracking difference 0x134=308>100, which is also determined to be a replay attack. Therefore, even if the signature of the replay packet itself is legitimate, it cannot pass the high-water mark for verification, thus achieving reliable replay protection.

[0153] Forward jump and counter error reset handling:

[0154] The user returned to the electric vehicle several hours after leaving, during which time the app received no broadcasts. When the broadcast was received again, FC_epoch=0x1C20, local fc_hwm=0x1000, and the forward difference 0xC20=3104, falling within the valid window of (0,32768]. After successful signature verification, fc_hwm=0x1C20 was directly updated without any candidate search or time estimation. If a battery's counter malfunctions due to batch write rollback after a power outage, the new cycle FC_epoch=0x1BB0, and the rollback difference relative to fc_hwm=0x1C00 is 0x50= If 80 ≤ 100, a resynchronization process is triggered: the data for this period is marked "unverified," fc_hwm remains unchanged and does not degrade; after the battery-side frame counter continues to increment and the FC_epoch of subsequent periods falls back into the forward window, normal judgment and baseline update resume. If fc_hwm has incremented to near the loopback boundary (e.g., 0xFFF8), when a new period of FC_epoch = 0x0010 is received, the forward difference modulo 65536 is 24, falling within the valid forward window, and the baseline is updated normally after the signature verification is successful.

[0155] First encounter with baseline establishment and time decay:

[0156] For batteries never encountered before, the app has no fc_hwm record. Upon receiving a broadcast, the app first performs fragmentation and reassembly, and then verifies the signature. If the signature verification is successful, the app establishes a baseline fc_hwm based on the FC of that packet and marks the data as "unverified." After receiving several (e.g., 3) consecutive packets with increasing FCs and successful signature verification, the data is marked as "verified." During the initial encounter, the public key is usually not cached. The app queries the Pub_D via the DHT network or a centralized API using the MAC address, or prompts the user to scan the device's QR code to obtain it. In addition, if no broadcast from a device is received for more than 7 days, the app performs a decay reset on the fc_hwm based on a trusted time source (NTP or platform server time, not relying on the local clock). When the broadcast from that device is received again, the baseline is rebuilt according to the initial encounter process.

[0157] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for digital signature fragmented round-robin transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries, characterized in that: Includes the following steps: S100: Receives Bluetooth broadcast packets sent by the battery and extracts device identification information, a health data field containing a full frame counter, fragment control bytes, and signature fragment data from them; S200: Perform a pre-check on the complete frame counter: use the received complete frame counter as the frame counter reference value for the current period, compare it with the high water level of the corresponding device maintained locally, and if the preset forward jump condition is met, the pre-check is passed and the signature verification process is allowed; if it is determined to be replay data, it is discarded directly. S300: Based on the device identification information and the fragment index in the fragment control byte, the received signature fragment data is cached and reassembled through round-by-round filling, and the complete digital signature is restored when all fragments are collected. S400: Obtain the device public key corresponding to the battery terminal, and based on the digital signature and the reconstructed signature to be verified message, select a signature verification algorithm that matches the suite identifier in the fragmentation control byte to perform digital signature verification operation; S500: After the digital signature verification is passed, a high-water mark final check is performed to confirm that the complete frame counter is within the valid forward window relative to the high-water mark. Then, the high-water mark is atomically updated to the value of the complete frame counter, and the health data in the Bluetooth broadcast packet is accepted.

2. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 1, characterized in that, The Bluetooth broadcast packet sent by the receiving battery terminal specifically includes: Listen for Bluetooth broadcast packets sent by the battery via the Bluetooth Low Energy Unconnectable Broadcast Channel; The receiving device supports one-to-many concurrent scanning and receiving of multiple batteries without needing to establish a Bluetooth connection with the battery. The health data field containing the complete frame counter has the following data structure: Within a data field space of a preset total byte length, the extracted complete frame counter is fixedly parsed at the last two consecutive bytes of the data field space using a mapping rule that prioritizes the most significant bit.

3. The method for digital signature fragmentation, round-robin transmission, reassembly, signature verification, and frame counter anti-replay of Bluetooth broadcast data for electric bicycle batteries according to claim 2, wherein the maintenance mechanism for the frame counter is configured as follows: A 16-bit unsigned integer is initialized inside the battery terminal as the frame counter, and its initial value is set to zero. In response to the triggering of various Bluetooth broadcast events, the current count value of the frame counter is controlled to increase in increments of one step, and a reset is triggered after the count value reaches the maximum threshold. The collected battery status data includes at least: The microcontroller unit at the battery end acquires real-time voltage, signed current, temperature with bias coding, health percentage, number of charge / discharge cycles, and fault codes used to characterize abnormal states bit by bit.

4. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 3, characterized in that, The preset forward jump condition is specifically defined by the following mathematical determination rules: Calculate the difference between the frame counter reference value and the high water level line, and perform a modulo operation based on the maximum physical range span of the complete frame counter; If the result of the modulo operation is greater than zero and less than or equal to the set legal forward window threshold, it is determined to be new data that meets the forward jump condition.

5. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 4, characterized in that, If the result of the modulo operation does not fall within the legal forward window threshold, then the following anti-replay exception branch logic is executed: If the difference is zero, or if the result of the modulo operation shows a rollback and the rollback span exceeds the preset rollback tolerance threshold, then it is determined that a substantial replay attack has been encountered, and the direct discard step is executed. If the result of the modulo operation is a rollback and does not exceed the rollback tolerance threshold, it is determined that the counter at the battery end has been abnormally reset, triggering a resynchronization mechanism, and the currently received Bluetooth broadcast packet is temporarily marked as unverified, and the baseline is updated after subsequent continuous data packets are confirmed.

6. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 5, characterized in that, The collected status data is encoded into a health data field of a preset length, and the current frame counter is written into a specified fixed byte of the health data field as a reference value. The collected status data is encoded into a health data field of a preset length, and a compact bit seamless splicing strategy is adopted, specifically including: The extracted multi-dimensional battery state data is converted into unsigned or signed data types according to their respective set bit widths. Discarding reserved bit stuffing, the converted state data are compactly assembled in the form of a continuous bit stream and compressed and encapsulated into a data block of fixed total byte length to form the health data field; The encoding process for the state data also includes error prevention and fault tolerance mechanisms for unsupported items: If it is detected that the cell type or control board of the battery terminal does not support the reporting of a certain status data, a preset sentinel value is filled into the bit segment allocated to that specific status data. The sentinel value is configured as the maximum limit value that the corresponding bit segment can represent, in order to explicitly indicate to the receiving end the lack of corresponding state data.

7. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from an electric bicycle battery according to claim 6, characterized in that, The received signature fragment data is cached and reassembled across rounds using the following cache state management mechanism: An independent reassembly cache is created for each identified device identifier, and the reassembly cache is divided into multiple consecutive slots corresponding to the shard index; Within a preset repeated transmission window, the signature fragment data received in different rounds is dynamically filled into the corresponding empty slots according to its fragment index, so as to realize data filling across rounds. In response to the detection of a substantial content change in the signature fragment data with the fragment index as the starting index, it is determined that a new signature cycle has started, triggering the clearing of the current reassembly cache and restarting the packet assembly process based on the current packet; The process of reconstructing a complete digital signature by assembling all the complete fragments specifically includes: Monitor the reorganized cache area, and when it is determined that all corresponding slots are filled with valid data, concatenate the data in each slot according to the natural order of the shard index. Remove the zero-padding bits of a preset length from the last slot data, and extract the complete asymmetric digital signature composed of the first signature component and the second signature component.

8. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 7, characterized in that, The health data field, the device identification information of the battery terminal, and the algorithm suite identifier are assembled to form a message to be signed, and the device private key is used to perform an asymmetric signature operation on the message to be signed to generate a complete digital signature. The process of forming the message to be signed employs a specific data frame concatenation structure, and its assembly format is as follows: The preset exclusive header, the manufacturer's code, the material identifier representing the cell material properties, the device identification information, the health data field, and the algorithm suite identifier used to indicate the type of cryptographic algorithm are sequentially assembled to form a binary message sequence of fixed byte length; The steps for generating a complete digital signature are as follows: The algorithm suite identifier is parsed, and the algorithm is dynamically routed to the corresponding domestic cryptographic algorithm engine or elliptic curve digital signature algorithm engine based on the parsing result. The device private key, which is pre-securely burned into the battery and prohibited from being exported, is invoked to perform a signature operation on the concatenated message to be signed using the corresponding engine, and outputs a complete digital signature containing a first signature component and a second signature component of a specific length.

9. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from electric bicycle batteries according to claim 8, characterized in that, The process of obtaining the device public key corresponding to the battery terminal employs a distribution mechanism without intra-channel key exchange, specifically including: In the broadcast channel link that receives the Bluetooth broadcast packet, no symmetric session key or asymmetric key data is transmitted; After extracting the device identification information, the receiving device sequentially queries the public key cache in its local memory, initiates a node query to the distributed hash network, calls the application programming interface of the centralized management platform, or parses the user's scanning command for the QR code physically attached to the battery side, in order to obtain the device public key through multiple bypass channels.

10. The method for digital signature fragmented transmission, reassembly verification, and frame counter anti-replay of Bluetooth broadcast data from an electric bicycle battery according to claim 9, characterized in that, The execution of the high-water mark final check and atomic update constitutes a dual-determination closed-loop mechanism to prevent concurrent state competition, specifically configured as follows: As a supplement to the pre-check before entering the signature verification process, after the time-consuming digital signature verification operation is completed, it is checked again whether the forward jump condition is still satisfied between the current complete frame counter and the locally maintained high watermark. If it is detected that the high watermark has been updated by other concurrent legitimate data packets during the signature verification process, causing the current data to no longer meet the forward jump condition, or the digital signature verification fails, then the baseline update process is blocked and the Bluetooth broadcast packet is discarded. Only when both the digital signature verification and the high-water mark final check are confirmed to be passed, the high-water mark is overwritten with the current value of the complete frame counter using an uninterrupted atomic operation.

Images