CN115618365A

CN115618365A - Method for realizing safe and trusted start, safety architecture system and related equipment

Info

Publication number: CN115618365A
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-01-17
Anticipated expiration: 2042-12-16
Also published as: CN115618365B

Abstract

The application provides a method for realizing safe trusted boot, a safe architecture system and related equipment, wherein the safe architecture system is provided with a rich execution environment subsystem, a trusted execution environment subsystem and a safe element subsystem, a trusted cryptographic service module is constructed in the safe architecture system, the trusted cryptographic service module comprises a TCM service module and a TCM cryptographic module, and the method not only utilizes a hardware trusted root technology to verify firmware step by step and realizes the construction of a trust chain of the safe boot technology; meanwhile, the trusted measurement, the trusted storage and the trusted report are carried out on the firmware loaded and operated in the starting process by utilizing the TCM service module and/or the TCM password module, so that the trust chain construction of the trusted computing technology is realized. In addition, the TCM service module and the TCM cryptographic module are built in the same subsystem, so that the integration level of the trusted cryptographic service module can be improved, and the complexity of the system for scheduling the trusted cryptographic service module is reduced.

Description

Method for realizing safe and trusted start, safety architecture system and related equipment

Technical Field

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

Background

With the development of technology, people put higher and higher requirements on the security of systems, and therefore trusted computing technologies such as trusted cryptographic service modules appear. How to improve the security and the scheduling flexibility in the system starting process in the process of providing services by using the trusted cryptography service module is a problem which needs to be solved urgently at present.

Disclosure of Invention

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

In a first aspect, a method for implementing secure trusted boot is provided, where the method is applied to a secure architecture system, and 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 constructed in the secure architecture system, and 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 constructed in a same subsystem except for the rich execution environment subsystem; the method comprises the following steps: in the starting process of the security architecture system, the TCM service module and/or the TCM cryptographic module are used for measuring the firmware running in the starting process, and the measurement result is recorded.

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

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

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

Software and hardware security architectures, such as Trustzone, SGX and other technologies, are applied in the trusted execution environment subsystem, and additional security guarantee of the execution environment can be provided for the TCM service module and the TCM cryptographic module placed therein.

The secure element subsystem has a trusted and secure storage resource and a computing environment, and can provide additional security guarantee of an execution environment for the TCM service module and the TCM cryptographic module arranged in the secure element subsystem.

In some implementations, the measuring, by the TCM service module and/or the TCM cryptographic module, firmware running during a boot process includes: 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.

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

In some implementations, the TCM service module and the TCM crypto module are implemented in the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem run on a first processor core, the measuring with the TCM service module and/or the TCM crypto module of 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 secure architecture system; performing self-checking on hardware resources of the first processor core and the TCM cryptographic module; loading and operating the TCM password module and the TCM service module under the condition that the self-check is passed; 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 measurement process, the hardware resources of the TCM cryptographic module are subjected to self-checking, so that the reliability of hardware required by measurement and the safety of the measurement process are ensured. By loading the TCM service module after the BL2 firmware runs, the complexity of the starting process can be reduced on the premise of ensuring safe starting. The self-checking of the hardware resources of the TCM cryptographic module may be implemented by the 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 of the TCM except hardware resources are ensured by operating the Self-checking program.

In some implementations, the method further includes: and performing signature authentication on the BL31 firmware by utilizing the BL2 firmware.

The BL31 firmware is signed and authenticated by using the BL2 firmware, which is beneficial to ensuring the safety of the starting process.

In some implementations, the secure architecture system has a root of trust built in, and before the running the BL2 firmware, the method further comprises: executing the trusted root; and performing signature authentication on the BL2 firmware by using the trusted root.

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

In some implementations, the TCM service module and the TCM crypto module are implemented in 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 measuring with the TCM service module and/or the TCM crypto module of 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 running the TCM service module and the TCM cryptographic module in the secure element subsystem; utilizing the TCM service module and the TCM cryptographic module to perform measurements on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

By arranging the special core for the secure element subsystem, the secure element subsystem can independently operate without depending on a 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 a starting process is improved.

In some implementations, the utilizing the TCM service module and the TCM cryptographic module measures 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 cryptographic module; running the BL2 firmware and initializing a processor core of the secure architecture system; 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 to run, and then the BL33 firmware, the system kernel and the like can be subjected to stage-by-stage credibility measurement by using the TCM service module and/or the TCM password module. This is advantageous for improving the security of the system software during the boot process.

The TCM module in the embodiment of the application multiplexes hardware resources in a processor security architecture system in a built-in manner. Compared with a system architecture additionally provided with an independent external TCM module, on one hand, the system effectively improves the data communication efficiency of TCM module measurement service and can reduce hardware cost; on the other hand, the built-in TCM module and the multiplexing cipher hardware resource are utilized to measure the BL2 firmware and one or more of the BL31 firmware, the BL32 firmware and the BL33 firmware, so that the software step-by-step measurement in the secure boot technology and the software credibility measurement in the credible computing technology are realized in a fused 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 root of trust built in, and prior to the loading and running of the firmware in the secure element subsystem, the method further comprises: signing and authenticating firmware in the secure element subsystem through the trusted root; the loading and running of firmware in the secure element subsystem includes: and loading and running the firmware in the secure element subsystem under the condition that the firmware in the secure element subsystem passes the authentication.

Signature authentication is carried out on the SE firmware through the trusted root, the integrity and the correctness of the SE firmware can be guaranteed, a trust chain of the firmware is constructed, and therefore the safety of the system is effectively improved.

In some implementations, the security architecture system is disposed in a computing device, the method further comprising: measuring programs of an operating system kernel of the computing device by utilizing the TCM service module and the TCM password module; loading the operating system kernel to initialize hardware resources of the computing device and to boot the operating system to complete the booting 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 cryptographic service module is constructed 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 constructed in a same subsystem except for the rich execution environment subsystem; the security architecture system is configured to: in the starting process of the security architecture system, the TCM service module and/or the TCM password module are used for measuring the firmware running in the starting process, and the measuring result is recorded.

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

In some implementations, the security architecture system is configured to: utilizing the TCM service module and/or the TCM cryptographic module to perform measurements on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

In some implementations, the TCM service module and the TCM cryptographic module are implemented 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 configured to: running the BL2 firmware and initializing a processor core of the secure 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 password module under the condition that the self-check is passed; 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 secure architecture system is configured to: and performing signature authentication on the BL31 firmware by utilizing the BL2 firmware.

