Vehicle-mounted controller equipment starting method and device

Abstract

The invention discloses a vehicle-mounted controller equipment starting method and device, and relates to the technical field of automobile safety. The method comprises the following steps: under the condition that a mirror image file is loaded to a dynamic random access memory, acquiring Android verification starting data in the mirror image file by operating a secondary starting loading program; generating a first hash value based on the head data block and the auxiliary data block, and verifying the first hash value and a second hash value stored in the authentication data block to obtain a first verification result; when the first verification result indicates that the first hash value is consistent with the second hash value, performing signature verification operation on a target signature pre-stored in the authentication data block to obtain a signature verification result; and under the condition that the signature verification result indicates that the authentication data block is credible, verifying the original mirror image in the mirror image file based on the auxiliary data block, and starting the mirror image file when the verification of the original mirror image is passed. According to the embodiment of the invention, the starting of the vehicle-mounted controller in the vehicle can be realized with lower cost and high safety.

Description

Technical Field

[0001] The present application belongs to the field of automobile safety technology, and in particular, relates to a method and device for starting a vehicle-mounted controller device. Background Art

[0002] At present, with the increasing degree of automobile electrification, the vehicle controller, as one of the core components of the automotive electronic system, undertakes the important task of vehicle control and management. In order to protect the vehicle controller from attacks and illegal access and ensure the safe and reliable operation of the vehicle system, the suppliers of vehicle electronic components have to consider the secure startup of the vehicle controller. The current existing technical solutions generally use HS (High Security) hardware devices in conjunction with software-level data encryption and startup authentication to ensure the secure startup of the firmware image. Compared with GP (General-Purpose) devices, HS devices have higher security features. They have added hardware security modules, such as secure encryption engines, secure memory, secure boot, etc., to provide higher data and system security.

[0003] However, although HS devices have higher safety performance than GP devices, many manufacturers sacrifice safety performance and use GP devices in order to reduce costs due to the high cost of HS devices. Based on this, the industry is still in urgent need of a new vehicle controller device startup solution to achieve the goal of fully realizing the safe startup of vehicle controllers while reducing costs. Summary of the invention

[0004] The embodiments of the present application provide a method and apparatus for starting a vehicle-mounted controller device, which can effectively start the vehicle-mounted controller in a vehicle at a lower cost and with higher safety, thereby effectively ensuring the safe and reliable operation of the overall vehicle system.

[0005] In a first aspect, an embodiment of the present application provides a method for starting a vehicle-mounted controller device, the method for starting a vehicle-mounted controller device comprising:

[0006] When the image file is loaded into the dynamic random access memory in the vehicle controller device, the Android verification startup data in the image file is obtained by running the secondary boot loader, where the Android verification startup data includes a header data block, an auxiliary data block, and an authentication data block;

[0007] Generate a first Hash value based on the header data block and the auxiliary data block, and verify the first Hash value with the second Hash value stored in the authentication data block to obtain a first verification result;

[0008] When the first verification result indicates that the first hash value and the second hash value are consistent, performing a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result;

[0009] When the signature verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes.

[0010] In some possible implementations, when the first verification result indicates that the first hash value and the second hash value are consistent, performing a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result includes:

[0011] When the first verification result indicates that the first hash value and the second hash value are consistent, determine to encrypt the target signature by using the first preset public key to obtain a third hash value;

[0012] Compare the third hash value with the fourth hash value corresponding to the target signature in the authentication data block to obtain a signature verification result;

[0013] Among them, when the third hash value and the fourth hash value are consistent, the signature verification result indicates that the authentication data block is credible.

[0014] In some possible implementations, when the first verification result indicates that the first Hash value and the second Hash value are consistent, determining to encrypt the target signature by using the first preset public key to obtain a third Hash value includes:

[0015] Transmitting the target signature in the authentication data block to a security chip, wherein a prefabricated first preset public key is pre-stored in the security chip;

[0016] A third hash value is received by encrypting the target signature using the first preset public key by the security chip.

[0017] In some possible implementations, when the first verification result indicates that the first Hash value and the second Hash value are consistent, determining to encrypt the target signature by using the first preset public key to obtain a third Hash value includes:

[0018] Based on the auxiliary data block, extracting a preselected and stored first preset public key;

[0019] The target signature is encrypted using the first preset public key to obtain a third hash value.

[0020] In some possible implementations, when the signature verification result indicates that the authentication data block is credible, verifying the original image in the image file based on the auxiliary data block, and starting the image file when the original image verification passes, includes:

[0021] If the signature verification result indicates that the authentication data block is credible, calling a second preset public key prefabricated in the secondary boot loader;

[0022] Compare the first preset public key with the second preset public key, and verify the original image based on the auxiliary data block when the first preset public key is consistent with the second preset public key;

[0023] If the original image is verified to be successful, start the image file.

[0024] In some possible implementations, when the image file is loaded into a dynamic random access memory in a vehicle-mounted controller device, obtaining Android verification boot data in the image file by running a secondary boot loader includes:

[0025] When the image file is loaded into the dynamic random access memory, the data size and offset information of the Android verification startup data are obtained from the tail data block in the image file by running the secondary boot loader;

[0026] Based on the data size and offset information of the Android verification startup data, the Android verification startup data is extracted from the image file.

[0027] In some possible implementations, when the signature verification result indicates that the authentication data block is credible, verifying the original image in the image file based on the auxiliary data block, and starting the image file when the original image verification passes, includes:

[0028] When the signature verification result indicates that the authentication data block is credible, extract the salt value data stored in the auxiliary data block;

[0029] Based on the salt value data and the original image, a fifth hash value corresponding to the original image is calculated;

