Secure boot method, electronic device, medium, secure boot software, and chip

Abstract

The application relates to the technical field of computers, in particular to a secure starting method, an electronic device, a medium, secure starting software and a chip. The method can first calculate label data corresponding to a to-be-authenticated object set (for example, a device image set) and obtain repair data by using a private key stored in the electronic device, then obtain authentication data by a first algorithm (for example, a reversible calculation algorithm) based on the label data and the repair data, wherein the calculation amount of the first algorithm is less than that of a digital signature algorithm. Then, whether the device image in the to-be-authenticated object set is trusted is determined by comparing the authentication data with a trusted root stored in the electronic device. In this way, the secure starting method provided in the embodiments of the application does not need to consume a large amount of computing resources or memory resources when comparing the authentication data with the trusted root, and can realize lightweight secure starting, so that the secure starting can be realized on an electronic device with limited resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a secure boot method, electronic device, medium, secure boot software and chip. Background Technology

[0002] A device image is a complete software package that a device relies on to boot and run. To ensure secure device startup, during the boot process, the device image stored on the device is verified through a root of trust and a series of trust chains to guarantee its trustworthiness, integrity, and privacy. The root of trust is a piece of trusted data embedded in the device, possessing both trustworthiness and immutability.

[0003] In some secure boot methods, the device may store a root of trust, a public key, a set of device images, and a signature of the set of device images, such as... Figure 1 As shown, during the secure boot process of the device, the public key is first verified through the root of trust. After the public key verification is successful, a digital signature verification algorithm is used to verify the signature of the device image set using the public key. If the signature verification is successful, it is determined that the device image in the device image set is trustworthy, and the secure boot process of the device continues.

[0004] Because digital signature verification algorithms require a lot of computation or memory, the secure boot process consumes a lot of computing or memory resources, making it difficult to implement secure boot methods on resource-constrained electronic devices (such as smart home devices, smart city devices, and other Internet of Things (IoT) devices). Summary of the Invention

[0005] To address the problem that secure boot methods are difficult to implement on resource-constrained electronic devices, this application provides a secure boot method, an electronic device, a medium, secure boot software, and a chip.

[0006] In a first aspect, this application provides a secure boot method applied to an electronic device, which stores a first private key, a set of objects to be authenticated, a first encrypted data, and an immutable first root of trust, wherein the set of objects to be authenticated includes a first device image, and the first device image corresponds to the first root of trust; the method includes: in response to a secure boot request, executing a secure boot process of the electronic device; during the secure boot process, performing tag calculation on the set of objects to be authenticated to obtain first tag data corresponding to the set of objects to be authenticated, and using the first private key to decrypt the first encrypted data to obtain first repair data; based on the first tag data and the first repair data, obtaining first authentication data through a first algorithm, wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm; and if the first authentication data is consistent with the first root of trust, determining that the first device image has been successfully authenticated, and loading the first device image.

[0007] It is understandable that if the first authentication data is consistent with the first root of trust, it means that the first device image is trustworthy. The electronic device can then determine that the first device image has been successfully authenticated and then load the first device image.

[0008] The secure boot method provided in this application embodiment can use a first root of trust to verify the first authentication data calculated by a first algorithm, thereby ensuring the trustworthiness of the first device image. Furthermore, the computational complexity of the first algorithm is less than that of the digital signature verification algorithm, and comparing the first authentication data with the first root of trust does not require significant computational or memory resources. Thus, lightweight secure boot can be achieved, enabling implementation on resource-constrained electronic devices.

[0009] In one possible implementation of the first aspect above, the method further includes: if the first authentication data is inconsistent with the first root of trust, determining that the first device image authentication has failed, and terminating the secure boot process.

[0010] It is understandable that if the first authentication data is inconsistent with the first root of trust, it means that the first device image is untrusted (for example, the first device image has been tampered with). The electronic device can then determine that the first device image authentication has failed and terminate the secure boot process to prevent unauthorized or tampered device images from being loaded and executed, thereby ensuring the security of the electronic device.

[0011] In one possible implementation of the first aspect above, the first algorithm is a reversible computation algorithm; the first data ciphertext is obtained by encrypting the first repair data using the first private key, wherein the first repair data is obtained by the first algorithm based on the trust label data of the first device image and the first trust root, and the trust label data of the first device image is obtained by label calculation of the first device image.

[0012] It can be understood that a reversible computation algorithm is a reversible data processing procedure. For example, a reversible computation algorithm can be a logical XOR algorithm.

[0013] In one possible implementation of the first aspect above, the first device image is in the first image ciphertext; the method further includes: during the process of performing tag calculation on the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, using the first private key to decrypt the first image ciphertext to obtain the first device image; or, before performing tag calculation on the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, using the first private key to decrypt the first image ciphertext to obtain the first device image.

[0014] It is understood that the first device image can be stored encrypted in the electronic device. That is, the set of objects to be authenticated may include the encrypted first image, which contains the first device image. When the first device image is encrypted, the electronic device can decrypt the encrypted first image to ensure that it can directly load the first device image after determining its trustworthiness, thereby ensuring a secure boot speed. This application does not specifically limit the timing of decrypting the encrypted first image. In other embodiments, the electronic device may also decrypt the encrypted first image after confirming successful authentication of the first device image, and then load the first device image.

[0015] In one possible implementation of the first aspect above, the method of using the first private key is as follows: using the first private key through a key ladder algorithm.

[0016] It is understandable that when using the key ladder algorithm to use the first private key, the electronic device does not need to directly use the first private key as the key used to decrypt the first data ciphertext or the first mirror ciphertext. In this way, the privacy of the first private key can be guaranteed and the first private key can be prevented from being leaked.

[0017] In one possible implementation of the first aspect described above, the electronic device further stores a first-level key, a second-level key, and a third-level key; the aforementioned method of using the first private key to decrypt the first encrypted data to obtain the first repaired data includes: using the first private key to decrypt the first-level key to obtain a first intermediate key; using the first intermediate key to decrypt the second-level key to obtain a second intermediate key; using the second intermediate key to decrypt the third-level key to obtain a secure boot key; and using the secure boot key to decrypt the first encrypted data to obtain the first repaired data.

[0018] It is understandable that in the process of using the first private key, the first step key, the second step key, and the third step key are different from any other key step in other scenarios in the electronic device that use key steps. This ensures that the first private key is used securely and privately.

[0019] For example, special data can be used as the first step key. In other scenarios where step keys are used, no step key can be the same as this special data. This special data can be, for example, all zeros.

[0020] The aforementioned key ladder algorithm is implemented through a three-level decryption process. In other embodiments, the key ladder algorithm can also be implemented through a two-level decryption process; this application does not specifically limit this method.

[0021] In one possible implementation of the first aspect above, the set of objects to be authenticated further includes a second device image, the first device image includes a second root of trust, and the electronic device also stores a second private key and a second encrypted data. After determining that the first device image is successfully authenticated, the method further includes: performing tag calculation on the set of objects to be authenticated to obtain second tag data corresponding to the set of objects to be authenticated, and using the second private key to decrypt the second encrypted data to obtain second repair data; based on the second tag data and the second repair data, obtaining second authentication data through a first algorithm; and if the second authentication data is consistent with the second root of trust, determining that the second device image is successfully authenticated and loading the second device image.

