Starting method and device of energy storage equipment, energy storage equipment, medium and program product

Abstract

The invention discloses a starting method and device of energy storage equipment, the energy storage equipment, a medium and a program. When a program is started, a first UUID in a register of a chip and a second UUID stored in an OTP area of the chip need to be read, a first comparison result can be obtained by comparing the first UUID and the second UUID, the first comparison result comprises consistency or inconsistency, and if the first UUID and the second UUID are inconsistent, the program stops running. According to the starting method of the energy storage device, before the energy storage device is started and in the process that the energy storage device is put into use, consistency verification is carried out on the second UUID stored in the OTP area of the chip and the first UUID stored in the current register, whether a program is bound with the chip or not can be judged, and then the program is started. Therefore, whether the security risk that the program is illegally tampered and copied exists or not is judged, the running program is stopped in time under the condition that the security risk exists, and security verification of the program is further started on the premise that the consistency of the first UUID and the second UUID is guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer network security technology, specifically to a startup method, device, energy storage device, storage medium, and program product for an energy storage device. Background Technology

[0002] Currently, most portable energy storage devices use a Microcontroller Unit (MCU) as the main controller. To prevent unauthorized firmware execution, protect the system from malware attacks, and ensure that the system does not crash due to code corruption during runtime, it is necessary to verify the integrity and legitimacy of the MCU program. However, most MCUs do not verify program integrity and legitimacy during runtime, posing a security risk. Some devices use Cyclic Redundancy Check (CRC) to verify program integrity but do not verify program legitimacy, which may allow the device to continue operating even if the program is tampered with and a new CRC is generated, also posing a security risk. Currently, most devices prevent unauthorized reading of the MCU's internal program by disabling Serial Wire Debug (SWD) or Flash memory read / write protection; however, this method is still vulnerable to being cracked, and once cracked, the program can be illegally read. Therefore, a secure boot method for energy storage devices is needed to avoid security risks caused by program leakage. Summary of the Invention

[0003] This application provides a startup method, apparatus, energy storage device, storage medium, and program product for an energy storage device. When the chip (such as an MCU) of the energy storage device starts the program, it reads the UUID in the register. Since the UUID of the chip containing a complete and valid program is unique and is written into the OTP area once, it is possible to determine whether the program is bound to the chip by comparing the UUID, thus avoiding the security risks of program operation caused by program leakage.

[0004] In a first aspect, embodiments of this application provide a method for starting up an energy storage device, the method comprising: When the program starts, it reads the first UUID from the chip's registers and the second UUID stored in the chip's OTP area; The first UUID and the second UUID are compared to obtain a first comparison result, which includes whether they match or do not match. If the first UUID and the second UUID are inconsistent, the program will stop running.

[0005] Secondly, embodiments of this application provide a starting device for an energy storage device, the device comprising: The read module is used to read the first UUID in the chip's registers and the second UUID stored in the chip's OTP area when the program starts. The comparison module is used to compare the first UUID and the second UUID to obtain a first comparison result, wherein the first comparison result includes whether they are consistent or inconsistent. The processing module is configured to stop the program if the first UUID and the second UUID are inconsistent.

[0006] Thirdly, this application provides an energy storage device, which includes a battery and a motherboard. The motherboard is equipped with a processor and a memory. The memory stores a computer program. The processor executes the startup method of the energy storage device as described in any of the above embodiments by calling the computer program stored in the memory.

[0007] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing a computer program adapted for loading by a processor to execute the startup method of the energy storage device as described in any of the above embodiments.

[0008] Fifthly, embodiments of this application provide a computer program product having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the startup method of the energy storage device as described in any of the above embodiments.

[0009] The startup method, apparatus, energy storage device, storage medium, and program product for energy storage devices provided in this application require reading a first UUID from the chip's register and a second UUID stored in the chip's OTP area during program startup. By comparing the first and second UUIDs, a first comparison result can be obtained, which may indicate consistency or inconsistency. If the first and second UUIDs are inconsistent, the program stops running. The startup method for energy storage devices provided in this application verifies the consistency between the second UUID stored in the chip's OTP area and the first UUID currently stored in the register before startup and during the use of the energy storage device. This determines whether the program is bound to the chip and further assesses whether there is a security risk of program tampering or copying. If a security risk exists, the program can be stopped immediately. This achieves further security verification for program startup while ensuring the consistency of the first and second UUIDs.

[0010] Additional aspects and advantages of embodiments of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of embodiments of this application. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario provided in the embodiments of this application; Figure 2 This is a first flowchart illustrating the startup method of an energy storage device provided in an embodiment of this application. Figure 3 This is a second flowchart illustrating the startup method of an energy storage device provided in an embodiment of this application. Figure 4 A schematic diagram of the third process for the startup method of the energy storage device provided in the embodiments of this application; Figure 5 A schematic diagram of the fourth process of the startup method for the energy storage device provided in the embodiments of this application; Figure 6 A fifth flowchart illustrating the startup method of the energy storage device provided in this application embodiment; Figure 7 A sixth flowchart illustrating the startup method of the energy storage device provided in this application embodiment; Figure 8 A schematic diagram of the overall process for starting up an energy storage device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the starting device of the energy storage device provided in the embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] Please see Figure 1 , Figure 1 This is an application scenario diagram of a startup method for an energy storage device provided in an embodiment of this application. The application scenario provided in this application includes an energy storage device 100 and an electronic device 200.

[0015] In some embodiments, this application provides an energy storage device 100, which includes a battery 101 and a motherboard 102. The motherboard 102 is provided with a processor and a memory. The memory stores a computer program. The processor executes the charging control method of the energy storage device provided in this application by calling the computer program stored in the memory.

