A security architecture system, a method for implementing secure and trustworthy boot, and a computing device

Abstract

The present application provides a security architecture system, a method for implementing secure and trustworthy boot, and a computing device. Among them, a security service platform including a TCM and a TPCM control module is integrated in the third subsystem of the security architecture system. Not only is the hardware trusted root technology used to verify the firmware step by step to realize the construction of the trust chain of the secure boot technology; at the same time, the TCM service module and / or the TCM cryptographic module are used to perform trusted measurement, trusted storage, and trusted reporting on the firmware loaded and running during the boot process to realize the construction of the trust chain of the trusted computing technology. At the same time, the second subsystem and the third subsystem can run on the same processor core (i.e., the first processor core), rather than running separately on different processor cores. In this way, processor resources can be saved; in addition, by setting in a homogeneous manner, the design complexity can be reduced.

Description

Technical Field

[0001] This specification relates to the field of computer application technologies. Specifically, it relates to trusted computing technologies in the field of computer application technologies. More specifically, it relates to a security architecture system, a method for implementing secure and trusted startup, and a computing device. Background Art

[0002] Trusted Computing (TC) is a technology promoted and developed by the TCG (Trusted Computing Group). One of the core objectives of trust is to ensure the integrity of systems and applications, thereby determining that the system or software is running in a trusted state as expected by the design objectives.

[0003] To gain the technological and industrial leadership in the field of trusted computing and ensure that the core technologies for international information security are in our own hands, China has introduced the TCM (Trusted Cryptography Module) standard in the field of trusted computing. TCM can measure the objects running in a computer system and implement an assessment of whether the measured objects are trusted. On the basis of the TCM standard, China has also introduced the TPCM (Trusted Platform Control Module) standard that integrates a customized control mechanism.

[0004] With the maturity of trusted computing technologies, trusted computing technologies have gradually been applied to various computing devices. How to make trusted computing technologies compatible with various computing devices is one of the directions that those skilled in the art strive for. Summary of the Invention

[0005] To solve the above technical problems, this application provides a security architecture system, a security service method, and a computing device to achieve the purpose of being compatible with TCM and TPCM to measure the firmware running during the startup process of a computing device, so as to meet the requirements for the trusted startup of various computing devices.

[0006] To achieve the above technical objectives, the embodiments of this application provide the following technical solutions:

[0007] In a first aspect, a security architecture system is provided, including: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in a first processor core. The security architecture system constructs a security service platform, which is built-in with a Trusted Cryptography Module (TCM). The security service platform also carries a TPCM control module, which is used to call the TCM in a software manner. The TCM and the TPCM control module run in the third subsystem. The security service platform is configured to:

[0008] In response to a power-on request, execute a startup process. During the startup process, use the TCM or the TPCM control module to measure the firmware running during the startup process and record the measurement result.

[0009] In this embodiment, by integrating a security service platform including a TCM and a TPCM control module in the security architecture system, and configuring the security service module to use the TCM or the TPCM control module to measure the firmware running during the startup process and record the measurement result during the startup process, the purpose of achieving trusted startup by compatible with two control routes of TCM and TPCM is realized, and the applicability of the security architecture system is improved.

[0010] At the same time, the second subsystem and the third subsystem can run on the same processor core (i.e., the first processor core), rather than running separately on different processor cores. In this way, processor resources can be saved; in addition, by setting in a homogeneous manner, the design complexity can be reduced.

[0011] In addition, it should be noted that in the related prior art, the implementation methods of external TPM and TCM will additionally increase the consumption of hardware resources in computer devices. The inventive concept proposed in this application can directly upgrade the settings of the processor in the traditional technology in scenarios not involving trusted computing; in scenarios involving trusted computing, the settings of the trusted technology in the processor can be directly updated. Here, the implementation solutions for the trusted technology can include: (one or more of external TPM and TCM; or, integrating a TPM inside the processor; or, integrating a TCM inside the processor).

[0012] In one embodiment, the security service platform using the TCM or the TPCM control module to measure the firmware running during the startup process is specifically used for:

[0013] Use the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0014] In this embodiment, the security service platform may selectively measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware during the startup process according to the actual situation of the computing device or the actual need for secure / trusted startup, so as to improve the applicability of the security architecture system to various application scenarios on the basis of ensuring the security of the security architecture system.

[0015] In one implementation, the security service platform executes the startup process. During the startup process, use the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically:

[0016] Run the BL2 firmware to initialize the processor core of the security architecture system;

[0017] Self-check the hardware resources of the TCM. In this step, the self-check of the hardware resources of the TCM may include the self-check of the hardware resources such as the random number generator of the TCM (for example, it can be a TRNG), the cryptographic algorithm hardware engine, etc.;

[0018] When the self-check of the hardware resources of the TCM passes, load and run the TCM and the TPCM control module;

[0019] Use the TCM or the TPCM control module to measure the BL2 firmware.

[0020] In this embodiment, select to measure part or all of the BL2 firmware and the BL31, BL32, and BL33 firmware. On the basis of ensuring the security of the security system architecture, it is beneficial to realize the trusted startup of the security architecture system and improve the efficiency of secure / trusted startup.

[0021] In addition, during the measurement process, by self-checking the hardware resources of the TCM cryptographic module, it is beneficial to ensure the reliability of the hardware required for measurement and the security of the measurement process.

[0022] In one implementation, after the security service platform runs the BL2 firmware, it is also used for:

[0023] Use the BL2 firmware to perform signature authentication on the BL31 firmware.

[0024] In this embodiment, the BL31 firmware is double-authenticated using the BL2 firmware and the TCM / TPCM control module, achieving an organic combination of secure / trusted boot and improving the security of the security architecture system.

[0025] In one implementation, the security service platform further includes a trusted root, and the trusted root includes the BL1 firmware;

[0026] Before running the BL2 firmware, the security service platform is further configured to:

[0027] Execute the trusted root to perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the boot process. If the self-check is successful, use the trusted root to perform signature authentication on the BL2 firmware;

[0028] When the security service platform runs the BL2 firmware, it specifically is configured to:

[0029] Run the BL2 firmware in the case where the BL2 firmware passes the authentication.

[0030] In this embodiment, taking the BL1 firmware as the trusted root and starting the execution from the trusted root ensures the security / trust of the entire boot chain and improves the security of the security architecture system.

[0031] In one implementation, the security service platform further includes a trusted root;

[0032] Before running the BL2 firmware, the security service platform is further configured to:

[0033] Execute the trusted root to perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the boot process. If the self-check is successful, run the TCM and the TPCM control module in the trusted root;

[0034] Use the TCM or the TPCM control module to perform signature authentication on the BL2 firmware;

[0035] When the security service platform runs the BL2 firmware, it specifically is configured to:

[0036] Run the BL2 firmware in the case where the BL2 firmware passes the authentication.

[0037] In this embodiment, by loading the TCM and the TPCM control module in the trusted root, the TCM and the TPCM control module can start running earlier, enabling complete measurement of the firmware during the boot process, achieving the security / trust of the entire boot chain, and improving the security of the security architecture system.

[0038] In one embodiment, the specific operations for the security service platform to load and run the TCM are as follows:

[0039] Load the TCM;

[0040] Run the self-check program of the TCM and obtain the self-check result returned by the self-check program of the TCM. If the self-check result is a self-check failure, terminate the startup process.

[0041] The self-check of the TCM can include the self-check of its core hardware resources, which can be implemented by the BL1 firmware in some embodiments. The self-check program of the TCM can be the built-in Self-Task program of the TCM. By running this self-check program, the security and trustworthiness of other resources of the TCM except for hardware resources can be guaranteed.

[0042] In one embodiment, the process for the security service platform to run the TPCM control module includes:

[0043] Run the TPCM control module, and set the flag bit of the TPCM control module according to the available status of the TPCM control module. The flag bit of the TPCM control module is used to indicate whether the TPCM control module is available;

[0044] The security service platform uses the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. The specific operations are as follows:

[0045] Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, use the TPCM control module to measure one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware;

[0046] If the flag bit of the TPCM control module indicates that the TPCM control module is not available, use the TCM module to measure one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0047] In this embodiment, when the TPCM control module is loaded, a flag bit indicating whether the TPCM control module is available is set. When the TPCM control module is available, the TPCM control module is preferentially used to measure the firmware running during the startup process, which is beneficial to giving full play to the technical advantages of the trusted computing 3.0 route and ensuring the autonomy, controllability, security, and trustworthiness of the secure / trusted startup process.

[0048] In one embodiment, the security architecture system is set in a computing device, and the security service platform is further used for:

[0049] Use the TCM or the TPCM control module to measure the operating system kernel of the computing device;

[0050] When the measurement result of the operating system kernel of the computing device passes, load the operating system kernel to initialize the hardware resources of the computing device and boot the operating system, thereby completing the startup of the computing device.

[0051] In this embodiment, an operation of using the TCM or the TPCM control module to measure the operating system kernel of the computing device is implemented, ensuring the full-chain security and trustworthiness of the startup process.

[0052] In a second aspect, a method for implementing secure and trustworthy startup is provided, which is applied to a security architecture system. The security architecture system includes: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in the first processor core. The security architecture system constructs a security service platform. The security service platform is built-in with a trusted cryptography module TCM. The security service platform is also equipped with a TPCM control module. The TPCM control module is used to call the TCM in a software manner. The TCM and the TPCM control module run in the third subsystem. The method for implementing secure and trustworthy startup includes:

[0053] In response to a power-on request, execute a startup process. During the startup process, use the TCM or the TPCM control module to measure the firmware running during the startup process and record the measurement result.

[0054] In one implementation, the step of using the TCM or the TPCM control module to measure the firmware running during the startup process includes:

[0055] Use the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0056] In a third aspect, a computing device is provided, including the security architecture system as described in any one of the above.

[0057] Fourthly, a starting device is provided and applied to a security architecture system. The security architecture system includes: a first subsystem, a second subsystem, and a third subsystem. The respective security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in a first processor core. A security service platform is built in the security architecture system. A trusted password module TCM is built in the security service platform. The security service platform is further equipped with a TPCM control module. The TPCM control module is used to call the TCM in a software manner. The TCM and the TPCM control module run in the third subsystem. The starting device includes:

[0058] A measurement module, configured to respond to a power-on request and execute a starting process. During the starting process, the firmware running during the starting process is measured by using the TCM or the TPCM control module, and the measurement result is recorded.

[0059] Fifthly, a computer-readable storage medium is provided. A computer program is stored on the computer-readable storage medium. When the computer program is run by a processor, the method for realizing secure and trusted starting as described above is implemented.

[0060] Sixthly, an embodiment of this specification provides a computer program product or a computer program. The computer program product includes a computer program. The computer program is stored in a computer-readable storage medium. A processor of the computer device reads the computer program from the computer-readable storage medium. When the processor executes the computer program, the steps of the method for realizing secure and trusted starting as described above are implemented.

[0061] As can be seen from the above technical solutions, an embodiment of this application provides a security architecture system, a method for realizing secure and trusted starting, and a computing device. Among them, a security service platform including a TCM and a TPCM control module is integrated in the third subsystem of the security architecture system, so that the security service platform can measure the firmware running during the starting process by using the TCM or the TPCM control module during the starting process, and store the measurement result. The stored measurement result can be used for remote verification after the computing device is connected to the network, meeting the requirements of trusted starting. The purpose of realizing trusted starting by being compatible with the TCM and TPCM standards is achieved based on the security architecture system.

[0062] At the same time, the second subsystem and the third subsystem can run on the same processor core (i.e., the first processor core), rather than running separately on different processor cores. In this way, processor resources can be saved. In addition, by setting in a homogeneous manner, the design complexity can be reduced. Description of the Drawings

[0063] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the accompanying drawings required for the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other accompanying drawings can also be obtained based on the provided accompanying drawings.

[0064] Figure 1 The structural schematic diagram of a security architecture system provided for an embodiment of this specification;

[0065] Figure 2 The flowchart of a method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0066] Figure 3 The flowchart of another method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0067] Figure 4 The flowchart of yet another method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0068] Figure 5 The structural schematic diagram of another security architecture system provided for an embodiment of this specification;

[0069] Figure 6 The flowchart of still another method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0070] Figure 7 The flowchart of an optionally implemented method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0071] Figure 8 The structural schematic diagram of yet another security architecture system provided for an embodiment of this specification;

[0072] Figure 9 The flowchart of another optionally implemented method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0073] Figure 10 The structural schematic diagram of still another security architecture system provided for an embodiment of this specification;

[0074] Figure 11 The flowchart of yet another optionally implemented method for realizing secure and trustworthy startup provided for an embodiment of this specification;

[0075] Figure 12Schematic flowchart of yet another alternative method for implementing secure and trustworthy boot provided for an embodiment of this specification;

[0076] Figure 13 Schematic flowchart of a method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0077] Figure 14 Schematic structural diagram of an alternative secure architecture system provided for an embodiment of this specification;

[0078] Figure 15 Schematic structural diagram of another alternative secure architecture system provided for an embodiment of this specification;

[0079] Figure 16 Schematic structural diagram of yet another alternative secure architecture system provided for an embodiment of this specification;

[0080] Figure 17 Schematic flowchart of another method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0081] Figure 18 Schematic structural diagram of yet another alternative secure architecture system provided for an embodiment of this specification;

[0082] Figure 19 Schematic flowchart of yet another method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0083] Figure 20 Schematic structural diagram of a secure architecture system provided for another embodiment of this specification;

[0084] Figure 21 Schematic flowchart of yet another method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0085] Figure 22 Schematic structural diagram of another secure architecture system provided for another embodiment of this specification;

[0086] Figure 23 Schematic flowchart of an alternative method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0087] Figure 24 Schematic flowchart of another alternative method for implementing secure and trustworthy boot provided for another embodiment of this specification;

[0088] Figure 25 Schematic structural diagram of yet another secure architecture system provided for another embodiment of this specification;

[0089] Figure 26 The structural schematic diagram of yet another security architecture system provided for another embodiment of this specification;

[0090] Figure 27 The flowchart of a method for implementing secure and trusted boot provided for an embodiment of this specification;

[0091] Figure 28 The structural schematic diagram of a computing device provided for an embodiment of this specification. Detailed implementation manners

[0092] Unless otherwise defined, the technical terms or scientific terms used in the embodiments of this specification shall have the ordinary meanings understood by those of ordinary skill in the field to which this specification belongs. The "first", "second" and similar terms used in the embodiments of this specification do not denote any order, quantity or importance, but are only used to avoid confusion of components.

[0093] Unless otherwise required by the context, throughout this specification, "a plurality of" means "at least two", and "including" is interpreted as an open and inclusive meaning, that is, "including, but not limited to". In the description of this specification, the terms "an embodiment", "some embodiments", "exemplary embodiments", "examples", "specific examples" or "some examples", etc. are intended to indicate that specific features, structures, materials or characteristics related to the embodiment or example are included in at least one embodiment or example of this specification. The schematic representations of the above terms do not necessarily refer to the same embodiment or example.

[0094] Next, the technical solutions in the embodiments of this specification will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments in this specification without creative efforts shall fall within the scope of protection of this specification.

[0095] For ease of understanding, some nouns or terms that may appear in the embodiments of this specification will be explained first below:

