A bluetooth identity-oriented end-to-end secure communication method and system

Abstract

The application discloses a kind of end-to-end security communication methods and systems for bluetooth identity identification, method includes the following steps: S1, initialization stage, using LE Secure Connections protocol establishes trusted key negotiation channel, and core key is derived;S2, daily identification stage, through dynamic resolvable private address RPA and encryption verification, prevent replay attack and relay attack;S3, storage stage, utilize hardware encryption engine and partition protection, ensure the physical security of key.The application uses the above-mentioned end-to-end security communication method and system for bluetooth identity identification, realizes end-to-end security coverage, from the initial pairing of mobile phone and equipment, to the dynamic verification of daily communication, to the hardware level protection of core key, forms whole-link closed-loop security system, effectively resists various malicious attacks, adapts high-risk scene such as finance, security, improves the security and reliability of bluetooth identity identification.

Description

Technical Field

[0001] This invention relates to the field of IoT near-field communication security technology, and in particular to an end-to-end secure communication method and system for Bluetooth identity recognition. Background Technology

[0002] As IoT technology continues to penetrate key sectors such as finance and security, the security challenges faced by near-field identification (NFC) systems are becoming increasingly severe. Current mainstream NFC solutions generally suffer from three prominent problems: cloud-based key storage is vulnerable to theft; static MAC addresses can be forged and cloned; and software-encrypted keys are at risk of leakage after the device is physically disassembled. These security vulnerabilities make traditional solutions insufficient to meet the high-security requirements of scenarios such as financial devices and smart locks.

[0003] Traditional Bluetooth identity verification technology has three major bottlenecks: The initialization phase lacks protection against man-in-the-middle attacks. Traditional BLE pairing uses the "Just Works" mode, and the key exchange process lacks a third-party verification step. Attackers can intercept and tamper with the keys, which can lead to subsequent communication being monitored.

[0004] Most devices use a fixed Bluetooth MAC address as their identifier. These static MAC addresses are easily obtained by attackers using sniffing tools. Once the address is obtained, attackers can forge devices and bypass the authentication process.

[0005] The security of key storage is also insufficient. Keys are usually stored in Flash in plaintext or software-encrypted form. When the device is physically disassembled, attackers can directly read the key through a programmer. This defect brings a fundamental security risk.

[0006] Existing improvement solutions still have significant security flaws and cannot fundamentally solve the aforementioned bottlenecks: for example, traditional BLE pairing solutions lack protection against man-in-the-middle attacks and have low key derivation strength, making them difficult to resist various malicious attacks; ordinary AES encrypted storage solutions rely on software algorithms to process keys, which are easily reverse-engineered and cannot guarantee key storage security; static address recognition solutions can be easily cloned and lack dynamic verification mechanisms, allowing attackers to easily bypass identity verification by forging addresses.

[0007] Furthermore, key application scenarios such as financial self-service terminals, smart door locks, medical equipment, and industrial control equipment all place high demands on the security capabilities of devices. These scenarios either need to prevent relay attacks and ensure the privacy and security of transaction or patient data, or they need to resist physical disassembly, device forgery, and replay attacks. Traditional Bluetooth identity recognition solutions, due to inherent defects such as static addresses and software encryption, are difficult to adapt to these high-security scenarios, further highlighting the necessity and urgency of developing new secure communication mechanisms.

[0008] Therefore, a security mechanism that can cover the entire link is urgently needed to solve the above dilemma. Summary of the Invention

[0009] The purpose of this invention is to provide an end-to-end secure communication method and system for Bluetooth identity recognition, constructing a full-link security mechanism covering key generation, identity verification, and storage management, and meeting the protection needs of high-security scenarios such as financial devices and smart locks through hardware-level encryption and dynamic verification technologies.

[0010] To achieve the above objectives, the present invention provides an end-to-end secure communication method for Bluetooth identity recognition, comprising the following steps: S1. Initialization phase: A trusted key negotiation channel is established using the LE Secure Connections protocol to derive the core key; S2, Daily Identification Phase: Replay attacks and relay attacks are prevented through Dynamically Resolvable Private Address RPA and encrypted verification. S3, the storage stage, utilizes a hardware encryption engine and partition protection to ensure the physical security of the keys.

[0011] Preferably, S1 is as follows: The LE Secure Connections pairing protocol is used for secure key exchange between devices. A shared secret is generated by exchanging public keys using the NIST P-256 Elliptic Curve ECDH algorithm. After the public key exchange, the Passkey Entry verification mechanism is used to defend against man-in-the-middle attacks. The core keys, including the link key LTK, identity resolution key IRK, and connection signature key CSRK, are generated using the key derivation algorithm HMAC-SHA256. The derived identity resolution key IRK is then encrypted and stored in a hardware secure area.

[0012] Preferably, in S1, the process of generating the shared key using the ECDH algorithm is as follows: Sa1: The device and mobile phone generate public and private key pairs based on NIST P-256 elliptic curves. The NIST P-256 elliptic curve expression is as follows: ; The private key is generated using the STM32's built-in true random number generator TRNG, and the public key is generated by the private key and the curve base point. The formula is obtained by performing scalar multiplication: ; In the formula, For private key, Public key coordinates; Sa2: The device and mobile phone exchange public keys through the manufacturer-defined data unit AD Type 0xFF of the Bluetooth broadcast packet. A 2-byte length field and a 1-byte checksum are attached before the public key is transmitted. After the receiver verifies the public key, it is stored in the RAM temporary buffer. Sa3, the device uses its own private key. With mobile phone public key Computational shared secrets : ; Private key for performing symmetric operations on mobile device With device public key Computational shared secrets Both parties will receive the same shared secret value; Sa4, the shared secret, is derived into session key material through the HMAC-SHA256 algorithm. The input parameters include the shared secret, Bluetooth device address BD_ADDR, pairing random number Rand, and salt value Salt. Finally, the link key LTK, identity resolution key IRK, and connection signature key CSRK are generated.

[0013] Preferably, in S1, the verification process of the Passkey Entry verification mechanism is as follows: Sb1. After the device enters pairing mode, a 6-digit random number Passkey is generated by the True Random Number Generator (TRNG) and displayed on the LCD screen or announced by a buzzer. Sb2. The user enters the Passkey displayed on the device in the Bluetooth pairing interface on the mobile phone. The mobile phone converts the Passkey into 16-byte Little-Endian format and then performs an XOR operation with the confirmation value derived from the shared secret. Sb3. Both parties calculate HMAC-SHA256 respectively. The device sends the calculation result to the mobile phone through the 0xFFFF feature value of GATT service. The mobile phone verifies whether the local calculation result is consistent with the received value. If they are consistent, the MITM protection is completed.

