Vehicle starting method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses a vehicle starting method and device, equipment and a storage medium. The method comprises the steps that if it is detected that a vehicle is powered on successfully, a program code of a program to be started is obtained; the program codes are subjected to real-time signature value verification, a verification result is obtained, and the program codes comprise program starting codes and program application codes; if the verification result represents that the program starting code verification succeeds and the program application code verification fails, generating an upgrading request corresponding to the to-be-started program so as to upgrade and replace the to-be-started program based on the upgrading request; and if the verification result represents that the verification of the program starting code fails, generating prompt information corresponding to the starting failure of the to-be-started program. According to the embodiment of the invention, by combining the safe starting of the vehicle with the over-the-air downloading technology, the requirement of manual intervention is reduced through an automatic verification and upgrading mechanism, and the maintenance cost of a vehicle system is reduced.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a virtual vehicle starting method, device, electronic device, and computer-readable storage medium. Background Art

[0002] Secure boot refers to the boot process that ensures that every executable program is trustworthy and has not been tampered with. In the on-board controller, the secure boot mechanism prevents the execution of malicious code by verifying the integrity and authenticity of the software code, thereby protecting the safety of the vehicle system.

[0003] In the related art, after the vehicle controller is powered on, a series of initialization operations will be performed first, including hardware self-test, clock configuration, etc. Then, the controller will execute the safe boot program from the root of trust. There are two commonly used methods, serial safe boot and parallel safe boot. Under serial verification, once the safety verification fails, the controller cannot be started, resulting in the inability to troubleshoot the problem. Under parallel verification, if the program verification fails, the vehicle has already started, which will have a serious impact on the safety of the vehicle. Therefore, a method for safe vehicle startup is urgently needed to overcome the above problems. Summary of the invention

[0004] To solve the above technical problems, embodiments of the present application provide a vehicle starting method and device, an electronic device, a computer-readable storage medium, and a computer program product.

[0005] According to one aspect of an embodiment of the present application, a vehicle starting method is provided, comprising: if it is detected that the vehicle is powered on successfully, obtaining the program code of the program to be started; performing a real-time signature value verification on the program code to obtain a verification result, the program code including a program startup code and a program application code; if the verification result indicates that the program startup code verification is successful, and the program application code verification fails, generating an upgrade request corresponding to the program to be started, so as to upgrade and replace the program to be started based on the upgrade request; if the verification result indicates that the program startup code verification fails, generating a prompt message corresponding to the failure to start the program to be started.

[0006] According to one aspect of an embodiment of the present application, the real-time signature value verification of the program code includes: calling a preset interface to obtain a real-time true random number, and determining a random verification area of ​​the program code based on the real-time true random number; and verifying the real-time signature value of the program code based on the random verification area.

[0007] According to one aspect of an embodiment of the present application, determining the random check area of ​​the program code based on the real-time true random number includes: generating a random index value corresponding to the program code based on the real-time true random number; selecting at least one random check area to be checked and a preset signature area corresponding to the random check area from a preset code area of ​​the program code based on the random index value.

[0008] According to one aspect of an embodiment of the present application, the signature of the program code is verified based on the random verification area, including: performing signature calculation on the random verification area to obtain a real-time signature value; performing asymmetric encryption calculation on the real-time signature value to obtain an encrypted real-time signature value; and comparing the encrypted real-time signature value with the initial burned signature value corresponding to the program.

[0009] According to one aspect of an embodiment of the present application, after comparing the encrypted real-time signature value with the initial burned signature value corresponding to the program, the method further includes: obtaining the initial burned signature value of the program to be started burned into the preset signature area; if the initial burned signature value matches the real-time signature value, a detection result indicating that the program code verification is successful is obtained.

[0010] According to one aspect of an embodiment of the present application, the generating of an upgrade request corresponding to the program to be started so as to upgrade and replace the program to be started based on the upgrade request includes: generating an upgrade request corresponding to the program to be started based on version information corresponding to the program to be started and terminal device information corresponding to the vehicle; sending the upgrade request to a server so as to generate a program upgrade package based on the upgrade request by the server.

[0011] According to one aspect of an embodiment of the present application, the method also includes: receiving a program upgrade package returned by the server, and decompressing the program upgrade package to obtain a decompressed program upgrade package; if the decompressed program upgrade package is complete and has not been tampered with, upgrading the program to be started based on the decompressed program upgrade package; if it is detected that the upgrade is complete, deleting the old version information of the program to be started, and starting the program to be started based on the program upgrade package.

[0012] According to one aspect of an embodiment of the present application, a vehicle starting device is provided, the device comprising: an acquisition module, which acquires the program code of a program to be started if it is detected that the vehicle is powered on successfully; a verification module, which performs real-time signature value verification on the program code to obtain a verification result, the program code comprising a program startup code and a program application code; a request module, which generates an upgrade request corresponding to the program to be started if the verification result indicates that the program startup code verification is successful, and the program application code verification fails, so as to upgrade and replace the program to be started based on the upgrade request; and a prompt module, which generates a prompt message corresponding to the failure to start the program to be started if the verification result indicates that the program startup code verification fails.