[0096] The secure hardware architecture is a system architecture designed for computing devices, aiming to build a secure framework for computing devices to resist various possible attacks. The implementation of the secure hardware architecture can be achieved by dividing the hardware and software resources of the processor into a secure world and a normal world. All operations that require confidentiality are executed in the secure world (such as fingerprint recognition, password processing, data encryption and decryption, and security authentication, etc.), and the rest of the operations are executed in the normal world (such as the user operating system, various ordinary application programs, etc.). The secure world and the normal world are switched through a mode called Monitor Mode. In the processor architecture, the physical processor core can be virtualized into two cores, a non-secure core (NS Core) that runs the code in the normal world, and a secure core (SecureCore) that runs the code in the secure world. The specific structural types of the secure hardware architecture can refer to the Trust Zone (abbreviated as TZ) and SGX (Software Guard Extensions) technologies.

[0097] Trusted Firmware (TF) is a security solution that divides the privilege levels during the startup and operation of computing devices. These privilege levels, combined with the secure hardware architecture, jointly ensure the security of the startup process of computing devices. Specifically, the trusted firmware technology divides four privilege levels from EL0 (Exception Level 0) to EL3. From EL0 to EL3, the privilege levels increase in sequence. Transferring from a higher EL to a lower EL is through the ERET instruction, and transferring from a lower EL to a higher EL is through an exception, thus strictly differentiating different privilege levels. Among them, EL0, EL1, and EL2 can be divided into NS-ELx (NoneSecure ELx, x = 0, 1, 2, that is, the normal world ELx) and S-ELx (Secure ELx, x = 0, 1, 2, that is, the secure world ELx), while EL3 has only one type, the secure world EL3. In some cases, the firmware required for the startup process of a computing device can include BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0098] Among them, the BL1 firmware can be called the Trusted Boot ROM, which is the earliest running firmware during the boot process and is also the firmware stored in the processor's ROM (Read-Only Memory). The BL1 firmware is not together with the BIOS of the computing device. In some types of trusted firmware technologies, the BL1 firmware is the root of all trust. The BL1 firmware can be used to initialize the core hardware of the computing device (such as Trusted SRAM, serial port, etc.) and find the BL2 hardware. In some cases, the BL1 firmware will verify the signature of the BL2 firmware. The BL1 firmware runs at the EL3 privilege level.

[0099] The BL2 firmware can be called the Trusted Boot Firmware. The BL2 firmware also runs at the EL3 privilege level. The significant difference between the BL2 firmware and the BL1 firmware is that the BL2 firmware can be stored on an external trusted storage device, and its trust can be established on the verification of the BL1 firmware. The BL2 firmware will initialize some key security hardware and software frameworks. After the initialization is completed, the BL2 firmware will find the BL31.

[0100] The BL31 firmware can be called the EL3 Runtime Firmware. The BL31 firmware also runs at the EL3 privilege level and is the last security stronghold at the EL3 privilege level. Unlike the BL1 firmware and the BL2 firmware, which are run only once, the BL31 firmware continuously provides security-related services for the Non-Secure world through SMC (Secure Monitor Call).

[0101] The BL32 firmware can include the OPTee OS (Open Portable Tee Operate System) and trusted applications. The OPTee OS can refer to the operating system of the trusted execution environment Tee. The BL32 firmware runs on S-EL1, and the trusted applications on the BL32 firmware run on S-EL0. In some cases, after the OPTee OS finishes running, it returns to the BL31 firmware at EL3. The BL31 firmware finds the BL33 firmware, and the BL31 firmware can also verify the signature of the BL33 firmware.

[0102] The BL33 firmware may include the Non-Trusted Firmware running in the normal world. The BL33 firmware may include the UEFI (Unified Extensible Firmware Interface) firmware for desktops, servers, etc. or U-boot (a bootloader for the embedded field), may also include the Linux Kernel, and may further include the basic input output system (BIOS) firmware. In the normal world, the execution permissions of EL0, EL1, EL2, and EL3 increase in sequence. Among them, the UEFI firmware is configured to run at the EL2 level in the normal world, and OP-TEE is configured to run at the EL1 level in the secure world. When entering the UEFI (BL33) startup, OP-TEE has already completed startup, and communication can be carried out between UEFI and OP-TEE through the secure monitor call (SMC) interface. Therefore, when performing UEFI startup, when verifying the integrity and security of the image file, certain functions can be implemented by triggering the SMC method in the normal world to call the corresponding interface of OP-TEE in the secure world. In this way, the verification process related to the image file can be transferred to the secure world for verification and the verification result can be returned to the normal world.

[0103] Trusted Computing (TC) is widely used in computing devices. It is a trusted computing platform based on the support of a security service module to improve the overall security of computing devices.

[0104] The security service module is a security chip that provides integrity and authenticity guarantees for computing devices and is generally strongly bound to the hardware platform of the computing device physically. The core function of the security server module is to build the functions of the three dimensions of trusted computing based on the supported cryptographic algorithms, including: platform integrity measurement and verification, platform trusted identity identification and authentication, and platform data protection. Optionally, the security service module may include at least one of the Trusted Crypto Module (TCM), Trusted Platform Module (TPM), and Trusted Platform Control Module (TPCM).

[0105] The TPM standard is introduced by the TCG (Trusted Computing Group). The TPM technical specification follows the corresponding international specifications. Therefore, it provides standard services that comply with the TPM international specifications. Generally, the TPM module can include two parts: the TPM cryptographic module and the TPM service module. The cooperation of the TPM cryptographic module and the TPM service module can support the implementation of the services of the TPM trusted computing technology.

[0106] TCM is a trusted computing chip proposed in China by drawing on the international trusted computing technology framework and technical concepts and combining with the actual development of domestic trusted computing technology. The algorithms used by TCM can include asymmetric cryptographic algorithms, symmetric cryptographic algorithms, and hash algorithms. Among them, the asymmetric cryptographic algorithm uses the elliptic curve cryptographic algorithm, including 3 sub-algorithms: elliptic curve digital signature algorithm (SM2-1), elliptic curve key exchange protocol (SM2-2), and elliptic curve public key encryption algorithm (SM2-3). The symmetric cryptographic algorithm uses the SM-4 algorithm (the SM-4 algorithm can be an algorithm based on the standard of ISO / IEC 18033-3:2010 / AMD1:2021 "Information Technology - Security Techniques - Encryption Algorithms - Part 3: Block Ciphers - Amendment 1: SM4"). This algorithm is a block algorithm with a block length of 128 bits and a key length of 128 bits. Both the encryption algorithm and the key expansion algorithm adopt a 32-round non-linear iterative structure. The hash algorithm uses the SM-3 algorithm (the SM-3 algorithm can be an algorithm based on the standard of GM / T 0004-2012 "SM3 Cryptographic Hash Algorithm"). This algorithm compresses text of indefinite length into a digest value of 32 bytes. The keys used by each cryptographic algorithm can be different. From the above description, it can be found that the main differences between TPM and TCM lie in the supported cryptographic algorithms and key types, and the storage master key of TCM is a symmetric key. TCM can include components such as an algorithm engine for providing key algorithms and storing keys (such as an SM2 engine, an SM3 engine, an SM4 engine), an HMAC engine (a unit for calculating message authentication codes based on the SM3 engine), and a random number generator (such as a true random number generator, True Random Number Generator, TRNG). These components can be realized by relying on the combination of hardware and software.

[0107] The TCM cryptographic module can be an independent module with protected storage space and is an essential key basic component of the trusted computing cryptographic support platform. The TCM cryptographic module can include trusted computing hardware resources. That is to say, the TCM cryptographic module can provide trusted basic computing resources for the trusted cryptographic service module. For example, the TCM cryptographic module can provide computing resources such as cryptographic operations, true random number generator (TRNG), and secure storage for the trusted cryptographic service module. The only interface for the TCM cryptographic module to interact with the system is a set of standard interfaces, which is a Chinese standard jointly launched by the State Cryptography Administration of China and domestic information technology (IT) enterprises.

[0108] The TCM service module can include service interfaces. In other words, the TCM service module can provide service interfaces for users (or application programs) to call resources in the TCM cryptographic module. In some embodiments, the TCM service module can call the TCM cryptographic module through the service interface to provide security services such as trusted measurement, trusted reporting, and trusted storage for application programs. In other embodiments, the TCM service module can also manage the resources of the TCM cryptographic module, or the TCM service module can hide complex function commands in the TCM cryptographic module to reduce the complexity for users to use the TCM cryptographic module. The State Cryptography Administration of China and domestic IT enterprises have also launched the interface standard for the TCM service module. Regarding the specific design of the TCM service module, different manufacturers have their own different design implementations.

[0109] The TPM cryptographic module is used to provide trusted computing hardware resources for the TPM trusted computing service. The trusted computing hardware resources specifically include storage space for storing data such as keys and random numbers, and hardware resources such as algorithm modules for various cryptographic algorithms. For example, usually, the TPM cryptographic module can support the digest algorithm units SHA-1, SHA-256, and the encryption and decryption algorithm units RSA, ECC, AES, and also supports new algorithms.

[0110] The TPM service module can refer to a module used to call the TPM cryptographic module and provide service interfaces. Similarly, the TPM cryptographic module and the TPM service module together constitute a complete TPM.

[0111] The trusted platform control module TPCM is composed of the TCM and the platform control mechanism. In addition to providing cryptographic service functions, it also provides platform control functions and can control the bus in the system. The platform control mechanism therein can be called the TPCM control module (or TPCM module), and the TPCM control module can actively call the TCM to provide security services such as security measurement.

[0112] A security service, also known as a cryptographic service, refers to the types of services that a security service module can provide based on the cryptographic algorithms it supports. Security services can specifically include trusted measurement, trusted storage, and trusted reporting, etc. Trusted storage can refer to the confidential storage or integrity protection of data through a cryptographic mechanism. Trusted reporting can refer to providing a report to the outside world that describes the internal state of the security service module. Trusted measurement refers to the measurement of the integrity and / or trustworthiness of other objects running in a computing device based on the cryptographic algorithms of the security service module, according to a measurement policy and a measurement reference value. Based on the measurement result, the running state of the measured object can be controlled. When the measurement of the object to be measured passes, the original state of the object to be measured can be maintained, or the operations that the object to be measured is expected to perform before being trusted-measured can be executed. When the measurement of the object to be measured fails, security measures can be taken against the object to be measured. For example, the computer can be controlled to reset, or the object to be measured can be controlled to restart, to avoid the security threats caused by the reasons for the measurement failure to the computer.

[0113] The Root of Trust (ROT) is the source of trust for a security architecture system and is a component that must be trusted. For the specific composition of the root of trust in a security system architecture, it varies in different system architectures. In some cases, the root of trust can refer to the Root of Trust for Measurement (RTM), the Root of Trust for Storage (RTS), and the Root of Trust for Reporting (RTR). In some cases, the root of trust can also be a TPCM. In some embodiments of this specification, the root of trust can also be the code in the previous line (segment) or the previous few lines (segments) that runs during the system power-on startup process and is stored in a Read-Only Memory (ROM) (which can be called the startup ROM or the Processor Based ROM). In some embodiments, since the BL1 firmware is stored in the ROM and belongs to the firmware required to run during the startup process, the BL1 firmware also has the characteristics of being difficult to tamper with and having high security. Therefore, the root of trust can include the BL1 firmware. The root of trust can be considered the source for establishing the system trust chain.

[0114] The Platform Configuration Register (PCR) is a set of special registers. This set of registers combines the newly written value with the original value in the register and performs a Hash calculation, and the operation result is used as the new value in the PCR. Generally, we write the measurement result of a specific object into the PCR register.

[0115] Trusted Software Base (TSB): The Trusted Software Base is an important part of the trusted computing system and is designed based on the dual-system architecture concept of coexisting computing and protection. The dual system at the software level consists of the host basic software and the Trusted Software Base. The Trusted Software Base actively intercepts and measures during the operation of the host basic software. Without modifying the original application, it actively provides real-time protection by formulating policies, thereby destroying and preventing malicious software such as viruses or Trojans that enter the system, achieving the security effect of active immune defense.

[0116] Baseboard Management Controller (BMC): Widely used in the out-of-band management subsystem of the processor in server-class computer platforms, its functions include virtual keyboard, mouse, display, power management control, and remote operation and maintenance, etc., and also include the monitoring of physical information such as the power voltage, temperature, fan status, and chassis status of the server platform. The Baseboard Management Controller is the first component on the motherboard to power on and start.

[0117] Base Input / Output System (BIOS). The basic input / output operations are realized through the I / O interface by the Base Input / Output System.

[0118] The security architecture system provided by the embodiments of this specification is to be compatible with the goals of TCM and TPCM to measure the firmware running during the startup process of computing devices, and to meet the requirements for the secure and trusted startup of various computing devices.

[0119] Generally speaking, the method for realizing secure and trusted startup proposed in this application covers the following situations:

[0120] In one embodiment, the hardware trusted root technology is used to perform hierarchical signature verification on the firmware to build the trust chain of the secure startup technology. Among them, the firmware may include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware;

[0121] Generally, the BL1 firmware can be set in the hardware trusted root, has the characteristic of being tamper-proof, is the first piece of code to power on and start, and is the origin of all trust chains. In this case, to implement the secure startup technology, the hardware trusted root needs to be executed first, and then, one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware are hierarchically verified. Exemplarily, this hierarchical verification is specifically reflected in: the BL2 firmware is signature-verified by the hardware trusted root, and then, the BL2 firmware signature-verifies the BL31 firmware, and the BL31 firmware signature-verifies the BL32 and / or BL33 firmware respectively.

[0122] In one embodiment, based on the implementation of the above-mentioned secure boot technology, the TCM or TPCM control module is further used to perform trusted measurement, trusted storage, and trusted reporting on the firmware loaded and run during the boot process, so as to implement the construction of the trust chain of the trusted computing technology.

[0123] The implementation process may include: power-on, execute the hardware trusted root, and then, verify one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware step by step. Exemplarily, the step-by-step verification is specifically reflected in: verifying the BL2 firmware through the hardware trusted root, and then, verifying the BL31 firmware, BL32, and / or BL33 firmware one by one through the BL2 firmware; or, verifying the BL31 firmware through the BL2 firmware, and then, verifying the BL33 firmware through the BL31 firmware; or, verifying the BL31 firmware through the BL2 firmware, and then, verifying the BL32 firmware and BL33 firmware one by one through the BL31 firmware; at the same time, perform self-check on the TCM hardware. In the case of successful self-check, load and run the TCM or TPCM control module. In the case of successful loading, use the TCM or the TPCM control module to measure at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. For example, use the TCM or the TPCM control module to measure the BL31 firmware, BL32 firmware, and BL33 firmware one by one; or, use the TCM or the TPCM control module to measure the BL31 firmware and BL33 firmware one by one; if the measurement is successful, the secure / trusted boot is completed, and if the measurement fails, the secure / trusted boot fails. In subsequent embodiments, the relevant implementation will be specifically described.

[0124] Next, the secure architecture system provided by the embodiments of this specification will be exemplarily described with reference to the accompanying drawings.

[0125] Exemplary System