[0016] Here, energy storage device 100 refers to a device capable of storing power. It is generally equipped with a rechargeable battery. By storing a large amount of power in the battery within the energy storage device, the energy storage device can output the stored electrical energy when needed.

[0017] Energy storage devices come in a variety of types, and can be categorized by application scenario: (1) Portable energy storage: generally small energy storage devices, using lithium-ion batteries, etc., are easy to carry and are used for outdoor camping, emergency charging and other scenarios. They can power mobile phones, computers, lighting equipment and other devices.

[0018] (2) Home energy storage: Used in homes to store solar power or electricity generated during off-peak hours of the power grid for use by home electrical equipment, achieving the purpose of peak shaving and valley filling, saving electricity costs, etc.

[0019] (3) Industrial and commercial energy storage: Used in factories, data centers, shopping malls and other places, it can be used for load regulation, demand-side management, power quality improvement, etc., to help users reduce electricity costs and improve power supply reliability.

[0020] (4) Grid energy storage: It is widely used in power systems to regulate the peak-valley difference of the power grid, smooth the fluctuations of renewable energy generation, and improve the stability and reliability of the power grid. Common types include large lithium-ion battery energy storage power stations, flow battery energy storage power stations, and pumped storage power stations.

[0021] In order to adapt to the increasingly diverse power consumption scenarios, portable energy storage devices have emerged. Portable energy storage devices are also called portable lithium-ion battery energy storage devices or outdoor power supplies. They usually refer to backup or emergency power supplies weighing no more than 18 kg. They use lithium-ion batteries as energy storage components and have AC or DC input charging interfaces and AC or DC output interfaces.

[0022] Among them, battery 101 is the energy core of the energy storage device, and is the component of the energy storage device that stores power.

[0023] Among them, the motherboard 102 is the control core of the energy storage device. The system's wake-up, shutdown, charging judgment and power consumption management are all controlled by the motherboard.

[0024] The energy storage device 100 is able to communicate with the electronic device 200 to cooperate with the electronic device 200 to implement the charging control method of this application.

[0025] Optionally, the electronic device 200 includes at least one of a terminal and a server.

[0026] The terminal may include, but is not limited to: smartphones (such as Android phones, iOS phones, etc.), tablet computers, laptops, desktop computers, smart speakers, smartwatches, portable personal computers, mobile internet devices (MIDs), smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, wearable devices, etc., and this application embodiment does not limit this.

[0027] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. This application does not limit this.

[0028] In some embodiments, the memory of the main control board 102 of the energy storage device 100 includes a Flash memory.

[0029] The FLASH flash memory comprises two main partitions: the BOOT (Bootloader) area and the APP (Application) area. The BOOT area is the highest priority partition in the FLASH, storing the boot code. Upon power-up, the CPU prioritizes reading the execution code from this area for initial verification to guide the APP area to run the application program. In other words, the BOOT area handles hardware initialization and system protection. The APP area is the core partition in the FLASH, storing the application program and occupying the majority of the FLASH capacity. All business functions of the device (such as data acquisition, communication, and control output) are implemented by the code in this area. The APP area is further subdivided into the APP header and the APP application itself. The APP header includes the APP program signature and the APP+BOOT program signature. Additionally, there is an OTP partition. OTP is a physical carrier that can be integrated into the FLASH (in most cases) or a special storage area on a separate chip. Its core characteristic is that it is permanently read-only after being programmed once and is not a sub-partition of the regular FLASH partition.

[0030] For example, please refer to Tables 1 to 3. For the GD32F450VG chip, its Flash memory can store 1024 kilobytes (KB) of data, with partitioned storage information. The L1 layer Flash memory is divided into two main partitions at L2: the BOOT area and the APP area. The APP area is further divided into two sub-partitions at L3: the APP header and the APP application area. The APP header includes the APP signature and the APP+BOOT signature (hybrid signature) that need to be verified at runtime. The OTP partition can store 256 bytes (B) of data. The GD32F450VG chip has a built-in dedicated SM2 algorithm hardware processing unit, supporting SM2 hardware acceleration and capable of performing core operations such as SM2 encryption, signing, and key exchange. This reduces security vulnerabilities in software implementations and is more suitable for scenarios with high efficiency and security requirements, such as encrypted communication and digital signatures.

[0031] Among them, the SM2 algorithm is a domestically developed algorithm launched by the State Cryptography Administration of China. It is an asymmetric algorithm based on elliptic curves. Compared with the RSA algorithm (a widely used asymmetric encryption algorithm named after its three inventors), the SM2 algorithm has advantages such as smaller keys, faster operation speed, and higher security for the same key length.

[0032] In this example, the addresses of Table 1, Table 2, and Table 3 are represented by hexadecimal numbers, and the stored content is also represented by hexadecimal numbers, with 2 digits representing 1 byte (8 bits).

[0033] Table 1: Flash partition storage configurations for different types of Flash partitions

[0034] Table 2: OTP Zone Storage Status

[0035] Table 3: APP Area Storage Status

[0036] Based on the above-described scenarios, this application provides a method for starting up an energy storage device. The technical solution of this application will be described in detail below through specific embodiments. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0037] Please see Figure 2 This application provides a method for starting up an energy storage device, including steps 011, 012 and 013, which are described in detail below.

[0038] Step 011: When the program starts, read the first UUID in the chip's register and the second UUID stored in the chip's OTP area.

[0039] The first UUID in the chip's register is the Universally Unique Identifier (UUID) stored in the chip currently in use. The UUID is a unique identifier inherent to the chip hardware, which is an authorized and legal identity identifier used for hardware binding to ensure that the program can only run on a specific chip. Typically, the UUID is a 128-bit (binary) number.