[0030] The fifth hash value is compared with the preset hash summary data in the auxiliary data block, and the image file is started when the fifth hash value is consistent with the preset hash summary data.

[0031] In some possible implementations, before obtaining the Android verification startup data in the image file by running the secondary boot loader, the vehicle controller device startup method further includes:

[0032] When the secondary boot loader in the vehicle controller device is started, obtaining system partition information of the vehicle controller device;

[0033] Based on the system partition information, a target image partition to be loaded is determined from N image partitions, and the image file in the target image partition is loaded into the dynamic random access memory, where N is a positive integer greater than or equal to 2.

[0034] In some possible implementations, when the image file is loaded into the dynamic random access memory in the vehicle controller device, before obtaining the Android verification startup data in the image file by running the secondary boot loader, the vehicle controller device startup method further includes:

[0035] Get the image file signed by the signature server.

[0036] Based on the same inventive concept, in a second aspect, an embodiment of the present application provides a vehicle-mounted controller device starting device, the vehicle-mounted controller device starting device comprising:

[0037] A first acquisition module is used to acquire Android verification startup data in the image file by running a secondary boot loader when the image file is loaded into a dynamic random access memory in the vehicle-mounted controller device, wherein the Android verification startup data includes a header data block, an auxiliary data block, and an authentication data block;

[0038] A first verification module, configured to generate a first Hash value based on the header data block and the auxiliary data block, and verify the first Hash value with a second Hash value stored in the authentication data block to obtain a first verification result;

[0039] A first signature verification module, configured to perform a signature verification operation on a target signature pre-stored in the authentication data block to obtain a signature verification result when a first verification result indicates that the first hash value and the second hash value are consistent;

[0040] The first startup module is used to verify the original image in the image file based on the auxiliary data block when the signature verification result indicates that the authentication data block is credible, and to start the image file when the original image passes the verification.

[0041] In a third aspect, an embodiment of the present application provides a vehicle-mounted controller device startup device, the vehicle-mounted controller device startup device comprising:

[0042] a processor and a memory storing computer program instructions;

[0043] When the processor executes the computer program instructions, it implements the vehicle controller device startup method provided in any one of the above-mentioned embodiments of the present application.

[0044] In a fourth aspect, an embodiment of the present application provides a computer storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, a vehicle controller device startup method as provided in any one of the above-mentioned embodiments of the present application is implemented.

[0045] In a fifth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes a vehicle controller device startup method as provided in any one of the above-mentioned embodiments of the present application.

[0046] The embodiment of the present application provides a method and device for starting a vehicle controller device. When the image file is loaded into the dynamic random access memory in the vehicle controller device, the Android verification startup data in the image file is obtained by running the secondary boot loader. In this case, a first hash value is generated based on the header data block and the auxiliary data block of the Android verification startup data, and the first hash value is verified with the second hash value stored in the authentication data block. When the first hash value and the second hash value are consistent, the target signature pre-stored in the authentication data block is verified to obtain a verification result. Finally, when the verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes.

[0047] From the above description, it can be seen that a method and apparatus for starting a vehicle-mounted controller device in an embodiment of the present application, compared with the prior art, does not require the use of high-cost HS equipment. By adding the above-mentioned secure boot verification process to the secondary boot loader of a general device, it can use the Android verification boot data pre-stored with a target signature to perform valid data signature verification operations and perform original image verification. The image file is allowed to be started only when the above-mentioned secure boot process verification is passed, thereby reducing the risk of operational attacks and illegal access to the vehicle controller device, and can achieve effective startup of the vehicle-mounted controller in the vehicle with lower cost and higher security, thereby effectively ensuring the safe and reliable operation of the overall vehicle system. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0049] Figure 1 This is a schematic diagram of a process for verifying an image file of an HS device provided in an embodiment of the present application;

[0050] Figure 2 It is a flowchart of a method for starting a vehicle controller device provided by an embodiment of the present application;

[0051] Figure 3 This is a schematic diagram of an image file with Android verification startup data added provided by an embodiment of the present application;

[0052] Figure 4 It is a scenario flow diagram of a method for starting a vehicle controller device provided in an embodiment of the present application;

[0053] Figure 5 It is a structural schematic diagram of a vehicle controller device starting device provided by an embodiment of the present application;

[0054] Figure 6 It is a structural diagram of a vehicle controller device starting device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0055] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present application by illustrating the examples of the present application.

[0056] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0057] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0058] It should be noted that the bootloader image file mentioned below in this application can be understood as a boot loader, whose main function is to initialize hardware devices, set hardware parameters, and load the operating system kernel. In an embedded system, the bootloader is the first program executed after the hardware is started. It is located between the operating system and the hardware and acts as a bridge.

[0059] As mentioned in the background technology section, HS devices have higher security features than GP (General-Purpose) devices. Figure 1 , Figure 1 It is a flow chart of the HS device verifying the image file provided by an embodiment of the present application, and the image file is, for example, a bootloader image file. When the HS device performs a secure boot, the root of trust (RoT) verifies the legitimacy of the public key in the bootloader image file. If the verification passes, the bootloader image file is started, and if the verification fails, it is not started. The root of trust is the earliest program started after the device is powered on. It runs in the read-only chip BOOT ROM. Since the root certificate in the BOOT ROM is only allowed to be written once and cannot be modified, it can be responsible for verifying the legitimacy of the image file. The bootloader image file will be started only if there is no problem with the verification.

[0060] However, although HS devices have higher security performance than GP devices, their prices are much higher than GP devices. Therefore, many manufacturers sacrifice security performance and use GP devices in order to reduce costs. GP devices have a wide range of functions and flexibility, and are generally suitable for application scenarios that require processing multiple types of data and tasks. However, compared with HS devices, they lack hardware security modules and cannot guarantee the security of their internal images. There is a risk of data tampering and illegal access by malicious parties, which poses a security risk when used in the automotive industry with high security requirements.

