Bluetooth data encryption method based on 32-bit chip

Abstract

The invention discloses a Bluetooth data encryption method based on a 32-bit chip, and the method comprises the following steps: S1, determining an encryption and decryption key through a Bluetooth end and an external opposite end, encrypting the encryption and decryption key through employing a first safety storage key, and obtaining a first ciphertext, and storing the first ciphertext; s2, when the Bluetooth end receives the second ciphertext and transmits the second ciphertext to the MCU, the MCU reads the first ciphertext; s3, decrypting the first ciphertext through the first secure storage key to obtain an encryption and decryption key, decrypting the second ciphertext by using the encryption and decryption key to obtain a plaintext, and adding one to the use count of the first secure storage key; and S4, destroying the first secure storage key reaching the upper limit of the number of times of use, and generating a second secure storage key to encrypt the plaintext and the encryption and decryption key. According to the invention, the communication between the external Bluetooth module and the MCU and the processing security of the MCU after receiving the data can be effectively ensured, the key is prevented from being easily acquired, and the reverse analysis attack aiming at the embedded equipment can be effectively prevented.

Description

Technical Field

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

[0002] In the field of consumer electronics or automotive electronics, there are more and more scenarios where Bluetooth modules are used for Bluetooth data transmission or Bluetooth OTA. The current general technology is to carry out secondary development based on Bluetooth chips, integrating the functions of car-related external accessories (such as charging piles, etc.) into the Bluetooth chip MCU. However, in the field of automotive electronics embedded development, Bluetooth chips that meet automotive-grade requirements are expensive and have fewer options. Therefore, in parts such as charging piles that do not belong to the development of internal domain control of the vehicle body, it is rare to integrate all the main functions into the Bluetooth chip. Taking charging piles as an example, a 32-bit automotive-grade MCU and a low-power MCU are still used. The BLE module is used for data transmission. In today's information security, the data security of Bluetooth transmission also needs to be taken seriously. The Bluetooth channel transmission itself has an encryption mode, but the MCU also needs to perform encryption operations during the transmission process, data storage and boot upgrade process to improve the security of the entire link and data storage and code version upgrade. If there are problems with the security of the MCU itself or the link, it is extremely vulnerable to threats from reverse analysis or disassembly, side channels and other attack methods, which are very harmful to the security of sensitive data and the entire system, especially for cost considerations. Some automotive-grade chips do not have the function of hardware security core HSM. In this case, it is even more necessary to ensure the security of information at the software level. Summary of the invention

[0003] In view of the above-mentioned shortcomings, the present invention proposes a Bluetooth data encryption method based on a 32-bit chip, which uses randomly generated keys in the encryption and decryption processes, can effectively ensure the security of communication between the external Bluetooth module and the MCU and the security of the MCU's processing after receiving data, prevents the key from being easily obtained, and can effectively prevent reverse analysis attacks on embedded devices.

[0004] To achieve the above object, 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 end and the external counterpart end determine a symmetric key or a private key in an asymmetric key pair as an encryption and decryption key for data transmission, and use a first secure storage key generated by a key management module to encrypt the encryption and decryption key to obtain a first ciphertext, and store the first ciphertext in an external storage space;

[0006] S2: After the Bluetooth end receives the second ciphertext of the encrypted data from the external opponent, the second ciphertext is transmitted to the MCU through the serial port or other means. After receiving the second ciphertext, the MCU reads the first ciphertext.

[0007] S3: decrypting the first ciphertext using the first secure storage key to obtain an encryption / decryption key, and decrypting the received second ciphertext using the encryption / decryption key to obtain plaintext, i.e., user sensitive data, and increasing the usage count of the first secure storage key by one;

[0008] S4: The first secure storage key that has reached the upper limit of the number of uses 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 and decryption key to obtain the third ciphertext and the fourth ciphertext. The third ciphertext and the fourth ciphertext are written into the external storage space, and 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 external flash. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext to the external storage space.

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