[0126] The embodiments of this specification provide a secure architecture system, such as Figure 1As shown in the figure, it includes: a first subsystem 11, a second subsystem 12, and a third subsystem 13. The corresponding security levels of the first subsystem 11, the second subsystem 12, and the third subsystem 13 increase in sequence. The second subsystem 12 and the third subsystem 13 run in the first processor core 31. The security architecture system 100 is built with a security service platform 20. The security service platform 20 is built-in with a trusted cryptography module TCM21. The security service platform 20 is also equipped with a TPCM control module 22. The TPCM control module 22 is used to call the TCM21 in a software manner. The TCM21 and the TPCM control module 22 run in the third subsystem 13. The security service platform 20 is configured to:

[0127] In response to a power-on request, execute a startup process. During the startup process, use the TCM21 or the TPCM control module 22 to measure the firmware running during the startup process, and record the measurement result.

[0128] In this embodiment, when the security architecture system 100 receives or detects a power-on request, it responds to the power-on request and starts prior to the firmware required to run during the startup process. Use the TCM21 or the TPCM control module 22 to achieve active measurement of the firmware required to run during the startup process. The active measurement of the firmware by the TCM21 or the TPCM control module 22 can include trusted measurement, trusted storage, and trusted reporting, to achieve the construction of the trust chain of trusted computing technology. In some implementation manners, in order to facilitate the priority startup of the security service platform 20, the TCM21 and the TPCM control module 22 of the security service platform 20 can be integrated with the processor of the computing device on the same chip. In this way, the external communication interface between the security service platform 20 and the chip integrated with the processor can be reduced, so that the security service platform 20 can easily receive or detect the power-on request, and also enables the security service platform 20 to conveniently use the TCM21 or the TPCM control module 22 to measure the firmware running during the startup process.

[0129] The measurement result can be recorded in the PCR of the security architecture system 100. The recorded measurement result can provide a remote verification service after the security architecture system 100 completes startup, meeting the requirements of trusted startup. The measurement result recorded in the PCR can also be used to generate a trusted report to provide a report describing the internal state of the security architecture system 100 to the outside world.

[0130] The TPCM control module 22 calling the TCM21 in a software manner may refer to the TPCM control module 22 calling the TCM21 by sending a software program call instruction to the TCM21.

[0131] The power-on request can be a power signal after the computing device is powered on, or a request to start the system sent to the security architecture system 100 after the computing device is powered on.

[0132] In some embodiments, the security architecture system may further include a root of trust. Based on the root of trust, the firmware is verified step by step to implement the construction of the trust chain of the secure boot technology. Among them, the firmware may include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. In some embodiments, the root of trust includes BL1 firmware. In this case, the BL1 firmware has the characteristic of being tamper-proof. It is the first piece of code for power-on startup and the source of all trust chains. In this case, the security architecture system may also implement the secure boot of the system based on the root of trust. Specifically, the secure boot process may include: first execute the root of trust, and then perform step-by-step signature verification on one or more of BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. Exemplarily, the step-by-step signature verification process may include: perform signature verification on the BL2 firmware through the root of trust, and then perform signature verification on the BL31 firmware through the BL2 firmware, and perform individual signature verification on the BL32 firmware and the BL33 firmware respectively through the BL31 firmware. If any level of verification fails, the startup process can be terminated. In this way, the secure boot of the security architecture system can be achieved. Optionally, in some embodiments, the firmware running during the secure boot process may not include the BL32 firmware. In this case, the BL31 firmware only needs to verify the BL33 firmware.

[0133] The first subsystem 11 can be a Rich Execution Environment (REE, also known as a rich execution environment) subsystem, which can be used to run objects such as the operating system (OS) and ordinary applications (also known as client applications (CA)) of the computing device.

[0134] The second subsystem 12 can be a Trusted Execution Environment (TEE) subsystem, which can be used to run trusted applications (Trusted Application, TA) to meet application requirements such as digital rights management (DRM), mobile payment, and sensitive data protection.

[0135] The third subsystem 13 can be a Secure Element (SE) subsystem, which can be used to implement secure chip technology to ensure the security of important resources.

[0136] The security level, which can also be referred to as the security protection level, can refer to the level that defines the information security protection capabilities of each subsystem. The information security protection capabilities of the subsystem can be ensured through means such as hardware isolation and / or software isolation.

[0137] Figure 1 Shown are the objects that may be running / hosted in the first subsystem 11, the second subsystem 12, and the third subsystem 13. For example, in the first subsystem 11, system firmware, an operating system OS, or a virtual machine VM (Virtual Machine) can run. The system firmware can be implemented as a Unified Extensible Firmware Interface (UEFI) for the desktop, server, etc. fields, or can be implemented as a boot loader (U-Boot) for the embedded field. In addition, the base firmware, system firmware, and operating system OS can communicate with an out-of-band control system (such as an embedded controller EC, a baseboard management controller BMC, etc.).

[0138] The second subsystem 12 can run a security operating system (TEE OS) on which the second subsystem 12 depends. In some embodiments, a trusted application TA can also run in the second subsystem 12. The security level of the second subsystem 12 is higher than that of the first subsystem 11, that is, the security of the second subsystem 12 is higher than that of the first subsystem 11. The second subsystem 12 can be used, for example, to support functions such as verifying the payment environment in payment services. The second subsystem 12 can provide trusted services to the first subsystem 11 and ordinary applications running thereon and is isolated from the first subsystem 11, that is, the first subsystem 11 and ordinary applications running thereon cannot directly access the hardware and software resources of the second subsystem 12.

[0139] The application running in the third subsystem 13 can be called a security element application (Applet), and its security is higher than that of the second subsystem 12. The third subsystem 13 can be used to store important resources such as root keys, and ensure the security of the important resources stored in the third subsystem 13 through means such as permission verification and cryptographic techniques. In the security architecture system 100, the security of the computing environment is ensured through the mutual cooperation among these three subsystems.

[0140] In addition, the first subsystem 11 is also used to run general applications (referred to as general apps for short), and the general apps therein can be applications related to payment scenarios, which implement basic operations such as browsing products, selecting products, and submitting orders. Trusted apps can run in the second subsystem 12. The trusted apps provide a trustworthy running environment for the first subsystem 11, and through the protection of confidentiality and integrity and the control of data access permissions, end-to-end security is ensured. In addition, the second subsystem 12 can run in parallel with the first subsystem 11, and for example, the second subsystem 12 interacts with the first subsystem 11 through a secure Application Programming Interface (API). As an example, the first subsystem 11 can send a request for a trusted service to the second subsystem 12 to request the second subsystem 12 to provide the corresponding trusted service and make a response based on the request.

[0141] The third subsystem 13 has a higher security level than the second subsystem 12 and can be used to build a trusted and secure resource storage and computing environment. Generally, the software system in the third subsystem 13 is relatively simple and includes fewer hardware components. Therefore, it is easier to establish physical protection and implement security safeguards, thereby improving the security level of the third subsystem 13 to serve security systems with higher security requirements. As an example, the second subsystem 12 can send a request for a security service to the third subsystem 13 to request the third subsystem 13 to provide the corresponding security service and make a response based on the request. The security service requested by the second subsystem 12 can be, for example, a service related to cryptographic operations requested from the third subsystem 13.

[0142] For example, in some embodiments, there is no direct physical path for the first subsystem 11 and the second subsystem 12 to access the third subsystem 13. Instead, requests can only be made to the third subsystem 13 through interactive means such as shared memory, and the third subsystem 13 provides services to the first subsystem 11 and the second subsystem 12. Regarding the third subsystem 13, as an implementation, the third subsystem 13 may include an execution engine, a static random access memory (SRAM), a non-volatile memory, or may further include a key derivation module (Key Derivation Function, KDF). Among them, important resources such as root keys can be stored in the non-volatile memory within the third subsystem 13, and the firmware or hardware of the third subsystem 13 ensures that there is no software or hardware path for the root key to be transmitted out of the third subsystem 13. In addition, the key derivation module KDF integrated within the third subsystem 13 can be implemented as software or hardware, for example, and is used to generate derived keys based on the root key. For example, the key derivation module KDF can be a hash function, which is usually used to transform a short password into a long password. Specifically, the above-mentioned shared memory may refer to a large-capacity memory that can be accessed by different processors in a multi-processor computer system. In some embodiments, resources such as the execution engine included in the third subsystem 13 can be used as trusted computing hardware resources for the TCM21 and / or TPM.

[0143] In this embodiment, by integrating the security service platform 20 including the TCM21 and the TPCM control module 22 into the security architecture system 100, and configuring the security service module to measure the firmware running during the startup process using the TCM21 or the TPCM control module 22 during the startup process and record the measurement results, the purpose of achieving trusted startup by compatible with both TCM and TPCM control routes is realized, and the applicability of the security architecture system is improved.

[0144] In order to flexibly configure the firmware that needs to be measured during the startup process, in some embodiments of this specification, the security service platform using the TCM or the TPCM control module to measure the firmware running during the startup process is specifically used for:

[0145] Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0146] The definitions of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware can refer to the relevant descriptions in the above text.

[0147] In this embodiment, the security service platform can selectively measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware during the startup process according to the actual situation of the computing device or the actual need for secure / trusted startup, so as to improve the applicability of the security architecture system to various application scenarios while ensuring the security of the security architecture system.

[0148] Some of the following embodiments introduce some possible specific startup processes. Optionally, in an embodiment of this specification, refer to Figure 2 , the security service platform executes the startup process. During the startup process, one or more of the following firmwares are measured by using the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically for:

[0149] Run the BL2 firmware to initialize the processor core of the security architecture system.

[0150] Perform self-check on the hardware resources of the TCM. In this step, the self-check on the hardware resources of the TCM may include self-check on the hardware resources such as the random number generator of the TCM (for example, it can be TRNG), the cryptographic algorithm hardware engine, etc.

[0151] When the self-check of the hardware resources of the TCM passes, load and run the TCM and the TPCM control module.

[0152] Measure the BL2 firmware by using the TCM or the TPCM control module.

[0153] Measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware by using the TCM or the TPCM control module.

[0154] The specific process can refer to Figure 2 , and this process may include:

[0155] S201: Startup: In response to the power-on request, execute the startup process.

[0156] S202: Load and run BL2: That is, run the BL2 firmware to initialize the processor core of the security architecture system.

[0157] S203: Perform self-check on the hardware resources of the TCM. When the self-check of the hardware resources of the TCM passes (or the self-check is successful), enter step S204: Load and run the TCM and the TPCM control module. When the self-check of the hardware resources of the TCM fails, enter step S206: Secure / trusted startup fails, and terminate the startup process.

[0158] S205: Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement is successful, go to step S207: Secure / Trusted boot completed. If the measurement fails, go to step S206: Secure / Trusted boot failed, and terminate the boot process.

[0159] In this embodiment, after the TCM hardware resource self-check, the TCM and TPCM control modules are loaded and run, enabling the TCM and TPCM control modules to selectively measure some or all of the BL31, BL32, and BL33 firmware, which is conducive to achieving the trusted boot of the security architecture system and ensuring the security of the security system architecture.

[0160] In addition, during the measurement process, by performing a self-check on the hardware resources of the TCM cryptographic module, it is beneficial to ensure the reliability of the hardware required for measurement and the security of the measurement process.

[0161] Optionally, in another embodiment, refer to Figure 3 , after the security service platform runs the BL2 firmware, it is further used for:

[0162] Use the BL2 firmware to perform signature authentication on the BL31 firmware.

[0163] The specific process can refer to Figure 3 , and this process includes:

[0164] S301: Boot: In response to a power-on request, execute the boot process.

[0165] S302: Load and run BL2: That is, run the BL2 firmware and initialize the processor core of the security architecture system.

[0166] S303: After the BL2 firmware runs, perform a self-check on the hardware resources of the TCM. If the self-check of the TCM hardware resources passes (or the self-check is successful), go to step S304: Load and run the TCM and the TPCM control module. If the self-check of the TCM hardware resources fails, go to step S306: Secure / Trusted boot failed, and terminate the boot process.

[0167] S305: Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement fails, go to step S306: Secure / Trusted boot failed, and terminate the boot process.

[0168] S308: Authenticate the BL31 firmware through the BL2 firmware signature, that is, after the BL2 firmware runs, the BL2 firmware is also used to sign and authenticate the BL31 firmware. When the authentication of the BL31 firmware by the BL2 firmware is successful and the measurement result in step S305 is successful, proceed to step S307: Secure / Trusted boot completed; otherwise, proceed to step S306: Secure / Trusted boot failed, terminating the boot process.

[0169] In this embodiment, the BL31 firmware is double - authenticated using the BL2 firmware and the TCM / TPCM control module, realizing the organic combination of secure / trusted boot and improving the security of the security architecture system.

[0170] In some embodiments, an optimized design is proposed for how to measure the firmware using the TCM or TPCM control module. Specifically, refer to Figure 4 , the process of the security service platform running the TPCM control module includes:

[0171] Run the TPCM control module, and set the flag bit of the TPCM control module according to the available state of the TPCM control module. The flag bit of the TPCM control module is used to indicate whether the TPCM control module is available.

[0172] The security service platform uses the TCM or the TPCM control module to specifically perform one or more of the following on the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware:

[0173] Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, use the TPCM control module to process one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0174] If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, use the TCM module to process one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0175] The specific process can refer to Figure 4 , and this process includes:

[0176] S401: Boot: In response to a power - on request, execute the boot process.

[0177] S402: Load and run BL2: That is, run the BL2 firmware and initialize the processor core of the security architecture system.

[0178] S403: Self-check the hardware resources of the TCM. If the self-check of the hardware resources of the TCM passes (or is successful), proceed to step S404: Load and run the TCM and the TPCM control module. If the self-check of the hardware resources of the TCM fails, proceed to step S408: Secure / Trusted boot fails, terminate the boot process.

[0179] S405: Detect the TPCM control module: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and the subsequent measurement step (S406) uses the TPCM control module for measurement. If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, the subsequent measurement step (S406) uses the TCM for measurement.

[0180] S406: Measure BL31, BL32, and BL33. According to the detection result of S405, use the TCM or the TPCM control module to measure at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement is successful, load and run at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. For example, use the TCM or the TPCM control module to measure the BL31 firmware, BL32 firmware, and BL33 firmware one by one. If the measurement is successful, load and run the BL31 firmware, BL32 firmware, and BL33 firmware one by one. In some embodiments, the TCM or the TPCM control module can be used to measure the BL31 firmware and the BL33 firmware one by one. If the measurement is successful, load and run the BL31 firmware and the BL33 firmware one by one. Proceed to S407: Secure / Trusted boot is completed. If the measurement fails, execute step S408: Secure / Trusted boot fails, terminate the boot process.

[0181] This embodiment is based on Figure 2Taking the startup process shown as an example for illustration, in some embodiments, the detection of the flag bit of the TPCM control module is usually performed along with the loading of the TPCM control module. When the flag bit of the TPCM control module is detected as available, the TPCM control module can be used to measure some or all of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, which can depend on the loading order of the TPCM control module and these firmwares. For example, when the loading order of the TPCM control module is prior to that of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, the TPCM control module can measure all of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. Of course, even if the loading order of the TPCM control module is prior to that of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, in some cases, only part of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware can be measured using the TPCM control module, and the remaining part can be not measured or measured using the TCM. When the loading order of the TPCM control module is between the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, the TPCM control module can measure some or all of the firmwares with a later loading order, and this specification does not limit this.

