CN115618365B

CN115618365B - Method for realizing safe and reliable starting, safe architecture system and related equipment

Info

Publication number: CN115618365B
Application number: CN202211616697.6A
Authority: CN
Inventors: 郭御风; 冯彦朝; 黎媛; 刘勇鹏
Original assignee: Phytium Technology Co Ltd
Current assignee: Phytium Technology Co Ltd
Priority date: 2022-12-16
Filing date: 2022-12-16
Publication date: 2023-06-13
Anticipated expiration: 2042-12-16
Also published as: CN115618365A

Abstract

The application provides a method for realizing safe and reliable starting, a safe architecture system and related equipment, wherein the safe architecture system is loaded with a rich execution environment subsystem, a reliable execution environment subsystem and a safe element subsystem, a reliable password service module is constructed in the safe architecture system, and the reliable password service module comprises a TCM service module and a TCM password module; meanwhile, the TCM service module and/or the TCM cryptographic module are/is utilized to perform trusted measurement, trusted storage and trusted report on the firmware loaded and operated in the starting process, so that the trust chain construction of the trusted computing technology is realized. In addition, the TCM service module and the TCM cipher module are built in the same subsystem, so that the integration level of the trusted cipher service module can be improved, and the dispatching complexity of the system to the trusted cipher service module can be reduced.

Description

Method for realizing safe and reliable starting, safe architecture system and related equipment

Technical Field

The present application relates to the field of processor technologies, and in particular, to a method for implementing secure trusted booting, a secure architecture system, and related devices.

Background

With the development of technology, higher and higher requirements are put on the security of a system, so that trusted computing technologies, such as a trusted cryptography service module, appear. In the process of providing services by utilizing a trusted cryptography service module, how to improve the security and the scheduling flexibility in the system starting process is a problem to be solved at present.

Disclosure of Invention

The embodiment of the application provides a method for realizing safe and reliable starting, a safe architecture system and related equipment, which can improve the safety of a system starting process and the flexibility of scheduling.

In a first aspect, a method for implementing secure trusted initiation is provided, where the method is applied to a secure architecture system, where the secure architecture system is loaded with a rich execution environment subsystem, a trusted execution environment subsystem and a secure element subsystem, and a trusted cryptographic service module is configured in the secure architecture system, where the trusted cryptographic service module includes a TCM service module and a TCM cryptographic module, and the TCM service module and the TCM cryptographic module are configured in the same subsystem except for the rich execution environment subsystem; the method comprises the following steps: and in the starting process of the security architecture system, the TCM service module and/or the TCM cryptographic module are/is utilized to measure the firmware running in the starting process, and the measurement result is recorded.

The trusted cryptography service module can comprise a TCM service module and a TCM cryptography module, and the TCM service module and the TCM cryptography module are separated, so that the scheduling flexibility is improved.

In addition, the embodiment of the application proposes that the trusted cryptography service module may be integrated in the secure architecture system, or that the trusted cryptography service module may be constructed in the secure architecture system in the embodiment of the application. Because the trusted cryptography service module is integrated in the security architecture system, the trusted cryptography service module not only can actively measure the firmware in the process of starting the chip, but also can realize the trusted starting of the chip, and ensure the security of the system.

The TCM service module and the TCM cipher module are built in the same subsystem, so that the integration level of the trusted cipher service module can be improved, and the dispatching complexity of the system to the trusted cipher service module can be reduced. For example, the TCM service module and the TCM cryptographic module are built into the trusted execution environment subsystem, or the TCM service module and the TCM cryptographic module are built into the secure element subsystem.

The trusted execution environment subsystem is applied with a software and hardware security architecture, such as Trustzone, SGX and other technologies, and can provide additional security guarantee of the execution environment for the TCM service module and the TCM cryptographic module arranged in the trusted execution environment subsystem.

The secure element subsystem has trusted and secure storage resources and an operational environment, and can provide additional security of an execution environment for a TCM service module and a TCM cryptographic module arranged therein.

In some implementations, the measuring firmware running during the boot process using the TCM service module and/or the TCM cryptographic module includes: and measuring one or more of the following firmware by using the TCM service module and/or the TCM cipher module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

By measuring one or more of BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware in the starting process, the safety of the starting process can be ensured.

In some implementations, the TCM service module and the TCM cryptographic module are built into the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem run on a first processor core, the utilizing the TCM service module and/or the TCM cryptographic module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include: running the BL2 firmware and initializing a processor core of the security architecture system; performing self-checking on hardware resources of the first processor core and the TCM cryptographic module; loading and operating the TCM cryptographic module and the TCM service module under the condition that the self-check is passed; and measuring one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by using the TCM cryptographic module and the TCM service module.

In the measuring process, the hardware resource of the TCM cryptographic module is subjected to self-checking, so that the reliability of hardware required by measurement and the safety of the measuring process are guaranteed. By loading the TCM service module after BL2 firmware is operated, the complexity of the starting flow can be reduced on the premise of ensuring safe starting. Self-checking of hardware resources of the TCM cryptographic module may be implemented by BL1 firmware. The Self-checking program of the TCM can be a Self-Task program built in the TCM, and the security and the credibility of other resources except hardware resources of the TCM are ensured by running the Self-checking program.

In some implementations, the method further comprises: and carrying out signature authentication on the BL31 firmware by utilizing the BL2 firmware.

And the BL31 firmware is signed and authenticated by the BL2 firmware, so that the safety of the starting process is guaranteed.

In some implementations, the secure architecture system has a trusted root built-in, and before the running the BL2 firmware, the method further includes: executing the trusted root; and carrying out signature authentication on the BL2 firmware by utilizing the trusted root.

The BL2 firmware is signed and authenticated through the trusted root, so that the running safety can be ensured, and the system safety is improved.

In some implementations, the TCM service module and the TCM cryptographic module are built into the secure element subsystem, the secure element subsystem is running on a second processor core, the trusted execution environment subsystem is running on a third processor core, and the use of the TCM service module and/or the TCM cryptographic module measures one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include: loading and running firmware in the secure element subsystem to initialize the secure element subsystem; initializing the second processor core and the third processor core; loading and operating the TCM service module and the TCM cryptographic module in the secure element subsystem; and measuring one or more of the following firmware by using the TCM service module and the TCM password module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

By setting the special core for the secure element subsystem, the secure element subsystem can independently operate independent of the trusted execution environment subsystem, and a TCM service module and a TCM password module in the secure element subsystem can be directly loaded in the secure element subsystem, so that measurement of BL firmware is realized, and the security of the starting process is improved.

In some implementations, the utilizing the TCM service module and the TCM cryptographic module metrics one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include: measuring the BL2 firmware by utilizing the TCM service module and the TCM cipher module; running the BL2 firmware and initializing a processor core of the security architecture system; and measuring one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by using the TCM service module and the TCM cryptographic module.

After the BL2 firmware is signed and authenticated, the TCM service module is loaded and operated, and the TCM service module and/or the TCM cryptographic module can be used for carrying out step-by-step credibility measurement on BL33 firmware, system kernel and the like. This is advantageous for improving the security of the system software during the start-up process.

The TCM module of the embodiment of the application multiplexes hardware resources in the processor security architecture system in a built-in mode. Compared with the system architecture with an independent external TCM module, on one hand, the system architecture effectively improves the data communication efficiency of the TCM module measurement service and can reduce the hardware cost; on the other hand, by utilizing a built-in TCM module and multiplexing password hardware resources, one or more of BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware are measured, so that software progressive measurement in a secure boot technology and software trusted measurement in a trusted computing technology are realized in a converged manner, and the security of the secure architecture system in the boot process is effectively improved.

In some implementations, the secure architecture system has a trusted root built-in, and before the loading and running of firmware in the secure element subsystem, the method further includes: signature authentication is carried out on firmware in the secure element subsystem through the trusted root; the loading and running firmware in the secure element subsystem includes: in the event that the firmware authentication in the secure element subsystem passes, loading and running the firmware in the secure element subsystem.

The trusted root performs signature authentication on the SE firmware, so that the integrity and the correctness of the SE firmware can be ensured, and a trust chain of the firmware is constructed, thereby effectively improving the security of the system.

In some implementations, the secure architecture system is disposed in a computing device, the method further comprising: measuring a program of an operating system kernel of the computing device by using the TCM service module and the TCM cryptographic module; and loading the kernel of the operating system to initialize hardware resources of the computing device and guide the operating system, thereby completing the starting of the computing device.

After the firmware measurement in the starting process is completed, the program of the kernel of the operating system is measured, so that the starting safety of the computing equipment can be ensured.