[0014] Preferably, S2 is as follows: Authentication is achieved based on the dynamic generation rules of resolvable private address RPA and the AES-CMAC algorithm for password message authentication. The resolvable private address RPA is generated by the identity resolution key IRK and the random number PRAND through AES-CMAC operation and is updated periodically. The identification terminal extracts the random number PRAND from the broadcast packet, reconstructs the RPA by combining it with the locally stored IRK, and performs AES-CMAC verification. At the same time, it integrates timestamp and Received Signal Strength Indicator (RSSI) monitoring to prevent replay attacks and relay attacks.

[0015] Preferably, in S2, the dynamic generation process of the resolvable private address RPA is as follows: Sc1: The mobile app generates a 24-bit random number using the system's random number generator, which is updated every 15 minutes and the timestamp counter is reset synchronously. Sc2. Using the identity resolution key IRK as the key, perform the AES-CMAC algorithm on the random number PRAND, and take the lower 24 bits of the result as the hash value; Sc3. Set the highest bit of the Hash value to 1 to indicate a private address and the second highest bit to 0 to indicate a resolvable type. Concatenate this with the random number PRAND to form a 6-byte Bluetooth RPA address.

[0016] Preferably, in S2, the process of dynamically generating a resolvable private address RPA using the AES-CMAC algorithm is as follows: Sd1, Calculate the subkey : AES-128(IRK,0x0000000000000000000000000000000000000000), if subkey If the highest bit is 0, then the subkey 1; otherwise, subkey XOR 0x87; Sd2. Divide the input random data PRAND and timestamp into 16-byte blocks. If the last block is less than 16 bytes long, pad it with 0x80 followed by zeros until it reaches 16 bytes. If the data length is 16 bytes, then the last block is combined with the subkey. XOR; Sd3, with an initial vector of 0x0000000000000000000000000000000000, is used. Each data block is XORed with the result of the previous round and then encrypted using AES. The last block is processed using a subkey. Substitute subkey ; Sd4. The lower 24 bits of the encryption result are embedded as a hash value into the RPA address, and the remaining bytes are used for integrity verification of the GATT data frame.

[0017] Preferably, S3 is as follows: The device uses a hardware encryption engine to encrypt the identity resolution key IRK generated during the initialization phase in AES-128-CBC mode, and divides the storage medium into a boot area, application area, encryption area, configuration area and log area. The encrypted IRK ciphertext, the randomly generated initialization vector, and the integrity check value are stored in the encrypted area; combined with a hardware anti-tampering mechanism, key leakage caused by physical disassembly is prevented. The specific process by which the device encrypts the identity resolution key IRK generated during the initialization phase in AES-128-CBC mode using a hardware encryption engine is as follows: S31. Before the device leaves the factory, a 128-bit root key is written to it via an offline programmer and stored in the STM32's system memory. S32. Calculate a temporary key by combining the identity resolution key IRK generated during the initialization phase with the device UID (unique device identifier) ​​using HMAC-SHA256. ; S33, Temporary Key Encryption is performed using AES-128-CBC mode. The initialization vector IV is generated by TRNG and stored together with the ciphertext. The encryption process is completed through the STM32's CRYP hardware accelerator, and the encryption result is stored in the Flash encryption area.

[0018] Preferably, the boot area address range is 0x08000000~0x08001FFF, which is used to store secure boot code, with a read protection level of 1, i.e., read is prohibited; The application area address range is 0x08002000~0x08017FFF, which is used to store the Bluetooth protocol stack and application. The protection level is read protection level 0, which means that reading is allowed, while write protection is enabled and erasure is prohibited. The encrypted area has an address range of 0x08018000~0x08018FFF and is used to store the encrypted core key. The protection level is read protection level 2, which means encrypted reading and write protection is enabled, with writing only allowed in initialization mode. The configuration area address range is 0x08019000~0x0801DFFF, used to store device parameters and pairing information. The protection level is read protection level 0, and write protection is enabled. Password verification is required to write to it. The log area address range is 0x0801E000~0x0801FFFF, used to store security event logs, including verification failure records. It adopts a circular write mode, and when the storage is full, it overflows and overwrites the old logs.

[0019] The present invention also provides an end-to-end secure communication system for Bluetooth identity recognition, including a main control unit, a Bluetooth communication unit, a key derivation module and a physical security module; The main control unit has a built-in AES-128 accelerator, TRNG module and anti-tampering monitoring unit, supports elliptic curve cryptography ECC operation, and the main control unit uses an MCU with an integrated hardware encryption engine, specifically an STM32L051 series microcontroller. The Bluetooth communication unit supports extended broadcast packets, adaptive frequency hopping (AFH), and LE Secure Connections pairing, with broadcast channels covering channels 37 / 38 / 39; The key derivation module generates a 32-bit random number based on the device's unique identifier (UID) and TRNG, and then uses the HMAC-based key derivation function HKDF to generate an IRK encryption key, ensuring the uniqueness of the key for each device. The physical security module includes a hardware debugging interface fuse circuit, which fuses the debugging interface in normal mode; and an integrated voltage and temperature monitoring unit, which triggers a key erasure command in case of an anomaly.

[0020] Therefore, the present invention employs the above-mentioned end-to-end secure communication method and system for Bluetooth identity recognition, and the beneficial effects are as follows: (1) This invention effectively solves the problem of lack of protection against man-in-the-middle attacks in traditional pairing schemes. By adopting the LESecure Connections pairing protocol and ECDH key exchange and Passkey verification mechanism, the security of key negotiation in the initialization stage is enhanced, the risk of key interception and tampering is eliminated, and the absolute security of Bluetooth near-field identity recognition initial pairing is guaranteed, which is suitable for the initialization requirements of high-security scenarios.

[0021] (2) This invention breaks through the bottleneck of static MAC addresses being easy to forge and clone. It adopts dynamic resolvable private addresses combined with the AES-CMAC algorithm, and realizes real-time verification through dynamic combination of hash value and random number. It effectively prevents device forgery and replay attacks, improves the protection reliability of daily identity recognition, and meets the daily verification needs of key scenarios.

[0022] (3) This invention solves the problem of insufficient security of traditional key storage. It stores the identity resolution key through a hardware encryption engine, avoiding the key from being exposed in plaintext or software encryption form. Even if the device is physically disassembled, the original key cannot be read, thus eliminating key leakage from the root and building a core defense line for full-link security protection.

