Starting method and device of embedded equipment, embedded equipment and storage medium

Abstract

The embodiment of the invention provides a starting method and device of embedded equipment, the embedded equipment and a storage medium. The method comprises the following steps: initializing hardware required for starting the embedded equipment; loading a first data head of first firmware data in the external storage device to the random access memory, wherein the first firmware data further comprises a plurality of data blocks; and under the condition that the first data head is a legal data head, executing a security verification process based on the first data head, and loading a plurality of data blocks of the first firmware data in the external storage device to the random access memory in sequence. According to the technical scheme, in the bootROM code starting process, the security verification process executed based on the first data head and the process of loading the remaining data blocks of the first firmware data are executed in parallel, the execution duration of the bootROM code can be shortened, then the starting duration of the embedded device is shortened, and the starting efficiency of the embedded device is improved.

Description

Technical Field

[0001] The present application relates to the technical field of embedded devices, and more specifically, to a startup method and apparatus for an embedded device, an embedded device, and a storage medium. Background Art

[0002] After the system is powered on or reset, the embedded device first executes the Boot ROM (Boot Read-Only Memory) code, which is the lowest and most basic link in the boot chain.

[0003] In the related art, when the Boot ROM code is executed, part of the hardware in the embedded device is initialized first, and then a boot loader is loaded. After the boot loader is loaded, a security verification process is performed on it.

[0004] In the related art, it takes a long time to execute the Boot ROM code, resulting in low startup efficiency of the embedded device. Summary of the Invention

[0005] The embodiments of the present application provide a method and apparatus for starting an embedded device, an embedded device, and a storage medium.

[0006] In a first aspect, an embodiment of the present application provides a method for starting an embedded device, which is applied to the embedded device, wherein the embedded device includes a random access memory, and the method includes: initializing the hardware required for starting the embedded device; loading a first data header of first firmware data in an external storage device into the random access memory, wherein the first firmware data also includes multiple data blocks; when the first data header is a legal data header, performing a security verification process based on the first data header, and sequentially loading multiple data blocks of the first firmware data in the external storage device into the random access memory.

[0007] In a second aspect, an embodiment of the present application provides a startup device for an embedded device, the device comprising: an initialization module for initializing the hardware required for starting the embedded device; a data loading module for loading a first data header of first firmware data in an external storage device into a random access memory, the first firmware data also comprising multiple data blocks; a security module for executing a security verification process based on the first data header when the first data header is a legal data header; the data loading module is also for sequentially loading multiple data blocks of the first firmware data in the external storage device into the random access memory when the first data header is a legal data header.

[0008] In a third aspect, an embodiment of the present application provides an embedded device, comprising: a memory; one or more processors coupled to the memory; and one or more programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method of the first aspect.

[0009] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer program instructions are stored. The computer program instructions can be called by a processor to execute the method described in the first aspect.

[0010] In a fifth aspect, an embodiment of the present application provides a computer program product, which, when instructions in the computer program product are executed, is used to implement the method described in the first aspect.

[0011] Compared with the technical solutions provided by related technologies, the technical solutions provided by the embodiments of the present application first load the first data header of the first firmware data after initializing the hardware required for starting the embedded device, and then execute the security verification process based on the first data header and the process of loading the remaining data blocks of the first firmware data in parallel. Compared with the solutions in related technologies that require hardware initialization, loading firmware data, and security verification of firmware data to be completed in sequence when the BootROM code is executed, the technical solutions provided by the embodiments of the present application shorten the execution time of the BootROM code, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0013] Figure 1 This is a structural block diagram of an embedded device provided by an embodiment of the present application.

[0014] Figure 2 This is a structural block diagram of a security module provided by an embodiment of the present application.

[0015] Figure 3 This is a schematic diagram of the data structure of firmware data provided by one embodiment of the present application.

[0016] Figure 4 This is a flowchart of a method for starting an embedded device provided by an embodiment of the present application.

[0017] Figure 5This is a flowchart of a method for starting an embedded device provided by another embodiment of the present application.

[0018] Figure 6 This is a flowchart of a method for starting an embedded device provided by another embodiment of the present application.

[0019] Figure 7 This is a flowchart of a method for starting an embedded device provided by another embodiment of the present application.

[0020] Figure 8 This is a flowchart of a method for starting an embedded device provided by another embodiment of the present application.

[0021] Figure 9 This is a flowchart of a method for starting an embedded device provided by another embodiment of the present application.

[0022] Figure 10 This is a block diagram of a startup device for an embedded device provided by an embodiment of the present application.

[0023] Figure 11 This is a structural block diagram of an embedded device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0024] The embodiments of the present application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application and are not to be construed as limiting the present application.

