Safe starting time optimization method and device, terminal and storage medium

Abstract

The invention discloses a safe starting time optimization method and device, a terminal and a storage medium, and the method comprises the steps that when a program execution signal is received, system firmware of a vehicle-mounted system is subjected to block processing, and a block processing result comprises a default check block and a random sampling check block; obtaining measured check-free starting time and total check time, and calculating the configuration number of the random spot check blocks according to a preset safety starting time upper limit; extracting the random extraction blocks corresponding to the configuration number in combination with a preset dynamic probability algorithm, and summarizing to obtain a to-be-detected block set; and performing hierarchical verification on the to-be-detected block set to obtain a verification result, and when the verification result is failure, performing atomic rollback according to the classification of the to-be-detected blocks. According to the method, on the premise that the firmware safety is guaranteed, the safety starting time can be effectively shortened, and the efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of system security boot optimization, and in particular to a security boot time optimization method, device, terminal and storage medium. Background Art

[0002] With the rapid development of intelligent connected vehicles, the security of in-vehicle software upgrade systems is becoming increasingly important. ISO 44495, published by the International Organization for Standardization, sets clear requirements for in-vehicle software upgrade systems, necessitating the establishment of a secure and reliable in-vehicle software operating environment. During device startup, firmware integrity and security checks are crucial for preventing malicious tampering, virus intrusion, and data leakage.

[0003] In the past, a full verification method was commonly used for secure startup of in-vehicle software. This method requires the individual verification of massive amounts of data when checking for system firmware tampering. Furthermore, existing secure startup technology solutions for in-vehicle software often employ an architecture in which the HOST (main core) and a trusted execution component work together. During system startup, the HOST, as the primary request initiator, sends a request for an integrity check of the software firmware to the trusted execution component. Upon receiving the request, the trusted execution component performs a comprehensive test of the software firmware and feeds back the test results to the main core. The main core then performs the corresponding actions based on the feedback. If it detects that the firmware has not been tampered with, it allows the system to operate normally. If any signs of tampering are found, the system is immediately stopped, thereby achieving security protection for the in-vehicle software.

[0004] Traditional full verification methods have significant flaws. Due to the vast volume of software and firmware, full verification requires verifying massive amounts of data one by one, resulting in a lengthy inspection process. While current technology can meet firmware security protection requirements, it cannot meet the full vehicle startup time requirements. This significantly reduces vehicle startup efficiency and makes it difficult to adapt to the fast response and efficient operation requirements of smart cars.

[0005] Therefore, how to effectively shorten the device startup time while ensuring firmware security has become a technical problem that needs to be solved urgently in the current field. Summary of the Invention

[0006] In order to overcome the above technical problems, the present application provides a secure boot time optimization method, device, terminal and storage medium.

[0007] In the first aspect, the present application provides a method for optimizing secure boot time, which uses the following technical means: A method for optimizing safe boot time, based on an in-vehicle system, includes the following steps: When a program execution signal is received, the system firmware of the vehicle system is processed in blocks, wherein the results of the block processing include a default check block and a random check block; Obtain the measured unchecked startup time and full check time, and calculate the configuration quantity of the random inspection block according to the preset upper limit of the safe startup time; extracting the randomly extracted blocks corresponding to the configured number in combination with a preset dynamic probability algorithm, and summarizing them to obtain a set of blocks to be checked; A hierarchical check is performed on the set of blocks to be checked and a check result is obtained. When the check result is a failure, an atomic rollback is performed according to the classification of the blocks to be checked.

[0008] By adopting the above technical solution, the system firmware blocks can be checked in a targeted manner, reducing unnecessary full verification; the number of random inspection blocks configured is calculated based on the non-verification startup time, the full verification time and the preset safety startup time upper limit, which can control the verification time under the premise of ensuring safety; the dynamic probability algorithm is used to extract random inspection blocks to summarize the set of blocks to be inspected, making the inspection more scientific and reasonable, realizing the key inspection of the key parts of the firmware and flexible inspection of the non-critical parts, greatly shortening the startup time, and at the same time ensuring the balance between the safety and efficiency of the startup and operation of the vehicle system.

[0009] Preferably, the block processing of the system firmware of the vehicle-mounted system, wherein the block processing results include mandatory inspection blocks and random inspection blocks, specifically includes the following steps: Dividing the system firmware into multiple code blocks according to functions, and dividing the multiple code blocks into multiple default check blocks and multiple random check blocks based on the introduced ISO 26262 functional safety standard and a predefined safety level assessment model; The security level assessment model is: S score =0.5S v +0.3E x +0.2C trl ； Among them, S score S is the security level score, v Severity score, E x Score the exposure rate, C trl Score controllability; A security level score of each code block is obtained according to the security level assessment model. When the security level score is not less than a preset mandatory inspection threshold, the current code block is a default inspection block, otherwise it is a randomly selected inspection block.

[0010] By adopting this technical solution, the system firmware is divided into multiple code blocks according to function. The ISO 26262 functional safety standard, combined with a safety level assessment model, divides the code blocks into default check blocks and random check blocks. Targeted checks are performed based on the type of code blocks, implementing a differentiated security strategy of "mandatory inspection of critical modules and random inspection of non-critical modules." This avoids the time-consuming problem of traditional full verification methods that require the individual verification of massive amounts of data, effectively improving system firmware inspection efficiency and significantly shortening boot time while ensuring firmware security.

