Software boot system, method and computer program product for preventing software version rollback

Abstract

This invention provides a software startup system, method, and computer program product to prevent software version rollback, belonging to the field of vehicle software update technology. It includes a startup control module, a verification module, an efuse module, and a bootloader program, the latter guiding software startup. The efuse module stores the developer's public key and a software version number sliding area, which contains a rolling value that rolls to higher versions after software updates. Upon power-up, the startup control module locks the bootloader startup process. After receiving a startup signal, it sends a verification request to the verification module. The verification module verifies the signature using the public key, performs hash verification based on the bootloader, and verifies the version based on the rolling value. If all verifications pass, it sends a verification pass signal. Upon receiving this signal, the startup control module allows the bootloader to execute the startup process and starts the software to be launched. This invention utilizes the immutable nature of the contents in efuse to ensure that the software will not roll back to a previous version.

Description

Technical Field

[0001] This invention relates to the field of vehicle software update technology, and specifically to a software startup system, method, and computer program product that prevents software version rollback. Background Technology

[0002] Nowadays, with the rapid development of network communication and computer technology, electronic and electrical products account for an increasingly large proportion of the market. When developing controller software, bugs and vulnerabilities are inevitable. If these bugs and vulnerabilities are exploited by malicious actors, they can damage the controller, lead to data leaks, and cause even more serious losses in critical scenarios.

[0003] However, developers also discover bugs and vulnerabilities in the software, and release updates to fix them. But if the software installation package is leaked, attackers can use the package to revert the software on the controller to a vulnerable version, causing the vulnerability to reappear.

[0004] While some products have version number detection mechanisms, this only applies to normal upgrades (software upgrades). However, directly using the debug interface to flash the firmware can forcibly write an older version of the software, thereby exposing vulnerabilities and bugs in the previous version. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a software startup system that prevents software version rollback, comprising: The startup control module, verification module, efuse module, and bootloader program are used to boot the software. The efuse module is used to store the developer's public key and the software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. The startup control module is used to lock the storage medium reading path of the bootloader program after the vehicle controller is powered on, and after receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. The verification module is used to verify the signature using the developer's public key in the efuse module and to verify the software version number using the current software version number scroll value in the software version number sliding area after receiving the verification request signal. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. The startup control module is also used to restore the storage medium read path of the bootloader program after receiving the first verification pass signal; The verification module is also used to read bootloader program data to complete hash value verification. After the hash value verification is successful, a second verification success signal is sent to the boot control module. The startup control module is also used to allow the bootloader program to execute the software startup process after receiving the second verification pass signal, so as to start the software to be started.

[0006] Furthermore, in the efuse module, the specific method for the software version number sliding area to roll the software version number to a higher software version number after the software is flashed is as follows: Each time the software is rewritten, a monotonic counter is used to roll the software version number to a higher version number.

[0007] Furthermore, the specific methods for locking the bootloader program's storage medium read path after the vehicle controller is powered on, and for restoring the bootloader program's storage medium read path after receiving the first verification pass signal, in the startup control module are as follows: The startup control module is integrated into the Boot ROM hardware of the main control chip of the vehicle controller. After the vehicle controller is powered on, the Boot ROM hardware circuit pulls down the read enable signal of the bootloader storage medium to lock the storage medium reading path of the bootloader program. After receiving the verification pass signal, the Boot ROM hardware pulls up the read enable signal of the bootloader storage medium to restore the storage medium read path of the bootloader program.

[0008] Furthermore, the specific methods for verifying the signature using the developer's public key in the efuse module, verifying the software version number using the current software version number scrolling value in the software version number sliding area, and completing the hash value verification by reading the bootloader program data are as follows: A startup verification field is pre-written into the software to be launched. The startup verification field includes the developer signature, the bootloader hash base value, and the software version number. The signature is verified based on the developer signature and the developer public key. The software version number is verified based on the software version number and the current software version number scroll value in the software version number sliding area. The verification module performs real-time one-way operation on the binary raw data of the bootloader program through a hardware hash algorithm to generate a fixed-length hash value. The hash value is verified based on the hash value and the bootloader hash base value.