In some implementations, the secure architecture system has a root of trust built in, the secure architecture system configured to: executing the root of trust before the running of the BL2 firmware; and performing signature authentication on the BL2 firmware by using the trusted root.

In some implementations, the TCM service module and the TCM cryptographic module are implemented in 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 security 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 running the TCM service module and the TCM cryptographic module in the secure element subsystem; measuring, with the TCM service module and the TCM cryptographic module, one or more of the following firmware: 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 cryptographic module; running the BL2 firmware and initializing a processor core of the secure architecture system; 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 root of trust built in, the secure architecture system configured to:

before the firmware in the secure element subsystem is loaded and run, performing signature authentication on the firmware in the secure element subsystem through the trusted root; and loading and running the firmware in the secure element subsystem under the condition that the firmware in the secure element subsystem passes the authentication.

In some implementations, the security architecture system is disposed in a computing device, the security architecture system configured to: measuring programs of an operating system kernel of the computing device by utilizing the TCM service module and the TCM password module; loading the operating system kernel to initialize hardware resources of the computing device and to boot the operating system to complete the booting of the computing device.

In a third aspect, a computing device is provided that includes the security architecture system of the second aspect or any implementation manner of the second aspect.

In a fourth aspect, a computer readable storage medium is provided, having a program stored thereon, where the program is to make a computer execute the method according to the first aspect or any one of the implementation manners of the first aspect.

Drawings

Fig. 1 is a schematic configuration 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-level 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 flowchart of a method for implementing secure trusted boot according to an embodiment of the present application.

FIG. 6 is a schematic diagram of a boot 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 flowchart of a startup method according to an embodiment of the present application.

Fig. 9 is a schematic flowchart of another startup method provided in an embodiment of the present application.

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

Fig. 11 is a schematic flowchart of another startup method provided in an embodiment of the present application.

Fig. 12 is a schematic flowchart of another startup 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 structural diagram of an apparatus for implementing secure trusted boot according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments.

As the demand for security of computing devices increases, more and more security technologies are gradually applied to various computing devices, wherein the security chip technology has become an important technical means of a security architecture system in the computing devices, and a security element subsystem implementing the security chip technology becomes a key part of many security architecture systems. If the security and the stability of the data of the computing system cannot be guaranteed, the computing environment becomes very vulnerable, and important resources, such as important data associated with payment, are easily leaked due to factors such as software attack or physical attack.

Generally, a security architecture system of a computing device may include three types of subsystems, namely, a Rich Execution Environment (REE) subsystem, a Trusted Execution Environment (TEE) subsystem, and a Secure Element (SE) subsystem. The safety element subsystem is fused with a typical safety computing processor architecture through a safety chip technology, a safety enhanced processor three-level safety computing architecture is constructed together, and the safety of important resources is guaranteed. Wherein, the safety 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 second highest security level, and the REE subsystem has the lowest security level.

Fig. 1 shows a schematic structural diagram of a security architecture system. The security architecture system 100 includes a REE subsystem, a TEE subsystem, and a SE subsystem. Generally, an application running in the REE subsystem may be referred to as a Common Application (CA), which is low in security and vulnerable to attacks. The application in fig. 1 represents a CA. Applications running in the TEE subsystem are generally called Trusted Applications (TAs), which are higher in security than CAs, and may be used to implement data-sensitive service scenarios, such as cardholder information and identity verification in payment services. Applications running in the SE subsystem may be referred to as secure trusted applications, which are more secure than 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 like a trusted root. The SE subsystem can ensure the safety of important resources in the SE subsystem through means of authority verification, cryptographic technology and the like. In the safety architecture system, the three subsystems are mutually matched, and different safety protection requirements can be flexibly provided for the calculation data.

The REE subsystem may include a general Operating System (OS) or a Virtual Machine (VM) running on a general-purpose embedded processor, in which an application program is installed. Application 1 through application n are shown in FIG. 1, where n is a positive integer. For example, an application may be a program that relates to a payment scenario, where basic services such as browsing for goods, selecting goods, submitting an order, etc. are implemented. The REE subsystem may include a Unified Extensible Firmware Interface (UEFI), a universal Boot loader (U-Boot). Although many security measures such as device access control, device data encryption mechanism, isolation mechanism during application running, access control based on authority check, etc. can be implemented in the REE subsystem based on software, the security of important data in the application cannot be guaranteed.

The TEE subsystem may include a general purpose secure kernel, a Trusted User Interface (TUI), and a TEE OS, which are independent operating environments running outside of a general operating system. The TUI may provide an interface with input or output secure interaction capabilities for trusted applications and users within a trusted execution environment, for example, in a payment scenario, the TUI may be used for display of transaction information and Personal Identification Number (PIN) entry, and the like. 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 may not have direct access to the TEE subsystem's hardware and software resources. For example, trusted applications, such as trusted application 1 to trusted application p shown in fig. 1, may be executed in the TEE subsystem, where p is a positive integer, and a trusted operating environment is provided for the REE subsystem through the trusted applications, and then end-to-end security is ensured through protection of confidentiality and integrity and control of data access rights. 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 (API).

The TEE subsystem provides a higher security level of execution than the REE subsystem, but does not provide a hardware isolation level of secure key storage and cryptographic related execution. Generally, the TEE subsystem may provide a lot of APIs for the REE subsystem, so that the REE subsystem calls resources of the TEE subsystem, the more APIs provided by the TEE subsystem for performing services, the greater the risk faced by the TEE subsystem, and it is difficult to ensure that the APIs do not have potential safety hazards, such as security holes, and further, resources such as keys in the TEE subsystem have security risks. Furthermore, various TAs are operated in the TEE subsystem, the TAs are completely dependent on an isolation mechanism provided by the TEE operating system, and there is no isolation at a hardware level, so that if security holes exist in the TAs themselves or the TAs themselves actively access keys or root keys corresponding to other TAs, a great security risk also exists in sensitive resources such as the keys.

Due to the above problems of the TEE subsystem, it is proposed to build a secure and trusted storage resource and computing environment based on SE. Generally, a software system in the SE subsystem is relatively simple and includes fewer hardware components, so that it is easy to establish physical protection and implement security assurance, thereby improving the security strength of the SE subsystem to serve a security system with higher security requirements. Therein, security applications, such as security application 1 through security application m shown in fig. 1, may be executed in the SE subsystem, where m is a positive integer.