[0061] In view of the above, in order to solve the problems of the prior art, the embodiments of the present application provide a method and apparatus for starting a vehicle controller device, so as to fully realize the safe startup of the vehicle controller while reducing the cost. It should be noted that the embodiments provided in the present application are not intended to limit the scope of the present application.

[0062] The following first introduces the vehicle controller device startup method provided in the embodiment of the present application.

[0063] Figure 2 The flowchart of the vehicle controller device startup method provided by an embodiment of the present application is shown. The vehicle controller device is specifically a GP general device in order to reduce the device cost. Figure 2 As shown, the vehicle controller device startup method includes the following steps:

[0064] S210, when the image file is loaded into the dynamic random access memory in the vehicle-mounted controller device, obtaining Android verification startup data in the image file by running the secondary boot loader, where the Android verification startup data includes a header data block, an auxiliary data block, and an authentication data block;

[0065] S220, generating a first hash value based on the header data block and the auxiliary data block, and verifying the first hash value with the second hash value stored in the authentication data block to obtain a first verification result;

[0066] S230, when the first verification result indicates that the first hash value and the second hash value are consistent, performing a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result;

[0067] S240: If the signature verification result indicates that the authentication data block is credible, verify the original image in the image file based on the auxiliary data block, and start the image file if the original image passes the verification.

[0068] An embodiment of the present application provides a method for starting a vehicle controller device, which obtains Android verification startup data in the image file by running a secondary boot loader when the image file is loaded into the dynamic random access memory in the vehicle controller device. In this case, a first hash value is generated based on the header data block and the auxiliary data block of the Android verification startup data, and the first hash value is verified with the second hash value stored in the authentication data block. When the first hash value and the second hash value are consistent, a verification operation is performed on the target signature pre-stored in the authentication data block to obtain a verification result. Finally, when the verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes.

[0069] From the above description, it can be seen that a vehicle-mounted controller device startup method according to an embodiment of the present application does not require the use of high-cost HS equipment compared to the prior art. It adds the above-mentioned secure startup verification process to the Android verification startup program of a general device, and can use the Android verification startup data pre-stored with a target signature to perform valid data signature verification operations and perform original image verification. The image file is allowed to be started only when the above-mentioned secure startup process verification is passed, thereby reducing the risk of vehicle controller device operation attacks and illegal access, and can achieve effective startup of the vehicle-mounted controller in the vehicle with lower cost and higher security, thereby effectively ensuring the safe and reliable operation of the overall vehicle system.

[0070] The specific implementation of the above steps 210 to 240 is described in detail below.

[0071] In S210, when the image file is loaded into the dynamic random access memory in the vehicle-mounted controller device, the Android Verified Boot (hereinafter referred to as AVB data) in the image file is obtained by running the secondary boot loader (Secondary Boot Loader, hereinafter referred to as SBL program), and the AVB data includes a header data block, an auxiliary data block and an authentication data block.

[0072] The following is an example of an image file such as a bootloader image file. In other feasible embodiments, the image file may also be other. Specifically, considering that the GP device lacks the hardware security module BOOTROM compared to the HS device, the GP device does not have root of trust and cannot guarantee the security of the subsequent bootloader image file. Therefore, in this application, the bootloader image file is verified by running the SBL program. SBL is a secondary boot loader and plays an important role in the startup process of devices such as embedded systems, smart phones, and automotive ECUs (Electronic Control Units). SBL is responsible for loading the system image from the storage device and performing necessary verification to ensure the integrity and correctness of the image. Before loading the system image, SBL may also need to perform some system initialization tasks, such as setting the working mode of the CPU (Central Processing Unit), initializing the memory, configuring peripherals, etc.

[0073] Since SBL is a necessary stage for device startup, this application adds bootloader verification in SBL and verifies the bootloader image file by using the AVB software verification process to ensure the safe startup of the bootloader image file.

[0074] In this embodiment, the above AVB data can be pre-added in the bootloader image file so as to implement security verification of the bootloader image file based on AVB. In this way, when the bootloader image file is loaded into the dynamic random access memory in the vehicle controller device, the AVB data in the bootloader image file is first obtained. Figure 3 , Figure 3 Schematic diagram of a bootloader image file with AVB data added provided by an embodiment of the present application. Figure 3As shown in the figure, in the bootloader image file, raw image is the original image of the bootloader; padding is the padding byte. Header data, Authentication data, and Auxiliarydata are added AVB data (vbmeta blob) responsible for verifying the legitimacy of the raw image.

[0075] Optionally, in some feasible embodiments of the present application, considering that the device often has the characteristic of dual partition loading for the image file, in order to realize accurate loading of the above image file, so as to realize efficient and safe verification and operation based on the image file in the subsequent implementation, before the above-mentioned Android verification startup data in the image file is obtained by running the secondary boot loader, the vehicle controller device startup method also includes:

[0076] When the secondary boot loader in the vehicle controller device is started, obtaining system partition information of the vehicle controller device;

[0077] Based on the system partition information, a target image partition to be loaded is determined from N image partitions, and the image file in the target image partition is loaded into the double data rate memory, where N is a positive integer greater than or equal to 2.

[0078] In this embodiment, the above-mentioned double data rate memory (Double Data Rate, DDR) is a memory module that can transmit data at both the rising edge and the falling edge of each clock cycle. Compared with the transmission access memory, it has higher data transmission efficiency and allows faster data processing speed.

