A low-power portable Bluetooth electronic lock unlocking control method

Abstract

The application discloses an unlocking control method of a low-power-consumption portable Bluetooth electronic lock and relates to the technical field of Internet of Things safety control. The electronic lock is in a deep sleep state by default, only a MEMS accelerometer interrupt circuit keeps running, a microcontroller is woken up after physical touch is detected, a lock body equipment identifier, a real-time clock time stamp and a cryptographic security random number are combined to perform message authentication code operation to generate a dynamic wake-up challenge code by using a shared root key, the challenge code is broadcast through Bluetooth, inertial measurement unit data is collected after the challenge code is received by a mobile phone terminal, 13-dimensional motion statistical features are extracted and combined with the challenge code to perform hash operation to obtain an intention feature hash, a session key is derived through a key derivation function and a single unlocking token is generated through message authentication code, time stamp freshness, random number deduplication, token consistency and intention feature non-zero four-step verification are sequentially performed at the lock end, and the lock is opened after all the verifications are passed.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security control technology, specifically to an unlocking control method for a low-power portable Bluetooth electronic lock. Background Technology

[0002] Bluetooth Low Energy (BLE) technology is widely used in portable electronic lock products due to its extremely low standby power consumption and mature ecosystem support. The typical unlocking process for existing BLE electronic locks is as follows: The electronic lock periodically sends BLE broadcasts, which the user's mobile application scans and initiates a connection. After pairing is completed through the BLE security management protocol, the mobile phone sends an unlock command encrypted or signed by a key derived from the long-term key to the lock. Once the lock verifies the command, it performs the unlocking action.

[0003] The aforementioned existing technical solutions have the following three fundamental defects: Firstly, all authentication information in existing solutions is transmitted via BLE wireless channels. The authentication logic implicitly assumes that the communication peer is the physical near end. However, a link-layer relay attacker can transparently forward BLE baseband data frames between two radio relay nodes, causing the electronic lock to mistakenly believe that a real user with a legitimate mobile phone is near the lock body. This allows the GATT application layer signature verification and message authentication code verification to pass, resulting in the lock being illegally opened without the user's knowledge. Existing BLE encryption mechanisms and software protection based on GATT response delays cannot effectively prevent this type of attack, and this defect cannot be patched by modifying the underlying BLE protocol.

[0004] Secondly, in order to reduce power consumption and shorten unlocking response time, existing portable electronic locks generally adopt a simplified authentication process during the disconnection and reconnection phase, identifying the other end solely based on the Bluetooth device address. Since the BLE protocol itself allows random addresses, attackers can forge the device address of a legitimate mobile phone to initiate a reconnection request. The lock will skip key verification and directly accept the connection, allowing attackers to send deceptive unlocking commands, i.e., the BLESA (Bluetooth Low Energy Spoofing Attack) vulnerability.

[0005] Third, existing defenses against relay attacks (such as continuously monitoring the received signal strength indicator and maintaining a long-term BLE connection to detect abnormal latency) all require the BLE RF module to continuously operate in a high-power receiving state, with a typical current of about 1 to 3 mA. For portable electronic locks that rely on button batteries or small lithium batteries for power, the power will be exhausted within a few days, which is fundamentally contradictory to the product form of portable low-power locks. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide a BLE electronic lock unlocking control method implemented in the pure application control layer that does not rely on radio frequency signal delay measurement, while meeting the ultra-low power consumption constraint of portable electronic locks, and effectively defending against link layer relay attacks, BLESA reconnection bypass attacks and DoS flooding attacks.