[0009] Furthermore, the specific method for verifying signatures based on the developer's signature and public key is as follows: The RSA asymmetric encryption algorithm is used. The verification module uses the developer's public key to decrypt the developer's signature to obtain the restored digest value. At the same time, the bootloader hash base value and software version number in the startup verification field are hashed to obtain the real-time digest value. If the restored digest value is consistent with the real-time digest value, the signature verification is deemed to have passed; otherwise, the signature verification is deemed to have failed.

[0010] Furthermore, the specific method for verifying the hash value based on the hash value and the bootloader hash base value is as follows: If the hash value matches the bootloader hash base value, the hash value verification is considered successful; otherwise, the hash value verification is considered unsuccessful.

[0011] Furthermore, the specific method for verifying the software version number based on the software version number and the current software version number scroll value in the software version number sliding area is as follows: The pointer controller reads the current software version number scroll value in the software version number slider area. If the current software version number scroll value is consistent with the software version number, the version number verification is considered successful; otherwise, the version number verification is considered unsuccessful.

[0012] Furthermore, the specific method for allowing the bootloader program to execute the software startup process in the startup control module is as follows: The startup control module sends a startup authorization command to the CPU of the vehicle controller's main control chip and loads the starting address of the bootloader program into the CPU, triggering the CPU to read and run the bootloader program to allow the bootloader program to execute the software startup process.

[0013] A software startup method to prevent software version rollback, comprising: The efuse module stores the developer's public key and a software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. After the vehicle controller is powered on, the startup control module locks the storage medium reading path of the bootloader program. After receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. After receiving the verification request signal, the verification module uses the developer's public key in the efuse module to verify the signature and uses the current software version number scroll value in the software version number sliding area to verify the software version number. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. After receiving the first verification pass signal, the startup control module restores the storage medium reading path of the bootloader program; The verification module reads the bootloader program data to complete the hash value verification. After the hash value verification is successful, it sends a second verification success signal to the boot control module. After receiving the second verification pass signal, the startup control module allows the bootloader program to execute the software startup process to start the software to be started.

[0014] A computer program product includes a computer program / instructions that, when executed by a processor, implement the aforementioned software startup method for preventing software version rollback.

[0015] The beneficial effects of this invention are as follows: 1. The boot control module is integrated into the main control chip's Boot ROM hardware. It physically controls the bootloader's storage medium reading path through level signals, locking the boot process upon power-on and only allowing it to proceed after all verifications pass. This hardware-level approach prevents software-level boot bypasses. The efuse module relies on a monotonic counter to achieve unidirectional irreversible updates of the software version number rolling value. Combined with hardware-level version number verification, even if an attacker flashes an older version of the software via the debugging interface, the software will be rejected due to version number mismatch, completely solving the problem of reproducing vulnerabilities in older versions and ensuring the security and stability of the vehicle software throughout its entire lifecycle.

[0016] 2. A triple verification system—signature verification, hash value verification, and software version number verification—forms complementary protection. Signature verification relies on the RSA asymmetric encryption algorithm to ensure the official authenticity and immutability of the core reference data for startup verification. Hash value verification enables accurate integrity detection of the bootloader program itself, preventing malicious code injection. Version number verification relies on the rolling value stored in efuse hardware to verify version freshness. Furthermore, mandatory signature verification is the first step in the verification process, ensuring the credibility of the benchmark data for subsequent verifications. This comprehensive approach, addressing data, program, and version, effectively avoids various attack methods such as forgery, tampering, and rollback, significantly enhancing the security protection capabilities of software startup.

[0017] 3. The core verification benchmarks, such as the developer's public key and the software version number rolling value, are stored in the efuse module. Once the data is burned, it cannot be modified or erased. Furthermore, the core operations such as version rolling, startup control, and data reading are all completed independently by the hardware module without relying on the software program. This fundamentally avoids the risk that attackers may tamper with the verification benchmarks, forge version identifiers, or modify the startup logic through the software layer, making the foundation of the entire security verification system have unbreakable hardware attributes. Attached Figure Description

