A Bluetooth data encryption method based on a 32-bit chip

Abstract

This invention discloses a Bluetooth data encryption method based on a 32-bit chip, comprising the following steps: S1: The Bluetooth terminal and an external counterpart determine an encryption / decryption key, and encrypt the encryption / decryption key using a first secure storage key to obtain a first ciphertext, which is then stored; S2: When the Bluetooth terminal receives a second ciphertext, it transmits it to the MCU, and the MCU reads the first ciphertext; S3: The first ciphertext is decrypted using the first secure storage key to obtain an encryption / decryption key, and the second ciphertext is decrypted using the encryption / decryption key to obtain plaintext, while the usage count of the first secure storage key is incremented by one; S4: The first secure storage key that has reached its usage limit is destroyed, and a second secure storage key is generated to encrypt the plaintext and the encryption / decryption key. This invention can effectively ensure the security of communication between the external Bluetooth module and the MCU, as well as the security of the MCU's data processing after receiving data, preventing the key from being easily obtained and effectively preventing reverse engineering attacks targeting embedded devices.

Description

Technical Field

[0001] This invention relates to the field of embedded electronics technology, and in particular to a Bluetooth data encryption method based on a 32-bit chip. Background Technology

[0002] In the consumer electronics and automotive electronics fields, the use of Bluetooth modules for Bluetooth data transmission or Bluetooth OTA (Over-The-Air) updates is becoming increasingly common. Currently, the general technology involves secondary development based on Bluetooth chips to integrate the functions of automotive-related external accessories (such as charging stations) into the Bluetooth chip MCU. However, in the field of automotive embedded development, automotive-grade Bluetooth chips are expensive and have limited options. Therefore, in areas such as charging stations that are not part of the vehicle's internal domain control development, it is rare to see all the main functions integrated into a Bluetooth chip. For example, in the case of charging stations, a 32-bit automotive-grade MCU and a low-power... Data transmission using BLE Bluetooth modules is increasingly sensitive to information security concerns. While Bluetooth itself employs encryption, the MCU also requires encryption during transmission, data storage, and boot upgrades to enhance the security of the entire link, data storage, and code version upgrades. If the MCU itself or the link has security vulnerabilities, it becomes highly susceptible to attacks from reverse engineering, disassembly, side-channel attacks, and other methods, posing a significant threat to sensitive data and the overall system security, especially considering cost. Some automotive-grade chips lack a hardware security sensor (HSM), making software-level security even more crucial. Summary of the Invention

[0003] To address the aforementioned shortcomings, this invention proposes a Bluetooth data encryption method based on a 32-bit chip. By utilizing randomly generated keys in the encryption and decryption processes, it can effectively ensure the security of communication between the external Bluetooth module and the MCU, as well as the security of the MCU's data processing after receiving data. This prevents the keys from being easily obtained and effectively prevents reverse engineering attacks targeting embedded devices.

[0004] To achieve the above objectives, the present invention provides the following technical solution: a Bluetooth data encryption method based on a 32-bit chip, comprising the following steps:

[0005] S1: The Bluetooth terminal and the external counterpart determine a private key in a symmetric key or asymmetric key pair as the encryption and decryption key for data transmission, and use the first secure storage key generated by the key management module to encrypt the encryption and decryption key to obtain the first ciphertext, and store the first ciphertext in the external storage space.

[0006] S2: When the Bluetooth terminal receives the second ciphertext of encrypted data from the external terminal, it transmits the second ciphertext to the MCU via serial port or other means. After receiving the second ciphertext, the MCU reads the first ciphertext.

[0007] S3: Decrypt the first ciphertext using the first secure storage key to obtain the encryption / decryption key, and use the encryption / decryption key to decrypt the received second ciphertext to obtain the plaintext, i.e., the user's sensitive data. Increment the usage count of the first secure storage key by one.

[0008] S4: The first secure storage key that has reached the usage limit is destroyed by the key management module, and the second secure storage key is regenerated by the key management module. The second secure storage key is used to encrypt the plaintext and the encryption / decryption key to obtain the third and fourth ciphertexts. The third and fourth ciphertexts are written to the external storage space. The second secure storage key is stored in another memory space of the key management module, waiting for the next decryption operation.

[0009] As an improvement, the external storage space is an external EEPROM or an external flash memory. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext into the external storage space.

[0010] As an improvement, the key management module is used to manage the entire lifecycle of the key, which includes the random generation and allocation of the key, the use of the key, the update of the key, the backup of the key, the recovery and destruction of the key.