[0040] The OTP area of ​​a chip refers to the One-Time Programmable (OTP) memory, a special type of storage area characterized by its one-time write capability. Once written, it cannot be modified, ensuring data security and immutability. Utilizing the characteristics of the OTP area, digital signatures and public keys can be stored.

[0041] Step 012: Compare the first UUID and the second UUID to obtain the first comparison result, which may include whether they match or do not match.

[0042] Specifically, the first comparison result is reflected in the hardware-level execution flow control; consistency or inconsistency corresponds to different execution flows. When the first comparison result is consistent, the chip continues to execute the next instruction.

[0043] Step 013: If the first UUID and the second UUID are inconsistent, the program will stop running.

[0044] Specifically, if the first UUID and the second UUID do not match, it indicates that the program is running on unauthorized and illegal hardware. This could mean that the program has been illegally copied / cloned, the program in the original chip has been completely read and burned onto another chip, or the chip has been replaced—the chip in a legitimate device has been removed and replaced with a new chip or one from another device. In other words, the program and hardware are incompatible. In this case, the program must be stopped to prevent the execution of tampered code from causing system failure or security risks.

[0045] For example, during the chip manufacturing stage, the manufacturer encrypts the UUID of the manufactured chip A (such as an MCU) (read from a register), along with data such as the digital signature and the public key for decrypting the digital signature, and writes it into the OTP area of ​​the FLASH memory of chip A. At this time, the UUID in the OTP area and the UUID in the register are the same, and the UUID written to the OTP area in chip A is unique and fixed, not changing with changes in hardware devices. When running the program within chip A, by reading the first UUID in the register within chip A and the second UUID stored in the OTP area of ​​chip A, and comparing whether the first UUID and the second UUID are consistent, it can be verified whether the chip is an original manufacturer chip, that is, the hardware device has not been replaced, and the program has not been illegally ported to other illegal devices.

[0046] This application provides a startup method for an energy storage device. During program startup, a first UUID stored in the chip's register and a second UUID stored in the chip's OTP area are read. By comparing the first and second UUIDs, a first comparison result is obtained, which may indicate consistency or inconsistency. If the first and second UUIDs are inconsistent, the program stops running. This startup method verifies the consistency between the second UUID stored in the chip's OTP area and the first UUID currently stored in the register before startup and during operation. This determines whether the program is bound to the chip, thereby verifying the program's legality and integrity. It also identifies potential security risks of program tampering or copying and promptly stops the program if such risks exist.

[0047] Please see Figure 3 In some embodiments, the program includes a bootloader or application program. Data in the OTP area is encrypted using a preset encryption key, which is generated based on a second UUID and first preset encrypted data. Reading the first UUID from the chip's registers and the second UUID stored in the chip's OTP area includes: Step 11: Read the first UUID from the chip's register; Step 12: Generate a first decryption key based on the first UUID and the first preset encrypted data; Step 13: Read the second UUID stored in the OTP area of ​​the chip using the first decryption key; Step 14: If the reading is successful, proceed to the step of comparing the first UUID and the second UUID to obtain the first comparison result; Step 15: If the read fails, the program stops running.

[0048] The bootloader, stored in the BOOT area, contains startup code responsible for initial verification and loading the app. The application, stored in the APP area, contains the code that executes the device's main functions.

[0049] The first preset encrypted data is a fixed string, or a fixed salt value, used to increase the complexity of the key derivation process and prevent rainbow table attacks (a large table that determines the mapping relationship between plaintext and hash value for a specific hash algorithm). The first preset encrypted data is embedded in the algorithm logic of the bootloader.

[0050] The preset encryption key is generated based on the first preset encrypted data and the second UUID using a key derivation algorithm. It corresponds to the first decryption key, and the difference between the preset encryption key and the first decryption key determines whether the decrypted OTP area data can be correctly read. Both the preset encryption key and the first decryption key are symmetric keys, used for both encrypting data (during firmware generation) and decrypting data (during program startup).

[0051] Specifically, before compiling the next step of the program, UUID verification should be performed first: The first UUID in the chip's register should be read. Since the hardware-bound UUID in the OTP area data is encrypted and cannot be read directly, a decryption key needs to be generated according to the decryption key generation algorithm corresponding to its preset encryption key generation algorithm. That is, a first decryption key is generated by combining the first UUID with the first preset encrypted data. The preset encryption key encrypts the SM2 public key, the second UUID, the BOOT signature, and the concatenated OTP area signature data (these four types of data together constitute the OTP area data). The generated first decryption key is used to read the second UUID stored in the chip's OTP area. If the read is successful, the first UUID in the register is compared with the second UUID stored in the chip's OTP area, resulting in a first comparison result indicating whether they match or not. Only when the result matches should the next step of the program execution proceed; if the result is inconsistent or the read fails, the program should stop running.

[0052] For example, after the chip powers on, it first runs the BOOT program (bootloader) to obtain bootloader data (BL.bin). The source code in the BOOT area contains instructions for reading the UUID register and generating the first decryption key. Through the execution of the bootloader, the first UUID stored in the register can be read, and the first decryption key ENC_OTP_KEY can be generated using the first UUID and a fixed salt "!@#$%^&**&^%$#@!" (used as the first preset encryption data) via the HKDF algorithm. Then, the first decryption key ENC_OTP_KEY is used to decrypt the OTP area data. After decryption, if the second UUID stored in the chip's OTP area data can be read successfully, the second UUID is compared with the first UUID. If they do not match, the program stops running directly. If the read fails, the program also stops running directly. If the second UUID matches the first UUID, further verification by other programs is performed.