[0079] In one example, after the vehicle controller device is powered on, the SBL program is executed first. In the SBL program, the system partition information (such as partition a or partition b) required by the vehicle controller device is first obtained to determine the image partition to be loaded. Then the bootloader image file of partition a or b is loaded into the DDR memory so that the signature verification operation can be performed on the parsed bootloader image file later.

[0080] It should be added that the a / b partitions in this embodiment are usually designed to support upgrades, so there is no essential difference between the partitions, and the same software image can be stored in different partitions. For example, assuming that the current operation is in partition a, when we need to upgrade the software, we can upgrade the image of partition b. After the upgrade is completed, switch to partition b to run, so that the upgraded software is switched to run. Different partitions may run in different situations. This application needs to select the partition required to run on the actual device, and load the bootloader image file stored therein into the DDR memory for security verification, so as to effectively check whether the bootloader image file has been tampered with.

[0081] Optionally, in some feasible embodiments of the present application, in order to more reasonably realize the acquisition of AVB data in the above-mentioned image file, when the image file is loaded into the double data rate memory in the vehicle controller device, the Android verification startup data in the image file is acquired by running the secondary boot loader, including:

[0082] When the image file is loaded into the double data rate memory, the data size and offset information of the Android verification boot data are obtained from the tail data block in the image file by running the secondary boot loader;

[0083] Based on the data size and offset information of the Android verification startup data, the Android verification startup data is extracted from the image file.

[0084] For example, please see Figure 3 The bootloader image file also includes a footer (tail data block), which is the memory space at the end of the bootloader image file, and can store the size and offset information of the AVB data added by some files. In this way, by accessing the footer data block, the size and offset of the AVB data (vbmeta blob) stored inside it can be obtained, so that the above AVB data can be quickly and accurately determined based on the data size and offset information.

[0085] In S220, when specifically implemented, after obtaining the above AVB data from the bootloader image file, a first hash value is generated based on the header data block and the auxiliary data block in the AVB data. When generating the first hash value, a SHA-256 (Secure Hash Algorithm 256-bit) cryptographic hash function can be specifically used to calculate the hash value. Then, the first hash value is verified with the second hash value stored in the authentication data block to obtain a first verification result.

[0086] The first verification result can be used to characterize whether the first hash value and the second hash value are consistent. In this embodiment, the data in the authentication data block is first assumed to be credible, and then the header data block and the auxiliary data block in the AVB data are verified with the second hash value stored in the authentication data block. If the first hash value and the second hash value are equal, it can be considered that the data in the header data block and the auxiliary data block in the AVB data are credible.

[0087] It should be added that the above-mentioned second hash value can be pre-encrypted based on the original auxiliary data block and header data block and stored in the authentication data block, so as to authenticate the data in the header data block and the auxiliary data block in the subsequent bootloader image secure boot verification process.

[0088] In S230, when the first verification result indicates that the first hash value and the second hash value are consistent, the data of the header data block and the auxiliary data block in the AVB data can be considered to be credible. In this case, the data in the authentication data block is verified to be credible and whether it has been tampered with.

[0089] In this embodiment, the authentication data block may be pre-signed by the signature server. Specifically, when performing security verification on the authentication data block, a signature verification operation is performed on the target signature pre-stored in the authentication data block, so that the security verification of the authentication data block can be performed according to the signature verification result.

[0090] Optionally, in some feasible embodiments of the present application, when the image file is loaded into the double data rate memory in the vehicle controller device, before the secondary boot loader is executed to obtain the AVB data in the image file, the vehicle controller device startup method further includes:

[0091] Get the image file signed by the signature server.

[0092] In this embodiment, since the signature is issued by the signature server, the signature server is trustworthy, and thus the image file can be effectively guaranteed to be trustworthy by verifying its signature.

[0093] Optionally, in some feasible embodiments of the present application, in order to more reasonably and safely implement the signature verification operation on the target signature in the above-mentioned authentication data block, when the first verification result indicates that the first hash value and the second hash value are consistent, the signature verification operation is performed on the target signature pre-stored in the authentication data block to obtain the signature verification result, including:

[0094] When the first verification result indicates that the first hash value and the second hash value are consistent, determine to encrypt the target signature by using the first preset public key to obtain a third hash value;

[0095] Compare the third hash value with the fourth hash value corresponding to the target signature in the authentication data block to obtain a signature verification result;

[0096] Among them, when the third hash value and the fourth hash value are consistent, the signature verification result indicates that the authentication data block is credible.

[0097] In this embodiment, when the first verification result indicates that the first hash value and the second hash value are consistent, the data in the authentication data block is verified to be credible. The authentication data block is pre-written with the target signature and the fourth hash value corresponding to the target signature.

[0098] When performing the signature verification operation, the target signature is encrypted using the first preset public key to obtain a third hash value, which is then compared with the fourth hash value in the authentication data block to obtain the above-mentioned signature verification result, so that the security of the authentication data block can be verified based on the signature verification result.

[0099] It should be added that, in this embodiment, the first preset public key can be formulated in advance according to the hash encryption algorithm used by the fourth hash value, so that the third hash value and the fourth hash value are encrypted using the same encryption algorithm when the data has not been tampered with. In this way, the comparability of the third hash value and the fourth hash value can be guaranteed.

[0100] Optionally, in some feasible embodiments of the present application, in order to provide a higher security level for the above-mentioned signature verification operation, when the first verification result indicates that the first hash value and the second hash value are consistent, determining to encrypt the target signature by using the first preset public key to obtain a third hash value includes:

[0101] Transmitting the target signature in the authentication data block to a security chip, wherein a prefabricated first preset public key is pre-stored in the security chip;

[0102] A third hash value is received by encrypting the target signature using the first preset public key by the security chip.