[0018] Figure 1This is a system block diagram of the present invention. Detailed Implementation

[0019] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0020] Example 1 Current vehicle controller software faces a security dilemma during upgrades and iterations: while developers can fix bugs and security vulnerabilities by releasing updates, if the software installation package is leaked, attackers can forcibly revert the software on the vehicle controller to a vulnerable older version through methods such as debugging interface flashing. This exposes the fixed vulnerabilities again, potentially damaging the controller, causing data leaks, and even more serious security losses in critical scenarios such as vehicle operation. Existing version number detection mechanisms only apply to normal software upgrade scenarios and cannot defend against version rollback attacks using unconventional methods such as flashing. They lack hardware-level, end-to-end version rollback prevention and startup security verification capabilities. To address these technical issues, [reference needed]. Figure 1 A software startup system for preventing software version rollback is proposed, comprising: The startup control module, verification module, efuse module, and bootloader program are used to boot the software. The efuse module is used to store the developer's public key and the software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. The startup control module is used to lock the storage medium reading path of the bootloader program after the vehicle controller is powered on, and after receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. The verification module is used to verify the signature using the developer's public key in the efuse module and to verify the software version number using the current software version number scroll value in the software version number sliding area after receiving the verification request signal. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. The startup control module is also used to restore the storage medium read path of the bootloader program after receiving the first verification pass signal; The verification module is also used to read bootloader program data to complete hash value verification. After the hash value verification is successful, a second verification success signal is sent to the boot control module. The startup control module is also used to allow the bootloader program to execute the software startup process after receiving the second verification pass signal, so as to start the software to be started.

[0021] The boot control module is a hardware boot control unit built into the main control chip (MCU / SoC) of the vehicle controller. It is integrated into the Boot ROM hardware (hardware circuit) that is pre-programmed at the chip's factory. It is a pure hardware circuit module with no software execution logic. After the vehicle controller is powered on, the boot control module directly locks the software boot process of the bootloader program, only allowing it to start after all verifications have passed. This entrusts the core control of boot permissions to the hardware module, rather than software logic, preventing attackers from bypassing boot verification by tampering with software or exploiting software vulnerabilities. This elevates the security protection of software boot from the software layer to the hardware layer, significantly improving the boot process's resistance to attacks.

[0022] The verification module is a hardware security verification engine integrated within the main control chip of the vehicle controller. It is a dedicated hardware circuit built into the chip and can independently perform verification operations such as signature verification, hash calculation, and version comparison, without relying on software execution. The verification module works in conjunction with the efuse module to complete triple verification: signature verification, hash value verification, and software version number verification. These three elements form a complementary security protection system: signature verification ensures that the core reference data for startup verification is official and authentic, and has not been tampered with; hash value verification ensures that the bootloader program itself is intact and free from malicious tampering or data corruption; and version number verification relies on the software version number sliding area of ​​the efuse module to prevent version rollback. These three verifications are indispensable, comprehensively avoiding various attack methods such as forged reference data, tampering with the startup program, and reverting to older versions via flashing, thus solving the problem of insufficient protection capabilities of single-version detection mechanisms in existing technologies.

[0023] The efuse module is a one-time programmable (OTP) hardware storage module built into the main control chip of the vehicle controller. It adopts a physical fuse-type storage structure, and the data cannot be modified or erased after being burned, making it a hardware-level secure storage unit. The developer's public key, software version number rolling value, and other core verification benchmarks are stored in the efuse module. Combined with the feature of the software version number sliding area rolling to higher versions after software flashing, the core verification data has hardware-level immutability and ineradicability. This prevents attackers from bypassing verification by forging or modifying the public key or version number benchmark value, ensuring the reliability of the entire verification system and preventing malicious tampering with the version rollback verification benchmarks.