[0053] Among them, the bootloader data (BL.bin) is an image file containing pure binary machine code generated after the BOOT program, i.e. the Bootloader source code, is compiled and linked. It is stored in the BOOT area during the firmware generation stage.

[0054] Among them, the HMAC-based Key Derivation Function (HKDF) is used to generate longer keys from short key materials. The main purpose of HKDF is to derive one or more keys with cryptographic strength from the original key materials, ensuring randomness and security. The Hash-based Message Authentication Code (HMAC) algorithm is a message integrity authentication algorithm based on a cryptographic hash function. It generates Message Authentication Codes (MACs) by appending keys to the beginning and end of the message, ensuring that the message has not been tampered with during transmission.

[0055] Please see Figure 4 In some embodiments, the OTP area stores a second UUID, a boot sector digital signature, a public key for a preset national cryptographic algorithm used for digital signing, and an OTP area signature. The OTP area signature is generated by hashing the second UUID, the boot sector digital signature, and the public key using a preset hash algorithm. The method further includes: Step 21: Read the second UUID, boot sector digital signature, public key, and OTP sector signature using the first decryption key; Step 22: Perform a hash operation on the second UUID, bootstrapping digital signature, and public key using a preset hash algorithm to obtain the first hash value; Step 23: Decrypt the OTP zone signature using the public key to obtain the second hash value; Step 24: Compare the first hash value and the second hash value to obtain a second comparison result, which may include whether they match or do not match. Step 25: If the first hash value and the second hash value are inconsistent, the program stops running.

[0056] The bootstrap digital signature is the digital signature of the BOOT area, also known as the BOOT signature, which verifies the legitimacy and integrity of the BOOT area program. A digital signature (or simply a signature) is a security verification mechanism based on asymmetric encryption technology. The sender uses their private key to encrypt the data digest to generate a signature, and the receiver uses the corresponding public key to decrypt and verify it. Its core functions are to confirm data integrity (unaltered), authenticity of origin (confirmed to have been sent by the sender), and non-repudiation (the sender cannot deny it). It is widely used in electronic contracts, file transfers, identity authentication, and other scenarios, and is a key technology for ensuring digital information security. The data digest is a condensed verification message generated from the original data; if the data is tampered with, the data digest will change. The bootstrap digital signature corresponds to the bootstrap encoding result. The public key for the preset national cryptographic algorithm used for digital signatures can be a public key generated by the SM2 algorithm. Preset national cryptographic algorithms, such as SM2, are elliptic curve public-key cryptography algorithms released by the State Cryptography Administration. Based on Error Checking and Correcting (ECC) technology, they include encryption, signature, and key exchange functions and are used for identity authentication, data encryption, etc. They are my country's independently controllable cryptographic standards.

[0057] The default hash algorithm is SHA-256. A hash algorithm is a one-way, irreversible cryptographic algorithm that takes input data of arbitrary length (strings, files, binary streams, etc.) and, through fixed logical calculations, outputs a fixed-length binary data (i.e., a hash value). Almost all data digests are generated using hash algorithms (e.g., file digests commonly use SHA-256 hash values). The Secure Hash Algorithm 256-bit (SHA-256) converts an input of arbitrary length into a 256-bit (32-byte) fixed-length hash value (data digest). It possesses high collision resistance and irreversibility; even a small difference in the input leads to a drastic change in the output. It is widely used for data integrity verification, digital signatures, etc., and is currently the mainstream secure hash algorithm.

[0058] Among them, the OTP area signature is generated during the firmware production process of chip manufacturing. The concatenated second UUID, boot area digital signature and public key are first converted into a 32-byte digital digest through a preset hash algorithm. Then, the digital digest is encrypted (such as using an SM2 private key) to obtain the digital signature of the OTP area. The digital signature is shown in Tables 2 and 3, and its length is 64 bytes.

[0059] Specifically, before launching the APP application, the OTP area data should be verified. First, the BOOT area program is launched, causing the first UUID and the first preset encrypted data to generate a first decryption key. If the first decryption key can read the second UUID, bootstrapping digital signature, public key, and OTP area signature, a preset hash algorithm is used to perform a hash operation on the second UUID, bootstrapping digital signature, and public key to obtain a first hash value. The first hash value is a data digest of the second UUID, bootstrapping digital signature, and public key information stored in the OTP. Since the OTP area signature is a digital signature formed by encrypting the hash value of the second UUID, bootstrapping digital signature, and public key (determined at production time) with a private key, the corresponding public key is needed to decrypt the OTP area signature to obtain a second hash value. The two hash values ​​are compared, resulting in a second comparison result (matching or not matching). If the first and second hash values ​​do not match, the program stops running. If the second comparison result matches, the OTP area protection is enhanced, ensuring that the OTP area data is not tampered with, and verification continues.

[0060] For example, using the first decryption key (ENC_OTP_KEY), decrypt the OTP_DATA.bin file containing all data stored in the OTP area, and read the first 144 bytes of data. This data includes the SM2 public key, the second UUID, and the bootstrap digital signature (BOOT signature). The data lengths of the public key and digital signature are shown in Table 2. A hash operation is performed on the second UUID, BOOT signature, and SM2 public key using a preset hash algorithm (SHA_256) to generate a first hash value (CUR_OTP_HASH). Then, the OTP area signature is decrypted using the preset national cryptographic algorithm (SM2) public key to obtain a second hash value (OTP_HASH). Next, the two hash values ​​are compared to obtain a second comparison result: if they match, they are not. If the first hash value and the second hash value do not match, the program stops running.

