Software startup verification method, software startup method, device, equipment and medium

Abstract

The application provides a software startup verification method, a software startup method, a device, equipment and a medium, and belongs to the field of information security. The software startup verification method comprises the following steps: running a startup header file of software, the startup header file being a data structure generated based on at least one program module in a software development and compilation stage; determining a verification result of the startup header file based on a first cryptography algorithm; in response to the verification result of the startup header file being passed, outputting a first instruction for indicating to start the software; determining a verification result of the at least one program module based on a second cryptography algorithm; and in response to the verification result of the at least one program module being failed, outputting a second instruction for indicating to prohibit running the program module. The software startup verification method provided by the application can shorten the waiting time of startup verification, and does not need to rely on hardware.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of information security, and in particular to a software startup verification method, a software startup method, an apparatus, a device and a medium. BACKGROUND

[0002] Energy saving and emission reduction is the key to the sustainable development of the automobile industry. Electric vehicles have become an important part of the sustainable development of the automobile industry due to their energy saving and environmental protection advantages. For electric vehicles, battery technology is an important factor for their development.

[0003] For an electric device containing a battery, in order to ensure the safe operation of the software loaded by the system, the integrity and security of the software need to be checked before the software is started to identify whether the software has been tampered with without authorization. However, since the software usually includes multiple program modules, a lot of time is required for checking, which increases the waiting time of the user. SUMMARY

[0004] The present application aims to at least solve one of the technical problems in the background art. To this end, one object of the present application is to provide a software startup verification method, a software startup method, an apparatus, a device and a medium to improve the problem of long software startup time.

[0005] Embodiments of the first aspect of the present application provide a software startup verification method, the software including at least one program module, the method comprising: running a startup header file of the software, the startup header file being a data structure generated based on at least one program module in the software development and compilation phase; determining a verification result of the startup header file based on a first cryptographic algorithm; in response to the verification result of the startup header file being passed, outputting a first instruction for indicating to start the software; determining a verification result of the at least one program module based on a second cryptographic algorithm; and in response to the verification result of the at least one program module being failed, outputting a second instruction for indicating to prohibit running the program module that fails the verification.

[0006] According to some embodiments of the present application, the verification method is completely implemented by software and does not need to rely on HSM, which can simplify the hardware arrangement and hardware cost. Since the startup header file is generated in the software development and compilation phase and contains information associated with the software program module, it has high reliability and small file size, and the verification time required is short and the computing power required is small, which can shorten the waiting time for startup verification. In addition, the program modules in the software are still verified after the software is started, thereby ensuring the integrity and reliability of the software verification.

[0007] In some embodiments, determining the verification result of the startup header file based on the first cryptographic algorithm includes: determining first verification information based on the first cryptographic algorithm and the startup header file, wherein the first verification information is used to verify the startup header file; and determining that the verification result of the startup header file is passed if the first verification information matches the first preset information; wherein the first preset information is verification information generated during the software development and compilation stage based on the first cryptographic algorithm and the startup header file. Comparing the first verification information calculated based on the cryptographic algorithm with the first preset information generated during the software development stage allows for a more accurate determination of whether the software has been tampered with, thereby improving the accuracy and reliability of software startup verification.

[0008] In some embodiments, first verification information is determined based on a first cryptographic algorithm and a startup header file. The first verification information used to verify the startup header file includes: calling a preset key; the preset key is a key determined based on the first cryptographic algorithm and pre-set during the software development and compilation phase; and determining the first verification information based on the first cryptographic algorithm, the startup header file, and the preset key. The generation of the preset key occurs during the software development and compilation phase, and is therefore random and unpredictable. Using the preset key in the encryption process ensures the uniqueness and security of the verification information, thereby more reliably verifying the integrity and origin of the startup header file and improving the credibility of the verification result.

[0009] In some embodiments, determining the verification result of at least one program module based on the second cryptographic algorithm includes: for any one of the at least one program module, determining second verification information for that program module based on the second cryptographic algorithm; and determining that the verification result of at least one program module fails if the second verification information is inconsistent with the second preset information in the startup header file. The second preset information is verification information corresponding to that program module generated based on the second cryptographic algorithm during the software development and compilation phase. Continuing to verify each program module in the software after startup allows for the verification of each program module without affecting the software's waiting time, thereby achieving the integrity and reliability of the entire software verification.

[0010] In some embodiments, the second cryptographic algorithm is a different encryption algorithm from the first cryptographic algorithm. Using different cryptographic algorithms, based on the characteristics and security requirements of the startup header file and program modules, can better adapt to these different needs, thereby balancing the reliability and efficiency of integrity verification.