[0022] In some embodiments, a multi-level secure boot scheme can be employed, using a cascading approach to connect multiple secure boot levels. It can be understood that the first device image is the device image that needs to be loaded during the first-level secure boot, and the first root of trust is the root of trust for the first-level secure boot. Since the first device image includes a second root of trust, this second root of trust is the root of trust for the second-level secure boot. After confirming that the first device image has been successfully authenticated, the electronic device can determine that the first device image is trustworthy, meaning that the second root of trust within the first device image is trustworthy. Therefore, the electronic device can perform the second-level secure boot based on the second root of trust.

[0023] Thus, in this multi-level secure boot scheme, each level of secure boot (except for the first level) is built upon the previous level, forming a complete chain of trust. This ensures that every step of the secure boot process undergoes rigorous verification, effectively preventing malicious tampering of the device image. Furthermore, it allows for customization and optimization of the secure boot process at different levels to adapt to the needs of different electronic devices and application scenarios. When updating the device image, only specific levels of the device image can be updated, facilitating device image updates and maintenance. In addition, if a device image has a problem (e.g., it has been maliciously tampered with), the problem can be quickly located, improving system reliability and maintainability.

[0024] Secondly, this application provides a secure boot method applied to an electronic device, which stores a first private key, a set of objects to be authenticated, third encrypted data, and an immutable first root of trust. The set of objects to be authenticated includes a first device image and a first digest of the first device image, with the first device image corresponding to the first root of trust. The method includes: responding to a secure boot request and executing a secure boot process for the electronic device; during the secure boot process, performing tag calculation on the set of objects to be authenticated to obtain third tag data corresponding to the set of objects to be authenticated, and using the first private key to decrypt the third encrypted data to obtain third repair data; based on the third tag data and the third repair data, obtaining third authentication data through a first algorithm, wherein the computational complexity of the first algorithm is less than that of a digital signature verification algorithm; and determining that the first digest authentication is successful if the third authentication data matches the first root of trust.

[0025] It is understandable that if the electronic device confirms that the first digest authentication is successful, it can continue the authentication process for the first device image.

[0026] In one possible implementation of the second aspect above, the method further includes: determining that the first digest authentication has failed and terminating the secure boot process if the third authentication data is inconsistent with the first root of trust.

[0027] It is understandable that if the first digest authentication fails, it means that the first digest is untrusted (e.g., the first digest has been tampered with), and the electronic device can terminate the secure boot process.

[0028] In one possible implementation of the second aspect above, the first algorithm is a reversible computation algorithm; the third data ciphertext is obtained by encrypting the third repair data using the first private key, wherein the third repair data is obtained by the first algorithm based on the trust label data of the first digest and the first trust root, and the trust label data of the first digest is obtained by label calculation of the first digest.

[0029] In one possible implementation of the second aspect above, the first device image is contained in the first image ciphertext; the method further includes: using a first private key to decrypt the first image ciphertext to obtain the first device image, and performing tag calculation on the first device image to obtain fourth tag data of the first device image; if the first digest authentication is successful, comparing the fourth tag data with the first digest; if the fourth tag data and the first digest are consistent, loading the first device image; if the fourth tag data and the first digest are inconsistent, terminating the secure boot process.

[0030] It is understandable that the fourth tag data can be the digest to be verified of the first device image. Corresponding to the case where there are multiple first device images, the number of first digests and the number of fourth tag data can also be multiple. After the electronic device uses the first private key to decrypt the ciphertext of the first image, it can obtain multiple first device images. The electronic device needs to calculate the digest to be verified for each first device image separately and compare the digest to be verified for each first device image with the first digest of that first device image.

[0031] In one possible implementation of the second aspect above, the method of using the first private key is as follows: using the first private key through a key ladder algorithm.

[0032] It is understandable that when using the first private key through the key ladder algorithm, electronic devices do not need to directly use the first private key as the key used to decrypt the third data ciphertext or the first mirror ciphertext. In this way, the privacy of the first private key can be guaranteed and the first private key can be prevented from being leaked.

[0033] In one possible implementation of the second aspect described above, the electronic device further stores a first-level key, a second-level key, and a third-level key; the aforementioned method of using the first private key to decrypt the third data ciphertext to obtain the third repaired data includes: using the first private key to decrypt the first-level key to obtain a first intermediate key; using the first intermediate key to decrypt the second-level key to obtain a second intermediate key; using the second intermediate key to decrypt the third-level key to obtain a secure boot key; and using the secure boot key to decrypt the third data ciphertext to obtain the third repaired data.

[0034] The aforementioned key ladder algorithm is implemented through a three-level decryption process. In other embodiments, the key ladder algorithm can also be implemented through a two-level decryption process; this application does not specifically limit this method.

[0035] Thirdly, this application provides an electronic device comprising: a memory for storing instructions; and a processor for executing the instructions to implement the methods provided by the first aspect and various possible implementations of the first aspect, or to implement the methods provided by the second aspect and various possible implementations of the second aspect.

[0036] Fourthly, this application provides a computer-readable storage medium storing a program or instructions that, when executed by a processor, implement the methods provided by the first aspect and various possible implementations thereof, or implement the methods provided by the second aspect and various possible implementations thereof.

[0037] Fifthly, embodiments of this application also provide secure boot software, including a computer program or instructions, which, when executed by a processor, cause the methods provided by the first aspect and various possible implementations of the first aspect, or the methods provided by the second aspect and various possible implementations of the second aspect, to be implemented.

[0038] In a sixth aspect, embodiments of this application also provide a chip, which includes a processor and a memory. The memory is used to store the secure boot software provided in the fifth aspect above. When the processor executes the computer program or instructions in the secure boot software, it can implement the methods provided in the first aspect and various possible implementations of the first aspect or the methods provided in the second aspect and various possible implementations of the second aspect.

[0039] The beneficial effects of the third to sixth aspects mentioned above can be referred to the relevant descriptions in the first aspect and its various possible implementations, or the second aspect and its various possible implementations, and will not be repeated here. Attached Figure Description

[0040] Figure 1 A flowchart illustrating a secure boot method is shown based on some embodiments.

[0041] Figure 2A A flowchart illustrating a secure boot method is shown based on an embodiment of this application.

[0042] Figure 2B A schematic diagram of a secure boot method is shown according to the method provided in the embodiments of this application;

[0043] Figure 2C A schematic diagram illustrating a method for using a first private key is shown based on the method provided in the embodiments of this application.

[0044] Figure 3According to the method provided in the embodiments of this application, a schematic diagram of a process for generating relevant data before an electronic device leaves the factory is shown;

[0045] Figure 4 A flowchart illustrating another secure boot method is shown based on methods provided in some embodiments;

[0046] Figure 5 According to the method provided in the embodiments of this application, a flowchart of another secure boot method is shown;

[0047] Figure 6 A schematic diagram of the structure of an electronic device is shown according to the method provided in the embodiments of this application;

[0048] Figure 7 A schematic diagram of yet another secure boot method is shown based on the method provided in the embodiments of this application. Detailed Implementation

[0049] The illustrative embodiments of this application include, but are not limited to, a secure boot method, an electronic device, a storage medium, and secure boot software.