[0011] As an improvement, the random generation and allocation of keys includes the key generation part of the key management module. The key generation of the symmetric algorithm is randomized by using a symmetric key random algorithm. A block of memory is allocated in the heap area using dynamic memory allocation to store the calculated first symmetric encryption algorithm key and use it as a securely stored key. After the first symmetric encryption algorithm key is generated, this memory is released and the first symmetric encryption algorithm key is stored in a specific flash space. The first symmetric encryption algorithm key represents any key existing in the key management module.

[0012] As an improvement, the use of the key involves defining a variable as the number of times this key is used. This variable is incremented by one after a string of plaintext has been encrypted and decrypted once by the same first symmetric encryption algorithm key, until the number of times the variable is used reaches a manually given limit.

[0013] As an improvement, the key update includes the following steps: when the number of times the first symmetric encryption algorithm key is used reaches a given limit, the key generation part will re-allocate memory and generate a second symmetric encryption algorithm key. The second symmetric encryption algorithm key represents any key existing in the key management module. The second symmetric encryption algorithm key directly overwrites the flash space of the first symmetric encryption algorithm key or allocates another flash space for storage, and completely clears the ciphertext calculated by the first symmetric encryption algorithm key from memory. The first symmetric encryption algorithm key is identified as an obsolete key.

[0014] As an improvement, key backup, recovery, and destruction include storing obsolete keys in a static memory area to back up the memory space used to store backups of old passwords, or using overwrite or secure erasure methods to completely erase the memory space used to destroy obsolete keys and then write new data.

[0015] As an improvement, secure startup and secure upgrade of data transmission are implemented based on the OTA packet of the Bluetooth module. In the creation of the OTA packet, an integrity verification algorithm is used to obtain a string of verification values. The verification values ​​are placed in a specific part of the OTA packet for integrity verification. Then, the public key of the asymmetric encryption algorithm is used to sign the verification values. The signed data Cipher_Update is placed in the memory location agreed upon by both parties for identity verification. The Private_Key used for designing is also stored in the external storage space using the secure storage key in steps S1-S2.

[0016] As an improvement, after the OTA packet transmission is completed, the Private_Key obtained in step S3 is used to design Cipher_Update to obtain a plaintext value, which is then compared with the integrity check value in the OTA packet. If they match, the identity verification passes; if they do not match, the legality verification of the OTA packet fails. After the identity verification passes, the integrity check comparison process is executed again.

[0017] Compared with the prior art, the advantages of the present invention are as follows:

[0018] (1) This invention provides a method for secure data storage and secure transmission to external Bluetooth devices on an MCU without HSM, which helps to reduce product costs and greatly increases the selectivity of materials.

[0019] (2) This invention utilizes the random generation of keys, the storage and retrieval of ciphertext, and memory management to effectively ensure the security of communication between the external Bluetooth module and the MCU and the security of the MCU's processing of received data. Furthermore, the encryption and decryption processes use randomly generated keys, and the keys are securely stored in a specific flash space after generation, preventing the keys from being easily obtained and effectively preventing reverse analysis attacks against embedded devices.

[0020] (3) The present invention uses a key management module to manage the entire life cycle of the key, including key generation, use, update, backup, recovery and destruction, to ensure the comprehensiveness and security of key management;

[0021] (4) This invention uses a combination of symmetric and asymmetric encryption algorithms to further enhance the security of data transmission and storage;

[0022] (5) This invention supports the updating and replacement of keys. When the number of times a key is used reaches the limit, a new key can be regenerated and overwritten or stored in a new flash space, ensuring the long-term validity and security of the key.

[0023] (6) The key backup and recovery mechanism in this invention allows the key to be recovered when it is lost or damaged, thus improving the fault tolerance of the system;

[0024] (7) A certain explanation is given regarding secure upgrades and startup based on secure storage. On MCU chips without HSM, during the creation and transmission of OTA packages, integrity verification algorithms and asymmetric encryption algorithms are used for verification and signing to ensure the integrity and legality of OTA packages. After the OTA package transmission is completed, the identity and integrity of the OTA package are further verified by designing and comparing the verification value, which prevents the injection and attack of malicious software and greatly increases the security of OTA package upgrades. Attached Figure Description

[0025] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0026] Figure 1 This is a flowchart of a Bluetooth data encryption method based on a 32-bit chip.

[0027] Figure 2 This is a flowchart illustrating the secure transmission process in an embodiment.

