CN118013509A

CN118013509A - Secure start method, secure start device, vehicle and storage medium

Info

Publication number: CN118013509A
Application number: CN202311803884.XA
Authority: CN
Inventors: 彭建成; 关文华
Original assignee: Guangzhou Automobile Group Co Ltd
Current assignee: Guangzhou Automobile Group Co Ltd
Priority date: 2023-12-26
Filing date: 2023-12-26
Publication date: 2024-05-10

Abstract

The embodiment of the application provides a safe starting method, a safe starting device, a vehicle and a storage medium, and relates to the technical field of information safety. Dividing the code of the application program into a plurality of data blocks in response to starting the secure start function, wherein each data block corresponds to a check value; checking the codes of the application program according to the check values of the data blocks; according to the verification result, whether the application program is started or not is determined, so that the verification values of a plurality of data blocks are adopted to replace all code plaintext of the application program in the related technology to verify the code of the application program, the problem of large calculation amount caused by the fact that all code plaintext with huge data amount is adopted to verify can be avoided under the condition that the code verification accuracy is not affected, the calculation amount in safe starting is reduced, the speed of safe starting is greatly improved, the delayed starting of the application program perceived by a user can be effectively avoided, and the user experience is improved.

Description

Secure start method, secure start device, vehicle and storage medium

Technical Field

The embodiment of the application relates to the technical field of information security, in particular to a safe starting method, a safe starting device, a vehicle and a storage medium.

Background

Along with the rapid development of intelligent network-connected automobiles, information security technology becomes increasingly important, the information security of the current automobile domain controllers belongs to a starting stage, the technology is not completely mature in the implementation stage of laws and regulations, and the safe starting is an important ring of information security and also becomes the key point of the research and development of the domain controllers of various manufacturers.

The safe starting is to verify the mirror image when the automobile chip is started to ensure that software on the automobile chip is legal and not tampered when the automobile chip is started, and is a mode for ensuring information safety in a starting stage, and the chip safe starting technology is used for preventing codes on the chip from being illegally modified and avoiding the condition of abnormal functions of a controller caused by abnormal starting of the chip. For example, secure boot techniques may be used to securely, effectively, and completely verify the code of an application to be booted in a domain controller at the time of boot of the domain controller, thereby avoiding running illegal (e.g., modified, or partially missing) code.

The secure boot method in the related art is to directly verify all codes of the application program themselves. However, the inventors found in the study that: with the development of intelligent internet-of-things automobiles and internet of things, the number of code plaintext of a software program on an automobile chip is larger and larger, and the calculation amount for verifying all the code plaintext is larger and larger, so that the safety starting efficiency is low, and even the starting delay of the software program perceived by a user can be caused, and the user experience is influenced.

Therefore, how to improve the safe starting efficiency is a current urgent problem to be solved.

Disclosure of Invention

The embodiment of the application provides a safe starting method, a safe starting device, a vehicle and a storage medium, which are used for solving the problems.

In a first aspect, an embodiment of the present application provides a method for secure startup, where the method includes: responding to an application program starting request, dividing the code of the application program into a plurality of data blocks, wherein each data block corresponds to a check value; checking the codes of the application program according to the check values of the data blocks; and determining whether to start the application program according to the verification result.

In a second aspect, an embodiment of the present application provides a safety start device, including: the code segmentation module is used for responding to an application program starting request, dividing the code of the application program into a plurality of data blocks, wherein each data block corresponds to a check value; the code verification module is used for verifying the codes of the application programs according to the verification values of the data blocks; and the program starting module is used for determining whether to start the application program according to the verification result.

In a third aspect, embodiments of the present application provide a vehicle comprising a memory and one or more processors, wherein the memory stores one or more applications for performing the method as described above when invoked by the one or more processors.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium having stored therein program code for performing a method as described above when invoked by a processor.