In a second aspect, a secure architecture system is provided, where the secure architecture system is loaded with a rich execution environment subsystem, a trusted execution environment subsystem and a secure element subsystem, and a trusted cryptography service module is configured in the secure architecture system, and the trusted cryptography service module includes a TCM service module and a TCM cryptography module, and the TCM service module and the TCM cryptography module are configured in the same subsystem except for the rich execution environment subsystem; the security architecture system is configured to: and in the starting process of the security architecture system, the TCM service module and/or the TCM cryptographic module are/is utilized to measure the firmware running in the starting process, and the measurement result is recorded.

In some implementations, the TCM service module and the TCM cryptographic module are built into the trusted execution environment subsystem, or the TCM service module and the TCM cryptographic module are built into the secure element subsystem.

In some implementations, the security architecture system is configured to: and measuring one or more of the following firmware by using the TCM service module and/or the TCM cipher module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

In some implementations, the TCM service module and the TCM cryptographic module are built into the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem are running on a first processor core, the secure architecture system configured to: running the BL2 firmware and initializing a processor core of the security architecture system; performing self-checking on hardware resources of the first processor core and the TCM cryptographic module; loading and operating the TCM service module and the TCM cipher module under the condition that the self-check is passed; and measuring one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by using the TCM cryptographic module and the TCM service module.

In some implementations, the security architecture system is configured to: and carrying out signature authentication on the BL31 firmware by utilizing the BL2 firmware.

In some implementations, the secure architecture system has a trusted root built-in, the secure architecture system configured to: executing the root of trust prior to the running the BL2 firmware; and carrying out signature authentication on the BL2 firmware by utilizing the trusted root.

In some implementations, the TCM service module and the TCM cryptographic module are built into the secure element subsystem, the secure element subsystem running on a second processor core, the trusted execution environment subsystem running on a third processor core, the secure architecture system configured to: loading and running firmware in the secure element subsystem to initialize the secure element subsystem; initializing the second processor core and the third processor core; loading and operating the TCM service module and the TCM cryptographic module in the secure element subsystem; and measuring one or more of the following firmware by using the TCM service module and the TCM password module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

In some implementations, the security architecture system is configured to: measuring the BL2 firmware by utilizing the TCM service module and the TCM cipher module; running the BL2 firmware and initializing a processor core of the security architecture system; and measuring one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by using the TCM service module and the TCM cryptographic module.

In some implementations, the secure architecture system has a trusted root built-in, the secure architecture system configured to:

signature authentication is carried out on the firmware in the secure element subsystem through the trusted root before the firmware in the secure element subsystem is loaded and operated; in the event that the firmware authentication in the secure element subsystem passes, loading and running the firmware in the secure element subsystem.

In some implementations, the secure architecture system is disposed in a computing device, the secure architecture system configured to: measuring a program of an operating system kernel of the computing device by using the TCM service module and the TCM cryptographic module; and loading the kernel of the operating system to initialize hardware resources of the computing device and guide the operating system, thereby completing the starting of the computing device.

In a third aspect, there is provided a computing device comprising the security architecture system of the second aspect or any implementation of the second aspect.

In a fourth aspect, a computer-readable storage medium is provided, on which a program is stored, the program causing a computer to perform the method according to the first aspect or any implementation manner of the first aspect.

Drawings

Fig. 1 is a schematic structural diagram of a security architecture system in the related art.

Fig. 2 is a schematic block diagram of a homogeneous three-level architecture.

Fig. 3 is a schematic block diagram of a heterogeneous three-stage architecture.

Fig. 4 is a schematic structural diagram of a security architecture system according to an embodiment of the present application.

Fig. 5 is a schematic flow chart of a method for implementing secure trusted booting according to an embodiment of the present application.

FIG. 6 is a schematic diagram of a startup process of a computing device.

Fig. 7 is a schematic structural diagram of a system software stack according to an embodiment of the present application.

Fig. 8 is a schematic flow chart of a starting method provided in an embodiment of the present application.

Fig. 9 is a schematic flow chart of another starting method provided in an embodiment of the present application.

Fig. 10 is a schematic structural diagram of another system software stack according to an embodiment of the present application.

Fig. 11 is a schematic flow chart of another starting method provided in an embodiment of the present application.

Fig. 12 is a schematic flow chart of another starting method provided in an embodiment of the present application.

Fig. 13 is a schematic diagram of a computing device provided in an embodiment of the present application.

Fig. 14 is a schematic block diagram of an apparatus for implementing secure trusted booting according to an embodiment of the present application.

Detailed Description

The following description of the technical solutions in the embodiments of the present application will be made clearly and completely with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments.

As security requirements for computing devices increase, more and more security technologies are gradually applied to various computing devices, where security chip technology has become an important technical means of security architecture systems in computing devices, and security element subsystems implementing security chip technology have become a key part of many security architecture systems. If the security and stability of the data of the computing system cannot be guaranteed, the computing environment becomes very fragile, and important resources are easily revealed due to factors such as software attack or physical attack, for example, important data associated with payment, and the like.

In general, a secure architecture system of a computing device may include three types of subsystems, a rich execution environment (rich execution environment, REE) subsystem, a trusted execution environment (trusted execution environment, TEE) subsystem, and a Secure Element (SE) subsystem, respectively. The safety element subsystem is fused with a typical safety computing processor architecture through a safety chip technology, and constructs a safety enhanced three-level safety computing architecture of the processor together, so that the safety of important resources is ensured. The security protection levels of the REE subsystem, the TEE subsystem and the SE subsystem are sequentially increased. That is, the SE subsystem has the highest security level, the TEE subsystem has the next highest security level, and the re subsystem has the lowest security level.

Fig. 1 shows a schematic structural diagram of a security architecture system. The secure architecture system 100 includes a REE subsystem, a TEE subsystem, and a SE subsystem. In general, applications running in the REE subsystem may be referred to as normal applications (client application, CA), which are less secure and vulnerable to attack. The application in fig. 1 represents CA. Applications running in the TEE subsystem are generally referred to as trusted applications (trusted application, TA) that are more secure than CA and can be used to implement data-sensitive business scenarios, such as cardholder information and identity verification in payment business. Applications running in the SE subsystem may be referred to as secure trusted applications, which are more secure than the CA and TA. Because the SE subsystem has the highest security level, the SE subsystem is generally used to perform computation and storage of important resources, such as information including a trusted root. The SE subsystem can ensure the security of important resources in the SE subsystem by means of authority verification, cryptographic technology and the like. In the security architecture system, the three subsystems are mutually matched, so that different security protection requirements can be flexibly provided for the calculation data.

The REE subsystem may include a general Operating System (OS) or Virtual Machine (VM) running on a general-purpose embedded processor, in which an application is installed. Application 1 to application n are shown in fig. 1, where n is a positive integer. For example, the application may be a program related to a payment scenario in which basic services such as browsing goods, selecting goods, submitting orders, etc. are implemented. The REE subsystem may include a unified extensible firmware interface (unified extensible firmware interface, UEFI), a universal Boot strap (universal Boot loader, U-Boot). Although many security measures such as device access control, device data encryption mechanisms, isolation mechanisms at application runtime, access control based on permission verification, etc. can be implemented in the REE subsystem, security of important data in the application cannot be guaranteed.

The TEE subsystem may include a general-purpose security kernel, a trusted user interface (trusted user interface, TUI), and a TEE OS, which are stand-alone operating environments that run outside of a general operating system. The TUI may provide an interface with secure interaction capability for input or output with a user for trusted applications within a trusted execution environment, e.g., in a payment scenario, the TUI may be used for display of transaction information and personal identification number (personal identification number, PIN) input, etc. The TEE may provide security services to, for example, the REE subsystem and be isolated from the REE subsystem, i.e., the REE subsystem and applications thereon cannot directly access hardware and software resources of the TEE subsystem. For example, trusted applications, such as trusted application 1 through trusted application p shown in fig. 1, may be executed in the TEE subsystem, where p is a positive integer, and the trusted application is used to provide a trusted operating environment for the re subsystem, and further, through confidentiality, integrity protection, and control of data access rights, end-to-end security is ensured. Further, the TEE subsystem may run in parallel with the REE subsystem. The TEE subsystem may interact with the REE subsystem, for example, through a secure application programming interface (application programming interface, API).

The TEE subsystem provides a higher level of security of the operating environment than the REE subsystem, but fails to provide a hardware isolation level of secure key storage and password-related operating environment. Generally, the TEE subsystem may provide a lot of APIs for the REE subsystem to call the resources of the TEE subsystem, and the more APIs provided by the TEE subsystem for performing services, the greater the risk faced by the TEE subsystem, the more it is difficult to ensure that the APIs do not have security hidden hazards, such as security holes, and thus security risks exist in the resources, such as keys, in the TEE subsystem. Furthermore, multiple TAs will be operated in the TEE subsystem, and the TAs are completely dependent on the isolation mechanism provided by the TEE operating system, and no hardware level isolation exists, so that if a security hole exists in the TA itself or the TA itself actively accesses a key or a root key corresponding to other TAs, a great security risk exists in sensitive resources such as a key.