[0182] In this embodiment, when the TPCM control module is loaded, a flag bit indicating whether the TPCM control module is available is set, and when the TPCM control module is available, the TPCM control module is preferentially used to measure the firmware running during the startup process, which is beneficial to exerting the technical advantages of the trusted computing 3.0 route and ensuring the autonomy, controllability, security, and trustworthiness of the secure / trusted startup process.

[0183] To ensure that the secure / trusted startup process is trusted from the very beginning of the startup process, in some embodiments, referring to Figure 5 , a trusted root 40 is also set in the security service platform. The trusted root 40 can be the first line (segment) or the first few lines (segments) of code when starting up, written in the ROM of the processor of the computing device, and is the source of all trust chains. In some embodiments, due to the non-tamperable characteristic of the BL1 firmware written in the ROM, the trusted root 40 can include the BL1 firmware.

[0184] Correspondingly, when the security service platform includes a trusted root, referring to Figure 6 , before running the BL2 firmware, the security service platform is further configured to:

[0185] Execute the trusted root to perform self - checks on the trusted computing hardware resources of the first processor core and the TCM. If the self - check fails, terminate the startup process. If the self - check succeeds, use the trusted root to perform signature authentication on the BL2 firmware.

[0186] The security service platform runs the BL2 firmware specifically for:

[0187] In the case where the BL2 firmware authentication passes, run the BL2 firmware. In the case where the BL2 firmware authentication fails, terminate the startup process.

[0188] Figure 6 The startup process shown can specifically include:

[0189] S601: Startup: In response to a power - on request, execute the startup process.

[0190] S602: Execute the trusted root. In some embodiments, the trusted root can be executed in the third subsystem or on the first processor core.

[0191] S603: Self - check: Perform self - checks on the trusted computing hardware resources of the first processor core and the TCM. If the self - check fails, execute step S614: Secure / Trusted startup failed, and terminate the startup process. If the self - check succeeds, enter step S604: Perform signature authentication on the BL2 firmware. If the BL2 firmware authentication fails, enter step S614: Secure / Trusted startup failed, and terminate the startup process. If the BL2 firmware signature authentication succeeds, enter step S605: Load and run BL2, that is, load and run the BL2 firmware.

[0192] S606: TCM self - check: Perform self - checks on the hardware resources of the TCM. In the case where the hardware resources of the TCM pass the self - check (or the self - check succeeds), enter step S607: Load and run the TCM and the TPCM control module. In the case where the hardware resources of the TCM do not pass the self - check (or the self - check fails), enter step S614.

[0193] S608: Detect the TPCM: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and subsequent measurement steps (S609, S611) use the TPCM control module for measurement. If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, subsequent measurement steps (S609, S611) use the TCM for measurement.

[0194] In some embodiments, in step S607, call services for initialization can also be provided during the operation of the system firmware, that is, expose the call interface of the TCM to meet the call requirements of the system firmware for the TCM.

[0195] When the BL2 firmware is signed and authenticated by the trusted root, public key algorithms including SM2, ECC (Ellipse Curve Cryptography) algorithms, etc. can be used. In this way, the integrity and correctness of the BL2 firmware can be guaranteed. It should be noted that the above SM2 and ECC are only examples and should not constitute limitations. The self-check of the trusted computing hardware resources of the TCM can include the self-check of core hardware resources such as a random number generator (e.g., TRNG) and a cryptographic algorithm hardware engine. When the measurement of the BL2 firmware is successful, step S606 is entered.

[0196] S610: Measure BL3: According to the detection result of S608, use the TCM or TPCM control module to measure at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement is successful, execute step S610: Load and run BL3, that is, load and run at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement fails, execute step S614: Secure / trusted boot fails, terminate the boot process.

[0197] In some embodiments, after the BL3 is loaded, it may further include step S611: According to the detection result of S608, use the TCM or TPCM control module to measure the system kernel. If the measurement is successful, execute step S612: System initialization, S613: Secure / trusted boot completed. If the measurement fails, execute step S614: Secure / trusted boot fails, terminate the boot process.

[0198] In this embodiment, taking the BL1 firmware as the trusted root and starting from the trusted root to execute ensures the security / trust of the entire boot chain and improves the security of the security architecture system.

[0199] In addition, when the measurement of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware fails, the corresponding firmware loading tasks are not executed, and the boot process is terminated, which can meet the requirements of the secure boot of the security architecture system.

[0200] When the security architecture system includes a trusted root, the TCM and TPCM control modules can also be loaded and run in the trusted root. For details, refer to Figure 7 , before running the BL2 firmware, the security service platform is further used for:

[0201] Execute the trusted root, perform self-check on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, run the TCM and the TPCM control module in the trusted root.

[0202] Use the TCM or the TPCM control module to perform signature authentication on the BL2 firmware.

[0203] The security service platform runs the BL2 firmware specifically for:

[0204] In the case where the BL2 firmware authentication passes, run the BL2 firmware. In the case where the BL2 firmware authentication fails, terminate the startup process.

[0205] Reference Figure 7 , the startup process may include:

[0206] S701: Startup: In response to a power-on request, execute the startup process.

[0207] S702: Execute the trusted root. In some embodiments, the trusted root may be executed in the third subsystem or in the second subsystem.

[0208] S703: Self-check: Perform self-check on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, execute step S713: Security / Trusted startup fails, terminate the startup process. If the self-check is successful, execute step S704: Perform basic initialization on the computing device, load the TCM and the TPCM control module, and perform self-check on the hardware resources of the TCM. In the case where the hardware resources of the TCM pass the self-check (or the self-check is successful), load the TCM and the TPCM control module, and enter step S705: Detect the TPCM control module: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and subsequent measurement steps (S706, S708, S709, S710) use the TPCM control module for measurement. If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, subsequent measurement steps (S706, S708, S709, S710) use the TCM for measurement. The self-check of the hardware resources of the TCM in this step may be a self-check of other hardware resources of the TCM except for the core hardware resources.

[0209] After the TPCM control module finishes the detection, proceed to step S706: Measure BL2, that is, use the TPCM control module or TCM to measure the BL2 firmware. In the case of a failure in measuring the BL2 firmware, proceed to step S713: Secure / Trusted Boot fails, and terminate the boot process. When the root of trust measures the BL2 firmware, public key algorithms including SM2, ECC (Ellipse Curve Cryptography), etc. can be used. This is just an example here and should not constitute a limitation. The self-check of the trusted computing hardware resources of the TCM can include the self-check of core hardware resources such as a random number generator (such as TRNG), a cryptographic algorithm hardware engine, etc. If the measurement of the BL2 firmware is successful, proceed to step S706.

[0210] In some embodiments, in step S705, call services for initialization can also be provided during the runtime of the system firmware, that is, expose the call interface of the TCM to meet the call requirements of the system firmware for the TCM.

[0211] S705: Measure BL2. According to the detection result of S705, use the TCM or TPCM control module to measure the BL2 firmware. If the measurement is successful, execute step S706: Load and run BL2, that is, load and run the BL2 firmware. If the measurement fails, execute step S713: Secure / Trusted Boot fails, and terminate the boot process.

[0212] S708: Measure BL3: According to the detection result of S705, use the TCM or TPCM control module to measure at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement is successful, execute step S709: Load and run BL3: that is, load and run at least one of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement fails, execute step S713: Secure / Trusted Boot fails, and terminate the boot process.

[0213] In some embodiments, after the BL3 is loaded, it can also include step S710: According to the detection result of S705, use the TCM or TPCM control module to measure the system kernel. If the measurement is successful, execute step S711: System initialization, S712: Secure / Trusted Boot completed. If the measurement fails, execute step S713: Secure / Trusted Boot fails, and terminate the boot process.

[0214] In this embodiment, the BL1 firmware is used as the root of trust and executed starting from the root of trust, ensuring the security / trust of the entire boot chain and improving the security of the security architecture system.

[0215] In addition, the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware do not execute the corresponding firmware loading tasks after a measurement failure and terminate the startup process, which can meet the requirements of secure startup of the security architecture system.

[0216] In this embodiment, after the self-check of the trusted computing hardware resources of the first processor core and the TCM is successful in step S703, the TCM and the TPCM control module are loaded and run in the trusted root, so that the TCM and the TPCM control module can run prior to most of the firmware required during the startup process, enabling the TCM and the TPCM control module to measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, and playing the active measurement function of trusted computing in the secure / trusted startup process.

[0217] However, it should be noted that since in the trusted root, that is, in the hardware trusted startup root, after the self-check and power-on basic initialization are completed, the TCM and the TPCM control module are loaded and run, this implementation method requires relatively large hardware resources and higher hardware costs. Therefore, the practical applicability of this method is relatively limited.

[0218] In this embodiment, by loading the TCM and the TPCM control module in the trusted root, the TCM and the TPCM control module can start running earlier, enabling complete measurement of the firmware during the startup process, achieving the security / trust of the entire startup chain, and improving the security of the security architecture system.

[0219] In some embodiments, after the measurement of the firmware required during the startup process is completed, in order to ensure the system security of the entire computing device, the security architecture system is set in the computing device, still referring to Figure 6 The security service platform is also used for:

[0220] Measuring the operating system kernel of the computing device by using the TCM or the TPCM control module.

[0221] When the measurement result of the operating system kernel of the computing device passes, load the operating system kernel to initialize the hardware resources of the computing device and boot the operating system, thereby completing the startup of the computing device.

[0222] In Figure 6 Step S611 realizes the operation of measuring the operating system kernel of the computing device by using the TCM or the TPCM control module, ensuring the security and trust of the entire startup process.

[0223] In some embodiments, in addition to the self-check of the TCM hardware resources, when the TCM is loaded and running, the TCM can be further self-checked to ensure the security and trustworthiness of the TCM. Specifically, in one embodiment of this specification, the security service platform loading and running the TCM is specifically used for:

[0224] Load the TCM.

[0225] Run the self-check program of the TCM and obtain the self-check result returned by the self-check program of the TCM. If the self-check result is a self-check failure, terminate the startup process.

[0226] The self-check program of the TCM can be the built-in Self-Task program of the TCM. By running this self-check program, the security and trustworthiness of other resources of the TCM except for the hardware resources are ensured.

[0227] It should be noted that in the above startup process, it mainly reflects the measurement of the firmware by the TCM or the TPCM control module in the trusted startup process. In the trusted startup process, the secure startup process can also be carried out in parallel, that is, the trusted root is used to verify the firmware step by step to realize the construction of the trust chain of the secure startup technology. Among them, the firmware can include one or more of the BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. As mentioned above, the BL1 firmware can be set in the trusted root, has the characteristic of being tamper-proof, is the first piece of code for power-on startup, and is the source of all trust chains. In this case, to implement the secure startup technology, the trusted root needs to be executed first, and then, one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware are verified step by step. Exemplarily, this step-by-step verification is specifically reflected in: the trusted root verifies the BL2 firmware, and then, the BL2 firmware verifies the BL31 firmware, and the BL31 firmware verifies the BL32 and / or BL33 firmware respectively.

[0228] In some cases, the computing device includes a multi-core processor. In this case, the embodiments of this specification also provide a secure architecture system based on the multi-core processor, such as Figure 8As shown, it includes: a first subsystem 11, a second subsystem 12, and a third subsystem 13. The security levels corresponding to the first subsystem 11, the second subsystem 12, and the third subsystem 13 increase in sequence. The second subsystem 12 runs in the first processor core 31, and the third subsystem 13 runs in the second processor core 32. The security architecture system 100 is built with a security service platform 20. The security service platform 20 is built-in with a trusted cryptography module TCM 21. The security service platform 20 is also equipped with a TPCM control module 22. The TPCM control module 22 is used to call the TCM 21 in a software manner. The TCM 21 and the TPCM control module 22 run in the third subsystem 13. The security service platform 20 is configured to:

[0229] In response to a power-on request, execute a startup process. During the startup process, use the TCM 21 or the TPCM control module 22 to measure the firmware running during the startup process, and record the measurement result.

[0230] In this embodiment, a security service platform 20 including a TCM 21 and a TPCM control module 22 is integrated in the third subsystem 13 of the security architecture system 100, so that the security service platform 20 can use the TCM 21 or the TPCM control module 22 to measure the firmware running during the startup process during the startup process. The active measurement of the firmware by the TCM 21 or the TPCM control module 22 can include trusted measurement, trusted storage, and trusted reporting, to achieve the construction of a trust chain for the trusted computing base. In some implementation manners, in order to facilitate the priority startup of the security service platform 20, the TCM 21 of the security service platform 20 and the TPCM control module 22 can be integrated with the processor of the computing device on the same chip. In this way, the external communication interface between the security service platform 20 and the chip integrating the processor can be reduced, so that the security service platform 20 can easily receive or detect the power-on request, and also makes it convenient for the security service platform 20 to use the TCM 21 or the TPCM control module 22 to measure the firmware running during the startup process.

[0231] In addition, the second subsystem 12 and the third subsystem 13 run on different processor cores respectively (i.e., the second subsystem 12 runs on the first processor core 31, and the third subsystem 13 runs on the second processor core 32), enabling the third subsystem 13 including TCM21 and TPM to operate independently without relying on the hardware resources of the second subsystem 12, being unaffected by the first subsystem 11 and the second subsystem 12, having higher security, and being beneficial to improving the overall security of the security architecture system 100. In addition, the third subsystem 13 running on an independent processor core can exclusively use the computing resources of the second processor core 32, which is beneficial to improving the task execution efficiency of the third subsystem 13, thereby enhancing the security service execution efficiency of the security architecture system 100.

[0232] The measurement result can be recorded in the PCR of the security architecture system 100. The recorded measurement result can provide a remote verification service after the security architecture system 100 finishes booting, meeting the requirements of trusted boot. The measurement result recorded in the PCR can also be used to generate a trusted report to provide a report describing the internal state of the security architecture system 100 to the outside world.

[0233] The power-on request can be the power signal after the computing device is powered on, or the request to start the system sent by the computing device to the security architecture system 100 after being powered on.

[0234] The TPCM control module calling the TCM in software manner may refer to the TPCM control module calling the TCM by sending a software program call instruction to the TCM.

[0235] In some embodiments, the security architecture system may further include a root of trust. Based on the root of trust, the firmware is verified step by step to implement the construction of the trust chain for the secure boot technology. Among them, the firmware may include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. In some embodiments, the root of trust includes BL1 firmware. In this case, the BL1 firmware has the characteristic of being tamper-proof. It is the first piece of code to be powered on and started, and it is the source of all trust chains. In this case, the security architecture system may also implement the secure boot of the system based on the root of trust. Specifically, the secure boot process may include: first execute the root of trust, and then perform step-by-step signature verification on one or more of BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. Exemplarily, the step-by-step verification process may include: the root of trust performs signature verification on the BL2 firmware, and then the BL2 firmware performs signature verification on the BL31 firmware, and the BL31 firmware respectively performs signature verification on the BL32 firmware and the BL33 firmware. If any level of signature verification fails, the boot process can be terminated to achieve the secure boot of the security architecture system. Optionally, in some embodiments, the firmware running during the secure boot process may not include the BL32 firmware. In this case, the BL31 firmware only needs to verify the BL33 firmware.

[0236] The first subsystem 11 may be a Rich Execution Environment (REE, also known as a rich execution environment) subsystem, which can be used to run objects such as the operating system (OS) and ordinary applications (also known as client applications (CA)) of a computing device.