[0011] Preferably, the step of obtaining the measured non-verification startup time and full verification time, and calculating the number of configurations of the random inspection blocks according to a preset upper limit of the safe startup time, specifically comprises the following steps: Get the unverified boot time obtained in a clean boot state with Secure Boot disabled, and the full verification time obtained in a full verification state with Secure Boot enabled but without block processing. Obtain historical statistical data and calculate the total mandatory check time for all the default check blocks; Calculate the total random check block check time based on the no-check startup time, the total mandatory check time, and a preset upper limit of the safe startup time; Calculate the single block verification time of each randomly selected block based on the full verification time and the total number of firmware blocks; The configuration quantity of the random sampling blocks is calculated according to the total sampling verification time and the single block verification time.

[0012] By adopting the above technical solution, the number of blocks that need to be sampled at each startup is dynamically calculated according to the system startup time requirements, avoiding the long startup time caused by full verification. While ensuring firmware security, the system startup time is shortened and the vehicle startup efficiency is improved.

[0013] Preferably, extracting the randomly selected blocks corresponding to the configured number by combining a preset dynamic probability algorithm and aggregating them to obtain a set of blocks to be checked specifically includes the following steps: All the randomly selected blocks are aggregated to form a random sampling block set, a selected block list is established and initialized to be empty, the number of remaining blocks to be selected is the configured number, the number of remaining unprocessed blocks is the total number of the randomly sampled blocks, and each of the randomly sampled blocks in the random sampling block set is sequentially selected and judged, specifically, Calculating the random sampling probability of the current random sampling block being selected based on the remaining number of blocks to be selected and the remaining number of unprocessed blocks, generating a random number using a hardware true random number generator, and comparing the random number with the random sampling probability; if the random number is less than the random sampling probability, marking the current random sampling block as a block to be inspected, and then performing a subtraction operation on the parameter of the remaining number of blocks to be selected; if the random number is not less than the random sampling probability, marking the random sampling block as an inspection-exempt block; Subtract one from the parameter of the number of remaining unprocessed blocks, and update and record the parameter states of the remaining number to be selected and the number of remaining unprocessed blocks; Before performing the selection and judgment processing on each of the randomly sampled blocks, the parameters of the number of blocks to be inspected, the remaining number to be selected, and the remaining number of unprocessed blocks are detected. When the preset termination condition is met, the selection and judgment processing is terminated, and all the randomly sampled blocks and the default inspection blocks that have been extracted are summarized to obtain a set of blocks to be inspected and output.

[0014] By employing this technical solution, randomly selected blocks are aggregated into sets. A dynamic probability algorithm, combined with hardware-based true random numbers, generates random inspection probabilities. These probabilities are then compared with the random numbers to screen blocks for inspection and blocks exempt from inspection. This allows for the scientific and rational selection of blocks for inspection from randomly selected blocks, while ensuring that the preset configuration quantity and the upper limit for secure boot time are met, thus improving inspection efficiency.

[0015] Preferably, the method further comprises the following steps: Obtaining a historical inspection record of each randomly selected block, the historical archive including the total number of random inspections in the history of the current randomly selected block, the most recent consecutive number of inspection exemptions, and the timestamp of the most recent inspection; After every preset number of power-on starts, all the randomly sampled inspection blocks are sorted in ascending order according to the total number of inspections, a number of the randomly sampled inspection blocks with the lowest cumulative number of inspections are selected and marked as mandatory inspection blocks, the historical inspection records of all the mandatory inspection blocks are cleared, and the blocks are directly added to the inspection block set at the next power-on start; When the number of consecutive exemptions from inspection of any randomly selected block reaches the exemption threshold, it is marked as a high-risk block to be inspected and is directly added to the set of blocks to be inspected when it is powered on next time.

[0016] By adopting the above technical solution, randomly inspected blocks are sorted in ascending order according to the total number of inspections and the blocks with the lowest cumulative number of inspections are marked as mandatory blocks to be inspected, which can ensure that blocks that have not been inspected for a long time are inspected; blocks with consecutive inspection exemptions reaching a threshold are marked as high-risk blocks to be inspected, which can focus on checking blocks that may be at risk, further improving the comprehensiveness and accuracy of vehicle system firmware security checks and ensuring system safety.

[0017] Preferably, performing hierarchical verification on the block set to be checked and obtaining verification results specifically includes the following steps: performing hierarchical verification on the block set to be checked according to a preset hierarchical verification strategy, wherein the hierarchical verification strategy includes basic verification and deep verification, specifically, Performing the basic check and the deep check on the default check block in sequence, the basic check including a SHA-256 hash check, and the deep check performed by a trusted execution component; performing the basic check on the random check block, the basic check including a CRC32 check; When both the basic check and the deep check of the default check block pass, the check of the default check block succeeds; otherwise, the check fails; When the basic check of the random sampling block passes, the check of the random sampling block is successful. When the random sampling block meets the preset trigger condition, the deep check is performed on the random sampling block. When the deep check passes, the check is successful, otherwise the check fails.

[0018] By adopting the above technical solution, a hierarchical verification is performed on the set of blocks to be checked, which consists of the default check block and the random check block obtained by block processing when the program execution signal is received. The default check block adopts SHA-256 hash basic verification and trusted execution component deep verification, and the random check block adopts CRC32 basic verification and performs deep verification when the conditions are met. This can more accurately and effectively verify the integrity of each block of the system firmware and detect tampering in time; the verification results are judged as successful or failed according to different rules. Under the premise of ensuring the security of the firmware, the high time-consuming problem caused by the full deep verification can be avoided, the startup time is shortened, and a balance between the safety and efficiency of the startup and operation of the vehicle system is achieved.

[0019] Preferably, when the verification result is failure, an atomic rollback is performed according to the classification of the block to be checked, specifically comprising the following steps: When the verification of any of the default check blocks or the random check blocks fails, the corresponding default check block or the random check block is marked as a fault block and an atomic rollback process is triggered, and the code block type of the fault block is recorded; A backup version of the faulty block corresponding to the code block type is selected, and double verification is performed on the backup version, the double verification including static verification and dynamic verification. When the double verification passes, an atomic replacement operation is performed based on the backup version to replace the faulty block with the backup version that passes the double verification.