Because of the above problems with TEE subsystems, it is proposed to build secure trusted storage resources and computing environments based on SE. Generally, a software system in the SE subsystem is relatively simple and comprises fewer hardware components, so that physical protection and implementation of security are easy to establish, and the security intensity of the SE subsystem is improved to serve a security system with higher security requirements. Wherein security applications, such as security application 1 through security application m shown in fig. 1, where m is a positive integer, may be executed in the SE subsystem.

The security architecture system in the embodiment of the application can be a homogeneous three-level architecture or a heterogeneous three-level architecture. These two architectures are described separately below.

Fig. 2 is a schematic diagram of a homogeneous three-level architecture according to an embodiment of the present application. In a homogeneous three-level architecture, both the trusted execution environment subsystem and the secure element subsystem operate on the same security level processor core (e.g., processor security core). Assuming that the trusted execution environment subsystem and the secure element subsystem are running on the first processor core, the first processor core is capable of handling both programs or services in the trusted execution environment subsystem and programs or services in the secure element subsystem.

In the architecture shown in fig. 2, an application core (AP-Cores) may be included in the rich execution environment subsystem, a Secure core (Secure-Cores) may be included in the trusted execution environment subsystem, and a cryptographic engine (or cryptographic service module), a Secure storage medium, and a SE's service interface (e.g., secure dynamic random access memory (dynamic random access memory, DRAM) interface) may be included in the Secure element subsystem. The security engine may provide resources such as cryptographic operations.

Fig. 3 is a schematic diagram of a heterogeneous three-stage architecture according to an embodiment of the present application. In a heterogeneous three-level architecture, the trusted execution environment subsystem and the secure element subsystem run on different processor cores, in other words, the secure element subsystem has separate processor cores. Assuming that the trusted execution environment subsystem is running on a second processor core and the secure element subsystem is running on a third processor core, the second processor core is responsible for handling programs or services in the trusted execution environment subsystem and the third processor core is responsible for handling programs or services in the secure element subsystem.

In the architecture shown in fig. 3, an application core (AP-Cores) may be included in the rich execution environment subsystem, a Secure core (Secure-Cores) may be included in the trusted execution environment subsystem, and an SE-specific core, a cryptographic engine, a Secure storage medium, and a SE's service interface (e.g., secure DRAM interface) may be included in the Secure element subsystem.

In the heterogeneous three-level architecture, the secure element subsystem has a special core, so the secure element subsystem has the advantages of graphics completeness and a custom hardware secure execution unit. The task execution in the secure element subsystem is completely independent and is not influenced by the execution environment of other subsystems, so that higher security and higher execution efficiency can be provided.

With the development of technology, in wider network environments, there is a growing demand for security of systems, such as where any operation or process behavior of remote entities is expected to be predictable or controllable, and trusted computing technology is emerging. One of the core goals of trust is to ensure the integrity of the system and the application (or software), thereby ensuring that the system or application operates in a trusted state as desired by the design goals. Trust is the basis for security, and any security scheme or security policy can further ensure security design goals only if operated in an untampered environment. In general, incorporating trusted verification in a system and application can reduce the likelihood of attack from using unknown or tampered systems/software.

Trusted computing (Trusted Computing, TC) is a technology that is driven and developed by trusted computing group (Trusted Computing Group, TCG). One of the core goals of trust is to ensure the integrity of the system and applications, thereby determining that the system or software is operating in a trusted state as desired by the design goals. Adding trusted verification to a system and application can reduce the likelihood of attack from using unknown or tampered systems/software. By taking the trusted example of a personal computer (personal computer, PC), in popular terms, the integrity and the correctness of a basic input/output system (basic input output system, BIOS) and an operating system are detected when each PC is started, so that the hardware configuration and the operating system are not tampered when a user uses the PC, and the security measures and the settings of all the systems are not bypassed; after the application is started, all applications such as social software, music software, video software and the like can be monitored in real time, and if the application is found to be tampered, loss stopping measures are immediately taken.

The trust is realized mainly by the technical means of measurement and verification. The measurement is to collect the detected state of the software or the system, and the verification is to compare the measurement result with the reference value to see whether the measurement result is consistent or not, if the measurement result is consistent with the reference value, the verification is passed, and if the measurement result is inconsistent with the reference value, the verification is failed. Trusted computing ensures trust by algorithms and keys embedded in trusted hardware by the chip vendor, and by the integrated dedicated microcontroller measuring and validating the software stack. There are three main types of trusted computing standards currently prevailing in the industry, based on the classification of the security chip and the trusted software base (Trusted Software Stack) running thereon: a trusted platform module (Trusted Platform Module, TPM), a trusted cryptography module (Trusted Cryptography Module, TCM), and a trusted platform control module (Trusted Platform Control Module, TPCM).

Commercially available, TPMs and TCM are typically built into computing devices as a trusted source for the computing devices. The specification of the TPM chip is formulated by the TCG. The TCM is a domestic trusted computing technology, the function of which corresponds to that of the TPM, and the difference is that the cryptographic technology in the TCM is independently researched and developed by China, so that the national information security is guaranteed.

TPCM is a trusted standard (currently a group standard in China) based on the idea of localization. The TPCM makes major changes to the hardware and trusted software stack (trusted software stack, TSS) architecture relative to the TPM and trusted cryptography service modules. The TPCM has the greatest advantage of being capable of taking an active measure and using a cryptographic algorithm which is independently developed in China. But TPCM has not been commercially scaled and product matured on a computing host.

The embodiment of the application is mainly introduced for the trusted cryptography service module.

The functions that the trusted cryptography service module can implement may include the following three. 1. And taking the trusted measurement root as a starting point, calculating the integrity measurement value of the system platform, establishing a trust chain of the computer system platform, and ensuring the credibility of the system platform. 2. Because the trusted report root can identify the trustworthiness of the platform identity and has uniqueness, platform identity certification and integrity reporting can be realized based on the trusted report root. 3. Based on the trusted storage root, the functions of key management and platform data security protection are realized, and corresponding password service is provided.

The trusted cryptography service module in the related art is usually located outside a chip (or a security architecture system), and is called by host software to play a role in a passive hooking manner, and only called by the host software to play a role, the security capability of the trusted cryptography service module is completely dependent on the security of the host system, and the active defensive capability of the computer system cannot be substantially improved. Once the host is controlled by an attacker, the role of the trusted cryptography service module is not played. Therefore, the trusted cryptography service module set in an externally hung mode cannot effectively improve the security of the computer system.

In addition, because the trusted cryptography service module is located outside the chip and only is called by the host software to play a role, the trusted cryptography service module can only perform passive measurement on the firmware and executable program of the chip and cannot perform active measurement.

In addition, since the trusted cryptography service module can only function after the host is started, the host software can only call the trusted service cryptography module, and therefore, the trusted cryptography service module cannot measure the firmware in the process of starting the chip, and the security of the system can be affected.

Based on the above, the embodiment of the application provides a method for realizing safe and reliable starting, which not only can actively measure the firmware in the process of starting the chip, but also can realize the reliable starting of the chip and ensure the safety of the system.

In general, the implementation of the secure trusted boot method presented in this application covers the following scenario.

In one embodiment, the firmware is verified step by using a hardware trusted root technology to implement a trust chain construction of a secure boot technology, wherein the firmware may include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

In general, the BL1 firmware can be arranged in a hardware trusted root, has the characteristic of non-tampering, is a first code section of power-on starting, and is a source of all trust chains. In this case, to implement the secure boot technique, a hardware root of trust needs to be executed first, and then one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware is subjected to step-by-step signature verification. Illustratively, the progressive signature verification is embodied in: and carrying out signature verification on the BL2 firmware through a hardware trusted root, then carrying out signature verification on the BL31 firmware through the BL2 firmware, and carrying out signature verification on the BL32 and/or BL33 firmware through the BL31 firmware.

In one embodiment, on the basis of realizing the above-mentioned safe starting technology, the TCM service module and/or the TCM cryptographic module are further utilized to perform trusted measurement, trusted storage and trusted report on the firmware loaded and operated in the starting process, so as to realize the trust chain construction of the trusted computing technology.