The security architecture system in the embodiment of the present application may be a homogeneous three-level architecture, and may also be a heterogeneous three-level architecture. These two architectures are described separately below.

Fig. 2 is a schematic diagram of an isomorphic three-stage architecture according to an embodiment of the present disclosure. In a homogeneous three-level architecture, both the trusted execution environment subsystem and the secure element subsystem run on the same security level processor core (e.g., processor security core). Assuming that the trusted execution environment subsystem and the secure element subsystem run on the first processor core, the first processor core is capable of processing 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, the rich execution environment subsystem may include an application core (AP-Cores), the trusted execution environment subsystem may include a Secure core (Secure-Cores), and the Secure element subsystem may include a cryptographic engine (or a cryptographic service module), a Secure storage medium, and a service interface (e.g., a Dynamic Random Access Memory (DRAM) interface) of the SE. The security engine may provide resources such as cryptographic operations.

Fig. 3 is a schematic diagram of a heterogeneous three-level architecture according to an embodiment of the present application. In the 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 independent processor cores. Assuming that the trusted execution environment subsystem runs on the second processor core and the secure element subsystem runs on the third processor core, the second processor core is responsible for processing programs or services in the trusted execution environment subsystem and the third processor core is responsible for processing programs or services in the secure element subsystem.

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

In the heterogeneous three-level architecture, the secure element subsystem has a dedicated core, so the secure element subsystem has image-wise completeness and has a custom hardware secure execution unit. The tasks in the safe element subsystem are completely independent from the execution environment of other subsystems, so that higher safety and higher execution efficiency can be provided.

With the development of technology, in a wider network environment, people put higher demands on the security of the system, for example, people want any operation or process behavior of a remote entity to be predictable or controllable, and thus, a trusted computing technology is developed. One of the core goals of trust is to ensure the integrity of the system and applications (or software) to ensure that the system or application runs in a trusted state as desired by design goals. Trust is the basis for security, and any security scheme or security policy can further ensure the security design goal only if it is run in an untampered environment. In general, the inclusion of trusted verification in systems and applications can reduce the likelihood of attacks due to the use of unknown or tampered systems/software.

Trusted Computing (TC) is a technology that is pushed and developed by the 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 expected by design goals. Incorporating trusted verification in systems and applications can reduce the likelihood of attacks due to unknown or tampered systems/software being used. By way of example, personal Computer (PC) trustworthiness, which is colloquially speaking, trustworthiness is to detect the integrity and correctness of a Basic Input Output System (BIOS) and an operating system when each PC is started, so that it is ensured that hardware configuration and the operating system are not tampered when a user uses a PC, and security measures and settings of all 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 loss stopping measures are immediately taken if the applications are found to be tampered.

Credibility is mainly realized through technical means of measurement and verification. The measurement is to collect the state of the detected software or system, the verification is to compare the measurement result with the reference value to see whether the measurement result is consistent with the reference value, if so, the verification is passed, and if not, the verification is failed. Trusted computing ensures trustworthiness by algorithms and keys embedded in trusted hardware by the chip vendor, and by measurement and verification of the software stack by an integrated dedicated microcontroller. According to the classification of security chips and Trusted Software base (Trusted Software Stack) running thereon, there are three major types of Trusted computing standards currently prevailing in the industry: a Trusted Platform Module (TPM), a Trusted Cryptography Module (TCM), and a Trusted Platform Control Module (TPCM).

In the market, the TPM and the TCM are generally embedded inside the computing device as a root of trust of the computing device. The specification of the TPM chip is laid down by the TCG. The TCM is a domestic trusted computing technology, the function of the TCM corresponds to that of the TPM, and the difference is that the cryptographic technology in the TCM is independently developed by China, so that the national information security is guaranteed.

TPCM is a trusted standard (currently a corporate standard in China) proposed based on a localization idea. Compared with the TPM and the trusted cryptography service module, the TPCM makes a large change to the hardware and Trusted Software Stack (TSS) architecture. The TPCM has the greatest advantages of being capable of being used as an active measure and using a cipher algorithm independently developed by China. However, TPCM has not been commercially scaled and product matured on a computing host.

The embodiment of the application is mainly introduced to the trusted password service module.

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

The trusted cryptography service module in the related art is usually located outside the chip (or the secure architecture system), and functions through host software calling in a passive hooking manner, and only functions through host software calling, and the security capability of the trusted cryptography service module completely depends on the security of the host system, and cannot substantially improve the active defense capability of the computer system. Once the host is controlled by an attacker, the role of the trusted cryptographic service module is played. Therefore, the security of the computer system cannot be effectively improved by adopting the trusted password service module arranged in a plug-in mode.

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

In addition, the trusted cryptographic service module can play a role only by calling the host, and the trusted cryptographic service module can be called only after the host software is started, so that the trusted cryptographic service module cannot measure the firmware in the chip starting process, and the safety of the system can be influenced.

Based on this, the embodiment of the application provides a method for realizing secure trusted boot, which not only can actively measure the firmware in the chip boot process, but also can realize trusted boot of the chip, thereby ensuring the security of the system.

In general, the method for implementing secure trusted boot proposed by the present application covers the following scenarios.

In one embodiment, the trust chain construction of the secure boot technology is realized by using hardware root of trust technology to verify the firmware step by step, 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 set in a hardware root of trust, has a non-tamper characteristic, is the first section of code of power-on start, and is the source of all trust chains. In this case, to implement the secure boot technique, the hardware root of trust needs to be executed first, and then, the signature verification is performed step by step on one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware. Illustratively, the progressive signature verification is embodied in: and signature verification is carried out on the BL2 firmware through the hardware trusted root, then signature verification is carried out on the BL31 firmware through the BL2 firmware, and signature verification is carried out on the BL32 and/or BL33 firmware respectively through the BL31 firmware.

In one embodiment, on the basis of implementing the secure boot technology, a TCM service module and/or a TCM cryptographic module is further used to perform trusted measurement, trusted storage and trusted reporting on firmware loaded and run in the boot process, so as to implement the trust chain construction of the trusted computing technology.