[0013] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device implements the vehicle starting method as described above.

[0014] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer-readable instructions are stored. When the computer-readable instructions are executed by a processor of a computer, the computer executes the vehicle starting method as described above.

[0015] According to one aspect of an embodiment of the present application, a computer program product is also provided, including a computer program, which implements the steps in the vehicle starting method as described above when executed by a processor.

[0016] In the technical solution provided in the embodiment of the present application, by performing real-time signature value verification on the program startup code and the program application code, it can be ensured that only authorized and verified codes can be executed. This helps prevent malicious code or unauthorized code from being loaded and run, thereby improving the security of the entire vehicle system. The successful verification of the program startup code is a prerequisite for the normal operation of the program. If the program startup code verification fails, the system can immediately generate a prompt message of startup failure, avoiding system instability or crash caused by the execution of erroneous code. At the same time, the verification of the program application code can also promptly discover and process potential problem codes, enhance the stability of the system, and the automated verification and upgrade mechanism reduces the need for manual intervention and reduces the maintenance cost of the vehicle system. In addition, by promptly discovering and processing potential problem codes, additional maintenance costs and time costs caused by system failures can also be avoided.

[0017] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present application, and together with the specification, are used to explain the principles of the present application. Obviously, the drawings described below are only some embodiments of the present application, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0019] Figure 1 is a schematic diagram of an implementation environment for starting a vehicle after the vehicle is powered on, shown in an exemplary embodiment of the present application;

[0020] Figure 2 is a flow chart of a vehicle starting method shown in an exemplary embodiment of the present application;

[0021] Figure 3 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0022] Figure 4 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0023] Figure 5 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0024] Figure 6 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0025] Figure 7 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0026] Figure 8 is a flow chart of a vehicle starting method shown in another exemplary embodiment of the present application;

[0027] Fig. 9 is a schematic diagram of a brief process of starting a vehicle after the vehicle is powered on in an exemplary application scenario;

[0028] Fig.10 is a block diagram of a vehicle starting device shown in an exemplary embodiment of the present application;

[0029] Fig.11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0030] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0031] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0032] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0033] The term "multiple" as used in this application refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0034] Secure boot refers to the boot process that ensures that every executable program is trusted and has not been tampered with. In the vehicle controller, the secure boot mechanism prevents the execution of malicious code by verifying the integrity and authenticity of the software code, thereby protecting the safety of the vehicle system. After the vehicle controller is powered on, a series of initialization operations will be performed first, including hardware self-test, clock configuration, etc. Then, the controller will execute the secure boot program from the root of trust. Code verification: The secure boot program will verify the integrity and authenticity of the next level program step by step. This is usually achieved through public key signature verification, that is, using the public key stored in the HSM to verify the signature information of the code. If the signature verification fails, it indicates that the code may have been tampered with, and the secure boot program will refuse to execute the code. Loading and execution: The verified code will be loaded into the corresponding execution environment and start to execute. During the execution process, the secure boot program will also monitor the running status of the code to ensure that it runs as expected. The trust chain is an important concept in the secure boot mechanism. It refers to the trusted program chain formed by step-by-step verification starting from the root of trust. In the vehicle controller, the trust chain establishment process is as follows:

[0035] Verification of the root of trust: First, verify the integrity and authenticity of the root of trust (such as BootRom in HSM). This is usually achieved through a verification mechanism provided by the hardware manufacturer.

[0036] Verification of the secure boot program: Next, the integrity and authenticity of the secure boot program is verified. This is usually done using a public key stored in a hardware security module (HSM) to verify the signature information of the secure boot program.

[0037] Verification of user programs: Finally, the integrity and authenticity of the user programs are verified. This is also achieved by using public key signature verification, but the public key used at this time may be dynamically obtained by the secure boot program during the verification process.

[0038] Among them, the commonly used secure boot methods include serial secure boot and parallel secure boot. In the serial secure boot method, the verification and execution of each level of program are carried out sequentially. Although this method has higher security performance, it takes a long time to start. In the parallel secure boot method, the verification and execution of some programs can be carried out at the same time. This can shorten the startup time, but may increase the risk of tampering. Therefore, in practical applications, it is necessary to balance the needs of security and startup time.

[0039] Figure 1 FIG. 1 is a schematic diagram of an implementation environment of a vehicle startup after the vehicle is powered on, according to an exemplary embodiment of the present application. Figure 1 As shown, after the vehicle is powered on, the program code of the program to be started after the vehicle is powered on is obtained through the smart terminal 110, wherein the program code includes the program startup code and the program application code. The smart terminal 110 performs real-time signature value verification on the program code to obtain the corresponding verification result. If the verification result indicates that the program startup code verification is successful, and the program application code verification fails, an upgrade request corresponding to the program to be started is generated, and the upgrade request is sent to the cloud server 120, so that the cloud server returns an upgrade package based on the upgrade request to upgrade and replace the program to be started. If the verification result indicates that the program startup code verification fails, a prompt message corresponding to the failure to start the program to be started is generated and sent to the central control screen of the vehicle, so that the user can quickly understand and solve the problem.