In the method, the device, the vehicle and the storage medium for safe starting provided by the embodiment of the application, the codes of the application program are divided into a plurality of data blocks in safe starting, and the codes of the application program are verified according to the verification values of the plurality of data blocks, so that the verification values of the plurality of data blocks are adopted to replace all code plaintext of the application program in the related art to verify the codes of the application program, the problem of large calculated amount caused by the verification of all code plaintext with huge data amount can be avoided under the condition that the code verification accuracy is not influenced, the calculated amount in safe starting is reduced, the speed of safe starting is greatly improved, the delayed starting of the application program perceived by a user can be effectively avoided, and the user experience is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG.1 is a flow chart illustrating a method for secure boot according to an embodiment of the present application;

FIG. 2 is a flow chart of a method for secure boot according to another embodiment of the present application;

FIG. 3 is a flow chart of a method for secure boot according to another embodiment of the present application;

fig. 4 is a schematic structural diagram of a safety starting device according to an embodiment of the present application;

Fig. 5 shows a schematic structural diagram of a vehicle according to an embodiment of the present application.

Detailed Description

In order to enable those skilled in the art to better understand the present application, a clear and complete description of the technical solution in the present embodiment will be provided below with reference to the accompanying drawings in the present embodiment. It will be apparent that the described embodiments are only some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The related concepts involved in secure boot are briefly described here:

The safe starting is to ensure that the authenticated codes are operated according to a fixed sequence through a technology, so that the modules are prevented from being bypassed and illegal codes are prevented from being operated. By the secure boot technique, the ECU boot can be directly restricted upon identifying an attacker tampering with the code of any electronic control unit (Electronic Control Unit, ECU) or re-brushing in an illegal code.

Verification is a check process in secure launch to check if the code of the application to be run is the official release code. In order to realize the verification process, a cryptographic algorithm is introduced, and when the officer issues the software package, a specific value of the current software package is calculated through the algorithm, and the specific value and the software package are written into an ECU FLASH memory (FLASH) together. And when the method is started, the characteristic value of the software package is calculated in real time and is compared with the characteristic value written into FLASH. If the two are consistent, the software package is legal, otherwise, the software package is not legal and is started safely.

Root of trust: the verification process needs to be realized through codes, and if an attacker can modify the codes in the verification process, the verification process can still be bypassed or the verification result can be tampered. Therefore, a code which cannot be modified by an attacker is needed to verify the verification code, so that the verification code cannot be modified. This code that an attacker cannot modify at all can be understood as a trust root, which is a piece of code that is consistently thought to be unable to be tampered with, typically implemented in hardware, e.g. bootROM, bootROM of a chip is a piece of code that is cured within the chip, which, once manufactured, is used for the bootROM to be unable to be altered.

Trust chain: the software of one ECU is basically divided into a plurality of parts, for example, a boot loader (bootloader), an Application (App), and the like. And the trust root is used as a starting point, and the first-stage verification is continuously realized, so that a trust chain is formed, and the validity of the verification of each module is ensured. For example bootROM validates bootloader, bootloader validates app.

The boot loader is also called a boot loader, and is the first piece of program code that runs after the ECU is powered on or reset, and the main function is to bring the software and hardware environment of the ECU system to a proper state, so as to prepare for finally calling the application program and entering the software. Specifically, the boot program is an intermediate interface between the underlying hardware and the upper application software, and in the vehicle ECU, the boot program is a separate program that starts to execute at power-up. It will download the application software to the ECU over the diagnostic communication link.

The trust root firmware is firmware used for guiding and verifying the bootstrap program, the memory area where the trust root firmware is located is unreadable and unwritable after being written once from factory, and the parameter configuration of the trust root firmware about the safe start in the chip operation process can only be realized through a specific safe start configuration engineering, and the trust root firmware is used as the trust root of the safe start and has very high safety. For example, the trust root firmware may be installed in a Read-Only Memory (BootROM) in the encryption chip. BootROM is a small block of mask Read-Only Memory (ROM) or write-protected flash Memory embedded in the cryptographic chip, containing the first code (i.e., code that trusts the root firmware) that the cryptographic chip executes upon power-up or reset. Among these, the encryption chip, also called encryption co-processor and security chip, is a special purpose chip that is specific for data and identity security, the encryption chip being capable of securely holding one or more keys and using these keys in data encryption. And allows the user to securely conduct end-to-end encryption.