[0025] In order to enable those skilled in the art to better understand the solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0026] First, the implementation environment provided by the embodiment of the present application is introduced, which includes an embedded device.

[0027] Combined with reference Figure 1 , which shows a block diagram of the structure of an embedded device 10 provided in one embodiment of the present application. The embedded device 10 includes a processor 110, a bus 120, a read-only memory 130, a random access memory 140, a security module 150, a peripheral controller 160, and a peripheral direct memory access (DMA) module 170.

[0028] The processor 110 is connected to the read-only memory 130 , the random access memory 140 , the security module 150 , the peripheral controller 160 , and the peripheral DMA module respectively through the bus 120 .

[0029] The read-only memory 130 is used to store sensitive data in the embedded device 10, such as BootROM code.

[0030] The random access memory 140 is used to store firmware data. After the embedded device 10 is powered on and started, the firmware data is loaded into the random access memory 140 for execution.

[0031] The security module 150 is used to execute a security verification process, including a security verification process based on a data header and a decryption process of a data block.

[0032] The peripheral controller 160 is connected to an external storage device, which may include an embedded MultiMedia Card (eMMC), a non-volatile memory (NAND) flash memory chip, a non-volatile memory (NOR) read-only memory, a secure digital (SD) card, etc.

[0033] The peripheral DMA module 170 is connected to the peripheral controller module 160. In the embodiment of the present application, the peripheral DMA module 170 is used to load data from the external storage device to the random access memory 140 via DMA. DMA is an efficient data transmission technology that allows data to be directly transferred between a peripheral device (i.e., an external storage device) and the memory (i.e., the random access memory 140) without the intervention of the processor 110. This can effectively reduce the burden on the processor 110 and improve data transmission efficiency.

[0034] The following combination Figure 2 The structure of the security module 150 is described.

[0035] The security module 150 includes a secure DMA submodule 1510, a digest calculation submodule 1520, a symmetric encryption and decryption submodule 1530, and an asymmetric encryption and decryption submodule 1540. The secure DMA submodule 1510 is connected to the digest calculation submodule 1520, the symmetric encryption and decryption submodule 1530, and the asymmetric encryption and decryption submodule 1540 via the bus 120.

[0036] The secure DMA submodule 1510 is used to ensure data security during data loading via DMA. In this embodiment of the present application, the secure DMA submodule 1510 is used to input the loaded data into other submodules in the security module 150 so that other submodules can perform data verification.

[0037] The digest calculation submodule 1520 is used to calculate a digest value based on a digest algorithm. Calculating a digest value refers to converting input data of any length into a unique hash value of a fixed length, and is typically used to verify data integrity. In the embodiment of the present application, the digest calculation submodule 1520 calculates the digest value of the data header to verify the integrity of the data header, and calculates the digest value of the firmware data to verify the integrity of the firmware data. Digest algorithms, also known as hash algorithms, include but are not limited to algorithms such as SHA1, SHA256, and SM3.

[0038] Symmetric encryption and decryption submodule 1530 is used to encrypt and decrypt data using a block cipher algorithm. In this embodiment of the present application, symmetric encryption and decryption submodule 1530 is used to decrypt data blocks within the firmware data. Block cipher algorithms include, but are not limited to, AES and SM4. Because block cipher algorithms require the encryption length to be equal to the cipher block length, data must be processed block by block. Furthermore, due to its block-based processing, data block loading and decryption operations can be performed in parallel.

[0039] Asymmetric encryption and decryption module 1540 is used to encrypt and decrypt data using a specified algorithm. In this embodiment of the present application, asymmetric encryption and decryption submodule 1540 is used to verify the signature of the data header in the firmware data, ensuring the legitimacy of the firmware to be launched, preventing third-party tampering with the firmware, and enhancing startup security. The specified algorithm can be RSA, SM2, or other algorithms.

[0040] In some embodiments, the security module 150 further includes a random number generation submodule 1550 , which is used to generate random numbers, which are typically used in the data encryption process.

[0041] Combined with reference Figure 3, which shows a schematic diagram of the data structure of the firmware data 30 provided by an embodiment of the present application. The firmware data 30 includes a data header 310 and multiple data blocks 320. The data header 310 may include a magic number, a firmware data block, a hash data block, an asymmetric data block, a symmetric data block, a data header checksum, and the like. The magic number is usually an identifier of the data type. The firmware data block includes contents such as the firmware size, the firmware memory storage address, the firmware deletion storage address, and the firmware memory running address. The hash data block includes contents such as the data header summary type, the firmware summary type, and the firmware summary. The asymmetric data block includes contents such as the signature algorithm type, public key information, and the firmware signature. The symmetric data block includes the encryption algorithm type and key information. It should be noted that the data blocks included in the data header 310, as well as the data structure and content included in the data blocks, can be adapted and adjusted according to the application scenario.