The implementation flow can comprise the following steps: and powering up, executing a hardware trusted root, and then performing step-by-step signature verification on one or more of BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware. Illustratively, the step-by-step is embodied in: carrying out signature verification on BL2 firmware through a hardware trusted root, and then carrying out signature verification on BL31 firmware, BL32 and/or BL33 firmware one by one through BL2 firmware; or, the BL31 firmware is subjected to signature verification through the BL2 firmware, and then the BL33 firmware is subjected to signature verification through the BL31 firmware; or, the BL31 firmware is subjected to signature verification through the BL2 firmware, and then the BL32 firmware and the BL33 firmware are subjected to signature verification one by one through the BL31 firmware; meanwhile, the TCM hardware self-tests, and a TCM service module and/or a TCM cryptographic module are loaded and operated under the condition that the self-tests are successful, and at least one of BL31 firmware, BL32 firmware and BL33 firmware is measured by the TCM service module and/or the TCM cryptographic module under the condition that the loading is successful, for example, BL31 firmware, BL32 firmware and BL33 firmware are measured one by the TCM service module and/or the TCM cryptographic module; alternatively, the TCM service module and/or the TCM cryptographic module are used to measure the BL31 firmware and the BL33 firmware one by one; if the measurement is successful, the secure/trusted boot is completed, and if the measurement is failed, the secure/trusted boot fails. In the following embodiments, the related implementations will be specifically described.

Further, the method of the embodiment of the application can be applied to a secure architecture system, and the secure architecture system can be provided with a rich execution environment subsystem, a trusted execution environment subsystem and a secure element subsystem. The security architecture system may be a homogeneous three-level architecture as described above, or may be a heterogeneous three-level architecture. The description of the rich execution environment subsystem, the trusted execution environment subsystem, and the secure element subsystem may be referred to above, and will not be repeated here for brevity.

The security architecture system of embodiments of the present application may be a chip, such as a system-on-a-chip (SOC) chip. In some embodiments, the term "secure architecture system" and the term "chip" may be used interchangeably, depending on the context.

The trusted cryptography service module in the embodiment of the application can comprise a TCM cryptography module and a TCM service module. The TCM service module and the TCM cipher module are combined to form a core technology or an important component of the trusted computing cipher support service platform. The TCM cryptographic module and the TCM service module can provide services for the trusted computing platform together, and can support the platform security functions such as platform integrity, platform identity credibility, platform data security protection and the like.

The TCM cryptographic module can be an independent module with a protected storage space and is a necessary key basic component of a trusted computing cryptographic support platform. The TCM cryptographic module may include trusted computing resources, that is, the TCM cryptographic module is capable of providing a trusted base computing resource for the trusted cryptographic service module. For example, the TCM cryptographic module may provide computing resources such as cryptographic operations, true random number generators (true random number generator, TRNG), secure storage, etc. for trusted cryptographic service modules. The only interface that the TCM cryptographic module interacts with the system is a set of standard interfaces that are the China standards developed by the China national code administration in combination with the national information technology (information technology, IT) enterprises.

The TCM service module may include a service interface, in other words, the TCM service module may provide a service interface for a user (or application) to invoke resources in the TCM cryptographic module. In some embodiments, the TCM service module may invoke the TCM cryptographic module through a service interface to provide security services such as trusted metrics, trusted reports, trusted storage, etc. to the application. In other embodiments, the TCM service module may also manage the resources of the TCM cryptographic module, or the TCM service module may also hide the complex function commands in the TCM cryptographic module, thereby reducing the complexity of using the TCM cryptographic module by the user. The national information technology IT enterprise is also put forward the interface standard of the TCM service module by the national password administration. And the TCM service module is specifically designed, and different manufacturers have different design and implementation respectively.

The embodiment of the application does not specifically limit the construction modes of the TCM service module and the TCM cryptographic module in the security architecture system. As one example, as shown in fig. 4, the TCM service module and the TCM cryptographic module may be built in the same subsystem except for the rich execution environment subsystem. The TCM service module and the TCM cipher module are built in the same subsystem, so that the integration level of the trusted cipher service module can be improved, and the complexity of calling the trusted cipher service module by the system can be reduced.

In some embodiments, the TCM service module and TCM cryptographic module may be built into a trusted execution environment subsystem. The trusted execution environment subsystem is applied with software and hardware security architecture, such as Trustzone, software protection extension (software guard extensions, SGX) and other technologies, and can provide additional execution environment security for the TCM service module and the TCM cryptographic module arranged therein. In other embodiments, the TCM service module and TCM cryptographic module may be built into the secure element subsystem. The secure element subsystem comprises the operation hardware resource of the TCM cryptographic module and has the characteristics of high performance, low power consumption, quick response and the like. In addition, the secure element subsystem has a trusted and secure storage resource and an operational environment, and can provide additional security of an execution environment for the TCM service module and the TCM cryptographic module arranged therein.

Because the trusted execution environment subsystem and the secure element subsystem both have secure operation environments, the TCM service module and the TCM cipher module are built in the two subsystems, and the requirements of the TCM service module and the TCM cipher module on security can be met.

Because the TCM service module and the TCM cryptographic module are built in the security architecture system, the TCM service module and the TCM cryptographic module can actively measure without depending on the invocation of a host. In addition, because the TCM service module and the TCM cryptographic module are built in the security architecture system, the TCM service module and the TCM cryptographic module can measure firmware in the starting process of the security architecture system, thereby being beneficial to ensuring the security of the system. For example, from an on-chip trusted root, all codes introduced in the starting process can be checked step by step, so that a complete trust chain is realized, and safe starting is realized.

Referring to fig. 5, the method of the embodiment of the present application may include step S510.

Step S510: in the starting process of the security architecture system, the TCM service module and/or the TCM cryptographic module are/is utilized to measure the firmware in the starting process, and the measurement result is recorded. The metrics are used to enable trusted enablement of the secure architecture system. The firmware during the boot-up process may include one or more of the following: BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

Metrics in embodiments of the present application may include trusted metrics, trusted storage, and trusted reporting of system-loaded firmware/software using TCM modules, thereby enabling trust chain construction of trusted computing technology.

Embodiments of the present application may store the metrology results, such as in a platform control register (platform control register, PCR). And after networking, remotely verifying the measurement result in the PCR, thereby realizing trusted starting. Because the trusted cryptography service module has the function of trusted storage, the measurement result can be stored in a trusted way by using the trusted cryptography service module, and the credibility of the measurement result can be ensured.

Of course, since the measurement results need to be remotely verified, the system start-up is continued during the start-up process, regardless of the trusted measurement results.

Trusted boots also typically require that a trusted root for the metrics be established in dependence on the secure boot to ensure that the metrics recorded into the PCR are trusted.

The embodiment of the application considers both secure start and trusted start, and can provide a more complete measurement method for the integrity, digital signature, firmware version and the like of the firmware loaded in the power-on process. As described above, in the process of secure boot, the firmware is verified step by using the hardware trusted root technology, so as to implement the trust chain construction of the secure boot technology. On the basis of realizing the safe starting technology, the TCM service module and/or the TCM cryptographic module are further utilized to perform trusted measurement, trusted storage and trusted report on the firmware loaded and operated in the starting process, so that the trust chain construction of the trusted computing technology is realized.

Generally, hardware resources in a secure architecture system (such as ARM V8) are typically divided into two parts, one being the secure world (secure world) and one being the normal world (normal world), where the normal world may also be referred to as the non-secure world, as shown in fig. 6. When the processor is running in the secure world, it has access to all hardware resources. However, when a processor is running in the ordinary world, it can only access resources in the ordinary world. Briefly, applications and operating systems in the general world are traditional, while applications and operating systems in the secure world are of special use (e.g., digital signature management, authentication). The two worlds communicate via a shared memory.

FIG. 6 illustrates a schematic diagram of a startup process of a computing device. Numbers on the arrows indicate the start-up sequence. Starting from Boot loader (BL 1) firmware in Boot read-only memory (ROM), starting according to the sequence of BL 1- & gt BL 2- & gt BL 31- & gt BL 32- & gt BL 33- & gt OS, and starting up an Operating System (OS) interface to finish starting. Of course, the computing device may also be started according to other starting sequences, which are not specifically limited in the embodiments of the present application.

As shown in fig. 6, the secure world includes firmware such as Boot ROM (diskless Boot ROM interface), platform initialization firmware (platform initialization firmwre), EL3 runtime firmware (BL 31), and open portable TEE (OP-TEE) (e.g., BL 32). The OP-TEE is an open source project, and a trusted execution software and hardware environment is completely realized, and in the environment, the information security can be greatly enhanced. The common world includes firmware that is: U-Boot/UEFI firmware (BL 33), kernel (kernel) of the operating system OS). The BL33 firmware may be basic input output system (basic input output system, BIOS) firmware. In the general world, the execution authority of EL0, EL1, EL2, EL3 increases in order. Wherein the UEFI firmware is configured to run at the EL2 level of the general world and the OP-TEE is configured to run at the EL1 level of the secure world. The OP-TEE has completed startup upon entering the UEFI (BL 33) startup, and communication between the UEFI and OP-TEE may be through a security monitoring call (secure monitor call, SMC) interface. Therefore, when the UEFI is started, when the integrity and the security of the image file are verified, certain functions can be realized by calling the OP-TEE corresponding interface of the security world in a mode of triggering the SMC by the common world, so that the verification process related to the image file can be transferred to the security world for verification, and a verification result is returned to the common world.