[0011] In some embodiments, the startup header file of the running software, which is generated during the software development and compilation phase and before the data structures generated based on at least one program module, also includes: running a preset startup verification program, which is a program generated during the software development and compilation phase and placed in a write-protected storage area. Pre-setting the startup verification program during the software development and compilation phase can determine trust anchors as early as possible, helping to form a highly reliable trust chain, improving the reliability of verification, and also facilitating further simplification of verification methods and improvement of verification efficiency.

[0012] An embodiment of the second aspect of this application provides a software startup method. The software includes at least one program module. The method includes: responding to receiving a wake-up command instructing the software to start; and executing the aforementioned software startup verification method. By executing the software startup verification method after receiving the wake-up command instructing the software to start, the integrity and security of the software can be ensured, the risk of unauthorized modifications leading to system performance degradation or security problems can be reduced, and the reliability of software operation can be improved.

[0013] In some embodiments, the software startup method further includes: starting the software in response to receiving a first instruction indicating that the software should be started. Starting the software after the startup header file verification is successful can save startup time and improve verification efficiency.

[0014] In some embodiments, the software startup method further includes: in response to receiving a second instruction indicating that the execution of a program module that failed verification should be prohibited, prohibiting the execution of the program module. Promptly prohibiting the execution of a program module in the event of a verification failure can effectively reduce the risks and hidden dangers that may result from software operation, and improve the security and reliability of software startup.

[0015] An embodiment of the third aspect of this application provides a software startup verification apparatus, comprising a running unit, a first verification unit, a first output unit, a second verification unit, and a second output unit: the running unit is configured to run a startup header file of the software, the startup header file being a data structure generated based on at least one program module during the software development and compilation phase; the first verification unit is configured to determine the verification result of the startup header file; the first output unit is configured to output a first instruction indicating startup of the software in response to a successful verification result of the startup header file; the second verification unit is configured to determine the verification result of at least one program module; and the second output unit is configured to output a second instruction indicating prohibition of running the program module that failed verification in response to a failed verification result of at least one program module.

[0016] An embodiment of the fourth aspect of this application provides a software startup apparatus, which includes a receiving unit and a software startup verification unit. The receiving unit is configured to receive a wake-up command indicating the startup of software; the software startup verification unit is configured to execute the above-described software startup verification method in response to the receiving unit receiving the wake-up command.

[0017] An embodiment of the fifth aspect of this application provides a computing device comprising: at least one processor; and at least one memory communicatively connected to the at least one processor, the at least one memory storing instructions which, when executed individually or jointly by the at least one processor, cause the computing device to perform the aforementioned software startup verification method or software startup method.

[0018] An embodiment of the sixth aspect of this application provides a computer-readable storage medium storing instructions that, when executed individually or jointly by one or more processors of a computing device, cause the computing device to perform the above-described software startup verification method or software startup method.

[0019] An embodiment of the seventh aspect of this application provides a computer program product including instructions that, when executed individually or jointly by one or more processors of a computing device, cause the computing device to perform the aforementioned software startup verification method or software startup method.

[0020] An embodiment of the eighth aspect of this application provides a battery management system, which includes the above-described software startup verification device, the above-described software startup device, the above-described computing device, the above-described computer-readable storage medium, or the above-described computer program product.

[0021] An embodiment of the ninth aspect of this application provides a battery device, which includes the above-described software startup verification device, software startup device, computing device, computer-readable storage medium, computer program product, or the above-described battery management system.

[0022] An embodiment of the tenth aspect of this application provides a vehicle that includes the above-described software startup verification device, software startup device, computing device, computer-readable storage medium, computer program product, battery management system, or battery device.

[0023] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0024] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments disclosed in this application and should not be construed as limiting the scope of this application.

[0025] Figure 1 A flowchart illustrating a software startup verification method according to some embodiments of this application;

[0026] Figure 2 This is a flowchart of a software startup method according to some embodiments of this application;

[0027] Figure 3 A block diagram of a software-initiated verification apparatus according to some embodiments of this application;

[0028] Figure 4 This is a block diagram of a software startup apparatus according to some embodiments of this application;

[0029] Figure 5 This is a flowchart illustrating the software startup method of some other embodiments of this application.

[0030] Explanation of reference numerals in the attached figures:

[0031] Software startup verification method 100, software startup method 200, software startup verification device 300, running unit 310, first verification unit 320, first output unit 330, second verification unit 340, second output unit 350, software startup device 400, receiving unit 410, and software startup verification unit 420. Detailed Implementation

[0032] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0034] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0035] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0036] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0037] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0038] In the description of the embodiments of this application, the technical terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of this application and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0039] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0040] Currently, judging from market trends, battery applications are becoming increasingly widespread. Batteries are not only used in energy storage systems such as hydropower, thermal power, wind power, and solar power plants, but also extensively in electric vehicles such as electric bicycles, electric motorcycles, and electric cars, as well as in military equipment and aerospace. With the continuous expansion of battery applications, market demand is also constantly increasing.