[0023] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0024] Figure 1This is an overall flowchart of an embodiment of an end-to-end secure communication method for Bluetooth identity recognition according to the present invention; Figure 2 This is an overall system block diagram of an embodiment of an end-to-end secure communication system for Bluetooth identity recognition according to the present invention. Detailed Implementation

[0025] The technical solution of the present invention will be further described below with reference to the accompanying drawings and embodiments.

[0026] Unless otherwise defined, the technical or scientific terms used in this invention shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains.

[0027] The end-to-end secure communication mechanism of this invention achieves end-to-end security through a three-layer progressive protection architecture: During the initialization phase, a trusted key negotiation channel is established using the LE Secure Connections protocol; during the routine identification phase, dynamic addresses and encrypted verification prevent identity forgery; and during the storage phase, a hardware encryption engine and partition protection ensure the physical security of the keys. The overall technical solution is based on the Bluetooth BLE 5.0 protocol stack and implements deep security customization from the protocol layer to the application layer on the STM32 MCU hardware platform.

[0028] like Figure 1 As shown, an end-to-end secure communication method for Bluetooth identity recognition includes the following steps: S1. In the initialization phase, a trusted key negotiation channel is established using the LE Secure Connections protocol to derive the core key, specifically as follows: The initialization phase is fundamental for establishing trust relationships between devices and requires the completion of three main tasks: key negotiation, authentication, and secure storage. This phase employs the LE Secure Connections pairing protocol for secure key exchange between devices. A shared secret is generated through public key exchange using the NIST P-256 Elliptic Curve ECDH algorithm. Following the public key exchange, a Passkey Entry verification mechanism is used to defend against man-in-the-middle attacks.

[0029] The system generates core keys, including a link key (LTK), a 128-bit identity resolution key (IRK), and a connection signature key (CSRK), using the HMAC-SHA256 key derivation algorithm. The derived identity resolution key (IRK) is then encrypted and stored in a secure hardware area. During initialization, the system sets up an independent state machine. Pairing mode is triggered by a hardware pin level (e.g., pressing and holding the configuration button for 5 seconds). If pairing is not completed within the timeout period, the system automatically exits and clears temporary data.

[0030] The process of generating a shared key using the ECDH algorithm of this invention is as follows: Sa1, Public-Private Key Pair Generation: The device and mobile phone generate public-private key pairs based on NIST P-256 elliptic curves. The NIST P-256 elliptic curve expression is as follows: .

[0031] The private key is generated using the STM32's built-in true random number generator TRNG, and the public key is generated by the private key and the curve base point. The formula is obtained by performing scalar multiplication: ; In the formula, For private key, These are the public key coordinates.

[0032] Sa2, Public Key Exchange: The device and the mobile phone exchange public keys through the manufacturer-defined data unit ADType 0xFF of the Bluetooth broadcast packet. A 2-byte length field and a 1-byte checksum are attached before the public key is transmitted. After the receiver verifies the public key, it is stored in the RAM temporary buffer.

[0033] Sa3, Shared Secret Computation: The device uses its own private key. With mobile phone public key Computational shared secrets : .

[0034] Private key for performing symmetric operations on mobile device With device public key Computational shared secrets According to the mathematical properties of the ECDH algorithm, both parties will obtain the same shared secret value.

[0035] Sa4, Key Derivation: The shared secret is derived into session key material using the HMAC-SHA256 algorithm. Input parameters include the shared secret, Bluetooth device address BD_ADDR, pairing random number Rand, and salt value Salt. This ultimately generates the link key LTK, identity resolution key IRK, and connection signature key CSRK. The derivation formula is as follows: Key Material= HMAC-SHA256(S,"le-sc-confirmation"||Rand||Salt||BD_ADDR_1||BD_ADDR_2); LTK=Key Material[0..15]; IRK=Key Material[16..31]; CSRK=Key Material[32..47].

[0036] The security strength compared to traditional Bluetooth pairing SSP is shown in Table 1: Table 1 Comparison of Safety Strength

[0037] The main control unit of this invention uses an STM32L051 series MCU and has a built-in hardware elliptic curve cryptography (ECC) accelerator, which can control the exchange time of 256-bit ECDH key within 80ms, which is about 15 times faster than pure software implementation, and avoids pairing timeouts caused by computation delay.

[0038] The verification process of the Passkey Entry verification mechanism of this invention is as follows: Sb1, Random Number Generation: After the device enters pairing mode, it generates a 6-bit random number Passkey (range 100000-999999) through a true random number generator TRNG, and displays it on the LCD screen or announces it through a buzzer. It supports custom frequency encoding, such as a long beep representing 1 and a short beep representing 0.

[0039] Sb2, User Input: The user inputs the Passkey displayed on the device in the Bluetooth pairing interface on the mobile phone. The mobile phone converts the Passkey into 16-byte Little-Endian format and then performs an XOR operation with the confirmation value derived from the shared secret.

[0040] Sb3, Hash Comparison: Both parties calculate HMAC-SHA256 (Key = Shared Secret, Data = Passkey||Rand1||Rand2). The device sends the calculation result to the mobile device via the 0xFFFF signature value of the GATT service. The mobile device verifies whether the local calculation result matches the received value. If they match, MITM protection is complete. When Passkey verification fails, the system does not directly indicate the error type, but returns a general failure message after a random delay of 1-3 seconds to prevent attackers from guessing the verification process through time difference analysis.

[0041] Enhanced security measures: To improve user experience, the device has a reserved hardware voice broadcast interface. If connected to an ISD1820 recording module, it will automatically play the voice prompt "Please enter the pairing code XXXXXX on your phone" after generating the Passkey, supporting both Chinese and English. For embedded devices without a display screen, Passkey information can be transmitted via LED flashing counts, with each flash representing a digit, and a 2-second interval between groups, or via buzzer frequency (high frequency for 1-5, low frequency for 6-0), ensuring secure and reliable human-machine interaction during initialization.

[0042] S2, the routine identification phase, is the system's high-frequency operating mode. It requires rapid identity verification while maintaining low power consumption. This is achieved through Dynamically Resolvable Private Address (RPA) and encrypted verification to prevent replay and relay attacks. Specifically: Authentication is achieved based on the dynamic generation rules of resolvable private address RPA and the AES-CMAC algorithm for password message authentication. The resolvable private address RPA is generated by the identity resolution key IRK and the random number PRAND through AES-CMAC operation and is updated periodically. The identification terminal extracts the random number PRAND from the broadcast packet, reconstructs the RPA by combining it with the locally stored IRK, and performs AES-CMAC verification. At the same time, it integrates timestamp and Received Signal Strength Indicator (RSSI) monitoring to prevent replay attacks and relay attacks.