[0028] Figure 3 This is a schematic diagram of the upgrade package structure for an example. Detailed Implementation

[0029] like Figure 1As shown, a Bluetooth data encryption method based on a 32-bit chip includes the following steps:

[0030] S1: The Bluetooth terminal and the external counterpart determine a private key in a symmetric key or asymmetric key pair as the encryption and decryption key for data transmission, and use the first secure storage key generated by the key management module to encrypt the encryption and decryption key to obtain the first ciphertext, and store the first ciphertext in the external storage space.

[0031] S2: When the Bluetooth terminal receives the second ciphertext of encrypted data from the external terminal, it transmits the second ciphertext to the MCU via serial port or other means. After receiving the second ciphertext, the MCU reads the first ciphertext.

[0032] S3: Decrypt the first ciphertext using the first secure storage key to obtain the encryption / decryption key, and use the encryption / decryption key to decrypt the received second ciphertext to obtain the plaintext, i.e., the user's sensitive data. Increment the usage count of the first secure storage key by one.

[0033] S4: The first secure storage key that has reached the usage limit is destroyed by the key management module, and the second secure storage key is regenerated by the key management module. The second secure storage key is used to encrypt the plaintext and the encryption / decryption key to obtain the third and fourth ciphertexts. The third and fourth ciphertexts are written to the external storage space. The second secure storage key is stored in another memory space of the key management module, waiting for the next decryption operation.

[0034] The external storage space is an external EEPROM or an external flash memory. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext into the external storage space.

[0035] When data transmission requires a security upgrade, the secure transmission process during OTA packet transmission based on the Bluetooth module is similar to the secure transmission part of general data.

[0036] The key management module manages the entire lifecycle of a key, including key random generation and allocation, key usage, key updates, key backup, recovery, and destruction.

[0037] The random generation and allocation of keys are included in the key generation section of the key management module. A symmetric key random algorithm is used to randomize the generation of symmetric algorithm keys. Dynamic memory allocation is used to allocate a block of memory in the heap area to store the calculated first symmetric encryption algorithm key and use it as a securely stored key. After the first symmetric encryption algorithm key is generated, this memory is released and the first symmetric encryption algorithm key is stored in a specific flash space. The first symmetric encryption algorithm key represents any key existing in the key management module.

[0038] The use of the key involves defining a variable as the number of times the key is used. After a string of plaintext is encrypted and decrypted once by the same first symmetric encryption algorithm key, this variable is incremented by one until the number of times the variable is used reaches a manually given limit.

[0039] The key update process involves the key generation section re-allocating memory and generating a second symmetric encryption algorithm key after the first symmetric encryption algorithm key has been used a given number of times. The second symmetric encryption algorithm key represents any key existing in the key management module. The second symmetric encryption algorithm key directly overwrites the flash space of the first symmetric encryption algorithm key or allocates another flash space for storage. The ciphertext calculated by the first symmetric encryption algorithm key is completely cleared from memory, and the first symmetric encryption algorithm key is identified as an obsolete key.

[0040] Key backup, recovery, and destruction include storing obsolete keys in a static memory area to back up the memory space used to store backups of old passwords, or using overwrite or secure erase methods to completely erase the memory space used to destroy obsolete keys and then write new data.

[0041] In the creation of the OTA package, an integrity verification algorithm is used to obtain a string of verification values. The verification values ​​are placed in a specific part of the OTA package for integrity verification. Then, the verification values ​​are signed using the public key of an asymmetric encryption algorithm. The signed data Cipher_Update is placed in the memory location agreed upon by both parties for identity verification. The Private_Key used for designing is also stored in the external storage space using the same secure storage key method as in steps S1-S2.

[0042] Example:

[0043] like Figure 3As shown, a Bluetooth data encryption method based on a 32-bit MCU microcontroller is disclosed. The on-board charging pile system includes a main controller MCU1 and a Bluetooth module BLE1. The external vehicle-mounted system includes a main controller MCU2, a Bluetooth module BLE2, and other vehicle-mounted components. The external mobile app includes a Bluetooth module BLE3. The Bluetooth module is responsible for data communication between the vehicle-mounted system or the mobile app and the charging pile. A classic Bluetooth BT module or a low-power BLE Bluetooth module can be used; in this embodiment, a BLE low-power Bluetooth module is used for Bluetooth communication. The charging pile main controller MCU1 communicates with the charging pile Bluetooth module BLE1 via serial port 1. Communication: The vehicle-mounted main controller MCU2 communicates with the vehicle-mounted Bluetooth module BLE2 via serial port 2; the charging pile Bluetooth module BLE1 interacts and transmits data with the vehicle-mounted Bluetooth module BLE2 or the mobile app-side Bluetooth module BLE3 through the Bluetooth underlying protocol stack and Bluetooth communication protocol. When the charging pile is communicating with the vehicle-mounted or mobile app-side, the charging pile Bluetooth module BLE1 is in slave mode, passively receiving message queries or requests from the vehicle-mounted Bluetooth module BLE2 or the mobile app-side Bluetooth module BLE3. The Bluetooth communication protocol consists of a frame header field (2 bytes), a frame identifier field (1 byte), a frame data field (32 bytes), and a CRC8 checksum frame (1 byte). The data field consists of four parts: first frame (bytes), second frame (bytes), and third frame (bytes). When the length of the data to be sent exceeds the length of the frame data field (32 bytes), PCI rules are used to process it into packets, sending the first frame and subsequent frames, to ensure that the length of each data frame sent does not exceed 32 bytes. After the charging pile Bluetooth module BLE1 receives a pairing request from the vehicle-mounted Bluetooth module BLE2 or the mobile phone Bluetooth module BLE3 and establishes a connection, it first receives the time synchronization command from the outside through the established channel. When the fifth byte of the data field is 0x00, it indicates that the charging pile Bluetooth module and the mobile phone Bluetooth module have been connected and this channel transmits sensitive data from the mobile phone. When the fifth byte of the field has a value of 0x01, it indicates that the charging pile Bluetooth module and the vehicle-mounted Bluetooth module are connected and this channel transmits sensitive data from the vehicle-mounted device. When the charging pile Bluetooth module BLE1 receives sensitive data from external input (vehicle-mounted device and mobile phone), the Bluetooth module will forward the data to the charging pile main controller MCU1 through a designated serial port channel. After receiving the data, MCU1 will unpack the data and decrypt it according to the above-mentioned secure transmission strategy. The decrypted data will be securely stored according to the secure storage strategy of this patent. The following will break down the steps into two parts: secure transmission and secure storage, and secure startup and secure upgrade.

[0044] (1) Before the data transmission begins, the charging pile system needs to agree with the vehicle terminal (hereinafter referred to as the external Bluetooth module terminal BLE2) on a symmetric key based on a symmetric key algorithm or a key pair of an asymmetric key algorithm as the encryption and decryption key KeyA for data transmission. The following uses the symmetric key as an example. After agreeing on the key, proceed to step (2).

[0045] (2) After agreeing on the key, the vehicle terminal calls the KeyM module to generate a vehicle terminal security storage key Key_Car. This security storage key Key_Car is used to encrypt the data transmission key KeyA to obtain CipherA. CipherA is written to the external flash or external EEPROM for whitelist storage. The vehicle terminal security storage key Key_Car is stored in segments in the flash memory of the vehicle terminal main controller MCU2. The charging station also calls the KeyM module to generate a charging station security storage key Key_Charger. This security storage key Key_Charger is used to encrypt the data transmission key KeyA to obtain CipherA′. CipherA′ is written to the external flash or external EEPROM for whitelist storage. The charging station security storage key Key_Charger is stored in segments in the flash memory of the charging station main controller MCU1. After the vehicle terminal and the charging station have completed the secure storage of the transmission key, proceed to step (3).

[0046] (3) Before preparing to transmit data, the vehicle-mounted main controller reads the encrypted secure storage key ciphertext CipherA from the external flash or external EEPROM storage space, and decrypts it using the Key_Car key generated in step (2) to obtain the transmission key KeyA. After obtaining the KeyA key, the usage count (i.e., the number of times the original Key_Car key is used) is incremented by one. When the number of times Key_Car is used reaches the specified number (e.g., three times), the key destruction process of KeyM is called to destroy it. The key destruction process is entered, and the memory space where the old key Key_Car is located is completely overwritten with 0x00. After the old secure storage key Key_Car on the vehicle-mounted side is destroyed, the vehicle-mounted main controller MCU2 encrypts the data DATA to be transmitted using the decrypted transmission key KeyA to obtain encrypted data Cipher_Data, and starts the transmission process. Cipher_Data is transmitted to the charging pile Bluetooth module BLE1 through the vehicle-mounted Bluetooth module BLE2 and enters step (4). At the same time, after encryption is completed, the vehicle-mounted secure storage key Key_Car2 is regenerated and the process re-enters step (2) to wait for the next use.