[0040] in, Figure 1 The smart terminal 110 shown can be any terminal device that supports a vehicle controller, such as a smart phone, a vehicle-mounted computer, a tablet computer, a laptop computer, or a wearable device, but is not limited thereto. Figure 1The cloud server 120 shown may be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The smart terminal 110 may communicate with the cloud server 120 via wireless networks such as 3G (third generation mobile information technology), 4G (fourth generation mobile information technology), and 5G (fifth generation mobile information technology), and this is not limited here.

[0041] In related technologies, after the vehicle controller is powered on, a series of initialization operations will be performed first, including hardware self-test, clock configuration, etc. Then, the controller will start the secure boot program from the root of trust. There are two commonly used methods: serial secure boot and parallel secure boot. Under serial verification, once the security verification fails, the controller cannot be started, resulting in the inability to troubleshoot the problem. Under parallel verification, if the program verification fails, the vehicle has already started moving, which will have a serious impact on the safety of the vehicle.

[0042] The problems pointed out above are generally applicable in vehicle safety startup scenarios. In order to solve these problems, the embodiments of the present application respectively propose a vehicle startup method, a vehicle startup device, an electronic device, a computer-readable storage medium and a computer program product. These embodiments will be described in detail below.

[0043] See also Figure 2 , Figure 2 is a flow chart of a vehicle starting method shown in an exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown is specifically executed by the smart terminal 110 in the implementation environment. It should be understood that the method can also be applied to other exemplary implementation environments and be specifically executed by devices in other implementation environments. This embodiment does not limit the implementation environment to which the method is applicable.

[0044] like Figure 2 As shown, in an exemplary embodiment, the vehicle starting method includes at least steps S210 to S240, which are described in detail as follows:

[0045] Step S210: If it is detected that the vehicle is powered on successfully, the program code of the program to be started is obtained.

[0046] When the vehicle key is turned to the "ON" position or the start button is pressed, the vehicle's power management system begins to work. The vehicle's various electronic control units (ECUs) begin the initialization process, which includes checking their own hardware status, loading firmware (if applicable), and preparing communication interfaces. During the initialization process, the ECU checks for any faults and stores this fault information in non-volatile memory for subsequent diagnosis. After initialization is complete, the vehicle's fault diagnostic system begins to run, checking the status of various sensors and actuators.

[0047] If any faults are found, the system will illuminate the warning light on the dashboard and may record the fault code for reference during subsequent maintenance. After the vehicle is powered on successfully and all controllers are initialized, the vehicle's startup program begins to execute. The startup program usually includes a series of steps, such as checking the vehicle status, performing pre-start safety checks, loading and executing the main program, etc. The acquisition of program code usually involves reading the startup program from non-volatile memory (such as flash memory) and loading it into the execution memory. Once the program code is loaded into the execution memory, the vehicle's microcontroller (MCU) or digital signal processor (DSP) begins to execute the code.

[0048] Step S220, performing real-time signature value verification on the program code to obtain a verification result, the program code includes a program startup code and a program application code.

[0049] Generally speaking, the program code includes the program startup code and the program application code, wherein the boot code can be verified by the trusted root, and then after the trusted root verification is successful, the boot is started, and then the program to be started is verified by the boot, and then the corresponding verification result is obtained. If the trusted root fails to verify the boot code, the subsequent steps of the boot verification of the program code can be skipped.

[0050] Exemplarily, after the program code is compiled and linked, the program code is signed using a private key. This signature is typically a digital signature based on the content of the program code and the uniqueness of the private key. The controller verifies the read signature using a public key stored in a hardware security module (HSM) or inside the controller. The verification process involves comparing the content of the program code with the signature to ensure that they match. If the signature verification is successful, it indicates that the program code has not been tampered with and is trustworthy. Based on the results of the signature verification, the controller generates a verification result. If the signatures of both the program startup code and the program application code are verified successfully, the verification result is "success". If the signature verification of the program startup code or the program application code fails, the verification result is "failure" and action may be required (such as generating an error code, recording a fault log, attempting recovery, etc.).

[0051] Among them, the root of trust: This is the most basic and trustworthy part of the system. It is responsible for starting and verifying other codes. In the vehicle system, the root of trust may be a hardware security module (HSM) or a specific, strictly verified firmware. Boot code verification: After the vehicle is powered on, the trusted root will first verify the Boot code, which usually involves verifying the signature of the Boot code to ensure that it has not been tampered with. Verification result: If the Boot code verification is successful, proceed to the next step; if the verification fails, it may trigger the error handling mechanism (such as entering the safe mode, recording the fault log, etc.), and the subsequent Boot verification steps to be performed will not be executed. Start Boot: After the Boot code verification is successful, the Boot code is responsible for starting and verifying the program code to be started. Program code verification: The Boot code will verify the program startup code and program application code, which also involves verifying the signature of the code to ensure its integrity and authenticity. Verification result: If the verification of the program to be started is successful, the program can be started and executed normally; if the verification fails, the corresponding error handling mechanism may be triggered (such as rolling back to the old version, recording error logs, trying automatic repair, etc.), (Verification: Through layered verification, it can be ensured that the code from the bottom layer to the upper layer is trustworthy. If there is a problem with the bottom layer code (such as the Boot code), the upper layer verification will not be performed, thus avoiding potential security risks. Improve security: Through mechanisms such as signature verification, it can be ensured that the code has not been tampered with or damaged during storage and transmission, thereby improving the security of the system, and enhancing reliability: Through timely error handling and recovery mechanisms, it can be ensured that the system can respond quickly and resume normal operation when encountering problems, thereby enhancing the reliability of the system.)