[0042] Combined with reference Figure 4 , which shows a flow chart of a method for starting an embedded device provided by an embodiment of the present application. The method includes the following process.

[0043] S401, initializing the hardware required for starting the embedded device.

[0044] The hardware required for embedded startup may include clocks, I / O pins, peripherals, etc. Initializing the above hardware may include setting clocks, resetting peripherals, configuring I / O pins, etc.

[0045] In some embodiments, after the embedded device is powered on or reset, the BootROM code is executed, and the BootROM code initializes the first hardware. The BootROM code is the first code executed by the embedded device when it is powered on or reset, and is responsible for initializing the hardware, loading firmware data, and performing security verification of the firmware data.

[0046] S402: Load a first data header of first firmware data in an external storage device into a random access memory.

[0047] The first firmware data also includes a plurality of data blocks. The external storage device may be an embedded multimedia card eMMC, NAND, NOR, SD card, etc.

[0048] Optionally, the embedded device executes the BootROM code to control the peripheral DMA module to load the first data header into the random access memory through DMA.

[0049] S403 : If the first data header is a valid data header, perform a security verification process based on the first data header, and load multiple data blocks of the first firmware data into a random access memory.

[0050] After the embedded device completes loading the first data header, it first checks whether the first data header is a valid data header. If the first data header is a valid data header, S403 is executed. If the first data header is not a valid data header, other data headers are reloaded until a valid data header is loaded. The process of determining the validity of a data header will be described in the following embodiments.

[0051] The security verification process performed based on the first data header refers to the signature verification process of the first data header, which is used to prevent the execution of unauthorized firmware and ensure user safety. The security verification process is performed by the security module in the embedded device. The security verification process performed based on the first data header is described in the following embodiments.

[0052] In an embodiment of the present application, during the process of loading the first firmware data, the first data header is loaded first. If the first data header is a legal data header, while executing the security verification process based on the first data header, other data blocks of the first firmware data are loaded in parallel. In this way, the execution time of the BootROM code is shortened, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device.

[0053] To sum up, the technical solution provided by the embodiment of the present application is to first load the first data header of the first firmware data after initializing the first hardware in the embedded device, and then execute the security verification process based on the first data header and the process of loading the remaining data blocks of the first firmware data in parallel. Compared with the solution in the related art that needs to complete hardware initialization, loading firmware data and security verification of firmware data in sequence when the BootROM code is executed, the technical solution provided by the embodiment of the present application shortens the execution time of the BootROM code, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device.

[0054] Combined with reference Figure 5 , which shows a flowchart of an embedded device startup method provided by another embodiment of the present application. Figure 4 In an optional embodiment provided in the embodiment, after S403, the method includes S504-S508.

[0055] S501, initializing the hardware required for starting the embedded device.

[0056] S502: Load a first data header of first firmware data in an external storage device into a random access memory.

[0057] The first firmware data further includes a plurality of data blocks.

[0058] S503 : If the first data header is a valid data header, perform a security verification process based on the first data header, and sequentially load multiple data blocks of the first firmware data in the external storage device into the random access memory.

[0059] S504 : After a data block among the plurality of data blocks of the first firmware data is loaded into the random access memory, generate a first notification message.

[0060] The first notification message is used to notify that a data block has been loaded into the random access memory. Optionally, after a data block is loaded, the peripheral DMA module sends an interrupt signal or a block transfer completion flag, which is also the first notification message.

[0061] It should be noted that if an error occurs during the data block loading process, the peripheral DMA module generates a data block loading error message. The processor controls the security module to stop the current data header verification work and the peripheral DMA module to stop data loading work based on the data block loading error message, and then searches for the next bootable firmware.

[0062] S505: Execute a decryption process on the loaded data block based on the first notification message.

[0063] Optionally, the security module in the embedded device uses the data block as a transmission descriptor node to configure the security module's security DMA submodule and symmetric encryption and decryption submodule based on the first notification message. The security DMA submodule is used to input the loaded data block into the symmetric encryption and decryption submodule, and the symmetric encryption and decryption submodule performs a decryption process on the loaded data block. Specifically, in combination with Figure 3 The data structure of the firmware data is shown in the figure. The embedded device obtains the encryption algorithm type and key message from the symmetric data block of the first data header through the security DMA sub-module. The security DMA sub-module inputs the above-mentioned encryption algorithm type and key message into the symmetric encryption and decryption sub-module, and the symmetric encryption and decryption sub-module performs the decryption process on the loaded data block based on the encryption algorithm type and key information.

[0064] While the embedded device decrypts the loaded data blocks through the symmetric decryption submodule, it also continues to load the remaining data blocks in the first firmware data through the peripheral DMA module. There is no need to wait until all data blocks are loaded before decrypting the data blocks. This can shorten the execution time of the BootROM code, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device.