[0020] By adopting the above technical solution, when the default check block or random check block of the system firmware fails to be verified, the faulty block is marked and the atomic rollback process is triggered, ensuring that the vehicle system can be restored to a normal state when a problem occurs in the firmware, thereby improving the safety and stability of the vehicle system operation.

[0021] In a second aspect, the present application provides a secure boot time optimization device, which adopts the following technical means: A safe startup time optimization device, based on a vehicle-mounted system, includes the following modules: a firmware block module, configured to perform block processing on the system firmware of the vehicle-mounted system when a program execution signal is received, wherein the block processing result includes a default check block and a random check block; A random inspection block quantity calculation module is used to obtain the measured non-verification startup time and full verification time, and calculate the configuration quantity of the random inspection blocks according to the preset safe startup time upper limit; A block configuration module for checking, configured to extract the randomly selected blocks corresponding to the configured number in combination with a preset dynamic probability algorithm, and to obtain a set of blocks for checking; The verification and rollback module is used to perform hierarchical verification on the set of blocks to be checked and obtain a verification result. When the verification result is failure, an atomic rollback is performed according to the classification of the blocks to be checked.

[0022] By adopting the above technical solutions, a complete boot time optimization system has been built, providing the necessary software technical support for achieving a balance between the safety and efficiency of vehicle system startup. While ensuring firmware security, the boot time is greatly shortened, significantly improving the intelligence and automation level of vehicle system safe boot technology, and meeting the requirements of technological progress.

[0023] In a third aspect, the present application provides a smart terminal that adopts the following technical solution: A smart terminal includes a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the secure boot time optimization method as described above.

[0024] In a fourth aspect, the present application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium stores at least one instruction, at least one program, code set, or instruction set, which is loaded and executed by a processor to implement the secure boot time optimization method as described above.

[0025] In summary, this application includes at least one of the following beneficial technical effects: 1. This application divides the system firmware of the vehicle system into blocks and combines a dynamic probability algorithm to extract random sampling blocks to form a set of blocks to be checked for verification. This avoids the problem of traditional full verification that requires verifying massive amounts of data one by one. It can significantly shorten the startup time, take into account the safe startup time requirements of the entire vehicle, improve vehicle startup efficiency, and meet the needs of smart cars for fast response and efficient operation.

[0026] 2. This application calculates the number of random check blocks to be configured based on the preset upper limit of the secure boot time. It can reasonably arrange verification resources while ensuring firmware security, and achieve a balance between the security and efficiency of the vehicle software upgrade system.

[0027] 3. This application improves efficiency through hierarchical verification and combines the atomic rollback mechanism to quickly restore the system when tampering is detected, ensuring the security and availability of the system and building a safe and reliable in-vehicle software operating environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a flow chart of a method for optimizing secure boot time according to an embodiment of the present application; Figure 2 This is a firmware block flow chart of the secure boot time optimization method according to an embodiment of the present application; Figure 3 This is a flowchart of a calculation random sampling block of a secure boot time optimization method according to an embodiment of the present application; Figure 4 It is a structural diagram of the secure boot time optimization device according to an embodiment of the present application. DETAILED DESCRIPTION

[0029] The technical solutions in the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. The described embodiments are only possible technical implementations of the present invention, but are not limited thereto. Those skilled in the art can fully combine the embodiments of the present invention, and other embodiments obtained without creative work are also within the scope of protection of the present invention.

[0030] The embodiment of the present application provides a method for optimizing safe startup time, based on the vehicle system, such as Figure 1 As shown, the following steps are included: S1. When a program execution signal is received, the system firmware of the vehicle system is processed in blocks. The results of the block processing include default check blocks and random check blocks, such as Figure 2 As shown, the specific steps include: S11. When a program execution signal is received, the system firmware of the vehicle system is divided into multiple code blocks according to functions, such as a core control module, a fault protection module, an auxiliary function module, etc.

[0031] S12. Based on the introduced ISO 26262 functional safety standard and combined with the predefined safety level assessment model, multiple code blocks are divided into multiple default check blocks and multiple random check blocks.

[0032] The ISO 26262 functional safety standard is an international standard for functional safety of road vehicles. It divides product safety integrity levels into five levels: QM, A, B, C and D, among which ASIL D represents the highest safety requirements. The ISO 26262 level classification is based on three parameters: severity of hazardous events, probability of exposure and controllability.

[0033] Therefore, based on the above standards, a security level assessment model is established to quantify the security levels of various code blocks obtained by division in this application. The security level assessment model in this embodiment is: S score =0.5S v +0.3E x +0.2C trl ； Among them, S score S is the security level score, v Severity score, E x Score the exposure rate, C trl Score controllability.

[0034] The severity score is used to indicate the degree of harm that module failure poses to personal safety, the exposure rate score is used to indicate the probability of module failure, and the controllability score indicates the degree to which the failure can be intervened by the driver or the system.

[0035] In the above safety level assessment process, the calculation process for severity score, exposure rate score and controllability score is as follows: For severity scoring, after each code block is divided, a pre-established mapping rule library between functional modules and severity levels is called to obtain the corresponding severity level based on the code block's function. Severity levels are categorized as no harm, minor harm, severe harm, and fatal harm, with corresponding values ​​assigned from 1 to 4. For example, a code block related to core control is assigned a severity level of "fatal harm" and a severity score of 4; a code block responsible only for playing user prompts is assigned a severity level of "no harm" and a severity score of 1.