The implementation process may include: and powering on, executing a hardware root of trust, and then performing step-by-step signature verification on one or more of BL2 firmware, BL31 firmware, BL32 firmware and BL33 firmware. Illustratively, the stage is embodied as: signature verification is carried out on BL2 firmware through a hardware trusted root, and then signature verification is carried out on BL31 firmware, BL32 firmware and/or BL33 firmware one by one through BL2 firmware; or, the BL31 firmware is subjected to signature verification by the BL2 firmware, and then the BL33 firmware is subjected to signature verification by 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 is subjected to self-test, and when the self-test is successful, the TCM service module and/or the TCM cryptographic module are loaded and operated, and when the loading is successful, at least one of BL31 firmware, BL32 firmware and BL33 firmware is measured by the TCM service module and/or the TCM cryptographic module, for example, BL31 firmware, BL32 firmware and BL33 firmware are measured one by the TCM service module and/or the TCM cryptographic module; or, measuring BL31 firmware and BL33 firmware one by utilizing TCM service module and/or TCM cryptographic module; 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, related implementations will be specifically set forth.

Further, the method of the embodiment of the present application may be applied to a security architecture system, where the security architecture system may be loaded with an rich execution environment subsystem, a trusted execution environment subsystem, and a secure element subsystem. The security architecture system may be the above-described homogeneous three-level architecture, or may be a heterogeneous three-level architecture. The descriptions of the rich execution environment subsystem, the trusted execution environment subsystem, and the secure element subsystem may be referred to the foregoing description, and for brevity, are not described in detail here.

The security architecture system of the embodiment 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 present application may include a TCM cryptography module and a TCM service module. The TCM service module and the TCM cryptographic module are combined to form a core technology or an important component of the trusted computing cryptography 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 realization of platform security functions such as platform integrity, platform identity trust, 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 may be capable of providing trusted base computing resources for the trusted cryptographic service module. For example, the TCM cryptographic module may provide computing resources such as cryptographic operations, true Random Number Generators (TRNGs), secure storage, and the like for the trusted cryptographic service module. The only interface for interaction between the TCM cryptographic module and the system is a set of standard interfaces, which are china standards developed by the china code authority in conjunction with the Information Technology (IT) corporation.

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 an application) to call a resource in the TCM cryptographic module. In some embodiments, the TCM service module may call the TCM cryptographic module through the service interface, thereby providing security services such as trusted metrics, trusted reports, trusted storage, and the like for the application. In other embodiments, the TCM service module may also manage resources of the TCM cryptographic module, or the TCM service module may also hide complex function commands in the TCM cryptographic module, thereby reducing complexity of using the TCM cryptographic module by a user. The interface standard of the TCM service module is also provided by the China national code administration in combination with the domestic information technology IT enterprises. Different manufacturers have different design implementations of TCM service modules.

The embodiment of the present application does not specifically limit the construction manner 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 TCM cryptographic module may be built in the same subsystem except the rich execution environment subsystem. The TCM service module and the TCM password module are built in the same subsystem, so that the integration level of the trusted password service module can be improved, and the complexity of calling the trusted password service module by the system is reduced.

In some embodiments, the TCM service module and the TCM cryptographic module may be built into a trusted execution environment subsystem. Software and hardware security architectures, such as Trustzone and software protection extensions (SGX), are applied in the trusted execution environment subsystem, and can provide additional security guarantee of the execution environment for the TCM service module and the TCM cryptographic module placed 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 computing hardware resources 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 a computing environment, and can provide additional security guarantee of an execution environment for the TCM service module and the TCM cryptographic module arranged in the secure element subsystem.

Because the trusted execution environment subsystem and the secure element subsystem both have a secure operating environment, the TCM service module and the TCM cryptographic module are built in the trusted execution environment subsystem and the secure element subsystem, and the requirements of the TCM service module and the TCM cryptographic module on security can be met.

Because the TCM service module and the TCM cryptographic module are constructed in the security architecture system, the TCM service module and the TCM cryptographic module can actively measure without depending on the calling of a host. In addition, because the TCM service module and the TCM password module are built in the security architecture system, the TCM service module and the TCM password module can measure the firmware in the starting process of the security architecture system, and therefore the security of the system is guaranteed. For example, all codes introduced in the starting process can be checked and signed step by step from the in-chip root of trust, 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 used for measuring the firmware in the starting process, and the measurement result is recorded. The measurement result is used for realizing the trusted start of the security architecture system. The firmware in the boot process may include one or more of the following: BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

The measurement in the embodiment of the present application may include performing trusted measurement, trusted storage, and trusted reporting on firmware/software loaded by a system by using a TCM module, thereby implementing the trust chain construction of a trusted computing technology.

Embodiments of the present application may store the measurement result, for example, store the measurement result in a Platform Control Register (PCR). After networking, the measurement result in the PCR is remotely verified, so that trusted starting is realized. Because the trusted cryptographic service module has the function of trusted storage, the measurement result can be trusted stored by using the trusted cryptographic service module, and the credibility of the measurement result can be ensured.

Of course, since the measurement result needs to be remotely verified, the booting process of the system is continued regardless of the trusted measurement result.

Trusted boot also typically relies on secure boot to establish a root of trust for the metrics to ensure that the results of the metrics recorded in the PCRs are trusted.

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

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

FIG. 6 shows a schematic diagram of a boot process of a computing device. The numbers on the arrows indicate the start-up sequence. Starting from Boot loader (BL 1) firmware in a Boot-only memory (ROM), starting in the sequence BL1 → BL2 → BL31 → BL32 → BL33 → OS, until an Operating System (OS) interface is started, the start is completed. Of course, the computing device may also be started according to other starting sequences, which is not specifically limited in this embodiment of the application.

As shown in fig. 6, the secure world includes firmware such as Boot ROM (diskless Boot ROM interface), platform initialization firmware (platform initialization firmware), EL3 runtime firmware (i.e. BL 31), and open portable TEE (OP-TEE) (e.g. BL 32). The OP-TEE is an open source project, completely realizes a trusted execution software and hardware environment, and can greatly enhance information safety in the environment. The common world includes firmware as follows: U-Boot/UEFI firmware (BL 33), kernel (kernel of operating system OS). The BL33 firmware may be a Basic Input Output System (BIOS) firmware. In the general world, the execution authority of EL0, EL1, EL2, and EL3 increases in order. Wherein the UEFI firmware is configured to operate at the common world EL2 level and the OP-TEE is configured to operate at the secure world EL1 level. When UEFI (BL 33) startup is entered, the OP-TEE has already finished startup, and the UEFI and the OP-TEE can communicate through a Security Monitor Call (SMC) interface. Therefore, when UEFI is started and integrity and security verification is carried out on the mirror image file, certain functions can be realized by calling an OP-TEE corresponding interface of the secure world in a mode of triggering SMC by the common world, and thus, a verification process related to the mirror image file can be transmitted to the secure world for verification and a verification result is returned to the common world.