[0052] Step S230: If the verification result indicates that the program startup code verification is successful, and the program application code verification fails, an upgrade request corresponding to the program to be started is generated, so as to upgrade and replace the program to be started based on the upgrade request.

[0053] Specifically, when the program application code verification fails, the system will first record this event, including the time, reason and related log information of the failure.

[0054] Next, the system generates an upgrade request, which usually contains the identifier of the program to be upgraded, the current version, the target version, and any necessary upgrade parameters or configurations.

[0055] The upgrade request may be stored in the system's non-volatile memory or sent to a remote server through the vehicle's network interface (if the vehicle supports remote upgrades). If the vehicle supports local upgrades, the system may attempt to read the new program application code from the vehicle's storage medium and perform an upgrade replacement based on the upgrade request. If the vehicle supports remote upgrades, the upgrade request will be sent to the remote server. After receiving the request, the server will verify the validity of the request and prepare the corresponding upgrade package (including the new program application code and necessary metadata). The server will then send the upgrade package to the vehicle, and after receiving the upgrade package, the vehicle will verify and install the new program application code. After the upgrade is completed, the system will perform a series of verification steps to ensure that the new program application code has been correctly installed and can operate normally. These verification steps may include restarting the vehicle system, running a series of test cases, or performing actual road tests. If the verification is successful, the system will update the relevant configuration information and prepare to enter normal operation.

[0056] Step S240: If the verification result indicates that the program startup code verification fails, a prompt message corresponding to the startup failure of the program to be started is generated.

[0057] When the program startup code verification fails, the system will immediately record the event, including the time, reason and related log information of the failure.

[0058] Next, the system generates a warning message, which usually contains a detailed description of the failure, possible solutions, or suggested next steps.

[0059] The format and content of the prompt information should be clear, accurate and easy to understand so that the system administrator or user can quickly identify the problem and take appropriate measures. The prompt information can be displayed through the vehicle's display screen, sound prompt or vehicle communication interface (such as OBD-II interface).

[0060] If the vehicle is equipped with a remote monitoring and diagnostic system, the prompt message can also be sent to a remote server so that the system administrator can remotely monitor and resolve the problem. After the prompt message is generated, the system may enter a safe mode to prevent potential malicious code execution or system damage. The system administrator or user should solve the problem according to the suggestions or solutions provided in the prompt message. This may include restoring the backed-up program startup code, updating the firmware, or contacting technical support. If the problem cannot be resolved, the system may need to be shut down or restarted and wait for repair or diagnosis.

[0061] In some embodiments of the present application, by performing real-time signature value verification on the program startup code and the program application code, it can be ensured that only authorized and verified code can be executed. This helps prevent malicious code or unauthorized code from being loaded and run, thereby improving the security of the entire vehicle system. The successful verification of the program startup code is a prerequisite for the normal operation of the program. If the program startup code verification fails, the system can immediately generate a prompt message of startup failure, avoiding system instability or crash caused by the execution of erroneous code. At the same time, the verification of the program application code can also promptly discover and process potential problem codes, enhance the stability of the system, and the automated verification and upgrade mechanism reduces the need for manual intervention and reduces the maintenance cost of the vehicle system. In addition, by promptly discovering and processing potential problem codes, additional maintenance costs and time costs caused by system failures can also be avoided.

[0062] Following the above embodiments, please refer to Figure 3 In one of the exemplary embodiments provided in the present application, the specific implementation process of the real-time signature value verification of the program code may also include step S310 and step S320, which are described in detail as follows:

[0063] Step S310, calling a preset interface to obtain a real-time true random number, and determining a random inspection area of ​​the program code based on the real-time true random number;

[0064] Step S320, verifying the real-time signature value of the program code based on the random verification area.

[0065] A real-time true random number can be calculated through a preset security interface, and then a random verification area can be selected from the code area of ​​the program code through the real-time true random number. After that, a real-time signature value verification can be performed on the program code of the program to be started in the random verification area, wherein the real-time signature value can be generated by relevant network security tools or libraries.