[0007] The technical solution of the present invention is as follows: A low-power portable Bluetooth electronic lock unlocking control method, applied to a system including an electronic lock and a user's mobile phone, includes the following steps: The electronic lock is in a deep sleep state, with the microcontroller and Bluetooth RF module both turned off, and only the interrupt detection circuit of the MEMS accelerometer running. When the MEMS accelerometer detects that the vibration acceleration of the lock body exceeds a preset threshold, it generates an interrupt signal to wake up the microcontroller. The microcontroller reads the real-time clock timestamp and the lock body device identifier, generates a cryptographically secure random number, and combines it with the shared root key to generate a dynamic wake-up challenge code through message authentication code calculation. It then turns on the Bluetooth RF module and encodes the dynamic wake-up challenge code and timestamp into a Bluetooth broadcast packet for transmission. The application on the user's mobile phone receives the Bluetooth broadcast packet, parses it to obtain the dynamic wake-up challenge code and timestamp, and after verifying the validity of the timestamp, it collects the three-axis acceleration and three-axis angular velocity data of the mobile phone's inertial measurement unit within a preset time window, extracts motion statistical features, and performs hash operation on the dynamic wake-up challenge code and timestamp to obtain the intent feature hash. Then, it derives a session key from the shared root key and Bluetooth session parameters, and uses the session key to perform message authentication code operation on the dynamic wake-up challenge code, intent feature hash, timestamp and mobile phone random number to generate a single unlock token. The user's mobile phone initiates a Bluetooth connection and performs a complete link-layer encrypted handshake. The single unlock token, intent feature hash, and mobile phone random number are reported to the electronic lock via GATT write operation. The electronic lock receives the above data and sequentially performs timestamp freshness verification, mobile phone random number deduplication verification, single unlock token consistency verification, and intent feature hash rationality verification. After all verifications are passed, the mechanical actuator is driven to complete the unlocking, and the mobile phone random number is recorded in the list of used random numbers. Then, the Bluetooth radio frequency is turned off and the microcontroller is returned to deep sleep state.

[0008] The beneficial effects of this invention are as follows: 1. This invention completely blocks link-layer relay attacks at the application layer. A single unlock token is simultaneously bound to a dynamic wake-up challenge code (which cannot be remotely forged) generated by the real physical touch spatiotemporal event sensed by the lock body's MEMS accelerometer and an intent feature hash collected in real time by the user's mobile phone inertial measurement unit (the relay node cannot obtain real mobile phone inertial measurement unit data). Even if the relay attacker forwards all the radio frequency data completely, he cannot construct a valid intent feature hash, and the token verification will inevitably fail.

[0009] 2. This invention eliminates the BLESA reconnection bypass vulnerability. Every BLE connection (including reconnection) forces a complete link-layer encrypted handshake. The session key is derived from the random number generated by each physical wake-up and the unique session key distribution value for each connection. The single unlock token contains a mobile terminal random number deduplication mechanism, so reconnection cannot skip the complete verification.

[0010] 3. This invention significantly reduces standby power consumption and naturally defends against DoS attacks. It uses a hierarchical control architecture that wakes up the BLE radio frequency by interrupting physical touch, allowing the electronic lock to remain in a deep sleep state with the radio frequency completely shut off when no one touches it. The deep sleep state current is only about 50 nanoamps (accelerometer interruption detection circuit), which is far lower than the standby current of the BLE radio frequency receiver. DoS flooding attacks cannot activate the BLE radio frequency module because they cannot simulate physical touch signals, thus naturally eliminating the battery drain caused by invalid radio frequency connections. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the overall system architecture of the present invention; Figure 2 This is a complete flowchart of the unlocking control method of the present invention; Figure 3 A sequence diagram for the timestamp synchronization sub-process; Figure 4 This is a schematic diagram for analyzing security attack countermeasures. Detailed Implementation

[0012] The following is in conjunction with the appendix Figure 1-4 The specific embodiments of the present invention will be further described below. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0013] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0014] System Composition The system of the present invention consists of two physical entities: a portable BLE electronic lock terminal and a user's smartphone terminal (application), which communicate with each other via a BLE wireless channel.

[0015] The electronic lock terminal includes: a MEMS accelerometer low-power wake-up module (standby current of approximately 50 nanoamps), a microcontroller (using a low-power BLE SoC), a BLE RF module (disabled by default), a real-time clock counter (timestamp source), a mechanical actuator (motor drive / lock cylinder), and a secure storage area (storing device identifiers and shared root keys).

[0016] The user's mobile phone includes: a mobile phone inertial measurement unit (integrating a three-axis accelerometer and a three-axis gyroscope), an unlock control application (responsible for motion intent feature extraction and token generation), a mobile phone BLE module, and a key storage area (storing the shared root key and session key).

[0017] Device pairing and key presetting When a user uses the electronic lock for the first time, the mobile application and the electronic lock are paired via the BLE security management protocol, and a 32-byte shared root key (hereinafter referred to as...) is generated through ECDH elliptic curve key negotiation. The accelerometer vibration detection threshold is securely stored separately in the phone key storage area and the lock security storage area. During the pairing phase, the threshold value is also checked. Write to the accelerometer configuration register (default value is 0.5g, where g is the gravitational acceleration of 9.8 m / s²). 2 (This can be adjusted by the application during the pairing phase). It is the highest-level long-term key in the system and is never transmitted in plaintext in any communication channel.