It should be noted that, in the embodiment of the present application, the encryption chip is used to implement the secure start method, that is, the entire secure start method runs on the encryption chip, so that the secure start speed is accelerated by using the characteristic that the hardware runs faster than the software, the secure start time is reduced, the start delay and the jam are avoided from being perceived by the user, and the user experience is further improved.

It should also be noted that after the code of the application is verified, the application runs on the protected ECU instead of the encryption chip.

That is, in the embodiment of the present application, by deploying the secure boot method and the application program (App) on different cores respectively for running, compared with the related art that adopts a soft verification manner (i.e., the secure boot and the application program run on the same ECU), the time for verifying the codes of multiple firmware (e.g., bootROM, bootloader, app) step by step according to the trust chain can be greatly shortened, so that the whole secure boot time is faster, the user is prevented from perceiving the boot delay and the jam, and further the user experience is improved.

Referring to fig. 1, fig. 1 is a flow chart illustrating a secure boot method according to an embodiment of the application. The safe starting method can be applied to a safe starting device or a vehicle. The secure boot method may specifically include the following steps S110 to S130.

Step S110: in response to initiating the secure launch function, the code of the application is divided into a plurality of data blocks, each data block corresponding to a check value.

The secure launch function refers to a function of launching an application program in a manner of stepwise verifying a trust chain by adopting a secure launch technique. In some embodiments, if the domain controller is powered up or reset to restart, it may be determined that the secure launch function is launched.

The application program refers to an application program to be started by default set in the initial stage of starting, and can be understood as an application program started by starting. The application program can be preset according to actual requirements and can be one or more.

In some implementations, after the secure launch function is initiated, the code of the application may be divided into a plurality of code blocks; determining check values of a plurality of code blocks, wherein each code block corresponds to one check value; a plurality of data blocks, each including a code block and a check value for the code block, are determined based on the check values for the plurality of code blocks and the plurality of code blocks.

The code of the application program refers to all source codes of the application program, and the source codes at least comprise executable codes. All codes of an application may be partitioned according to an application program (App) code structure protocol. The application code structure protocol may be predefined by the developer, and as an example, the application code structure protocol may define the number of bytes required for each data block, each code block, and each check value, the number of bytes per data block = the number of bytes per code block + the number of bytes per check value. For example, the number of bytes corresponding to each data block may be defined as 4100 bytes, the number of bytes corresponding to each code block may be 4096 bytes, the number of bytes corresponding to each check value may be 4 bytes, and assuming that the code size of the application program is 1 megabyte (i.e., 1048576 bytes), the code of the application program is divided in such a manner that each code block occupies 4100 bytes, and 256 code blocks may be obtained.

The type of the check value corresponding to each code block may be determined according to actual requirements, and for example, the check value corresponding to each code block may be a cyclic redundancy check (Cyclic Redundancy Check, CRC) value. After dividing the code blocks, a 32-bit cyclic redundancy check (Cyclic Redundancy Check-32, CRC-32) algorithm may be used to calculate the CRC check value for each code block separately, resulting in a CRC check value for each code block. After the check value is obtained, the code blocks with the corresponding relation and the check value can be packed to obtain the data block.

Step S120: and checking the codes of the application program according to the check values of the plurality of data blocks.

Hash values of check values of a plurality of data blocks may be calculated; signing the hash value to obtain a signature value; and checking the code of the application program according to the signature value.

In the embodiment of the application, the check values of the plurality of data blocks can be all extracted to obtain a plurality of check values. The plurality of check values are placed in a global buffer (buffer) in a random access memory (Random Access Memory, RAM). The plurality of check values placed in the global buffer are combined into one global buffer value.