[0237] The second subsystem 12 may be a Trusted Execution Environment (TEE) subsystem, which can be used to run Trusted Applications (TA) to meet application requirements such as Digital Rights Management (DRM), mobile payment, and sensitive data protection.

[0238] The third subsystem 13 may be a Secure Element (SE) subsystem, which can be used to implement secure chip technology to ensure the security of important resources.

[0239] The security level, also known as the security protection level, may refer to the level that defines the information security protection capabilities of each subsystem. The information security protection capabilities of the subsystem can be guaranteed through hardware isolation and / or software isolation, etc.

[0240] Figure 8

[0240] shows objects that may run / operate in the first subsystem 11, the second subsystem 12, and the third subsystem 13. For example, system firmware, an operating system OS, or a virtual machine VM (Virtual Machine) may run in the first subsystem 11. The system firmware may be implemented as a Unified Extensible Firmware Interface (UEFI) for the desktop, server, and other fields, or may be implemented as a boot loader (U-Boot) for the embedded field. In addition, the base firmware, system firmware, and operating system OS may communicate with an out-of-band control system (such as an embedded controller EC, a baseboard management controller BMC, etc.).

[0241] Figure 8 The second subsystem 12 may run a security operating system (TEE OS) on which the second subsystem 12 depends. In some embodiments, a trusted application TA may also run in the second subsystem 12. The security level of the second subsystem 12 is higher than that of the first subsystem 11, that is, the security of the second subsystem 12 is higher than that of the first subsystem 11. The second subsystem 12 may be used to support functions such as verifying the payment environment in payment services, for example. The second subsystem 12 may provide trusted services to the first subsystem 11 and ordinary applications running thereon and is isolated from the first subsystem 11, that is, the first subsystem 11 and ordinary applications running thereon cannot directly access the hardware and software resources of the second subsystem 12.

[0242] The application running in the third subsystem 13 may be called a security element application (Applet), and its security is higher than that of the second subsystem 12. The third subsystem 13 may be used to store important resources such as root keys, and ensure the security of the important resources stored in the third subsystem 13 through means such as permission verification and cryptographic techniques. In the security architecture system 100, the security of the computing environment is ensured through the mutual cooperation of these three subsystems.

[0243] In addition, the first subsystem 11 is also used to run ordinary applications (hereinafter referred to as ordinary applications), and the ordinary applications therein can be applications related to payment scenarios, which implement basic services such as browsing products, selecting products, and submitting orders. A trusted application can be run in the second subsystem 12. The trusted application provides a trustworthy running environment for the first subsystem 11, and then through the protection of confidentiality and integrity and the control of data access rights, end-to-end security is ensured. In addition, the second subsystem 12 can run in parallel with the first subsystem 11, and for example, the second subsystem 12 interacts with the first subsystem 11 through a secure Application Programming Interface (API). As an example, the first subsystem 11 can send a request for a trusted service to the second subsystem 12 to request the second subsystem 12 to provide the corresponding trusted service and make a response based on the request.

[0244] The third subsystem 13 has a higher security level than the second subsystem 12 and can be used to build a trusted and secure resource storage and computing environment. Generally, the software system in the third subsystem 13 is relatively simple and includes fewer hardware components. Therefore, it is easier to establish physical protection and implement security guarantees, thereby improving the security level of the third subsystem 13 to serve a security system with higher security requirements. As an example, the second subsystem 12 can send a request for a security service to the third subsystem 13 to request the third subsystem 13 to provide the corresponding security service and make a response based on the request. The security service requested by the second subsystem 12 can be, for example, a service related to cryptographic operations requested from the third subsystem 13.

[0245] For example, in some embodiments, there is no direct physical path for the first subsystem 11 and the second subsystem 12 to access the third subsystem 13. They can only send requests to the third subsystem 13 through interactive means such as shared memory, and the third subsystem 13 provides services to the first subsystem 11 and the second subsystem 12. Regarding the third subsystem 13, as an implementation, the third subsystem 13 may include an execution engine, a static random access memory (SRAM), a non-volatile memory, or may further include a key derivation module (Key Derivation Function, KDF). Among them, important resources such as root keys can be stored in the non-volatile memory within the third subsystem 13, and the firmware or hardware of the third subsystem 13 ensures that there is no software or hardware path for the root key to be transferred out of the third subsystem 13. In addition, the key derivation module KDF integrated within the third subsystem 13 can be implemented as software or hardware, for example, and is used to generate derived keys based on the root key. For example, the key derivation module KDF can be a hash function, which is usually used to transform a short password into a long password. Specifically, the above-mentioned shared memory may refer to a large-capacity memory that can be accessed by different processors in a multi-processor computer system. In some embodiments, resources such as the execution engine included in the third subsystem 13 can be used as trusted computing hardware resources of the TCM21 and / or TPM.

[0246] In this embodiment, by integrating the security service platform 20 including the TCM21 and the TPCM control module 22 into the security architecture system 100, and configuring the security service module to measure the firmware running during the startup process using the TCM21 or the TPCM control module 22 during the startup process and record the measurement results, the purpose of achieving trusted startup by compatible with both the TCM21 and TPCM control routes is realized, and the applicability of the security architecture system 100 is improved.

[0247] In order to flexibly configure the firmware that needs to be measured during the startup process, in some embodiments of this specification, the security service platform uses the TCM or the TPCM control module to measure the firmware running during the startup process specifically for:

[0248] Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0249] For the definitions of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, reference can be made to the relevant descriptions above.

[0250] In this embodiment, the security service platform can selectively measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware during the startup process according to the actual situation of the computing device or the actual need for secure / trusted startup, so as to improve the applicability of the security architecture system to various application scenarios on the basis of ensuring the security of the security architecture system.

[0251] Some of the following embodiments introduce some possible specific startup processes. Optionally, in an embodiment of this specification, refer to Figure 9 , the security service platform executes the startup process. During the startup process, one or more of the following firmwares are measured by using the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically for:

[0252] Load and run the firmware in the third subsystem to initialize the third subsystem;

[0253] Self-check the hardware resources of the TCM;

[0254] When the self-check of the hardware resources of the TCM passes, load and run the TCM and the TPCM control module;

[0255] Use the TCM or the TPCM control module to measure one or more of the following firmwares: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0256] The specific process can refer to Figure 9 , and this process includes:

[0257] S901: Startup: In response to the power-on request, execute the startup process.

[0258] S902: Run the firmware in the third subsystem to initialize the third subsystem. In this embodiment, since the third subsystem runs on a separate second processor core and has Turing completeness, it can run the firmware in the third subsystem by itself.

[0259] S903: Self-check the hardware resources of the TCM. When the self-check of the hardware resources of the TCM passes, execute step S904: Load and run the TCM and the TPCM control module. When the self-check of the hardware resources of the TCM fails, execute step S907, and the secure / trusted startup fails, terminating the startup process.

[0260] S905: Measurement Firmware: Use the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. If the measurement is successful, execute step S906: Secure / Trusted Boot Completed. If the measurement fails, execute step S907: Secure / Trusted Boot Failed, and terminate the boot process.

[0261] The execution process of step S905 may include: Use the TCM or the TPCM control module to measure the BL2 firmware. If the measurement fails, execute step S907. If the measurement is successful, load and run the BL2 firmware, and use the TCM or the TPCM control module to measure one or more of the BL31 firmware, BL32 firmware, and BL33 firmware. If the measurement fails, execute step S907. If the measurement is successful, load and run one or more of the BL31 firmware, BL32 firmware, and BL33 firmware, and execute step S906.

[0262] In some embodiments, use the TCM or TPCM to perform a trusted measurement on the firmware and / or software loaded during the system power-on process. The system does not judge the measurement result, and the power-on process will proceed normally. Only the trusted measurement result is securely stored in the system's PCR. After the power-on is completed, during the real-time operation of the system, the PCR value will be used to perform a trusted report to the remote server. The remote server judges whether the measurement result is successful or failed. Generally, if the PCR value is incorrect, the local device / processor architecture system will be judged as an untrusted device. The arbitration policy for untrusted devices will be incorporated into the situation awareness system for processing. This patent cannot limit the result of a failed trusted measurement. It should be noted that the subsequent related embodiments also apply to this specific implementation manner and will not be elaborated one by one.

[0263] In this embodiment, due to the Turing completeness of the third subsystem, after the firmware of the third subsystem runs, the TCM and TPCM control modules can be loaded in the third subsystem, enabling the TCM and TPCM control modules to intervene earlier in the firmware measurement during the boot process, which is beneficial to improving the security of the security architecture system.

[0264] In addition, the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware do not execute the corresponding firmware loading tasks after the measurement fails and terminate the boot process, which can meet the requirements of the secure boot of the security architecture system.

[0265] To ensure that the secure / trusted boot process is trusted from the very beginning of the boot process, in some embodiments, refer to Figure 10, a trusted root 40 is also set in the security service platform. The trusted root 40 can be the first line (segment) or the first few lines (segments) of code when starting up, written in the ROM of the processor of the computing device, and is the source of all trust chains. Since the BL1 firmware is stored in the ROM that is difficult to tamper with, the trusted root 40 can include the BL1 firmware.

[0266] Correspondingly, when the security service platform includes a trusted root, refer to Figure 11 , before the security service platform loads and runs the firmware in the third subsystem, it is also used for:

[0267] Execute the trusted root, perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, authenticate the firmware in the third subsystem through the trusted root signature;

[0268] The security service platform loading and running the firmware in the third subsystem is specifically used for:

[0269] In the case where the firmware in the third subsystem is authenticated successfully, load and run the firmware in the third subsystem. In the case where the firmware in the third subsystem is not authenticated successfully, terminate the startup process.

[0270] The specific process refers to Figure 11 :

[0271] S1101: Startup: In response to the power-on request, execute the startup process.

[0272] S1102: Execute the trusted root. In some embodiments, the trusted root can be executed in the third subsystem, or can be executed on the first processor core / second processor core.

[0273] S1103: Self-check: Perform self-checks on the trusted computing hardware resources of the TCM. If the self-check fails, execute step S1110: Security / Trusted startup fails, terminate the startup process; if the self-check is successful, execute step S1104: Sign and authenticate the firmware: Use the trusted root to perform signature authentication on the firmware in the third subsystem. When performing signature authentication, public key algorithms including SM2, ECC (Ellipse Curve Cryptography) algorithms, etc. can be used. In this way, the integrity and correctness of the firmware can be guaranteed. It should be noted that the above SM2, ECC are only examples and should not constitute a limitation. The self-check of the trusted computing hardware resources of the TCM can include self-checks on core hardware resources such as random number generators (such as TRNG), cryptographic algorithm hardware engines, etc.

[0274] If the firmware measurement of the third subsystem is successful (when the firmware authentication in the third subsystem passes), step S1105 is executed: Run the firmware in the third subsystem to initialize the third subsystem.

[0275] If the firmware measurement of the third subsystem fails, step S1110 is executed: The secure / trusted boot fails, and the boot process is terminated.

[0276] S1106: Self-check the hardware resources of the TCM. The self-check of the hardware resources of the TCM in this step can be the self-check of the hardware resources of the TCM other than the core hardware resources. When the self-check of the hardware resources of the TCM passes, step S1107 is executed: Load and run the TCM and the TPCM control module. When the self-check of the hardware resources of the TCM fails, step S1110 is executed, the secure / trusted boot fails, and the boot process is terminated.

[0277] In some embodiments, in step S1107, when loading the TCM, call services for initialization can also be provided for the system firmware during runtime, that is, expose the call interface of the TCM to meet the call requirements of the system firmware for the TCM.

[0278] S1108: Measure the firmware: Use the TCM or the TPCM control module to measure one or more of the following firmwares: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. If the measurement is successful, step S1109 is executed: The secure / trusted boot is completed. If the measurement fails, step S1010 is executed, the secure / trusted boot fails, and the boot process is terminated.

[0279] In this embodiment, by measuring the firmware of the third subsystem through the trusted root, the security / trust of the entire boot chain is achieved, improving the security of the security architecture system.

[0280] In this embodiment, in addition to measuring one or more of the following firmwares through the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware, a secure boot process can also be executed simultaneously, that is, perform hierarchical signature authentication on the firmware using the trusted root. The hierarchical signature authentication process can include: Perform signature authentication on the BL2 firmware through the trusted root, perform signature authentication on the BL31 firmware through the BL2 firmware, perform signature authentication on the BL32 firmware and / or the BL33 firmware respectively through the BL31 firmware. If the signature authentication of any level of firmware fails, the boot process is terminated.

[0281] When the security architecture system includes a trusted root, the TCM and the TPCM control module can also be loaded and run in the trusted root. The trusted root can include the BL1 firmware. For details, refer toFigure 12 The security service platform executes a startup process. During the startup process, one or more of the following firmware are measured by using the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically, it is used for:

[0282] Execute the trusted root, perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, load and run the TCM and the TPCM control module in the trusted root.

[0283] Use the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0284] Reference Figure 12 In this embodiment, after the self-check in step S1203: the self-check of the trusted computing hardware resources of the TCM is successful, step S1204 is executed: load and run the TCM and the TPCM control module in the trusted root, so that the TCM and the TPCM control module can run prior to most of the firmware required during the startup process, so that the TCM and the TPCM control module can measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, and play the active measurement function of trusted computing in the secure / trusted startup process. After the self-check in step S1203 fails, step S1209 is executed: the secure / trusted startup fails, and the startup process is terminated.

[0285] After loading and running the TCM and the TPCM control module in the trusted root, step S1205 can be executed: sign and authenticate the firmware: that is, use the TCM or the TPCM control module to sign and authenticate the firmware in the third subsystem. In the case of authentication failure, step S1209 is executed. In the case of successful authentication, steps S1206 to S1209 are executed.

[0286] Regarding the specific feasible execution processes of steps S1201 to S1203, S1206 to S1209, reference can be made to Figure 11 the relevant descriptions of S1101 to S1110 in , and this specification will not elaborate here.

[0287] In this embodiment, by loading the TCM and the TPCM control module in the trusted root, the TCM and the TPCM control module can measure the firmware of the third subsystem, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, realizing the security / trust of the entire startup chain and improving the security of the security architecture system.

[0288] However, it should be noted that in the trusted root, that is, in the hardware trusted boot root, after the self-check and power-on basic initialization are completed, the TCM and TPCM control modules are loaded and run. This implementation method requires relatively large hardware resources and higher hardware costs. Therefore, the practical applicability of this method is relatively limited.

[0289] In some embodiments, an optimized design is proposed for how to use the TCM or TPCM control module to measure the firmware. Specifically, referring to Figure 13 , the loading and running process of the TCM and the TPCM control module includes:

[0290] Load and run the TCM and the TPCM control module, and set the flag bit of the TPCM control module according to the available state of the TPCM control module. The flag bit of the TPCM control module is used to indicate whether the TPCM control module is available.

[0291] The security service platform uses the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically:

[0292] Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, use the TPCM control module to measure one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0293] If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, use the TCM module to measure one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware.

[0294] The specific process can refer to Figure 13 , in this embodiment, when loading and running the TCM and TPCM control modules in step S1307, the flag bit of the TPCM control module is also set, and then step S1308 is executed: Detect the TPCM, that is, detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and the subsequent measurement steps (S1309, S1310) use the TPCM control module for measurement. If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, the subsequent measurement steps (S1309, S1310) use the TCM for measurement.

