Secure boot method, hardware root of trust, computing device, and storage medium

Abstract

Provided in the present application are a secure boot method, a hardware root of trust, a computing device, and a computer-readable storage medium. The secure boot method is applied to a hardware root of trust of a computing device, and comprises: executing first code, wherein the first code comprises a first line of code that runs after the computing device is booted, and is stored in the hardware root of trust; moving second code into a memory of the hardware root of trust, wherein the second code comprises code that runs after the first code; and performing trusted computing on the second code, and then executing the second code. By means of the present application, a hardware root of trust is not easily bypassed by an attacker, thereby enabling a system to boot and operate more securely and reliably.

Description

Secure boot method, hardware trusted root, computing device, and storage medium

[0001] This application claims priority to the Chinese patent application No. 202411359119.8, filed on September 26, 2024, entitled "Secure boot method, hardware trusted root, computing device, and storage medium", the entire content of which is incorporated herein by reference. TECHNICAL FIELD

[0002] The present application relates to the technical field of trusted computing, in particular to a secure boot method, a hardware trusted root, a computing device, and a computer readable storage medium. BACKGROUND

[0003] There are trusted computing technologies in the art for ensuring the safe and reliable operation of computing devices. A hardware trusted root is an important implementation form of trusted computing technology, which is a hardware installed in a computing device for verifying whether the software and hardware in the computing device are safe and reliable. However, the existing hardware trusted root technology has the security risk of being easily attacked and bypassed. Therefore, there is an urgent need in the art for a more secure and reliable hardware trusted root technology that is not easily bypassed by attackers and can make the system startup and operation more secure and reliable. SUMMARY

[0004] To this end, the present application is committed to providing a secure boot method, a hardware trusted root, a computing device, and a computer readable storage medium, which are not easily bypassed by attackers and can make the system startup and operation more secure and reliable.

[0005] In one aspect, the present application provides a secure boot method applied to a hardware trusted root of a computing device, the method comprising: executing a first code, the first code comprising a first line of code running after the computing device starts, the first code being stored in the hardware trusted root; moving a second code to a memory of the hardware trusted root, the second code comprising a code running after the first code; performing trusted computing on the second code, and then executing the second code.

[0006] According to this aspect, the first line of code running after the computing device starts is located in the hardware trusted root, so that the first line of code and the subsequent codes can be subjected to the security verification of the hardware trusted root, thereby ensuring the security of the running software of the entire computing device from the source. In addition, the hardware trusted root has the ability to actively read and write, and can actively move the second code running after the first code to the memory of the hardware trusted root for trusted computing, thereby avoiding the security risk caused by passive moving through a business processor and preventing the hardware trusted root from being bypassed.

[0007] In a possible implementation manner of the present application, the second code comprises an upgradable first line of code of the hardware trusted root.

[0008] According to the present implementation, the first code of the hardware trusted root is non-upgradable and stored in a read-only memory, and the first line of upgradable code, i.e., the second code, is code that can be updated later. By running the second code after the first code, the first code that is non-modifiable and non-upgradable can guarantee the security of the second code, so that the hardware trusted root has both the flexibility of upgradable update and the security from the source.

[0009] In a possible implementation of the present application, the first code is stored in the hardware trusted root, including: the first code is stored in a boot read-only memory of the hardware trusted root.

[0010] According to the present implementation, storing the first code in the boot read-only memory (BootROM) can guarantee that the first code is not tampered with. The boot read-only memory can only be read, and the content therein cannot be written and modified, so that the security of the first code is fundamentally guaranteed, and the entire startup chain of the computing device can be guaranteed to be secure.

[0011] In a possible implementation of the present application, the trusted computing of the second code includes: verifying a digital signature of the second code; and / or measuring the second code.

[0012] According to the present implementation, the trusted computing of the code includes two ways, one is digital signature verification, and the other is measurement (i.e., computing a hash value for the code). By verifying the signature, it can be guaranteed that the code is not tampered with, and the trustworthiness and integrity of the code are guaranteed. By measurement, it can be verified whether the code has been changed in a remote manner, and the trustworthiness and integrity of the code can also be guaranteed. The two means can be used alternatively or simultaneously, and can be used to guarantee the security and reliability of the code, and avoid the code from being attacked or destroyed.