BL1 firmware may be referred to as trusted boot ROM (Trusted Boot ROM), which is the firmware that runs earliest during boot up, and is also firmware stored in read-only memory (ROM). BL1 firmware is not co-located with the BIOS of the computing device, and in some types of trusted firmware technology BL1 firmware is the root of trust of everything. BL1 firmware can be used to initialize core hardware (e.g., trusted Static Random Access Memory (SRAM), serial port, etc.) of a computing device and find BL2 hardware, in some cases BL1 firmware will sign BL2 firmware. BL1 firmware runs on the EL3 privilege level.

BL2 firmware may be referred to as (trusted boot firmware Trusted Boot Firmware), BL2 firmware also operates on the EL3 privilege level, with the notable difference that BL2 firmware and BL1 firmware may be stored on an external trusted storage device, whose trust may be based on the verification of it by BL1 firmware. The BL2 firmware initializes some critical security hardware and software frameworks, and after initialization is completed, the BL2 firmware finds BL31. In some embodiments, BL31 firmware is authenticated by BL2 firmware signature.

BL31 Firmware may be referred to as EL3 run Firmware (EL 3 run Firmware). BL31 firmware also runs on the EL3 privilege level, the last security fort of the EL3 privilege level. BL31 firmware, unlike BL1 firmware and BL2 firmware, is run once and continuously provides security-related services to the general world (Non-Secure) through security monitoring calls (Secure Monitor Call, SMC).

BL32 firmware may include an open portable Tee operating system (Open Portable Tee Operate System, OPTee OS), which may refer to the operating system of a trusted execution environment, and trusted applications. BL32 firmware runs on S-EL1, and trusted applications on BL32 firmware run on S-EL0.BL31 firmware can be signed against BL32 firmware. In some cases, after the OPTee OS finishes running, returning BL31 firmware of the EL3, wherein the BL31 firmware finds BL33 firmware, and the BL31 firmware can also check BL33 firmware.

BL33 Firmware may include Firmware (Non-Trusted Firmware) running in the general world, BL33 Firmware may include extensible Firmware interface (Unified Extensible Firmware Interface, UEFI) Firmware or U-boot (boot loader for embedded applications) Firmware for desktop, server, etc., linux Kernel, BIOS Firmware.

In some embodiments, embodiments of the present application may utilize a TCM service module and/or TCM cryptographic module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, thereby improving the security of the system. In some embodiments, some of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware may be measured using a TCM cryptographic module, while another part of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware may be measured using a TCM service module and TCM cryptographic module.

For example, the TCM service module and/or the TCM cryptographic module may be used to measure the BL31 firmware, the BL32 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware, the BL32 firmware and the BL33 firmware are loaded and run one by one. For another example, in the case that the BL32 firmware is not included, the TCM service module and/or the TCM cryptographic module may be used to measure the BL31 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware and the BL33 firmware are loaded and run one by one.

The start-up process of the security architecture system is generally divided into the following stages, BL1 stage, BL2 stage, BL31 stage, BL32 stage, BL33 stage. According to the starting sequence, the secure architecture system starts up and then firstly executes BL1 firmware, then marks BL2 firmware, and BL2 firmware starts up BL31 firmware or BL32 firmware according to specific design. BL32 firmware may only exist if BL31 firmware is available, and is signed and loaded to start.

Because BL1 firmware is the first firmware in the system starting process and BL1 firmware is a section of non-tamperable firmware code, measurement is carried out from BL1 firmware, and the security of the system can be fundamentally ensured. In some embodiments, BL1 firmware may also be referred to as a trusted boot root, or a trusted root of a secure architecture system, or a hardware trusted root, or the like.

The starting sequence of the firmware is not specifically limited in the embodiment of the present application. For example, the boot sequence of the firmware may be BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, as the boot sequence shown in FIG. 6. For another example, the start-up sequence of the firmware may be BL1 firmware, BL2 firmware, BL31 firmware, BL33 firmware, BL32 firmware. For another example, the start-up sequence of the firmware may be BL1 firmware, BL2 firmware, BL33 firmware, BL31 firmware, BL32 firmware.

The above-mentioned firmware dividing manner is merely an example, and embodiments of the present application are not limited thereto, and may divide the firmware in other manners. For example, the Feiteng System software stack divides the firmware into Feiteng trusted roots (PBR) and Feiteng base firmware layers (phytium base firmware, PBF), the PBF including PBF-BL1, PBF-BL2, PBF-BL31, PBF-BL32, PBF-BL33.PBR is a trusted root, and PBF-BL1 and PBF-BL2 are platform initialization firmware.

After the firmware boot is completed, the operating system kernel may be booted, thereby completing the booting of the computing device.

The starting process of the embodiment of the present application is described below with respect to different configurations of the TCM service module and the TCM cryptographic module in the secure architecture system. The TCM service module and the TCM cryptographic module hereinafter may be collectively referred to as a TCM module, i.e., the TCM module may include the TCM service module and the TCM cryptographic module.

Example one

The TCM service module and the TCM cryptographic module are built in a secure element subsystem, and the secure architecture system is of a homogeneous three-level architecture, that is, the secure element subsystem and the trusted execution environment subsystem run on the same processor core. Assuming that the trusted execution environment subsystem and the secure element subsystem are running on the first processor core, the first processor core is capable of handling both programs or services in the trusted execution environment subsystem and programs or services in the secure element subsystem.

Before introducing the start-up procedure, a description is first given of a system software stack of a homogeneous three-level architecture in an embodiment of the present application with reference to fig. 7.

As shown in fig. 7, the system software stack may include three layers of firmware: trusted root (e.g., PBR or BL1 firmware), base firmware (e.g., PBF), and system firmware. The trusted root may be a trusted boot root built in a chip and is responsible for first-stage signing on the basic firmware. In some embodiments, the system software stack may not include a trusted root.

The basic firmware is mainly used for basic initialization of the chip and provides relevant services. For example, the underlying firmware may be used to implement initialization services, power management, recovery (e.g., image recovery), RAS, secure platform architecture (PSPA) support, security monitor, secure boot, secure partition manager (secure partition manager, SPM) call, and the like. Where RAS represents reliability, availability, and serviceability analysis. In addition, the base firmware may also be responsible for loading a secure operating system, such as a TEE OS, running in a secure state.

Depending on the application scenario, the system firmware may have two implementations. As shown in fig. 7, the system firmware may be implemented as an extensible firmware interface (unified extensible firmware interface, UEFI) oriented to the desktop, server, etc. domain, or may be implemented as a Boot loader (U-Boot) oriented to the embedded domain.

In addition, the underlying firmware, system firmware, and operating system may communicate with out-of-band control systems (e.g., embedded controllers (embeded controller, EC), baseboard management controllers (baseboard management controller, BMC), etc.).

As shown in fig. 7, the secure element subsystem is provided with a TCM service module and a TCM cryptographic module, which are used for verifying and verifying codes in the process of secure startup. The TCM cryptographic module provides standard services such as TRNG, trusted root key, secure storage cryptographic operation, signature verification and the like based on hardware. The trusted root key may include a trusted storage root, a trusted metrics root, and a trusted reporting root. The TCM service module may implement services including, but not limited to, trusted metrics, trusted reports, trusted stores, etc., by invoking the TCM cryptographic module.

Referring to fig. 8, the method shown in fig. 8 may include steps S810 to S860.

Step S810: and responding to the power-on request, and executing a starting process. The load runs BL2 firmware. In this step, the processor core of the secure architecture system may also be initialized.

Before the BL2 firmware is run, a trusted root can be run, and the BL2 firmware is signed and authenticated by the trusted root. The trusted root may be, for example, BL1 firmware. And if the BL2 firmware authentication is successful, the BL2 firmware is rerun. If BL2 firmware authentication fails, the boot flow may be exited and the secure/trusted boot fails. By carrying out signature authentication on BL2 firmware, the integrity and the correctness of BL2 firmware can be ensured.

The trusted root may be code that runs directly after the chip is powered up. The trusted root may be executed on the SE engine of the secure element subsystem or on the trusted core of the trusted execution environment subsystem.

After running the root of trust, the processor core may be initialized. For example, hardware resources such as TZCs, double Data Rates (DDR), peripheral component interconnect express (peripheral component interconnect express, PCIe), network-on-chip (NoC), etc., may be initialized. The processor herein may be a first processor.

Step S820: and performing self-checking on hardware resources of the first processor core and the TCM cryptographic module. The self-checking program of the TCM cryptographic module may be a program preset in the system.

If the self-test passes, step S830 is continued. If the self-test fails, the boot flow may be exited.

Step S830: and loading and running the TCM cryptographic module and the TCM service module under the condition that the self-check passes.