[0050] The electronic devices provided in this application include, but are not limited to, Internet of Things (IoT) devices, mobile phones, tablets, desktop computers, laptops, handheld computers, netbooks, virtual reality (VR) devices, augmented reality (AR) devices, and in-vehicle electronic devices. Among these, IoT devices may include, but are not limited to, electronic devices in the fields of smart homes, smart cities, and smart agriculture.

[0051] As mentioned earlier, some secure boot methods use digital signature algorithms to verify the signatures of the device image set stored in the device. Since digital signature algorithms require a lot of computation or consume a lot of memory, the secure boot process consumes a lot of computing or memory resources, making it difficult to implement secure boot methods on resource-constrained devices.

[0052] The aforementioned digital signature verification algorithms can be, for example, the RSA public-key cryptography algorithm, the elliptic curve digital signature algorithm (ECDSA), the Edwards-curve digital signature algorithm (EdDSA), the SM2 digital signature algorithm (SM2DSA), etc., in asymmetric cryptography. Alternatively, they can be, for example, the CRYSTALS-Dilithium algorithm, the Falcon algorithm, the Leighton-Micali signature algorithm (LMS), the extended Merkle signature scheme (XMSS), the SPHINCS+ algorithm, etc., in post-quantum cryptography.

[0053] It is understandable that the various digital signature verification algorithms listed above require a large amount of computation or memory usage during the signature verification process.

[0054] In view of this, embodiments of this application provide a secure boot method. This method does not require a digital signature verification algorithm for signature verification. Instead, it first calculates tag data corresponding to the set of objects to be authenticated (e.g., a set of device images) and uses a private key stored in the electronic device to obtain repair data. Then, based on the tag data and the repair data, authentication data is obtained through a first algorithm (e.g., a reversible computation algorithm), wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm. Afterwards, by comparing the authentication data with the root of trust stored in the electronic device, it is determined whether the device images in the set of objects to be authenticated are trustworthy.

[0055] It is understandable that if the authentication data is consistent with the root of trust, it means that the device image is trustworthy. In this case, the electronic device can determine that the device image has been successfully authenticated and then load the device image.

[0056] The secure boot method provided in this application embodiment can use a root of trust to verify the authentication data calculated by the first algorithm, thereby ensuring the trustworthiness of the device image. Furthermore, the computational complexity of the first algorithm is less than that of the digital signature verification algorithm, and comparing the authentication data with the root of trust does not require significant computational or memory resources. Thus, lightweight secure boot can be achieved, enabling implementation on resource-constrained electronic devices.

[0057] It is understandable that if the authentication data is inconsistent with the root of trust, it means that the device image is untrusted (e.g., the device image has been tampered with). The electronic device can then determine that the device image authentication has failed and terminate the secure boot process to prevent unauthorized or tampered device images from being loaded and executed, thereby ensuring the security of the electronic device.

[0058] The following is combined with Figure 2A and Figure 2B The secure boot method provided in the embodiments of this application will be described. The subject executing this method can be any of the electronic devices mentioned in the embodiments of this application.

[0059] In some embodiments, the electronic device stores a first private key, a set of objects to be authenticated, a first encrypted data, and a first root of trust that cannot be tampered with. The set of objects to be authenticated may include a first device image, and the first device image corresponds to the first root of trust.

[0060] like Figure 2A and Figure 2B As shown, the method includes:

[0061] S201, in response to the secure boot request, execute the secure boot procedure for the electronic device.

[0062] In some embodiments, an electronic device may perform a secure boot process in response to a secure boot request.

[0063] It is understandable that during the secure boot process of an electronic device, it is necessary to verify the trustworthiness of each device image stored in the electronic device. Device images can include firmware images, system images, etc., where firmware images can contain data such as operating system kernels, device drivers, and configuration files, and system images can contain complete operating system images. That is to say, there can be multiple first device images in the set of objects to be authenticated. When an electronic device verifies multiple first device images, the multiple first device images can be treated as a single image set and verified through the processes described in S202 to S204 below, or the first device images within the multiple first device images can be verified separately through the processes described in S202 to S204 below.

[0064] S202, during the secure startup process, the set of objects to be authenticated is labeled to obtain the first label data corresponding to the set of objects to be authenticated, and the first private key is used to decrypt the first data ciphertext to obtain the first repair data.

[0065] In some embodiments, during the secure boot process, the electronic device can perform tag calculation on the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, and use the first private key to decrypt the first data ciphertext to obtain the first repair data.

[0066] It is understood that electronic devices can use tag calculation methods to perform tag calculation. For example, tag calculation methods may include, but are not limited to, cryptographic algorithms such as hash algorithms (HASH), message authentication code (MAC) algorithms, and authenticated encryption with associated data (AEAD) algorithms.

[0067] In some embodiments, the first data ciphertext may be obtained by encrypting the first repair data using a first private key, wherein the first repair data is obtained by a first algorithm based on the trust label data of the first device image and the first trust root, and the trust label data of the first device image is obtained by label calculation of the first device image.

[0068] It is understandable that before an electronic device leaves the factory, developers can calculate the first repair data on the device manufacturer's equipment or server, encrypt the first repair data using a first private key to obtain the first data ciphertext, and then burn the first data ciphertext into the electronic device, so that the electronic device can store the first data ciphertext. The specific process will be described later and will not be elaborated here.

[0069] In some embodiments, corresponding to the case where an electronic device verifies multiple first device images as a set of images: the first tag data can be the tag data corresponding to the set of images, and the first repair data can correspond to the set of images, and the trust tag data can be obtained by tag calculation on the set of images.

[0070] For example, an electronic device can calculate the first tag data using a hash algorithm. The first tag data corresponding to the set of objects to be authenticated can be a digest of the mirror set. Furthermore, the trust tag data can also be a trust digest of the mirror set; that is, the trust tag data can be obtained by calculating the tag of the mirror set using a hash algorithm.

[0071] It is understood that a hash algorithm is a one-way function that can map input data of arbitrary length to a fixed-length output (called a digest or hash value), a process that typically does not require a key. Furthermore, the trust label data in the above embodiment is obtained by calculating the labels on the image set within the device before it leaves the factory. That is, the image set used to calculate the trust label data is a trusted image set, while the image set used to calculate the first label data is a image set to be verified.

[0072] In this case, the verification process in S203 and subsequent S203 to S204 can be a verification process of the electronic device against the image set (including multiple first device images). The number of first data ciphertexts stored in the electronic device can be one, and this first data ciphertext corresponds to the image set.

[0073] In some embodiments, corresponding to the case where the electronic device verifies each of the multiple first device images: for any first device image, the first tag data can be the tag data corresponding to the first device image, and the first repair data can also correspond to the first device image, and the trust tag data can be obtained by tag calculation for the first device image.

[0074] For example, an electronic device can calculate the first tag data using a hash algorithm, so the first tag data corresponding to the set of objects to be authenticated can be a digest of the first device image. Furthermore, the trust tag data can also be a trust digest of the first device image; that is, the trust tag data can be obtained by calculating the tag of the first device image using a hash algorithm.

[0075] It is understood that the trust label data in the above embodiments is obtained by calculating the label of the first device image in the device before the device leaves the factory. That is to say, the first device image used when calculating the trust label is a trusted first device image, while the first device image used when calculating the first label data is a first device image to be verified.

[0076] In this case, the verification process in S203 and subsequent S203 to S204 can be a verification process of the electronic device against any one of the first device images. The electronic device can also store multiple first data ciphertexts, and each of the multiple first data ciphertexts corresponds one-to-one with a multiple first device image.