[0041] Before running software, electrical devices need to pass a startup verification program to check the software stored in memory to ensure its reliability. For example, a vehicle has a battery system, including a battery management system. When the vehicle starts, a hardware security module (HSM) verifies each program module in the battery management system one by one. If all verifications pass, the battery management system is considered untampered, and it starts and runs. However, this verification method requires significant computing power and is time-consuming, increasing startup time and thus user waiting time.

[0042] To address the above problems, this application provides a software startup verification method. The software includes at least one program module. The verification method includes: running the software's startup header file, which is a data structure generated during the software development and compilation phase based on at least one program module; determining the verification result of the startup header file based on a first cryptographic algorithm; outputting a first instruction to indicate software startup in response to a successful verification result of the startup header file; determining the verification result of at least one program module based on a second cryptographic algorithm; and outputting a second instruction to indicate prohibition of running the failed program module in response to a failed verification result of at least one program module. This embodiment uses a pure software approach to verify software startup, eliminating the need for hardware security modules and reducing hardware costs. Software startup is allowed once the startup header file verification is successful. Because the startup header file is small, the verification comparison time is short, reducing computational requirements and shortening startup waiting time. Furthermore, after software startup, each program module in the software continues to be verified one by one, ensuring the integrity and reliability of software verification.

[0043] The software startup verification method disclosed in this application can be used, but is not limited to, in electrical devices such as vehicles, ships, or aircraft, which helps to reduce the startup waiting time of electrical devices.

[0044] This application provides an electrical device that uses a battery as a power source. The electrical device can be, but is not limited to, mobile phones, tablets, laptops, electric toys, power tools, electric vehicles, electric cars, ships, spacecraft, etc. Electric toys can include stationary or mobile electric toys, such as game consoles, electric car toys, electric ship toys, and electric airplane toys, etc. Spacecraft can include airplanes, rockets, space shuttles, and spacecraft, etc.

[0045] Please refer to Figure 1 , Figure 1 A flowchart of a software startup verification method provided for some embodiments of this application.

[0046] This application provides a software startup verification method 100, such as... Figure 1 As shown, the software startup verification method 100 includes:

[0047] S110. The startup header file of the running software. The startup header file is a data structure generated during the software development and compilation phase based on at least one program module.

[0048] S120. Determine the verification result of the startup header file based on the first cryptographic algorithm;

[0049] S130. In response to the successful verification of the startup header file, output the first instruction to indicate the startup software.

[0050] S140. Determine the verification result of at least one program module based on the second cryptographic algorithm;

[0051] S150. In response to the failure of the verification result of at least one program module, output a second instruction to indicate that the program module that failed the verification is prohibited from running.

[0052] The software in this embodiment can be system software (e.g., a control system), a single program module (e.g., an application program) designed for a specific task, or a collection of multiple program modules. The software package contains one or more program modules, each of which can represent a part of the software, such as a submodule or an application. In some embodiments, the software can be a battery management system or a battery control system for a battery device, or a vehicle control system, depending on the application scenario and object; this application does not impose any limitations on this.

[0053] Software startup verification is an important security measure that verifies whether software has been tampered with, damaged, or maliciously attacked before it starts. It can detect problems before the software runs, avoiding security risks and operational anomalies caused by software tampering.

[0054] The startup header file is generated during software development, specifically during the compilation and linking of each program module. The compiler and linker generate a startup header file containing all necessary metadata based on the program module's code and resources. Once generated, the startup header file can be written to the device's memory. In some embodiments, the startup header file may also include encryption or verification information for each program module to provide authentication functionality.

[0055] The first cryptographic algorithm and the second encryption algorithm are both cryptographic verification algorithms, which are mathematical methods and calculation rules used to encrypt and decrypt information, and to achieve data confidentiality, integrity, and authentication. In step S120, the verification result of the startup header file refers to the result of performing an integrity verification on the startup header file. The verification result can be either pass or fail, which allows identification based on the verification result whether the software has been tampered with or damaged before startup. The first cryptographic algorithm can be one or more of symmetric encryption algorithms, asymmetric encryption algorithms, and hash algorithms. It is understood that the terms "first" and "second" are used here only for ease of distinction and do not imply a limitation on the algorithm types. In the embodiments of this application, the first cryptographic algorithm and the second encryption algorithm can be the same cryptographic algorithm or different cryptographic algorithms.

[0056] In step S130, if the startup header file verification passes, it means that the startup header file meets the requirements for integrity and security, thus preliminarily determining that the software verification has passed, and a first instruction can be output to instruct the software to start running. In some embodiments, the startup header file verification can be performed by the bootloader. After successful verification, the bootloader will issue a first instruction to transfer control to the software's entry point, thereby starting the software. The first instruction can be a jump instruction. If the startup header file verification fails, the bootloader may not issue a jump instruction to transfer control to the software's entry point, thus refusing to start the software.