[0043] In this phase, Dynamically Resolvable Private Addresses (RPA) are used instead of static MAC addresses. The mobile device periodically generates RPA addresses containing random numbers and hash values, and the device verifies the address's legitimacy by calculating the AES-CMAC value using the stored IRK. To prevent replay attacks, a 4-byte timestamp (with second-level precision) is embedded in the broadcast packet, and the device maintains a time window (±3 seconds); verification is rejected if the time exceeds this range. The communication process employs an adaptive scanning strategy, increasing the scanning frequency to 100ms / time during peak device activity periods (e.g., 8:00-22:00 for smart door locks) and reducing it to 500ms / time during sleep periods to save power.

[0044] The resolvable private address RPA of this invention is composed of a 24-bit random number (PRAND) and a 24-bit hash value (Hash), conforming to the definition in Bluetooth Core Specification v5.0 Vol 6 Part B Section 1.3.2.2. The dynamic generation process of the resolvable private address RPA is as follows: Sc1, PRAND generation: The mobile app generates a 24-bit random number using the system's random number generator, which is updated every 15 minutes (configurable from 5 to 30 minutes). The timestamp counter is reset synchronously during the update.

[0045] Sc2, Hash Calculation: Using the identity resolution key IRK as the key, the AES-CMAC algorithm is executed on the random number PRAND, and the lower 24 bits of the result are taken as the hash value. The calculation formula is: Hash=AES-CMAC(IRK,PRAND)&0x00FFFFFF.

[0046] Sc3, Address Assembly: Set the highest bit of the Hash value to 1 to indicate a private address and the second highest bit to 0 to indicate a resolvable type. After concatenation with the random number PRAND, a 6-byte Bluetooth RPA address is formed (Hash[23:16]||Hash[15:8]||Hash[7:0]||PRAND[23:16]||PRAND[15:8]||PRAND[7:0]).

[0047] Address verification process: After receiving the broadcast packet, the device extracts the RPA address and separates the PRAND and Hash fields. It then recalculates the AES-CMAC value using the locally stored IRK on the PRAND. If the lower 24 bits of the calculated result match the Hash field, the address is considered valid. To improve verification efficiency, the device preloads the IRK into the key register of the AES hardware accelerator, and the verification process is completed independently by the hardware without CPU intervention. Table 2 shows the privacy leakage sharing for different address types. Table 2 Comparison of Privacy Protection

[0048] The dynamic update mechanism of RPA addresses prevents attackers from tracking devices through MAC addresses for extended periods, while the resolvable feature ensures that legitimate devices can verify the validity of addresses via IRK, thus balancing privacy protection and identity authentication needs.

[0049] The AES-CMAC algorithm used in this invention is an AES-based cryptographic message authentication code algorithm suitable for integrity verification of fixed-length data. In this invention, it is used for RPA address validity verification and GATT data frame protection, and its implementation follows the NISTSP 800-38B standard. The process of dynamically generating a resolvable private address RPA using the AES-CMAC algorithm is as follows: Sd1, Subkey Generation: Compute subkey : AES-128(IRK,0x0000000000000000000000000000000000000000), if subkey If the highest bit is 0, then the subkey 1; otherwise, subkey XOR 0x87.

[0050] Sd2, Data Blocking: The input random data (PRAND) and timestamp are divided into 16-byte blocks. If the last block is less than 16 bytes long, it is padded with 0x80 followed by zeros to reach 16 bytes. If the data is 16 bytes long, the last block is combined with the subkey. XOR.

[0051] Sd3, Iterative Calculation: The initial vector is 0x000000000000000000000000000000000. Each block of data is XORed with the result of the previous round and then encrypted with AES. The last block is processed using a subkey. Substitute subkey .

[0052] Sd4, Result Truncation: The lower 24 bits of the encryption result are embedded as a hash value in the RPA address, and the remaining bytes are used for integrity verification of the GATT data frame.

[0053] Hardware acceleration implementation: The STM32L051 integrates an AES-128 hardware accelerator, supporting multiple modes such as ECB / CBC / CTR / CMAC. This invention selects CMAC mode by configuring the MODE[2:0] bits of the AES_CR register to 0b101. The key is written through the AES_KEYR register (32 bits of data written in four separate steps), and the data is input through the AES_DINR register. The accelerator supports DMA transfer, allowing direct reading of PRAND data from Flash for computation. The result is read through the AES_DOUTR register. The entire process takes approximately 85 seconds. μs, Compared to software implementation, it is about 37 times faster, taking approximately 3.2ms.

[0054] After successful verification, the device returns the verification status to the mobile phone via the "authentication result" feature value (UUID 0x2A50) of the GATT service, which includes a timestamp and a random number of the device. The mobile phone can then further verify the legitimacy of the device, thus forming a two-way authentication mechanism.

[0055] S3, the storage stage, utilizes a hardware encryption engine and partition protection to ensure the physical security of the keys, specifically: The device uses a hardware encryption engine to encrypt the identity resolution key (IRK) generated during the initialization phase in AES-128-CBC mode. The storage medium is divided into five logical partitions: a startup partition, an application partition, an encryption partition, a configuration partition, and a log partition. The encrypted IRK ciphertext, the randomly generated initialization vector, and the integrity check value are stored in the encryption partition. Combined with a hardware anti-tampering mechanism, key leakage due to physical disassembly is prevented.

[0056] As shown in Table 3, the 28KB Flash memory of the STM32L051 is divided into 5 logical partitions, and the read / write protection level is configured using the STM32CubeProgrammer tool. The specific partitioning is as follows: Table 3 Storage Media Partitioning

[0057] As shown in Table 3, the boot area, with an address range of 0x08000000~0x08001FFF, stores secure boot code and has a read protection level of 1, meaning reading is prohibited. The application area, with an address range of 0x08002000~0x08017FFF, stores the Bluetooth protocol stack and application program, with a read protection level of 0, meaning reading is allowed, and write protection is enabled, prohibiting erasure. The encryption area, with an address range of 0x08018000~0x08018FFF, stores the encrypted core key, with a read protection level of 2, meaning encrypted reading is allowed, and write protection is enabled, allowing writing only in initialization mode.

[0058] The configuration area has an address range of 0x08019000 to 0x0801DFFF and is used to store device parameters and pairing information. It has a read protection level of 0 and write protection is enabled, requiring password verification to write. The log area has an address range of 0x0801E000 to 0x0801FFFF and is used to store security event logs, including verification failure records. It uses a circular write mode, and when the storage is full, it overflows and overwrites old logs.