[0013] In a possible implementation of the present application, the method further includes: moving, by executing the second code, a third code to a memory of a business processor of the computing device, the third code including code that runs after the second code, and the hardware trusted root being mounted on a bus of the business processor; and performing, by executing the second code, trusted computing on the third code, and then the business processor executes the third code.

[0014] According to the present implementation, the third code is the initial code that starts to run on the business processor side, and the moving and trusted computing of the third code are performed by executing the second code, so that the security of the third code can be guaranteed according to the security of the second code, and thus the software running on the business processor can be established on the secure initial code.

[0015] In a possible implementation of the present application, the third code includes a first line of code that the business processor runs.

[0016] According to the present implementation, the third code includes the first line of code run by the business processor, so that the third code can be a security source of the software and hardware on the business processor side, and the software run by the business processor is ensured to be based on a secure and trusted basis, and various firmware or application software run by the business processor is prevented from being attacked or damaged.

[0017] In a possible implementation of the present application, the method further includes: moving, by executing the second code, the fourth code into the memory of the hardware trusted root, the fourth code including code run after the second code; and performing, by executing the second code, trusted computing on the fourth code, and then the hardware trusted root executes the fourth code.

[0018] According to the present implementation, the fourth code is code run by the hardware trusted root after the second code, and mainly includes hardware trusted root firmware. By moving and verifying the fourth code by executing the second code, the security of the fourth code is ensured to be based on the second code, so that the security and reliability of various firmware or software run on the hardware trusted root are ensured.

[0019] In a possible implementation of the present application, the fourth code includes hardware trusted root firmware.

[0020] According to the present implementation, the fourth code includes firmware of the hardware trusted root, so that the initial function of the hardware trusted root can be normally run, and the security of the hardware trusted root firmware is ensured to be based on the second code that has been verified to be secure, so that the security and reliability of the hardware trusted root after normal running are ensured.

[0021] In a possible implementation of the present application, the method further includes: moving, by executing the third code, the fifth code into the memory of the business processor, the fifth code including code run after the third code; and performing, by executing the third code, trusted computing on the fifth code, and then the business processor executes the fifth code.

[0022] According to the present implementation, the fifth code is code of a boot loader of the business processor, and the security of the fifth code is moved and verified by executing the third code, so that the trustworthiness of the fifth code is ensured to be based on the third code that has been verified to be secure, and the starting and boot loading process of the business processor can be smoothly performed, and the process is prevented from being tampered or damaged by an attacker.

[0023] In a possible implementation of the present application, the fifth code includes a boot loader.

[0024] According to the present implementation, the fifth code includes a Bootloader of the business processor, so that the business processor can be correctly booted and loaded before the operation of an operating system (OS), so that the whole computing device can normally enter the operating system interface, and the process is prevented from being attacked and interfered by an attacker.

[0025] In another aspect, the present application provides a hardware trusted root, which is arranged in a computing device, and includes: an execution module configured to execute first code, the first code including first lines of code that are run after the computing device is started, the first code being stored in the hardware trusted root; a migration module configured to migrate second code to a memory of the hardware trusted root, the second code including code that is run after the first code; and a trusted computing module configured to perform trusted computing on the second code and then execute the second code.

[0026] In a possible implementation of the present application, the second code includes first lines of code of the hardware trusted root that are upgradable.

[0027] In a possible implementation of the present application, the execution module is further configured to: store the first code in a boot read-only memory of the hardware trusted root.

[0028] In a possible implementation of the present application, the trusted computing module is further configured to: verify a digital signature of the second code; and / or measure the second code.

[0029] In a possible implementation of the present application, the apparatus is further configured to: migrate, by executing the second code, third code to a memory of a business processor of the computing device, the third code including code that is run after the second code, the hardware trusted root being mounted on a bus of the business processor; and perform, by executing the second code, trusted computing on the third code, and then the business processor executes the third code.

[0030] In a possible implementation of the present application, the third code includes first lines of code that are run by the business processor.

[0031] In a possible implementation of the present application, the apparatus is further configured to: migrate, by executing the second code, fourth code to the memory of the hardware trusted root, the fourth code including code that is run after the second code; and perform, by executing the second code, trusted computing on the fourth code, and then the hardware trusted root executes the fourth code.

[0032] In a possible implementation of the present application, the fourth code includes firmware of the hardware trusted root.

[0033] In a possible implementation of the present application, the apparatus is further configured to: by executing the third code, the business processor moves the fifth code to the memory of the business processor, the fifth code including code running after the third code; by executing the third code, the business processor performs trusted computing on the fifth code, and then the business processor executes the fifth code.