[0057] In step S140, each program module in the software can be verified sequentially using a second cryptographic algorithm, or multiple program modules can be verified simultaneously. The second cryptographic algorithm used to verify the program modules can employ symmetric encryption algorithms, hash algorithms, asymmetric encryption algorithms, or other cryptographic algorithms to determine whether each program module in the software has been tampered with. By verifying at least one program module, the integrity of the software verification can be ensured.

[0058] In step S150, if the verification result of any program module fails, the verification is deemed to have failed, the program module is considered to have been tampered with, and a second instruction is issued to prohibit the operation of the program module that failed the verification. If all verifications are successful, the startup verification program is completely exited, and the software continues to run normally. In some embodiments, the bootloader can continue to perform the verification operation for each program module in the background or in a low-priority thread while the software is starting or running. This can improve verification efficiency and does not occupy startup waiting time. Moreover, when a program module fails the verification, only that program module can be prohibited from running, which can minimize the impact on the operation of other normal program modules.

[0059] This application presents a pure software verification method that does not rely on hardware, simplifying hardware deployment and reducing hardware costs. Since the startup header file is generated based on the program modules in the software during the software development and compilation phase, it contains key information and configurations for software startup. Verification results of the startup header file can accurately reflect whether the software has been tampered with. By first verifying the software's startup header file and allowing the software to start only when the verification result is satisfactory, the waiting time required for software startup verification can be significantly shortened. This is because the startup header file is small, requiring less time for verification and less computational power. Furthermore, continuing to verify the program modules in the software after startup improves the completeness and reliability of software verification. Additionally, by using a second instruction to specifically disable program modules that fail verification, the impact on the operation of other normal program modules can be minimized, thus improving software usability.

[0060] According to some embodiments of this application, step S120 includes: determining first verification information based on a first cryptographic algorithm and a startup header file; the first verification information is used to verify the startup header file; in response to the first verification information being consistent with the first preset information, determining that the verification result of the startup header file is passed; wherein, the first preset information is verification information generated based on the first cryptographic algorithm and the startup header file during the software development and compilation stage.

[0061] Verification of the startup header file can be achieved using a first cryptographic algorithm. In some embodiments, during the software development and compilation phase, a suitable first cryptographic algorithm is selected to process the startup header file, generating a feature value or digest. This generated feature value or digest is then saved as first preset information. This information is typically stored in a secure location so that it can be read during software startup and compared with the first verification information generated during the verification phase of the startup header file.

[0062] If the first verification information is consistent with the first preset information, the verification result of the startup header file is determined to be successful; if the first verification information is inconsistent with the first preset information, the verification result of the startup header file is determined to be unsuccessful.

[0063] By comparing the first verification information calculated based on cryptographic algorithms with the first preset information generated during the software development stage, it is possible to more accurately determine whether the software has been tampered with, thereby improving the accuracy and reliability of software startup verification.

[0064] According to some embodiments of this application, first verification information is determined based on a first cryptographic algorithm and a startup header file; the first verification information is used to verify the startup header file, including: calling a preset key; the preset key is a key determined based on the first cryptographic algorithm and preset during the software development and compilation stage; the first verification information is determined based on the first cryptographic algorithm, the startup header file, and the preset key.

[0065] The default key is generated during the software development and compilation phase using a primary cryptographic algorithm. This algorithm can be a hash algorithm, a symmetric encryption algorithm, or an asymmetric encryption algorithm. The default key is typically generated using a secure random number generator, ensuring its randomness and unpredictability. The default key can be a symmetric key or the private key portion of an asymmetric key. The generated default key is usually securely stored in a specific location within the software or stored in encrypted form on an external device or server to prevent unauthorized access.

[0066] The preset key can be retrieved either by reading it from a storage location or by communicating with an external device or server.

[0067] During the software development and compilation phase, a first cryptographic algorithm (such as a symmetric encryption algorithm) can be used, with the startup header file as plaintext input and a preset key as the encryption key. After processing by the encryption algorithm, the encrypted startup header file is obtained. During the software startup verification phase, the same first cryptographic algorithm and preset key as in the software development and compilation phase are used to perform encryption calculations on the read startup header file, obtaining the corresponding first verification information. If the software has not been tampered with, the first verification information should be consistent with the first preset information; at this point, the verification result of the startup header file can be determined as passed.

[0068] Preset keys are typically generated during the software development and compilation phase. They are random and unpredictable. Using preset keys in the encryption process ensures the uniqueness and security of the verification information, thereby more reliably verifying the integrity and origin of the startup header file and improving the credibility of the verification results.

[0069] According to some embodiments of this application, step S140 includes:

[0070] For any one of the program modules in at least one program module, the second verification information of the program module is determined based on the second cryptographic algorithm;