[0036] For exposure rate scoring, the system automatically records the calling frequency or execution duration of each code block during operation. For example, it counts the number of calls per minute of code blocks related to vehicle network communication in real time, and counts the running duration of code blocks related to navigation path planning in different driving scenarios. Based on the preset probability quantification rules, the score is automatically generated in combination with the running frequency including the calling frequency or execution duration. The probability quantification rule maps the running frequency or execution duration of the code block to the exposure rate level. The exposure rate levels include frequent, occasional, rare, and extremely unlikely to be exposed, and the corresponding assignment values ​​are 4 to 1.

[0037] If a code block is executed and runs continuously every time the vehicle is started, it means that the personnel are continuously exposed to the risk of failure of this code block during vehicle operation. Therefore, its exposure rate is assessed as "frequent" and assigned a value of 4. If a code block is rarely triggered, or even executed only a few times in the entire life cycle of the vehicle, such as some hidden debugging code, it is classified as "extremely unlikely" and assigned a value of 1. Other situations are not further described.

[0038] For controllability scoring, code dependency scanning tools are used to analyze each code block's external dependencies and alternative execution paths. If a code block is found to have multiple redundant execution branches or can be quickly taken over by other modules, it is marked as high controllability. If its execution results directly affect critical systems and there is no alternative solution, it is marked as low controllability.

[0039] Based on the results of code dependency analysis and preset controllability assessment rules, a score is automatically assigned. If the functionality of a code block can be seamlessly taken over by other modules within 100ms, a score of 1 is assigned; if there is no effective response after a failure, a score of 4 is assigned.

[0040] S13. Substitute the calculated severity score, exposure rate score, and controllability score into the security level assessment model to calculate the security level score of each code block. When the security level score is not less than the preset mandatory inspection threshold, the current code block is the default inspection block, otherwise it is a randomly selected inspection block.

[0041] In this embodiment, the mandatory check threshold is set to 8. If a code block's security level score is 8 or higher, the code block is classified as a default check block; otherwise, it is classified as a random check block. In one specific implementation, modules such as core control, security authentication, and fault protection are calculated and confirmed as default check blocks, while logging, user prompts, and other modules are randomly checked blocks.

[0042] S2. Obtain the measured unchecked startup time and full check time, and calculate the number of random check blocks based on the preset upper limit of the safe startup time, such as Figure 3 As shown, the specific steps include: S21. Obtaining a non-verification boot time obtained in a clean boot state with the secure boot mechanism disabled, and a full verification time obtained in a full verification state with the secure boot mechanism enabled but without block processing; The non-verification boot time is the time to directly boot without all verification, and the full verification time is the boot time to check the entire firmware.

[0043] Both the no-verification boot time and the full-verification boot time are pre-measured. The no-verification boot time is calculated by performing a no-verification boot with secure boot disabled, repeating the measurement 10 times, and taking the average value. The full-verification boot time is calculated by recording the complete verification boot time with the system firmware unblocked.

[0044] S22. Obtain historical statistical data and calculate the total mandatory check time of all default check blocks. Since the default check blocks must be checked at each startup, the total check time of these blocks needs to be calculated.

[0045] Assume there are k default check blocks, Among them, t m The verification time for each default check block is obtained through historical statistical data, i is an integer from 1 to k, T m The total check time for all default check blocks is calculated.

[0046] In actual implementation, the verification time of each default check block may not be the same because the size and verification method of different blocks may be different. However, for simplicity, the average time can be taken, or the verification time of each block can be pre-calculated based on the block size and verification method.

[0047] S23. Calculate the total random check block check time based on the no-check startup time, the total mandatory check time, and the preset upper limit of the safe startup time to obtain the total random check block check time.

[0048] T sr =T limit -T base -T m ; Among them, T sr is the total sampling and calibration time, T limit is the upper limit of safe boot time, T base This is the startup time without verification.

[0049] The upper limit of the safe boot time is given by the system requirements. The value can be adjusted according to the actual implementation requirements. The upper limit of the allowed safe boot time is minus the non-verification boot time, that is, the time consumed even without verification, and then minus the time consumed by the full verification time. The remaining time is the time that can be used to check the random sampling block.

[0050] In a specific implementation method, if the total random inspection and verification time is a negative value, it means that even if only the default inspection block is used, the time limit cannot be met. At this time, a security exception alarm should be triggered, for example, the system cannot meet the security startup time requirement and needs to be redesigned or an alarm should be triggered.

[0051] S24. Calculate the single block verification time of each randomly sampled block by combining the full verification time, the non-verification startup time, and the total number of firmware blocks.

[0052] Among them, T full is the full verification time, N total is the total number of blocks in the firmware, which is obtained by the sum of the default check blocks and the random check blocks divided in step S1.

[0053] It should be noted that in order to simplify the calculation of the dynamic configuration number of randomly sampled blocks, the single block verification time here is uniformly derived using an average time. This embodiment calculates it based on the total time and total number of blocks for full verification.

[0054] S25. Calculate the number of random inspection blocks based on the total inspection and verification time and the single block verification time.

[0055] The calculation formula is as follows, Among them, N random The number of configuration blocks for random sampling is rounded down to ensure that the security check time does not exceed the upper limit of the secure startup time.

[0056] S3. Using a preset dynamic probability algorithm to extract random blocks corresponding to the configured number, and summarizing them to obtain a set of blocks to be inspected, specifically including the following steps: S31. Aggregate all randomly selected blocks to form a randomly selected block set, create a selected block list and initialize the selected block list to be empty.

[0057] Get the configuration quantity N need , set the remaining number to be selected this time to the configured number, that is, R need =N need , the number of remaining unprocessed blocks R remaining is the total number of randomly sampled blocks, i.e.