[0024] The bootloader program is the low-level boot program of the vehicle controller. It is stored in the controller's non-volatile hardware storage medium (such as Flash memory) and is used to complete hardware initialization and boot the software.

[0025] By combining the version rolling feature of the efuse module software version number sliding area with the version number verification of the verification module, the vehicle controller can only start software that matches the software version number rolling value currently stored in the hardware. Even if an attacker flashes an older version of the software through unconventional means such as debugging interfaces, the software will be rejected due to version number verification failure. This completely eliminates version rollback behavior from the source of software startup, solving the technical defects of existing technologies where normal upgrades can detect the version and flashing can forcibly roll back the version. This ensures that fixed bugs and security vulnerabilities will not be exposed again due to version rollback, and significantly improves the security and stability of the vehicle controller throughout its entire service life.

[0026] As a specific implementation method, in the efuse module, the specific method for rolling the software version number sliding area to a higher software version number after the software is flashed is as follows: Each time the software is rewritten, a monotonic counter is used to roll the software version number to a higher version number.

[0027] The rolling value of the software version number is defined by the developer. For example, the rolling value of the initial software version 1.0.0 is 0, the rolling value of version 1.0.1 is 1, and so on.

[0028] The version rolling operation relies on the efuse hardware module. The rolled software version number is physically immutable and indelible, ensuring the authenticity and uniqueness of the current valid version baseline and preventing attackers from bypassing rollback checks by forging or tampering with version values. A monotonic counter is used to achieve unidirectional rolling of the software version number to higher versions only, giving the version value irreversible update characteristics. This mechanism completely eliminates software version rollback attacks, ensuring the system only allows the execution of legitimate software with higher versions, significantly improving the security protection capabilities of the vehicle controller software startup. After each software update, the version number is rolled uniformly a preset number of times, standardizing and predicting the version update logic, avoiding verification anomalies caused by disordered version number changes, and ensuring the stability and reliability of the version verification process. Version rolling is completed independently by the hardware monotonic counter, without relying on software program participation, fundamentally avoiding the risk of software-level tampering with version update records and forging higher version identifiers.

[0029] As a specific implementation, the method for locking the bootloader program's storage medium read path after the vehicle controller is powered on, and for restoring the bootloader program's storage medium read path after receiving the first verification pass signal, in the startup control module is as follows: The startup control module is integrated into the Boot ROM hardware of the main control chip of the vehicle controller. After the vehicle controller is powered on, the Boot ROM hardware circuit pulls down the read enable signal of the bootloader storage medium to lock the storage medium reading path of the bootloader program. After receiving the verification pass signal, the Boot ROM hardware pulls up the read enable signal of the bootloader storage medium to restore the storage medium read path of the bootloader program.

[0030] Pulling low means forcing the voltage of a circuit pin to a low level (e.g., 0V), and pulling high means forcing the voltage of a circuit pin to a high level (e.g., 3.3V or 5V). The read enable signal is active high. When high, the memory chip allows reading and the bootloader to start; when low, the memory chip refuses to be read, locking the bootloader program from starting. The boot control module is a hardware circuit (Boot ROM) pre-installed in the chip at the factory. It locks the bootloader program as soon as it is powered on. The entire process is controlled by hardware circuitry, which cannot be modified or bypassed by software. After receiving the first verification pass signal, the boot control module pulls the read enable signal high, restoring the read path of the corresponding memory chip. Only when the CPU (Central Processing Unit) can read the bootloader program can the software start normally.

[0031] The Boot ROM is a hardware circuit that is fixed at the chip factory. It has no software execution logic and cannot be modified. This makes the core logic of starting the lock / release mechanism the underlying hardware rules of the vehicle controller. Attackers cannot modify this logic by tampering with the software or flashing the firmware, thus ensuring the security of the process from the root of the startup control.