[0059] Access control: Encryption area protection: The encryption area is configured for write protection via the STM32's FLASH_WRPR register. Protection can only be deactivated in initialization mode (through dual verification of hardware pin levels and password). Reading requires using the dedicated encryption area API, which automatically calls the irk_decrypt_load() function to decrypt the data, returning a temporary decrypted result instead of the original ciphertext.

[0060] Bad block management: The encrypted area uses a wear-leveling algorithm, automatically selecting the sector with the fewest erase cycles during each write operation to prevent a single sector from being damaged by frequent writes. The system maintains a bad block table (stored in the configuration area), marking unusable sectors and automatically skipping them.

[0061] Secure Boot: The boot sector code is verified by the STM32 Hardware Root of Trust (HSE) to ensure that only signed firmware can run, preventing attackers from reading encrypted data by replacing the firmware.

[0062] Physical protection measures: During the hardware design of the device, the Flash pins of the MCU (such as PSRAM, NWR, NOE) are protected by circuitry through epoxy resin potting or coating. Physical disassembly will trigger a short circuit on these pins, causing the MCU to automatically erase the encrypted data. For financial-grade devices, a voltage monitoring circuit can be integrated. When an abnormal power supply is detected (such as below 2.7V), the key erasure process is immediately initiated to prevent low-voltage attacks from reading memory data.

[0063] Key storage is the last line of defense for end-to-end security. This invention employs a triple protection strategy of "hardware encryption + partition protection + access control" to ensure that the IRK is never exposed throughout the entire device lifecycle. The STM32 MCU's Flash memory is divided into multiple logical partitions, with the encrypted area configured as read-only via hardware registers, allowing data to be written only during the initialization phase (verified through the secure boot process). Key processing is completed entirely within the hardware encryption engine, bypassing the CPU bus and memory, thus physically eliminating the risk of key leakage.

[0064] The IRK key is not stored directly as the original value. Instead, it is encrypted and stored after being derived from a mixture of the device's unique identifier (UID) and a random number. The specific process by which the device encrypts the identity resolution key IRK generated during the initialization phase in AES-128-CBC mode using a hardware encryption engine is as follows: S31. Root Key Generation: Before the device leaves the factory, a 128-bit root key is written to it via an offline programmer and stored in the STM32's system memory. This area is hardware write-protected and cannot be read or modified by conventional means.

[0065] S32, IRK Derivation: The identity resolution key IRK generated during the initialization phase and the device's 96-bit unique device identifier UID are used to calculate a temporary key using HMAC-SHA256. ;T=HMAC-SHA256(Root Key,IRK||UID).

[0066] S33, AES encryption: Temporary key Encryption is performed using AES-128-CBC mode. The initialization vector IV is generated by TRNG and stored together with the ciphertext. The encryption process is completed through the STM32's CRYP hardware accelerator, and the encryption result is stored in the Flash encryption area.

[0067] Decryption process: When the identity resolution key IRK is needed during routine identification, the system performs a reverse operation: it reads the ciphertext and IV from the Flash memory, decrypts them using the CRYP accelerator to obtain the temporary key T, and then calculates the IRK by combining the UID and Root Key. The entire decryption process is completed in a closed loop within the hardware. The identity resolution key IRK exists only in the registers of the CRYP accelerator. After decryption, it is directly used for AES-CMAC operations. The registers are immediately cleared after the operation is completed to ensure that the IRK never appears in memory or on the bus.

[0068] like Figure 2As shown, the present invention provides an end-to-end secure communication system for Bluetooth identity recognition, comprising a main control unit, a Bluetooth communication unit, a key derivation module, and a physical security module.

[0069] The main control unit has a built-in AES-128 accelerator, TRNG module and anti-tampering monitoring unit, and supports elliptic curve cryptography ECC operation. The main control unit adopts an MCU with an integrated hardware encryption engine, specifically an STM32L051 series microcontroller.

[0070] The Bluetooth communication unit supports extended broadcast packets, adaptive frequency hopping (AFH), and LE Secure Connections pairing, with broadcast channels covering channels 37 / 38 / 39.

[0071] The key derivation module generates a 32-bit random number based on the device's unique identifier (UID) and TRNG, and then uses the HMAC-based key derivation function HKDF to generate an IRK encryption key, ensuring the uniqueness of the key for each device.

[0072] The physical security module includes a hardware debugging interface fuse circuit, which fuses the debugging interface in normal mode; and an integrated voltage and temperature monitoring unit, which triggers a key erasure command in case of an anomaly.

[0073] Example 1: I. Hardware System Design: This system's hardware architecture is based on the STM32L051C8T6 microcontroller, integrating a Bluetooth Low Energy module, hardware encryption engine, secure storage unit, and peripheral interface circuits to form a high-security near-field identification terminal. The overall design follows the "principle of least privilege," retaining only necessary communication interfaces and peripherals, and reducing the attack surface through hardware customization. Power management employs a low-power design, supporting continuous operation for ≥6 months in battery-powered mode (at typical identification frequencies), meeting the long-term operational requirements of embedded devices.

[0074] (1) STM32 MCU security feature configuration: Core controller selection: STM32L051C8T6 (ARM Cortex-M0+ core, 128KB Flash, 20KB RAM), with the following security features: Hardware encryption engine: Integrated AES-128 accelerator supporting ECB / CBC / CTR / CMAC modes, true random number generator TRNG (compliant with NIST SP 800-22 standard), and elliptic curve cryptography ECC accelerator supporting P-256 / P-384 curves.

[0075] Physical tamper protection: Built-in voltage monitoring (VDD monitoring range 1.65V-3.6V), temperature sensor (-40℃~+105℃), JTAG interface fuse function (configurable via option byte).

[0076] Storage protection: Flash supports read protection RDP, write protection WRP, and sector locking, while SRAM has parity verification functionality.

[0077] (2) Security configuration implementation: JTAG Interface Disable: Configure the option byte using the STM32CubeProgrammer tool to set the nSWBOOT0 pin to GPIO mode, which fuses the JTAG debug interface and prevents memory data from being read through the debug port.

[0078] TRNG initialization: Enables a hardware random number generator, which improves randomness by continuously sampling noise sources.

[0079] Voltage / Temperature Monitoring: Configure PWR peripheral to trigger an interrupt. When VDD < 2.5V or temperature > 85℃, automatically erase the encryption key and enter shutdown mode.

[0080] The above security configuration is compared with other methods, as shown in Table 4: Table 4 Comparison of Safety Features of Different Controllers