[0058] S32, perform selection and judgment processing on each random sampling block in the random sampling block set in sequence, specifically, S321, calculate the random sampling probability of the current random sampling block being selected based on the remaining number of blocks to be selected and the remaining number of unprocessed blocks, that is, S322. Generate a random number using a hardware true random number generator, where the random number ranges from 0 to 1, and compare the random number with the random sampling probability.

[0059] S323, if the random number is less than the random sampling probability, mark the current random sampling block as the block to be checked, and then perform a minus one operation on the remaining parameters to be selected, that is, R need =R need -1; If the random number is not less than the random inspection probability, the random inspection block will be marked as an inspection-free block.

[0060] S324: Regardless of whether the current random inspection block is selected as the block to be inspected, the number of remaining unprocessed blocks is reduced by one, that is, R remaining =R remaining -1.

[0061] The parameter status of the remaining number of blocks to be selected and the remaining number of unprocessed blocks is updated and recorded.

[0062] Before performing the selection and judgment processing on each randomly sampled block, the parameters of the number of blocks to be inspected, the number of remaining blocks to be selected, and the number of remaining unprocessed blocks are detected. When the preset termination condition is met, the selection and judgment processing is terminated.

[0063] In this embodiment, there are two termination conditions, namely, When the number of randomly selected blocks marked as blocks to be checked reaches the configured number N need When , the lottery is terminated; Or when the number of remaining unprocessed blocks R remaining Equal to the remaining number of selections R need When the current and subsequent random inspection blocks are directly marked as blocks to be inspected, no subsequent selection is required.

[0064] For ease of understanding, a specific implementation method is described below: For example, in 10 random blocks (BLOCK1 to BLOCK10), 5 blocks need to be selected. R need =5; R remaining =10; First, process BLOCKLOCK1, P = 5 / 10 = 0.5, assuming the random number is 0.6, which is greater than 0.5, mark BLOCK1 as an inspection-free block and update Rneed =5, R remaining =9; Process BLOCK2, P = 5 / 9 ≈ 0.556, assuming the random number is 0.4, which is less than 0.556, mark BLOCK2 as a block to be checked and update R need =4, R remaining =8; Process BLOCK3, P = 4 / 8 = 0.5, assuming the random number is 0.3, which is less than 0.5, mark BLOCK3 as a block to be checked and update R need =3, R remaining =7; Process BLOCK4, P = 3 / 7 ≈ 0.429, assuming the random number is 0.7, which is greater than 0.429, mark BLOCK4 as an inspection-free block and update R need =3, R remaining =6; Process BLOCK5, P = 3 / 6 = 0.5, assuming the random number is 0.5, equal to 0.5, mark BLOCK5 as an inspection-free block, and update R need =3, R remaining =5; Process BLOCK6, P = 3 / 5 = 0.6, assuming the random number is 0.2, which is less than 0.6, mark BLOCK6 as a block to be checked and update R need =2, R remaining =4; Process BLOCK7, P = 2 / 4 = 0.5, assuming the random number is 0.9, which is greater than 0.5, mark BLOCK7 as an inspection-free block and update R need =2, R remaining =3; Process BLOCK8 and check the termination condition. The selected block is 3, which is less than 5. The remaining blocks are 3, which is greater than the required block 2. Therefore, the selection continues. P = 2 / 3 ≈ 0.667. Assuming the random number is 0.4, which is less than 0.667, mark BLOCK8 as a block to be checked and update R need =1, R remaining =9; Process BLOCK9 and check the termination condition. The selected block is 4, which is less than 5. The remaining blocks are 2, which is greater than the required block 1. Therefore, the selection continues. P = 1 / 2 = 0.5. Assume that the random number is 0.6, which is greater than 0.5. Mark BLOCK9 as an exempt block and update R need =1, R remaining =1; BLOCK10 is processed, triggering the termination condition: the sum of the remaining blocks and the selected blocks is 5, which is equal to the total number of blocks to be selected, 5. BLOCK10 is directly marked as pending inspection, and the process is terminated.

[0065] Therefore, the blocks to be checked are: BLOCK2, BLOCK3, BLOCK6, BLOCK8, BLOCK10.

[0066] S325: Summarize all the randomly extracted blocks and default check blocks to obtain a set of blocks to be checked and output the set.

[0067] S33. After each preset number of power-on starts, the random inspection block with the lowest cumulative number of inspections is selected and directly marked as a block to be inspected until the coverage is completed.

[0068] S331. Obtain historical inspection records for each randomly selected block. The historical archive includes the total number of random inspections for the current randomly selected block, the most recent consecutive number of inspection exemptions, and the timestamp of the most recent inspection. The total number of inspections in this history is limited. In this implementation, it refers to the total number of inspections within a preset power-on period. The most recent consecutive number of inspection exemptions refers to the number of consecutive times that the block has not been inspected. Continuous refers to two or more times.

[0069] S332. After every preset number of power-on starts, all random inspection blocks are sorted in ascending order according to the total number of inspections, and several random inspection blocks with the lowest cumulative number of inspections are selected and marked as mandatory inspection blocks. The number of random inspection blocks with the lowest cumulative number of inspections is determined according to: K = max(1, N need / 5), Clear the historical inspection records of all mandatory blocks to be inspected, and add them directly to the set of blocks to be inspected at the next power-on.

[0070] In this embodiment, the preset number of times is set to 10 by default and can be adjusted before actual implementation.

[0071] S333. When the number of consecutive exemptions from inspection for any randomly selected block reaches the exemption threshold, it is marked as a high-risk block to be inspected and is directly added to the set of blocks to be inspected at the next power-on startup.