[0011] As an improvement, the random generation and distribution of keys are included in the key generation part of the key management module, and the key generation of the symmetric algorithm is randomized by using a symmetric key random algorithm. Dynamic memory allocation is used to apply for a piece 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.

[0012] As an improvement, 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, the variable is increased by one until the number of times the variable is used reaches a manually given limit.

[0013] As an improvement, the key update includes that when the number of uses of the first symmetric encryption algorithm key reaches a given limit, the key generation part will re-apply for 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 opens up another flash space for storage, and clears all ciphertext calculated by the first symmetric encryption algorithm key in the memory, and the first symmetric encryption algorithm key is identified as an abandoned key.

[0014] As an improvement, the backup, recovery and destruction of keys include storing the discarded keys in the static memory area for backing up the memory space used to store backups of old passwords or completely erasing the memory space for destroying the discarded keys by overwriting or secure erasure and then writing new data.

[0015] As an improvement, the secure startup and secure upgrade of data transmission are implemented based on the OTA package of the Bluetooth module. In the production of the OTA package, a string of check values ​​is obtained using an integrity check algorithm, and the check value is placed in a specific part of the OTA package for integrity check. The check value is then signed using the public key of the asymmetric encryption algorithm, and 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 decryption is stored in the external storage space using the secure storage key in the same way as steps S1-S2.

[0016] As an improvement, after the OTA package transmission is completed, the Private_Key obtained in step S3 is also used to decrypt the Cipher_Update to obtain a string of plaintext values, which are then compared with the integrity check value in the OTA package. If they are consistent, the identity verification passes; if they are inconsistent, the legitimacy check of the OTA package fails. After passing the identity verification, the integrity verification comparison process is executed.

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

[0018] (1) The present invention provides a method for securely storing data on an MCU without an HSM and securely transmitting data to an external Bluetooth device, which is beneficial for reducing product costs and greatly increasing the selectivity when selecting materials;

[0019] (2) The present invention utilizes random key generation, ciphertext access, and memory management to effectively ensure the security of communication between the external Bluetooth module and the MCU and the MCU's processing after receiving data. The encryption and decryption process uses 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, ensuring the comprehensiveness and security of key management;

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

[0022] (5) The present invention supports key update and replacement. When the number of times a key is used reaches a 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 of the present invention allows the key to be restored when it is lost or damaged, thereby improving the fault tolerance of the system;

[0024] (7) A certain degree of explanation is given on the secure upgrade and startup based on secure storage. On MCU chips that do not have HSM, integrity verification algorithms and asymmetric encryption algorithms are used to verify and sign during the production and transmission of OTA packages to ensure the integrity and legitimacy of the OTA packages. After the OTA package is transmitted, the identity and integrity of the OTA package are further verified by decrypting the signature and comparing the verification value, preventing the injection and attack of malicious software, thereby greatly increasing the security of OTA package upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0026] Figure 1 This is a flow chart of a Bluetooth data encryption method based on a 32-bit chip;

[0027] Figure 2 It is a flowchart of secure transmission of an embodiment;

[0028] Figure 3 It is a schematic diagram of the upgrade package structure of the embodiment. DETAILED DESCRIPTION

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

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

[0031] S2: After the Bluetooth end receives the second ciphertext of the encrypted data from the external opponent, the second ciphertext is transmitted to the MCU through the serial port or other means. After receiving the second ciphertext, the MCU reads the first ciphertext.

[0032] S3: decrypting the first ciphertext using the first secure storage key to obtain an encryption / decryption key, and decrypting the received second ciphertext using the encryption / decryption key to obtain plaintext, i.e., user sensitive data, and increasing the usage count of the first secure storage key by one;

[0033] S4: The first secure storage key that has reached the upper limit of the number of uses 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 and decryption key to obtain the third ciphertext and the fourth ciphertext. The third ciphertext and the fourth ciphertext are written into the external storage space, and 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 external flash. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext to the external storage space.

[0035] When data transmission needs to be securely upgraded, the secure transmission during the OTA package transmission based on the Bluetooth module is similar to the secure transmission of general data.