[0077] In some embodiments, when an electronic device calculates the first tag data corresponding to the set of objects to be authenticated, it may also use the first private key.

[0078] For example, in the case where an electronic device verifies multiple first device images as a single image set: the electronic device can use a first private key to calculate first tag data through a message authentication algorithm. The first tag data corresponding to the set of objects to be authenticated can be the MAC code of that image set. Furthermore, the trust tag data can also be the trust MAC code of that image set; that is, the trust tag data can be obtained by using the first private key to calculate the tag for that image set through a message authentication algorithm.

[0079] For cases where an electronic device verifies each of multiple first device images: For any one first device image, the electronic device can use a first private key to calculate first tag data using an Authentication Encryption Algorithm (AEAD). The first tag data can then be the authentication tag (TAG) of the first device image. Furthermore, the trust tag data can also be the trust authentication tag (TAG) of that first device image; that is, the trust tag data can be calculated using the first private key and the Authentication Encryption Algorithm (AEAD) for that first device image.

[0080] S203, based on the first tag data and the first repair data, the first authentication data is obtained through the first algorithm.

[0081] In some embodiments, an electronic device may obtain first authentication data based on first tag data and first repair data using a first algorithm, wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm.

[0082] In some embodiments, the first algorithm is a reversible computation algorithm. It can be understood that a reversible computation algorithm is a reversible data processing procedure. If the reversible computation algorithm is represented as a function FUNC, then the expression of the reversible computation algorithm can be the following formula (1):

[0083] ; (1);

[0084] Here, A can represent trust tag data, B can represent first repair data, and C can represent first authentication data. For example, the reversible computation algorithm can be a logical XOR algorithm, i.e. ; .

[0085] If the reversible computation algorithm is represented by functions FUNC_1 and FUNC_2, then the expression of the reversible computation algorithm can be the following formula (2):

[0086] ; (2);

[0087] The functions FUNC_1 and FUNC_2 are different. For example, FUNC_1 can be a multiplication operation in mathematics, while FUNC_2 can be a division operation in mathematics. ; .

[0088] It should be noted that any calculation that satisfies the above formula (1) or formula (2) can be used as the reversible calculation algorithm mentioned in the embodiments of this application.

[0089] In some embodiments, the first device image may be contained within a first image ciphertext. In other words, the set of objects to be authenticated may include the first image ciphertext, which contains the first device image.

[0090] It is understandable that the first device image can be stored encrypted within the electronic device. For example, before the electronic device leaves the factory, developers can obtain the first device image from the device manufacturer's equipment or server, encrypt the first device image using a first private key to obtain the first image ciphertext, and then burn the first image ciphertext into the electronic device, thus enabling the electronic device to store the first image ciphertext. The specific process will be described later and will not be elaborated here.

[0091] In some embodiments, the electronic device may use a first private key to decrypt the first image ciphertext to obtain the first device image during the process of calculating tags for the set of objects to be authenticated and obtaining the first tag data corresponding to the set of objects to be authenticated. Alternatively, the electronic device may use the first private key to decrypt the first image ciphertext to obtain the first device image before calculating tags for the set of objects to be authenticated and obtaining the first tag data corresponding to the set of objects to be authenticated.

[0092] It is understood that when the first device image is encrypted, the electronic device can decrypt the encrypted first image to ensure that it can directly load the first device image after determining its trustworthiness, thereby ensuring the secure boot speed of the electronic device. This application does not specifically limit the timing of decrypting the encrypted first image. In other embodiments, the electronic device may also decrypt the encrypted first image after confirming successful authentication of the first device image, and then load the first device image.

[0093] For example, an electronic device can use a first private key to decrypt the first mirror ciphertext using the Advanced Encryption Standard (AES) algorithm.

[0094] For example, the Galois / Counter Mode (GCM) algorithm is an encryption mode of authentication encryption algorithms that can be used in conjunction with symmetric encryption algorithms (such as AES) to simultaneously achieve data decryption and tag calculation. The AES-GCM algorithm is a combination of the AES and GCM algorithms. Electronic devices can also use a first private key to simultaneously decrypt the first mirror ciphertext and calculate the first tag data using the AES-GCM algorithm.

[0095] S204, if the first authentication data is consistent with the first root of trust, the first device image is determined to be successfully authenticated, and the first device image is loaded.

[0096] In some embodiments, if the first authentication data is consistent with the first root of trust, the electronic device may determine that the first device image has been successfully authenticated and load the first device image.

[0097] It is understandable that once the electronic device confirms successful authentication of the first device image, it can continue the secure boot process. Subsequent secure boot procedures may include: loading the first device image into runtime memory, executing the first device image, initializing hardware resources and peripherals, loading security policies, and booting the operating system kernel.

[0098] In some embodiments, if the first authentication data is inconsistent with the first root of trust, the electronic device may determine that the first device image authentication has failed and terminate the secure boot process.

[0099] It is understandable that the inconsistency between the first authentication data and the first root of trust indicates that the first label data and the trust label data are inconsistent. This means that the first device image has been tampered with, i.e., the first device image is untrusted. Therefore, electronic devices can terminate the secure boot process (i.e., terminate the device boot process) to avoid loading an untrusted device image, thereby ensuring the security of the electronic device.

[0100] In some embodiments, the first private key can be used in the above S202 by using the first private key through a key ladder algorithm.

[0101] It is understandable that when using the key ladder algorithm with the first private key, the electronic device does not need to directly use the first private key as the key for decrypting the first data ciphertext or the first mirror ciphertext. Furthermore, if the electronic device also needs to use the first private key when performing tag calculations, it also does not need to directly use the first private key as the key used in tag calculations. In this way, the confidentiality of the first private key can be guaranteed, preventing its leakage.

[0102] In some embodiments, the electronic device also stores a first step key, a second step key, and a third step key. For example... Figure 2C As shown, when the electronic device uses the first private key, it can decrypt the first step key to obtain the first intermediate key. Then, it can use the first intermediate key to decrypt the second step key to obtain the second intermediate key. Finally, it can use the second intermediate key to decrypt the third step key to obtain the secure boot key. The secure boot key is the key used to decrypt the first data ciphertext or the first mirror ciphertext.

[0103] For example, an electronic device can use a secure boot key to decrypt the first encrypted data to obtain the first repaired data. Similarly, an electronic device can use a secure boot key to decrypt the first encrypted image to obtain the first device image. If the electronic device also needs to use the first private key when performing tag calculation, it can use the secure boot key to perform tag calculation and obtain the first tag data.

[0104] It is understandable that in the process of using the first private key, the first step key, the second step key, and the third step key are different from any other key step in other scenarios in the electronic device that use key steps. This ensures that the first private key is used securely and privately.

[0105] For example, special data can be used as the first step key. In other scenarios where step keys are used, no step key can be the same as this special data. This special data can be, for example, all zeros.

[0106] The aforementioned key ladder algorithm is implemented through a three-level decryption process. In other embodiments, the key ladder algorithm can also be implemented through a two-level decryption process; this application does not specifically limit this method.

[0107] In some embodiments, a multi-level secure boot scheme can be adopted, which uses a cascading approach to connect multiple secure boot levels.