[0072] It should be noted that the mandatory blocks to be inspected and the high-risk blocks to be inspected are directly added to the set of blocks to be inspected and processed as default inspection blocks, but in essence they are all randomly sampled blocks, so they occupy the configured number of randomly sampled blocks. In the next power-on startup, the number of randomly sampled blocks drawn should be the calculated configured number minus the number of mandatory blocks to be inspected and the high-risk blocks to be inspected. The rest of the process is the same as step S32 and will not be repeated here.

[0073] S4. Perform hierarchical verification on the set of blocks to be checked and obtain verification results. If the verification result is failure, perform atomic rollback based on the classification of the blocks to be checked. Specifically, the steps include: S41, perform hierarchical verification on the block set to be checked according to the preset hierarchical verification strategy, the hierarchical verification strategy includes basic verification and deep verification, specifically, S411. Perform basic verification and deep verification on the default check block in sequence. The basic verification of the default check block includes a SHA-256 hash check to verify the integrity of the default check block. The deep verification is behavior monitoring and is performed through the Trusted Execution Element (TEE). Memory sandbox detection is run in the Trusted Execution Environment. S412. Perform basic verification on the random inspection block. The basic verification of the random inspection block includes CRC32 verification. Rapid screening is performed through CRC32 to save time. The core principle of the layered verification strategy is that the default check block must complete two levels of verification: basic verification and deep verification. The random inspection block will only perform two levels of verification when specific conditions are triggered, otherwise only one level of basic verification will be performed.

[0074] S413. When both the basic check and the deep check of the default check block pass, the check of the default check block succeeds; otherwise, the check fails. S414. When the basic verification of the random sampling block passes, the verification of the random sampling block is successful. When the random sampling block meets the preset trigger conditions, a deep verification is performed on the random sampling block, that is, the TEE deep check is triggered. When the deep verification passes, the verification is successful, otherwise the verification fails.

[0075] In this embodiment, the trigger condition for performing deep verification on the random inspection block is that the basic verification of the current random inspection block fails, and then deep verification is performed.

[0076] S42: When the verification result is failure, perform atomic rollback based on the classification of the block to be checked, specifically including the following steps: S421. When any default check block or random check block fails verification, it is marked as a fault block and the atomic rollback process is triggered to record the code block type and error type of the fault block. The error type includes at least one of hash error, control flow hijacking, and memory out of bounds.

[0077] S422. Select a backup version of the corresponding fault block according to the code block type. The code block type includes a default check block or a random check block. The mandatory check block and the high-risk check block also belong to the random check block.

[0078] In this embodiment, for the default check block, versions V-1, V-2, and V-3 are selected from the secure storage area in sequence. Version V-1 is the executable version closest to the faulty block. For the random check block, version V-1 is selected from the secure storage area.

[0079] S423: Perform dual verification on the backup version. The dual verification includes static verification and dynamic verification. In this embodiment, the first static verification is ECDSA digital signature verification, which aims to verify the authenticity of the firmware source. The second dynamic verification is CRC32 real-time integrity check. The integrity and authenticity of the backup version are confirmed through dual verification.

[0080] When both static verification and dynamic verification pass, double verification passes, otherwise it fails.

[0081] For the default check block, when the V-1 version fails verification, the V-2 version is verified. When all three backup versions fail verification, the double verification fails.

[0082] When the double verification of the backup version fails, or the same faulty block is rolled back more than twice within 24 hours, the system circuit breaker is triggered and an alarm is issued.

[0083] S424: When the double verification passes, perform an atomic replacement operation based on the backup version to replace the faulty block with the backup version that passed the double verification. After the replacement is complete, update the running version pointer, record the rollback event, and move the currently damaged faulty version into the quarantine area.

[0084] Based on the same inventive concept above, the embodiment of the present application also discloses a safe startup time optimization device, such as Figure 4 As shown, it includes the following modules: The firmware block module is used to block the system firmware of the vehicle system when receiving the program execution signal. The block processing results include default check blocks and random check blocks; The random inspection block quantity calculation module is used to obtain the measured non-verification startup time and full verification time, and calculate the configuration quantity of random inspection blocks based on the preset safe startup time upper limit; A block configuration module for checking is used to extract randomly selected blocks corresponding to the configured number by combining a preset dynamic probability algorithm, and to obtain a set of blocks for checking; The verification and rollback module is used to perform hierarchical verification on the set of blocks to be verified and obtain the verification results. When the verification result is failure, an atomic rollback is performed based on the classification of the blocks to be verified.

[0085] In a specific implementation scheme, the firmware block module includes the following units: The first firmware block division unit is used to divide the system firmware into multiple code blocks according to function, and based on the introduced ISO26262 functional safety standard and combined with a predefined safety level assessment model, divide the multiple code blocks into multiple default check blocks and multiple random check blocks; The safety level assessment model is: S score =0.5S v +0.3E x +0.2C trl ; Among them, S score S is the security level score, v Severity score, E x Score the exposure rate, C trl Score controllability; The second firmware block unit is used to obtain a security level score for each code block based on the security level assessment model. When the security level score is not less than a preset mandatory inspection threshold, the current code block is a default inspection block, otherwise it is a random inspection block.

[0086] In a specific implementation scheme, the sampling block quantity calculation module includes the following units: The first random check block number calculation unit is used to obtain the non-verification boot time obtained in the pure boot state with the secure boot mechanism disabled, and the full verification time obtained in the full verification state with the secure boot mechanism enabled but without block processing; the second random check block number calculation unit is used to obtain historical statistical data and calculate the total mandatory verification time of all default check blocks; The third random check block quantity calculation unit is used to calculate the total random check block quantity time that can be used for random check block quantity verification based on the no-check startup time, the total mandatory check time, and the preset upper limit of the safe startup time; A fourth random check block number calculation unit is used to calculate the single block verification time of each randomly selected check block according to the full verification time and the total number of firmware blocks; The fifth random inspection block quantity calculation unit is used to calculate the configuration quantity of random inspection blocks according to the total random inspection verification time and the single block verification time.