[0036] The key management module is used to manage the entire life cycle of the key, which includes the random generation and distribution of the key, the use of the key, the update of the key, the backup, recovery and destruction of the key.

[0037] The random generation and distribution of keys are included in the key generation part of the key management module. The symmetric key random algorithm is used to randomize the key generation of the symmetric algorithm. Dynamic memory allocation is used to apply for a piece 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 includes defining a variable as the number of times the key is used. After a string of plain text is encrypted and decrypted once by the same first symmetric encryption algorithm key, the variable is increased by one until the number of times the variable is used reaches a manually given limit.

[0039] The key update includes that when the number of times the first symmetric encryption algorithm key is used reaches a given limit, the key generation part will re-apply for 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 opens up another flash space for storage, and clears all ciphertext calculated by the first symmetric encryption algorithm key in the memory, and the first symmetric encryption algorithm key is identified as an abandoned key.

[0040] The backup, recovery and destruction of keys include storing the discarded keys in the static memory area for backing up the memory space used to store the backup of the old password or completely erasing the memory space for destroying the discarded keys by overwriting or secure erasure and then writing new data.

[0041] In the production of OTA packages, an integrity check algorithm is used to obtain a string of check values, which are placed in a specific part of the OTA package for integrity check. The check value is then 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 decryption is stored in an external storage space using the secure storage key in the same way as steps S1-S2.

[0042] Example:

[0043] like Figure 3As shown, a Bluetooth transmission data encryption method based on a 32-bit MCU microcontroller, the vehicle charging pile system includes a main controller MCU1 and a Bluetooth module BLE1, the external vehicle-end system includes a main controller MCU2, a Bluetooth module BLE2 and other vehicle-end component devices, and the external mobile phone app end includes a Bluetooth module BLE3; wherein the Bluetooth module is responsible for the data communication interaction between the vehicle-end or the mobile phone app end and the charging pile end, and 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 module; wherein the pile-end main controller MCU1 communicates with the pile-end Bluetooth module BLE1 through serial port 1 Communication, the main controller MCU2 on the vehicle side communicates with the Bluetooth module BLE2 on the vehicle side through serial port 2; the Bluetooth module BLE1 on the pile side interacts with the Bluetooth module BLE2 on the vehicle side or the Bluetooth module BLE3 on the mobile app side through the Bluetooth underlying protocol stack and the Bluetooth communication protocol for message exchange and data transmission. When the pile side communicates with the vehicle side or the mobile app side, the Bluetooth module BLE1 on the pile side is in slave positioning and passively receives message inquiries or requests from the Bluetooth BLE2 on the vehicle side or the Bluetooth BLE3 on the mobile phone side; 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 check frame (1 Bytes). When the length of the data to be sent is greater than the length of the frame data field (32 bytes), the PCI rule is used to perform packet transmission of the first frame + continuous frames to ensure that the data frame length of each message sent does not exceed 32 bytes; when the pile-end Bluetooth module BLE1 receives a pairing request from the vehicle-end Bluetooth module BLE2 or the mobile-end Bluetooth module BLE3 and establishes a connection, it first receives a time synchronization instruction from the outside through the established channel. When the fifth byte value of the data field is 0x00, it indicates that the charging pile-end Bluetooth module is connected to the mobile-end Bluetooth module and this channel transmits sensitive data from the mobile phone. When the data When the fifth byte value of the domain is 0x01, it means that the Bluetooth module on the charging pile side is connected to the Bluetooth module on the vehicle side and this channel transmits sensitive data from the vehicle side; when the Bluetooth module BLE1 on the charging pile side receives sensitive data from external input (the vehicle side and the mobile phone side), the Bluetooth module will forward the data to the main controller MCU1 on the charging pile side through the specified 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 be a detailed breakdown of the steps from secure transmission and secure storage, secure startup and secure upgrade:

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