[0061] The discrepancy between the first and second hash values ​​may be due to physical or software attacks. Although OTP area data is written only once, physical attacks or storage failures can corrupt the data. For example, an attacker might tamper with the OTP area or chip registers using hardware methods (such as laser fault injection), causing corruption of the first or second UUID data, thus preventing the generation of a correct first decryption key, or even if a correct first decryption key is generated, the two will still be inconsistent. Even if the OTP data is not tampered with, errors during the burning process (such as incomplete data writing) will also render the decrypted data invalid. Attackers may also maliciously modify the BOOT area program through FLASH vulnerabilities, causing changes to the first preset encrypted data and generating a first decryption key inconsistent with the preset decryption key, thus disrupting the verification process. In other words, the consistency between the second hash value generated by decrypting the OTP area signature and the second UUID stored in the OTP area, the boot sector digital signature, and the first hash value generated by the public key mainly depends on whether a correct first decryption key can be generated. The correctness of the first decryption key needs to be determined by comparing whether the two hash values ​​are consistent. At the same time, comparing the hash values ​​can also further verify whether the boot sector program has been tampered with, and whether the public key of the preset national cryptographic algorithm has been damaged, through the boot sector digital signature.

[0062] Please see Figure 5 In some embodiments, the boot sector digital signature is generated by signing the hash value of the boot sector with the private key of the preset national cryptographic algorithm for digital signing, and the hash value of the boot sector is generated by hashing the boot program data (BOOT program data) with the preset hash algorithm.

[0063] Specifically, before the device is manufactured and firmware is burned, a bootloader is run on the developer's computer or server. After running, bootloader data (such as the binary file BL.bin) is obtained. A hash operation is performed using a preset hash algorithm (such as SHA-256) to obtain the hash value of the bootloader area (such as BL_HASH). Then, a signature is generated using the private key of a preset national cryptographic algorithm (such as SM2) to sign the hash value of the bootloader area (such as BL_HASH), resulting in a digital signature of the bootloader area (BL_SIG). The hash value of the bootloader area is a fixed-length 32-byte (256-bit) string, representing the unique, correct, and tamper-proof state of the bootloader at the time of manufacture.

[0064] In some embodiments, the startup method further includes: Step 31: Read the digital signature in the boot sector using the first decryption key; Step 32: Perform a hash operation on the bootstrap data using a preset hash algorithm to obtain a third hash value; Step 33: Decrypt the boot sector digital signature using the public key to obtain the fourth hash value; Step 34: Compare the third hash value and the fourth hash value to obtain the third comparison result, which may include whether they match or not. Step 35: If the third hash value and the fourth hash value are inconsistent, the program stops running.

[0065] Specifically, the boot sector digital signature (also known as the BOOT signature, such as BL_SIG) is read using the first decryption key (e.g., ENC_OTP_KEY). After reading, the boot sector digital signature is decrypted using the SM2 public key to obtain a fourth hash value (e.g., BL_HASH). This fourth hash value serves as a digital digest of the boot program data (e.g., BL.bin) stored in the OTP area during chip manufacturing, used to determine if there have been any changes in the current FLASH BOOT area. A third hash value (e.g., CUR_BL_HASH) is generated by hashing the binary file produced by the boot program (i.e., the boot program data, such as BL.bin) using a preset hash algorithm (SHA_256). The two hash values ​​are then compared to obtain a third comparison result. If the third and fourth hash values ​​do not match, it indicates that the boot sector data cannot correspond to the boot sector signature stored in the OTP area, posing a security risk to the program and requiring the program to be stopped. The operating procedures required for this verification process are stored in the boot program area.

[0066] Please see Figure 6 In some embodiments, the startup method for the energy storage device further includes: Step 41: Read the data in the application area that stores application data using the second decryption key. The second decryption key is generated based on the first UUID and the second preset encrypted data. The data in the application area includes the application header and application data. The application header includes the application signature. The application signature is generated by signing the application data with the private key of the preset national cryptographic algorithm for digital signing. Step 42: Hash the application data using a preset hash algorithm to obtain the fifth hash value; Step 43: Decrypt the application signature using the public key to obtain the sixth hash value; Step 44: Compare the fifth hash value and the sixth hash value to obtain the fourth comparison result, which may include whether they match or do not match; Step 45: If the fifth hash value and the sixth hash value are inconsistent, the program stops running.

[0067] The second preset encrypted data is a fixed string, or a fixed salt value, used to increase the complexity of the key derivation process and prevent rainbow table attacks (a table that determines the mapping relationship between plaintext and hash values ​​for a specific hash algorithm). The second preset encrypted data is embedded in the bootloader's algorithm logic. The second preset encrypted data and the first preset encrypted data are two different fixed salt values.

[0068] The second decryption key is a symmetric key generated in a similar way to the first decryption key. The second decryption key is obtained by using a key derivation algorithm (such as the HKDF algorithm) to generate the first UUID and the second preset encrypted data. Similarly, the second decryption key also has an encryption key generated by the second UUID and the second preset encrypted data, which is used to encrypt the application area data. If the second decryption key is consistent with the encryption key, the program verification result is more likely to be good.

[0069] The application header, or APP header data, is used to verify the application before it runs. Following it is the application data (also known as APP program data) used to execute specific functions. The application header includes the application signature (also known as the APP signature) and a hybrid signature (also known as a mixed signature) generated by hashing and encrypting the bootloader data and application data. The application signature is a digital signature generated by hashing and encrypting the application data separately.