[0295] For other execution details of steps S1301 to S1313 that are not described in detail, reference can be made toFigure 11 Regarding the relevant descriptions of S1101 to S1110, they will not be elaborated in this specification.

[0296] This embodiment is described by taking Figure 11 the shown startup process as an example. In some embodiments, the detection of the flag bit of the TPCM control module is usually performed along with the loading of the TPCM control module. When the flag bit of the TPCM control module is detected as available, the TPCM control module can be used to measure some or all of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. This can depend on the loading order of the TPCM control module and these firmwares. For example, when the loading order of the TPCM control module is prior to that of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, the TPCM control module can measure all of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. Of course, even if the loading order of the TPCM control module is prior to that of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, in some cases, only some of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware can be measured using the TPCM control module, and the remaining parts can be not measured or measured using the TCM. When the loading order of the TPCM control module is between the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware, the TPCM control module can measure some or all of the firmwares with a later loading order. This specification does not limit this.

[0297] In this embodiment, when the TPCM control module is loaded, a flag bit indicating whether the TPCM control module is available is set. When the TPCM control module is available, the TPCM control module is preferentially used to measure the firmware running during the startup process, which is beneficial to giving full play to the technical advantages of the trusted computing 3.0 route and ensuring the autonomy, controllability, security, and trustworthiness of the secure / trusted startup process.

[0298] In some embodiments, still referring to Figure 13 , after the measurement in step S1309, step S1310 is also performed: loading and running at least one of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. After that, it may further include step S1311: according to the detection result of S1308, using the TCM or the TPCM control module to measure the system kernel. If the measurement is successful, then step S1312 is executed: system initialization, and S1313: secure / trusted startup is completed. If the measurement fails, then step S1314 is executed: secure / trusted startup fails, and the startup process is terminated.

[0299] The measurement of the system kernel enables the trusted computing technology to run through the entire startup process, ensuring the security / trustedness of the entire startup process.

[0300] In some embodiments, in addition to the self-check of the TCM hardware resources, when the TCM is loaded and running, a further self-check of the TCM can be performed to ensure the security and trustedness of the TCM. Specifically, in an embodiment of this specification, the security service platform loading and running the TCM is specifically used for:

[0301] Loading the TCM.

[0302] Running the self-check program of the TCM and obtaining the self-check result returned by the self-check program of the TCM. If the self-check result is a self-check failure, the startup process is terminated.

[0303] The self-check program of the TCM can be the built-in Self-Task program of the TCM. By running this self-check program, the security and trustedness of other resources of the TCM except for the hardware resources are ensured.

[0304] It should be noted that in the above startup process, it mainly reflects the measurement of the firmware by the TCM or TPCM control module in the trusted startup process. In the trusted startup process, the secure startup process can also be carried out in parallel, that is, using the trusted root to verify the firmware step by step to realize the construction of the trust chain of the secure startup technology. Among them, the firmware can include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. As described above, the BL1 firmware can be set in the trusted root, has the characteristic of being tamper-proof, is the first piece of code to start up when powered on, and is the source of all trust chains. In this case, to implement the secure startup technology, the trusted root needs to be executed first, and then, one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware are verified by signature step by step. Exemplarily, this step-by-step signature authentication is specifically reflected in: the trusted root verifies the signature of the BL2 firmware, and then, the BL2 firmware verifies the signature of the BL31 firmware, and the BL31 firmware verifies the signatures of the BL32 and / or BL33 firmware respectively.

[0305] In some cases, the TPCM control module may be set in different subsystems from the TCM cryptographic module of the TCM. Specifically, the embodiments of this specification also provide a security architecture system, such as Figure 14As shown, it includes: a first subsystem 11, a second subsystem 12, and a third subsystem 13. The security levels corresponding to the first subsystem 11, the second subsystem 12, and the third subsystem 13 increase in sequence. The second subsystem 12 and the third subsystem 13 run in the first processor core. The security architecture system constructs a security service platform. The security service platform is built-in with a trusted cryptography module TCM. The security service platform is also equipped with a TPCM control module 22. The TPCM control module 22 is used to call the TCM in a software manner. The TCM includes a TCM cryptography module 211. The TPCM control module 22 and the TCM cryptography module 211 run in different subsystems except the first subsystem 11. The security service platform is configured as:

[0306] In response to a power-on request, execute a startup process. During the startup process, use the TCM or the TPCM control module 22 to measure the firmware running during the startup process, and record the measurement result.

[0307] In this embodiment, when the security architecture system receives or detects a power-on request, it responds to the power-on request and starts prior to the firmware required to run during the startup process. Use the TCM or the TPCM control module 22 to implement active measurement of the firmware required to run during the startup process. The active measurement of the firmware by the TCM 21 or the TPCM control module 22 can include trusted measurement, trusted storage, and trusted reporting, to achieve the construction of a trust chain of the trusted computing base. In some implementation manners, to facilitate the priority startup of the security service platform, the TCM of the security service platform and the TPCM control module 22 can be integrated with the processor of the computing device on the same chip. In this way, the external communication interface between the security service platform and the chip integrating the processor can be reduced, enabling the security service platform to easily receive or detect the power-on request, and also enabling the security service platform to conveniently use the TCM or the TPCM control module 22 to measure the firmware running during the startup process.

[0308] The measurement result can be recorded in the PCR of the security architecture system. The recorded measurement result can provide a remote verification service after the security architecture system completes startup, meeting the requirements of trusted startup. The measurement result recorded in the PCR can also be used to generate a trusted report to provide a report describing the internal state of the security architecture system to the outside world.

[0309] The TPCM control module 22 calling the TCM in a software manner can mean that the TPCM control module 22 calls the TCM by sending a software program call instruction to the TCM.

[0310] The power-on request can be a power signal after the computing device is powered on, or a request to start the system sent to the security architecture system after the computing device is powered on.

[0311] In some embodiments, the security architecture system may further include a root of trust. Based on the root of trust, hierarchical verification of the firmware is performed to achieve the construction of the trust chain of the secure boot technology. Among them, the firmware may include one or more of BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. In some embodiments, the root of trust includes BL1 firmware. In this case, the BL1 firmware has the characteristic of being tamper-proof. It is the first piece of code for power-on startup and the source of all trust chains. In this case, the security architecture system can also achieve the secure startup of the system based on the root of trust. Specifically, the secure startup process may include: first execute the root of trust, and then perform hierarchical signature verification on one or more of BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. Exemplarily, the hierarchical signature verification process may include: the root of trust verifies the BL2 firmware, and then the BL2 firmware performs signature verification on the BL31 firmware. The BL31 firmware respectively performs signature verification on the BL32 firmware and the BL33 firmware. If any level of signature verification fails, the startup process can be terminated to achieve the secure startup of the security architecture system. Optionally, in some embodiments, the firmware running during the secure startup process may not include the BL32 firmware. In this case, the BL31 firmware only needs to verify the BL33 firmware.

[0312] The first subsystem 11 may be a Rich Execution Environment (REE, also known as a rich execution environment) subsystem, which can be used to run objects such as the operating system (OS) and ordinary applications (also known as client applications (CA)) of the computing device.

[0313] The second subsystem 12 may be a Trusted Execution Environment (TEE) subsystem, which can be used to run trusted applications (Trusted Application, TA) to meet application requirements such as digital rights management (Digital Rights Management, DRM), mobile payment, and sensitive data protection.

[0314] The third subsystem 13 may be a Secure Element (SE) subsystem, which can be used to implement secure chip technology to ensure the security of important resources.

[0315] The security level, which can also be referred to as the security protection level, may refer to the level that defines the information security protection capabilities of each subsystem. The information security protection capabilities of the subsystem can be ensured through methods such as hardware isolation and / or software isolation.

[0316] Figure 14 Shows the objects that may be running / loaded in the first subsystem 11, the second subsystem 12, and the third subsystem 13. For example, system firmware, an operating system OS, or a virtual machine VM (Virtual Machine) can run in the first subsystem 11. The system firmware can be implemented as a Unified Extensible Firmware Interface (UEFI) for the desktop, server, etc. fields, or can be implemented as a boot loader (U-Boot) for the embedded field. In addition, the base firmware, system firmware, and operating system OS can communicate with an out-of-band control system (such as an embedded controller EC, a baseboard management controller BMC, etc.).

[0317] The second subsystem 12 can run a security operating system (TEE OS) on which the second subsystem 12 depends. In some embodiments, a trusted application TA can also run in the second subsystem 12. The security level of the second subsystem 12 is higher than that of the first subsystem 11, that is, the security of the second subsystem 12 is higher than that of the first subsystem 11. The second subsystem 12 can be used, for example, to support functions such as verifying the payment environment in payment services. The second subsystem 12 can provide trusted services to the first subsystem 11 and the ordinary applications running thereon and is isolated from the first subsystem 11, that is, the first subsystem 11 and the ordinary applications running thereon cannot directly access the hardware and software resources of the second subsystem 12.

[0318] The application running in the third subsystem 13 can be called a security element application (Applet), and its security is higher than that of the second subsystem 12. The third subsystem 13 can be used to store important resources such as root keys, and ensure the security of the important resources stored in the third subsystem 13 through means such as permission verification and cryptographic techniques. In the security architecture system, the security of the computing environment is ensured through the mutual cooperation among these three subsystems.

[0319] In addition, the first subsystem 11 is also used to run ordinary applications (referred to as ordinary apps), where the ordinary apps can be apps related to payment scenarios, and can implement basic operations such as browsing products, selecting products, and submitting orders. Trusted apps can run in the second subsystem 12. The trusted apps provide a trustworthy running environment for the first subsystem 11, and through the protection of confidentiality and integrity and the control of data access permissions, ensure end-to-end security. In addition, the second subsystem 12 can run in parallel with the first subsystem 11, and for example, the second subsystem 12 interacts with the first subsystem 11 through a secure Application Programming Interface (API). As an example, the first subsystem 11 can send a request for a trusted service to the second subsystem 12 to request the second subsystem 12 to provide the corresponding trusted service and make a response based on the request.

[0320] The third subsystem 13 has a higher security level than the second subsystem 12 and can be used to build a trusted and secure resource storage and computing environment. Generally, the software system in the third subsystem 13 is relatively simple and includes fewer hardware components, so it is easier to establish physical protection and implement security guarantees, thereby improving the security level of the third subsystem 13 to serve a security system with higher security requirements. As an example, the second subsystem 12 can send a request for a security service to the third subsystem 13 to request the third subsystem 13 to provide the corresponding security service and make a response based on the request. The security service requested by the second subsystem 12 can be, for example, a service related to password operations requested from the third subsystem 13, etc.

[0321] For example, in some embodiments, there is no direct physical path for the first subsystem 11 and the second subsystem 12 to access the third subsystem 13. They can only send requests to the third subsystem 13 through interactive means such as shared memory, and the third subsystem 13 provides services to the first subsystem 11 and the second subsystem 12. Regarding the third subsystem 13, as an implementation, the third subsystem 13 may include an execution engine, a static random access memory (SRAM), a non-volatile memory, or may further include a key derivation module (Key Derivation Function, KDF). Among them, important resources such as root keys can be stored in the non-volatile memory within the third subsystem 13, and the firmware or hardware of the third subsystem 13 ensures that there is no software or hardware path for the root key to be transmitted out of the third subsystem 13. In addition, the key derivation module KDF integrated within the third subsystem 13 can be implemented as software or hardware, for example, and is used to generate derived keys based on the root key. For example, the key derivation module KDF can be a hash function, which is usually used to transform a short password into a long password. Specifically, the above-mentioned shared memory may refer to a large-capacity memory that can be accessed by different processors in a multi-processor computer system. In some embodiments, resources such as the execution engine included in the third subsystem 13 can be used as trusted computing hardware resources for TCM and / or TPM.

[0322] In this embodiment, a security service platform including a TCM and a TPCM control module 22 is integrated in the third subsystem 13 of the security architecture system, so that the security service platform can measure the target firmware using the TCM or the TPCM control module 22 during the startup process and store the measurement results. The stored measurement results can be used for remote verification after the computing device is connected to the network, meeting the requirements of trusted startup. The purpose of trusted startup is achieved based on the security architecture system, which is compatible with the TCM and TPCM standards.

[0323] In addition, the TPCM control module 22 and the TCM cryptographic module 211 run in different subsystems other than the first subsystem 11, so that the TCM cryptographic module 211 and the TPCM control module 22 are isolated from each other. On the one hand, this is conducive to enhancing the independence between the TCM cryptographic module 211 and the TPCM control module 22; on the other hand, when a subsystem other than the first subsystem 11 is unavailable, the security service platform can still use the TCM cryptographic module 211 / TPCM control module 22 in another subsystem to measure the firmware running during the startup process, which is conducive to improving the robustness of the security architecture system.

[0324] Reference Figure 15 and, in combination with reference Figure 14 Figure 14 and Figure 15 ​Shows a feasible setting method of the TCM cryptographic module 211 and the TPCM control module 22. In Figure 14 the TCM cryptographic module 211 runs in the third subsystem 13, and the TPCM control module 22 runs in the second subsystem 12. In Figure 15 the TCM cryptographic module 211 runs in the second subsystem 12, and the TPCM control module 22 runs in the third subsystem 13.

[0325] Setting the TCM cryptographic module 211 in the third subsystem 13 with a higher security level is beneficial to ensuring better protection of the hardware resource foundation of the TCM (i.e., the TCM cryptographic module 211). And setting the TPCM control module 22 in the third subsystem 13 is beneficial to starting the TPCM control module 22 earlier, enabling the TPCM control module 22 to participate in the measurement work of the firmware running in the startup process earlier and giving full play to the advantages of trusted computing 3.0. The specific setting positions of the TCM cryptographic module 211 and the TPCM control module 22 can be flexibly selected according to the actual situation, and this specification does not limit this.

[0326] To flexibly configure the firmware that needs to be measured during the startup process, in some embodiments of this specification, the security service platform uses the TCM or the TPCM control module to measure the firmware running during the startup process specifically for:

[0327] Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0328] The definitions of BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware can refer to the relevant descriptions above.

[0329] In this embodiment, the security service platform can selectively measure the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware during the startup process according to the actual situation of the computing device or the actual needs for secure / trusted startup, so as to improve the applicability of the security architecture system to various application scenarios on the basis of ensuring the security of the security architecture system.

[0330] The following some embodiments introduce some possible specific startup processes. Optionally, in an embodiment of this specification, refer to Figure 16, the TCM21 further includes a TCM service module 212. The TCM service module 212 and the TCM password module 211 run in the third subsystem 13, the TPCM control module 22 runs in the second subsystem 12, and the second subsystem 12 and the third subsystem 13 run on the first processor core 31.

[0331] Reference Figure 17 , the security service platform executes a startup process. During the startup process, one or more of the following firmware are measured using the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically for:

[0332] Run the BL2 firmware and initialize the processor core of the security architecture system.

[0333] Perform self-check on the hardware resources of the TCM password module. In this step, the self-check on the hardware resources of the TCM may include self-check on hardware resources such as the random number generator of the TCM (which can be a TRNG for example), the cryptographic algorithm hardware engine, etc.

[0334] When the self-check of the hardware resources of the TCM password module passes, load and run the TCM password module.