[0034] In a possible implementation of the present application, the fifth code includes a bootloader.

[0035] In another aspect, the present application provides a computing device, the computing device comprising a hardware trusted root configured to execute a computer program to implement the secure boot method.

[0036] In another aspect, the present application provides a computer-readable storage medium storing a computer program configured to execute the secure boot method.

[0037] In another aspect, the present application provides a computer program product comprising program code which, when the computer program product is executed by a computer, causes the computer to implement the secure boot method.

[0038] Any of the hardware trusted root, the computing device, the computer-readable storage medium or the computer program product provided above are configured to execute the secure boot method provided above, and thus can achieve the beneficial effects of the corresponding solutions of the corresponding method provided above, which will not be described herein again. BRIEF DESCRIPTION OF DRAWINGS

[0039] Hereinafter, a specific embodiment of the present application will be described in detail with reference to the accompanying drawings, in which:

[0040] FIG. 1 shows an architecture schematic diagram of a secure boot method according to an embodiment of the present application;

[0041] FIG. 2 shows a system structure schematic diagram of a hardware trusted root according to an embodiment of the present application;

[0042] FIG. 3 shows an architecture schematic diagram of a secure boot method according to an embodiment of the present application;

[0043] FIG. 4 shows a flow schematic diagram of a secure boot method according to an embodiment of the present application;

[0044] FIG. 5 shows a flow schematic diagram of a secure boot method according to an embodiment of the present application;

[0045] FIG. 6 shows a structure schematic diagram of a hardware trusted root according to an embodiment of the present application;

[0046] FIG. 7 shows a structure schematic diagram of a computing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to make the concept and thought of the present application more clear to those skilled in the art, the present application is described in detail below in combination with specific embodiments. It should be understood that the embodiments given herein are only a part of all the embodiments that the present application can have. Those skilled in the art can make improvements, modifications or replacements to some or all of the embodiments described below after reading the description of the present application, and these improvements, modifications or replacements are also included in the scope of protection of the present application.

[0048] In the present application, the terms "one", "a" and other similar words are not intended to mean that there is only one of the described things, but that the description is only directed to one of the described things, which can have one or more. In the present application, the terms "include", "comprise" and other similar words are intended to mean logical interrelation, and cannot be regarded as indicating spatial structural relation. For example, "A includes B" is intended to mean that B logically belongs to A, and does not mean that B is located inside A in space. In addition, the meaning of the terms "include", "comprise" and other similar words should be regarded as open, rather than closed. For example, "A includes B" is intended to mean that B belongs to A, but B does not necessarily constitute all of A, and A can also include C, D, E and other elements.

[0049] In the present application, the terms "first", "second" and other similar words are not intended to imply any order, quantity and importance, but are only used to distinguish different elements. In the present application, the terms "embodiment", "the present embodiment", "an embodiment", "one embodiment" do not mean that the description is only applicable to one specific embodiment, but also means that the description can also be applicable to another one or more embodiments. Those skilled in the art should understand that any description made herein for a certain embodiment can be replaced, combined or otherwise combined with the description of another one or more embodiments, and the new embodiments generated by the replacement, combination or other combination are easily thought by those skilled in the art and belong to the scope of protection of the present application.

[0050] In the embodiments of the present application, the secure boot can refer to the process of booting the computing device under the condition of ensuring the security of the boot files and the entire boot chain. The secure boot is the premise of ensuring that the computing device is not destroyed or disturbed by attackers, and only the secure boot of the computer system can realize the reliable operation and secure calculation of the computer.

[0051] In embodiments of the present application, the hardware trusted root can refer to a basic component in a computer system or electronic device that exists in hardware form and has high trustworthiness and security. For example, the hardware trusted root can ensure its own integrity and reliability through physical characteristics and security design, and is difficult to be tampered with or destroyed; can securely store critical information such as encryption keys, digital certificates, security policies, etc.; can provide a trusted basis and starting point for the entire system, and other components can establish a chain of trust based on the trustworthiness of the hardware trusted root; can verify and authorize critical operations of the system to ensure that only legitimate operations can be performed; has strong resistance to physical attacks and logical attacks, and protects stored sensitive information from being stolen or tampered with. The hardware trusted root plays an important role in ensuring system security, preventing malicious software attacks, ensuring data confidentiality and integrity, etc., and is widely used in the information security field, such as encryption systems, security chips, trusted computing platforms, etc. In some embodiments, the hardware trusted root can be specifically a hardware security module (HSM).