Since the check value of each code block is calculated from the code text of that code block, the check values corresponding to different code blocks are different, and if two data blocks have the same check value, they are likely to have the same code block. Therefore, the check value can be regarded as the code original of the corresponding code block, and likewise, the global buffer value obtained by combining a plurality of check values can also be regarded as the code original of the complete application program. Therefore, the global buffer value can be regarded as signing the code original text, so that compared with the direct signing of the code original text, the method reduces the operand and improves the signing efficiency.

After the global buffer value is obtained, a hash value of the global buffer value may be calculated using a hash algorithm as a hash value of check values of a plurality of data blocks. The hash algorithm may be secure hash algorithm-2 (Secure Hash Algorithm-2, SHA-2). SHA-2 may include, but is not limited to, SHA256 algorithm, SHA224 algorithm, SHA384 algorithm, and the like, among others. In the embodiment of the application, the hash value of the global buffer value can be calculated by adopting the SHA256 algorithm, and a hash value with a fixed length of 256 bits (32 bytes) can be obtained.

After obtaining the hash value of the check values of the plurality of data blocks, the hash value may be signed using an encryption algorithm. The encryption algorithm may include, but is not limited to, a symmetric encryption algorithm and an asymmetric encryption algorithm, wherein the symmetric encryption algorithm has lower computation complexity compared with the asymmetric encryption algorithm, and the asymmetric encryption algorithm has higher security compared with the symmetric encryption algorithm. By way of example, the asymmetric encryption algorithm may be an RSA-2048 algorithm. RSA-2048 is an asymmetric encryption algorithm that has a pair of keys, one public key for encrypting data and one private key for decrypting data. When signing the hash value, namely encrypting the hash value by adopting a public key, and acquiring the encrypted value as a signature value of the hash value.

In some embodiments, a pre-stored target signature value corresponding to an application may be obtained; if the signature value is the same as the target signature value, determining that the code of the application program passes the verification; if the signature value is different from the target signature value, determining that the code of the application program fails to pass the verification, and then jumping to the fault processing firmware to perform fault processing. For example, when the code of the application program fails verification, the secure boot fails, and at this time, the signature value and the target signature value may be compared, and the difference between the two signatures may be recorded in the read-only memory area, so as to facilitate the subsequent maintenance processing of the fault by related personnel. Here, a specific description of the fault handling firmware is referred to step S310.

The target signature value stored in advance refers to the accurate signature value of the application program. It will be appreciated that in the ECU of the domain controller, the application program that needs to be run first at power-up is typically an officially published program. When the application program is issued by authorities, the application program can be signed by the RSA-2048 algorithm, and the obtained signature is an accurate signature (namely, a pre-stored target signature value). The domain controller may read-only store the target signature value in a memory area of the domain controller (e.g., in a flash memory) to protect the security of the target signature value.

Step S130: and determining whether to start the application program according to the verification result.

The verification result includes that the code of the application program passes the verification, or that the code of the application program does not pass the verification.

The code of the application program is verified, so that the code of the application program is complete, safe and effective, the application program can be allowed to start, and the starting address of the application program can be jumped to at the moment so as to execute the application program in the protected ECU.

The code of the application program is not verified, which indicates that the code of the application program is possibly tampered with or is missing, so that the security of the application program is difficult to ensure, and in this case, the application program is not started.

Referring to fig. 2, fig. 2 is a flow chart illustrating a secure boot method according to another embodiment of the application. The safe starting method can be applied to a safe starting device or a vehicle. The secure boot method may specifically include the following steps S210 to S240.

Step S210: in response to initiating the secure boot function, the boot root firmware is initiated to verify the boot program.

While the bootstrap program may verify the security, integrity, and validity of the application program, the bootstrap program itself may also be tampered with by an attacker. If an attacker can modify the code of the bootstrap program, the verification process or falsification of the verification result can still be bypassed. Therefore, the embodiment of the application adopts the trust root firmware instead of the boot strap as the starting firmware, and adopts the trust root firmware to conduct boot verification on the boot strap, so that the safety of starting the application program can be further improved.