[0065] S506 : When the security verification process passes and all the data blocks of the first firmware data are loaded and decrypted, a digest value of the first firmware data is obtained from the first data header.

[0066] When the security verification process passes and all the data blocks of the first firmware data are loaded and decrypted, the embedded device obtains the summary value of the first firmware data from the first data header through the security DMA submodule in the security module. Figure 3 According to the data structure of the firmware data shown in FIG, the security DMA sub-module reads the digest value of the first firmware data from the hash data block in the first data header.

[0067] S507: Calculate a first digest value of the first firmware data.

[0068] Combine Figure 3 The data structure of the firmware data is shown in FIG. 1 , the security module configures a summary submodule, and the summary submodule calculates a first summary value of the first firmware data based on the firmware summary type included in the hash data block in the first data header.

[0069] S508: If the first digest value matches the digest value of the first firmware data, start running the first firmware corresponding to the first firmware data.

[0070] If the first digest value is the same as the digest value of the first firmware data, it means that the two match and the first firmware data is legal and valid. At this time, the digest submodule generates a verification pass message. After monitoring the verification pass message, the processor starts running the first firmware corresponding to the first firmware data.

[0071] If the first digest value is different from the digest value of the first firmware data, it means that the two do not match and the first firmware data is illegal data. At this time, the digest submodule generates a verification failure message. After monitoring the verification failure message, the processor searches for the next bootable firmware.

[0072] In an embodiment of the present application, when the security verification process is passed and all data blocks of the first firmware data are loaded and decrypted, the embedded device will further perform security verification through the summary value of the first firmware data stored in the first data header and the first summary value calculated based on the first firmware data to ensure that the loaded first firmware data is legal and valid.

[0073] In summary, the technical solution provided by the embodiment of the present application decrypts a loaded data block of the first firmware data when the loading is complete, and simultaneously continues to load the remaining data blocks in the first firmware data through the peripheral DMA module, without having to wait until all data blocks are fully loaded before decrypting the data blocks. This can shorten the execution time of the BootROM code, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device. Furthermore, when the security verification process based on the first data header passes and all data blocks of the first firmware data are loaded and decrypted, further security verification is performed using the digest value of the first firmware data stored in the first data header and the first digest value calculated based on the first firmware data to ensure that the loaded first firmware data is legal and valid.

[0074] Combined with reference Figure 6 , which shows a flowchart of an embedded device startup method provided by an embodiment of the present application. Figure 4 In an optional embodiment, before S403, and based on Figure 5 In an optional embodiment provided in the embodiment, before S503, it is necessary to perform a validity check on the first data header. The validity check on the first data header includes the following steps S603-S606.

[0075] S601, initializing the hardware required for starting the embedded device.

[0076] S602: Load a first data header of first firmware data in an external storage device into a random access memory.

[0077] The first firmware data further includes a plurality of data blocks.

[0078] S603: Perform verification based on the magic number in the first data header.

[0079] The magic number is an identifier of the data type. The magic number is verified to verify whether the loaded data is a data header. If the magic number in the first data header is the specified value, the loaded data is a data header and the verification passes. If the magic number in the first data header is not the specified value, the loaded data header is not a data header and the verification fails. In this case, the embedded device generates a fourth notification message, reloads the next data header based on the fourth notification message, and verifies the legitimacy of the loaded data header. The fourth notification message is used to notify the user that the first data header is invalid.

[0080] S604: If the verification passes, perform verification based on the checksum in the first data header.

[0081] The checksum is verified to verify the integrity of the first data header. Optionally, the embedded device calculates the checksum of the first data header through the security module and compares the calculated checksum with the checksum in the first data header. If the two are the same, the checksum passes; if the two are different, the checksum fails. At this time, the embedded device generates a fourth notification message, reloads the next data header according to the fourth notification message, and determines the legitimacy of the loaded data header.

[0082] S605 : If the verification passes, the data blocks included in the first data header are checked in sequence based on the data types of the data blocks included in the first data header.

[0083] Checking the data block included in the first data header includes checking the integrity and correctness of the data block. Figure 3 In the data structure of the firmware data shown in FIG, the data types of the data blocks included in the first data header include firmware data blocks, hash data blocks, asymmetric data blocks, and symmetric data blocks.

[0084] When the data type is firmware data block, checking the firmware data block includes: checking whether the firmware data block includes firmware size, firmware memory storage address, firmware flash storage address and firmware memory motion address, and checking whether an illegal address appears.

[0085] When the data type is a hash data block, checking the hash data block includes: checking whether the hash data block includes a data header summary type, a firmware summary type, and a firmware summary, and checking whether the above data header summary type and firmware summary type are legal.