[0052] Currently, the security of various security solutions depends on the security of their hardware trusted roots, including the mainstream devices in various industries, which rely on hardware trusted root modules to provide various security features. These security features include the most basic security boot features to ensure the security of the entire device. However, because there was no open source standard for the hardware trusted root before, there was no standard compliance for the overall deployment of the hardware trusted root. In recent years, the first on-chip trusted root Caliptra standard has emerged in the industry, which has built some reference designs for the deployment of the hardware trusted root.

[0053] Through research and analysis, the present inventors have realized that in the open-source reference design, the hardware trusted root is hung on the master SoC (System on Chip) in a passive (slave) mode, and there are security problems in the construction of the secure boot chain. Specifically, first, Caliptra is the hardware trusted root, but the establishment of the entire boot chain needs to rely on the SoC (i.e., the business processor) side, which is equivalent to expanding the boundary of the trusted base, and the security premise constraint of the entire scheme is stronger. Caliptra is not the first-level boot code, and the premise must be trusted with the BootROM (Boot Read-Only Memory) on the SoC side, in order to trust the entire system. Such an architecture has the problem of bypassing the hardware trusted root, and the anti-bypass capability is weak. Second, Caliptra obtains the boot file image from the external flash, relies on the SoC side component to move the boot file image to the mailbox (equivalent to a cache for temporarily storing files), and at the same time, when Caliptra completes the verification of the file in the mailbox, there is a risk that the image file in the mailbox component will be maliciously replaced by the SoC side component, resulting in the problem of Caliptra executing malicious firmware. In other words, the firmware movement of the hardware trusted root Caliptra relies on the SoC component, and after Caliptra completes the verification and measurement of the firmware (or other files) in the mailbox, there is a tampering window period before the firmware is moved to the SRAM (Static Random-Access Memory) inside Caliptra for running, which has a security risk.

[0054] Therefore, in some embodiments of the present application, a hardware trusted root active deployment method is proposed, so that the first-level boot code of the entire system is located in the boot read-only memory of the hardware trusted root, rather than in the boot read-only memory of the SoC side, preventing the hardware trusted root from being bypassed. Through this active hardware trusted root deployment method, it is ensured that the first-level code of system boot is located inside the hardware trusted root, ensuring that the hardware trusted root cannot be bypassed, while actively reading the hardware trusted root firmware stored externally and performing verification and running, which is highly secure.

[0055] FIG. 1 shows a schematic diagram of the architecture of a secure boot method according to an embodiment of the present application.

[0056] As shown in FIG. 1, the hardware root of trust is arranged in the computing device as a security base of the computing device for protecting the security and reliability of the software and hardware on the computing device. During the whole startup of the computing device, the first code stored in the hardware root of trust is firstly run, and the first code includes the first line of code run after the computing device is powered on, so that the security of the software system of the computing device is controlled at the source, the security of the whole startup chain is ensured through the level-by-level trusted computing and verification, and the trust chain is constructed. After the first code is run, the hardware root of trust actively moves the mirror file of the second code from the external storage (for example, a flash memory) to the memory of the hardware root of trust, and performs the trusted computing (including digital signature verification and / or measurement) on the second code through the running of the first code. After the trusted computing is completed, the security of the second code is confirmed, and then the hardware root of trust starts to execute the second code, and the system of the whole computing device is gradually started in this way.

[0057] FIG. 2 shows a system structure diagram of the hardware root of trust according to an embodiment of the present application.

[0058] As shown in FIG. 2, in the embodiment, the hardware root of trust is a hardware module, and the specific form can be a SoC. In the embodiment, the service processor is the main processor of the computing device, and is used to execute various applications and service functions of the computing device. In the embodiment, the computing device can be a base station, a router, a server, etc. In the embodiment, the service processor can also be a SoC, in which a memory (for example, a ROM or a RAM, etc.), a processor (for example, a CPU), a bus, etc. are arranged, and the hardware root of trust is mounted on the bus of the service processor as a hardware module, thereby providing the security service and the security base for the service processor.

[0059] FIG. 3 shows an architecture diagram of a secure startup method according to an embodiment of the present application.