[0047] (4) After receiving a pairing request from the vehicle-mounted Bluetooth module BLE2 and successfully establishing a connection with BLE2, the charging pile Bluetooth module BLE1 receives the AT data command (AT+DATA) sent by BLE2 and transmits the received data to the charging pile main controller MCU1 via serial port. After MCU1 reads the ciphertext CipherA′ of the transmission key from the external flash or external EEPROM, it decrypts the key using the charging pile storage key Key_Charger generated in step (2) to obtain the transmission key KeyA. After obtaining the KeyA key, the usage count of the original Key_Charger key is incremented by one. When the Key_Charger key usage count reaches the specified number (e.g., three times), the key destruction module of KeyM is called to destroy it, and the original memory space of the old secure storage key Key_Charger is completely overwritten to 0. x00, after the Key_Charger key is destroyed, the pile-end main controller MCU1 unpacks the data transmitted from BLE1, that is, it identifies the header and tail of the AT command and obtains the data data frame segment to obtain Cipher_Data. After obtaining the encrypted data Cipher_Data, it uses the transmission key KeyA obtained from the decryption to decrypt it to obtain the plaintext data DATA. After obtaining DATA, according to the Bluetooth communication protocol, sensitive data such as user mobile phone number, vehicle VIN code, etc. are extracted. The KeyM module is called again to generate a symmetric key Key_Charge2 as a new secure storage key. MCU1 uses Key_Charge2 to encrypt the extracted sensitive data to obtain encrypted data DATA_Cipher, and then writes it to the external flash or external EEPROM for whitelist storage, waiting for the next reading and a new round of calling and transmission.

[0048] like Figure 3 As shown, when data transmission requires a security upgrade, taking the mobile app and charging pile system as an example...

[0049] (1) Before starting OTA data transmission, the mobile app needs to agree with the charging pile system on an asymmetric key pair calculated by an asymmetric encryption algorithm (such as RSA, ECC, etc.) as a tool for identity verification; the public key part of this key, Public_Key, is securely stored by the charging pile terminal through a secure storage process; the private key part, Private_Key, is securely stored by the host computer terminal.

[0050] (2) When creating the OTA upgrade package file, the SHA256 integrity verification algorithm is used to verify the app part of the program to obtain 32 bytes of Verify1; in the host computer tool, these 32 bytes are concatenated to the end of the app part, and then the private key of the asymmetric key pair generated in step (1) is used to encrypt these 32 bytes of Verify1 to obtain a signature information of about 2kb in length, and then the host computer tool is used to concatenate it to the end of the 32-byte verification value, such as Figure 2 As shown; proceed to step (3) to enter the OTA packet sending process;

[0051] (3) Based on the secure transmission process, the Bluetooth module BLE3 on the mobile app continuously sends OTA data packets, i.e. the upgrade package app part, to the Bluetooth module BLE1 on the charging pile. After the transmission is completed, proceed to step (4). Otherwise, if the packet transmission fails or the packet is not fully transmitted, the upgrade will fail. This is defined according to the timeout rules or communication failures defined by the OTA protocol, which will not be elaborated here.

[0052] (4) After receiving the OTA packet from the mobile app BLE3, the charging pile terminal BLE1 stores each packet in the flash memory of the Bluetooth module BLE1 after verification. Until the last packet is transmitted, BLE1 informs the main controller MCU1 of the charging pile terminal to start the upgrade and flashing operation through the serial port and enters step (5).

[0053] (5) After receiving the OTA packet transmission completion instruction from BLE1, the main controller MCU1 at the pile end starts booting and obtains the encrypted public key ciphertext Public_Cipher from the external EEPROM in step (1). It decrypts the Public_Key using the secure storage process at the pile end. Boot uses Public_Key to decrypt the signature part of the OTA upgrade package to obtain 32 bytes of plain_Verify verification information. Then it compares this plain_Verify part with the Verify1 verification value obtained in step (2). If they match, it enters the flashing process step (6). If they do not match, the upgrade package is deemed invalid and the upgrade fails.

[0054] (6) The charging pile performs the flashing process, and after the upgrade package is flashed into the flash during boot, it restarts and performs other verification operations to ensure successful upgrade.

[0055] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0056] The units described in some embodiments of this disclosure can be implemented in software or in hardware. The described units can also be located in a processor, and the functions described above can be performed at least in part by one or more hardware logic components.