[0066] Exemplarily, there needs to be a preset interface that can provide real-time true random numbers. True random numbers refer to random numbers that cannot be predicted or reproduced. They usually come from physical processes (such as thermal noise, cosmic rays, etc.) or high-quality random number generators. By calling this interface, you can obtain one or more real-time true random numbers. These random numbers will be used to determine the random inspection area in subsequent steps. Once the real-time true random numbers are obtained, you can use these random numbers to generate one or more random indexes or positions. These indexes or positions will be used to select specific code segments or data areas in the program code as random inspection areas. The random inspection area can be one or more continuous or scattered code segments. After determining the random inspection area, you need to calculate the real-time signature value of the program code in the area. The real-time signature value is usually obtained by processing the program code through a hash function or encryption algorithm.

[0067] Next, you need to compare the calculated real-time signature value with an expected or known signature value. This expected signature value may be generated during the compilation or release phase of the program code and stored in a secure location for verification.

[0068] If the calculated real-time signature value matches the expected signature value, it means that the part of the program code in the random verification area has not been tampered with and the verification has passed. If it does not match, it means that the program code may have been tampered with and corresponding security measures need to be taken.

[0069] In some embodiments of the present application, the random verification area determined based on the real-time true random number is dynamically changed, which means that the position and size of the verification area may be different each time the verification is performed. By comparing the real-time signature value with the data in the random verification area, it is possible to verify whether the program code has been tampered with or replaced. This verification method provides an additional layer of security and enhances the reliability of the program.

[0070] Following the above embodiments, please refer to Figure 4 In one of the exemplary embodiments provided in the present application, the specific implementation process of determining the random inspection area of ​​the program code based on real-time true random numbers may also include step S410 and step S420, which are described in detail as follows:

[0071] Step S410, generating a random index value corresponding to the program code based on a real-time true random number;

[0072] Step S420: selecting at least one random check area to be checked and a preset signature area corresponding to the random check area from a preset code area of ​​the program code based on the random index value.

[0073] Exemplarily, these real-time true random numbers are used as input to generate one or more random index values ​​through an algorithm (such as a hash function, an encryption algorithm, or a pseudo-random number generator). These random index values ​​will be used to locate the random inspection area to be verified in the preset code area of ​​the program code. The preset code area is a specific area in the program code, which contains code segments or data that may need to be verified.

[0074] Use the random index value generated in the previous step to select at least one random inspection area to be verified from the preset code area. The selection of the random inspection area should be based on the index value to ensure that the area selected for each verification is random and unpredictable. Each random inspection area should have a corresponding preset signature area, which stores the signature value corresponding to the random inspection area. The signature value is usually generated during the program code compilation or release stage and is used to verify the integrity of the random inspection area during the subsequent verification process. According to the position and size of the random inspection area, the position and size of the corresponding preset signature area can be determined.

[0075] In some embodiments of the present application, random inspection areas of different sizes and positions can be flexibly selected from a preset code area through a random index value, which makes the verification process more comprehensive and can cover different parts of the program code.

[0076] Following the above embodiments, please refer to Figure 5 In one of the exemplary embodiments provided in the present application, the specific implementation process of verifying the signature of the program code based on the random verification area may also include steps S510 to S530, which are described in detail as follows:

[0077] Step S510, performing signature calculation on the random check area to obtain a real-time signature value;

[0078] Step S520, performing asymmetric encryption calculation on the real-time signature value to obtain an encrypted real-time signature value;

[0079] Step S530, comparing the encrypted real-time signature value with the initial burning signature value corresponding to the program.