Before step S210, information configuration and programming operations are required for the root of trust firmware and the boot strap program. Specifically, the information configuration and programming of the trust root firmware and the boot strap program may include the following steps one to four.

Step one: the key slot in the trust root firmware is formatted.

After the trust root firmware installation is complete, the key slot in the trust root firmware flash may be formatted first. The key slot may be a storage area in the nonvolatile memory where data cannot be changed once written, unless reformatted or the trust root firmware is updated. By formatting the key slot, it can be ensured that no data is present in the key slot.

Step two: the public key used to verify the encryption algorithm of the boot program is written into the key slot.

The public key of the encryption algorithm used to verify the boot program (e.g., the asymmetric encryption algorithm RSA-2048 described above) may be written into the key slot to ensure absolute security of the encryption algorithm.

In some embodiments, the key slot may have identification information, and the developer knows in advance the mapping relationship between the identification information of the key slot and the key of the encryption algorithm. For example, a 16-byte key of the advanced encryption standard (Advanced Encryption Standard, AES) may be stored in a key slot with identification information 65792.

Step three: a security measurement record (Secure Measurement Record, SMR) table and a validation record (Certification Record, CR) table are configured.

Parameters needed for each verification can be written in advance by establishing a configuration table. The configuration table may include an SMR table and a CR table.

By way of example, the SMR table may be configured with the following:

1. the number of boot procedures that need to be checked (max 8);

2. the starting address (i.e., the first bit of the memory address) of each boot program that needs to be verified;

3. the size (i.e., number of bytes) of each boot program that needs to be checked;

4. Algorithms used by each boot program that needs to be checked (e.g., AES, RSA-2048, etc. described above);

5. Identification information of a key slot corresponding to an algorithm used by each boot program to be verified (e.g., 65792 described above);

6. each boot program that needs to be checked has a media access control (MEDIAACCESS CONTROL, MAC) address, or a signed memory address (i.e., memory address).

By way of example, the CR table may be configured with the following:

1. Numbering of the boot program to be started;

2. An enable flag for each boot program that needs to be verified;

3. after the verification is passed, the starting address of the bootstrap program;

4. check for failed sanctions (i.e., subsequent processing).

In some embodiments, the signature of the boot program may be calculated from the information recorded in the SMR table in advance, and the calculated signature may be stored in the memory address of the sixth item in the SMR table in advance.

Step four: the boot program is re-programmed.

After the above configuration is all completed, a specific flag bit in the boot program start address (i.e., the second entry in the CR table described above) may be modified to enable the secure launch function. By way of example, the secure BOOT function is enabled by modifying the boot_seq flag bit of the BootLoader BOOT address to 1. After the modification is completed, the power control module of the domain controller can be used for carrying out power-down restarting on the encryption chip or carrying out reset operation on the domain controller so as to enable the modification to be effective.

After completing steps one to four, each time the ECU is powered on or reset to start (i.e., when the secure start function is started), the BOOT firmware will first perform verification on the BOOT program that needs to be verified and is recorded in the SMR table when the specific flag bit (e.g., boot_seq flag bit) is detected to be 1 by the trusted root firmware, and the BOOT program is allowed to run after the BOOT program verification is passed.

For example, when the trust root firmware reads that the boot_seq flag bit is 1, the trust root firmware may search the SMR table, obtain an encryption algorithm (e.g., RSA-2048 algorithm) in the SMR table, and sign a BOOT program that needs to be checked in the SMR table by using the encryption algorithm. After the signature is obtained, the signature obtained this time is compared with the signature of the corresponding boot strap recorded in the address of the sixth item in the SMR table, and when the signature and the signature are identical, it can be determined that the boot strap passes the verification. If the two signatures are different, it can be determined that the boot program fails verification, and at this time, the method can jump to the fault processing firmware to perform fault processing. For example, when the bootstrap program fails to pass the verification, the two signatures corresponding to the bootstrap program can be compared at the moment, and the difference between the two signatures is recorded in the read-only memory area, so that the subsequent maintenance processing of the fault by related personnel is facilitated. Here, a specific description of the fault handling firmware is referred to step S310.