[0103] In one example, the security chip may be an ESE (embedded Secure Element) security chip, which is an embedded security chip that can provide independent chip-based security protection for the device. In this embodiment, by storing the first preset public key in the ESE security chip, the ESE security chip is effectively combined to perform collaborative signature verification.

[0104] In specific implementation, the ESE security chip and the vehicle controller device can be connected to each other through a peripheral interface or other means. When the vehicle controller device needs to verify the credibility of the authentication data block, the target signature in the authentication data block is sent to the ESE security chip. The ESE security chip will perform hardware encryption on the received target signature with the first preset public key pre-set therein, and return the encrypted third hash value.

[0105] Next, after receiving the third hash value sent by the ESE security chip, the third hash value is compared with the fourth hash value stored in the authentication data block, so as to obtain the final signature verification result, which can determine whether the data in the authentication data block is credible.

[0106] In this embodiment, an ESE security chip with multiple hardware-level security sensors and rich cryptographic algorithms is used to assist in the security startup verification of the vehicle controller device. By storing the above-mentioned first preset public key in the ESE security chip, it is equivalent to adding a layer of security protection for the public key data. In addition, the encryption process of the target signature is completely implemented by the ESE security chip through hardware operations, so the encryption result also has higher reliability and can meet the diverse security requirements of complex business terminals.

[0107] Optionally, another signature verification method is provided in some feasible embodiments of the present application. Specifically, when the first verification result indicates that the first hash value and the second hash value are consistent, determining that the target signature is encrypted by the first preset public key to obtain a third hash value includes:

[0108] Based on the auxiliary data block, extracting a preselected and stored first preset public key;

[0109] The target signature is encrypted using the first preset public key to obtain a third hash value.

[0110] In a specific implementation, the first preset public key is extracted from the verified auxiliary data block, and the target signature in the authentication data block is encrypted with the first preset public key to obtain the third hash value. The third hash value can be used to compare with the fourth hash value to obtain the final verification result of the authentication data block.

[0111] More specifically, considering that the data in the auxiliary data block cannot be fully guaranteed to be credible, for example, a malicious party signs with his own private key, and the public key is stored in the auxiliary data block, then it is possible that the signature verification result in this case is credible. Therefore, in order to further confirm the reliability of the above-mentioned signature verification result, when the signature verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes, including:

[0112] If the signature verification result indicates that the authentication data block is credible, calling a second preset public key prefabricated in the secondary boot loader;

[0113] Compare the first preset public key with the second preset public key, and verify the original image based on the auxiliary data block when the first preset public key is consistent with the second preset public key;

[0114] If the original image is verified to be successful, start the image file.

[0115] In this embodiment, in order to prevent the situation that, for example, the entire image file is tampered with, after obtaining the above-mentioned signature verification result, the reliability and accuracy of the first preset public key in the auxiliary data block will be further verified again.

[0116] In the specific implementation, the second preset public key prefabricated in the SBL program is used to compare it with the first preset public key in the auxiliary data block. If the data in the auxiliary data block has not been tampered with, the first preset public key and the second preset public key are equal. If the data in the auxiliary data block has been tampered with, the first preset public key and the second preset public key may not be equal, in which case the aforementioned signature verification result is unreliable. In this way, by setting the verification confirmation of the above-mentioned first preset public key, the aforementioned security verification can be fully guaranteed to be credible.

[0117] In S240, when the signature verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block to ensure that the original image has not been tampered with. If the original image verification passes, the image file is started. Taking the image file as a bootloader image file as an example, when the bootloader image file is specifically started, the bootloader image can be started by running the above-mentioned bootloader original image that has passed the final security verification, and no strict restrictions are made here.

[0118] Optionally, in some feasible embodiments of the present application, in order to more reasonably implement the reliability verification of the above-mentioned original image to provide a higher level of secure startup of the vehicle controller device, when the signature verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes, including:

[0119] When the signature verification result indicates that the authentication data block is credible, extract the salt value data stored in the auxiliary data block;

[0120] Based on the salt value data and the original image, a fifth hash value corresponding to the original image is calculated;

[0121] The fifth hash value is compared with the preset hash summary data in the auxiliary data block, and the image file is started when the fifth hash value is consistent with the preset hash summary data.

[0122] Specifically, since the AVB data in the image file is guaranteed to be credible after the aforementioned verification process, the AVB data can continue to be used to verify the original image in the image file.

[0123] Specifically, firstly, the salt value data (salt data) stored in the auxiliary data block is extracted, and the fifth hash value is calculated together with the data in the original image, and then the fifth hash value is compared with the preset hash summary data in the auxiliary data block. If the fifth hash value is consistent with the preset hash summary data, it means that the original image data is legal and has not been tampered with. In this case, the above image file is started.

[0124] It should be added that the preset hash summary data in the auxiliary data block is the digest data of the auxiliary data block, and the digest data is a hash value related to the original image. This hash value is obtained by hashing the image data and can be used to verify the integrity of the image and that it has not been tampered with.

[0125] In order to facilitate understanding of the vehicle controller device startup method provided in the above embodiment, the above method is described below using a specific scenario embodiment. Figure 4 It is a scenario flow diagram of a method for starting a vehicle controller device provided in an embodiment of the present application.

[0126] This scenario embodiment provides a secure boot solution based on a vehicle controller device, which improves the safety performance of the vehicle controller device by adding a secure boot process on the GP device.

[0127] like Figure 4 As shown, the scenario embodiment may specifically include the following steps:

[0128] After the vehicle controller device is powered on, the SBL program is executed first. In the SBL program, the a / b partition information is first obtained to determine the image partition to be loaded; then the bootloader image file of the a partition or b partition is loaded into the DDR memory; and then data security verification is performed based on the bootloader image file.