[0108] When using a multi-level secure boot scheme, the set of objects to be authenticated may also include a second device image, the first device image includes a second root of trust, and the electronic device also stores a second private key and a second encrypted data.

[0109] In some embodiments, after determining that the first device image authentication is successful, the electronic device can further perform tag calculation on the set of objects to be authenticated to obtain second tag data corresponding to the set of objects to be authenticated, and use a second private key to decrypt the second data ciphertext to obtain second repair data. Then, based on the second tag data and the second repair data, the electronic device can obtain second authentication data through a first algorithm. Afterwards, if the second authentication data matches the second root of trust, the electronic device can determine that the second device image authentication is successful and load the second device image.

[0110] It can be understood that the first device image is the device image that needs to be loaded during the first-level secure boot, and the first root of trust is the root of trust for the first-level secure boot. Since the first device image includes a second root of trust, this second root of trust is the root of trust for the second-level secure boot. After confirming that the first device image has been successfully authenticated, the electronic device can determine that the first device image is trustworthy, that is, the second root of trust within the first device image is trustworthy. Therefore, the electronic device can perform the second-level secure boot based on the second root of trust.

[0111] It should be noted that the number of security boot levels and the device image to be loaded at each security boot level can be set according to the actual application, and this application does not limit this.

[0112] For example, multiple device images in an electronic device can be divided into two levels. In Level 1 Secure Boot, at least one first device image needs to be loaded based on the first root of trust. In Level 2 Secure Boot, at least one second device image needs to be loaded based on the second root of trust. Alternatively, multiple device images in an electronic device can be divided into three levels. In this example, the second device image may include a third root of trust, and in Level 3 Secure Boot, at least one third device image needs to be loaded based on the third root of trust.

[0113] Thus, in this multi-level secure boot scheme, each level of secure boot (except for the first level) is built upon the previous level, forming a complete chain of trust. This ensures that every step of the secure boot process undergoes rigorous verification, effectively preventing malicious tampering of the device image. Furthermore, it allows for customization and optimization of the secure boot process at different levels to adapt to the needs of different electronic devices and application scenarios. When updating the device image, only specific levels of the device image can be updated, facilitating device image updates and maintenance. In addition, if a device image has a problem (e.g., it has been maliciously tampered with), the problem can be quickly located, improving system reliability and maintainability.

[0114] The following is combined with Figure 3 This section describes the process mentioned in S203 and S204 above, whereby developers generate relevant data (such as first image ciphertext, first data ciphertext, etc.) on the equipment manufacturer's equipment or servers before the electronic device leaves the factory. The equipment manufacturer's equipment can be its electronic devices, such as computers. The equipment manufacturer's servers can include cloud servers, backend databases, etc.

[0115] For ease of explanation, the equipment or server from the equipment vendor will be referred to as the first device, and the electronic device to be programmed with data will be referred to as the second device. For example... Figure 3 As shown, the process includes:

[0116] S301, the second device generates a random root of trust and a random private key.

[0117] In some embodiments, the second device may generate a random root of trust and a random private key.

[0118] It is understandable that both the random root of trust and the random private key are randomly generated, which ensures their unpredictability and thus enhances security. Furthermore, these random root of trust and random private key can be stored in an immutable storage area within the second device, such as a one-time programmable (OTP) hardware storage unit.

[0119] In some embodiments, after receiving a first instruction from the first device, the second device may generate a random root of trust and a random private key in response to the first instruction.

[0120] S302, the second device sends a random root of trust and a random private key to the first device.

[0121] In some embodiments, the second device may send a random root of trust (an example of the first root of trust mentioned in this application) and a random private key (an example of the first private key mentioned in this application) to the first device.

[0122] It is understandable that the second device can send a random root of trust and a random private key through a secure encrypted channel to ensure security and prevent the random root of trust and the random private key from being leaked.

[0123] S303, the first device obtains the device image.

[0124] In some embodiments, after receiving a random root of trust and a random private key, the first device can obtain a device image (such as the first device image mentioned in this application).

[0125] It's understandable that developers can pre-compile device images and store them on the local storage of the first device or upload them to the cloud. The first device can then directly retrieve the compiled device image from its local storage or the cloud. Alternatively, developers can also compile device images on the first device. After receiving a random root of trust and a random private key, the first device can then obtain the pre-compiled device image.

[0126] S304, the first device performs tag calculation on the device image to obtain the image tag of the device image.

[0127] In some embodiments, the first device may perform tag calculation on the device image to obtain a picture tag for the device image (e.g., the trust tag data mentioned in this application). For example, the first device may calculate the picture tag using a hash algorithm.

[0128] It is understandable that, taking the acquisition of the first device image by the first device as an example, if the first device calculates the trust tag data corresponding to the first device image using a hash algorithm, then after the second device leaves the factory, during the secure boot process of the second device, it is also necessary to use a hash algorithm to calculate the first tag data.

[0129] In other embodiments, the first device may use a random private key to calculate a mirror label (e.g., the trust label data mentioned herein) of the device image. For example, the first device may calculate the mirror label using a message authentication algorithm, or the first device may calculate the mirror label using an Authentication Encryption Algorithm (AEAD).

[0130] It is understandable that, taking the acquisition of the first device image by the first device as an example, if the first device calculates the trust label data corresponding to the first device image through the message authentication algorithm, then after the second device leaves the factory, the second device also needs to use the message authentication algorithm to calculate the first label data during the secure boot process of the second device.

[0131] S305, the first device obtains repair data based on the aforementioned mirror tag and random root of trust using the first algorithm.

[0132] In some embodiments, the first device may obtain repair data (such as the first repair data mentioned in the embodiments of this application) based on the aforementioned mirror tag and random root of trust using a first algorithm.

[0133] As mentioned earlier, the first algorithm can be a reversible computation algorithm.

[0134] For example, taking the compilation of a first device image by a first device as an example, the random root of trust is the first root of trust mentioned in this application. The first device can obtain the first repair data based on the first tag data and the first root of trust through the first algorithm.

[0135] S306, the first device uses the aforementioned random private key to encrypt the aforementioned repair data, thereby obtaining the ciphertext of the repair data.

[0136] In some embodiments, the first device may use the aforementioned random private key to encrypt the aforementioned repair data to obtain repair data ciphertext (such as the first data ciphertext mentioned in the embodiments of this application).

[0137] For example, taking the acquisition of a first device image by a first device as an example, the first device can encrypt the first repair data using the AES algorithm to obtain the first data ciphertext.

[0138] S307, the first device burns the above-mentioned repair data ciphertext and device image to the second device.

[0139] In some embodiments, after obtaining the repaired encrypted data, the first device can burn the repaired encrypted data and the device image to the second device. For example, the process of the first device burning the repaired encrypted data and the device image to the second device may include: the first device transmitting the repaired encrypted data and the device image (e.g., a file containing the repaired encrypted data and the device image) to the production line of the second device; on the production line of the second device, workers can use specialized burning tools or equipment to burn the repaired encrypted data and the device image (e.g., a file containing the repaired encrypted data and the device image) into the second device.

[0140] It is understandable that the number of device images that the first device needs to burn can be multiple, that is, the number of device images that the first device needs to obtain can be multiple.