[0087] In a specific implementation scheme, the block configuration module includes the following units: The first block configuration unit is used to aggregate all randomly selected blocks to form a random inspection block set, establish a selected block list and initialize the selected block list to be empty. The number of remaining blocks to be selected is the configured number, and the number of remaining unprocessed blocks is the total number of randomly inspected blocks. Each randomly inspected block in the random inspection block set is selected and judged in turn. Specifically, The random sampling probability of the current random sampling block being selected is calculated based on the remaining number of blocks to be selected and the remaining number of unprocessed blocks. A hardware true random number generator is used to generate a random number, and the random number is compared with the random sampling probability. If the random number is less than the random sampling probability, the current random sampling block is marked as a block to be inspected. At this time, the remaining number of parameters to be selected is subtracted by one. If the random number is not less than the random sampling probability, the random sampling block is marked as an inspection-free block. The parameter of the number of remaining unprocessed blocks is decremented by one, and the parameter status of the remaining number to be selected and the number of remaining unprocessed blocks is updated and recorded; The second block configuration unit is used to detect the parameters of the number of blocks to be inspected, the remaining number to be selected, and the remaining number of unprocessed blocks before performing the selection and judgment processing on each randomly selected block. When the preset termination condition is met, the selection and judgment processing is terminated, and all the randomly selected blocks and default inspection blocks that have been selected are summarized to obtain a set of blocks to be inspected and output.

[0088] The third block to be inspected configuration unit is used to obtain the historical inspection record of each randomly selected block, and the historical archive includes the total number of random inspections in the history of the current randomly selected block, the most recent number of consecutive inspection exemptions, and the timestamp of the most recent inspection; the fourth block to be inspected configuration unit is used to sort all randomly inspected blocks in ascending order according to the total number of inspections after each preset number of power-on startups, select several randomly inspected blocks with the lowest cumulative number of inspections and mark them as mandatory blocks to be inspected, clear the historical inspection records of all mandatory blocks to be inspected, and directly add them to the set of blocks to be inspected at the next power-on startup; The fifth block to be inspected configuration unit is used to mark any randomly selected block as a high-risk block to be inspected when the number of consecutive inspection exemptions reaches the inspection exemption threshold, and directly add it to the block to be inspected set at the next power-on startup.

[0089] In a specific implementation scheme, the verification and rollback module includes the following units: A first verification unit is configured to perform hierarchical verification on the set of blocks to be checked according to a preset hierarchical verification strategy. The hierarchical verification strategy includes basic verification and deep verification. Specifically, basic verification and deep verification are sequentially performed on the default check block. The basic verification includes a SHA-256 hash check, and the deep verification is performed by a trusted execution component. Basic verification is performed on the randomly selected check block. The basic verification includes a CRC32 check. The second verification unit is configured to verify that the default check block succeeds if both the basic verification and the deep verification of the default check block pass, otherwise the verification fails; When the basic check of the random sampling block passes, the check of the random sampling block is successful. When the random sampling block meets the preset trigger conditions, the random sampling block is subjected to a deep check. When the deep check passes, the check is successful, otherwise the check fails.

[0090] A first rollback unit is configured to, when any default check block or random check block fails verification, mark the corresponding default check block or random check block as a faulty block and trigger an atomic rollback process, and record the code block type of the faulty block; The second rollback unit is used to select the backup version of the corresponding fault block according to the code block type, and perform double verification on the backup version. The double verification includes static verification and dynamic verification. When the double verification passes, an atomic replacement operation is performed based on the backup version to replace the fault block with the backup version that passes the double verification.

[0091] Based on the same inventive concept mentioned above, an embodiment of the present application also discloses a computer-readable storage medium, which stores at least one instruction, at least one program, code set or instruction set. The at least one instruction, at least one program, code set or instruction set can be loaded and executed by a processor to implement the secure boot time optimization method provided by the above method embodiment.

[0092] Also based on the same inventive concept mentioned above, an embodiment of the present application also discloses a computer-readable storage medium, which stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by a processor to implement the secure boot time optimization method as described above.

[0093] Those skilled in the art will appreciate that all or part of the steps of the above embodiments may be implemented by hardware or by programs instructing related hardware to implement them. The programs may be stored in computer-readable storage media, which may include, for example, various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks, or optical disks.

[0094] The above are only optional embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A safe boot time optimization method based on a vehicle-mounted system, characterized in that: The steps include: When a program execution signal is received, the system firmware of the vehicle system is processed in blocks, wherein the results of the block processing include a default check block and a random check block; Obtain the measured unchecked startup time and full check time, and calculate the configuration quantity of the random inspection block according to the preset upper limit of the safe startup time; extracting the randomly extracted blocks corresponding to the configured number in combination with a preset dynamic probability algorithm, and summarizing them to obtain a set of blocks to be checked; A hierarchical check is performed on the set of blocks to be checked and a check result is obtained. When the check result is a failure, an atomic rollback is performed according to the classification of the blocks to be checked.

2. The secure boot time optimization method according to claim 1, wherein: The block processing of the system firmware of the vehicle-mounted system, wherein the block processing results include mandatory inspection blocks and random inspection blocks, specifically includes the following steps: Dividing the system firmware into multiple code blocks according to functions, and dividing the multiple code blocks into multiple default check blocks and multiple random check blocks based on the introduced ISO 26262 functional safety standard and a predefined safety level assessment model; The security level assessment model is: S score =0.5S v +0.3E x +0.2C trl ； Among them, S score S is the security level score, v Severity score, E x Score the exposure rate, C trl Score controllability; A security level score of each code block is obtained according to the security level assessment model. When the security level score is not less than a preset mandatory inspection threshold, the current code block is a default inspection block, otherwise it is a randomly selected inspection block.