[0086] If the data type is a symmetric data block, the check on the symmetric data block includes checking whether the symmetric data block includes the encryption algorithm type and key information, and checking whether the encryption algorithm type and key information are valid. Optionally, if the symmetric data block passes the check, the security module can initialize the symmetric encryption and decryption submodule based on the encryption algorithm.

[0087] If the data type is an asymmetric data block, the inspection of the asymmetric data block includes: checking whether the asymmetric data includes the signature algorithm type, public key information, and firmware signature, and verifying the integrity and legitimacy of the public key information. The public key information verification process includes: calculating a digest value of the public key information through the security module, and comparing the calculated digest value with the digest value of the public key information stored in the one-time programmable memory (OTP). If the two are the same, the public key information is valid; if they are different, the public key information is invalid.

[0088] S606: If all the data blocks included in the first data header pass the check, determine that the first data header is a legal data header.

[0089] If any data block included in the first data header fails the check, the first data header is determined to be an illegal data header. At this time, the embedded device generates a fourth notification message, reloads the next data header according to the fourth notification message, and judges the legitimacy of the loaded data header.

[0090] S607 , executing a security verification process based on the first data header, and sequentially loading multiple data blocks of the first firmware data in the external storage device into the random access memory.

[0091] To sum up, the technical solution provided in the embodiment of the present application also judges the legitimacy of the first data header. When it is determined that the first data header is a legal data header, the subsequent security verification process and data loading process are executed to ensure that the loaded first data header is legal and valid.

[0092] Combined with reference Figure 7 , which shows a flowchart of a method for starting an embedded device provided by an embodiment of the present application, based on Figure 4-Figure 6 In an optional embodiment provided in the embodiment, the security verification process based on the first data header includes the following steps S703-S706.

[0093] S701: Initialize the hardware required for starting the embedded device.

[0094] S702: Load a first data header of first firmware data in an external storage device into a random access memory.

[0095] The first firmware data further includes a plurality of data blocks.

[0096] S703: If the first data header is a legal data header, obtain the signature algorithm type, public key information, firmware signature, and summary value of the first data header from the first data header to perform a signature authentication operation on the firmware summary value and the firmware signature.

[0097] In the case that the first data header is a legal data header, combined with Figure 3 In the data structure of the firmware data shown, the security DMA submodule in the security module reads the signature algorithm type, public key information and firmware signature from the asymmetric data block of the first data header, and reads the summary value of the first data header from the hash data block.

[0098] S704: Obtain the encryption algorithm type from the first data header, and perform a decryption operation on the firmware signature based on the encryption algorithm type and the public key information to obtain a decryption result.

[0099] The security module is configured with an asymmetric encryption and decryption submodule, which performs a decryption operation on the firmware signature through the signature algorithm type and the public key information to obtain a decryption result. Optionally, the asymmetric encryption and decryption submodule generates a decryption completion message after the decryption is completed. Optionally, when the decryption fails, the asymmetric encryption and decryption submodule generates a decryption failure message. At this time, the security verification process based on the first data header fails, and the processor controls the security module to stop working (if there is a decryption operation on the data block, the control security module terminates the decryption operation on the data block, and if S705 is not completed, the control security module stops the calculation process of the second summary value), and controls the peripheral DMA module to stop loading the data block of the first firmware data and look for the next bootable firmware.

[0100] S705: Calculate a second digest value corresponding to the decryption result.

[0101] The security module is configured with a summary submodule, and the summary submodule calculates a second summary value corresponding to the decryption result according to the data header summary type in the hash data block. Optionally, the summary submodule generates a calculation completion message after completing the calculation of the second summary value. Optionally, when the second summary value calculation fails, the summary submodule generates a calculation failure message. At this time, the security verification process based on the first data header fails, and the processor controls the security module to stop working (if there is a decryption operation on the data block, the control security module terminates the decryption operation on the data block, and, if S704 is not completed, the control security module stops the decryption process), and controls the peripheral DMA module to stop loading the data block of the first firmware data and search for the next bootable firmware.

[0102] It should be noted that the above S704-S705 are executed in parallel.

[0103] S706: If the second digest value matches the digest value of the first data header, the security verification process is passed.

[0104] The security module compares the second digest value with the digest value of the first data header based on the decryption completion message and the calculation completion message. If the second digest value is the same as the digest value of the first data header, the two match and the security verification process passes. The embedded device then continues to execute the subsequent data block loading process and the decryption process of the loaded data block. In some embodiments, if the security verification process passes, the security module generates a verification pass message to notify the processor that the security verification process based on the first data header has passed.