[0141] Taking the example that the first device needs to obtain multiple first device images, for instance, after the first device obtains multiple first device images, it can treat the multiple first device images as an image set. The image tag calculated in S304 above is the first tag data corresponding to the image set. The repair data obtained in S305 above is the first repair data corresponding to the image set. Furthermore, the repair data ciphertext obtained in S306 above is the first data ciphertext corresponding to the image set.

[0142] It is understandable that, corresponding to the case in this example, after the second device leaves the factory, during the secure boot process of the second device, the second device can verify multiple images of the first device as a set of images.

[0143] For example, after the first device obtains multiple first device images, the electronic device can execute the above-described processes S304 to S306 for any one of the multiple first device images. That is, the image tag calculated in S304 is the first tag data corresponding to the first device image, the repair data obtained in S305 is the first repair data corresponding to the first device image, and the repair data ciphertext obtained in S306 is the first data ciphertext corresponding to the first device image.

[0144] It is understandable that in this example, there can be multiple first data ciphertexts. Corresponding to this example, after the second device leaves the factory, during the secure boot process of the second device, the second device can verify each of the multiple first device images.

[0145] In some embodiments, when the device image on the second device needs to be updated / upgraded, the device manufacturer's developers can implement the device image update / upgrade process through the first device. The first device can compile a new device image (or obtain a pre-compiled new device image), calculate a new image tag for the new device image using the aforementioned random private key, and then, based on the new image tag and the aforementioned random root of trust, the first device can obtain new repair data through a first algorithm. Afterwards, the first device can use the aforementioned random private key to encrypt the new repair data, obtaining new ciphertext repair data. Then, the first device can burn the new device image and the new ciphertext repair data into the second device, completing the device image update / upgrade.

[0146] Therefore, in the secure boot method provided in this application embodiment, the device image (such as the first device image mentioned in this application) has upgradeability.

[0147] In some secure boot methods, for Figure 1 The secure boot process shown allows the electronic device to store a set of digests (referred to as a digest set) corresponding to each device image in a device image set, as well as the signature of the digest set. For example... Figure 4 As shown, the device image summary set may include summary 1, summary 2, ..., summary N, and the device image set may include device image 1, device image 2, ..., device image N.

[0148] During the secure boot process of an electronic device, after successful public key verification, the device can employ a digital signature verification algorithm to verify the signature of the digest set using the public key. If the signature verification is successful, it determines that each digest in the digest set is trustworthy. Then, the electronic device can calculate the digest of each device image in the device image set and compare the calculated digest with the digest corresponding to the same device image in the digest set. For example, if device image 1 corresponds to digest 1, the electronic device can calculate the digest of device image 1 and compare it with digest 1. If the verification is successful, the electronic device can determine that the device images in the device image set are trustworthy and continue the secure boot process.

[0149] It is understandable that in this secure boot method, a digital signature verification algorithm is used to verify the signature of the digest set stored in the device. Since the digital signature verification algorithm requires a lot of computation or occupies a lot of memory, the secure boot process of the device will consume a lot of computing resources or memory resources, making it difficult to implement the secure boot method on resource-constrained devices.

[0150] Therefore, this application provides a secure boot method.

[0151] The following is combined with Figure 5 This application introduces another secure boot method provided by its embodiments. The subject executing this method can be any of the electronic devices mentioned in the embodiments of this application.

[0152] In some embodiments, the electronic device stores a first private key, a set of objects to be authenticated, a third data ciphertext, and a first root of trust that cannot be tampered with, wherein the set of objects to be authenticated includes a first device image and a first digest of the first device image, and the first device image corresponds to the first root of trust.

[0153] like Figure 5 As shown, the method includes:

[0154] S501, in response to a secure boot request, executes the secure boot procedure for the electronic device.

[0155] In some embodiments, an electronic device may perform a secure boot process in response to a secure boot request.

[0156] As can be understood, as mentioned above, there can be multiple first device images, and therefore, there can also be multiple first digests. When an electronic device verifies multiple first device images, the multiple first device images can be treated as a set of images, and the multiple first digests can be treated as a set of digests. Then, the digest set is verified through the processes described in S502 to S504 below.

[0157] S502, during the secure startup process, performs tag calculation on the set of objects to be authenticated to obtain the third tag data corresponding to the set of objects to be authenticated, and uses the first private key to decrypt the third data ciphertext to obtain the third repair data.

[0158] In some embodiments, during the secure boot process, the electronic device can perform tag calculation on the set of objects to be authenticated to obtain third tag data corresponding to the set of objects to be authenticated, and use the first private key to decrypt the third data ciphertext to obtain third repair data.

[0159] It is understandable that electronic devices can use tag calculation methods when calculating third-party tag data. For example, tag calculation methods may include, but are not limited to, cryptographic hash algorithms, message authentication code (MAC) algorithms, and authenticated encryption with associated data (AEAD) algorithms.

[0160] In some embodiments, the third data ciphertext may be obtained by encrypting the third repair data using the first private key, wherein the third repair data is obtained by the first algorithm based on the trust label data of the first digest and the first trust root, and the trust label data of the first digest is obtained by label calculation of the first digest.

[0161] It is understandable that before an electronic device leaves the factory, developers can calculate the third repair data on the device manufacturer's equipment or server, encrypt the third repair data using the first private key to obtain the third data ciphertext, and then burn the third data ciphertext into the electronic device, so that the electronic device can store the third data ciphertext.

[0162] In some embodiments, corresponding to the case where an electronic device verifies multiple first digests as a digest set: the third tag data mentioned above can be the tag data corresponding to the digest set, and the third repair data mentioned above can correspond to the digest set, and the trust tag data mentioned above can be obtained by tag calculation on the digest set.

[0163] For example, an electronic device can calculate third-label data using a hash algorithm. The third-label data corresponding to the set of objects to be authenticated can be a digest of the digest set. Furthermore, the trust label data can also be a trust digest of the digest set; that is, the trust label data can be obtained by calculating the label of the digest set using a hash algorithm.

[0164] In some embodiments, the electronic device may also use the first private key when calculating the third tag data corresponding to the set of objects to be authenticated.

[0165] For example, an electronic device can use a first private key to calculate third tag data through a message authentication algorithm. The third tag data can be the MAC code of the digest set. Furthermore, the aforementioned trust tag data can also be the trust MAC code of the digest set.

[0166] Combination Figure 3 The process is as follows: After calculating the first digest of each first device image using the first private key, the first device can combine multiple first digests into a digest set. Using the first private key, it can then calculate the trust MAC code (i.e., tag data) of this digest set through a message authentication algorithm. Next, based on this trust MAC code and the first root of trust, the first device can obtain the third repair data using the first algorithm. Then, the first device can further encrypt the third repair data using the first private key to obtain the third data ciphertext. Finally, the third data ciphertext, multiple first device images, and multiple first digests are burned onto an electronic device.

[0167] It is understood that, in this case, the verification process S503 and subsequent S503 to S504 can be a verification process of the electronic device on the digest set (including multiple first digests), and this verification process can be predefined. The number of third data ciphertexts stored in the electronic device can be one, and this third data ciphertext corresponds to the digest set.

[0168] S503, based on the third tag data and the third repair data, obtains the third authentication data through the first algorithm.

[0169] In some embodiments, the electronic device may obtain third authentication data based on third tag data and third repair data through a first algorithm, wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm.

[0170] In some embodiments, the first algorithm is a reversible computation algorithm. For an introduction to reversible computation algorithms, please refer to the relevant description in S203 above; it will not be repeated here.