[0060] As shown in FIG. 3, after the whole computing device is powered on or the whole system is reset, the first code is executed. The first code includes the first line of code running after the system is started. The first level code of active deployment is located in the boot read-only memory of the hardware trusted root. The boot read-only memory actively reads the image of the second code from the external memory (for example, flash) to the memory (for example, SRAM) of the hardware trusted root, decrypts and verifies the signature of the image of the second code, and after the verification is completed, the second code is run from the boot read-only memory. The second code includes the first line of upgradeable code of the hardware trusted root, that is, the first level upgradeable code. Since the first code is stored in the read-only memory and cannot be upgraded, the earliest upgradeable code is the second code running after the first code. The second code moves the third code from the external memory to the memory of the business processor, and calculates the hash value of the third code in the moving process. After the signature verification of the third code is completed, the business processor is reset, and the third code is run. The third code includes the earliest running code of the business processor, that is, the first level boot firmware. In some embodiments, the third code includes the BIOS (Basic Input Output System). Since the third code usually has a large amount of data, it needs to be transmitted in fragments during the moving process, and the hash value is calculated once for each transmission of a fragment. After all the fragments are transmitted, the hash value of all the fragments is calculated, and then the hash value of the entire third code is calculated according to the hash value of all the fragments, which is used for measurement or signature verification. Then, the second code actively reads the fourth code (that is, the hardware trusted root firmware) from the external memory to the memory of the hardware trusted root, and completes the signature verification of the fourth code. After the verification is passed, the hardware trusted root jumps to run the hardware trusted root firmware. The third code reads the image of the fifth code (that is, the Bootloader) from the external memory to the memory of the business processor, and verifies the signature of the image of the fifth code. After the verification is passed, the business processor jumps to run the fifth code, and verifies the signature of the next level image (for example, the file image of the operating system) to start.

[0061] FIG. 4 shows a flowchart of a secure boot method according to an embodiment of the present application.

[0062] According to the present embodiment, the secure boot method is applied to the hardware trusted root of the computing device, which includes steps S410 to S430, which are described in detail below.

[0063] S410, execute the first code, the first code includes the first line of code running after the computing device is started, and the first code is stored in the hardware trusted root.

[0064] In the embodiment, the first code is the earliest running code of the whole computing device system. The first code is stored in the hardware trusted root, so that the earliest running code cannot be tampered by the malicious program possibly existing in the business processor side, and the earliest running code is protected by the hardware trusted root, thereby preventing malicious attacks from the source and ensuring security.

[0065] As an example, in order to store the first code in the hardware trusted root, the first code can be stored in the boot read-only memory of the hardware trusted root.

[0066] In the embodiment, the boot read-only memory (BootROM) is a memory in the hardware trusted root for storing unmodifiable data, and is the first running code in the boot process. When the system is powered on or reset, the program in the boot read-only memory is first executed to perform basic initialization operation on the hardware. The boot read-only memory is the starting point of the whole system trust, and the code stored in the boot read-only memory is set when the chip is manufactured, so that the boot read-only memory has high trustworthiness. The trustworthiness of the boot read-only memory is verified and expanded in the subsequent system boot and running process, and a trust chain from the hardware to the operating system and the application program is established. The first code is stored in the boot read-only memory, so that the first code is ensured to be executed first, and the first code can only be read but cannot be modified, thereby ensuring the reliability and security of the first code.

[0067] S420, moving the second code to the memory of the hardware trusted root, the second code including code running after the first code.

[0068] In the embodiment, the second code is the code running after the first code, which means that the security of the second code cannot be directly guaranteed by the hardware trusted root, and needs to be guaranteed by the execution and verification of the first code. In the embodiment, the moving of the second code is actively performed by the hardware trusted root, so that the moving of the second code does not need the participation of the business processor, and the moving process is not affected by the business processor. This moving mode benefits from the active deployment mode of the hardware trusted root. If the hardware trusted root is a passive deployment mode, the moving of the second code needs to depend on the business processor, and the malicious program in the business processor can tamper or contaminate the second code in the moving process, so that the security of the second code cannot be guaranteed.

[0069] As an example, the second code includes the first line of code of the hardware trusted root which can be upgraded.

[0070] In the present example, the second code comprises the first line of upgradeable code of the hardware trusted root, i.e., the second code is the first level upgradeable code of the hardware trusted root. When the computing device system is updated, the first code is not updatable or upgradeable because it is stored in the boot read-only memory. The second code is the code running after the first code and is not stored in the read-only memory and thus is updatable and upgradeable. The second code comprises the first line of upgradeable code, meaning that the second code is the earliest running upgradeable code of the hardware trusted root, which runs immediately after the non-upgradeable first code, thereby providing the hardware trusted root with upgradeable flexibility and scalability.