[0070] Specifically, the data in the application area (APP area) (such as APP_DATA.bin, including the application header APP_HEAD.bin and application data APP.bin, where APP_HEAD.bin is encrypted by ENC_APP_KEY) is decrypted using a second decryption key (such as ENC_APP_KEY). The application signature in the application header (such as APP_SIG) is decrypted using a public key (such as SM2), yielding a sixth hash value (APP_HASH). This sixth hash value serves as a digital digest of the application signature in the signature data of the application header (APP area header) stored in the application area on the developer's computer or server during chip production, used to determine if the APP area of ​​the current FLASH has been altered. A fifth hash value (such as CUR_APP_HASH) is generated by hashing the application data (such as APP.bin) stored in the application area using a preset hash algorithm (SHA_256). The two hash values ​​are then compared to obtain a fourth comparison result. If the fifth and sixth hash values ​​do not match, it indicates that the application data cannot correspond to the legitimate application data stored in the application area, posing a security risk to the program, and the program should be stopped. The operating procedures required for this verification process are still stored in the bootloader area.

[0071] Among them, APP.bin is an image file containing pure binary machine code generated after the APP program, i.e., the source code, is compiled and linked. It is stored in the APP area application during the firmware generation stage.

[0072] Please see Figure 7 In some embodiments, the application header also includes a hybrid data signature, which is generated by signing application data and bootstrap data with a private key of a preset national cryptographic algorithm for digital signing. The method further includes: Step 51: Hash the application area and bootloader data using a preset hash algorithm to obtain the seventh hash value; Step 52: Decrypt the mixed data signature using the public key to obtain the eighth hash value; Step 53: Compare the seventh hash value and the eighth hash value to obtain the fifth comparison result. The fourth comparison result includes whether they match or do not match. Step 54: If the seventh hash value and the eighth hash value are inconsistent, the program stops running.

[0073] The hybrid data signature is a separate digital signature from the application header, obtained after the application header has been decrypted using the second decryption key. Hybridization is not a superposition of two signatures, but rather a single digital signature resulting from the hashing of application data and bootstrap data using a private key.

[0074] For example, when generating firmware, the bootloader data BL.bin and the application data APP.bin are merged to generate mixed data ALL.bin. ALL.bin is then hashed using the SHA-256 algorithm to generate the digital digest of ALL_HASH, which is then encrypted with the SM2 private key to generate ALL.SIG, i.e., the mixed data signature.

[0075] Specifically, using the public key (SM2) to decrypt the mixed data signature (e.g., ALL_SIG) in the application header yields the eighth hash value (ALL_HASH). This eighth hash value serves as a digital digest of the mixed data signature in the application header (APP header) signature data stored in the application area on the developer's computer or server during chip production. It is used to determine if there have been any changes to the APP and BOOT areas of the current FLASH memory. Using a preset hash algorithm (SHA_256), a hash operation is performed on the new code (e.g., ALL.bin) formed by concatenating the application data (e.g., APP.bin) stored in the application area and the data in the bootloader area (e.g., BL.bin), i.e., the application data and bootloader data. This generates the seventh hash value (e.g., CUR_ALL_HASH). The two hash values ​​are then compared to obtain the fifth comparison result. If the seventh and eighth hash values ​​do not match, it indicates that the application data and bootloader data cannot correspond to the legitimate application data stored in the application header, posing a security risk to program execution, and program execution should be stopped. The operating procedures required for this verification process are still stored in the bootloader area.

[0076] In some embodiments, the startup method further includes: During program execution, at preset intervals, a step is performed to compare the first UUID and the second UUID to obtain the first comparison result.

[0077] Specifically, the program includes a bootloader and the application. The preset cycle refers to the application's runtime cycle; that is, each time the application executes, the consistency between the first UUID and the second UUID should be verified. Additionally, the bootloader should also verify the consistency between the first and second UUIDs during runtime. Only by ensuring the consistency between the first and second UUIDs can the correspondence between the program and the hardware be guaranteed, thus ensuring its legitimacy.

[0078] Please see Figure 8 The following flowchart provides a complete explanation of the startup verification process for energy storage devices.

[0079] The entire verification process includes verifying the OTP area data, BOOT program data, APP program data, and the mixed data generated by concatenating APP program data and BOOT program data. This includes the loading of the BOOT program and the APP program. When the program starts loading or reloads, the consistency of the registers and the UUID written in the OTP area should be verified.

[0080] After the chip powers on, the BOOT program is loaded first. Running the BOOT program reads the first UUID from the chip's registers. Using this first UUID and a fixed salt "!@#$%^&**&^%$#@!", the HKDF algorithm is used to generate the first decryption key ENC_OTP_KEY for the OTP area data. This key is used to decrypt the read OTP area data, which is often an encrypted binary file named OTP_DATA.bin. The data is then decrypted using ENC_OTP_KEY, yielding the SM2 public key, the second UUID, the BOOT signature, and the OTP area signature.

[0081] After successfully reading and decrypting the OTP area data, a SHA-256 operation is performed on the SM2 public key + UUID + BOOT signature in the OTP area data to obtain the first hash value CUR_OTP_HASH. Then, the OTP area signature is decrypted using the SM2 public key to obtain the second hash value OTP_HASH.

[0082] The program compares the first UUID with the second UUID to obtain the first comparison result. If they do not match, the program stops running. It then compares the first hash value with the second hash value to obtain the second comparison result. If they do not match, the program stops running. (In the overall flowchart, the order is to obtain the second comparison result first, then the first comparison result; the order can be reversed.)

[0083] If the first UUID and the second UUID are the same and the first hash value is the same as the second hash value, then the first decryption key is the same as the preset encryption key generated during the firmware generation stage. The OTP area data has not been tampered with and corresponds to the hardware, so the next stage of verification can be carried out.