The BL1 firmware may be referred to as a Trusted Boot ROM (Trusted Boot ROM), which is the earliest firmware to run during Boot, and is also stored in a read-only memory (ROM). The BL1 firmware is not co-located with the BIOS of the computing device, and in some types of trusted firmware technology, the BL1 firmware is the root of trust for everything. The BL1 firmware can be used to initialize core hardware of the computing device (e.g., trusted static random access memory (Trusted SRAM), serial port, etc.) and find the BL2 hardware, and in some cases, the BL1 firmware can perform a checkmark on the BL2 firmware. The BL1 firmware runs at the EL3 privilege level.

The BL2 Firmware may be referred to as (Trusted Boot Firmware), the BL2 Firmware also runs at the EL3 privilege level, and the significant difference between the BL2 Firmware and the BL1 Firmware is that the BL2 Firmware may be stored on an external Trusted storage device, and its trust may be based on the verification of it by the BL1 Firmware. The BL2 firmware will initialize some critical security hardware and software frameworks, and after the initialization is completed, the BL2 firmware will find the BL31. In some embodiments, BL31 firmware is authenticated by the BL2 firmware signature.

The BL31 Firmware may be referred to as EL3 Runtime Firmware (EL 3 Runtime Firmware). The BL31 firmware also runs at the EL3 privilege level, which is the last security barrier of the EL3 privilege level. Unlike BL1 firmware and BL2 firmware, which are run once, BL31 firmware continues to provide security-related services to the general world (Non-Secure) through Security Monitor Calls (SMC).

The BL32 firmware may include an Open Portable Tee operating System (OPTee OS), which may refer to an 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. The BL31 firmware can be signed to the BL32 firmware. In some cases, after the OPTee OS runs, the BL31 firmware of the EL3 is returned, the BL31 firmware finds the BL33 firmware, and the BL31 firmware can also check the BL33 firmware.

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

In some embodiments, the present application embodiments may utilize 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 to improve the security of system. In some embodiments, some of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware may be measured using the TCM cryptographic module, while another of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware may be measured using the TCM service module and the TCM cryptographic module.

For example, the BL31 firmware, the BL32 firmware, and the BL33 firmware may be measured one by using the TCM service module and/or the TCM cryptographic module, 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, when the BL32 firmware is not included, the BL31 firmware and the BL33 firmware may be measured one by the TCM service module and/or the TCM cryptographic module, and if the measurement is successful, the BL31 firmware and the BL33 firmware may be loaded and run one by one.

The starting process of the safety architecture system is generally divided into the following stages, namely a BL1 stage, a BL2 stage, a BL31 stage, a BL32 stage and a BL33 stage. According to the starting sequence, after the safety architecture system is started, the BL1 firmware is executed firstly, then the BL2 firmware is verified, and the BL2 firmware starts the BL31 firmware or the BL32 firmware according to specific design. The BL32 firmware may only exist if there is BL31 firmware, and is signed and load-started.

Since the BL1 firmware is the first firmware in the system boot process, and the BL1 firmware is a piece of non-falsifiable firmware code, the measurement is performed from the 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 root of trust for a secure architecture system, or a hardware root of trust, or the like.

The embodiment of the present application does not specifically limit the starting sequence of the firmware. For example, the boot sequence of the firmware may be BL1 firmware → BL2 firmware → BL31 firmware → BL32 firmware → BL33 firmware, as shown in the boot sequence of fig. 6. For another example, the firmware may be started in the order BL1 firmware → BL2 firmware → BL31 firmware → BL33 firmware → BL32 firmware. For another example, the firmware may be started in the sequence BL1 firmware → BL2 firmware → BL33 firmware → BL31 firmware → BL32 firmware.

The division manner of the firmware is only an example, and the embodiment of the present application is not limited thereto, and the firmware may be divided in other manners according to the embodiment of the present application. For example, the Feiteng system software stack divides the firmware into a Feiteng root of trust (PBR) layer and a Feiteng base firmware (PBF) layer, wherein the PBF layer comprises PBF-BL1, PBF-BL2, PBF-BL31, PBF-BL32 and PBF-BL33.PBR is a root of trust, and PBF-BL1 and PBF-BL2 are platform initialization firmware.

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

The following describes a starting process of the embodiment of the present application with respect to different construction manners of the TCM service module and the TCM cryptographic module in the security architecture system. Hereinafter, the TCM service module and the TCM cryptographic module may be collectively referred to as a TCM module, that is, the TCM module may include a TCM service module and a TCM cryptographic module.

Example 1

The TCM service module and the TCM cryptographic module are constructed in the 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 operate in 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 the boot process is introduced, a system software stack of the homogeneous three-level architecture in the embodiment of the present application is introduced with reference to fig. 7.

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

The basic firmware is mainly used for basic initialization of the chip and provides related services. For example, the base 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 (SPM) calls, and so on. Where RAS represents reliability, availability and serviceability analysis. In addition, the base firmware may also be responsible for loading a secure operating system running in a secure state, such as a TEE OS.

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 (UEFI) facing to the fields of desktop, server, etc., or may be implemented as a Boot loader (U-Boot) facing to the embedded field.

In addition, the base firmware, the system firmware, and the operating system may communicate with an out-of-band control system (e.g., embedded Controller (EC), baseboard Management Controller (BMC), etc.).

As shown in fig. 7, a TCM service module and a TCM password module are arranged in the secure element subsystem, and are used for performing signature verification and authentication on a code in a secure boot process. The TCM cryptographic module provides hardware-based standard services such as TRNG, trusted root key, secure storage cryptographic operation, signature verification and the like. The trusted root key may include a trusted storage root, a trusted metrics root, and a trusted reports root. The TCM service module may implement services including, but not limited to, trusted metrics, trusted reports, trusted storage, and the like by invoking the TCM cryptographic module.

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

Step S810: and responding to the power-on request, and executing a starting process. The BL2 firmware is loaded and run. 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 signature authentication is carried out on the BL2 firmware by using the trusted root. The root of trust may be, for example, BL1 firmware. And when the BL2 firmware is successfully authenticated, the BL2 firmware is operated again. If the BL2 firmware authentication fails, the boot process may be exited and the secure/trusted boot fails. By performing signature authentication on the BL2 firmware, the integrity and the correctness of the BL2 firmware can be guaranteed.