[0105] If the second digest value is different from the digest value of the first data header, the two do not match, and the security verification process fails. At this time, the processor controls the peripheral DMA module to end the loading process of the data block of the first firmware data, and, if there is a decryption operation on the data block, terminate the above decryption operation and search for the next bootable firmware. Optionally, if the security verification process fails, the embedded device generates a verification failure message; based on the verification failure message, the second data header of the second firmware data in the external storage device is loaded into the random access memory, and the second firmware data also includes multiple data blocks; if the second data header is a valid data header, the security verification process is executed based on the second data header, and the multiple data blocks of the second firmware data in the external storage device are sequentially loaded into the random access memory. The legitimacy judgment process of the second data header is referred to in S603-S606 and is not described in detail here. The security verification process parameters S703-S706 executed based on the second data header are not described in detail here.

[0106] S707 : If the first data header is a valid data header, load multiple data blocks of the first firmware data in the external storage device into the random access memory in sequence.

[0107] To sum up, the technical solution provided in the embodiment of the present application also obtains the signature algorithm type, public key information, and firmware signature, decrypts the firmware signature based on the signature algorithm type and public key information, obtains the decryption result, calculates the second summary value of the decryption result, and performs a security check on the first data header through the comparison result of the second summary value and the summary value of the first data header to ensure that the loaded first firmware data is legal and valid.

[0108] Please refer to Figure 8 , which shows a flowchart of a method for starting an embedded device provided by an embodiment of the present application. Figure 4-7 In an optional embodiment provided in the embodiment, the method further includes the following S801-S803.

[0109] S801: When it is detected that an error occurs in hardware required for starting the embedded device, a second notification message is generated.

[0110] The second notification message is used to notify the embedded device that an error has occurred in the hardware required for startup. The above hardware can be a clock, peripherals, I / O pins, etc., and this embodiment of the application does not limit this.

[0111] S802: Based on the second notification message, the startup process of the embedded device is terminated, sensitive data in the random access memory is cleared, and the read permission of the read-only memory in the embedded device is disabled.

[0112] Aborting the embedded device's boot process includes controlling the peripheral DMA module to stop data loading, controlling the security module to stop executing the data header security verification process, and controlling the security module to stop the data block decryption process. Optionally, the embedded device can obtain permission information for each data item in the random access memory and remove data with permission information greater than the preset permission as sensitive data to prevent sensitive data leakage. Disabling read permissions on the read-only memory prevents other devices from reading data from the read-only memory.

[0113] S803, enter lock mode.

[0114] After entering locked mode, the embedded device cannot start.

[0115] To sum up, the technical solution provided in the embodiment of the present application, when a hardware error is detected in the embedded device, terminates the startup process of the embedded device, clears sensitive data in the random access memory, and turns off the read permission of the read-only memory in the embedded device, and enters the locked mode. At this time, the embedded device will not continue to start, which can ensure that the embedded device starts and runs in a safe environment.

[0116] Please refer to Figure 9 , which shows a flowchart of a method for starting an embedded device provided by an embodiment of the present application. Figure 4-7 In an optional embodiment provided in the embodiment, the method further includes the following S901-S903.

[0117] S901: When multiple data headers are loaded into a random access memory, if no valid data header is found during traversal, a third notification message is generated.

[0118] The third notification message is used to notify that a legal data header has not been traversed. In an embodiment of the present application, the embedded device sequentially loads multiple data headers from an external storage device and performs a legitimacy check after each data header is loaded. If the loaded data header is a legal data header, the subsequent security verification process and data block loading process are executed. If the loaded data header is an illegal data header, the next data header is loaded. If all loadable data headers are illegal, it is determined that a legal data header has not been traversed.

[0119] S902: Clear sensitive data in the random access memory based on the third notification message, and disable the read permission of the read-only memory in the embedded device.

[0120] S903, enter the lock mode.

[0121] To sum up, the technical solution provided in the embodiment of the present application clears sensitive data in the random access memory without traversing the legal data header, and turns off the read permission of the read-only memory in the embedded device and enters the locked mode. At this time, the embedded device will not continue to start, which can ensure that the embedded device starts and runs in a safe environment.

[0122] Please refer to Figure 10 , which shows a block diagram of a startup device for an embedded device provided by an embodiment of the present application, the device includes: an initialization module 1010, a data loading module 1020 and a security module 1030.

[0123] The initialization module 1010 is used to initialize the hardware required for starting the embedded device.

[0124] The data loading module 1020 is configured to load a first data header of first firmware data in an external storage device into a random access memory, where the first firmware data further includes a plurality of data blocks.

[0125] The security module 1030 is configured to execute a security verification process based on the first data header when the first data header is a legal data header.

[0126] The data loading module 1020 is further configured to sequentially load multiple data blocks of the first firmware data in the external storage device into the random access memory when the first data header is a valid data header.