[0045] (2) After the key is agreed upon, the vehicle-side calls the KeyM module to generate a vehicle-side secure storage key Key_Car, uses the secure storage key Key_Car to encrypt the data transmission key KeyA to obtain CipherA, writes CipherA to the external flash or external eeprom for whitelist storage, and the vehicle-side secure storage key Key_Car is stored in segments in the flash memory of the vehicle-side main controller MCU2; the pile-side also calls the KeyM module to generate a pile-side secure storage key Key_Charger, uses the secure storage key Key_Charger to encrypt the data transmission key KeyA to obtain CipherA′, writes CipherA′ to the external flash or external eeprom for whitelist storage, and the pile-side secure storage key Key_Charger is stored in segments in the flash memory of the pile-side main controller MCU1; after the above secure storage of the transmission key by the vehicle-side and the pile-side is completed, proceed to step (3);

[0046] (3) Before preparing to transmit data, the main controller at the vehicle end reads the encrypted secure storage key ciphertext CipherA from the external flash or external eeprom storage space, and uses the Key_Car key generated in step (2) to decrypt it to obtain the transmission key KeyA. After obtaining the KeyA key, the usage count (i.e., the number of times the key_Car is used) of the original Key_Car key is increased by one. When the number of times Key_Car is used reaches the specified number of times (for example, three times), the key destruction process of KeyM is called to destroy it, and the key destruction process is entered to overwrite the memory space where the old key Key_Car is located with 0x00. After the old secure storage key Key_Car at the vehicle end is destroyed, the main controller MCU2 at the vehicle end encrypts the data DATA to be transmitted using the transmission key KeyA obtained by decryption to obtain the encrypted data Cipher_Data, and starts the transmission process. Cipher_Data is transmitted to the charging pile end Bluetooth module BLE1 through the vehicle end Bluetooth module BLE2, and then enters step (4). At the same time, after the encryption is completed, step (2) is re-entered to regenerate the vehicle end secure storage key Key_Car2, and wait for the next use;