[0071] In response to the inconsistency between the second verification information of the program module and the second preset information in the startup header file, it is determined that the verification result of at least one program module is unsuccessful; wherein, the second preset information is the verification information corresponding to the program module generated based on the second cryptographic algorithm during the software development and compilation stage.

[0072] In some embodiments, program modules in the software can be verified sequentially, for example, the next program module is verified only after the previous program module passes the verification, and subsequent verification steps are stopped when a verification result fails, in order to save computing resources. In other embodiments, multiple program modules in the software can also be verified synchronously in parallel, which can save verification time.

[0073] The second preset information and the second verification information are verification information calculated using the second cryptographic algorithm on the corresponding program modules. It is understood that when there are multiple program modules, the second preset information and the second verification information can also be multiple pairs, each corresponding one-to-one with a different program module.

[0074] The second pre-defined information is recorded in the startup header file. This means that during the software development and compilation phase, when the startup header file is generated, the second pre-defined information corresponding to each program module in the software is calculated and generated based on a second cryptographic algorithm. The startup header file is loaded into memory early in the software startup process, allowing for rapid access to the second pre-defined information and reducing waiting time during verification. Furthermore, the startup header file is typically protected to a certain extent, for example, through encryption and digital signatures to ensure its security and integrity. Recording the second pre-defined information in the startup header file leverages these protection mechanisms to enhance the security of the verification information.

[0075] After the software starts, each program module in the software is verified. This can be done without affecting the software's waiting time, thereby ensuring the integrity and reliability of the entire software verification.

[0076] According to some embodiments of this application, the second cryptographic algorithm is a different encryption algorithm from the first cryptographic algorithm used to verify the startup header file.

[0077] The startup header file stores information used to verify the integrity and authenticity of the software. Since the software can run after the startup header file has passed verification, the integrity and reliability requirements for its verification are relatively higher. The verification of program modules is performed after the startup header file has passed verification, and the verification strength and requirements differ from those for the startup header file. Therefore, different cryptographic algorithms can be used to better adapt to these different needs, based on the characteristics and security requirements of the startup header file and program modules respectively. For example, the startup header file may require higher encryption strength and stability, while program modules may prioritize efficiency and flexibility.

[0078] In some embodiments, the first cryptographic algorithm is a block cipher algorithm, and the first verification information is a message authentication code.

[0079] Block ciphers are encryption algorithms that break plaintext down into fixed-size blocks of data and then encrypt each block individually. Each block is encrypted independently, typically using the same key. Common block cipher algorithms include the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), and Triple Data Encryption (TDE).

[0080] A message authentication code (MAC) is a short data string used to verify message integrity and sender identity. It is typically generated by hashing the message using a key, ensuring the message has not been tampered with during transmission. If the message and MAC are sent together, the receiver can recalculate the MAC (first verification information) using the same preset key and compare it with the received MAC (first preset information) to verify message integrity. MACs can verify the origin of data, ensuring it was sent by a known, trusted sender, which helps prevent man-in-the-middle attacks and other identity forgery attacks. Block cryptography algorithms are designed for fast processing of large amounts of data, are suitable for implementation in both hardware and software, and are simpler and easier to understand and implement than other algorithms. Therefore, they can generate MACs more efficiently, achieving a balance between security, efficiency, and ease of use.

[0081] In some embodiments, the second cryptographic algorithm is a hash algorithm, and the second preset information is the hash value calculated by the corresponding program module based on the hash algorithm.

[0082] A hash algorithm is a one-way encryption algorithm that accepts input data of arbitrary length, processes it, and generates a unique output value of fixed length. Hash algorithms include MD5, SHA-1, SHA-256, and SHA-3. A hash value is the result of a hash algorithm processing a specific block of data; it is typically a fixed-length binary string. Hash algorithms ensure that data is not tampered with during transmission or storage. If the data changes, its hash value will also change, thus allowing for the detection of integrity issues.

[0083] Hash algorithms are fast and can quickly verify the integrity of large amounts of data. They are suitable for verifying multiple program modules in software. In particular, when combined with the verification of the startup header file to confirm the reliability of the software source, choosing a hash algorithm that can be quickly verified for subsequent program modules can balance the reliability of integrity verification and the efficiency of the verification.

[0084] Depending on the characteristics and security requirements of the startup header file and program modules, different cryptographic algorithms can be used to better adapt to these different needs, thereby balancing the reliability and efficiency of integrity verification.

[0085] According to some embodiments of this application, before step S110, the method further includes: running a preset startup verification program, which is a program generated during the software development and compilation stage and placed in a write-protected storage area.

[0086] A boot verification program is program code stored in memory used to perform software boot verification. It refers to an immutable, predefined algorithm embedded in the device firmware or boot program during the software development and compilation phase. This algorithm can serve as a trust anchor, ensuring the integrity and source credibility of the boot program. By starting from the trust anchor, each subsequent software component can be verified, making all software components in the boot process trustworthy, thus forming a more complete trust chain. Once the trust anchor is established, software updates can ensure their legitimacy by verifying information without the need for additional complex verification steps.