The root of trust may be code that runs directly after the chip is powered on. The root of trust may be executed on an SE engine of the secure element subsystem or on a 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 TZC, double Data Rate (DDR), peripheral component interconnect express (PCIe), network-on-chip (NoC), and the like may be initialized. The processor here may be the 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 can be a program preset in the system.

If the self-check passes, the step S830 is continuously executed. If the self-test fails, the startup procedure may be exited.

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

After the BL2 firmware runs, the hardware resources of the TCM cryptographic module can be self-checked. And under the condition that the hardware resource self-checking of the TCM cryptographic module passes, the TCM cryptographic module and the TCM service module are loaded and operated, so that the safety of the system is ensured. And if the self-checking of the TCM cryptographic module fails, the starting process is exited.

The TCM crypto module may include a service interface that may be used by firmware or the TCM service module to invoke a service. The steps can also initialize the service interface of the TCM cryptographic module to provide calling service for initialization when the system firmware runs.

Step 840: and measuring one or more of BL31 firmware, BL32 firmware and BL33 firmware by using the TCM cryptographic module and the TCM service module. For example, the BL31 firmware, the BL32 firmware and the BL33 firmware are measured one by the TCM cryptographic module and the TCM service module, 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, when 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.

Before the measurement is performed on the BL31 firmware, the BL32 firmware and the BL33 firmware, the running environment of the secure element subsystem may be self-checked. It is determined whether there is BL31 firmware, BL32 firmware, and BL33 firmware, and the measurement and loading of firmware present in the system is booted.

In the embodiment of the application, the TCM cryptographic module and the TCM service module can be used to measure one or more of BL31 firmware, BL32 firmware and BL33 firmware, and the measurement sequence may be consistent with the starting sequence of the BL31 firmware, the BL32 firmware and the BL33 firmware. If the measurement fails, the startup procedure 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 the embodiments of the present application may be provided in a computing device. After the above firmware measurement is completed, the embodiments of the present application may further use the TCM service module and the TCM cryptographic module to measure the program of the operating system kernel of the computing device. After the measurement result is obtained, the measurement result can be safely stored. The startup procedure may be exited if the measurement fails.

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

It can be seen from the above flows that the embodiment of the present application can determine the measurement result of each firmware, and if any firmware measurement fails, the start-up flow can be exited, so that the security of the start-up process can be ensured.

The start-up procedure is described in more detail below with reference to fig. 9. It should be noted that the flow shown in fig. 9 is only for convenience of understanding, and the present application is not limited to the embodiment described above.

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

Step S904: and carrying out safety self-check on the state of the chip. The self-test process may include a self-test of core hardware such as TRNG, cryptographic algorithm hardware engines, etc. If the self-test fails, subsequent secure/trusted boot operations may not be performed.

Step S908: if the chip self-test is successful, the processor core can be initialized, such as hardware like TZC, DDR, PCIe, noC, etc. In addition, the TCM cryptographic module 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 system firmware runtime.

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

Step S912: and if the BL2 firmware is successfully authenticated, operating the BL2 firmware. The processor platform is initialized and the TCM service modules are loaded. In some embodiments, the TCM service module may also be loaded in step S908, that is, the TCM password module and the TCM service module may be loaded in step S908. The environment self-checks, determines whether there is BL31 firmware, BL32 firmware, and BL33 firmware, and directs the measurement and loading of these three pieces of firmware.

Step S914: and measuring the BL31 firmware/BL 32 firmware/BL 33 firmware by utilizing the TCM service module and the TCM cryptographic module, and recording a measurement result. If the measurement fails, the secure/trusted boot flow may be exited.

Step S916: in case of successful measurement of the BL31 firmware/BL 32 firmware/BL 33 firmware, measuring a system kernel environment program by using the TCM service module and the TCM cryptographic module, and storing the measurement result. If the measurement fails, the secure/trusted boot flow may be exited.

Step S918: the system kernel is loaded, the hardware resources of the computing device are initialized, and the operating system is booted.

Step S920: the secure/trusted boot is completed.

The public key algorithm of the embodiment of the present application includes, but is not limited to, SM2 and elliptic cryptography (ECC). The SM2 and ECC are merely examples, and should not be construed as limiting.

Example two

The TCM service module and the TCM cryptographic module are built in the 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 operate in different processor cores. Assuming that the trusted execution environment subsystem runs on the second processor core and the secure element subsystem runs on the third processor core, the second processor core is capable of processing programs or services in the trusted execution environment subsystem and the third processor core is capable of processing programs or services in the secure element subsystem.

Before the boot process is introduced, a system software stack of a heterogeneous three-level architecture in the embodiment of the present application is introduced with reference to fig. 10.

Differences between the system software stack of fig. 10 and the system software stack of fig. 7 include: the initialization service and the related firmware for secure boot and root of trust are located in the secure element subsystem. The underlying hardware of the processor in fig. 10, i.e., the firmware components, may be used to implement initialization services, power management, recovery, SPM calls, security monitor, RAS, and the like.

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

Step S1110: the 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 and can operate independently without depending on the trusted execution environment subsystem, the firmware in the secure element subsystem can be loaded and operated by using the dedicated core, thereby initializing the secure element subsystem.

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

In some embodiments, prior to step S1110, the SE firmware may be signed with the trusted root. In the event that the SE firmware authentication passes, the SE firmware is reloaded and run. For example, after the chip is powered on, the trusted root is executed first. The root of trust may be located in the secure element subsystem. And carrying out self-checking on the state of the chip. And if the self-checking fails, the subsequent starting operation process is not executed. The self-test process may include self-testing of core hardware resources such as TRNGs, cryptographic algorithm engines, and the like. And in the case that the chip self-test passes, signature authentication can be performed on the SE firmware by using the trusted root. And if the authentication fails, exiting the starting process.

In the event that the SE firmware authentication passes, the SE firmware may be loaded and run. Further, core modules in the secure element subsystem, such as components of a cryptographic algorithm engine, OTP, etc., may be initialized.

Step S1120: loading and running the TCM service module and the TCM cryptographic module in the secure element subsystem. Because the secure element subsystem is provided with a special processor core, and the trusted root is arranged in the secure element subsystem, the TCM service module and the TCM code module can be loaded and operated after the trusted root is operated.