[0081] (3) Bluetooth module and peripheral circuit interface: Bluetooth module selection: nRF52832 (Nordic Semiconductor), compatible with BLE5.0 protocol, supports extended broadcast packets (maximum 255 bytes), AES-CCM encrypted transmission, and communicates with STM32 via UART interface (baud rate 115200, 8N1, hardware flow control).

[0082] Peripheral circuit design: UART communication interface: The STM32's USART2 (PA2=TX, PA3=RX) is connected to the nRF52832's UART interface, and RTS / CTS flow control (PA0=RTS, PA1=CTS) is configured to prevent data overflow.

[0083] A TVS diode (SMBJ33A) is added to the circuit to protect against ESD, and a 22Ω resistor is connected in series to suppress signal reflection.

[0084] Power management circuit: Main power supply: 3.3V LDO (RT9193-33), input voltage range 2.5V-5.5V, output current 300mA, ripple ≤5mV.

[0085] Backup power: CR2032 button cell battery (3V, 230mAh), isolated by diode, automatically switches when the main power fails, supports operation for ≥72 hours in low power mode.

[0086] Status indication: RGB LEDs (PA8 / PA9 / PA10): Blue indicates standby, green indicates successful verification, and red indicates verification failure / error.

[0087] Buzzer (PB0, driver transistor 8050): Used for Passkey voice prompts and abnormal alarms.

[0088] II. Key Safety Designs: During the private key generation process, 32 bytes of random numbers are generated continuously using TRNG, rejecting all zeros or weak keys (such as consecutive identical bytes).

[0089] When Passkey verification fails, flash_increment_failed_attempts() is executed to record the number of failures. If the number of failures is 5, the pairing function will be locked for 30 minutes.

[0090] Performance optimization: AES-CMAC computation is implemented through a hardware accelerator, and the encryption of 16 bytes of data takes about 12μs, which is about 40 times faster than the software implementation of the mbedTLS library.

[0091] During RPA verification, the IRK key is directly loaded into the AES key register via irk_decrypt_load() to avoid memory exposure.

[0092] Secure storage features: The encrypted area is configured for write protection via flash_set_write_protect(), and can only be deactivated via flash_clear_write_protect() in initialization mode (requires hardware pin and password verification).

[0093] The root key is stored in the STM32 system memory. This area cannot be modified after leaving the factory and can be configured as read-only using Option Bytes.

[0094] III. Implementation of Secure Communication Process: State machine design: The system operation state is divided into 4 main states, which are scheduled in a loop through the state_machine() function. State transitions are triggered by events (such as Bluetooth interruption, timer timeout).

[0095] State definition: typedef enum{ STATE_STANDBY=0, / / Standby state (low power scan) STATE_INIT=1, / / Initialize state (pairing mode) STATE_VERIFY=2, / / Verification status (RPA+CMAC verification) STATE_AUTHORIZED=3, / / Authorization status (data communication) STATE_ERROR=4 / / Error status (requires reset) }SystemState; SystemState current_state=STATE_STANDBY; uint32_t state_timeout=0; / / State timeout counter (ms).

[0096] IV. Performance Testing: ① Safety performance test (1) Relay attack resistance test: To verify the ability to defend against relay attacks during the daily identification phase, a test environment based on a Bluetooth signal repeater (model BT-Relay Pro, supporting 2.4GHz band signal amplification and forwarding) was set up.

[0097] The test scenario was set as follows: the initial distance between the legitimate Bluetooth device and the identification terminal was 1m (RSSI=-45dBm). The device signal was amplified and forwarded to the terminal 50m away via a repeater, simulating a "close-range illusion". The system has a built-in distance change detection algorithm to calculate the RSSI change rate of adjacent broadcast packets in real time. When the calculated change in distance The interception mechanism is triggered when the attack speed exceeds 5 m / s. After 100 consecutive attack attempts, the system detected the abnormal RSSI curve within 300 ms and rejected the authentication request, achieving a 100% interception success rate. In contrast, the traditional solution without integrated relay protection achieved an 85% success rate for relay attacks under the same conditions, verifying the effectiveness of RPA dynamic address combined with RSSI monitoring in resisting relay attacks.

[0098] (2) Key storage security test To assess the resistance to physical dismantling of IRK key hardware encrypted storage, 10 prototypes were selected for destructive testing: after physical dismantling, the data of the Flash encrypted partition was directly read using a J-Link V11 programmer, and compared with a control group device using a traditional software AES encrypted storage solution.

[0099] The results showed that the Flash data of the prototype of this invention was 128 bytes of AES-CBC encrypted data (including IV vector and CRC32 checksum). After continuous analysis for 72 hours using a professional reverse engineering tool (IDA Pro 7.7), the plaintext IRK could not be cracked. In contrast, the plaintext IRK of the control group device was extracted within 4 hours. Simultaneously, attempts to write to the encrypted partition in normal mode via the debug interface resulted in a "permission denied" instruction from the system. Normal reading and writing were only possible in the initialization mode (requiring hardware pin level triggering), verifying the effectiveness of Flash partition access control.

[0100] (3) Test against MITM attack To verify the anti-man-in-the-middle attack capability of LE Secure Connections pairing during the initialization phase, an Ellisys Bluetooth Analyzer Pro 400 was used to build a MITM attack platform. During the pairing process, the platform intercepted and replaced the ECDH public keys of both parties in real time. The test included 100 pairing scenarios. The attack platform attempted to inject a fake public key to induce the generation of an incorrect shared secret. Simultaneously, Passkey Entry verification was enabled. The device randomly generated a 6-digit number and displayed it on a hardware OLED screen, which the user then manually entered into the terminal.

[0101] The results showed that all attack attempts terminated due to Passkey verification failure, and no successful MITM attacks occurred. In contrast, the control group using traditional BLE Legacy pairing (without MITM protection) achieved a 92% success rate for MITM attacks under the same conditions, demonstrating that ECDH key exchange combined with Passkey verification can effectively resist man-in-the-middle attacks.

[0102] (4) Anti-replay attack test To defend against replay attacks during the routine identification phase, a Nordic nRF Sniffer is used to capture legitimate device broadcast packets (including a 32-bit timestamp field). This packet is then repeatedly transmitted to the identification terminal via a signal generator at a frequency of 10Hz. During verification, the system extracts the timestamp of the data packet and compares it with the local real-time clock. A replay is identified when the timestamp deviation exceeds 500ms or a duplicate timestamp is detected. After 1000 consecutive replay tests, the terminal consistently returned a "verification failed" response, resulting in a 0% success rate for replay attacks. Traditional solutions without integrated timestamp verification achieved a 100% success rate under the same conditions, validating the anti-replay effectiveness of AES-CMAC combined with dynamic timestamps.