[0057] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the technical solution of the present invention, or the direct application of the concept and technical solution of the present invention to other occasions without modification, are all within the protection scope of the present invention.

Claims

1. A Bluetooth data encryption method based on a 32-bit chip, characterized in that: Includes the following steps: S1: The Bluetooth terminal and the external counterpart determine a private key in a symmetric key or asymmetric key pair as the encryption and decryption key for data transmission, and use the first secure storage key generated by the key management module to encrypt the encryption and decryption key to obtain the first ciphertext, and store the first ciphertext in the external storage space. S2: When the Bluetooth terminal receives the second ciphertext of encrypted data from the external terminal, it transmits the second ciphertext to the MCU via serial port or other means. The MCU receives the second ciphertext and then reads the first ciphertext. S3: Decrypt the first ciphertext using the first secure storage key to obtain the encryption / decryption key, and use the encryption / decryption key to decrypt the received second ciphertext to obtain the plaintext, i.e., the user's sensitive data. Increment the usage count of the first secure storage key by one. S4: The first secure storage key that has reached the usage limit is destroyed by the key management module, and a second secure storage key is regenerated by the key management module. The second secure storage key is used to encrypt the plaintext and the encryption / decryption key to obtain a third ciphertext and a fourth ciphertext. The third ciphertext and the fourth ciphertext are written into the external storage space. The second secure storage key is stored in another memory space of the key management module, waiting for the next decryption operation. Secure data transmission startup and secure upgrade are implemented based on the OTA packet of the Bluetooth module. In the creation of the OTA packet, an integrity verification algorithm is used to obtain a string of verification values. The verification values ​​are placed in a specific part of the OTA packet for integrity verification. Then, the verification values ​​are signed using the public key of the asymmetric encryption algorithm. The signed data Cipher_Update is placed again in the memory location agreed upon by both parties for identity verification. The Private_Key used for designing is also stored in the external storage space using the secure storage key in the manner described in steps S1-S2. After the OTA packet transmission is completed, the Private_Key obtained in step S3 is used to design Cipher_Update to obtain a plaintext value, which is then compared with the integrity verification value in the OTA packet. If they match, the identity verification passes; if they do not match, the legality verification of the OTA packet fails. After the identity verification passes, the integrity verification comparison process is executed again.

2. The Bluetooth data encryption method based on a 32-bit chip according to claim 1, characterized in that: The external storage space is an external EEPROM or an external flash memory. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext into the external storage space.

3. The Bluetooth data encryption method based on a 32-bit chip according to claim 1, characterized in that: The key management module is used to manage the entire lifecycle of the key, which includes the random generation and allocation of the key, the use of the key, the update of the key, the backup of the key, the recovery and destruction of the key.

4. The Bluetooth data encryption method based on a 32-bit chip according to claim 2, characterized in that: The random generation and allocation of the key includes the key generation part of the key management module, which uses a symmetric key random algorithm to randomize the key generation of the symmetric algorithm, uses dynamic memory allocation to apply for a block of memory in the heap area to store the calculated first symmetric encryption algorithm key, and uses it as a securely stored key. After the first symmetric encryption algorithm key is generated, this block of memory is released, and the first symmetric encryption algorithm key is stored in a specific flash space. The first symmetric encryption algorithm key represents any key existing in the key management module.

5. The Bluetooth data encryption method based on a 32-bit chip according to claim 2, characterized in that: The use of the key includes defining a variable as the number of times the key is used. After a string of plaintext is encrypted and decrypted once by the same first symmetric encryption algorithm key, this variable is incremented by one until the number of times the variable is used reaches a manually given limit.

6. The Bluetooth data encryption method based on a 32-bit chip according to claim 2, characterized in that: The key update includes the following steps: when the number of times the first symmetric encryption algorithm key is used reaches a given limit, the key generation part will re-allocate memory and generate a second symmetric encryption algorithm key. The second symmetric encryption algorithm key represents any key existing in the key management module. The second symmetric encryption algorithm key directly overwrites the flash space of the first symmetric encryption algorithm key or allocates another flash space for storage, and completely clears the ciphertext calculated by the first symmetric encryption algorithm key from memory. The first symmetric encryption algorithm key is identified as an obsolete key.

7. A Bluetooth data encryption method based on a 32-bit chip according to claim 6, characterized in that: The backup, recovery, and destruction of the key include backing up the obsolete key in the static memory area, using the memory space for storing backups of old passwords, or completely erasing the memory space for destroying the obsolete key using overwrite or secure erase methods and then writing new data.

Images