[0084] The SHA-256 algorithm is used to calculate the hash of the BOOT program data (BL.bin) stored in the BOOT area, resulting in the third hash value CUR_BL_HASH. The SM2 public key is then used to decrypt the BOOT signature read from the first decryption key, resulting in the fourth hash value BL_HASH.

[0085] The third hash value is compared with the fourth hash value to obtain the third comparison result. If they do not match, the program stops running. If the third comparison result matches, the program continues to the next stage.

[0086] Using the first UUID and the salt value "qwertyu!@#$%^&", the HKDF algorithm is used to generate the decryption key ENC_APP_KEY for the APP area data. The ENC_APP_KEY is then used to decrypt the header data of the APP area, yielding the APP signature and the mixed signature.

[0087] The SHA-256 algorithm is used to calculate the hash of the APP program data APP.bin stored in the APP area, resulting in the fifth hash value CUR_APP_HASH. The APP signature read from the second decryption key is then decrypted using the SM2 public key, resulting in the sixth hash value APP_HASH.

[0088] The hash value is compared with the fifth and sixth hash values ​​to obtain the fourth comparison result. If they do not match, the program stops running. If the fourth comparison result matches, the program continues to the next stage.

[0089] After the above BOOT program is verified, the APP program can be loaded to execute the functions of the energy storage device. After running the program, a new APP program data APP.bin is obtained.

[0090] The first UUID is compared with the second UUID again to obtain the updated first comparison result. If they do not match, it proves that the APP has a security problem and the APP should stop running. If the updated first comparison result matches, proceed to the next stage.

[0091] The hash value of the mixed data generated by concatenating the BOOT program data and the new APP program data is calculated using the SHA-256 algorithm to obtain the seventh hash value CUR_ALL_HASH. The mixed signature in the APP header data read by the second decryption key is decrypted using the SM2 public key to obtain the eighth hash value ALL_HASH.

[0092] The hash value will be compared with the seventh and eighth hash values ​​to obtain the fifth comparison result. If they do not match, the program will stop running. If the fifth comparison result matches, the verification result indicates that the program has legitimacy and integrity, and the APP program is running normally.

[0093] Finally, since the results of running APP.bin may differ each time, the first and second UUIDs and the sixth and seventh hash values ​​should be continuously and periodically compared during the process. If any of them are inconsistent, the process should be stopped immediately.

[0094] The startup method for the energy storage device provided in this application embodiment binds the APP to the hardware via UUID. Upon power-up, the chip's UUID is read from the BOOT area and compared with the UUID stored in the OTP area for verification. During APP operation, the UUID's legitimacy is periodically verified, ensuring that even if the program is illegally obtained, it cannot run on other chips. Data integrity and legitimacy are verified through data signature. After loading the BOOT area program, the BOOT signature is verified first, followed by the APP signature, and finally, the BOOT+APP hybrid digital signature is verified in the APP program, ensuring the program is not tampered with. Furthermore, storing core private data such as digital signatures, public keys, and UUIDs in the OTP area leverages the single-write characteristic of the OTP area to prevent data tampering. Signature verification of the OTP area data enhances its protection, ensuring the OTP area data remains tamper-proof. Specifically, a preset hash algorithm is used to generate hash values ​​for the OTP, BOOT, and APP areas. A preset national cryptographic algorithm is used for digital signature, which encrypts the concatenated OTP area data to ensure data security. The first decryption key is generated using the chip's UUID and a fixed salt value. Because each device has a different key, security is greatly enhanced. During APP operation, in addition to periodically verifying the UUID, signature verification is also performed to ensure that the APP program is not tampered with during operation.

[0095] The startup method for energy storage devices provided in this application allows for digital signature verification of all area data before operation, preventing program tampering. Simultaneously, verification also prevents program copying. For example, the entire APP+BOOT+OTP area of ​​the program can be read and burned onto another chip. When verifying the OTP again, because the chip has been replaced, the chip's UUID is inconsistent with the UUID stored in the OTP. The BOOT program cannot use the UUID to calculate the accurate key, and due to the incorrect key, the OTP area data cannot be decrypted to obtain the correct data. If only the BOOT+APP area data is copied, since BOOT requires signature verification before operation, and the signature is stored in the OTP area, the new chip's OTP area data will inevitably not include the BOOT signature information from the legitimate chip, thus preventing normal operation. If only the APP area is copied and the BOOT program is loaded manually, the APP area program needs to verify the BOOT+APP area signature information during operation. Since the BOOT is an illegitimate program, verification will fail. This ensures that the program cannot run normally after being tampered with or copied, avoiding security risks and ultimately protecting the program within the FLASH memory.

[0096] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0097] This application embodiment also provides a starting device 300 for an energy storage device, used to perform the steps in the above-described starting method for an energy storage device. Please refer to... Figure 9 , Figure 9 This is a schematic diagram of a module of a starting device 300 for an energy storage device provided in an embodiment of this application. The starting device 300 for the energy storage device includes: The read module is used to read the first UUID in the chip's registers and the second UUID stored in the chip's OTP area when the program starts. The comparison module is used to compare the first UUID and the second UUID to obtain a first comparison result, wherein the first comparison result includes whether they are consistent or inconsistent. The processing module is configured to stop the program if the first UUID and the second UUID are inconsistent.

[0098] It should be noted that the specific details of each module unit in the starting device 300 of the above-mentioned energy storage device have been described in detail in the embodiments of the starting method of the above-mentioned energy storage device, and will not be repeated here.