[0129] During the specific verification, the data size and offset information of the AVB data are obtained from the footer (tail data block) in the bootloader image file, so as to obtain the AVB data (corresponding to Figure 3vbmeta blob data); then verify the header data block and the auxiliary data block in the AVB data. In this scenario embodiment, the data of the authentication data block in the AVB data is assumed to be credible, and the first hash value calculated by using the header and auxiliary data blocks is compared with the second hash value stored in the authentication data block. If they are equal, it means that the data of the header and auxiliary data blocks are credible.

[0130] The next step is to verify the credibility of the authentication data block in the AVB data, such as Figure 4 As shown, this scenario embodiment provides the following two specific verification schemes.

[0131] Option 1, reference Figure 4 As shown in the dotted box on the left, the AVB processing flow is adopted to extract the first preset public key from the verified auxiliary data block, and then perform a signature verification operation on the signature (target signature) stored in the authentication data block according to the first preset public key, and compare the obtained third hash value with the fourth hash value corresponding to the target signature stored in the authentication data block. If they are equal, it means that the data in the authentication data block is credible. In this way, the data credibility verification of AVB data is completed.

[0132] In order to further improve the reliability and security of the above data verification, this scenario embodiment takes into account the prevention of the entire bootloader image from being tampered with. For example, a malicious party signs with his own private key and puts the public key in the auxiliary block. Then it is possible that such AVB data can be verified by hash value and public key. Therefore, after completing the AVB data verification, a process of confirming the above first preset public key is added. That is, by using the public key (second preset public key) prefabricated in the SBL and the public key (first preset public key) in the auxiliary block for comparison. If the first preset public key and the second preset public key are equal, it means that the entire verification process of the AVB data is credible.

[0133] Option 2, reference Figure 4The dashed box on the right shows the signature verification process of the ESE security chip. First, the ESE security chip is initialized; then the target signature stored in the authentication data block is passed to the ESE security chip, which uses the first preset public key pre-set in it to perform hardware encryption on the target signature and returns the encrypted third hash value.

[0134] Next, the returned third hash value is compared with the fourth hash value stored in the authentication data block. If they are equal, it means that the data in the authentication data block is credible, and further indicates that the above-mentioned entire AVB data verification process is credible.

[0135] It should be emphasized that due to the verification failure problem caused by the replacement of the entire SBL image, compared with the aforementioned signature verification scheme in which the public key is prefabricated in the SBL code, the second scheme uses the ESE security chip to increase the security protection of the public key data, and the encryption of the target signature is implemented by the ESE security chip through hardware operation, so it has higher reliability.

[0136] Please continue to refer to Figure 4 At the end of the bootloader image file verification process, the bootloader original image needs to be verified and compared. The bootloader original image can refer to the above Figure 3 The raw image part of the image file shown in the figure. Since the AVB data in the bootloader image file has been guaranteed to be credible through the above verification process, the AVB data can continue to be used to verify the above bootloader raw image.

[0137] Specifically, first extract the salt data stored in the auxiliary data block, calculate the fifth hash value together with the bootloader original image, and compare the calculated fifth hash value with the digest data stored in the auxiliary data block. If they are the same, it means that the bootloader original image data is legal and has not been tampered with. In this way, the entire bootloader verification is completed, and the bootloader image that passes the verification can be legally started.

[0138] In the present scenario embodiment, the present invention adds a bootloader verification process on the GP device, especially taking the aforementioned solution 2 as an example, by combining software and hardware (SBL+AVB+ESE) verification processing, adds a secure boot process on the GP device and combines the ESE security chip for signature verification. Compared with pure software verification, it has higher reliability, improves the security of vehicle controller device startup and operation, and reduces the risk of vehicle controller system being attacked and illegally accessed. In addition, the cost of using a GP device with secure boot capability is greatly reduced compared to using an HS device, thereby effectively achieving cost control.

[0139] Based on the vehicle controller device startup method provided in the above embodiment, out of the same inventive concept, the present application also provides a vehicle controller device startup device corresponding to the vehicle controller device startup method. Figure 5 The vehicle-mounted controller equipment starting device is introduced in detail.

[0140] Figure 5 A schematic diagram of the structure of a vehicle controller device starting device provided in one embodiment of the present application is shown. Figure 5 The vehicle-mounted controller device starting device 500 shown includes:

[0141] A first acquisition module 510 is used to acquire Android verification boot data in the image file by running a secondary boot loader when the image file is loaded into the double data rate memory in the vehicle controller device, wherein the Android verification boot data includes a header data block, an auxiliary data block and an authentication data block;

[0142] A first verification module 520, configured to generate a first Hash value based on the header data block and the auxiliary data block, and verify the first Hash value with a second Hash value stored in the authentication data block to obtain a first verification result;

[0143] The first signature verification module 530 is used to perform a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result when the first verification result indicates that the first hash value and the second hash value are consistent;

[0144] The first starting module 540 is used to verify the original image in the image file based on the auxiliary data block when the signature verification result indicates that the authentication data block is credible, and start the image file when the original image passes the verification.

[0145] An embodiment of the present application provides a vehicle controller device startup device, which obtains Android verification startup data in the image file by running a secondary startup loader when the image file is loaded into the double data rate memory in the vehicle controller device by setting the corresponding functional module. In this case, a first hash value is generated based on the header data block and the auxiliary data block of the Android verification startup data, and it is verified with the second hash value stored in the authentication data block. When the first hash value and the second hash value are consistent, the target signature pre-stored in the authentication data block is verified to obtain a verification result. Finally, when the verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image verification passes.