[0335] Load and run the TCM service module and the TPCM control module.

[0336] Use the TCM or the TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware.

[0337] The specific process refers to Figure 17 :

[0338] S1701: Startup: In response to a power-on request, execute the startup process.

[0339] S1702: Load and run BL2: That is, run the BL2 firmware and initialize the processor core of the security architecture system.

[0340] S1703: Self-check of the hardware resources of the TCM: That is, perform self-check on the hardware resources of the TCM password module. When the self-check of the hardware resources of the TCM passes (or the self-check is successful), enter step S1704: Load and run the TCM password module. When the self-check of the hardware resources of the TCM fails, enter step S1710: Secure / Trusted startup fails, terminate the startup process.

[0341] S1705: Load and run the TCM service module.

[0342] S1706: Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement is successful, proceed to step S1707: Secure / Trusted Boot Completed. If the measurement fails, proceed to step S1708: Secure / Trusted Boot Failed, and terminate the boot process. In step S1706, since the TPCM control module runs in the second subsystem and is usually encapsulated with the operating system of the second subsystem, the TPCM control module cannot be loaded and run until the BL32 firmware including the operating system of the second subsystem is loaded and run.

[0343] In this embodiment, select to measure some or all of the BL2 firmware and the BL31, BL32, and BL33 firmware. On the basis of ensuring the security of the security system architecture, it is conducive to realizing the trusted boot of the security architecture system and ensuring the security of the security system architecture.

[0344] In addition, the TCM password module and the TCM service module can be loaded together when the hardware resource self-check of the TCM password module passes, which can enable the TCM to obtain complete functions as soon as possible, open the call interface for the system firmware, and meet the requirement of the system firmware to call the TCM for trusted computing.

[0345] Optionally, in another embodiment, after the security service platform runs the BL2 firmware, it is further used for:

[0346] Use the BL2 firmware to perform signature authentication on the BL31 firmware.

[0347] This process may include:

[0348] Startup: In response to a power-on request, execute the startup process.

[0349] Load and run BL2: That is, run the BL2 firmware and initialize the processor core of the security architecture system.

[0350] After the BL2 firmware runs, perform a self-check on the hardware resources of the TCM. If the self-check of the hardware resources of the TCM passes (or the self-check is successful), load and run the TCM and the TPCM control module. If the self-check of the hardware resources of the TCM fails, the secure / trusted boot fails and the boot process is terminated.

[0351] Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement fails, the secure / trusted boot fails and the boot process is terminated.

[0352] The BL2 signature authentication of BL31 means that after the BL2 firmware runs, the BL2 firmware is also used to perform signature authentication on the BL31 firmware. When the signature authentication of the BL31 firmware by the BL2 firmware is successful and the measurement results of BL31, BL32, and BL33 are successful, the secure / trusted boot is completed; otherwise, the secure / trusted boot fails and the boot process is terminated.

[0353] In this embodiment, the dual authentication of the BL31 firmware by the BL2 firmware and the TCM / TPCM control module is utilized to achieve the organic combination of secure / trusted boot and improve the security of the security architecture system.

[0354] In one embodiment of this specification, referring to Figure 18 , the TCM further includes a TCM service module. The TCM service module 212 and the TCM cryptographic module 211 run in the third subsystem 13, and the second subsystem 12 runs on the second processor core 32, and the third subsystem 13 runs on the third processor core 33;

[0355] The security service platform executes the boot process. During the boot process, one or more of the following firmwares are measured by using the TCM or the TPCM control module: the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware. Specifically:

[0356] Load and run the firmware in the third subsystem to initialize the third subsystem;

[0357] Self-check the hardware resources of the TCM cryptographic module;

[0358] When the self-check of the hardware resources of the TCM cryptographic module passes, load and run the TCM;

[0359] Measure the BL2 firmware by using the TCM;

[0360] Run the BL2 firmware;

[0361] Measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware by using the TCM or the TPCM control module.

[0362] In this embodiment, since the second subsystem and the third subsystem run on different processor cores respectively, the third subsystem has Turing completeness and can execute tasks independently, which is beneficial to improving the task execution efficiency of the third subsystem.

[0363] It is precisely because the third subsystem is Turing complete that during the startup process, the firmware in the third subsystem can be loaded and run first to initialize the third subsystem, enabling the third subsystem to have a running environment. The subsequent measurement steps can refer to Figure 17 the relevant descriptions in

[0364] In some embodiments, an optimized design is proposed for how to measure the firmware using the TCM or TPCM control module. Specifically, when the TPCM control module runs in the second subsystem and the TCM service module and the TPM password module run in the third subsystem, refer to Figure 19 wherein the security service platform uses the TCM or the TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware, specifically for:

[0365] Using the TCM to measure the BL31 firmware;

[0366] When the BL31 firmware passes the authentication, load and run the BL31 firmware; when the BL31 firmware fails the authentication, terminate the startup process.

[0367] Using the TCM to measure the BL32 firmware;

[0368] Run the BL32 firmware and the TPCM control module;

[0369] Detect the available state of the TPCM control module and set a flag bit representing the available state of the TPCM control module;

[0370] If the flag bit represents that the TPCM control module is available, use the TPCM control module to measure the BL33 firmware;

[0371] If the flag bit represents that the TPCM control module is not available, use the TCM to measure the BL33 firmware.

[0372] The specific steps include:

[0373] S1901: Measure BL31: Since the TPCM control module runs in the second subsystem, the TPCM control module is not running yet before the BL32 firmware is loaded and run. At this time, it is necessary to use the TCM to measure the BL31 firmware.

[0374] If the measurement of the BL31 firmware is successful, execute step S1902: Load and run BL31. If the measurement of the BL31 firmware fails, execute step S1907: Secure / Trusted startup fails, terminate the startup process.

[0375] S1903: Measure BL32: Similarly, since the TPCM control module is not running before the BL32 firmware is loaded, it is necessary to use the TCM that has been loaded and run in the previous steps to measure the BL32 firmware.

[0376] If the BL32 firmware measurement is successful, proceed to step S1904: Load and run the BL32 firmware and the TPCM control module.

[0377] If the BL32 firmware measurement fails, then execute step S1907: Secure / Trusted boot fails, terminate the boot process.

[0378] S1905: Detect the TPCM control module: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and use the TPCM control module for subsequent measurement steps (S1906). If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, use the TCM for subsequent measurement steps (S1906).

[0379] S1906: Measure BL33: According to the detection result of step S1905, select the TCM or the TPCM control module to measure the BL33 firmware.

[0380] If the BL33 firmware measurement fails, then execute step S1907: Secure / Trusted boot fails, terminate the boot process.

[0381] If the BL33 firmware measurement is successful, then execute step S1908: Secure / Trusted boot is completed.

[0382] The steps before step S1901 vary depending on factors such as whether the second subsystem and the third subsystem run on the same processor core. The specific feasible execution process can refer to the relevant descriptions in the above text.

[0383] In this embodiment, when the TPCM control module is loaded, a flag bit indicating whether the TPCM control module is available is set, and when the TPCM control module is available, the TPCM control module is preferentially used to measure the firmware running during the boot process, which is beneficial to giving play to the technical advantages of the trusted computing 3.0 route and ensuring the autonomy, controllability, security, and trustworthiness of the secure / trusted boot process.

[0384] In one embodiment of this specification, refer to Figure 20, the TCM further includes a TCM service module 212. The TCM service module 212 and the TPCM control module 22 run in the second subsystem 12, the TCM password module 211 runs in the third subsystem 13, and the second subsystem 12 and the third subsystem 13 run on the first processor core 31;

[0385] As Figure 21 shown, the security service platform executes a startup process. During the startup process, one or more of the following firmware is measured by using the TCM or the TPCM control module: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically for:

[0386] Perform self-check on the hardware resources of the TCM password module.

[0387] When the self-check of the hardware resources of the TCM password module passes, load and run the TCM password module.

[0388] Use the TCM password module to measure the BL2 firmware.

[0389] Run the BL2 firmware and initialize the processor core of the security architecture system.

[0390] Use the TCM or the TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware.

[0391] Refer to Figure 21 , the specific startup process includes:

[0392] S2101: Startup: In response to a power-on request, execute the startup process.

[0393] S2102: Load and run BL2: That is, run the BL2 firmware and initialize the processor core of the security architecture system.

[0394] S2103: Self-check of the hardware resources of the TCM: That is, after the BL2 firmware runs, perform a self-check on the hardware resources of the TCM password module. When the self-check of the hardware resources of the TCM passes (or the self-check is successful), enter step S2104: Load and run the TCM password module. When the self-check of the hardware resources of the TCM fails, enter step S2107: Secure / Trusted startup fails, terminate the startup process.

[0395] S2105: Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement is successful, proceed to step S2106: Secure / Trusted Boot Completed. If the measurement fails, proceed to step S2107: Secure / Trusted Boot Failed, and terminate the boot process. In step S2105, since the TPCM control module and the TCM service module run in the second subsystem and are usually encapsulated with the operating system of the second subsystem, the TPCM control module and the TCM service module can only be loaded and run after the BL32 firmware including the operating system of the second subsystem has been loaded and run.

[0396] In this embodiment, the TCM service module is not loaded and run together with the TCM cryptographic module. The task of loading and running the TCM service module can be placed in a stage when the computing resources are relatively sufficient for loading (for example, after the BL2 firmware has been loaded and run), which is beneficial to shortening the boot time required for the boot process.

[0397] For a computing device with a multi-core processor, in some embodiments, refer to Figure 22 , the TCM service module 212 and the TPCM control module 22 run in the second subsystem 12, and the second subsystem 12 runs on the second processor core 32, and the third subsystem 13 runs on the third processor core 33;

[0398] Refer to Figure 23 , the security service platform executes the boot process. During the boot process, use the TCM or the TPCM control module to measure one or more of the following firmwares: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware. Specifically for:

[0399] Load and run the firmware in the third subsystem to initialize the third subsystem;

[0400] Perform self-check on the hardware resources of the TCM cryptographic module;

[0401] When the self-check of the hardware resources of the TCM cryptographic module passes, load and run the TCM cryptographic module;

[0402] Use the TCM cryptographic module to measure the BL2 firmware;

[0403] Load and run the BL2 firmware to initialize the processor core of the security architecture system;

[0404] Use the TCM or the TPCM control module to measure one or more of the following firmware: BL31 firmware, BL32 firmware, BL33 firmware.

[0405] For specific steps, refer to Figure 23 , including:

[0406] S2301: Startup: In response to a power-on request, execute the startup process.

[0407] S2302: Load and run the firmware of the third subsystem to initialize the third subsystem. In this embodiment, since the third subsystem runs on a separate second processor core and is Turing complete, it can run the firmware in the third subsystem by itself.

[0408] S2303: Self-check of the hardware resources of the TCM: That is, self-check the hardware resources of the TCM password module. When the self-check of the hardware resources of the TCM passes (or is successful), enter step S2304: Load and run the TCM password module. When the self-check of the hardware resources of the TCM fails, enter step S2309: Secure / Trusted startup fails, terminate the startup process.

[0409] S2305: Measure BL2: Use the TCM password module to measure the BL2 firmware. When the measurement result of the BL2 firmware passes (or is successful), enter step S2306: Load and run BL2: That is, load and run the BL2 firmware to initialize the processor core of the security architecture system. When the measurement result of the BL2 firmware fails, enter step S2309 to terminate the startup process.

[0410] S2307: Measure BL31, BL32, BL33: Use the TCM or TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware. If the measurement is successful, enter step S2308: Secure / Trusted startup completed. If the measurement fails, enter step S2309: Secure / Trusted startup fails, terminate the startup process. In step S2307, since the TPCM control module and the TCM service module run in the second subsystem and are usually encapsulated with the operating system of the second subsystem, the TPCM control module and the TCM service module can be loaded and run only after the BL32 firmware including the operating system of the second subsystem is loaded and run.

[0411] In this embodiment, the third subsystem is loaded and run first during the startup process, enabling the third subsystem to run normally first, which is beneficial to improving the task processing efficiency of the third subsystem and thus improving the startup efficiency.

[0412] For the case where the TCM service module and the TPCM control module run in the second subsystem, and the TCM cryptographic module runs in the third subsystem (i.e., the second subsystem runs on the second processor core and the third subsystem runs on the third processor core), some embodiments of this specification provide a measurement method for a BL3 firmware (i.e., at least one of the BL31 firmware, the BL32 firmware, and the BL33 firmware). Specifically, referring to Figure 24 The security service platform uses the TCM or the TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware, specifically for:

[0413] Use the TCM cryptographic module to measure the BL31 firmware.

[0414] When the BL31 firmware authentication is passed, load and run the BL31 firmware. When the BL31 firmware authentication fails, terminate the startup process.

[0415] Use the TCM cryptographic module to measure the BL32 firmware.

[0416] Run the BL32 firmware, the TCM service module, and the TPCM control module.

[0417] Detect the available state of the TPCM control module and set a flag bit representing the available state of the TPCM control module.

[0418] If the flag bit represents that the TPCM control module is available, use the TPCM control module to measure the BL33 firmware.

[0419] If the flag bit represents that the TPCM control module is unavailable, use the TCM to measure the BL33 firmware.

[0420] The specific steps include:

[0421] S2401: Measure BL31: Since the TCM service module and the TPCM control module run in the second subsystem, before loading and running the BL32 firmware, the TCM service module and the TPCM control module are not yet running. At this time, the TCM cryptographic module is needed to measure the BL31 firmware.

[0422] If the BL31 firmware measurement is successful, execute step S2402: Load and run BL31. If the BL31 firmware measurement fails, execute step S2407: Secure / Trusted boot fails, terminate the startup process.

[0423] S2403: Measure BL32: Similarly, since the TCM service module and the TPCM control module are not running before the BL32 firmware is loaded, it is necessary to use the TCM password module that has been loaded and run in the previous steps to measure the BL32 firmware.

[0424] If the BL32 firmware measurement is successful, proceed to step S2404: Load and run the BL32 firmware and the TPCM control module.

[0425] If the BL32 firmware measurement fails, then execute step S2407: Secure / Trusted boot fails, terminate the boot process.

[0426] S2405: Detect the TPCM control module: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, enable the TPCM control module, and use the TPCM control module for subsequent measurement steps (S2406). If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, use the TCM for subsequent measurement steps (S2406).

[0427] S2406: Measure BL33: According to the detection result of step S2405, select the TCM or the TPCM control module to measure the BL33 firmware.

[0428] If the BL33 firmware measurement fails, then execute step S2407: Secure / Trusted boot fails, terminate the boot process.

[0429] If the BL33 firmware measurement is successful, then execute step S2408: Secure / Trusted boot completed.

[0430] The steps before step S2401 vary depending on factors such as whether the second subsystem and the third subsystem run on the same processor core. The specific feasible implementation can refer to the relevant descriptions in the above text.

[0431] In this embodiment, when the TPCM control module is loaded, a flag bit indicating whether the TPCM control module is available is set, and when the TPCM control module is available, the TPCM control module is preferentially used to measure the firmware running during the boot process, which is beneficial to giving play to the technical advantages of the trusted computing 3.0 route and ensuring the autonomy, controllability, security, and trustworthiness of the secure / trusted boot process.