[0032] As a specific implementation method, the specific steps for verifying the signature using the developer's public key in the efuse module, verifying the software version number using the current software version number scrolling value in the software version number sliding area, and completing the hash value verification by reading the bootloader program data are as follows: A startup verification field is pre-written into the software to be launched. The startup verification field includes the developer signature, the bootloader hash base value, and the software version number. The signature is verified based on the developer signature and the developer public key. The software version number is verified based on the software version number and the current software version number scroll value in the software version number sliding area. The verification module performs real-time one-way operation on the binary raw data of the bootloader program through a hardware hash algorithm to generate a fixed-length hash value. The hash value is verified based on the hash value and the bootloader hash base value.

[0033] By packaging and solidifying the developer signature, bootloader hash base value, and software version number in the startup verification field, the core reference data of the three-level verification forms a complete and indivisible verification unit, avoiding the problem of core reference data being tampered with or forged separately, and achieving overall protection of the verification base data.

[0034] As a specific implementation method, the method for verifying signatures based on developer signatures and developer public keys is as follows: The RSA asymmetric encryption algorithm is used. The verification module uses the developer's public key to decrypt the developer's signature to obtain the restored digest value. At the same time, the bootloader hash base value and software version number in the startup verification field are hashed to obtain the real-time digest value. If the restored digest value is consistent with the real-time digest value, the signature verification is deemed to have passed; otherwise, the signature verification is deemed to have failed.

[0035] RSA (Rivest, Shamir, and Adleman) is an asymmetric cryptographic algorithm based on a public-private key pair. The private key is used for digital signatures, and the public key is used for signature verification. The private key is held only by the software distributor, while the public key is publicly available for signature verification. This algorithm ensures the legitimacy and unforgeability of the signed data. The developer first hashes the combination of the bootloader hash base value and the software version number in the startup verification field to obtain the original digest value M. Then, the developer signs the original digest value M using the private key, with the formula C=M. d (mod n), the verification module of the vehicle controller decrypts and verifies the developer's signature using the public key stored in the efuse module, with the formula M'=C e (mod n), where M' is the restored digest value. The restored digest value M' is exactly the same as the original digest value M. When the restored digest value M' is the same as the real-time digest value, the signature verification is considered successful. In the above formula, (e,n) is the RSA public key, e is the public key exponent, n is the modulus of the public or private key, (d,n) is the RSA private key, d is the private key exponent, M is the original digest value, C is the developer signature, and mod is the modulo operation.

[0036] The signature verification is to prove that the bootloader hash base value and software version number are officially released by the manufacturer and are not fake data forged or tampered with by attackers.

[0037] The hash operation described above applies to the combination of the bootloader hash base value and the software version number in the startup verification field. The software version number, as binary data, can directly participate in the hash operation. Hashting it together with the bootloader hash base value ensures the integrity and legitimacy of the version number data, preventing it from being tampered with independently. Verification is achieved through a double-digest method: decrypting the signature to obtain the original digest and then comparing it with a real-time digest calculated from the combined data. This ensures accurate and reliable verification results. The uniqueness of the hash algorithm guarantees that even a minor alteration to the combined data will completely change the real-time digest, causing verification to fail. This achieves precise tamper-proof verification of core reference data. r The hash base value and software version number are used as combined data for hash calculation, achieving coordinated protection of the two core reference data and preventing attackers from tampering with the software version number or bootloader separately. r The hash base value is used to bypass the signature verification problem, allowing the signature verification process to simultaneously verify the legality and integrity of two core data.

[0038] As a specific implementation method, the method for verifying the hash value based on the hash value and the bootloader hash base value is as follows: If the hash value matches the bootloader hash base value, the hash value verification is considered successful; otherwise, the hash value verification is considered unsuccessful.

[0039] The hash value is calculated on-site and compared with the bootloader hash baseline value in the startup verification field. If they match, it indicates that the bootloader program is intact and has not been injected with malicious code. A hash value is a fixed-length digest value obtained by processing data using a hash algorithm. It is unique and irreversible; any slight change in the data content will significantly change its corresponding hash value. In this solution, the hash value is used to characterize the integrity of the bootloader program. By comparing the real-time hash value of the bootloader program with the preset hash baseline value, it can be determined whether the bootloader program has been tampered with or damaged.