[0099] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement a... There may be multiple modules or units. Furthermore, each module or unit can be an integral module containing the functions of that module or unit. The starting device 300 of the energy storage device can be integrated into a terminal or server that has storage and a processor and thus computing capabilities, or the starting device 300 of the energy storage device can be that terminal or server.

[0100] This application also provides a computer-readable storage medium for storing a computer program. This computer-readable storage medium can be applied to an energy storage device, and the computer program causes the energy storage device to execute the corresponding processes in the energy storage device startup method described in the embodiments of this application; for brevity, these will not be elaborated further here.

[0101] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. The processor of the energy storage device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the energy storage device to perform the corresponding process in the energy storage device startup method of the embodiments of this application. For simplicity, further details are omitted here.

[0102] This application also provides a computer program including computer instructions stored in a computer-readable storage medium. The processor of the energy storage device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the energy storage device to perform the corresponding process in the energy storage device startup method of this application. For simplicity, further details are omitted here.

[0103] It should be understood that the processor in this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0104] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), SynchLink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0105] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0106] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0107] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0109] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0110] In addition, the functional units in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0111] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an energy storage device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0112] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for starting up an energy storage device, characterized in that, include: When the program starts, it reads the first UUID from the chip's registers and the second UUID stored in the chip's OTP area; The first UUID and the second UUID are compared to obtain a first comparison result, which includes whether they match or do not match. If the first UUID and the second UUID are inconsistent, the program will stop running.

2. The starting method for the energy storage device according to claim 1, characterized in that, The program includes a bootloader or application program. Data in the OTP area is encrypted using a preset encryption key, which is generated based on the second UUID and the first preset encrypted data. Reading the first UUID from the chip's registers and the second UUID stored in the chip's OTP area includes: Read the first UUID from the chip's register; A first decryption key is generated based on the first UUID and the first preset encrypted data; The second UUID stored in the OTP area of ​​the chip is read using the first decryption key; If the reading is successful, proceed to the step of comparing the first UUID and the second UUID to obtain the first comparison result; If the read operation fails, the program will stop running.

3. The starting method for the energy storage device according to claim 2, characterized in that, The OTP area stores the second UUID, the boot sector digital signature, the public key of the preset national cryptographic algorithm for digital signature, and the OTP area signature. The OTP area signature is generated by hashing the second UUID, the boot sector digital signature, and the public key using a preset hash algorithm. The method further includes: The second UUID, the boot sector digital signature, the public key, and the OTP sector signature are read using the first decryption key. A first hash value is obtained by performing a hash operation on the second UUID, the boot sector digital signature, and the public key using a preset hash algorithm. The public key is used to decrypt the OTP zone signature to obtain the second hash value; The first hash value and the second hash value are compared to obtain a second comparison result, which includes whether they match or do not match. If the first hash value and the second hash value are inconsistent, the program stops running.

4. The starting method for the energy storage device according to claim 3, characterized in that, The boot sector digital signature is generated by signing the hash value of the boot sector with the private key of the preset national cryptographic algorithm for digital signing. The hash value of the boot sector is generated by hashing the boot sector data using a preset hash algorithm.

5. The starting method for the energy storage device according to claim 3, characterized in that, The method further includes: The boot sector digital signature is read using the first decryption key; A third hash value is obtained by performing a hash operation on the bootloader data using a preset hash algorithm; The public key is used to decrypt the boot sector digital signature to obtain the fourth hash value; The third hash value and the fourth hash value are compared to obtain a third comparison result, which may include whether they match or not. If the third hash value and the fourth hash value are inconsistent, the program will stop running.

6. The starting method for the energy storage device according to claim 3, characterized in that, The method further includes: The application area data storing application data is read using a second decryption key. The second decryption key is generated based on a first UUID and a second preset encrypted data. The data in the application area includes an application header and application data. The application header includes an application signature. The application signature is generated by signing the application data with a private key of a preset national cryptographic algorithm for digital signing. The application data is hashed using a preset hash algorithm to obtain a fifth hash value; Use the public key to decrypt the application signature to obtain the sixth hash value; The fifth hash value and the sixth hash value are compared to obtain a fourth comparison result, which includes whether they match or do not match. If the fifth hash value and the sixth hash value are inconsistent, the program will stop running.

7. The starting method for the energy storage device according to claim 6, characterized in that, The application header also includes a hybrid data signature, which is generated by signing application data and bootloader data using a private key of a preset national cryptographic algorithm for digital signing; the method further includes: The application area and the bootloader data are hashed using a preset hash algorithm to obtain a seventh hash value; The public key is used to decrypt the mixed data signature to obtain the eighth hash value; The seventh hash value and the eighth hash value are compared to obtain a fifth comparison result, wherein the fourth comparison result includes whether they match or do not match. If the seventh hash value and the eighth hash value are inconsistent, the program will stop running.

8. The starting method for the energy storage device according to claim 1, characterized in that, Also includes: During program execution, the step of comparing the first UUID and the second UUID to obtain the first comparison result is performed once every preset period.

9. A starting device for an energy storage device, characterized in that, include: The read module is used to read the first UUID in the chip's registers and the second UUID stored in the chip's OTP area when the program starts. The comparison module is used to compare the first UUID and the second UUID to obtain a first comparison result, wherein the first comparison result includes whether they are consistent or inconsistent. The processing module is configured to stop the program if the first UUID and the second UUID are inconsistent.

10. An energy storage device, characterized in that, The device includes a battery and a motherboard, the motherboard having a processor and a memory, the memory storing a computer program, and the processor executing the method as described in any one of claims 1-8 by calling the computer program stored in the memory.

11. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in claims 1-8.

Images