In some embodiments, a TCM cryptographic module (e.g., a software portion of the 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-test program of the trusted cryptographic service module may be run. If the self-test fails, the startup procedure may be exited. The hardware self-test program may be a program preset in the secure element subsystem.

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

For example, the BL31 firmware, the BL32 firmware and the BL33 firmware are measured one by the TCM service module and the TCM cryptographic module, 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, when 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.

Since the TCM service module and the TCM cryptographic module are loaded and run, the TCM service module and the TCM cryptographic module can be used to measure the firmware in the boot process.

In some embodiments, BL2 firmware may be measured using a TCM service module and a TCM cryptographic module. In the event that the BL2 firmware metric succeeds, the BL2 firmware can be run and the processor core of the secure architecture system initialized. If the measurement fails, the startup procedure 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 be operated in preference to most of firmware required to be operated in the boot process, and the TCM service module and the TCM cryptographic module may measure all of BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, thereby performing an active measurement function of trusted computing in the secure/trusted boot process.

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

In some embodiments, after the trusted root runs, the embodiment of the present application may further perform signature authentication on the BL2 firmware by using the trusted root. And running the BL2 firmware when the BL2 firmware is successfully authenticated.

In some embodiments, the TCM service module and TCM crypto module may be loaded and run after the BL2 firmware runs. And then measuring one or more of BL31 firmware, BL32 firmware and BL33 firmware by using the TCM service module and the TCM cryptographic module. That is, the TCM service module and the TCM crypto module may not measure the BL2 firmware.

In some embodiments, in the embodiments of the present application, before the TCM service module and the TCM cryptographic module are loaded and run, a hardware resource of the TCM cryptographic module may be self-checked. And in the case of passing the self-checking, the TCM service module and the TCM password module are loaded and operated.

It should be noted that, besides measuring one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware through the TCM service module and/or the TCM cryptographic module, the secure boot process may be performed simultaneously, that is, the firmware is subjected to step-by-step signature authentication by using the root of trust, where the step-by-step signature authentication may include: and performing signature authentication on the BL2 firmware through the trusted root, performing signature authentication on the BL31 firmware through the BL2 firmware, performing signature authentication on the BL32 firmware and/or the BL33 firmware through the 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 above firmware measurement is completed, the embodiments of the present application may further use the TCM service module and the TCM cryptographic module to measure the program of the operating system kernel of the computing device. After the measurement result is obtained, the measurement result can be safely stored. The startup procedure may be exited if the measurement fails.

After the program metrics of the operating system kernel are complete, the operating system kernel may be loaded to initialize the hardware resources of the computing device and to boot the operating system to complete the booting of the computing device. It can be seen from the above flows that the embodiment of the present application can determine the measurement result and the signature authentication result of each firmware, and if any one of the firmware measurement fails or the signature authentication fails, the secure/trusted boot process can be exited, so that the security of the secure/trusted boot process can be ensured.

The start-up procedure is described in more detail below with reference to fig. 12. It should be noted that the flow shown in fig. 12 is only for convenience of understanding, and the present application is not limited to the embodiment described above.

Step S1202: and powering on the chip and executing the trusted root. The root of trust may be located in the secure element subsystem.

Step S1204: and carrying out safety self-check on the state of the chip. The self-test process may include a self-test of core hardware such as TRNG, cryptographic algorithm hardware engines, etc. If the self-test fails, subsequent secure/trusted boot operations may not be performed.

Step S1206: if the chip self-check is successful, signature authentication can be performed on the SE firmware by using the trusted root. For example, the SE firmware may be signed using a public key algorithm. Public key algorithms include, but are not limited to, SM2 and ECC. The SM2 and ECC are merely 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. Initializing core modules in the secure element subsystem, such as components of a cryptographic engine algorithm, OTP, and the like. Loading and running a TCM service module and a TCM cryptographic module 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 system firmware runtime.

Step 1210: and verifying BL2 firmware by using a TCM service module and a TCM cryptographic module. If the signature verification fails, the secure/trusted boot process may be exited.

Step S1212: and under the condition that the BL2 firmware is successfully checked, loading and running the BL2 firmware to finish the initialization of the processor platform. The environment self-checks, determines whether there is BL31 firmware, BL32 firmware, and BL33 firmware, and directs the measurement and loading of these three pieces of firmware.

Step S1214: and measuring the BL31 firmware/BL 32 firmware/BL 33 firmware by utilizing the TCM service module and the TCM cryptographic module, and recording a measurement result. If the measurement fails, the secure/trusted boot flow may be exited.

Step S1216: in case of successful measurement of the BL31 firmware/BL 32 firmware/BL 33 firmware, measuring a system kernel environment program by using the TCM service module and the TCM cryptographic module, and storing the measurement result. If the measurement fails, the secure/trusted boot flow may be exited.

Step S1218: the system kernel is loaded, the hardware resources of the computing device are initialized, and the operating system is booted.

Step S1220: the secure/trusted boot is completed.

The public key algorithm of the embodiment of the present application includes, but is not limited to, SM2 and ECC. The SM2 and ECC are merely examples, and should not be construed as limiting.

In addition to the above-described scheme for measuring firmware, the embodiments of the present application may also perform a gradual signature verification on firmware. For example, the BL2 firmware is signed and authenticated by the root of trust, and then, the BL31 firmware may be signed and authenticated by the BL2 firmware, and the BL32 and/or BL33 firmware may be signed and authenticated by the BL31 firmware, respectively. The starting process can be terminated when any one level of verification fails, and in this way, the safe starting of the safety architecture system can be realized. Optionally, in some embodiments, the firmware running during the secure architecture system boot process may not include the BL32 firmware, and at this time, the BL31 firmware may verify the BL33 firmware.

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

An embodiment of the present application further provides a security architecture system, and a 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 security architecture system can be loaded with a rich execution environment subsystem, a trusted execution environment subsystem and a security element subsystem, wherein a trusted cryptographic service module is constructed in the security architecture system, the trusted cryptographic service module 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 is configured to: and in the starting process of the safety architecture system, measuring the firmware operated in the starting process, and recording the measurement result.

In some embodiments, the TCM service module and the TCM cryptographic module are implemented in the trusted execution environment subsystem, or the TCM service module and the TCM cryptographic module are implemented in 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 implemented in the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem operate in a first processor core, the secure architecture system is configured to perform a self-check on 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 the self-check; the TCM cryptographic module is configured to perform a metric on the BL2 firmware; the safety architecture system is configured to run the BL2 firmware, initialize a processor core of the safety architecture system, and load and run the TCM service module; the TCM cryptographic module and the TCM service module are configured to perform metrics on one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware.

In some embodiments, the TCM service module and the TCM cryptographic module are implemented in the secure element subsystem, and the secure element subsystem and the trusted execution environment subsystem operate in a first processor core, the secure architecture system is configured to perform a self-check on 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 the self-check; the TCM cryptographic module and the TCM service module are configured to perform measurement on 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, and the BL33 firmware.

In some embodiments, the secure architecture system has a root of trust built in, the secure architecture system configured to: executing the root of trust before the running of the BL2 firmware; and performing signature authentication on the BL2 firmware by using the trusted root.

In some embodiments, the TCM service module and the TCM cryptographic module are implemented in 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 running the TCM service module and the TCM cryptographic module in the secure element subsystem; the TCM service module and the TCM crypto 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 crypto module are configured to perform metrics on 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 crypto module are configured to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware.

In some embodiments, the secure architecture system has a root of trust built in, the secure architecture system configured to: before the loading and running of the firmware in the secure element subsystem, performing signature authentication on the firmware in the secure element subsystem through the trusted root; and loading and running the firmware in the secure element subsystem under the condition that the firmware in the secure element subsystem passes the authentication.

In some embodiments, the security architecture system is disposed in a computing device, the TCM service module and the TCM cryptographic module configured to measure a program of an operating system kernel of the computing device; the security architecture system is configured to: loading the operating system kernel to initialize hardware resources of the computing device and to boot the operating system to complete the booting 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 secure architecture system 1310 may be any of the secure architecture systems described above.

The embodiment of the present application does not specifically limit the specific form of the computing device. For example, the computing device may be a mobile terminal, a desktop computer, a tablet computer, a Personal Computer (PC), a Personal Digital Assistant (PDA), a smart watch, a netbook, a wearable electronic device, an Augmented Reality (AR) device, and so forth.

Fig. 14 is a schematic structural diagram of an apparatus for implementing trusted boot according to an embodiment of the present application. The apparatus may be used to implement the methods 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. The memory 1410 may be used to store instructions. The controller 1420 may be configured to perform the methods described in any of the embodiments above 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 (CPU). Alternatively, the processor may be another general-purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, 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.

An embodiment of the present application further 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 causes the computer to execute the method performed by the security architecture system (such as TCM service module and/or TCM crypto module) in the embodiments of the present application.

The embodiment of the application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to the security architecture system provided by the embodiments of the present application, and the program enables the computer to execute the method executed by the security architecture system (such as TCM service module and/or TCM crypto module) in the 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 enables the computer to execute the method performed by the security architecture system (such as the TCM service module and/or the TCM cryptographic module) in the various embodiments of the present application.

In the above embodiments, all or part of the implementation may be realized 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, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions can 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 can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes 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 (DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), among others.

Those of ordinary skill in the art will appreciate that the various illustrative 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 implementation. 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 the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed 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 can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

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

The above description is only for the 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 of the changes or substitutions within the technical scope of the present application, and shall 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 trusted boot is characterized in that the method is applied to a safe architecture system, the safe architecture system is provided with a rich execution environment subsystem, a trusted execution environment subsystem and a safe element subsystem, a trusted cryptographic service module is constructed in the safe architecture system, the trusted cryptographic service module 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 method comprises the following steps:

in the starting process of the security architecture system, the TCM service module and/or the TCM cryptographic module are used for measuring the firmware running in the starting process, and the measurement result is recorded.

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

3. The method according to claim 1, wherein the measuring the firmware running during the boot process by the TCM service module and/or the TCM cryptographic module comprises:

utilizing the TCM service module and/or the TCM cryptographic module to perform measurements 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 implemented in the secure element subsystem, and wherein the secure element subsystem and the trusted execution environment subsystem operate in a first processor core,

the utilizing 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:

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

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

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

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 of claim 4, further comprising:

and performing signature authentication on the BL31 firmware by utilizing the BL2 firmware.

6. The method according to claim 4 or 5, wherein a root of trust is built in the secure architecture system, and before the running of the BL2 firmware, the method further comprises:

executing the trusted root;

and performing signature authentication on the BL2 firmware by using the trusted root.

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

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 running the TCM service module and the TCM cryptographic module in the secure element subsystem;

utilizing the TCM service module and the TCM cryptographic module to perform measurements on one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

8. The method of claim 7, wherein the utilizing the TCM service module and the TCM cryptographic module measures 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 cryptographic module;

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.

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

signing and authenticating firmware in the secure element subsystem through the trusted root;

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

and loading and running the firmware in the secure element subsystem under the condition that the firmware in the secure element subsystem passes the authentication.

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

measuring programs of an operating system kernel of the computing device by utilizing the TCM service module and the TCM password module;

loading the operating system kernel to initialize hardware resources of the computing device and to boot the operating system to complete the booting of the computing device.

11. A safety architecture system is characterized in that the safety architecture system is provided with a rich execution environment subsystem, a trusted execution environment subsystem and a safety element subsystem, a trusted cryptographic service module is constructed in the safety architecture system, the trusted cryptographic service module 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 security architecture system is configured to: in the starting process of the security architecture system, the TCM service module and/or the TCM password module are used for measuring the firmware running in the starting process, and the measuring result is recorded.

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

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

14. The security architecture system of claim 13, wherein the TCM services module and the TCM cryptography module are implemented in the secure element subsystem, and wherein the secure element subsystem and the trusted execution environment subsystem are run by a first processor core, the security architecture system configured to:

loading and operating the TCM service module and the TCM password module under the condition that the self-check passes;

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

16. The secure architecture system of claim 14 or 15, wherein the secure architecture system has a root of trust 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 services module and the TCM cryptography module are implemented in the secure element subsystem, the secure element subsystem operating in a second processor core, the trusted execution environment subsystem operating in a third processor core, the secure architecture system configured to:

initializing the second processor core and the third processor core;

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

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

before the loading and running of the firmware in the secure element subsystem, performing signature authentication on the firmware in the secure element subsystem through the trusted root;

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

21. A computing device, comprising: a security architecture system as claimed in any one of claims 11 to 20.

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