[0018] Deep sleep and physical wake-up The electronic lock is in a deep sleep state during normal standby: the microcontroller and BLE RF module are both turned off, and only the threshold detection interrupt circuit of the MEMS accelerometer remains active, with a standby current of about 50 nanoamps.

[0019] When the MEMS accelerometer detects that the vibration acceleration of the lock body along any axis exceeds a preset threshold... When the accelerometer interrupt pin outputs a high-level signal, it triggers the microcontroller to resume operation from deep sleep mode. After receiving the interrupt, the microcontroller first clears the accelerometer interrupt flag to prevent repeated triggering.

[0020] Dynamic wake-up challenge code generation After the microcontroller is woken up, it performs the following operations to generate a dynamic wake-up challenge code (hereinafter referred to as WC).

[0021] Read the current count value from the on-chip low-power real-time clock register, convert it to Unix timestamp format (seconds based on January 1, 1970, 00:00:00 UTC), and record it as... It is stored in the microcontroller's SRAM in 4-byte unsigned big-endian integer format. If the real-time clock becomes unreliable due to power failure, the timestamp synchronization sub-process is triggered (see below for details).

[0022] The on-chip hardware random number generator is invoked (if the chip does not have a hardware random number generator, a software cryptographically secure random number generator using a mixture of ADC noise sampling and clock jitter sampling is used) to generate a 16-byte cryptographically secure random number, denoted as . This ensures that the random numbers generated each time the device is woken up are unique.

[0023] Read the unique device identifier of the lock body from the secure storage area (denoted as...). (16 bytes in length, programmed at the factory and cannot be changed) and shared root key (32 bytes).

[0024] Will (16 bytes) (4 bytes) and (16 bytes) Concatenate sequentially to construct a 36-byte message body, Execute the key on the message body The operation is performed, and the first 16 bytes of the result (32 bytes) are used as the dynamic wake-up challenge code. : ; Among them, symbols This indicates a byte string concatenation operation performed in sequence. Indicated by For key, For the message The operation outputs a 32-byte digest, where [0:15] indicates that 16 bytes from offset 0 to 15 are retrieved. This is a unique device identifier for the lock body. For the lock's real-time clock timestamp, The cryptographically secure random number generated for this wake-up call. To share the root key.

[0025] A length of 16 bytes (128 bits) provides sufficient collision resistance for one-time challenge codes.

[0026] The design ensures that every It corresponds to only one real physical touch event, and is strongly bound to the time of the event and the identity of the lock body. It is unpredictable, non-reusable, and cannot be migrated across devices.

[0027] BLE Broadcast The microcontroller enables the BLE RF module, (16 bytes) (4 bytes) and (16 bytes under BLE 5.x extended broadcast, and truncated to 8 bytes under BLE 4.x broadcast to meet the 31-byte total length constraint) The custom manufacturer data field (Manufacturer Specific AD Type, type code 0xFF) is encoded into the BLE broadcast packet, starts the BLE broadcast and sets the broadcast timeout window (default 5 seconds). If no valid connection request is received from the mobile device within the timeout window, the BLE RF module is turned off and cleared. This causes the microcontroller to return to a deep sleep state. This mechanism also provides natural protection against DoS flood attacks because attackers cannot activate the BLE RF module without touching the lock body.

[0028] Mobile timestamp pre-verification The mobile application scans and receives BLE broadcast packets, then parses and extracts them. and ,calculate If the difference between the time and the local time on the mobile phone exceeds the preset effective deviation window (30 seconds by default), it is determined that it may be a replay attack, and the process is rejected and the user is notified of the abnormality; otherwise, the motion intent collection stage is entered.

[0029] Mobile device motion intent feature acquisition and intent feature hash calculation After the mobile application successfully parses the WC, it immediately registers the inertial measurement unit data listener with the operating system to sample the frequency. (Default 50 Hz) Synchronously collect three-axis acceleration data and three-axis gyroscope data from the mobile phone for a preset time window duration. (Default is 800 milliseconds, configurable range is 500 milliseconds to 1500 milliseconds). The start time of the acquisition window is defined as after the application successfully parses the broadcast packet. At that moment, the acquisition process is carried out in a background thread, without blocking the BLE connection preparation process of the main thread; After the data acquisition is completed, the raw data is organized into a triaxial acceleration sampling sequence. (Dimensions are N rows and 3 columns, unit is g, N is the total number of sampling points, N equals) and The product divided by 1000 (N is 40 under default parameters) and the triaxial angular velocity sampling sequence (Dimensions are N rows and 3 columns, unit is ° / s). If the actual number of sampling points returned by the operating system deviates slightly from N due to scheduling jitter, it will be aligned to N points by linear interpolation or truncation to ensure that the feature vector dimension is fixed.