[0146] From the above description, it can be seen that a vehicle-mounted controller device starting device according to an embodiment of the present application does not need to adopt high-cost HS equipment compared to the prior art. It adds the above-mentioned secure boot verification process to the secondary boot loader of a general device, and can use the Android verification startup data pre-stored with the target signature to perform valid data signature verification operations and original image verification. The image is allowed to be started only when the above-mentioned secure boot process verification is passed, thereby reducing the risk of vehicle controller device operation attacks and illegal access, and can achieve effective startup of the vehicle-mounted controller in the vehicle with lower cost and higher security, thereby effectively ensuring the safe and reliable operation of the overall vehicle system.

[0147] In some possible implementations, the first signature verification module 530 performs a signature verification operation on a target signature pre-stored in the authentication data block when the first verification result indicates that the first hash value and the second hash value are consistent, to obtain a signature verification result, including:

[0148] The first determination submodule may be used to determine that a third Hash value is obtained by encrypting the target signature by using the first preset public key when the first verification result indicates that the first Hash value and the second Hash value are consistent;

[0149] The first comparison submodule may be used to compare the third hash value with a fourth hash value corresponding to the target signature in the authentication data block to obtain a signature verification result;

[0150] Among them, when the third hash value and the fourth hash value are consistent, the signature verification result indicates that the authentication data block is credible.

[0151] In some possible implementations, the first determining submodule determines, when the first verification result indicates that the first hash value and the second hash value are consistent, that the third hash value is obtained by encrypting the target signature by the first preset public key, including:

[0152] A first transmission unit may be used to transmit a target signature in the authentication data block to a security chip, wherein a prefabricated first preset public key is pre-stored in the security chip;

[0153] The first receiving unit may be configured to receive a third hash value obtained by encrypting a target signature by the security chip based on a first preset public key.

[0154] In some possible implementations, the first determining submodule determines, when the first verification result indicates that the first hash value and the second hash value are consistent, that the third hash value is obtained by encrypting the target signature by the first preset public key, including:

[0155] A first extraction unit may be used to extract a pre-selected and stored first preset public key based on the auxiliary data block;

[0156] The first encryption unit can be used to encrypt the target signature using a first preset public key to obtain a third hash value.

[0157] In some possible implementations, the first startup module 540, when the signature verification result indicates that the authentication data block is credible, verifies the original image in the image file based on the auxiliary data block, and starts the image file when the original image passes the verification, including:

[0158] The first retrieval submodule may be used to retrieve a second preset public key prefabricated in the secondary boot loader when the signature verification result indicates that the authentication data block is credible;

[0159] A first check submodule may be used to compare the first preset public key with the second preset public key, and verify the original image based on the auxiliary data block when the first preset public key is consistent with the second preset public key;

[0160] The first startup submodule can be used to start the image file when the original image is verified to be passed.

[0161] In some possible implementations, the first acquisition module 510, when the image file is loaded into the double data rate memory in the vehicle controller device, acquires the Android verification startup data in the image file by running the secondary boot loader, including:

[0162] A first acquisition submodule may be used to acquire data size and offset information of Android verification startup data from a tail data block in the image file by running a secondary boot loader when the image file is loaded into the double data rate memory;

[0163] The second acquisition submodule can be used to extract the Android verification startup data from the image file based on the data size and offset information of the Android verification startup data.

[0164] In some possible implementations, the first startup module 540, when the signature verification result indicates that the authentication data block is credible, verifies the original image in the image file based on the auxiliary data block, and starts the image file when the original image passes the verification, including:

[0165] The first extraction submodule may be used to extract the salt value data stored in the auxiliary data block when the signature verification result indicates that the authentication data block is credible;

[0166] The first calculation submodule may be used to calculate a fifth hash value corresponding to the original image based on the salt value data and the original image;

[0167] The second startup submodule can be used to compare the fifth Hash value with the preset Hash summary data in the auxiliary data block, and start the image file when the fifth Hash value is consistent with the preset Hash summary data.

[0168] In some possible implementations, before obtaining the Android verification startup data in the image file by running the secondary startup loader, the vehicle controller device startup device further includes:

[0169] The second acquisition module may be used to acquire the system partition information of the vehicle-mounted controller device when the secondary boot loader in the vehicle-mounted controller device is started;

[0170] The first loading module can be used to determine the target image partition to be loaded from N image partitions based on the system partition information, and load the image file in the target image partition into the double data rate memory, where N is a positive integer greater than or equal to 2.

[0171] In some possible implementations, when the image file is loaded into the double data rate memory in the vehicle controller device, before obtaining the Android verification startup data in the image file by running the secondary boot loader, the vehicle controller device startup device further includes:

[0172] The third acquisition module can be used to obtain the image file signed by the signature server.

[0173] Based on the vehicle controller device startup method provided in the above embodiment, out of the same inventive concept, the present application also provides a vehicle controller device startup device corresponding to the vehicle controller device startup method. Figure 6 A detailed introduction to the vehicle controller device startup device.

[0174] See below Figure 6 , Figure 6 It is a structural diagram of a vehicle controller device starting device provided in one embodiment of the present application.

[0175] The vehicle controller device startup device may include a processor 601 and a memory 602 storing computer program instructions.

[0176] Specifically, the processor 601 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0177] The memory 602 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 602 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 602 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 602 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 602 is a non-volatile solid-state memory.

[0178] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, typically, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to an aspect of the present disclosure.

[0179] The processor 601 implements any one of the vehicle controller device startup methods in the above embodiments by reading and executing computer program instructions stored in the memory 602 .

[0180] In one example, the data vehicle controller device startup device may also include a communication interface 603 and a bus 610. Figure 6 As shown, the processor 601, the memory 602, and the communication interface 603 are connected via a bus 610 and communicate with each other.

[0181] The communication interface 603 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0182] Bus 610 includes hardware, software or both, and the parts of the vehicle-mounted controller device startup device are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-side bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 610 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the application considers any suitable bus or interconnection.