Step S220: if the bootstrap program passes the verification, the bootstrap program is started to divide the code of the application program into a plurality of data blocks.

Step S230: and checking the codes of the application program according to the check values of the plurality of data blocks.

Step S240: and determining whether to start the application program according to the verification result.

The specific descriptions of step S220 to step S240 may refer to the related descriptions of step S110 to step S130, and the embodiments of the present application are not described herein again.

The following technical effects are additionally present in step S210 to step S240 compared to step S110 to step S130: the domain controller system safety start verification process is improved, the trust root firmware is added to conduct guide verification on the guide program on the basis of the code of the original start verification application program from the guide program, the trust root firmware is used as the start firmware for safety start verification instead of the guide program, and the safety of application program start can be further improved.

Referring to fig. 3, fig. 3 is a flow chart illustrating a secure boot method according to another embodiment of the application. The secure start method may further include steps S310 to S320 in addition to the above steps S110 to S130 or steps S210 to S240.

Step S310: when a secure boot failure is determined, a jump is made to the fault handling firmware.

The secure boot failure may include a verification that the boot program fails the trust root firmware, or a verification that the code of the application program fails the boot program.

The fault handling firmware and other firmware are stored in different memory areas, for example, the fault handling firmware may be located in the last 128k memory area of a flash memory chip (e.g., cflash chip), isolated from normal firmware (e.g., trust root firmware, boot strap program, and application program), not interfering with each other, and meeting functional security requirements. After any one level of verification of the security start trust chain fails, the start address of the fault processing firmware is jumped to, and the fault processing firmware is operated. In addition, the fault processing firmware is arranged in the flash memory chip, so that the effect of hardware acceleration is achieved, and the execution efficiency can be improved.

For example, the jump of the fault handling firmware may be implemented according to a boot address of the fault handling firmware. In some embodiments, the start address of the fault handling firmware may be written in advance to the fourth entry in the CR table when the CR table is configured, so that each time a verification failure occurs, the fault handling firmware is jumped to and fault handling is performed.

For example, the configuration table corresponding to the fault handling firmware may be configured in advance as follows:

1. the starting address of the fault handling firmware (i.e., the first bit of the memory address);

2. maximum number of checks before entering the fault handling firmware;

3. Relevant parameters of the fault handling firmware.

In some embodiments, a count may be made each time a check failure occurs and a secure boot may be made again. When the number of times of continuous check failure exceeds the maximum check number, the method jumps to the fault processing firmware to perform fault processing, thereby improving the success rate of safe starting.

Step S320: and acquiring the diagnosis message through the fault processing firmware and recording the diagnosis message in the read-only area.

The fault processing firmware has the most basic FLASH memory (FLASH) driving and controller area network (ControllerArea Network, CAN) communication functions, CAN acquire the reason and the position of the last safe start failure (for example, the reason and the position of the code of the application program which do not pass verification), writes the reason of the safe start failure into a diagnosis message, informs the central domain controller of the occurrence of the safe start failure through the diagnosis message, and records the situation in a protected memory area (namely, a read-only memory area), thereby facilitating the staff to find the controller start failure in time, taking less time to accurately locate the reason of the failure, processing the failure as soon as possible, and greatly providing convenience for engineers and maintenance staff.

The read-only memory area may be an area in an eeprom, which is not limited herein. The diagnosis message is stored in the read-only area, so that the problem that a developer is difficult to locate the fault cause caused by the fact that an attacker modifies the diagnosis message can be prevented.

After the central domain controller receives the diagnosis message, a prompt message can be sent to a user or a cloud through the central control display screen so as to inform the user of the 'failure of the current start', and remind the user of timely maintenance. When the staff is in the follow-up maintenance, the position and the reason of the safe start failure can be accurately positioned according to the diagnosis message in the read-only area, so that the staff spends less time processing the failure, and the maintenance work of the staff is facilitated.