[0087] Write-protected memory areas are storage regions configured to be read-only and not writable. Their primary purpose is to protect the data stored within from accidental modification or overwriting. For example, in critical system settings, configuration files, or firmware storage areas, write protection is implemented to prevent erroneous operations from causing system instability or malfunction. Write-protected memory areas can be implemented using hardware mechanisms. For instance, some storage devices have physical write-protection switches; when the switch is on, a specific area of ​​the storage device is write-protected and cannot be written to. Additionally, some chip-level storage devices (such as flash memory) can also implement hardware write protection through specific pin or register settings. Write-protected memory areas can also be implemented using software. For example, operating systems or applications can restrict write operations to specific memory areas by setting file permissions, access control lists (ACLs), etc.

[0088] Pre-setting the verification process during the software development and compilation phase can help determine trust anchors as early as possible, which helps to form a trust chain with high credibility, improves the reliability of verification, and also helps to further simplify the verification method and improve verification efficiency.

[0089] like Figure 2 As shown, an embodiment of the second aspect of this application provides a software startup method 200, wherein the software includes at least one program module, and the software startup method 200 includes:

[0090] S210: In response to receiving a wake-up command instructing the software to be started, execute the software startup verification method 100.

[0091] Software here refers to a set of instructions, data, and related documents that can run on a computer or related device to perform a specific function or complete a specific task. It can be various types of applications, such as operating systems, office software, games, etc. In some embodiments, software can be a vehicle control system, or a system onboard a vehicle with a specific purpose or function, such as a battery management system, navigation system, etc.

[0092] A program module is a component of software, possessing relatively independent functions and capable of performing specific tasks or processing specific types of data. For example, in a pool management system, program modules could include a battery monitoring module, a power estimation module, a balancing control module, a charging management module, a discharging management module, a fault diagnosis module, a communication module, and so on.

[0093] A wake-up command is a trigger signal used to instruct software to transition from a hibernation, shutdown, or waiting state to a startup and running state. This command can be generated by user actions (such as clicking an icon or pressing a specific key), system events (such as scheduled startup or invocation of other related software), or input from external devices.

[0094] In some embodiments, a wake-up command needs to be sent to the software each time it needs to be run. After receiving the wake-up command, the software will execute the software startup verification method 100 in the above embodiments. Specifically, a preset startup verification program can be run to perform startup verification on the software to check whether the software has been tampered with.

[0095] By executing the software startup verification method 100 after receiving a wake-up command instructing the software to start, the integrity and security of the software can be improved as much as possible, the risk of unauthorized tampering leading to system performance degradation or security problems can be reduced, and the reliability of software operation can be improved.

[0096] According to some embodiments of this application, such as Figure 2 As shown, the software startup method 200 also includes:

[0097] S220: In response to receiving a first instruction indicating that the software should be started, the software is started.

[0098] In other embodiments, the software startup method 200 further includes:

[0099] S230: In response to receiving a second instruction indicating that the execution of a program module that has failed verification is prohibited, the execution of that program module is prohibited.

[0100] When the software startup verification program successfully verifies the startup header file, it issues the first instruction, transferring control to the software's entry point, thereby starting and running the software. The first instruction can be a jump instruction.

[0101] Step S230 can be executed after the software starts. The software startup verification program can continue to verify each program module in the software to ensure the integrity of the startup verification. When a program module fails the verification, the software startup verification program will issue a second instruction to prohibit the execution of that program module.

[0102] The software can be launched once the startup header file verification is successful, saving startup time and improving verification efficiency. If verification fails, promptly disabling the program module can effectively reduce potential risks and hidden dangers during software operation, while preserving usable functionality. This not only improves the security and reliability of software startup but also enhances software usability.

[0103] like Figure 3 As shown, an embodiment of the third aspect of this application provides a software startup verification device 300, which includes a running unit 310, a first verification unit 320, a first output unit 330, a second verification unit 340, and a second output unit 350. The running unit 310 is configured to run a startup header file of the software, the startup header file being a data structure generated based on at least one program module during the software development and compilation phase. The first verification unit 320 is configured to determine the verification result of the startup header file. The first output unit 330 is configured to output a first instruction indicating that the software should be started in response to a successful verification result of the startup header file. The second verification unit 340 is configured to determine the verification result of at least one program module. The second output unit 350 is configured to output a second instruction indicating that the program module that failed the verification should be prohibited from running in response to a failed verification result of at least one program module.

[0104] The software startup verification device 300 can be a program or module for executing the software startup verification method 100. It can also achieve the beneficial effects that the software startup verification method 100 in the above embodiments can obtain, which will not be elaborated here.