[0183] The vehicle-mounted controller device startup device executes the vehicle-mounted controller device startup method in the embodiment of the present application, thereby realizing the vehicle-mounted controller device startup method described in the embodiment of the present application.

[0184] In addition, in combination with the vehicle controller device startup method in the above embodiment, the embodiment of the present application can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when the computer program instructions are executed by the processor, any vehicle controller device startup method in the above embodiment is implemented.

[0185] Based on the vehicle controller device startup method in the above-mentioned embodiments, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the vehicle controller device startup method provided in any one of the above-mentioned embodiments of the present application.

[0186] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0187] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0188] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0189] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0190] The above is only a specific implementation of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A method for starting a vehicle controller device, characterized in that: The method comprises: When the image file is loaded into the dynamic random access memory in the vehicle controller device, the Android verification startup data in the image file is obtained by running the secondary boot loader, wherein the Android verification startup data includes a header data block, an auxiliary data block and an authentication data block; Generate a first Hash value based on the header data block and the auxiliary data block, and verify the first Hash value with the second Hash value stored in the authentication data block to obtain a first verification result; When the first verification result indicates that the first hash value and the second hash value are consistent, performing a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result; When the signature verification result indicates that the authentication data block is credible, the original image in the image file is verified based on the auxiliary data block, and the image file is started when the original image passes the verification.

2. The method according to claim 1, characterized in that When the first verification result indicates that the first hash value and the second hash value are consistent, performing a signature verification operation on the target signature pre-stored in the authentication data block to obtain a signature verification result includes: When the first verification result indicates that the first Hash value is consistent with the second Hash value, determine to encrypt the target signature by using a first preset public key to obtain a third Hash value; Compare the third hash value with a fourth hash value in the authentication data block corresponding to the target signature to obtain the signature verification result; Wherein, when the third hash value and the fourth hash value are consistent, the signature verification result indicates that the authentication data block is credible.

3. The method according to claim 2, characterized in that The step of determining, when the first verification result indicates that the first Hash value is consistent with the second Hash value, encrypting the target signature by using a first preset public key to obtain a third Hash value includes: Transmitting the target signature in the authentication data block to a security chip, wherein the security chip pre-stores the pre-made first preset public key; The third hash value is received by encrypting the target signature by the security chip based on the first preset public key.

4. The method according to claim 2, characterized in that: The step of determining, when the first verification result indicates that the first Hash value is consistent with the second Hash value, encrypting the target signature by using a first preset public key to obtain a third Hash value includes: Based on the auxiliary data block, extracting the first preset public key that is pre-selected and stored; The target signature is encrypted using the first preset public key to obtain the third hash value.

5. The method according to claim 4, characterized in that When the signature verification result indicates that the authentication data block is credible, verifying the original image in the image file based on the auxiliary data block, and starting the image file when the original image passes the verification, includes: If the signature verification result indicates that the authentication data block is credible, retrieving a second preset public key prefabricated in the secondary boot loader; comparing the first preset public key with the second preset public key, and verifying the original image based on the auxiliary data block when the first preset public key is consistent with the second preset public key; When the original image file passes the verification, the image file is started.

6. The method according to claim 1, characterized in that When the image file is loaded into the dynamic random access memory in the vehicle-mounted controller device, obtaining the Android verification startup data in the image file by running the secondary startup loader includes: When the image file is loaded into the dynamic random access memory, obtaining data size and offset information of the Android verification startup data from a tail data block in the image file by running the secondary boot loader; The Android verification startup data is extracted from the image file based on the data size and offset information of the Android verification startup data.

7. The method according to claim 1, characterized in that When the signature verification result indicates that the authentication data block is credible, verifying the original image in the image file based on the auxiliary data block, and starting the image file when the original image passes the verification, includes: If the signature verification result indicates that the authentication data block is credible, extracting the salt value data stored in the auxiliary data block; Based on the salt value data and the original image, a fifth hash value corresponding to the original image is calculated; The fifth Hash value is compared with the preset Hash summary data in the auxiliary data block, and the image file is started if the fifth Hash value is consistent with the preset Hash summary data.

8. The method according to claim 1, characterized in that Before obtaining the Android verification startup data in the image file by running the secondary startup loader, the method further includes: When the secondary bootloader in the vehicle-mounted controller device is started, obtaining system partition information of the vehicle-mounted controller device; Based on the system partition information, a target image partition to be loaded is determined from N image partitions, and the image file in the target image partition is loaded into the dynamic random access memory, where N is a positive integer greater than or equal to 2.

9. The method according to claim 1, characterized in that: In the case where the image file is loaded into the dynamic random access memory in the vehicle-mounted controller device, before obtaining the Android verification startup data in the image file by running the secondary boot loader, the method further includes: Obtain the image file signed by the signature server.

10. A vehicle-mounted controller device starting device, characterized in that: The device comprises: A first acquisition module is used to acquire Android verification startup data in the image file by running a secondary boot loader when the image file is loaded into a dynamic random access memory in the vehicle-mounted controller device, wherein the Android verification startup data includes a header data block, an auxiliary data block, and an authentication data block; A first verification module, configured to generate a first Hash value based on the header data block and the auxiliary data block, and verify the first Hash value with a second Hash value stored in the authentication data block to obtain a first verification result; A first signature verification module, configured to perform a signature verification operation on a target signature pre-stored in the authentication data block to obtain a signature verification result when the first verification result indicates that the first hash value and the second hash value are consistent; The first startup module is used to verify the original image in the image file based on the auxiliary data block when the signature verification result indicates that the authentication data block is credible, and to start the image file when the original image passes the verification.

Images