3. The secure boot time optimization method according to claim 1, wherein: The step of obtaining the measured non-verification startup time and full verification time and calculating the configuration quantity of the random inspection blocks according to the preset upper limit of the safe startup time specifically includes the following steps: Get the unverified boot time obtained in a clean boot state with Secure Boot disabled, and the full verification time obtained in a full verification state with Secure Boot enabled but without block processing. Obtain historical statistical data and calculate the total mandatory check time for all the default check blocks; Calculate the total random check block check time based on the no-check startup time, the total mandatory check time, and a preset upper limit of the safe startup time; Calculate the single block verification time of each randomly selected block based on the full verification time and the total number of firmware blocks; The configuration quantity of the random sampling blocks is calculated according to the total sampling verification time and the single block verification time.

4. The method for optimizing secure boot time according to claim 1, wherein: The method of extracting the randomly selected blocks corresponding to the configured number in combination with a preset dynamic probability algorithm and aggregating them to obtain a set of blocks to be inspected specifically includes the following steps: aggregating all the randomly selected blocks to form a random inspection block set, establishing a selected block list and initializing the selected block list to be empty, wherein the remaining number to be selected is the configured number, and the remaining number of unprocessed blocks is the total number of the randomly inspected blocks; and sequentially performing a selection and judgment process on each of the randomly inspected blocks in the random inspection block set, specifically, Calculating the random sampling probability of the current random sampling block being selected based on the remaining number of blocks to be selected and the remaining number of unprocessed blocks, generating a random number using a hardware true random number generator, and comparing the random number with the random sampling probability; if the random number is less than the random sampling probability, marking the current random sampling block as a block to be inspected, and then performing a subtraction operation on the parameter of the remaining number of blocks to be selected; if the random number is not less than the random sampling probability, marking the random sampling block as an inspection-exempt block; Subtract one from the parameter of the remaining number of unprocessed blocks, and update and record the parameter states of the remaining number to be selected and the remaining number of unprocessed blocks; Before performing the selection and judgment processing on each of the randomly sampled blocks, the parameters of the number of blocks to be inspected, the remaining number to be selected, and the remaining number of unprocessed blocks are detected. When the preset termination condition is met, the selection and judgment processing is terminated, and all the randomly sampled blocks and the default inspection blocks that have been extracted are summarized to obtain a set of blocks to be inspected and output.

5. The method for optimizing secure boot time according to claim 4, wherein: The following steps are also included: Obtaining a historical inspection record of each randomly selected block, the historical archive including the total number of random inspections in the history of the current randomly selected block, the most recent consecutive number of inspection exemptions, and the timestamp of the most recent inspection; After every preset number of power-on starts, all the randomly sampled inspection blocks are sorted in ascending order according to the total number of inspections, a number of the randomly sampled inspection blocks with the lowest cumulative number of inspections are selected and marked as mandatory inspection blocks, the historical inspection records of all the mandatory inspection blocks are cleared, and the blocks are directly added to the inspection block set at the next power-on start; When the number of consecutive exemptions from inspection of any of the randomly selected inspection blocks reaches the exemption threshold, it is marked as a high-risk block to be inspected and is directly added to the set of blocks to be inspected when it is powered on next time.

6. The method for optimizing secure boot time according to claim 1, wherein: The step of performing hierarchical verification on the block set to be checked and obtaining a verification result specifically comprises the following steps: Perform hierarchical verification on the block set to be checked according to a preset hierarchical verification strategy, wherein the hierarchical verification strategy includes basic verification and deep verification, specifically, Performing the basic check and the deep check on the default check block in sequence, the basic check including a SHA-256 hash check, and the deep check performed by a trusted execution component; performing the basic check on the random check block, the basic check including a CRC32 check; When both the basic check and the deep check of the default check block pass, the check of the default check block succeeds; otherwise, the check fails; When the basic check of the random sampling block passes, the check of the random sampling block is successful. When the random sampling block meets the preset trigger condition, the deep check is performed on the random sampling block. When the deep check passes, the check is successful, otherwise the check fails.

7. The method for optimizing secure boot time according to claim 6, wherein: When the verification result is failure, an atomic rollback is performed according to the classification of the block to be checked, specifically including the following steps: When the verification of any of the default check blocks or the random check blocks fails, the corresponding default check block or the random check block is marked as a fault block and an atomic rollback process is triggered, and the code block type of the fault block is recorded; A backup version of the faulty block corresponding to the code block type is selected, and double verification is performed on the backup version, the double verification including static verification and dynamic verification. When the double verification passes, an atomic replacement operation is performed based on the backup version to replace the faulty block with the backup version that passes the double verification.

8. A safe startup time optimization device based on a vehicle-mounted system, characterized in that: Includes the following modules: a firmware block module, configured to perform block processing on the system firmware of the vehicle-mounted system when a program execution signal is received, wherein the block processing result includes a default check block and a random check block; A random inspection block quantity calculation module is used to obtain the measured non-verification startup time and full verification time, and calculate the configuration quantity of the random inspection blocks according to the preset safe startup time upper limit; A block configuration module for checking, configured to extract the randomly selected blocks corresponding to the configured number in combination with a preset dynamic probability algorithm, and to obtain a set of blocks for checking; The verification and rollback module is used to perform hierarchical verification on the set of blocks to be checked and obtain a verification result. When the verification result is failure, an atomic rollback is performed according to the classification of the blocks to be checked.

9. An intelligent terminal, characterized in that: It includes a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the secure boot time optimization method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The readable storage medium stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the secure boot time optimization method as described in any one of claims 1 to 7.

Images