[0105] like Figure 4 As shown, an embodiment of the fourth aspect of this application provides a software startup apparatus 400, which includes a receiving unit 410 and a software startup verification unit 420. The receiving unit 410 is configured to receive a wake-up command indicating the startup of software; the software startup verification unit 420 is configured to execute the software startup verification method 100 in response to the receiving unit 410 receiving the wake-up command.

[0106] In some embodiments, the software startup verification unit 420 may be the software startup verification device 300 in the above embodiments.

[0107] An embodiment of the fifth aspect of this application provides a computing device including at least one processor; and at least one memory communicatively connected to the at least one processor, the at least one memory storing instructions that, when executed individually or jointly by the at least one processor, cause the computing device to perform the above-described software startup verification method 100 or software startup method 200.

[0108] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0109] An embodiment of the sixth aspect of this application provides a computer-readable storage medium storing instructions that, when executed individually or jointly by one or more processors of a computing device, cause the computing device to perform the above-described software startup verification method 100 or software startup method 200.

[0110] It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0111] An embodiment of the seventh aspect of this application provides a computer program product including instructions that, when executed individually or jointly by one or more processors of a computing device, cause the computing device to perform the software startup verification method 100 or the software startup method 200 described above.

[0112] An embodiment of the eighth aspect of this application provides a battery management system, which includes the above-described software startup verification device 300, the above-described software startup device 400, the above-described computing device, the above-described computer-readable storage medium, or the above-described computer program product.

[0113] The battery management system may include a software-boot verification device 300 or a software boot device 400, wherein the software-boot verification device 300 or the software boot device 400 may be stored in a storage area in the form of program code. In some embodiments, the battery management system may further include a computing device, a computer-readable storage medium, or a computer program product that can be used to execute or implement the software boot verification method 100.

[0114] An embodiment of the ninth aspect of this application provides a battery device, which includes the above-described software startup verification device 300, software startup device 400, computing device, computer-readable storage medium, computer program product, or the above-described battery management system.

[0115] The battery device may include the aforementioned battery management system, or it may directly include a software-initiated verification device 300 or a software-initiated device 400, wherein the software-initiated verification device 300 or the software-initiated device 400 may be stored in the storage area of ​​the battery device's system in the form of program code. In some embodiments, the battery device may also include a computing device, a computer-readable storage medium, or a computer program product that can be used to execute or implement the software-initiated verification method 100.

[0116] An embodiment of the tenth aspect of this application provides a vehicle that includes the above-described software startup verification device 300, software startup device 400, computing device, computer-readable storage medium, computer program product, battery management system, or battery device.

[0117] The technical solution of this application will be further described below with reference to a specific embodiment.

[0118] This embodiment provides a startup method for a battery management system installed in a vehicle. Please refer to [link / reference]. Figures 1-5 During the development and compilation phase of the battery management system, a preset key, a startup header file, and first preset information (such as a message authentication code) are generated based on the first cryptographic algorithm. The startup header file contains second preset information (such as a hash value) obtained by each program module in the battery management system based on the second cryptographic algorithm. At the same time, the startup verification program is written into the write-protected storage area in one go to prevent the startup verification program from being tampered with.

[0119] The startup method includes:

[0120] The vehicle controller sends a wake-up command to the battery management system, which is used to instruct the battery management system to run.

[0121] After receiving the wake-up command, the battery management system runs a preset startup verification program, which performs the following steps:

[0122] The startup header file for running the software;

[0123] The preset key is invoked, and the first verification information is calculated based on the first cryptographic algorithm, the preset key, and the startup header file.

[0124] The first verification information is compared with the first preset information. If they match, the startup header file verification result is determined to be successful, and a first instruction is issued to instruct the processor to start and run the battery management system. If they do not match, the startup header file verification result is determined to be unsuccessful, and the startup of the battery management system is prohibited.

[0125] After the battery management system (BMS) starts successfully, it continues to verify each program module within the BMS. The software consists of N program modules, block1-blockN, where N is a positive integer greater than or equal to 1. Specifically, this includes:

[0126] For any given program module, perform the following operations: Calculate the second verification information for that program module based on the second cryptographic algorithm; compare the calculated second verification information with the corresponding second preset information in the startup header file. If they do not match, the program module verification is deemed to have failed, and a second instruction is issued to instruct the processor to prohibit the execution of that program module. If all program modules pass verification, the startup verification program completes execution and exits.

[0127] In this embodiment, the startup verification of the battery management system is entirely implemented in software, without relying on the HSM. Furthermore, due to the small header file size, the computational power required for verification is low, and the verification time is short. The software can be started immediately after the startup header file verification passes, reducing user waiting time. Continuing to verify each program module within the software after startup ensures the integrity and security of the verification process.