[0171] S504, if the third authentication data is consistent with the first root of trust, the first digest authentication is confirmed to be successful.

[0172] In some embodiments, the electronic device may determine that the first digest authentication was successful if the third authentication data is consistent with the first root of trust.

[0173] It is understandable that, corresponding to the case where there are multiple first device images, there are also multiple first digests. When the electronic device verifies multiple first digests as a digest set, if the third authentication data is consistent with the first root of trust, it can be determined that multiple first digests in that digest set have been successfully authenticated. If the electronic device determines that the first digest authentication is successful, it can continue the authentication process for the first device image.

[0174] In some embodiments, the electronic device may determine that the first digest authentication has failed and terminate the secure boot process if the third authentication data is inconsistent with the first root of trust.

[0175] It is understandable that if the first digest authentication fails, it means that the first digest is untrusted (e.g., the first digest has been tampered with), and the electronic device can terminate the secure boot process.

[0176] In some embodiments, the first device image is contained in the first image ciphertext. The electronic device can use a first private key to decrypt the first image ciphertext to obtain the first device image, and then perform tag calculation on the first device image to obtain fourth tag data for the first device image. If the first digest authentication is successful, the electronic device compares the fourth tag data with the first digest. If the fourth tag data and the first digest match, the electronic device loads the first device image; if the fourth tag data and the first digest do not match, the electronic device can terminate the secure boot process.

[0177] It is understandable that the fourth tag data can be the digest to be verified of the first device image. Corresponding to the case where there are multiple first device images, the number of first digests and the number of fourth tag data can also be multiple. After the electronic device uses the first private key to decrypt the ciphertext of the first image, it can obtain multiple first device images. The electronic device needs to calculate the digest to be verified for each first device image separately and compare the digest to be verified for each first device image with the first digest of that first device image.

[0178] In some embodiments, the electronic device may use a hash algorithm to compute the fourth tag data. In other embodiments, the electronic device may also use a first private key to compute the fourth tag data using an Authentication Encryption Algorithm (AEAD).

[0179] In some embodiments, the electronic device uses the first private key by using the key ladder algorithm.

[0180] It is understandable that when using the key ladder algorithm to use the first private key, the electronic device does not need to directly use the first private key as the key used to decrypt the third data ciphertext, decrypt the first mirror ciphertext, or calculate the third tag data. In this way, the privacy of the first private key can be guaranteed and the first private key can be prevented from being leaked.

[0181] In some embodiments, the electronic device further stores a first ladder key, a second ladder key, and a third ladder key. The electronic device can use the first private key to decrypt the first ladder key to obtain a first intermediate key, and then use the first intermediate key to decrypt the second ladder key to obtain a second intermediate key. The electronic device can then use the second intermediate key to decrypt the third ladder key to obtain a secure boot key. The secure boot key is the key used to decrypt the third data ciphertext, decrypt the first mirror ciphertext, or calculate the third tag data.

[0182] For example, an electronic device can use a secure boot key to decrypt third-party data ciphertext and obtain third-party repair data.

[0183] It is understandable that in the process of using the first private key, the first step key, the second step key, and the third step key are different from any other key step in other scenarios in the electronic device that use key steps. This ensures that the first private key is used securely and privately.

[0184] For example, special data can be used as the first step key. In other scenarios where step keys are used, no step key can be the same as this special data. This special data can be, for example, all zeros.

[0185] The aforementioned key ladder algorithm is implemented through a three-level decryption process. In other embodiments, the key ladder algorithm can also be implemented through a two-level decryption process; this application does not specifically limit this method.

[0186] In such Figure 5 The secure boot method shown can also employ a multi-level secure boot scheme, using a cascading approach to connect multiple secure boot levels. For details, please refer to the previous description of the multi-level secure boot scheme; it will not be repeated here.

[0187] This application also provides an electronic device, which may include a memory and a processor. The memory is used to store instructions, and the processor is used to execute the instructions stored in the memory to implement the secure boot method provided in this application.

[0188] This application also provides secure boot software, which may include a computer program or instructions that, when executed by a processor, enable the secure boot method provided in the embodiments of this application to be implemented.

[0189] In some embodiments, the memory of the electronic device may store the secure boot software mentioned in the embodiments of this application, and during the secure boot process of the electronic device, the processor of the electronic device may execute the computer program or instructions in the secure boot software.

[0190] The following is combined with Figure 6 This application describes the structure of an electronic device provided in an embodiment.

[0191] like Figure 6 As shown, the electronic device 100 may include an OTP storage unit 110, a non-volatile memory unit 120, a memory 130, an encryption / decryption engine 140, and a processor 150.

[0192] The OTP storage unit 110 may include a model key area and a public key hash area. The model key area may store a first private key 111, and the public key hash area may store a first root of trust 112.

[0193] The non-volatile memory unit 120 may store a first image ciphertext 121, a third data ciphertext 122, and metadata 123. The metadata 123 may include a first digest set 1231. It is understood that the first image ciphertext 121 may include multiple first device images, and the first digest set 1231 may include multiple first digests mentioned in this application, with each of the multiple first digests corresponding one-to-one with a multiple first device image.

[0194] The memory 130 may store secure boot software 131. The processor 150 may execute the computer program or instructions in the secure boot software 131 to implement the secure boot method provided in the embodiments of this application.

[0195] based on Figure 6 The electronic device shown below, in conjunction with Figure 7 The schematic diagram shown illustrates a secure boot method provided by an embodiment of this application. For ease of understanding, the logical XOR algorithm is used as an example of the first algorithm.

[0196] like Figure 7 As shown, processor 150 executes computer programs or instructions in secure boot software 131 to initiate the secure boot process of electronic device 100. During this secure boot process, processor 150 can use a first private key via encryption / decryption engine 140.

[0197] Specifically, the processor 150 can send a key usage request to the encryption / decryption engine 140. After receiving the key usage request, the encryption / decryption engine 140 can read the first private key 111 from the OTP storage unit 110 in response to the key usage request. The key usage request may include multiple ladder keys.

[0198] The encryption / decryption engine 140 can obtain a secure boot key based on a first private key and multiple ladder keys. The specific process can be referred to the previous section on using the first private key via the key ladder algorithm, and will not be repeated here. Then, the encryption / decryption engine 140 can use the secure boot key to decrypt the third data ciphertext 122 in the non-volatile memory unit 120 to obtain the third repair data; decrypt the first image ciphertext 121 to obtain the first device image and calculate the digest to be verified; and perform tag calculation on the first digest set 1231 in the metadata 123 to obtain the third tag data.

[0199] It is understood that the first image ciphertext 121 may include multiple first device images. Therefore, after decrypting the first image ciphertext 121, the number of first device images obtained can be multiple, and the number of digests to be verified can also be multiple, with multiple first device images corresponding one-to-one with multiple digests to be verified.

[0200] Next, processor 150 can read the third tag data and third repair data from non-volatile memory unit 120, and obtain the third authentication data through a logical XOR algorithm. Then, processor 150 can read the first root of trust 112 from OTP storage unit 110 and use the first root of trust 112 to verify the third authentication data. If the third authentication data matches the first root of trust 112, processor 150 can determine that the first digest set 1231 has been successfully authenticated. Then, processor 150 can read the digests to be verified from non-volatile memory unit 120 and compare each digest to be verified with the digests corresponding to the same first device image in the first digest set 1231. If each digest to be verified matches each digest in the first digest set 1231, processor 150 can determine that each first device image has been successfully authenticated. Then, processor 150 can load each first device image.