[0040] The hash calculation described in this invention refers to the process by which the verification module performs real-time one-way calculations on the binary raw data of the bootloader program using a hardware hash algorithm to generate a hash value of fixed length. This calculation is completed independently by the hardware security verification engine of the verification module, without relying on the bootloader program or other software to run. The real-time hash value obtained is used to compare with the bootloader hash base value in the startup verification field to verify the integrity and tamper-proof nature of the bootloader program.

[0041] As a specific implementation method, the method for verifying the software version number based on the software version number and the current software version number scroll value in the software version number sliding area is as follows: The pointer controller reads the current software version number scroll value in the software version number slider area. If the current software version number scroll value is consistent with the software version number, the version number verification is considered successful; otherwise, the version number verification is considered unsuccessful.

[0042] The software version number in the sliding area only increases and never decreases; this is irreversible due to hardware limitations. Startup is only allowed if the version number of the software to be launched matches the current software version number's rolling value. Once a new version is flashed, the old version can never be launched again. Flashing an older version via USB cable will also fail because the version number and the rolling value are inconsistent. This ensures that in-vehicle software can only be flashed via push notifications.

[0043] As a specific implementation method, the bootloader program is allowed to execute the software startup process in the startup control module as follows: The startup control module sends a startup authorization command to the CPU of the vehicle controller's main control chip and loads the starting address of the bootloader program into the CPU, triggering the CPU to read and run the bootloader program to allow the bootloader program to execute the software startup process.

[0044] Example 2 A software startup method to prevent software version rollback, comprising: The efuse module stores the developer's public key and a software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. After the vehicle controller is powered on, the startup control module locks the storage medium reading path of the bootloader program. After receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. After receiving the verification request signal, the verification module uses the developer's public key in the efuse module to verify the signature and uses the current software version number scroll value in the software version number sliding area to verify the software version number. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. After receiving the first verification pass signal, the startup control module restores the storage medium reading path of the bootloader program; The verification module reads the bootloader program data to complete the hash value verification. After the hash value verification is successful, it sends a second verification success signal to the boot control module. After receiving the second verification pass signal, the startup control module allows the bootloader program to execute the software startup process to start the software to be started.

[0045] Example 3 A computer program product includes a computer program / instructions that, when executed by a processor, implement the software startup method for preventing software version rollback as described in Embodiment 2.

[0046] The contents not described in detail in this specification are prior art known to those skilled in the art. Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0047] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0048] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0049] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0050] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit its scope of protection. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that after reading the present invention, they can still make various changes, modifications or equivalent substitutions to the specific implementation of the invention, but these changes, modifications or equivalent substitutions are all within the scope of protection of the pending claims of the present invention.

Claims

1. A software startup system for preventing software version rollback, characterized in that, include: The startup control module, verification module, efuse module, and bootloader program are used to boot the software. The efuse module is used to store the developer's public key and the software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. The startup control module is used to lock the storage medium reading path of the bootloader program after the vehicle controller is powered on, and after receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. The verification module is used to verify the signature using the developer's public key in the efuse module and to verify the software version number using the current software version number scroll value in the software version number sliding area after receiving the verification request signal. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. The startup control module is also used to restore the storage medium read path of the bootloader program after receiving the first verification pass signal; The verification module is also used to read bootloader program data to complete hash value verification. After the hash value verification is successful, a second verification success signal is sent to the boot control module. The startup control module is also used to allow the bootloader program to execute the software startup process after receiving the second verification pass signal, so as to start the software to be started.

2. The software startup system for preventing software version rollback according to claim 1, characterized in that, In the efuse module, the specific method by which the software version number slider scrolls the software version number to a higher software version number after the software is flashed is as follows: Each time the software is rewritten, a monotonic counter is used to roll the software version number to a higher version number.