After BL2 firmware runs, self-checking can be performed on hardware resources of the TCM cryptographic module. Under the condition that the hardware resource self-check of the TCM cryptographic module passes, the TCM cryptographic module and the TCM service module are reloaded and operated, so that the safety of the system is guaranteed. If the self-checking of the TCM cryptographic module is not passed, the starting process is exited.

The TCM cryptographic module may include a service interface that may be used by firmware or TCM service modules to invoke services. The steps described above may also initialize the service interface of the TCM cryptographic module to provide calling services for initialization for the system firmware runtime.

Step S840: one or more of BL31 firmware, BL32 firmware and BL33 firmware is measured by using the TCM cryptographic module and the TCM service module. For example, the TCM cryptographic module and the TCM service module are utilized to measure the BL31 firmware, the BL32 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware, the BL32 firmware and the BL33 firmware are loaded and run one by one. For another example, in the case that the BL32 firmware is not included, the TCM cryptographic module and the TCM service module may be used to measure the BL31 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware and the BL33 firmware are loaded and run one by one.

The running environment of the secure element subsystem may be self-checked prior to the measurements made on the BL31 firmware, BL32 firmware, BL33 firmware. Judging whether BL31 firmware, BL32 firmware and BL33 firmware exist or not, and guiding the measurement and loading of the firmware existing in the system.

The embodiment of the application can measure one or more of BL31 firmware, BL32 firmware and BL33 firmware by using the TCM cryptographic module and the TCM service module, and the measurement sequence can be consistent with the starting sequence of BL31 firmware, BL32 firmware and BL33 firmware. If the metric fails, the boot flow may be exited. The embodiment of the application can also safely store the measurement result so as to realize trusted starting.

The security architecture system of embodiments of the present application may be provided in a computing device. After the firmware measurement is completed, the embodiment of the application can also measure the program of the operating system kernel of the computing device by using the TCM service module and the TCM password module. After the measurement result is obtained, the measurement result can be stored safely. The boot flow may be exited if the metrics fail.

After the program metrics of the operating system kernel are completed, the operating system kernel may be loaded to initialize hardware resources of the computing device and boot the operating system to complete the boot of the computing device.

From the above flow, the embodiment of the present application may determine the measurement result of each firmware, and any firmware fails to measure, so that the startup flow may be exited, and the security of the startup process may be ensured.

The start-up procedure is described in more detail below in connection with fig. 9. It should be noted that, the flow shown in fig. 9 is only for easy understanding, and the description of the embodiments of the present application should not be limited to this application.

Step S902: and powering up the chip, and executing the trusted root. The trusted root may be executed on the SE engine of the secure element subsystem or on the trusted core of the trusted execution environment subsystem.

Step S904: and carrying out safe self-checking on the chip state. The self-test procedure may include self-test of core hardware such as TRNG, cryptographic algorithm hardware engine, etc. If the self-test fails, no subsequent secure/trusted boot operation may be performed.

Step S908: if the chip self-test is successful, the processor core may be initialized, such as initializing hardware TZC, DDR, PCIe, noC. In addition, TCM cryptographic modules may also be loaded and run in the secure element subsystem. In some embodiments, hardware resources of the TCM cryptographic module may also be self-checked. For example, a preset SE-TCM hardware self-test program may be run. If the self-test does not pass, the secure/trusted boot flow may be exited. In some embodiments, this step may also provide a call service for initialization for the system firmware runtime.

Step S910: and carrying out signature authentication on BL2 firmware by utilizing the trusted root. For example, the BL2 firmware may be signature authenticated using a public key algorithm. If authentication fails, the secure/trusted boot flow may be exited.

Step S912: and running BL2 firmware under the condition that BL2 firmware authentication is successful. Initializing a processor platform and loading a TCM service module. In some embodiments, the TCM service module may also be loaded in step S908, that is, the TCM cryptographic module and the TCM service module may be loaded in step S908. Environment self-checking, judging whether BL31 firmware, BL32 firmware and BL33 firmware exist or not, and guiding the measurement and loading of the three firmware.

Step S914: and measuring BL31 firmware/BL 32 firmware/BL 33 firmware by using the TCM service module and the TCM cipher module, and recording measurement results. If the metrics fail, the secure/trusted boot flow may be exited.

Step S916: and under the condition that BL31 firmware/BL 32 firmware/BL 33 firmware measurement is successful, measuring a system kernel environment program by using the TCM service module and the TCM cryptographic module, and storing measurement results. If the metrics fail, the secure/trusted boot flow may be exited.

Step S918: and loading a system kernel, initializing hardware resources of the computing device and guiding an operating system.

Step S920: a secure/trusted boot is completed.

Public key algorithms of embodiments of the present application include, but are not limited to, SM2 and elliptic encryption algorithms (ellipse curve cryptography, ECC). Note that SM2 and ECC are only examples, and should not be construed as limiting.

Example two

The TCM service module and the TCM cryptographic module are built in a secure element subsystem, and the secure architecture system is a homogeneous three-level architecture, that is, the secure element subsystem and the trusted execution environment subsystem run on different processor cores. Assuming that the trusted execution environment subsystem is running on a second processor core and the secure element subsystem is running on a third processor core, the second processor core is capable of handling programs or services in the trusted execution environment subsystem and the third processor core is capable of handling programs or services in the secure element subsystem.

Before introducing the start-up procedure, the system software stack of the heterogeneous three-level architecture in the embodiment of the present application will be described with reference to fig. 10.

The differences between the system software stack in fig. 10 and the system software stack in fig. 7 include: the associated firmware for the initialization service and secure boot and the trusted root are provided in the secure element subsystem. The underlying hardware, i.e., firmware components, of the processor in fig. 10 may be used to implement initialization services, power management, recovery, SPM invocation, security monitor, RAS, etc. functions.

Referring to fig. 11, the method shown in fig. 11 includes steps S1110 to S1130.

Step S1110: firmware in the secure element subsystem is loaded and run to initialize the secure element subsystem.

Since the secure element subsystem has a dedicated core, it may operate independently of the trusted execution environment subsystem, and thus the dedicated core may be utilized to load and operate firmware in the secure element subsystem to initialize the secure element subsystem.

For convenience of description, the firmware in the secure element subsystem will be hereinafter simply referred to as SE firmware.

In some embodiments, before step S1110, the SE firmware may be signature authenticated with a trusted root. And reloading and running the SE firmware under the condition that the SE firmware passes the authentication. For example, after the chip is powered up, the root of trust is executed first. The root of trust may be located in the secure element subsystem. And carrying out self-checking on the chip state. If the self-checking fails, the subsequent starting operation flow is not executed. The self-checking process may include self-checking of core hardware resources such as TRNG, cryptographic algorithm engines, etc. In the case of chip self-test passing, the SE firmware may be signature authenticated with a trusted root. If the authentication fails, the start-up procedure is exited.

In the event that the SE firmware is authenticated, the SE firmware may be loaded and run. Further, core modules in the secure element subsystem, such as cryptographic algorithm engines, OTP, etc., may be initialized.

Step S1120: loading and running the TCM service module and the TCM cryptographic module in the secure element subsystem. Since the secure element subsystem has a dedicated processor core, the trusted root is disposed in the secure element subsystem, and thus, the TCM service module and the TCM cryptographic module may be loaded and operated after the trusted root is operated.

In some embodiments, a TCM cryptographic module (e.g., a software portion of a TCM cryptographic module) and a TCM service module may be loaded and run in the secure element subsystem after initialization of the core module in the secure element subsystem is complete. For example, a hardware self-checking program of the trusted cryptography service module may be run. If the self-test does not pass, the start-up procedure may be exited. The hardware self-test program may be a program preset in the secure element subsystem.

Step S1130: the TCM service module and the TCM cryptographic module are utilized to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

For example, the TCM service module and the TCM cryptographic module are utilized to measure the BL31 firmware, the BL32 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware, the BL32 firmware and the BL33 firmware are loaded and run one by one. For another example, in the case that the BL32 firmware is not included, the TCM service module and/or the TCM cryptographic module may be used to measure the BL31 firmware and the BL33 firmware one by one, and if the measurement is successful, the BL31 firmware and the BL33 firmware are loaded and run one by one.

Because the TCM service module and the TCM cipher module are loaded and run completely, the TCM service module and the TCM cipher module can be used for measuring the firmware in the starting process.

In some embodiments, the BL2 firmware may be measured using a TCM service module and a TCM cryptographic module. In the event that the BL2 firmware metrics are successful, the BL2 firmware may be run and the processor core of the secure architecture system initialized. If the metric fails, the boot flow is exited.

In this embodiment, the TCM service module and the TCM cryptographic module may be loaded in the trusted root, so that the TCM service module and the TCM cryptographic module may operate in preference to most of the firmware that needs to operate in the startup process, so that the TCM service module and the TCM cryptographic module may measure BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware, and perform an active measurement function of trusted computing in the secure/trusted startup process.