[0127] In some embodiments, the security module 1030 includes a symmetric encryption and decryption submodule (not shown). The data loading module 1020 is configured to generate a first notification message after a data block from among the plurality of data blocks of the first firmware data is loaded into the random access memory. The symmetric encryption and decryption submodule is configured to perform a decryption process on the loaded data block based on the first notification message.

[0128] In some embodiments, the device further includes a startup module, and the security module 1030 includes a digest submodule (not shown). The digest submodule is configured to, upon passing the security verification process and the loading and decryption of the multiple data blocks of the first firmware data, obtain a digest value of the first firmware data from the first data header and calculate a first digest value of the first firmware data. The startup module is configured to, if the first digest value matches the digest value of the first firmware data, start and execute the first firmware corresponding to the first firmware data.

[0129] In some embodiments, the device further includes: a first generation module, a startup process termination module, a data clearing module, a permission closing module, and a locking module (not shown in the figure). The first generation module is used to generate a second notification message when a hardware error required for the startup of the embedded device is detected. The startup process termination module is used to terminate the startup process of the embedded device based on the second notification message. The data clearing module is used to clear sensitive data in the random access memory. The permission closing module is used to turn off the read permission of the read-only memory in the embedded device. The locking module is used to enter the lock mode.

[0130] In some embodiments, the apparatus further includes: a second generation module (not shown). The second generation module is configured to generate a third notification message if no valid data header is found when loading multiple data headers into the random access memory. The data clearing module is further configured to clear sensitive data in the random access memory based on the third notification message. A permission closing module is configured to close the read permission of the read-only memory in the embedded device. A locking module is configured to enter a locked mode.

[0131] In some embodiments, the device further includes: a third generation module (not shown in the figure). The third generation module is configured to generate a verification failure message if the security verification process fails. The data loading module 1020 is configured to load a second data header of the second firmware data based on the verification failure message, where the second firmware data further includes multiple data blocks. The security module 1030 is configured to execute the security verification process based on the second data header if the second data header is a valid data header. The data loading module 1020 is further configured to sequentially load multiple data blocks of the second firmware data in the external storage device into the random access memory if the second data header is a valid data header.

[0132] In some embodiments, the security module 1030 is used to obtain the signature algorithm type, public key information, firmware signature and summary value of the first data header from the first data header to perform signature authentication operations on the firmware summary value and firmware signature; obtain the encryption algorithm type from the first data header, perform a decryption operation on the firmware signature based on the encryption algorithm type and public key information to obtain a decryption result; calculate a second summary value corresponding to the decryption result; if the second summary value matches the summary value of the first data header, the security verification process passes; if the second summary value does not match the summary value of the first data header, the security verification process fails.

[0133] In some embodiments, the apparatus further includes: a data header verification module (not shown in the figure). The data header verification module is configured to perform verification based on the magic number in the first data header; if the verification passes, perform verification based on the checksum in the first data header; if the verification passes, sequentially check the data blocks included in the first data header based on the data types of the data blocks included in the first data header; if all checks of the data blocks included in the first data header pass, then determine the first data header as a valid data header.

[0134] To sum up, the technical solution provided by the embodiment of the present application is to first load the first data header of the first firmware data after initializing the first hardware in the embedded device, and then execute the security verification process based on the first data header and the process of loading the remaining data blocks of the first firmware data in parallel. Compared with the solution in the related art that needs to complete hardware initialization, loading firmware data and security verification of firmware data in sequence when the BootROM code is executed, the technical solution provided by the embodiment of the present application shortens the execution time of the BootROM code, thereby reducing the startup time of the embedded device and improving the startup efficiency of the embedded device.

[0135] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0136] In several embodiments provided in this application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0137] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0138] See also Figure 11 , which shows that an embodiment of the present application further provides an embedded device 1100, which includes: one or more processors 1110, a memory 1120, and one or more applications. The one or more applications are stored in the memory 1120 and configured to be executed by the one or more processors 1110, and the one or more applications are configured to execute the methods described in the above embodiments.

[0139] The processor 1110 may include one or more processing cores. The processor 1110 utilizes various interfaces and circuits to connect various components within the battery management system. It executes instructions, programs, code sets, or instruction sets stored in the memory 1120, as well as accesses data stored in the memory 1120, to perform various functions of the battery management system and process data. Optionally, the processor 1110 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 1110 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem handles wireless communications. It is understood that the modem may not be integrated into the processor 1110 and may be implemented separately via a communication chip.

[0140] The memory 1120 may include a random access memory 1120 (RAM) or a read-only memory 1120 (Read-Only Memory). The memory 1120 may be used to store instructions, programs, codes, code sets, or instruction sets. The memory 1120 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the various method embodiments described below, etc. The data storage area may also store data created by the embedded device during use (such as a phone book, audio and video data, chat history data, etc.).