[0432] To ensure that the secure / trusted boot process is trusted from the very beginning of the boot process, in some embodiments, refer to Figure 25When the second subsystem 12 and the third subsystem 13 run on the same processor core (i.e., the first processor core 31), a trusted root 40 is also set in the security service platform. The trusted root 40 can be the first line (section) or the first few lines (sections) of code written in the ROM of the processor of the computing device and is the source of all trust chains. The trusted root 40 may include the BL1 firmware.

[0433] Execute the trusted root to perform self-check on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, use the trusted root to perform signature authentication on the BL2 firmware.

[0434] The security service platform runs the BL2 firmware specifically for:

[0435] When the BL2 firmware passes the authentication, run the BL2 firmware. When the BL2 firmware fails the authentication, terminate the startup process.

[0436] Regarding the startup process after running the BL2 firmware, reference can be made to the relevant description of the startup process when the second subsystem and the third subsystem run on the same processor core in the above text, and this specification will not elaborate here.

[0437] In this embodiment, by measuring the BL2 firmware with the trusted root, the security / trust of the entire startup chain is achieved, improving the security of the security architecture system.

[0438] Reference Figure 26 When the second subsystem 12 and the third subsystem 13 run on different processor cores (i.e., the second subsystem 12 runs on the second processor core 32 and the third subsystem 13 runs on the third processor core 33), a trusted root 40 is also set in the security service platform. The trusted root 40 can be the first line (section) or the first few lines (sections) of code written in the ROM of the processor of the computing device and is the source of all trust chains. In some embodiments, due to the characteristic that the BL1 firmware is stored in the ROM and is not easily tampered with, the trusted root 40 includes the BL1 firmware.

[0439] Before the security service platform loads and runs the firmware in the third subsystem, the security architecture system with a built-in trusted root is also used for:

[0440] Execute the trusted root;

[0441] Perform signature authentication on the firmware in the third subsystem through the trusted root;

[0442] The security service platform loads and runs the firmware in the third subsystem specifically for:

[0443] When the firmware authentication in the third subsystem passes, load and run the firmware in the third subsystem.

[0444] When the firmware authentication in the third subsystem fails, terminate the startup process.

[0445] For the startup steps after loading and running the firmware in the third subsystem, reference can be made to the relevant description of the startup process when the second subsystem and the third subsystem run on different processor cores in the above text, and this specification will not elaborate here.

[0446] In this embodiment, by measuring the firmware in the third subsystem through the trusted root, the security / trustedness of the entire startup chain is achieved, improving the security of the security architecture system.

[0447] In addition, the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware do not execute the corresponding firmware loading tasks after the measurement fails and terminate the startup process, which can meet the requirements of the secure startup of the security architecture system.

[0448] In some embodiments, after the measurement of the firmware required to run during the startup process is completed, in order to ensure the system security of the entire computing device, the security architecture system is set in the computing device, and the security service platform is further used for:

[0449] Measure the operating system kernel of the computing device by using the TCM or the TPCM control module.

[0450] When the measurement result of the operating system kernel of the computing device passes, load the operating system kernel to initialize the hardware resources of the computing device and boot the operating system, thereby completing the startup of the computing device.

[0451] In this embodiment, the operation of measuring the operating system kernel of the computing device by using the TCM or the TPCM control module is realized, ensuring the security and trustedness of the entire startup chain.

[0452] In some embodiments, in addition to the self-check of the TCM hardware resources, when the TCM is loaded and run, the TCM can be further self-checked to ensure the security and trustedness of the TCM. Specifically, in an embodiment of this specification, the security service platform loading and running the TCM is specifically used for:

[0453] Load the TCM.

[0454] Run the self-check program of the TCM and obtain the self-check result returned by the self-check program of the TCM. If the self-check result is a self-check failure, terminate the startup process.

[0455] The self-check program of the TCM can be the Self-Task program built into the TCM. By running this self-check program, the security and trustworthiness of other resources except for the hardware resources of the TCM are ensured.

[0456] It should be noted that in the above startup process, it mainly reflects the measurement of the firmware by the TCM or the TPCM control module during the trusted startup process. During the trusted startup process, the secure startup process can also be carried out in parallel, that is, the trusted root is used to verify the firmware step by step to build the trust chain of the secure startup technology. Among them, the firmware can include one or more of the BL1 firmware, BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware. As mentioned above, the BL1 firmware can be set in the trusted root, has the characteristic of being tamper-proof, is the first piece of code to be powered on and started, and is the source of all trust chains. In this case, to implement the secure startup technology, the trusted root needs to be executed first, and then, one or more of the BL2 firmware, BL31 firmware, BL32 firmware, and BL33 firmware are verified by signature step by step. Exemplarily, this step-by-step signature authentication is specifically reflected in: the trusted root verifies the signature of the BL2 firmware, and then, the BL2 firmware verifies the signature of the BL31 firmware, and the BL31 firmware verifies the signatures of the BL32 and / or BL33 firmware respectively.

[0457] Exemplary Method

[0458] The embodiment of this specification also provides a method for implementing secure and trusted startup, which is applied to a security architecture system, such as Figure 27 As shown, the method for implementing secure and trusted startup includes:

[0459] S2701: In response to the power-on request, execute the startup process. During the startup process, use the TCM or the TPCM control module to measure the firmware running during the startup process and record the measurement results.

[0460] The security architecture system may include: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in the first processor core. The security architecture system constructs a security service platform, and the security service platform is built with a trusted password module TCM. The security service platform also carries a TPCM control module. The TPCM control module is used to call the TCM in a software manner. The TCM includes a TCM password module. The TPCM control module and the TCM password module run in different subsystems except for the first subsystem.

[0461] The security architecture system may also include: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in the first processor core. The security architecture system constructs a security service platform, which is built-in with a Trusted Cryptography Module (TCM). The security service platform also carries a TPCM control module, which is used to call the TCM in a software manner. The TCM and the TPCM control module run in the third subsystem.

[0462] The security architecture system may also include: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem runs in the first processor core, and the third subsystem runs in the second processor core. The security architecture system constructs a security service platform, which is built-in with a Trusted Cryptography Module (TCM). The security service platform also carries a TPCM control module, which is used to call the TCM in a software manner. The TCM and the TPCM control module run in the third subsystem.

[0463] Optionally, during the startup process, using the TCM or the TPCM control module to measure the firmware running during the startup process includes:

[0464] Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

[0465] For the specific structure of the security architecture system and the specific feasible execution steps of the method for implementing secure and trustworthy startup corresponding to each specific structure, reference can be made to the relevant descriptions in the above "Exemplary System". Details are not elaborated herein.

[0466] Exemplary Electronic Device

[0467] Another embodiment of this application also proposes an electronic device. Refer to Figure 28 As shown, an exemplary embodiment of this specification also provides an electronic device, including: a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it executes the steps in the method for implementing secure and trustworthy startup according to various embodiments of this specification described in the above embodiments of this specification.

[0468] The internal structure of this electronic device may be as Figure 28As shown, the electronic device includes a processor, a memory, a network interface, and an input device connected via a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the central control device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it performs the steps in the method for implementing secure and trusted boot according to various embodiments of this specification described in the above embodiments of this specification.

[0469] The processor may include a main processor, and may also include a baseband chip, a modem, etc.

[0470] The memory stores a program for implementing the technical solution of the present invention, and may also store an operating system and other key services. Specifically, the program may include program code, and the program code includes computer operation instructions. More specifically, the memory may include a read-only memory (ROM), other types of static storage devices that can store static information and instructions, a random access memory (RAM), other types of dynamic storage devices that can store information and instructions, a disk memory, a flash memory, etc.

[0471] The processor may be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present invention. It may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0472] The input device may include a device for receiving user input data and information, such as a keyboard, a mouse, a camera, a scanner, a light pen, a voice input device, a touch screen, a pedometer, or a gravity sensor, etc.

[0473] The output device may include a device for allowing output of information to the user, such as a display screen, a printer, a speaker, etc.

[0474] The communication interface may include any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, a radio access network (RAN), a wireless local area network (WLAN), etc.

[0475] The processor executes the program stored in the memory and calls other devices, which can be used to implement each step of any one of the methods for implementing secure and trustworthy startup provided in the above embodiments of the present application.

[0476] The electronic device may further include a display component and a voice component. The display component may be a liquid crystal display screen or an electronic ink display screen. The input device of the electronic device may be a touch layer covering the display component, or a button, a trackball or a touchpad provided on the outer shell of the electronic device, or an external keyboard, a touchpad or a mouse, etc.

[0477] Those skilled in the art can understand that Figure 28 the structure shown in

[0478] Exemplary Computer Program Product and Storage Medium

[0479] In addition to the above methods and devices, the method for implementing secure and trustworthy startup provided in the embodiments of this specification may also be a computer program product, which includes computer program instructions. When the computer program instructions are run by a processor, the processor is caused to execute the steps in the method for implementing secure and trustworthy startup according to various embodiments of this specification described in the "Exemplary Method" section above of this specification.

[0480] The computer program product may be written in any combination of one or more programming languages for programming code to perform the operations of the embodiments of this specification. The programming languages include object-oriented programming languages such as Java, C++, etc., and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, executed as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0481] In addition, the embodiments of this specification also provide a computer-readable storage medium, on which a computer program is stored. The computer program is executed by a processor to perform the steps in the method for implementing secure and trustworthy startup according to various embodiments of this specification described in the "Exemplary Method" section above of this specification.

[0482] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in this specification can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0483] The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0484] The above-described embodiments merely represent several implementation manners of this specification. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the solutions provided by the embodiments of this specification. It should be noted that for those of ordinary skill in the art, without departing from the concept of this specification, several modifications and improvements can still be made, and these all belong to the protection scope of this specification. Therefore, the protection scope of the patent of this specification should be subject to the appended claims.

Claims

1. A security architecture system, characterized in that, Including: A first subsystem, a second subsystem, and a third subsystem, where the security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in the first processor core. The security architecture system constructs a security service platform, which has a trusted cryptography module (TCM) built-in. The security service platform also carries a TPCM control module. The TCM and the TPCM control module run in the third subsystem. The security service platform is configured to: In response to a power-on request, execute a startup process. During the startup process, use the TCM or the TPCM control module to measure the firmware running during the startup process and record the measurement result. Among them, during the process of using the TPCM control module to measure the firmware, the TPCM control module calls the TCM in a software manner. The TPCM control module calling the TCM in a software manner means that the TPCM control module actively calls the TCM to provide security measurement services by sending a software program call instruction to the TCM. The startup process includes first running the firmware carried by each subsystem and then performing system initialization. After the firmware of the third subsystem runs, the TCM and the TPCM control module are loaded in the third subsystem so that the TCM and the TPCM control module can intervene in the firmware measurement during the startup process earlier.

2. The system according to claim 1, wherein The security service platform using the TCM or the TPCM control module to measure the firmware running during the startup process is specifically used for: Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

3. The system according to claim 2, wherein The security service platform executes the startup process. During the startup process, using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware is specifically used for: Running the BL2 firmware and initializing the processor core of the security architecture system; Performing a self-check on the hardware resources of the TCM; When the self-check of the hardware resources of the TCM passes, loading and running the TCM and the TPCM control module; Using the TCM or the TPCM control module to measure one or more of the BL31 firmware, the BL32 firmware, and the BL33 firmware.

4. The system according to claim 3, characterized in that After the security service platform runs the BL2 firmware, it is also used for: Using the BL2 firmware to perform signature authentication on the BL31 firmware.

5. The system according to any one of claims 3 or 4, characterized in that, The security service platform also includes a trusted root; the trusted root includes the BL1 firmware; Before the security service platform runs the BL2 firmware, it is also used for: Execute the trusted root to perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, use the trusted root to perform signature authentication on the BL2 firmware; The specific operation of the security service platform to run the BL2 firmware is as follows: Run the BL2 firmware when the authentication of the BL2 firmware passes.

6. The system according to claim 3 or 4, characterized in that The security service platform further includes a trusted root; the trusted root includes the BL1 firmware; Before running the BL2 firmware, the security service platform is further configured to: Execute the trusted root to perform self-checks on the trusted computing hardware resources of the first processor core and the TCM. If the self-check fails, terminate the startup process. If the self-check is successful, run the TCM and the TPCM control module in the trusted root; Use the TCM or the TPCM control module to perform signature authentication on the BL2 firmware; The specific operation of the security service platform to run the BL2 firmware is as follows: Run the BL2 firmware when the authentication of the BL2 firmware passes.

7. The system according to claim 3 or 4, characterized in that, The specific operation of the security service platform to load and run the TCM is as follows: Load the TCM; Run the self-check program of the TCM and obtain the self-check result returned by the self-check program of the TCM. If the self-check result indicates a self-check failure, terminate the startup process.

8. The system according to any one of claims 1 to 4, characterized in that, The process of the security service platform running the TPCM control module includes: Run the TPCM control module and set the flag bit of the TPCM control module according to the available status of the TPCM control module. The flag bit of the TPCM control module is used to indicate whether the TPCM control module is available; The specific operation of the security service platform to use the TCM or the TPCM control module to measure the firmware running during the startup process is as follows: Detect the flag bit of the TPCM control module. If the flag bit of the TPCM control module indicates that the TPCM control module is available, use the TPCM control module to measure one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware; If the flag bit of the TPCM control module indicates that the TPCM control module is unavailable, use the TCM module to measure one or more of the BL2 firmware, the BL31 firmware, the BL32 firmware, and the BL33 firmware.

9. The system according to any one of claims 1 to 4, characterized in that, The security architecture system is disposed in a computing device, and the security service platform is further configured to: Use the TCM or the TPCM control module to measure the operating system kernel of the computing device; When the measurement result of the operating system kernel of the computing device passes, load the operating system kernel to initialize the hardware resources of the computing device and boot the operating system, thereby completing the startup of the computing device.

10. A method for implementing secure and trusted boot, characterized in that, Applied to a security architecture system, the security architecture system includes: a first subsystem, a second subsystem, and a third subsystem. The security levels corresponding to the first subsystem, the second subsystem, and the third subsystem increase in sequence. The second subsystem and the third subsystem run in the first processor core. The security architecture system constructs a security service platform, and the security service platform is built-in with a Trusted Cryptography Module (TCM). The security service platform is also equipped with a TPCM control module. The method for realizing secure and trusted startup includes: In response to a power-on request, execute the startup process. During the startup process, use the TCM or the TPCM control module to measure the firmware running during the startup process, and record the measurement results. Among them, during the process of using the TPCM control module to measure the firmware, the TPCM control module calls the TCM in a software manner. The TPCM control module calling the TCM in a software manner means that the TPCM control module actively calls the TCM to provide security measurement services by sending software program call instructions to the TCM. The startup process includes first running the firmware carried by each subsystem, and then performing system initialization. After the firmware of the third subsystem runs, load the TCM and the TPCM control module in the third subsystem, so that the TCM and the TPCM control module can intervene in the firmware measurement during the startup process earlier.

11. The method according to claim 10, wherein During the startup process, using the TCM or the TPCM control module to measure the firmware running during the startup process includes: Using the TCM or the TPCM control module to measure one or more of the following firmware: BL2 firmware, BL31 firmware, BL32 firmware, BL33 firmware.

12. A computing device, characterized in that, The computing device includes the security architecture system according to any one of claims 1-9.

Images