However, it should be noted that, in the trusted root, that is, in the hardware trusted boot root, after the self-checking and the basic initialization of power-up are completed, the TCM service module and the TCM cryptographic module are loaded and run, and this implementation needs to occupy relatively large hardware resources, and the hardware cost is also higher, so that the practical applicability of this implementation is relatively limited.

In some embodiments, the embodiments of the present application may also utilize the trusted root to sign-authenticate the BL2 firmware after the trusted root is running. And running BL2 firmware under the condition that BL2 firmware authentication is successful.

In some embodiments, the TCM service module and TCM cryptographic module may be reloaded and run after BL2 firmware is run. One or more of BL31 firmware, BL32 firmware, BL33 firmware is then measured using the TCM service module and TCM cryptographic module. That is, the TCM service module and TCM cryptographic module may not measure BL2 firmware.

In some embodiments, the embodiments of the present application may perform self-checking on hardware resources of the TCM cryptographic module before the TCM service module and the TCM cryptographic module load operation. And under the condition that the self-checking passes, reloading and operating the TCM service module and the TCM cipher module.

It should be noted that, in addition to measuring one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware by the TCM service module and/or the TCM cryptographic module, the secure boot process may be performed simultaneously, that is, the firmware may be subjected to step-by-step signature authentication by using the trusted root, where the step-by-step signature authentication may include: and carrying out signature authentication on BL2 firmware through a trusted root, carrying out signature authentication on BL31 firmware through BL2 firmware, carrying out signature authentication on BL32 firmware and/or BL33 firmware through BL31 firmware, and terminating the starting process if any stage of firmware authentication fails.

It should also be noted that the security architecture system of the embodiments of the present application may be provided in a computing device. After the firmware measurement is completed, the embodiment of the application can also measure the program of the operating system kernel of the computing device by using the TCM service module and the TCM password module. After the measurement result is obtained, the measurement result can be stored safely. The boot flow may be exited if the metrics fail.

After the program metrics of the operating system kernel are completed, the operating system kernel may be loaded to initialize hardware resources of the computing device and boot the operating system to complete the boot of the computing device. From the above flow, the embodiment of the present application may determine the measurement result and the signature authentication result of each firmware, and any firmware measurement failure or signature authentication failure may exit the secure/trusted starting flow, so as to ensure the security of the secure/trusted starting process.

The start-up procedure is described in more detail below in connection with fig. 12. It should be noted that the flow shown in fig. 12 is only for easy understanding, and the description of the embodiments of the present application should not be limited to this application.

Step S1202: and powering up the chip, and executing the trusted root. The trusted root may be provided in the secure element subsystem.

Step S1204: and carrying out safe self-checking on the chip state. The self-test procedure may include self-test of core hardware such as TRNG, cryptographic algorithm hardware engine, etc. If the self-test fails, no subsequent secure/trusted boot operation may be performed.

Step S1206: if the chip self-test is successful, the SE firmware can be signed and authenticated by the trusted root. For example, the SE firmware may be signature authenticated using a public key algorithm. Public key algorithms include, but are not limited to, SM2 and ECC. Note that SM2 and ECC are only examples, and should not be construed as limiting. If authentication fails, the secure/trusted boot flow may be exited.

Step S1208: the SE firmware is loaded and run. The core modules in the secure element subsystem, such as cryptographic engine algorithms, OTP, etc., are initialized. The TCM service module and the TCM cryptographic module are loaded and run in the secure element subsystem. If the self-test does not pass, the secure/trusted boot flow may be exited. In some embodiments, this step may also provide a call service for initialization for the system firmware runtime.

Step S1210: and verifying BL2 firmware by using the TCM service module and the TCM cipher module. If the verification fails, the secure/trusted boot flow may be exited.

Step S1212: and under the condition that BL2 firmware verification is successful, loading and operating BL2 firmware, and finishing initialization of the processor platform. Environment self-checking, judging whether BL31 firmware, BL32 firmware and BL33 firmware exist or not, and guiding the measurement and loading of the three firmware.

Step S1214: and measuring BL31 firmware/BL 32 firmware/BL 33 firmware by using the TCM service module and the TCM cipher module, and recording measurement results. If the metrics fail, the secure/trusted boot flow may be exited.

Step S1216: and under the condition that BL31 firmware/BL 32 firmware/BL 33 firmware measurement is successful, measuring a system kernel environment program by using the TCM service module and the TCM cryptographic module, and storing measurement results. If the metrics fail, the secure/trusted boot flow may be exited.

Step S1218: and loading a system kernel, initializing hardware resources of the computing device and guiding an operating system.

Step S1220: a secure/trusted boot is completed.

Public key algorithms of embodiments of the present application include, but are not limited to, SM2 and ECC. Note that SM2 and ECC are only examples, and should not be construed as limiting.

In addition to the scheme for measuring the firmware described above, the embodiment of the application may also perform step-by-step signature verification on the firmware. For example, the BL2 firmware may be signature-authenticated by the trusted root, and then the BL31 firmware may be signature-authenticated by the BL2 firmware, and the BL32 and/or BL33 firmware may be signature-authenticated by the BL31 firmware, respectively, and so on. Any level of verification failure may terminate the boot process, in this way, secure booting of the secure architecture system may be achieved. Alternatively, in some embodiments, the firmware running during the startup of the secure architecture system may not include the BL32 firmware, and the BL31 firmware may verify the BL33 firmware.

Method embodiments of the present application are described above in detail in connection with fig. 1-12, and apparatus embodiments of the present application are described below in detail in connection with fig. 13-14. It is to be understood that the description of the method embodiments corresponds to the description of the device embodiments, and that parts not described in detail can therefore be seen in the preceding method embodiments.

The embodiment of the application also provides a security architecture system, and the structure of the security architecture system is shown in fig. 4. The security architecture system may be any of the security architecture systems described above.

The secure architecture system can be carried with a rich execution environment subsystem, a trusted execution environment subsystem and a secure element subsystem, wherein a trusted cryptographic service module is constructed in the secure architecture system and comprises a TCM service module and a TCM cryptographic module, and the TCM service module and the TCM cryptographic module are constructed in the same subsystem except the rich execution environment subsystem; the TCM service module and/or the TCM cryptographic module are configured to: and in the starting process of the security architecture system, measuring the firmware running in the starting process, and recording the measurement result.

In some embodiments, the TCM service module and the TCM cryptographic module are built into the trusted execution environment subsystem, or the TCM service module and the TCM cryptographic module are built into the secure element subsystem.

In some embodiments, the TCM service module and/or the TCM cryptographic module is configured to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

In some embodiments, the TCM service module and the TCM cryptographic module are built in the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem are run on a first processor core, the secure architecture system is configured to self-check hardware resources of the TCM cryptographic module, and load and run the TCM cryptographic module if the hardware resources of the TCM cryptographic module pass self-check; the TCM cryptographic module is configured to measure the BL2 firmware; the secure architecture system is configured to run the BL2 firmware and initialize a processor core of the secure architecture system, load and run the TCM service module; the TCM cryptographic module and the TCM service module are configured to measure one or more of the BL31 firmware, the BL32 firmware, the BL33 firmware.

In some embodiments, the TCM service module and the TCM cryptographic module are built in the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem are run on a first processor core, the secure architecture system is configured to self-check hardware resources of the TCM cryptographic module, and load and run the TCM cryptographic module and the TCM service module if the hardware resources of the TCM cryptographic module pass self-check; the TCM cryptographic module and the TCM service module are configured to measure the BL2 firmware; the secure architecture system is configured to run the BL2 firmware and initialize a processor core of the secure architecture system; the TCM cryptographic module and the TCM service module are configured to measure one or more of the BL31 firmware, the BL32 firmware, the BL33 firmware.

In some embodiments, the secure architecture system has a trusted root built into it, the secure architecture system configured to: executing the root of trust prior to the running the BL2 firmware; and carrying out signature authentication on the BL2 firmware by utilizing the trusted root.

In some embodiments, the TCM service module and the TCM cryptographic module are built into the secure element subsystem, the secure element subsystem running on a second processor core, the trusted execution environment subsystem running on a third processor core, the secure architecture system configured to load and run firmware in the secure element subsystem to initialize the secure element subsystem; initializing the second processor core and the third processor core; loading and operating the TCM service module and the TCM cryptographic module in the secure element subsystem; the TCM service module and the TCM cryptographic module are configured to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

In some embodiments, the TCM service module and the TCM cryptographic module are configured to measure the BL2 firmware; the secure architecture system is configured to run the BL2 firmware and initialize a processor core of the secure architecture system; the TCM service module and the TCM cryptographic module are configured to measure one or more of the BL31 firmware, the BL32 firmware, the BL33 firmware.