3. The software startup system for preventing software version rollback according to claim 1, characterized in that, In the startup control module, the specific methods for locking the bootloader program's storage medium read path after the vehicle controller is powered on, and for restoring the bootloader program's storage medium read path after receiving the first verification pass signal, are as follows: The startup control module is integrated into the Boot ROM hardware of the main control chip of the vehicle controller. After the vehicle controller is powered on, the Boot ROM hardware circuit pulls down the read enable signal of the bootloader storage medium to lock the storage medium reading path of the bootloader program. After receiving the verification pass signal, the Boot ROM hardware pulls up the read enable signal of the bootloader storage medium to restore the storage medium read path of the bootloader program.

4. The software startup system for preventing software version rollback according to claim 1, characterized in that, The specific methods for verifying signatures using the developer's public key in the efuse module, verifying the software version number using the current software version number scrolling value in the software version number slider, and verifying the hash value by reading bootloader program data are as follows: A startup verification field is pre-written into the software to be launched. The startup verification field includes the developer signature, the bootloader hash base value, and the software version number. Signature verification is performed based on the developer signature and the developer public key. Software version number verification is performed based on the software version number and the current software version number scroll value in the software version number sliding area. The verification module performs real-time one-way calculations on the binary raw data of the bootloader program using a hardware hash algorithm to generate a fixed-length hash value. The hash value is then verified based on the hash value and the bootloader hash base value.

5. The software startup system for preventing software version rollback according to claim 4, characterized in that, The specific method for verifying signatures based on developer signatures and developer public keys is as follows: The RSA asymmetric encryption algorithm is used. The verification module uses the developer's public key to decrypt the developer's signature to obtain the restored digest value. At the same time, the bootloader hash base value and software version number in the startup verification field are hashed to obtain the real-time digest value. If the restored digest value is consistent with the real-time digest value, the signature verification is deemed to have passed; otherwise, the signature verification is deemed to have failed.

6. The software startup system for preventing software version rollback according to claim 4, characterized in that, The specific method for verifying the hash value based on the hash value and the bootloader hash baseline value is as follows: If the hash value matches the bootloader hash base value, the hash value verification is considered successful; otherwise, the hash value verification is considered unsuccessful.

7. The software startup system for preventing software version rollback according to claim 4, characterized in that, The specific method for verifying the software version number based on the software version number and the current software version number scroll value in the software version number sliding area is as follows: The pointer controller reads the current software version number scroll value in the software version number slider area. If the current software version number scroll value is consistent with the software version number, the version number verification is considered successful; otherwise, the version number verification is considered unsuccessful.

8. The software startup system for preventing software version rollback according to claim 1, characterized in that, The specific method for allowing the bootloader program to execute the software startup process in the startup control module is as follows: The startup control module sends a startup authorization command to the CPU of the vehicle controller's main control chip and loads the starting address of the bootloader program into the CPU, triggering the CPU to read and run the bootloader program to allow the bootloader program to execute the software startup process.

9. A software startup method to prevent software version rollback, characterized in that, include: The efuse module stores the developer's public key and a software version number slider. The software version number slider stores the software version number rollover value. The software version number slider is used to roll the software version number rollover value to a higher software version number after the software is flashed. After the vehicle controller is powered on, the startup control module locks the storage medium reading path of the bootloader program. After receiving the software startup signal sent by the software to be started, it sends a verification request signal to the verification module. After receiving the verification request signal, the verification module uses the developer's public key in the efuse module to verify the signature and uses the current software version number scroll value in the software version number sliding area to verify the software version number. After both the signature verification and the software version number verification are passed, the module sends the first verification pass signal to the startup control module. After receiving the first verification pass signal, the startup control module restores the storage medium reading path of the bootloader program; The verification module reads the bootloader program data to complete the hash value verification. After the hash value verification is successful, it sends a second verification success signal to the boot control module. After receiving the second verification pass signal, the startup control module allows the bootloader program to execute the software startup process to start the software to be started.

10. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the software startup method for preventing software version rollback as described in claim 9.

Images