[0201] The secure boot method provided in this application embodiment can use a root of trust to verify the authentication data calculated by the first algorithm, thereby ensuring the trustworthiness of the device image. Furthermore, the computational complexity of the first algorithm is less than that of the digital signature verification algorithm, and comparing the authentication data with the root of trust does not require significant computational or memory resources. Thus, lightweight secure boot can be achieved, enabling implementation on resource-constrained electronic devices.

[0202] This application also provides a chip including a processor and a memory. The memory is used to store secure boot software. When the processor executes the computer program or instructions in the secure boot software, it can implement the secure boot method provided in the embodiments of this application.

[0203] This application also provides a computer-readable storage medium storing a program or instructions that, when executed by a processor, can implement the secure boot method provided in the embodiments of this application.

[0204] Various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or combinations of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0205] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor, a microcontroller, an application-specific integrated circuit, or a microprocessor.

[0206] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. The mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0207] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, compact discread-only memory (CD-ROMs), magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0208] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0209] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0210] It should be noted that in the examples and description of this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0211] Although this application has been illustrated and described with reference to certain embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

Claims

1. A secure boot method, characterized in that, The invention is applied to an electronic device, which stores a first private key, a set of objects to be authenticated, a first encrypted data, and a first root of trust that cannot be tampered with, wherein the set of objects to be authenticated includes a first device image, and the first device image corresponds to the first root of trust. The method includes: In response to a secure boot request, the secure boot process of the electronic device is executed; During the secure startup process, a tag is calculated on the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, and the first private key is used to decrypt the first data ciphertext to obtain the first repair data; Based on the first tag data and the first repair data, the first authentication data is obtained through the first algorithm, wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm. If the first authentication data is consistent with the first root of trust, the first device image is determined to be successfully authenticated, and the first device image is loaded.

2. The method according to claim 1, characterized in that, The method further includes: If the first authentication data is inconsistent with the first root of trust, the first device image authentication is determined to have failed, and the secure boot process is terminated.

3. The method according to claim 1 or 2, characterized in that, The first algorithm is a reversible computation algorithm; The first data ciphertext is obtained by encrypting the first repair data using the first private key. The first repair data is obtained by the first algorithm based on the trust label data of the first device image and the first trust root. The trust label data of the first device image is obtained by label calculation of the first device image.

4. The method according to claim 1 or 2, characterized in that, The first device image is in the first image ciphertext; the method further includes: In the process of calculating the tags of the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, the first private key is used to decrypt the first image ciphertext to obtain the first device image; or, Before performing tag calculation on the set of objects to be authenticated to obtain the first tag data corresponding to the set of objects to be authenticated, the first private key is used to decrypt the first image ciphertext to obtain the first device image.

5. The method according to claim 1, 2 or 4, characterized in that, The method of using the first private key is as follows: the first private key is used through the key ladder algorithm.

6. The method according to claim 5, characterized in that, The electronic device also stores a first-level key, a second-level key, and a third-level key; The step of using the first private key to decrypt the first encrypted data to obtain the first repaired data includes: The first private key is used to decrypt the first ladder key to obtain the first intermediate key; The second ladder key is decrypted using the first intermediate key to obtain the second intermediate key; The third ladder key is decrypted using the second intermediate key to obtain the secure startup key; Using the secure boot key, the first encrypted data is decrypted to obtain the first repaired data.

7. The method according to any one of claims 1 to 6, characterized in that, The set of objects to be authenticated also includes a second device image, the first device image includes a second root of trust, and the electronic device also stores a second private key and a second data ciphertext; After determining that the first device image authentication is successful, the method further includes: Tag calculation is performed on the set of objects to be authenticated to obtain the second tag data corresponding to the set of objects to be authenticated, and the second private key is used to decrypt the second data ciphertext to obtain the second repair data; Based on the second tag data and the second repair data, the second authentication data is obtained through the first algorithm; If the second authentication data matches the second root of trust, the second device image is determined to be successfully authenticated, and the second device image is loaded.

8. A safe boot method, characterized in that, The method is applied to an electronic device, which stores a first private key, a set of objects to be authenticated, a third data ciphertext, and a first root of trust that cannot be tampered with. The set of objects to be authenticated includes a first device image and a first digest of the first device image, and the first device image corresponds to the first root of trust. The method includes: In response to a secure boot request, the secure boot process of the electronic device is executed; During the secure startup process, a tag is calculated on the set of objects to be authenticated to obtain the third tag data corresponding to the set of objects to be authenticated. Then, the third data ciphertext is decrypted using the first private key to obtain the third repair data. Based on the third tag data and the third repair data, the third authentication data is obtained through the first algorithm, wherein the computational complexity of the first algorithm is less than that of the digital signature verification algorithm. If the third authentication data matches the first root of trust, the first digest authentication is determined to be successful.

9. The method according to claim 8, characterized in that, The method further includes: If the third authentication data is inconsistent with the first root of trust, the first digest authentication is determined to have failed, and the secure boot process is terminated.

10. The method according to claim 8 or 9, characterized in that, The first algorithm is a reversible computation algorithm; The third data ciphertext is obtained by encrypting the third repair data using the first private key. The third repair data is obtained by the first algorithm based on the trust label data of the first digest and the first trust root. The trust label data of the first digest is obtained by calculating the label of the first digest.

11. The method according to claim 8 or 9, characterized in that, The first device image is in the first image ciphertext; The method further includes: Using the first private key, the first image ciphertext is decrypted to obtain the first device image, and... Tag calculation is performed on the first device image to obtain the fourth tag data of the first device image; If the first digest authentication is successful, compare the fourth tag data with the first digest. If the fourth tag data matches the first summary, load the first device image; If the fourth tag data and the first digest are inconsistent, the secure boot process is terminated.

12. The method according to claim 8, 9 or 11, characterized in that, The method of using the first private key is as follows: the first private key is used through the key ladder algorithm.

13. The method according to claim 12, characterized in that, The electronic device also stores a first-level key, a second-level key, and a third-level key; The step of using the first private key to decrypt the third data ciphertext to obtain the third repaired data includes: The first private key is used to decrypt the first ladder key to obtain the first intermediate key; The second ladder key is decrypted using the first intermediate key to obtain the second intermediate key; The third ladder key is decrypted using the second intermediate key to obtain the secure startup key; The secure boot key is used to decrypt the third data ciphertext to obtain the third repair data.

14. An electronic device, characterized in that, include: Memory, used to store instructions; A processor for executing the instructions to implement the method of any one of claims 1 to 7, or to implement the method of any one of claims 8 to 13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7, or implement the method as described in any one of claims 8 to 13.

16. A secure boot software, characterized in that, It includes a computer program or instructions that, when executed by a processor, cause the method of any one of claims 1 to 7 or the method of any one of claims 8 to 13 to be implemented.

17. A chip, characterized in that, The chip includes a processor and a memory, the memory being used to store the secure boot software of claim 16, and when the processor executes the computer program or instructions in the secure boot software, it can implement the method of any one of claims 1 to 7 or the method of any one of claims 8 to 13.

Images