[0080] Specifically, a hash function or encryption algorithm (such as SHA-256, MD5, RSA, etc., but note that MD5 is no longer recommended due to security issues) is used to calculate the signature of the content of the random check area, where the result of the signature calculation is a fixed-length string, namely the real-time signature value, which uniquely represents the content of the random check area. After the real-time signature value is generated, in order to increase security, it can be encrypted using an asymmetric encryption algorithm (such as RSA, ECC, etc.). In asymmetric encryption, a pair of public and private keys is required. The public key is used to encrypt data, and the private key is used to decrypt data. In this scenario, the private key is usually used to encrypt the real-time signature value. The encrypted real-time signature value will be a longer, seemingly random string that cannot be easily decrypted or tampered with by unauthorized persons. The initial burning signature value is generated during the program code compilation or release stage and stored in a secure location (such as the device's read-only memory).

[0081] When verifying, the encrypted real-time signature value needs to be compared with the initial burning signature value. If the two match, it means that the program code in the random verification area has not been tampered with since compilation or release, and the verification passes. If they do not match, it means that the program code may have been tampered with, or an error occurred during the encryption process, and corresponding security measures need to be taken.

[0082] In some embodiments of the present application, the selection of a random check area enables each check to be concentrated on different parts of the code, avoiding a comprehensive check of the entire program code, which reduces the check time and improves the check efficiency. The asymmetric encryption algorithm can resist man-in-the-middle attacks and ensure that the signature value is not intercepted or tampered with by a third party during transmission. The initial burned signature value is generated when the program is first burned to the device. It serves as a benchmark for subsequent checks. By comparing it with the encrypted real-time signature value, it is possible to promptly detect whether the code has been illegally modified.

[0083] Following the above embodiments, please refer to Figure 6 In one of the exemplary embodiments provided in the present application, after comparing the encrypted real-time signature value with the initial burning signature value corresponding to the program, the specific implementation process of the vehicle startup method may further include step S610 and step S620, which are described in detail as follows:

[0084] Step S610, obtaining an initial burning signature value of the program to be started burned into the preset signature area;

[0085] Step S620: If the initial burning signature value matches the real-time signature value, a detection result indicating that the program code verification is successful is obtained.

[0086] Specifically, the initial burning signature value is generated during the program compilation or release phase, and it represents a fixed state of the program code when it is burned into the device. This signature value is usually stored in the device's read-only memory (ROM) or secure storage area to prevent tampering. During the program startup or verification phase, the initial burning signature value needs to be read from this secure storage area. The real-time signature value is obtained by hashing and encrypting the program code (or a specific area therein) before the program starts. This process usually involves using a hash algorithm (such as SHA-256) to generate a summary of the code content, and then encrypting this summary using an asymmetric encryption algorithm (such as RSA-2048). The calculation of the real-time signature value should be consistent with the generation process of the initial burning signature value to ensure that the two can be effectively compared. If the initial burning signature value matches the real-time signature value, the test result of the successful startup of the program code is obtained, and the vehicle's safe startup test is completed.

[0087] In some embodiments of the present application, the selection of a random verification area enables each verification to be concentrated on different parts of the code, avoiding a comprehensive verification of the entire program code, and through an asymmetric encryption algorithm it can ensure that the encrypted signature value is not stolen or tampered with during transmission. By quickly verifying the program code, the system startup time can be reduced and the user experience can be improved.

[0088] Following the above embodiments, please refer to Figure 7 In one of the exemplary embodiments provided in the present application, the specific implementation process of generating an upgrade request corresponding to the program to be started and upgrading and replacing the program to be started based on the upgrade request may also include steps S710 and S720, which are described in detail as follows:

[0089] Step S710, generating an upgrade request corresponding to the program to be started based on the version information corresponding to the program to be started and the terminal device information corresponding to the vehicle;

[0090] Step S720: Send the upgrade request to the server, so that the server generates a program upgrade package based on the upgrade request.

[0091] Exemplarily, firstly, by parsing the corresponding fields in the message uploaded by the vehicle, it is determined which code has failed to be verified; when the code that failed to be verified is boot, the cloud operation and maintenance platform sends the boot startup verification failure event to the car's central control screen to notify the owner to repair the vehicle in time; when the code that failed to be verified is app, the cloud operation and maintenance platform triggers the OTA process, performs online upgrades, and replaces the abnormal app. For example, when verifying the program loading code of the program to be started, if the program loading code verification fails, it is necessary to send a message of program loading code verification failure to the corresponding controller end, and then, when the controller end receives the verification failure message, it forwards the message to the cloud operation and maintenance platform. After the cloud operation and maintenance platform receives the message of the safety startup failure, it can generate an upgrade request based on the terminal device information corresponding to the vehicle and the version information corresponding to the program to be started that failed to start, and send the upgrade request to the server (cloud operation and maintenance platform) to generate a program upgrade package for the program to be started based on the upgrade request based on the cloud operation and maintenance platform.

[0092] Optionally, read the current version information of the program to be started from the terminal device or storage system of the vehicle. The version information usually includes the version number, release date, function description, etc. Collect detailed information of the vehicle terminal device, such as device model, operating system version, hardware configuration, etc. This information helps the server determine the program upgrade package suitable for the device. Combine the version information of the program to be started and the detailed information of the vehicle terminal device to generate a structured upgrade request. The upgrade request should contain necessary identification information, such as vehicle ID, device ID, current program version, target version (if known), etc. After receiving the upgrade request, the server parses the information in the request. Based on the detailed information of the vehicle terminal device, the server checks whether there is an available program upgrade package. If there is no available upgrade package, the server may return a "no update" response. If there is an available upgrade package, the server prepares the corresponding program upgrade package. The server generates a suitable program upgrade package based on the detailed information of the vehicle terminal device. The upgrade package may include new program files, configuration files, update instructions, etc. The server sends the program upgrade package back to the vehicle terminal device through the network.

[0093] In some embodiments of the present application, the precise upgrade package matching and generation process helps to ensure the compatibility of the upgraded software with the vehicle terminal equipment, which helps to ensure the stable operation of the vehicle and avoid vehicle startup failures or abnormalities caused by software upgrades.

[0094] Following the above embodiments, please refer to Figure 8 In one of the exemplary embodiments provided in the present application, the specific implementation process of the above vehicle starting method may also include steps S810 to S830, which are described in detail as follows:

[0095] Step S810, receiving the program upgrade package returned by the server, and decompressing the program upgrade package to obtain the decompressed program upgrade package;

[0096] Step S820: if the decompressed program upgrade package is complete and has not been tampered with, then the program to be started is upgraded based on the decompressed program upgrade package;

[0097] Step S830: If it is detected that the upgrade is completed, the old version information of the program to be started is deleted, and the program to be started is started based on the program upgrade package.

[0098] Specifically, after receiving the upgrade package, it will first be decompressed. The decompression process is to release the contents of the compressed file and restore it to the original folder and file structure. After the decompression is completed, the client will check whether the decompressed file is complete. This is usually achieved by comparing the hash value or size of the file. The hash value is a special digital signature that can uniquely identify the contents of a file. If the hash value of the file matches the expected hash value, it means that the file is complete and not damaged. In addition to the integrity check, the client will also verify whether the upgrade package has been tampered with. This is usually achieved through digital signature or certificate verification. When the server releases the upgrade package, it will generate a digital signature, which the client can use to verify the source and integrity of the upgrade package to ensure that it has not been maliciously modified by a third party. Finally, the client will start the program to be started based on the decompressed and verified new version of the program upgrade package. This usually involves running the executable file of the program and loading the necessary configuration files and resources.

[0099] In some embodiments of the present application, by combining the vehicle's safe start with over-the-air download technology, when the vehicle's safe start is detected and the application verification fails, the problem can be automatically solved remotely without the need for maintenance personnel to handle it, and the program upgrade package can be decompressed and verified by automated tools, which can reduce manual intervention and improve the efficiency and accuracy of the upgrade process.

[0100] Fig. 9It is a brief flowchart of vehicle startup in an exemplary application scenario. In the application scenario shown in 9, if it is detected that the vehicle is powered on successfully, the program code of the program to be started is obtained; the preset interface is called to obtain a real-time true random number, and the random check area of ​​the program code is determined based on the real-time true random number; the real-time signature value of the program code is verified based on the random check area to obtain a verification result, and the program code includes a program startup code and a program application code; if the verification result indicates that the program startup code verification is successful, and the program application code verification fails, then an upgrade request corresponding to the program to be started is generated, so as to upgrade and replace the program to be started based on the upgrade request; if the verification result indicates that the program startup code verification fails, then a prompt message corresponding to the failure to start the program to be started is generated. For the detailed implementation process, please refer to the records in the aforementioned embodiments, which will not be repeated here.

[0101] Fig.10 is a block diagram of a vehicle starting device shown in an exemplary embodiment of the present application. The device can be applied to Figure 1 The implementation environment shown is specifically configured in the intelligent terminal 110. The device may also be applicable to other exemplary implementation environments and specifically configured in other devices. This embodiment does not limit the implementation environment applicable to the device.

[0102] like Fig.10 As shown, the exemplary vehicle starting device includes: when the acquisition module 1010 detects that the vehicle is powered on successfully, the program code of the program to be started is acquired; the verification module 1020 performs real-time signature value verification on the program code to obtain a verification result, and the program code includes a program startup code and a program application code; the request module 1030 verification result indicates that the program startup code verification is successful, and if the program application code verification fails, an upgrade request corresponding to the program to be started is generated, so as to upgrade and replace the program to be started based on the upgrade request; the prompt module 1040 verification result indicates that the program startup code verification fails, and a prompt message corresponding to the failure of starting the program to be started is generated.

[0103] According to one aspect of an embodiment of the present application, the verification module 1020 also includes: calling a preset interface to obtain a real-time true random number, and determining a random verification area of ​​the program code based on the real-time true random number; and verifying the real-time signature value of the program code based on the random verification area.

[0104] According to one aspect of an embodiment of the present application, the verification module 1020 also includes: generating a random index value corresponding to the program code based on a real-time true random number; selecting at least one random verification area to be verified and a preset signature area corresponding to the random verification area from a preset code area of ​​the program code based on the random index value.

[0105] According to one aspect of an embodiment of the present application, the verification module 1020 also includes: performing signature calculation on the random check area to obtain a real-time signature value; performing asymmetric encryption calculation on the real-time signature value to obtain an encrypted real-time signature value; and comparing the encrypted real-time signature value with the initial burned signature value corresponding to the program.

[0106] According to one aspect of an embodiment of the present application, the verification module 1020 also includes: obtaining an initial burning signature value of the program to be started burned into a preset signature area; if the initial burning signature value matches the real-time signature value, a detection result indicating that the program code verification is successful is obtained.

[0107] According to one aspect of an embodiment of the present application, the request module 1020 also includes: generating an upgrade request corresponding to the program to be started based on version information corresponding to the program to be started and terminal device information corresponding to the vehicle; sending the upgrade request to the server to generate a program upgrade package based on the upgrade request based on the server.

[0108] According to one aspect of an embodiment of the present application, the above-mentioned vehicle starting device also includes: an upgrade module, which receives a program upgrade package returned by the server, and decompresses the program upgrade package to obtain a decompressed program upgrade package; if the decompressed program upgrade package is complete and has not been tampered with, the program to be started is upgraded based on the decompressed program upgrade package; if it is detected that the upgrade is complete, the old version information of the program to be started is deleted, and the program to be started is started based on the program upgrade package.

[0109] The vehicle starting device provided in the above embodiment and the vehicle starting method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs the operation has been described in detail in the method embodiment, and will not be repeated here. In practical applications, the vehicle starting device provided in the above embodiment can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not limited here.

[0110] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by one or more processors, the electronic device implements the vehicle starting method provided in the above-mentioned embodiments.

[0111] Fig.11 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. Fig.11 The computer system 1100 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0112] like Fig.11 As shown, the computer system 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1102 or the program loaded from the storage part 1108 to the random access memory (RAM) 1103, such as executing the method described in the above embodiment. In the RAM 1103, various programs and data required for system operation are also stored. The CPU 1101, the ROM 1102 and the RAM 1103 are connected to each other through the bus 1104. The input / output (I / O) interface 1105 is also connected to the bus 1104.