[0071] S430, performing trusted computing on the second code, and then executing the second code.

[0072] In the present embodiment, trusted computing can refer to a computing manner for verifying and evaluating the trustworthiness and security of a computing object, for providing reliable security protection for a computing environment, and preventing attacks of malicious software, data tampering, and unauthorized access. After performing trusted computing on the second code, the security and trustworthiness of the second code can be confirmed or to be confirmed, and after the computing is completed, the hardware trusted root can jump to the second code and execute it.

[0073] As an example, in order to perform trusted computing on the second code, the digital signature of the second code can be verified, and / or the second code can be measured.

[0074] In the present example, trusted computing comprises verification of the digital signature and measurement of the code. In the process of verifying the digital signature, the digital signature needs to be verified to obtain a hash value, and then the second code is hashed to obtain another hash value; the two hash values are compared, if consistent, it means that the second code has not been tampered with, if inconsistent, it means that the second code has been tampered with. In the present example, measurement refers to the calculation of a hash function on the second code to obtain a hash value, i.e., the measurement is completed; the hash value is used for later verification by a remote manner, and if the verification is passed, it means that the second code has not been tampered with.

[0075] FIG. 5 shows a flowchart of a secure boot method according to an embodiment of the present application.

[0076] According to the present embodiment, the secure boot method is applied to the hardware trusted root of the computing device, comprising steps S510 to S590, which are described in detail below.

[0077] S510, executing the first code, the first code comprising the first line of code running after the computing device is booted, the first code being stored in the hardware trusted root.

[0078] S520, migrating the second code into the memory of the hardware root of trust, the second code comprising code that runs after the first code.

[0079] S530, performing trusted computation on the second code, and then executing the second code.

[0080] For details about S510 to S530, refer to the detailed description of S410 to S430 in the embodiment of FIG. 1 above, which will not be repeated here.

[0081] S540, migrating the third code into the memory of the business processor of the computing device by executing the second code, the third code comprising code that runs after the second code, the hardware root of trust being mounted on the bus of the business processor.

[0082] In the embodiment, the business processor is a computing component of the computing device for processing specific business logic and tasks. In some embodiments, the business processor can be implemented as a system on chip (SoC) including CPU, memory, cryptography engine, bus, etc. The hardware root of trust is used to protect the business processor, and is used to provide a secure base for the business processor of the computing device. In the embodiment, the hardware root of trust is mounted on the bus of the business processor, so as to interact and communicate with various components of the business processor.

[0083] As an example, the third code comprises the first line of code that the business processor runs.

[0084] In the example, the third code comprises the first line of code that the business processor runs, i.e. the code that the business processor runs earliest. The code that the business processor runs earliest can be the underlying code that prepares for the overall start and functional running of the business processor. In some embodiments, the third code comprises the BIOS or other firmware of the computing device.

[0085] S550, performing trusted computation on the third code by executing the second code, and then the business processor executes the third code.

[0086] In the embodiment, the hardware root of trust performs trusted computation on the third code by executing the second code, i.e. performs verification of digital signature or performs measurement. After the trusted computation is completed, the business processor executes the third code.

[0087] S560, migrating the fourth code into the memory of the hardware root of trust by executing the second code, the fourth code comprising code that runs after the second code.

[0088] In this embodiment, the hardware root of trust prepares for the trusted computation of the fourth code by executing the second code to move the fourth code into the memory (e.g. SRAM) of the hardware root of trust. If the fourth code passes the trusted computation, the hardware root of trust jumps to and executes the fourth code.

[0089] As an example, the fourth code includes firmware of the hardware root of trust.

[0090] In this example, the fourth code includes firmware of the hardware root of trust. The firmware of the hardware root of trust is responsible for initializing and basic configuration of the internal hardware components of the hardware root of trust when the hardware root of trust starts, such as setting the registers of the hardware, determining the working mode, frequency and other parameters of the hardware, so that the hardware can work normally. The firmware of the hardware root of trust is a specific program embedded in the hardware device, which is between hardware and software. It is responsible for controlling the basic functions of the hardware, implementing the initialization, configuration and management of the hardware, and at the same time provides an interface for the software to interact with the hardware.