[0128] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A method of verifying software startup applied to a vehicle, characterized by, The software comprises at least one program module, and the verification method for starting the software comprises: running a starting header file of the software, the starting header file being a data structure generated based on the at least one program module in a software development and compilation stage; determining a verification result of the starting header file based on a first cryptography algorithm; in response to the verification result of the starting header file being passed, outputting a first instruction for instructing to start the software; after the software is started and runs, determining a verification result of the at least one program module based on a second cryptography algorithm; in response to the verification result of the at least one program module being failed, outputting a second instruction for instructing to prohibit running the program module that fails the verification.

2. The software-initiated authentication method of claim 1, wherein, The determination of the verification result of the starting header file based on the first cryptography algorithm comprises: determining first verification information based on the first cryptography algorithm and the starting header file, the first verification information being used for verifying the starting header file; in response to the first verification information being consistent with first preset information, determining that the verification result of the starting header file is passed; wherein the first preset information is verification information generated based on the first cryptography algorithm and the starting header file in the software development and compilation stage.

3. The software-initiated authentication method of claim 2, wherein, The determination of the first verification information based on the first cryptography algorithm and the starting header file comprises: calling a preset key, the preset key being a key determined based on the first cryptography algorithm and preset in the software development and compilation stage; determining the first verification information based on the first cryptography algorithm, the starting header file and the preset key.

4. The software-initiated authentication method of any of claims 1-3, wherein, The determination of the verification result of the at least one program module based on the second cryptography algorithm comprises: for any one of the at least one program module, determining second verification information of the program module based on the second cryptography algorithm; in response to the second verification information of the program module being inconsistent with second preset information in the starting header file, determining that the verification result of the at least one program module is failed; wherein the second preset information is verification information corresponding to the program module and generated based on the second cryptography algorithm in the software development and compilation stage.

5. The software-initiated authentication method of any one of claims 1-3, wherein, The second cryptography algorithm and the first cryptography algorithm are different encryption algorithms.

6. The software-initiated authentication method of any one of claims 1-3, wherein, Before the running of the starting header file of the software, the starting header file being a data structure generated based on the at least one program module in the software development and compilation stage, the method further comprises: running a preset starting verification program, the preset starting verification program being a program generated in the software development and compilation stage and placed in a write-protected storage area.

7. A software startup method, the software comprising at least one program module, characterized in that, The software starting method comprises: in response to receiving a wake-up instruction for instructing to start the software, executing the verification method for starting the software according to any one of claims 1-6.

8. The software booting method of claim 7, wherein, The method further comprises: in response to receiving the first instruction for instructing to start the software, starting the software; and / or in response to receiving the second instruction for instructing to prohibit running the program module that fails the verification, prohibiting running the program module.

9. An authentication device for software startup applied to a vehicle, characterized by, The software comprises at least one program module, and the software startup verification device comprises: a running unit configured to run a startup header file of the software, the startup header file being a data structure generated based on the at least one program module in a software development and compilation phase; a first verification unit configured to determine a verification result of the startup header file; a first output unit configured to output a first instruction for instructing to start the software in response to the verification result of the startup header file being passed; a second verification unit configured to determine a verification result of the at least one program module after the software is started to run; a second output unit configured to output a second instruction for instructing to prohibit running a program module that fails to pass the verification in response to the verification result of the at least one program module being failed.

10. A software starting apparatus, said software comprising at least one program module, characterized in that, The software startup device comprises: a receiving unit configured to receive a wake-up instruction for instructing to start the software; and a software startup verification unit configured to perform the software startup verification method according to any one of claims 1-6 in response to the receiving unit receiving the wake-up instruction.

11. A computing device, comprising: comprise: at least one processor; and at least one memory communicatively connected with the at least one processor, the at least one memory storing instructions that, when executed by the at least one processor alone or collectively, cause the computing device to perform the method according to any one of claims 1-8.

12. A computer-readable storage medium, characterized in that, storing instructions that, when executed by one or more processors of a computing device alone or collectively, cause the computing device to perform the method according to any one of claims 1-8.

13. A computer program product, characterised in that, comprise instructions that, when executed by one or more processors of a computing device alone or collectively, cause the computing device to perform the method according to any one of claims 1-8.

14. A battery management system, characterized by, comprise the software startup verification device according to claim 9, the software startup device according to claim 10, the computing device according to claim 11, the computer-readable storage medium according to claim 12, or the computer program product according to claim 13.

15. A battery device characterized by comprising: comprise the software startup verification device according to claim 9, the software startup device according to claim 10, the computing device according to claim 11, the computer-readable storage medium according to claim 12, the computer program product according to claim 13, or the battery management system according to claim 14.

16. A vehicle characterized by comprising: comprise: the software startup verification device according to claim 9, the software startup device according to claim 10, the computing device according to claim 11, the computer-readable storage medium according to claim 12, the computer program product according to claim 13, the battery management system according to claim 14, or the battery device according to claim 15.

Images