[0030] The following statistical characteristics are calculated for the sampled sequence: Calculate the mean vector of the triaxial accelerations respectively. (3 floating-point numbers, the arithmetic mean of the acceleration sequences for each axis) and standard deviation vector (3 floating-point numbers, unbiased standard deviation of acceleration sequences for each axis, with N minus 1 as the denominator); Calculate the mean vector of the angular velocities of the three axes respectively. (3 floating-point numbers, the arithmetic mean of the angular velocity sequences of each axis) and standard deviation vector (3 floating-point numbers, unbiased standard deviation of the angular velocity sequence for each axis); Calculate the scalar energy of motion First, calculate the square of the Euclidean norm of the triaxial acceleration components at each sampling time, then take the arithmetic mean of the results over all time points. ; Where N is the total number of sampling points, , , The first The acceleration components (in g) at each sampling point along the X, Y, and Z axes are summed and their indices are calculated. Subtract 1 from 0 to N. It is a floating-point number, with the unit being g. 2 .

[0031] The motion feature vector is constructed by sequentially concatenating the above 13 floating-point numbers: the mean vector of triaxial acceleration (3 floating-point numbers), the standard deviation vector of triaxial acceleration (3 floating-point numbers), the mean vector of triaxial angular velocity (3 floating-point numbers), the standard deviation vector of triaxial angular velocity (3 floating-point numbers), and the scalar of kinetic energy (1 floating-point number). Each floating-point number is serialized according to IEEE 754 single-precision big-endian byte order, resulting in a 52-byte serialized byte string. .

[0032] Will (52 bytes) (16 bytes) and (4 bytes) are concatenated sequentially into a 72-byte message body. The message body is then subjected to a SHA-256 operation, and the first 16 bytes are taken as the intent feature hash (IH). ; in, Representation Standard Hash function, output 32 bytes. A serialized byte string of motion feature vectors. For dynamic wake-up challenge codes, For the lock-end timestamp, [0:15] indicates that 16 bytes from byte offset 0 to 15 are taken as the IH.

[0033] and The introduction of IH ensures a strong binding between IH and the current physical wake-up event. Even if the motion characteristics are exactly the same in two events, the IH of different wake-up events will differ due to [the specific physical wake-up event]. Different and completely different, eliminating the possibility of replay.

[0034] When a link-layer relay attacker forwards BLE data, they cannot obtain the motion data of the inertial measurement unit of the real mobile phone, and therefore cannot construct a valid IH, so token verification will inevitably fail.