[0091] S570, performing trusted computation on the fourth code by executing the second code, and then the hardware root of trust executes the fourth code.

[0092] In this embodiment, the hardware root of trust performs trusted computation on the fourth code by executing the second code, i.e. digital signature verification or measurement, and then the hardware root of trust executes the fourth code. Since the fourth code can include firmware of the hardware root of trust. After the fourth code starts to execute, the whole startup process of the hardware root of trust ends, and the hardware root of trust enters the normal working state.

[0093] S580, by executing the third code, the business processor moves the fifth code into the memory of the business processor, and the fifth code includes code running after the third code.

[0094] In this embodiment, the third code has been moved into the memory of the business processor, and the business processor can move the fifth code into the memory of the business processor by executing the third code. The third code is the earliest code running on the business processor side. The fifth code is code running after the third code, so the security of the fifth code depends on the verification and evaluation of the hardware root of trust on the third code.

[0095] As an example, the fifth code includes a bootloader.

[0096] In this example, the fifth code includes a bootloader. The bootloader is a small program that runs before the operating system kernel, and its main role is to load the operating system kernel from the storage device into memory and hand over control to the operating system kernel, thus starting the operation of the operating system. For example, the main task of the bootloader is to load the operating system kernel from the storage device (such as hard disk, flash memory, etc.) into memory, which will read the image file of the operating system kernel according to the type and file system format of the storage device, and load it to a specific location in memory; during the loading process, the bootloader may perform some checksum and verification work to ensure the integrity and correctness of the operating system kernel. The bootloader is a program executed after the first code (stored in the BootROM) and the third code (for example, BIOS). The BootROM first performs chip-level hardware initialization and bootloader loading, and then the BIOS performs more comprehensive hardware detection and initialization, and starts the bootloader. The bootloader then performs further hardware initialization and is responsible for loading the operating system kernel.

[0097] S590, by executing the third code, the service processor performs trusted computing on the fifth code, and then the service processor executes the fifth code.

[0098] In this embodiment, the service processor performs trusted computing on the fifth code by executing the third code, that is, performs digital signature verification or measurement on the fifth code. After the calculation is completed, the service processor starts to execute the fifth code. Since the third code can be BIOS, the fifth code can be a program that the computing device system runs after BIOS, for example, Bootloader. By running the fifth code, the service processor can prepare for the next running code, which may be, for example, the operating system of the computing device.

[0099] Based on the method embodiment described in the foregoing Figure 4, the embodiment of the application further provides a hardware trusted root, and a structural diagram thereof is shown in Figure 6.

[0100] According to this embodiment, the hardware trusted root 600 is arranged in the computing device, and the hardware trusted root 600 includes an execution module 610, a moving module 620 and a trusted computing module 630. The execution module 610 is used to execute the first code, the first code includes the first line of code running after the computing device is started, and the first code is stored in the hardware trusted root. The moving module 620 is used to move the second code to the memory of the hardware trusted root, and the second code includes the code running after the first code. The trusted computing module 630 is used to perform trusted computing on the second code, and then execute the second code.

[0101] It should be noted that the hardware trusted root 600 provided by the embodiment shown in FIG. 6, when performing the method, is only an example of the division of the above functional modules, and in actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the hardware trusted root is divided into different functional modules to complete all or part of the functions described above. In addition, the hardware trusted root 600 provided by the above embodiment and the method embodiment shown in FIG. 4 respectively belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0102] FIG. 7 is a schematic diagram of the hardware structure of a computing device 700 provided by an embodiment of the present application.

[0103] Referring to FIG. 7, the computing device 700 includes a processor 710, a memory 720, a communication interface 730, a bus 740, and a hardware trusted root 750. The processor 710, the memory 720, the communication interface 730, and the hardware trusted root 750 are connected to each other through the bus 740. The processor 710, the memory 720, the communication interface 730, and the hardware trusted root 750 can also be connected in other connection manners other than the bus 740.

[0104] The memory 720 can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, hard disk, etc.

[0105] The processor 710 can be a general-purpose processor, which can be a processor that performs specific steps and / or operations by reading and executing the contents stored in the memory (such as the memory 720). For example, the general-purpose processor can be a central processing unit (CPU).