[0103] ② Communication performance test: In a standard electromagnetic shielded room with a temperature of 25℃, humidity of 50%, and no external interference, the communication performance of a certain brand and model of mobile phone was evaluated using an STM32L051 core board + BLE5.0 module as the test terminal. The key indicators are as follows: Initialization pairing time: The average time from initiating a pairing request to completing the entire process of LTK / IRK storage is 2.3 seconds (100 tests), with the 95th percentile value ≤ 2.8 seconds, meeting the design target (≤ 3 seconds); the average pairing time of traditional LE Legacy is 1.8 seconds, but it lacks MIT protection mechanism.

[0104] Daily identification response time: The average time taken for the terminal to receive the broadcast packet, complete AES-CMAC verification, and return the authorization result is 320ms (1000 tests), with the 99th percentile value ≤450ms. The main time consumption is distributed in AES-CMAC hardware acceleration calculation (accounting for 65%) and RPA address resolution (accounting for 25%), which meets the real-time requirements of high-security scenarios, with a response time ≤500ms.

[0105] GATT encryption transmission efficiency: When transmitting 512 bytes of data using AES-CCM encryption, the throughput reaches 185kbps, which is 108% higher than the software-implemented AES encryption (89kbps); the hardware encryption engine reduces the time of a single AES-CMAC operation from 12ms in the software implementation to 2.3ms, significantly optimizing encryption performance.

[0106] ③ Cross-platform compatibility testing: To verify the system's compatibility with mainstream mobile operating systems, 10 representative models were selected for testing, covering various mobile phones operating HarmonyOS, Android, and iOS systems. Each model completed 100 initial pairings and 1000 daily recognitions. Key results are as follows: RPA address resolution success rate: A certain brand's A1 model, equipped with HarmonyOS 2.0, and A2 model, equipped with HarmonyOS 3.1, achieved an average resolution success rate of 99.2%.

[0107] A certain brand's B1 model, equipped with Android 12, and B2 model, equipped with Android 14, achieved an average parsing success rate of 98.7%.

[0108] The C1 model of a certain brand, equipped with iOS 13 and iOS 16, achieved an average parsing success rate of 98.1%, meeting the design goal of ≥98% overall.

[0109] Key exchange compatibility: All models successfully completed LE Secure Connections pairing with no public key exchange failures; traditional BLE Legacy pairing resulted in 12% pairing failures on iOS 15+ models (due to the system disabling insecure pairing methods), but the solution of this invention does not have this problem.

[0110] Special scenario adaptation: To address the iOS broadcast packet length limit of 31 bytes, by compressing vendor-defined fields (e.g., reducing them from 25 bytes to 18 bytes), the total length of the broadcast packet is controlled within 31 bytes, increasing the iOS parsing success rate from 95.3% to 99.0%.

[0111] To address the extended broadcast interval in Android's low-power mode (from 500ms to 2s), the scanning strategy has been optimized to combine active scanning at a 1s interval with passive listening for continuous reception, keeping the identification response latency within 600ms and ensuring availability in low-power scenarios.

[0112] The method and system provided by this invention can be applied to the following high-security scenarios: Financial self-service terminal scenarios: such as operator authentication for ATMs and self-service card issuing machines, where the daily identification response time is ≤300ms, and it supports resistance to relay attacks. Interception is triggered when the speed exceeds 5 m / s, and the key storage meets the Level 3 encryption strength of the "Financial Industry Information Security Level Protection Assessment Requirements".

[0113] Smart door lock scenarios: including home security door locks and office access control, RPA address update cycle ≤10 minutes, physical anti-tampering triggering is achieved through PCB strain gauge sensors, and IRK and encrypted partition data are erased within 3 seconds when the shell is detected to be disassembled.

[0114] In medical device scenarios: the AES-CMAC verification data includes the device serial number and user ID, and the transmitted data is encrypted with LTK (AES-CCM mode), which complies with the HIPAA (Health Insurance Portability and Accountability Act) encryption requirements for medical data privacy.

[0115] Therefore, the present invention adopts the above-mentioned end-to-end secure communication method and system for Bluetooth identity recognition, which can effectively resist attacks such as man-in-the-middle, replay, relay and key leakage, realize a secure closed loop of pairing, identification and storage, and with hardware-level encryption protection, it can be adapted to high-risk scenarios such as finance and security, significantly improving the security, reliability and practicality of Bluetooth identity recognition.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the technical solutions of the present invention, and these modifications or equivalent substitutions cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. An end-to-end secure communication method for Bluetooth identity recognition, characterized in that, Includes the following steps: S1. Initialization phase: A trusted key negotiation channel is established using the LE Secure Connections protocol to derive the core key; S2, Daily Identification Phase: Replay attacks and relay attacks are prevented through Dynamically Resolvable Private Address RPA and encrypted verification. S3, the storage stage, utilizes a hardware encryption engine and partition protection to ensure the physical security of the keys.

2. The end-to-end secure communication method for Bluetooth identity recognition according to claim 1, characterized in that, S1 specifically refers to: The LE Secure Connections pairing protocol is used for secure key exchange between devices. A shared secret is generated by exchanging public keys using the NIST P-256 Elliptic Curve ECDH algorithm. After the public key exchange, the Passkey Entry verification mechanism is used to defend against man-in-the-middle attacks. The core keys, including the link key LTK, identity resolution key IRK, and connection signature key CSRK, are generated using the key derivation algorithm HMAC-SHA256. The derived identity resolution key IRK is then encrypted and stored in a hardware secure area.

3. The end-to-end secure communication method for Bluetooth identity recognition according to claim 2, characterized in that, In S1, the ECDH algorithm generates the shared key as follows: Sa1: The device and mobile phone generate public and private key pairs based on NIST P-256 elliptic curves. The NIST P-256 elliptic curve expression is as follows: ； The private key is generated using the STM32's built-in true random number generator TRNG, and the public key is generated by the private key and the curve base point. The formula is obtained by performing scalar multiplication: ； In the formula, For private key, Public key coordinates; Sa2: The device and mobile phone exchange public keys through the manufacturer-defined data unit AD Type 0xFF of the Bluetooth broadcast packet. A 2-byte length field and a 1-byte checksum are attached before the public key is transmitted. After the receiver verifies the public key, it is stored in the RAM temporary buffer. Sa3, the device uses its own private key. With mobile phone public key Computational shared secrets : ； Private key for performing symmetric operations on mobile device With device public key Computational shared secrets Both parties will receive the same shared secret value; Sa4, the shared secret, is derived into session key material through the HMAC-SHA256 algorithm. The input parameters include the shared secret, Bluetooth device address BD_ADDR, pairing random number Rand, and salt value Salt. Finally, the link key LTK, identity resolution key IRK, and connection signature key CSRK are generated.