[0141] An embodiment of the present application further provides a computer-readable storage medium, which stores computer program instructions. The computer program instructions can be called by a processor to execute the method described in the above embodiment.

[0142] The computer-readable storage medium may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read-Only Memory), an EPROM, a hard disk, or a ROM. Alternatively, the computer-readable storage medium includes a non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for computer program instructions for executing any of the method steps described above. These computer program instructions may be read from or written to one or more computer program products. The computer program instructions may be compressed in a suitable form.

[0143] The above is only a preferred embodiment of the present application and does not constitute any form of limitation to the present application. Although the present application has been disclosed as above with preferred embodiments, it is not intended to limit the present application. Any person skilled in the art can make some changes or modifications to equivalent embodiments using the technical contents disclosed above without departing from the scope of the technical solution of the present application. However, any brief modifications, equivalent changes and modifications made to the above embodiments based on the technical essence of the present application without departing from the content of the technical solution of the present application are still within the scope of the technical solution of the present application.

Claims

1. A method for starting an embedded device, characterized in that: Applied to an embedded device, the embedded device including a random access memory, the method comprising: Initializing the hardware required to start the embedded device; Loading a first data header of first firmware data in an external storage device into a random access memory, wherein the first firmware data further includes a plurality of data blocks; In the case that the first data header is a legal data header, a security verification process is performed based on the first data header, and multiple data blocks of the first firmware data in the external storage device are loaded into the random access memory in sequence.

2. The method according to claim 1, characterized in that The method further comprises: generating a first notification message after one of the plurality of data blocks of the first firmware data is loaded into the random access memory; A decryption process is performed on the loaded data block based on the first notification message.

3. The method according to claim 2, characterized in that The method further comprises: When the security verification process passes and all the data blocks of the first firmware data are loaded and decrypted, obtaining a digest value of the first firmware data from the first data header; calculating a first digest value of the first firmware data; If the first digest value matches the digest value of the first firmware data, the first firmware corresponding to the first firmware data is started and executed.

4. The method according to any one of claims 1 to 3, characterized in that The method further comprises: generating a second notification message when detecting that an error occurs in hardware required for starting the embedded device; terminating a startup process of the embedded device based on the second notification message, clearing sensitive data in the random access memory, and disabling a read permission of a read-only memory in the embedded device; Enter lock mode.

5. The method according to any one of claims 1 to 3, characterized in that The method further comprises: When multiple data headers are loaded into the random access memory, if no valid data header is traversed, generating a third notification message; Clearing sensitive data in the random access memory based on the third notification message, and disabling read permission of the read-only memory in the embedded device; Enter lock mode.

6. The method according to any one of claims 1 to 3, characterized in that The method further comprises: If the security verification process fails, generating a verification failure message; loading a second data header of second firmware data in the external storage device into a random access memory based on the verification failure message, wherein the second firmware data further includes a plurality of data blocks; In the case that the second data header is a legal data header, a security verification process is performed based on the second data header, and multiple data blocks of the second firmware data in the external storage device are loaded into the random access memory in sequence.

7. The method according to any one of claims 1 to 3, characterized in that The performing of a security verification process based on the first data header includes: Obtaining a signature algorithm type, public key information, a firmware signature, and a digest value of the first data header from the first data header, so as to perform a signature authentication operation on the firmware digest value and the firmware signature; Obtaining an encryption algorithm type from the first data header, and performing a decryption operation on the firmware signature based on the encryption algorithm type and the public key information to obtain a decryption result; Calculating a second digest value corresponding to the decryption result; If the second digest value matches the digest value of the first data header, the security verification process is passed; If the second digest value does not match the digest value of the first data header, the security verification process fails.

8. The method according to any one of claims 1 to 3, characterized in that After the first data header in the external storage device is loaded into the random access memory, the method further includes: Performing verification based on the magic number in the first data header; If the verification passes, performing verification based on the checksum in the first data header; If the verification passes, sequentially checking the data blocks included in the first data header based on the data types of the data blocks included in the first data header; If all the data blocks included in the first data header pass the check, the first data header is determined as the legal data header.

9. A startup device for an embedded device, characterized in that: The device comprises: An initialization module, used for initializing the hardware required to start the embedded device; a data loading module, configured to load a first data header of first firmware data in an external storage device into a random access memory, wherein the first firmware data further comprises a plurality of data blocks; a security module, configured to perform a security verification process based on the first data header if the first data header is a valid data header; The data loading module is further configured to sequentially load multiple data blocks of the first firmware data in the external storage device into the random access memory when the first data header is a legal data header.

10. An embedded device, characterized in that: include: Memory; one or more processors coupled to the memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the method according to any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, which can be called by a processor to execute the method according to any one of claims 1 to 8.

Images