[0106] The communication interface 730 includes an input / output (I / O) interface, a physical interface, and a logical interface for realizing interconnection of devices inside the computing device 700, and an interface for realizing interconnection of the computing device 700 and other devices (for example, other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber interface, an ATM interface, and the like. The communication interface 730 can be externally connected to an input device and an output device. For example, the input device can be a microphone or a microphone array for capturing a voice input signal; can be a communication network connector for receiving a collected input signal from the cloud or other devices; and can further include, for example, a keyboard, a mouse, and the like. The output device can output various information to the outside, including determined distance information, direction information, and the like. The output device can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, and the like.

[0107] The bus 740 can be any type of communication bus for realizing interconnection of the processor 710, the memory 720, the communication interface 730, and the hardware trusted root 750, for example, a system bus.

[0108] The hardware trusted root 750 can include at least one circuit to perform all or part of the steps of the secure boot method provided by the embodiment shown in FIG. 4.

[0109] The above devices can be respectively arranged on independent chips, or at least partially or entirely arranged on the same chip. Whether to arrange the devices independently on different chips or to integrate them on one or more chips often depends on the needs of product design. The embodiments of the present application do not limit the specific implementation form of the above devices.

[0110] The computing device 700 shown in FIG. 7 is merely exemplary, and in the implementation process, the computing device 700 can further include other components, which are not listed one by one herein.

[0111] The embodiments of the present application can also be a computer readable storage medium having computer program instructions stored thereon, which, when executed by a processor, cause the processor to perform the steps of the secure boot method according to various embodiments of the present application described in the foregoing description.

[0112] The computer readable storage medium can be any combination of one or more computer readable medium(s). The computer readable medium can be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium include the following: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0113] The concepts, principles and ideas of the present application are described in detail above in conjunction with the specific embodiments (including examples and instances). It should be understood by those skilled in the art that the embodiments of the present application are not limited to the above forms, and those skilled in the art can make any possible improvements, replacements and equivalents to the steps, methods, devices and components in the above embodiments after reading the present application. These improvements, replacements and equivalents should be considered to fall within the scope of the present application. The scope of protection of the present application is only subject to the claims.

Claims

1. A method of secure booting, characterized by, A method applied to a hardware root of trust of a computing device, the method comprising: executing first code, the first code comprising first lines of code to be run after the computing device is booted, the first code being stored in the hardware root of trust; moving second code into memory of the hardware root of trust, the second code comprising code to be run after the first code; performing trusted computation on the second code, and then executing the second code.

2. The method of claim 1, wherein, the second code comprises first lines of code of the hardware root of trust that are upgradable.

3. The method of claim 1, wherein, the first code being stored in the hardware root of trust comprises: the first code being stored in a boot read-only memory of the hardware root of trust.

4. The method of claim 1, wherein, the performing trusted computation on the second code comprises: verifying a digital signature of the second code; and / or measuring the second code.

5. The method according to any one of claims 1 to 4, characterized in that, the method further comprises: moving, by the executing of the second code, third code into memory of a business processor of the computing device, the third code comprising code to be run after the second code, the hardware root of trust being mounted on a bus of the business processor; performing, by the executing of the second code, trusted computation on the third code, and then the business processor executing the third code.

6. The method of claim 5, wherein, the third code comprises first lines of code to be run by the business processor.

7. The method of claim 5, wherein, the method further comprises: moving, by the executing of the second code, fourth code into memory of the hardware root of trust, the fourth code comprising code to be run after the second code; performing, by the executing of the second code, trusted computation on the fourth code, and then the hardware root of trust executing the fourth code.

8. The method of claim 7, wherein, the fourth code comprises hardware root of trust firmware.

9. The method of claim 5, wherein, the method further comprises: moving, by the executing of the third code, fifth code into memory of the business processor, the fifth code comprising code to be run after the third code; performing, by the executing of the third code, trusted computation on the fifth code, and then the business processor executing the fifth code.

10. The method of claim 9, wherein, the fifth code comprises a bootloader.

11. A hardware trusted root, characterized by the hardware root of trust is disposed in a computing device, the hardware root of trust comprising: an executing module for executing first code, the first code comprising first lines of code to be run after the computing device is booted, the first code being stored in the hardware root of trust; a moving module for moving second code into memory of the hardware root of trust, the second code comprising code to be run after the first code; a trusted computation module for performing trusted computation on the second code, and then executing the second code.

12. A computing device, comprising: the computing device comprises a hardware root of trust for executing a computer program to implement the secure booting method of any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, the computer readable storage medium stores a computer program for executing the secure booting method of any one of claims 1 to 10.

Images