4. The end-to-end secure communication method for Bluetooth identity recognition according to claim 2, characterized in that, In S1, the verification process of the Passkey Entry verification mechanism is as follows: Sb1. After the device enters pairing mode, a 6-digit random number Passkey is generated by the True Random Number Generator (TRNG) and displayed on the LCD screen or announced by a buzzer. Sb2. The user enters the Passkey displayed on the device in the Bluetooth pairing interface on the mobile phone. The mobile phone converts the Passkey into 16-byte Little-Endian format and then performs an XOR operation with the confirmation value derived from the shared secret. Sb3. Both parties calculate HMAC-SHA256 respectively. The device sends the calculation result to the mobile phone through the 0xFFFF feature value of GATT service. The mobile phone verifies whether the local calculation result is consistent with the received value. If they are consistent, the MITM protection is completed.

5. The end-to-end secure communication method for Bluetooth identity recognition according to claim 4, characterized in that, S2 specifically refers to: Authentication is achieved based on the dynamic generation rules of resolvable private address RPA and the AES-CMAC algorithm for password message authentication. The resolvable private address RPA is generated by the identity resolution key IRK and the random number PRAND through AES-CMAC operation and is updated periodically. The identification terminal extracts the random number PRAND from the broadcast packet, reconstructs the RPA by combining it with the locally stored IRK, and performs AES-CMAC verification. At the same time, it integrates timestamp and Received Signal Strength Indicator (RSSI) monitoring to prevent replay attacks and relay attacks.

6. The end-to-end secure communication method for Bluetooth identity recognition according to claim 5, characterized in that, In S2, the dynamic generation process of resolvable private address RPAs is as follows: Sc1: The mobile app generates a 24-bit random number using the system's random number generator, which is updated every 15 minutes and the timestamp counter is reset synchronously. Sc2. Using the identity resolution key IRK as the key, perform the AES-CMAC algorithm on the random number PRAND, and take the lower 24 bits of the result as the hash value; Sc3. Set the highest bit of the Hash value to 1 to indicate a private address and the second highest bit to 0 to indicate a resolvable type. Concatenate this with the random number PRAND to form a 6-byte Bluetooth RPA address.

7. The end-to-end secure communication method for Bluetooth identity recognition according to claim 5, characterized in that, In S2, the process of dynamically generating a resolvable private address RPA using the AES-CMAC algorithm is as follows: Sd1, Calculate the subkey : AES-128(IRK,0x0000000000000000000000000000000000000000), if subkey If the highest bit is 0, then the subkey 1; otherwise, subkey XOR 0x87; Sd2. Divide the input random data PRAND and timestamp into 16-byte blocks. If the last block is less than 16 bytes long, pad it with 0x80 followed by zeros until it reaches 16 bytes. If the data length is 16 bytes, then the last block is combined with the subkey. XOR; Sd3, with an initial vector of 0x0000000000000000000000000000000000, is used. Each data block is XORed with the result of the previous round and then encrypted using AES. The last block is processed using a subkey. Substitute subkey ; Sd4. The lower 24 bits of the encryption result are embedded as a hash value into the RPA address, and the remaining bytes are used for integrity verification of the GATT data frame.

8. The end-to-end secure communication method for Bluetooth identity recognition according to claim 7, characterized in that, S3 specifically refers to: The device uses a hardware encryption engine to encrypt the identity resolution key IRK generated during the initialization phase in AES-128-CBC mode, and divides the storage medium into a boot area, application area, encryption area, configuration area and log area. The encrypted IRK ciphertext, the randomly generated initialization vector, and the integrity check value are stored in the encrypted area; combined with a hardware anti-tampering mechanism, key leakage caused by physical disassembly is prevented. The specific process by which the device encrypts the identity resolution key IRK generated during the initialization phase in AES-128-CBC mode using a hardware encryption engine is as follows: S31. Before the device leaves the factory, a 128-bit root key is written to it via an offline programmer and stored in the STM32's system memory. S32. Calculate a temporary key by combining the identity resolution key IRK generated during the initialization phase with the device UID (unique device identifier) ​​using HMAC-SHA256. ; S33, Temporary Key Encryption is performed using AES-128-CBC mode. The initialization vector IV is generated by TRNG and stored together with the ciphertext. The encryption process is completed through the STM32's CRYP hardware accelerator, and the encryption result is stored in the Flash encryption area.

9. An end-to-end secure communication method for Bluetooth identity recognition according to claim 8, characterized in that, In S3, the boot area address range is 0x08000000~0x08001FFF, which is used to store secure boot code. The protection level is read protection level 1, which means reading is prohibited. The application area address range is 0x08002000~0x08017FFF, which is used to store the Bluetooth protocol stack and application. The protection level is read protection level 0, which means that reading is allowed, while write protection is enabled and erasure is prohibited. The encrypted area has an address range of 0x08018000~0x08018FFF and is used to store the encrypted core key. The protection level is read protection level 2, which means encrypted reading and write protection is enabled, with writing only allowed in initialization mode. The configuration area address range is 0x08019000~0x0801DFFF, used to store device parameters and pairing information. The protection level is read protection level 0, and write protection is enabled. Password verification is required to write to it. The log area address range is 0x0801E000~0x0801FFFF, used to store security event logs, including verification failure records. It adopts a circular write mode, and when the storage is full, it overflows and overwrites the old logs.

10. An end-to-end secure communication system for Bluetooth identity recognition, used to implement the method according to any one of claims 1-9, characterized in that, It includes a main control unit, a Bluetooth communication unit, a key derivation module, and a physical security module; The main control unit has a built-in AES-128 accelerator, TRNG module and anti-tampering monitoring unit, supports elliptic curve cryptography ECC operation, and the main control unit uses an MCU with an integrated hardware encryption engine, specifically an STM32L051 series microcontroller. The Bluetooth communication unit supports extended broadcast packets, adaptive frequency hopping (AFH), and LE Secure Connections pairing, with broadcast channels covering channels 37 / 38 / 39; The key derivation module generates a 32-bit random number based on the device's unique identifier (UID) and TRNG, and then uses the HMAC-based key derivation function HKDF to generate an IRK encryption key, ensuring the uniqueness of the key for each device. The physical security module includes a hardware debugging interface fuse circuit, which fuses the debugging interface in normal mode; and an integrated voltage and temperature monitoring unit, which triggers a key erasure command in case of an anomaly.

Images