[0047] (4) After the charging pile-side Bluetooth module BLE1 receives the pairing request from the vehicle-side Bluetooth module BLE2 and successfully establishes a connection relationship with BLE2, the pile-side Bluetooth module BLE1 receives the AT data command (AT+DATA) sent by BLE2, and transmits the received data to the pile-side main controller MCU1 through the serial port. After MCU1 reads the ciphertext CipherA′ of the transmission key from the external flash or external eeprom, it uses the pile-side storage key Key_Charger generated in step (2) to decrypt it and obtain the transmission key KeyA. After obtaining the KeyA key, the number of times the original Key_Charger key is used is increased by one. When the number of times the Key_Charge key is used reaches the specified number of times (for example, 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 of the pile-side is completely overwritten with 0 x00, after the Key_Charger key is destroyed, the main controller MCU1 at the pile end unpacks the data transmitted by BLE1, that is, identifies the head and tail of the AT command and obtains the data frame segment to obtain Cipher_Data. After obtaining the data ciphertext Cipher_Data, it uses the transmission key KeyA obtained by decryption to decrypt it to obtain the transmission data plaintext DATA; after obtaining DATA, according to the Bluetooth communication protocol, the sensitive data such as the user's mobile phone number, vehicle VIN code, etc. are split out, and 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 split sensitive data to obtain the encrypted data DATA_Cipher, and then writes it to the external flash or external eeprom for whitelist storage, waiting for the next round of calling and transmission after being read;

[0048] like Figure 3 As shown in the figure, when data transmission needs to be upgraded safely, take 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 using 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 end through a secure storage process; the private key part Private_Key is securely stored by the host computer end;

[0050] (2) When making an OTA upgrade package file, use the SHA256 integrity check algorithm to check the app part of the program to obtain the 32-byte Verify1; in the host computer tool, splice these 32 bytes after the app part, and then use the private key Private_Key of the asymmetric key pair generated in step (1) to encrypt the 32-byte Verify1 to obtain a signature information of about 2kb in length, and then use the host computer tool to splice it after the 32-byte check value, such as Figure 2 As shown; go to step (3) and enter the OTA package sending process;

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

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

[0053] (5) After receiving the OTA package transmission completion instruction from BLE1, the main controller MCU1 on the pile side starts booting, obtains the public key ciphertext Public_Cipher encrypted in step (1) from the external eeprom, and uses the pile side security storage process to decrypt and obtain Public_Key; Boot uses Public_Key to decrypt the signature part of the OTA upgrade package to obtain 32 bytes of plain_Verify verification information, and then compares this plain_Verify part with the Verify1 verification value obtained in step (2). If they are consistent, enter the flashing process step (6); if they are inconsistent, the upgrade package is deemed invalid and the upgrade fails;

[0054] (6) The charging pile performs the flashing process and reboots and performs other verification operations after the boot flashes the upgrade package into the flash to ensure a successful upgrade.

[0055] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

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

[0057] The present invention is described above by way of example in conjunction with the accompanying drawings. It is obvious that the specific implementation of the present invention is not limited to the above-mentioned method. As long as various non-substantial improvements are made using the technical solution of the present invention, or the concept and technical solution of the present invention are directly applied to other occasions without improvement, they 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: The following steps are involved: S1: The Bluetooth end and the external counterpart end determine a symmetric key or a private key in an asymmetric key pair as an encryption and decryption key for data transmission, and use a first secure storage key generated by a key management module to encrypt the encryption and decryption key to obtain a first ciphertext, and store the first ciphertext in an external storage space; S2: After the Bluetooth end receives the second ciphertext of the encrypted data from the external opponent, the second ciphertext is transmitted to the MCU through the serial port or other means, and the MCU reads the first ciphertext after receiving the second ciphertext; S3: decrypting the first ciphertext using the first secure storage key to obtain an encryption / decryption key, and decrypting the received second ciphertext using the encryption / decryption key to obtain plaintext, i.e., user sensitive data, and increasing the usage count of the first secure storage key by one; S4: The first secure storage key that has reached the upper limit of the number of uses 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 and decryption key to obtain the third ciphertext and the fourth ciphertext, and 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.

2. The method for encrypting Bluetooth data 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. The external storage space reads the ciphertext from the MCU, and the MCU writes the ciphertext into the external storage space.

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

4. The method for encrypting Bluetooth data based on a 32-bit chip according to claim 2, characterized in that: The random generation and distribution of the key is included in 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, and uses dynamic memory allocation to apply for a piece 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 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 method for encrypting Bluetooth data 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 plain text is encrypted and decrypted once by the same first symmetric encryption algorithm key, the variable is increased by one until the number of times the variable is used reaches a manually given limit.

6. The method for encrypting Bluetooth data based on a 32-bit chip according to claim 2, characterized in that: The key update includes that when the number of times the first symmetric encryption algorithm key is used reaches a given limit, the key generation part will re-apply for 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 opens up another flash space for storage, and clears all ciphertext calculated by the first symmetric encryption algorithm key in the memory, and the first symmetric encryption algorithm key is identified as an abandoned key.

7. The method for encrypting Bluetooth data based on a 32-bit chip according to claim 6, characterized in that: The backup, recovery and destruction of the key include storing the abandoned key in the memory space for storing the backup of the old password in the static memory area for backing up or completely erasing the memory space for destroying the abandoned key by overwriting or secure erasing means and then writing new data.

8. The method for encrypting Bluetooth data based on a 32-bit chip according to claim 1, characterized in that: The secure startup and secure upgrade of data transmission are implemented based on the OTA package of the Bluetooth module. In the production of the OTA package, a string of check values ​​is obtained using an integrity check algorithm, and the check value is placed in a specific part of the OTA package for integrity check. The check value is then signed using the public key of the asymmetric encryption algorithm, and 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 decryption is stored in the external storage space using the secure storage key in the manner of steps S1-S2.

9. The method for encrypting Bluetooth data based on a 32-bit chip according to claim 8, characterized in that: After the OTA package transmission is completed, the Private_Key obtained in step S3 is also used to decrypt Cipher_Update to obtain a string of plaintext values, which are then compared with the integrity check value in the OTA package. If they are consistent, the identity check passes; if they are inconsistent, the legitimacy check of the OTA package fails. After passing the identity check, the integrity check comparison process is executed.

Images