[0113] The following components are connected to the I / O interface 1105: an input section 1106 including a keyboard, a mouse, etc.; an output section 1107 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the I / O interface 1105 as needed. A removable medium 1111, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1110 as needed so that a computer program read therefrom is installed into the storage section 1108 as needed.

[0114] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1109, and / or installed from a removable medium 1111. When the computer program is executed by a central processing unit (CPU) 1101, various functions defined in the system of the present application are executed.

[0115] The computer-readable medium shown in the embodiment of the present application can be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium can be, for example, a system, device or device of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable signal medium can include a data signal propagated in a baseband or as a part of a carrier wave, wherein a computer-readable computer program is carried. This propagated data signal can take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. A computer program contained on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

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

[0117] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0118] Another aspect of the present application further provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the vehicle starting method as described above is implemented. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0119] Another aspect of the present application also provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the vehicle starting method provided in each of the above embodiments.

[0120] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. A vehicle starting method, characterized in that: include: If it is detected that the vehicle is powered on successfully, the program code of the program to be started is obtained; Performing real-time signature value verification on the program code to obtain a verification result, wherein the program code includes a program startup code and a program application code; If the verification result indicates that the program startup code verification succeeds, and the program application code verification fails, then generating an upgrade request corresponding to the program to be started, so as to upgrade and replace the program to be started based on the upgrade request; If the verification result indicates that the program startup code verification fails, a prompt message corresponding to the startup failure of the program to be started is generated.