[0035] Session key derivation and single unlock token generation The mobile application reads from the key store ,by For input key materials, Salt value, in byte string ASCII encoding (20 bytes) and Link layer session key distribution value (SKD) is concatenated into context information, through... Algorithm generates 32-byte session key : ; in, The standard is based on The key derivation function derives an output key material of length L bytes from the input key material IKM; For shared root key (input key material); The random number (salt value) generated in this round of wake-up; ( (session key distribution value) is During the link layer encrypted handshake process, a unique session identifier is generated by each of the master and slave ends contributing 8 bytes, totaling 16 bytes, which uniquely identifies the current encrypted session; 32 bytes is the output key length. If the operating system API does not directly expose the SKD, then the SKD is replaced by a 6-byte equivalent session identifier formed by concatenating the connection access address (4 bytes) at the time of BLE connection establishment and the connection event counter (2 bytes). Each BLE connection (including reconnections) uses this SKD. The difference between (regenerated upon each physical wake-up) and SKD (unique per connection) leads to completely different outcomes. This achieves independence of keys for each session, fundamentally eliminating the BLESA reconnection bypass vulnerability.

[0036] The mobile application generates 16-byte random numbers through the operating system's cryptographically secure random number generator interface. Stored in the application's memory, it will be cleared after this token is sent. (16 bytes) (16 bytes) (4 bytes) and Construct a 52-byte token message body by sequentially concatenating (16 bytes) ,by For key pairs implement The operation yields a 16-byte single-use unlock token. : ; in, Indicated by For key, For the message The operation (based on the Advanced Encryption Standard's Authentication Code (ACC) algorithm) outputs a 16-byte authentication tag. For session key, For dynamic wake-up challenge codes, For intent feature hashing, For the lock end timestamp, This is the random number generated on the mobile device.

[0037] BLE connection establishment and token reporting The mobile application initiates a BLE connection request, and both parties complete the BLE link layer connection establishment and a full cryptographic handshake (performed on every connection, without skipping), and then use GATT write operations to... (16 bytes) (16 bytes) and (16 bytes) A ​​total of 48 bytes are written to the lock end's predefined unlock token feature value (UUID is defined by the manufacturer) and sent to the lock end microcontroller as a single GATT write request.

[0038] Lock end four-step sequential verification The lock-end microcontroller receives 48 bytes of data via the GATT write callback and parses it to obtain... (Byte offset 0 to 15) (Byte offsets 16 to 31) and (Byte offset 32 ​​to 47), perform the following four verification steps in sequence. If any step fails, the process will immediately terminate and enter the security failure handling procedure (record security log, shut down BLE radio frequency, and return to deep sleep state): The first step is to verify the freshness of the timestamp: read the current real-time clock timestamp. Calculate the time difference equal minus ,like Exceeding the preset valid time window (Default time is 30 seconds) If the token expires, the verification will fail.

[0039] The second step, Deduplication verification: Check Does it already exist in the list of used random numbers maintained by the lock end (implemented with a circular buffer, storing the most recently preset number of used ones)? If it exists in the test case, it is considered a replay attack and the verification fails.

[0040] The third step is to verify the consistency of the single unlock token: the lock reads the token from the secure storage area. And generated in this round of awakening The SKD of the current connection is obtained from the BLE link layer, and independently derived using the same HKDF parameters as the mobile device. , derived independently As the key, with (Local data generated during this round of wake-up by the lock), received intent feature hash , (Local data of the lock end) and For the message, perform AES-CMAC operation to obtain the reference token. Using a constant-time comparison function (to prevent timing side-channel attacks) With received The comparison is performed byte by byte. If all 16 bytes are inconsistent, the verification fails.

[0041] Step 4, Intent Feature Hash Reasonableness Verification: Verify the received... The string must not be entirely zero bytes to prevent attackers from injecting zero-vector features to bypass intent verification. If a feature range strategy is configured on the lock end, further verification is possible. Whether the corresponding exercise energy is higher than the preset active exercise threshold is an optional configuration item.

[0042] After all four verification steps are successful, the microcontroller sends an unlocking pulse signal to the mechanical actuator drive circuit, driving the motor to rotate or the electromagnet to engage, completing the physical unlocking action. Write the used random number list, record the timestamp and related information of this successful unlocking to the security log storage area, then send the successful unlocking GATT notification to the mobile application, close the BLE connection, turn off the BLE radio frequency, and the microcontroller returns to deep sleep state.

[0043] Timestamp synchronization subprocess To ensure the accuracy of the lock's real-time clock (due to clock drift caused by button battery failure or prolonged disuse), the following lightweight time synchronization sub-process is executed after the BLEGATT connection is established and before the unlock token is verified: The mobile application obtains the current timestamp of the lock via GATT read operations. Calculate the local time of the mobile phone The difference ,like If the absolute value exceeds the preset synchronization threshold (60 seconds by default), the mobile application will send the current timestamp to the lock via a GATT write operation. The timestamp is generated by The derived private key is protected by an HMAC-SHA256 signature to prevent attackers from forging time synchronization messages to expand the time window and launch attacks. After the lock verifies the signature's validity, the real-time clock is updated. And return a confirmation of successful synchronization, if If the absolute value does not exceed the synchronization threshold, the synchronization step is skipped, and the normal unlocking process continues.

[0044] Alternative Implementation Method 1: Unlocking Control Method Based on Physical Button Trigger In a minimal hardware configuration scenario that does not use an accelerometer, a physical button can be set on the lock body. When the user actively presses the button, an interrupt signal is generated and directly connected to the external interrupt pin of the microcontroller, replacing the automatic vibration detection method of the MEMS accelerometer and triggering the microcontroller wake-up and dynamic wake-up challenge code generation process. The remaining processes for dynamic wake-up challenge code generation, intent feature hash calculation, token generation, and lock-end verification are exactly the same as those described above.

[0045] Since button operation itself represents a clear user intent, the starting point of the time window for collecting motion intent by the mobile inertial measurement unit can be changed to start immediately after the application receives the WC broadcast, while the rest of the algorithm logic remains unchanged.

[0046] This alternative is suitable for extremely low-cost padlock or cabinet lock products.

[0047] Alternative Implementation Method 2: Unlocking Control Method Based on Ultra-Wideband Ranging Trigger If hardware costs allow, ultra-wideband (UWB, IEEE 802.15.4z) radio frequency chips can be added to both the electronic lock and the mobile phone to obtain real centimeter-level physical distance information using UWB time-of-flight ranging capabilities. When UWB ranging confirms that the distance between the user's mobile phone and the lock body is less than a preset distance threshold, it replaces the physical touch judgment of the MEMS accelerometer as the first trigger condition to trigger the microcontroller to wake up. The generation of the dynamic wake-up challenge code WC has been changed to use the timestamp of the UWB ranging event and the ranging sequence number as the spatiotemporal anchor point, replacing the vibration timestamp of the accelerometer. The remaining token generation and verification processes are exactly the same as those described above and can be directly reused.

[0048] This alternative approach is suitable for high-end products with extremely high security requirements and relatively relaxed cost constraints.

[0049] Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of the present invention. Therefore, any modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the protection scope defined by the claims of the present invention.

Claims

1. A method for unlocking a low-power portable Bluetooth electronic lock, applied to a system including an electronic lock terminal and a user's mobile phone terminal, characterized in that, Includes the following steps: The electronic lock is in a deep sleep state, with the microcontroller and Bluetooth RF module both turned off. Only the interrupt detection circuit of the MEMS accelerometer remains operational. When the MEMS accelerometer detects that the vibration acceleration of the lock body exceeds a preset threshold, it generates an interrupt signal to wake up the microcontroller. The microcontroller reads the real-time clock timestamp and the lock body device identifier, generates a cryptographically secure random number, and combines it with the shared root key to generate a dynamic wake-up challenge code through message authentication code calculation. It then turns on the Bluetooth RF module and encodes the dynamic wake-up challenge code and timestamp into a Bluetooth broadcast packet for transmission. The user's mobile application receives the Bluetooth broadcast packet, parses it to obtain the dynamic wake-up challenge code and timestamp, verifies the validity of the timestamp, and collects the three-axis acceleration and three-axis angular velocity data of the mobile phone's inertial measurement unit within a preset time window. It extracts 13-dimensional motion statistical features, including the three-axis acceleration mean vector, the three-axis acceleration unbiased standard deviation vector, the three-axis angular velocity mean vector, the three-axis angular velocity unbiased standard deviation vector, and the motion energy scalar. The 13-dimensional motion statistical features are serialized according to IEEE 754 single-precision big-endian byte order, concatenated with the dynamic wake-up challenge code and timestamp, and hashed to obtain the intent feature hash. Then, a session key is derived from the shared root key and Bluetooth session parameters. The session key is used to perform message authentication code calculation on the dynamic wake-up challenge code, intent feature hash, timestamp, and mobile phone random number to generate a single unlock token. The user's mobile phone initiates a Bluetooth connection and performs a complete link-layer encrypted handshake. The single unlock token, intent feature hash, and mobile phone random number are reported to the electronic lock via GATT write operation. The electronic lock receives the above data and sequentially performs timestamp freshness verification, mobile phone random number deduplication verification, single unlock token consistency verification, and intent feature hash non-zero verification. After all verifications are passed, the mechanical actuator is driven to complete the unlocking, and the mobile phone random number is recorded in the list of used random numbers. Then, the Bluetooth radio frequency is turned off and the microcontroller is returned to deep sleep state.

2. The method according to claim 1, characterized in that, The method for generating the dynamic wake-up challenge code is as follows: the microcontroller reads the real-time clock to obtain the timestamp, calls the hardware random number generator to generate a random number, concatenates the lock device identifier, the timestamp and the random number in sequence to form a message body, performs HMAC-SHA256 operation on the message body using the shared root key as the key, and takes the first 16 bytes of the operation result as the dynamic wake-up challenge code.

3. The method according to claim 1, characterized in that, The method for calculating the intent feature hash is as follows: After receiving the Bluetooth broadcast packet and successfully parsing the dynamic wake-up challenge code, the three-axis acceleration sampling sequence and the three-axis angular velocity sampling sequence of the mobile phone are collected synchronously at a preset sampling frequency, and the collection is continued for a preset time window duration. The mean vector and unbiased standard deviation vector of the three-axis acceleration, the mean vector and unbiased standard deviation vector of the three-axis angular velocity, and the arithmetic mean of the sum of squares of the acceleration components of each axis at all sampling times are calculated as scalar values ​​of kinetic energy, totaling 13 floating-point numbers; The 13 floating-point numbers are serialized according to IEEE 754 single-precision big-endian byte order, and then concatenated with the dynamic wake-up challenge code and timestamp in sequence. The concatenation result is then subjected to SHA-256 operation, and the first 16 bytes are taken as the intent feature hash.

4. The method according to claim 1, characterized in that, The method for deriving the session key is as follows: Using a shared root key as input key material, a cryptographically secure random number as salt value, and Bluetooth link layer session key dispersion value as part of context information, a 32-byte session key is derived through the HKDF algorithm. Each Bluetooth connection (including reconnection) generates a unique session key due to the difference in the cryptographically secure random number and the session key distribution value; The method for generating the single-use unlock token is as follows: the dynamic wake-up challenge code, intent feature hash, timestamp, and mobile terminal random number are concatenated in sequence to form a token message body, and the AES-CMAC operation is performed on the token message body using the session key to output 16 bytes as the single-use unlock token.

5. The method according to claim 1, characterized in that, The four-step verification process of the electronic lock is as follows: The first step is to read the current real-time clock timestamp, calculate the difference between it and the broadcast timestamp, and if the difference exceeds the preset valid time window, the token is deemed to have expired and the verification fails. The second step is to check whether the random number on the mobile device already exists in the list of used random numbers. If it does, it is determined to be a replay attack and the verification fails. The third step is for the electronic lock to independently read the shared root key and the random number generated in this round of wake-up from the secure storage area, obtain the session key distribution value of the current Bluetooth connection, independently derive the session key according to the same parameters as the mobile phone, recalculate the reference token, and compare it byte by byte with the received single unlock token using a constant time comparison function. If they do not match, the verification fails. Step 4, Non-zero verification of intent feature hash: Verify that the received intent feature hash is not a string of all zero bytes. If it is a string of all zero bytes, it is determined to be an intent feature injection attack, and the verification fails. Unlocking can only proceed after all four steps are completed.

6. The method according to claim 1, characterized in that, After the electronic lock enables Bluetooth radio frequency broadcasting, it sets a broadcast timeout window. If no valid connection request is received from the user's mobile phone within the timeout window, the Bluetooth radio frequency module is turned off, the dynamic wake-up challenge code is cleared, and the microcontroller returns to deep sleep state.

7. The method according to claim 1, characterized in that, After the Bluetooth GATT connection is established but before the single unlock token verification, a timestamp synchronization sub-process is executed: the user's mobile phone reads the current timestamp of the electronic lock and compares it with the local time of the mobile phone. If the absolute value of the deviation exceeds the preset synchronization threshold, the mobile phone sends the current timestamp to the electronic lock. The timestamp is protected by an HMAC-SHA256 signature of a special key derived from the shared root key. After the electronic lock verifies the signature is valid, it updates the real-time clock.

8. The method according to claim 5, characterized in that, The list of used random numbers is implemented using a circular buffer, which cyclically stores a preset number of recently used mobile terminal random numbers. After each successful verification and unlocking, the random number generated on the mobile device is written into the list. When verification fails, the electronic lock records a security log, shuts down the Bluetooth radio frequency, and returns the microcontroller to a deep sleep state.

9. A method for unlocking a low-power portable Bluetooth electronic lock, applied to a system including an electronic lock terminal and a user mobile phone terminal, wherein the electronic lock terminal includes a microcontroller, a Bluetooth radio frequency module, a physical button interrupt circuit, a real-time clock, and a mechanical actuator, and the user mobile phone terminal includes a mobile phone inertial measurement unit and an unlocking control application, wherein the electronic lock terminal and the user mobile phone terminal communicate via a Bluetooth low-power wireless channel, and the electronic lock terminal and the user mobile phone terminal are pre-paired via a Bluetooth security management protocol and jointly hold a shared root key; Its features are, Includes the following steps: The electronic lock is in a deep sleep state, with the microcontroller and Bluetooth radio frequency module both turned off. Only the physical button interruption detection circuit on the lock body remains running. When the user presses the physical button, an interrupt signal is generated to wake up the microcontroller. After the microcontroller is woken up, it reads the real-time clock timestamp and the lock body device identifier, generates a cryptographically secure random number, and generates a dynamic wake-up challenge code by combining the shared root key and the message authentication code. It then turns on the Bluetooth radio frequency module and encodes the dynamic wake-up challenge code and timestamp into a Bluetooth broadcast packet for transmission. The application on the user's mobile phone receives the Bluetooth broadcast packet, parses it to obtain the dynamic wake-up challenge code and timestamp, verifies the validity of the timestamp, collects the three-axis acceleration and three-axis angular velocity data of the mobile phone's inertial measurement unit within a preset time window, extracts 13-dimensional motion statistical features, concatenates them with the dynamic wake-up challenge code and timestamp to perform a hash operation to obtain the intent feature hash, and then derives a session key from the shared root key and Bluetooth session parameters. The session key is used to perform a message authentication code operation on the dynamic wake-up challenge code, intent feature hash, timestamp and mobile phone random number to generate a single unlock token. The user's mobile phone initiates a Bluetooth connection and performs a complete link-layer encrypted handshake. The single unlock token, intent feature hash, and mobile phone random number are reported to the electronic lock via GATT write operation. The electronic lock receives the above data and sequentially performs timestamp freshness verification, mobile phone random number deduplication verification, single unlock token consistency verification, and intent feature hash non-zero verification. After all verifications are passed, the mechanical actuator is driven to complete the unlocking, and the mobile phone random number is recorded in the list of used random numbers. Then, the Bluetooth radio frequency is turned off and the microcontroller is returned to deep sleep state.

10. A method for unlocking a low-power portable Bluetooth electronic lock, applied to a system comprising an electronic lock terminal and a user mobile phone terminal, wherein the electronic lock terminal includes a microcontroller, a Bluetooth radio frequency module, an ultra-wideband radio frequency chip, a real-time clock, and a mechanical actuator, and the user mobile phone terminal includes a mobile phone inertial measurement unit, an ultra-wideband radio frequency chip, and an unlocking control application; the electronic lock terminal and the user mobile phone terminal communicate via a Bluetooth low-power wireless channel; the electronic lock terminal and the user mobile phone terminal are pre-paired via a Bluetooth security management protocol and share a root key. Its features are, Includes the following steps: The electronic lock is in a deep sleep state, with the microcontroller and Bluetooth RF module both turned off. Only the ultra-wideband RF chip maintains a low-power ranging and listening state. When the ultra-wideband time-of-flight ranging confirms that the physical distance between the user's mobile phone and the lock body is less than a preset distance threshold, a trigger signal is generated to wake up the microcontroller. After the microcontroller is woken up, it reads the lock body device identifier, and uses the timestamp and ranging sequence number of the ultra-wideband ranging event as the spatiotemporal anchor point to replace the real-time clock vibration timestamp, generates a cryptographically secure random number, and generates a dynamic wake-up challenge code by combining the shared root key and the message authentication code. It then turns on the Bluetooth radio frequency module and encodes the dynamic wake-up challenge code and timestamp into a Bluetooth broadcast packet for transmission. The application on the user's mobile phone receives the Bluetooth broadcast packet, parses it to obtain the dynamic wake-up challenge code and timestamp, verifies the validity of the timestamp, collects the three-axis acceleration and three-axis angular velocity data of the mobile phone's inertial measurement unit within a preset time window, extracts 13-dimensional motion statistical features, concatenates them with the dynamic wake-up challenge code and timestamp to perform a hash operation to obtain the intent feature hash, and then derives a session key from the shared root key and Bluetooth session parameters. The session key is used to perform a message authentication code operation on the dynamic wake-up challenge code, intent feature hash, timestamp and mobile phone random number to generate a single unlock token. The user's mobile phone initiates a Bluetooth connection and performs a complete link-layer encrypted handshake. The single unlock token, intent feature hash, and mobile phone random number are reported to the electronic lock via GATT write operation. The electronic lock receives the above data and sequentially performs timestamp freshness verification, mobile phone random number deduplication verification, single unlock token consistency verification, and intent feature hash non-zero verification. After all verifications are passed, the mechanical actuator is driven to complete the unlocking, and the mobile phone random number is recorded in the list of used random numbers. Then, the Bluetooth radio frequency is turned off and the microcontroller is returned to deep sleep state.

Images