According to the safe starting method provided by the embodiment of the application, when the safe starting failure is determined, the safe starting is skipped to the fault processing firmware, the diagnosis message is obtained through the fault processing firmware and recorded in the read-only storage area, so that a worker can accurately position the position and the reason of the safe starting failure according to the diagnosis message in the read-only storage area when carrying out subsequent maintenance, the worker spends less time processing the fault, and convenience is brought to the maintenance work of the worker.

Referring to fig. 4, fig. 4 is a schematic structural diagram of a safety starting device according to an embodiment of the application. The safety starter device 100 may be applied to a vehicle. The secure launch apparatus 100 comprises a code segmentation module 110 for dividing the code of the application into a plurality of data blocks, each corresponding to a check value, in response to launching the secure launch function; a code verification module 120, configured to verify the code of the application program according to the verification values of the plurality of data blocks; and the program starting module 130 is used for determining whether to start the application program according to the verification result.

In some embodiments, the code verification module 120 is further configured to calculate a hash value of the verification values of the plurality of data blocks; signing the hash value to obtain a signature value; and checking the code of the application program according to the signature value.

In some embodiments, the code verification module 120 is further configured to obtain a pre-stored target signature value corresponding to the application program; if the signature value is the same as the target signature value, determining that the code of the application program passes verification; and if the signature value is different from the target signature value, determining that the code of the application program does not pass the verification.

In some embodiments, the code segmentation module 110 is further configured to divide the code of the application program into a plurality of code blocks; determining check values of the plurality of code blocks, wherein each code block corresponds to one check value; and determining a plurality of data blocks according to the check values of the plurality of code blocks and the plurality of code blocks, wherein each data block comprises one code block and the check value of the code block.

In some embodiments, the program starting module 130 is further configured to start the application program if the code characterizing the application program by the verification result passes the verification; and if the verification result indicates that the code of the application program does not pass the verification, jumping to the fault processing firmware to perform fault processing.

In some implementations, the code segmentation module 110 is further configured to initiate a root of trust firmware to verify the boot strap program in response to initiating the secure launch function; and if the bootstrap program passes the verification, starting the bootstrap program to divide the code of the application program into a plurality of data blocks.

In some embodiments, the safety-starting device 100 further comprises a fault handling module. And the fault processing module is used for jumping to the fault processing firmware to perform fault processing if the bootstrap program fails to pass the verification.

It can be clearly understood by those skilled in the art that the secure start apparatus 100 provided in the embodiment of the present application can implement the secure start method provided in the embodiment of the present application. The specific working process of the above node may refer to a process corresponding to the secure start method in the embodiment of the present application, which is not described herein.

In the embodiments of the present application, the modules shown or discussed are coupled or directly coupled or communicatively coupled to each other via some interfaces, devices or modules, which may be electrical, mechanical or otherwise.

In addition, each functional module in the embodiment of the present application may be integrated in one processing module, or each module may exist alone physically, or two or more modules may be integrated in one module. The integrated modules may be implemented in hardware or in software as functional modules, which are not limited in this embodiment of the present application.

Referring to fig. 5, fig. 5 shows a schematic structural diagram of a vehicle according to an embodiment of the application. The vehicle 200 comprises a memory 210 and one or more processors 220, wherein the memory 210 has stored therein one or more application programs for performing the methods of the method embodiments described above when invoked by the one or more processors 220.

Wherein the processor 220 may include one or more processing cores. The processor 220 utilizes various interfaces and lines to connect various portions of the overall vehicle 200, perform various functions of the vehicle and process data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 210, and invoking data stored in the memory 210. The processor 220 may be implemented in at least one hardware form of digital signal Processing (DIGITAL SIGNAL Processing, DSP), field Programmable gate array (FieldProgrammable GATEARRAY, FPGA), programmable Logic Array (PLA). The processor 220 may integrate one or a combination of several of a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU), and a modem, etc. It will be appreciated that the modem may not be integrated into the processor 220 and may be implemented solely by a single communication chip.