2. The method according to claim 1, characterized in that The real-time signature value verification of the program code includes: Calling a preset interface to obtain a real-time true random number, and determining a random inspection area of ​​the program code based on the real-time true random number; The real-time signature value of the program code is verified based on the random verification area.

3. The method according to claim 2, characterized in that The method of determining the random inspection area of ​​the program code based on the real-time true random number comprises: Generate a random index value corresponding to the program code based on the real-time true random number; At least one random verification area to be verified and a preset signature area corresponding to the random verification area are selected from a preset code area of ​​the program code based on the random index value.

4. The method according to claim 3, characterized in that The verifying the signature of the program code based on the random verification area includes: Performing signature calculation on the random verification area to obtain a real-time signature value; Performing asymmetric encryption calculation on the real-time signature value to obtain an encrypted real-time signature value; The encrypted real-time signature value is compared with the initial burning signature value corresponding to the program.

5. The method according to claim 4, characterized in that After comparing the encrypted real-time signature value with the initial burning signature value corresponding to the program, the method further includes: Obtaining an initial burning signature value of the program to be started burned into the preset signature area; If the initial burning signature value matches the real-time signature value, a detection result indicating that the program code verification is successful is obtained.

6. The method according to claim 1, characterized in that The generating an upgrade request corresponding to the program to be started, so as to upgrade and replace the program to be started based on the upgrade request, includes: Generate an upgrade request corresponding to the program to be started based on the version information corresponding to the program to be started and the terminal device information corresponding to the vehicle; The upgrade request is sent to a server, so that the server generates a program upgrade package based on the upgrade request.

7. The method according to claim 6, characterized in that The method further comprises: receiving the program upgrade package returned by the server, and decompressing the program upgrade package to obtain a decompressed program upgrade package; If the decompressed program upgrade package is complete and has not been tampered with, upgrading the program to be started based on the decompressed program upgrade package; If it is detected that the upgrade is completed, the old version information of the program to be started is deleted, and the program to be started is started based on the program upgrade package.

8. A vehicle starting device, characterized in that: The device comprises: The acquisition module acquires the program code of the program to be started if it detects that the vehicle is powered on successfully; A verification module performs real-time signature value verification on the program code to obtain a verification result, wherein the program code includes a program startup code and a program application code; a request module, if the verification result indicates that the program startup code verification is successful, and the program application code verification fails, then generating an upgrade request corresponding to the program to be started, so as to upgrade and replace the program to be started based on the upgrade request; The prompt module generates prompt information corresponding to the failure of starting the program to be started if the verification result indicates that the program startup code verification fails.

9. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enables the electronic device to implement the vehicle starting method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Computer-readable instructions are stored thereon, and when the computer-readable instructions are executed by a processor of a computer, the computer is caused to execute the vehicle starting method according to any one of claims 1 to 7.

Images