In some embodiments, the secure architecture system has a trusted root built into it, the secure architecture system configured to: signature authentication is carried out on the firmware in the secure element subsystem through the trusted root before the firmware in the secure element subsystem is loaded and operated; in the event that the firmware authentication in the secure element subsystem passes, loading and running the firmware in the secure element subsystem.

In some embodiments, the secure architecture system is disposed in a computing device, the TCM service module and the TCM cryptographic module are configured to measure a program of an operating system kernel of the computing device; the security architecture system is configured to: and loading the kernel of the operating system to initialize hardware resources of the computing device and guide the operating system, thereby completing the starting of the computing device.

Fig. 13 is a schematic structural diagram of a computing device according to an embodiment of the present application. The computing device 1300 includes a secure architecture system 1310. The security architecture system 1310 may be any of the security architecture systems described above.

The embodiments of the present application do not specifically limit the specific form of the computing device. For example, the computing device may be a mobile terminal, desktop computer, tablet computer, personal computer (personal computer, PC), personal digital assistant (personal digital assistant, PDA), smart watch, netbook, wearable electronic device, augmented reality (augmented reality, AR) device, or the like.

Fig. 14 is a schematic structural diagram of an apparatus for implementing trusted booting according to an embodiment of the present application. The apparatus may be used to implement the method described in the method embodiments above. The apparatus 1400 may be a secure architecture system, a computer, or any type of computing device.

The apparatus 1400 may include a memory 1410 and a processor 1420. Memory 1410 may be used for storing instructions. The controller 1420 may be used to perform the methods described in any of the previous embodiments according to instructions stored in the memory 1410.

The processor 1420 may be a general purpose processor or a special purpose processor. For example, the processor may be a central processing unit (central processing unit, CPU). Alternatively, the processor may be another general purpose processor, a digital signal processor (digital signal processor, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), an off-the-shelf programmable gate array (field programmable gate array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The embodiment of the application also provides a computer readable storage medium for storing a program. The computer readable storage medium can be applied to the security architecture system provided in the embodiments of the present application, and the program can make the computer execute the method executed by the security architecture system (such as the TCM service module and/or the TCM cryptographic module) in the embodiments of the present application.

Embodiments of the present application also provide a computer program product. The computer program product includes a program. The computer program product may be applied to a secure architecture system provided in embodiments of the present application, and the program may cause a computer to perform the methods performed by the secure architecture system (e.g., TCM service module and/or TCM cryptographic module) in various embodiments of the present application.

The embodiment of the application also provides a computer program. The computer program can be applied to the security architecture system provided in the embodiments of the present application, and the computer program can make the computer execute the method executed by the security architecture system (such as the TCM service module and/or the TCM cryptographic module) in the embodiments of the present application.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy Disk, a hard Disk, a magnetic tape), an optical medium (e.g., a digital video disc (Digital Video Disc, DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method for realizing safe and reliable starting is characterized in that the method is applied to a safe architecture system, the safe architecture system is loaded with a rich execution environment subsystem, a reliable execution environment subsystem and a safe element subsystem, a reliable password service module is constructed in the safe architecture system, the reliable password service module comprises a TCM service module and a TCM password module, the TCM service module and the TCM password module are constructed in the same subsystem except the rich execution environment subsystem, the TCM password module is used for providing reliable hardware computing resources for the reliable password service module, and the TCM service module is used for providing service interfaces for calling resources in the TCM password module;

The method comprises the following steps:

during the startup of the security architecture system, any one or more of the following metrics are performed:

the TCM cryptographic module is utilized to measure the firmware running in the starting process step by step, and the measurement result is recorded; or (b)

And calling the TCM cipher module by the TCM service module through the service interface to measure the firmware running in the starting process step by step, and recording a measurement result.

2. The method of claim 1, wherein the TCM service module and the TCM cryptographic module are built into the trusted execution environment subsystem or the TCM service module and the TCM cryptographic module are built into the secure element subsystem.

3. The method of claim 1, wherein the step-wise measuring of firmware running during boot-up comprises:

progressive metrics are performed on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

4. The method of claim 3, wherein the TCM service module and the TCM cryptographic module are built into the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem are running on a first processor core,

The measuring one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include:

running the BL2 firmware and initializing a processor core of the security architecture system;

performing self-checking on hardware resources of the first processor core and the TCM cryptographic module;

loading and operating the TCM cryptographic module and the TCM service module under the condition that the self-check is passed;

and measuring one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by using the TCM cryptographic module and the TCM service module.

5. The method according to claim 4, wherein the method further comprises:

and carrying out signature authentication on the BL31 firmware by utilizing the BL2 firmware.

6. The method of claim 4 or 5, wherein the secure architecture system has a trusted root built-in, the method further comprising, prior to the running the BL2 firmware:

executing the trusted root;

and carrying out signature authentication on the BL2 firmware by utilizing the trusted root.

7. The method of claim 3, wherein the TCM service module and the TCM cryptographic module are built into the secure element subsystem, the secure element subsystem operating on a second processor core, the trusted execution environment subsystem operating on a third processor core,

The progressive metrics are performed on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include:

loading and running firmware in the secure element subsystem to initialize the secure element subsystem;

initializing the second processor core and the third processor core;

loading and operating the TCM service module and the TCM cryptographic module in the secure element subsystem;

and carrying out step-by-step measurement on one or more of the following firmware by utilizing the TCM service module and the TCM password module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

8. The method of claim 7, wherein the progressive metric is performed on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, include:

measuring the BL2 firmware by utilizing the TCM service module and the TCM cipher module;

and carrying out step-by-step measurement on one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by utilizing the TCM service module and the TCM cryptographic module.

9. The method of claim 7, wherein the secure architecture system has a trusted root built-in, the method further comprising, prior to the loading and running firmware in the secure element subsystem:

signature authentication is carried out on firmware in the secure element subsystem through the trusted root;

the loading and running firmware in the secure element subsystem includes:

in the event that the firmware authentication in the secure element subsystem passes, loading and running the firmware in the secure element subsystem.

10. The method of claim 7, wherein the secure architecture system is disposed in a computing device, the method further comprising:

measuring a program of an operating system kernel of the computing device by using the TCM service module and the TCM cryptographic module;

and loading the kernel of the operating system to initialize hardware resources of the computing device and guide the operating system, thereby completing the starting of the computing device.

11. The security architecture system is characterized in that the security architecture system is provided with a rich execution environment subsystem, a trusted execution environment subsystem and a security element subsystem, a trusted cryptography service module is constructed in the security architecture system, the trusted cryptography service module comprises a TCM service module and a TCM cryptography module, the TCM service module and the TCM cryptography module are constructed in the same subsystem except the rich execution environment subsystem, the TCM cryptography module is used for providing trusted hardware computing resources for the trusted cryptography service module, and the TCM service module is used for providing service interfaces for calling resources in the TCM cryptography module;

The security architecture system is configured to: during the startup of the security architecture system, any one or more of the following metrics are performed: the TCM cryptographic module is utilized to measure the firmware running in the starting process step by step, and the measurement result is recorded; or the TCM service module is utilized to call the TCM cipher module through the service interface to measure the firmware running in the starting process step by step, and the measurement result is recorded.

12. The secure architecture system of claim 11, wherein the TCM service module and the TCM cryptographic module are built into the trusted execution environment subsystem or the TCM service module and the TCM cryptographic module are built into the secure element subsystem.

13. The secure architecture system of claim 11, wherein the secure architecture system is configured to:

14. The secure architecture system of claim 13, wherein the TCM service module and the TCM cryptographic module are built into the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem are running on a first processor core, the secure architecture system configured to:

loading and operating the TCM service module and the TCM cipher module under the condition that the self-check is passed;

and carrying out step-by-step measurement on one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware by utilizing the TCM cryptographic module and the TCM service module.

15. The secure architecture system of claim 14, wherein the secure architecture system is configured to:

16. The secure architecture system of claim 14 or 15, wherein the secure architecture system has a trusted root built-in, the secure architecture system configured to:

executing the root of trust prior to the running the BL2 firmware;

17. The secure architecture system of claim 13, wherein the TCM service module and the TCM cryptographic module are built into the secure element subsystem, the secure element subsystem operating on a second processor core, the trusted execution environment subsystem operating on a third processor core, the secure architecture system configured to:

initializing the second processor core and the third processor core;

18. The secure architecture system of claim 17, wherein the secure architecture system is configured to:

19. The secure architecture system of claim 17, wherein the secure architecture system has a trusted root built-in, the secure architecture system configured to:

signature authentication is carried out on the firmware in the secure element subsystem through the trusted root before the firmware in the secure element subsystem is loaded and operated;

20. The secure architecture system of claim 17, wherein the secure architecture system is disposed in a computing device, the secure architecture system configured to:

21. A computing device, comprising: the security architecture system of any one of claims 11-20.

22. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a program that causes a computer to execute the method according to any one of claims 1-10.