The Memory 210 may include a random access Memory (RandomAccess Memory, RAM) or a Read Only Memory (ROM). Memory 210 may be used to store instructions, programs, code sets, or instruction sets. The memory 210 may include a stored program area and a stored data area. The storage program area may store instructions for implementing an operating system, instructions for implementing at least one function, instructions for implementing the various method embodiments described above, and the like. The storage data area may store data created by the vehicle 200 in use, etc.

Embodiments of the present application also provide a computer readable storage medium having program code stored therein for performing a method as described in the method embodiments above when called by a processor.

The computer readable storage medium may be an electronic Memory such as flash Memory, electrically erasable programmable Read-Only Memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ ONLY MEMORY, EEPROM), electrically programmable Read-Only Memory (ELECTRICAL PROGRAMMABLE READ ONLY MEMORY, EPROM), hard disk, or Read Only Memory (ROM). In some embodiments, the computer readable storage medium may comprise a non-volatile computer readable medium (non-transitorycomputer-readable storage medium, NTRSM). The computer readable storage medium has storage space for program code to perform any of the method steps described above. The program code can be read from or written to one or more computer program products. The program code may be compressed in a suitable form.

Although the present application has been described in terms of the preferred embodiments, it should be understood that the present application is not limited to the specific embodiments, but is capable of numerous modifications and equivalents, and alternative embodiments and modifications of the embodiments described above, without departing from the spirit and scope of the present application.

Claims

1. A method of secure initiation comprising:

In response to initiating a secure launch function, dividing a code of the application into a plurality of data blocks, each data block corresponding to a check value;

checking the codes of the application program according to the check values of the data blocks;

And determining whether to start the application program according to the verification result.

2. The method of claim 1, wherein verifying the code of the application based on the verification values of the plurality of data blocks comprises:

calculating hash values of the check values of the plurality of data blocks;

Signing the hash value to obtain a signature value;

and checking the code of the application program according to the signature value.

3. The method of claim 2, wherein verifying the code of the application based on the signature value comprises:

acquiring a pre-stored target signature value corresponding to the application program;

if the signature value is the same as the target signature value, determining that the code of the application program passes verification;

And if the signature value is different from the target signature value, determining that the code of the application program does not pass the verification.

4. The method of claim 1, wherein the dividing the code of the application into a plurality of data blocks comprises:

Dividing the code of the application program into a plurality of code blocks;

determining check values of the plurality of code blocks, wherein each code block corresponds to one check value;

and determining a plurality of data blocks according to the check values of the plurality of code blocks and the plurality of code blocks, wherein each data block comprises one code block and the check value of the code block.

5. The method according to any one of claims 1 to 4, wherein determining whether to launch the application according to the verification result comprises:

if the verification result represents the code of the application program to pass verification, starting the application program;

And if the verification result indicates that the code of the application program does not pass the verification, jumping to the fault processing firmware to perform fault processing.

6. The method of claim 1, wherein the dividing the code of the application into a plurality of data blocks in response to initiating the secure launch function comprises:

in response to initiating the secure boot function, initiating a root of trust firmware to verify the boot program;

and if the bootstrap program passes the verification, starting the bootstrap program to divide the code of the application program into a plurality of data blocks.

7. The method of claim 6, wherein the method further comprises:

If the bootstrap program fails to pass the verification, jumping to the fault processing firmware to process the fault.

8. A safety-activated device, the device comprising:

the code segmentation module is used for responding to the starting of the safety starting function and dividing the codes of the application program into a plurality of data blocks, wherein each data block corresponds to one check value;

The code verification module is used for verifying the codes of the application programs according to the verification values of the data blocks;

and the program starting module is used for determining whether to start the application program according to the verification result.

9. A vehicle comprising a memory and one or more processors, wherein the memory stores one or more applications for performing the method of any of claims 1-7 when invoked by the one or more processors.

10. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a program code for performing the method according to any of claims 1-7 when called by a processor.