A trusted platform module calling method, system and device and storage medium

Abstract

The application discloses a kind of trusted platform module calling method, system, device and storage medium, method includes: using CAmkES framework realizes seL4 system component and TPM Proxy component;According to seL4 system component, seL4 microkernel operating system is realized by Linux virtual machine;SeL4 microkernel operating system is deployed based on embedded system;When embedded system needs to be upgraded, trusted upgrade is executed by seL4 microkernel operating system;When embedded system is normally operated, TPM calling request is obtained by Linux virtual machine, and TPM calling result is returned by TPM Proxy component.The present application can provide soft TPM trusted upgrade service and TPM calling service for embedded system that cannot integrate hardware TPM, improve the trusted computing capability of embedded system, and can be widely applied in trusted computing technical field.

Description

Technical Field

[0001] This invention relates to the field of trusted computing technology, and in particular to a trusted platform module invocation method, system, device and storage medium. Background Technology

[0002] A Trusted Platform Module (TPM) is an international standard for secure cryptographic processors, typically a type of dedicated microprocessor designed to ensure hardware security through internally integrated cryptographic keys. TPM can also refer to dedicated hardware conforming to this standard, including chips and modules. TPMs can be used in areas such as digital rights management, computer system login management, software licensing, and anti-fraud. Using TPMs can effectively improve the security of TPM-protected applications and firmware, and enhance the service security of platforms equipped with TPMs.

[0003] TPM is divided into two standards: TPM1.0 and TPM2.0. TPM1.0 is a single-layer architecture, using a single RSA2048 storage root key and requiring the implementation of the SHA-1 digest algorithm, RSA public-key algorithm, AES symmetric encryption algorithm, and corresponding cryptographic primitives. It supports four authentication modes: HMAC, PCR, address information, and entity existence verification. TPM2.0 is a three-layer structure, including a platform layer, a storage layer, and an endorsement layer. Each layer contains multiple root keys. Its algorithms and cryptographic primitives additionally support the SHA256 digest algorithm and the ECC asymmetric encryption algorithm. TPM2.0 requires the implementation of a dedicated XOR function in the cryptographic primitives. Users can use authorization primitives to perform logical operations on various authentication methods to build complex authentication strategies as needed.

[0004] Due to differences in hardware design, hardware TPMs from different manufacturers, or even the same manufacturer adapting to different hardware platforms, are typically incompatible. The cryptographic functions in hardware TPMs are usually implemented using dedicated cryptographic hardware, and some firmware is stored in write-once programmable memory. Therefore, when the integrity of the computing environment changes, the provider of the change (such as a software vendor or operating system vendor) usually needs to update the hardware TPM using security credentials and internal interfaces. Consequently, integrating hardware TPMs into existing embedded systems is difficult, and it is challenging to perform trusted upgrade management and invocation of software TPMs and the system, thus affecting their trusted computing capabilities. Summary of the Invention

[0005] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0006] Therefore, one objective of this invention is to provide a trusted platform module invocation method, which can provide a software TPM trusted upgrade service and a TPM invocation service for embedded systems that cannot integrate hardware TPM, thereby improving the trusted computing capabilities of embedded systems.

[0007] Another objective of this invention is to provide a trusted platform module invocation system.

[0008] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include:

[0009] In a first aspect, embodiments of the present invention provide a trusted platform module invocation method, comprising the following steps:

[0010] The seL4 system components and TPM Proxy components are implemented using the CAmkES framework. The seL4 system components include a soft TPM component, a soft TPM trusted management component, and a VMM component.

[0011] The seL4 system components are implemented using a Linux virtual machine to create the seL4 microkernel operating system.

[0012] The seL4 microkernel operating system is deployed based on an embedded system.

[0013] When the embedded system needs to be upgraded, a trusted upgrade is performed through the seL4 microkernel operating system.

[0014] When the embedded system is running normally, it obtains TPM call requests through the Linux virtual machine and returns TPM call results through the TPM Proxy component.

[0015] Furthermore, in one embodiment of the present invention, the step of implementing the seL4 system components and TPM Proxy components using the CAmkES framework specifically includes:

[0016] A soft TPM component is implemented using the CAmkES framework. The soft TPM component is used to encrypt and protect key TPM data. The soft TPM component has a TPM call interface and a TPM upgrade interface. The TPM call interface is used to read the key TPM data, and the TPM upgrade interface is used to upgrade the soft TPM component.

[0017] A software TPM trusted management component is implemented using the CAmkES framework. The software TPM trusted management component has a TPM upgrade request interface, which is used to request the software TPM component to be upgraded.

[0018] A VMM component is implemented using the CAmkES framework. The VMM component has a relay interface, which is used to relay events between the Linux virtual machine and the software TPM component.

[0019] A TPM Proxy component is implemented using the CAmkES framework. The TPM Proxy component is used to intercept and obtain the TPM call request sent by the trusted application, and transparently pass the TPM call request to the soft TPM component through seL4 IPC. It is also used to receive the TPM call result of the soft TPM component and return it to the trusted application.

[0020] Furthermore, in one embodiment of the present invention, the step of implementing the seL4 microkernel operating system through a Linux virtual machine based on the seL4 system components specifically includes:

[0021] Install the Linux virtual machine into the VMM component;

[0022] Configure the Linux virtual machine to install the TSS protocol stack, the TPM Proxy component, related kernel modules, and the trusted application, and configure the TSS protocol stack and the TPM Proxy component to start automatically at boot.

[0023] The CAmkES framework is used to establish links between the soft TPM component, the VMM component, and the soft TPM trusted management component. The soft TPM trusted management component is configured as the first component to be loaded, and the VMM component is configured to be loaded after the soft TPM component has been loaded.

[0024] The seL4 system components are integrated with the seL4 microkernel to form the seL4 microkernel operating system.

[0025] Furthermore, in one embodiment of the present invention, the step of deploying the seL4 microkernel operating system based on the embedded system specifically includes:

[0026] The seL4 microkernel operating system is made into a bootable system image, and the bootable system image and other files required to boot the seL4 microkernel operating system are copied to the preset embedded system;

[0027] Start the embedded system, and boot the seL4 microkernel operating system on the embedded system using the bootable system image and the other files;

[0028] The configuration of the Linux virtual machine is loaded through the software TPM trusted management component, and the presence of external storage devices and trusted upgrade packages is detected.

[0029] The software TPM component is loaded through the seL4 microkernel operating system;

[0030] Once the soft TPM component has finished loading, the interface between the soft TPM trusted management component and the soft TPM component is initialized through the soft TPM trusted management component.

[0031] The configuration of the Linux virtual machine is loaded and started through the VMM component, so that the TSS protocol stack and the TPM Proxy component are started according to the configuration of the Linux virtual machine;

[0032] The interface between the TPM Proxy component and the software TPM component is initialized by the TPM Proxy component, the seL4 microkernel operating system starts up, and the embedded system starts up.

[0033] Furthermore, in one embodiment of the present invention, the step of performing a trusted upgrade through the seL4 microkernel operating system when the embedded system needs to be upgraded specifically includes:

[0034] The update file is signed using a trusted signature tool to generate a trusted upgrade package, and the trusted upgrade package is stored in an external storage device.

[0035] Insert the external storage device into the embedded system and restart the embedded system;

[0036] During the startup process of the seL4 microkernel operating system, the software TPM trusted management component is loaded according to the configuration of the Linux virtual machine, and the presence of the external storage device and the trusted upgrade package is detected.

[0037] When the soft TPM trusted management component detects the trusted upgrade package, it verifies the signature, integrity, and update version number of the trusted upgrade package;

[0038] If the verification passes, a trusted upgrade is performed using the soft TPM trusted management component.

[0039] The seL4 microkernel operating system continues to load the seL4 system components until the system boots up completely, thus achieving a complete trusted system upgrade.

[0040] Furthermore, in one embodiment of the present invention, the step of performing trusted upgrades through the soft TPM trusted management component specifically includes:

[0041] The data port between the TPM upgrade request interface and the TPM upgrade interface of the soft TPM component is initialized by the soft TPM trusted management component, and a shared memory buffer is allocated for the data port. Then, the address of the shared memory buffer is mapped to the process address space of the soft TPM trusted management component and the soft TPM component.

[0042] The trusted update data is extracted from the trusted upgrade package by the soft TPM trusted management component, and the trusted update data is written into the shared memory buffer;

[0043] Send a trusted upgrade request to the TPM upgrade interface through the TPM upgrade request interface;

[0044] The software TPM component uses cryptographic primitives to decrypt the TPM key data, reads the trusted update data in the shared memory buffer to update the decrypted TPM key data, and then uses cryptographic primitives to re-encrypt the updated TPM key data.

[0045] The software TPM component checks whether there is any content in the trusted update data that updates the Linux virtual machine. If so, the files in the Linux virtual machine image that need to be updated are updated, and the version number of the Linux virtual machine image is incremented after the update is completed.

[0046] The software TPM component increments its own version number to complete a trusted upgrade.

[0047] Furthermore, in one embodiment of the present invention, the step of obtaining the TPM call request through the Linux virtual machine and returning the TPM call result through the TPM Proxy component when the embedded system is running normally specifically includes:

[0048] The trusted application in the Linux virtual machine sends the TPM call request to the TSS protocol stack based on the standard API.

[0049] The TPM Proxy component uses API interception to obtain the TPM call request, and then transparently passes the TPM call request to the soft TPM component via seL4 IPC.

[0050] The software TPM component processes the TPM call request to obtain the TPM call interface, and then uses seL4IPC to return the TPM call result to the TPM Proxy component in the Linux virtual machine.

[0051] The TPM Proxy returns the TPM call result to the trusted application, enabling the trusted application to obtain standard TPM services and realize a complete software TPM call.

[0052] Secondly, embodiments of the present invention provide a trusted platform module invocation system, including:

[0053] The component implementation module is used to implement the seL4 system components and TPM Proxy components using the CAmkES framework. The seL4 system components include a soft TPM component, a soft TPM trusted management component, and a VMM component.

[0054] The system implementation module is used to implement the seL4 microkernel operating system through a Linux virtual machine based on the seL4 system components;

[0055] The system deployment module is used to deploy the seL4 microkernel operating system based on the embedded system;

[0056] A trusted upgrade module is used to perform a trusted upgrade through the seL4 microkernel operating system when the embedded system needs to be upgraded.

[0057] The TPM invocation module is used to obtain TPM invocation requests through the Linux virtual machine when the embedded system is running normally, and to return TPM invocation results through the TPM Proxy component.

[0058] Thirdly, embodiments of the present invention provide a trusted platform module invocation device, comprising:

[0059] At least one processor;

[0060] At least one memory for storing at least one program;

[0061] When the at least one program is executed by the at least one processor, the at least one processor implements the aforementioned trusted platform module invocation method.

[0062] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a processor-executable program, which, when executed by a processor, is used to perform the aforementioned trusted platform module invocation method.

[0063] The advantages and beneficial effects of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention:

[0064] This invention deploys a seL4 microkernel operating system with seL4 as its kernel on an embedded system. It uses the CAmkES framework to build a soft TPM component, a soft TPM trusted management component, and a VMM component. A Linux virtual machine is deployed within the VMM component for operational use. The soft TPM component can use built-in cryptographic primitives to encrypt and protect critical TPM data. The Linux virtual machine can obtain standard TPM services from the soft TPM component through the seL4 IPC mechanism. The soft TPM trusted management component uses trusted upgrade packages to collect critical TPM data from the soft TPM component. The CapDL language of the CAmkES framework grants each component the most limited permissions to complete its required work. The seL4 microkernel can protect the operation of each component and critical TPM data through a capability-based mandatory access control mechanism, rejecting unauthorized access. This provides trusted soft TPM upgrade services and TPM invocation services for embedded systems that cannot integrate hardware TPMs, improving the trusted computing capabilities of the embedded system. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments of the present invention are described below. It should be understood that the drawings described below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 A flowchart illustrating the steps of a trusted platform module invocation method provided in this embodiment of the invention;

[0067] Figure 2 A schematic diagram of the structure of an embedded system with a seL4 microkernel operating system deployed in an embodiment of the present invention;

[0068] Figure 3 A flowchart for trusted upgrades of software TPM components and Linux virtual machines provided in this embodiment of the invention;

[0069] Figure 4 A timing diagram for trusted upgrades of software TPM components and Linux virtual machines provided in an embodiment of the present invention;

[0070] Figure 5 A flowchart illustrating the process of a trusted application obtaining standard TPM services for a Linux virtual machine, as provided in an embodiment of the present invention.

[0071] Figure 6 A timing diagram for trusted applications of Linux virtual machines to obtain standard TPM services provided in embodiments of the present invention;

[0072] Figure 7 A structural block diagram of a trusted platform module invocation system provided in an embodiment of the present invention;

[0073] Figure 8 This is a structural block diagram of a trusted platform module invocation device provided in an embodiment of the present invention. Detailed Implementation

[0074] The embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0075] In the description of this invention, "multiple" means two or more. The use of "first" and "second" is for distinguishing technical features only and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or the order of the indicated technical features. Furthermore, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art.

[0076] First, the relevant entities in the embodiments of the present invention will be explained.

[0077] seL4 is a formally verified, highly real-time microkernel operating system with capability-based mandatory access control security. In seL4, when an entity needs to access another object, it must explicitly declare the required "capability" attribute during the build phase. This attribute includes a reference to the target object and its specific permissions (e.g., read-only, write-only, or read-write). seL4 also has virtual machine management capabilities, enabling it to support the operation of general-purpose Linux operating systems through hardware virtualization.

[0078] To perform an operation, a seL4 application must invoke a capability it possesses that grants it sufficient access to the required service. Based on this design, the system ensures that software components are isolated from each other and authorizes and controls communication between components by selectively granting specific communication capabilities. Only components explicitly authorized by their capabilities are allowed to perform the corresponding operations.

[0079] A capability is an unforgeable credential containing a reference to a specific kernel object, such as a Thread Control Block (TCB), and access permissions regarding which methods can be invoked (to be applied to this object). Conceptually, a capability resides in an application's capability space, where an address points to a slot that may contain a capability. An application can access services such as kernel services by referencing a capability using the address of the slot containing the capability. The capability mechanism is enforced by the seL4 kernel and has a high level of security.

[0080] The CAmkES framework is a type of system module that runs natively on seL4 and provides services to the seL4 system. The CAmkES framework is written in CAmkES ADL, a formal architecture description language that contains precise descriptions of components, interfaces, and the linkers that connect them. CAmkES ensures that what system designers describe in ADL is an accurate description of the possible interactions between components and ensures that no behavior outside the design scope is generated. This is achieved through CapDL, the capability allocation language within the CAmkES platform. The CAmkES framework includes a compiler that automatically translates CAmkES ADL into CapDL, eliminating the need for designers to write CapDL code themselves.

[0081] CapDL is a precise expression of access permissions in the seL4 system, and seL4 is responsible for its execution. This means that as long as the system runs components written in CapDL, CapDL can guarantee that the behavior of the components is consistent with that described by CAmkES ADL, thereby ensuring strong security for the system and its components.

[0082] seL4 microkernel: The kernel of the seL4 microkernel operating system, used to schedule CAmkES system components and use a capability-based mandatory access control mechanism to whitelist access permissions for system components, achieving strong isolation between system components and virtualization Linux support.

[0083] The seL4SharedDataWithCaps data port linker, also known as the CAmkES linker, is capable of manipulating memory frames and can be used to establish cross-virtual machine data ports, enabling the VMM to map the shared memory buffers of the data ports into the virtual machine address space. In this invention, this linker is used to establish a shared memory buffer between the soft TPM component and the TPM Proxy, allowing the TPM Proxy to access the shared memory buffer and exchange data with the soft TPM component using the dataport kernel module in the Linux virtual machine.

[0084] seL4SharedData data port linker: CAmkES linker, used to establish data ports between CAmkES components. In this invention, this linker is used to establish a link between a soft TPM component and a soft TPM trusted management component, thereby enabling the data ports of the corresponding interfaces between the above components to establish a shared memory buffer.

[0085] The software TPM component, a CAmkES system component, implements the standard TPM services required by the TPM specification. Critical TPM data, including the endorsement key, is encrypted and stored internally by the component's cryptographic primitives. The component has two interfaces: a TPM call interface for providing standard TPM services to Linux virtual machines, allowing only reading of critical TPM data; and a TPM upgrade interface for upgrading the software TPM. This upgrade uses a seL4 capability-based mandatory access control mechanism, authorizing only the software TPM trusted management component to call the upgrade, allowing reading and writing of critical TPM data. This interface also includes a seL4 notification interface and a shared memory buffer based on the seL4SharedData data port linker.

[0086] The software TPM trusted management component, CAmkES system component, is used to discover and verify trusted upgrade packages, and extract trusted update data from verified trusted upgrade packages to upgrade the software TPM component. The component includes a TPM upgrade request interface for upgrading the software TPM component. This interface includes a notification interface based on the seL4 notification mechanism and a shared memory buffer based on the seL4SharedData data port linker. The component is implemented to detect the presence of external storage devices and trusted upgrade packages after loading; if a trusted upgrade package is detected, a trusted upgrade is automatically performed.

[0087] VMM Component: The CAmkES system component implements a VMM for running Linux virtual machines, providing support for cross-virtual machine communication. The component includes a notification interface based on the seL4 notification mechanism, used to relay events between the Linux virtual machine and the software TPM component.

[0088] Linux Virtual Machine: A virtualized Linux operating system running within the VMM component, equipped with the TSS protocol stack, TPMProxy, and three kernel modules: emits_event and consumers_event. Embedded system users utilize this virtual machine for their work.

[0089] The dataport kernel module: This module is used to create shared memory between the virtual machine and the seL4 native CAmkES component. In this invention, this module is used to establish a shared memory buffer between the Linux virtual machine and the software TPM component.

[0090] The emits_event kernel module: This module allows a process within a Linux virtual machine to send an event to the seL4 native CAmkES component across virtual machines. In this invention, this module is used by the TPM Proxy to notify the soft TPM component to retrieve TPM call requests from their shared memory buffer.

[0091] The `consumes_event` kernel module allows a process in a Linux virtual machine to use system calls to wait for or poll for an event emitted by the seL4 native CAmkES component. In this invention, this module is used by the TPM Proxy to wait for notifications from the soft TPM component in order to retrieve the TPM call results from their shared memory buffer.

[0092] TSS Protocol Stack: A Linux virtual machine protocol stack used in computers with hardware TPM to accept TPM service API requests from applications, access the TPM via system APIs, obtain TPM call results, and return them to the calling application. In this invention, this protocol stack is not actually active; TPM call requests sent to this stack will be intercepted by the TPM Proxy.

[0093] TPM Proxy: A Linux virtual machine application that uses an API to intercept TPM call requests sent by applications to the TSS protocol stack, transparently passes them to the soft TPM component via seL4 IPC, receives TPM call results from the soft TPM component, and returns them to the application. TPM Proxy includes a TPM call request interface for obtaining standard TPM services from the soft TPM component. This interface includes a notification interface based on the emits_event and consumers_event kernel modules and a shared memory buffer based on the dataport kernel module and the seL4SharedDataWithCaps data port linker.

[0094] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0095] like Figure 2The diagram illustrates the structure of an embedded system deployed with the seL4 microkernel operating system, as provided in an embodiment of the present invention. This embodiment applies seL4 to a software TPM and its trusted management. As a microkernel that has undergone complete formal verification and implementation proof, seL4 possesses a capability-based mandatory access control mechanism, enabling fine-grained and strict control over the access permissions of various system components. The permissions of seL4 system components developed using the formally verified CAmkES platform are restricted by CapDL, granting only the minimum permissions required to complete their work. Permission control is executed by the seL4 microkernel. Therefore, the method proposed in this embodiment has good security, effectively ensuring the security of standard TPM services and TPM standard services, and enabling trusted upgrades of software TPM components and Linux virtual machines. Furthermore, compared to traditional hardware TPMs, the software TPM of this invention has better hardware adaptation flexibility, providing standard TPM services for embedded systems that are difficult to integrate with hardware TPMs.

[0096] Reference Figure 1 This invention provides a trusted platform module invocation method, which specifically includes the following steps:

[0097] S101. The seL4 system components and TPM Proxy components are implemented using the CAmkES framework. The seL4 system components include the soft TPM component, the soft TPM trusted management component, and the VMM component.

[0098] Step S101 specifically includes the following steps:

[0099] S1011. The soft TPM component is implemented using the CAmkES framework. The soft TPM component is used to encrypt and protect the key TPM data. The soft TPM component has a TPM call interface and a TPM upgrade interface. The TPM call interface is used to read the key TPM data, and the TPM upgrade interface is used to upgrade the soft TPM component.

[0100] S1012. The soft TPM trusted management component is implemented using the CAmkES framework. The soft TPM trusted management component has a TPM upgrade request interface, which is used to request the soft TPM component to be upgraded.

[0101] S1013. The VMM component is implemented using the CAmkES framework. The VMM component has a relay interface, which is used to relay events between the Linux virtual machine and the software TPM component.

[0102] S1014. The TPM Proxy component is implemented using the CAmkES framework. The TPM Proxy component is used to intercept and obtain TPM call requests sent by trusted applications, and transparently pass the TPM call requests to the soft TPM component through seL4 IPC. It is also used to receive the TPM call results of the soft TPM component and return them to the trusted application.

[0103] Specifically, a soft TPM component is implemented using the CAmkES framework. This soft TPM component encrypts and protects critical TPM data, including the endorsement key, and provides two interfaces: a TPM call interface for providing standard TPM services to Linux virtual machines, which only reads critical TPM data; and a TPM upgrade interface for upgrading the soft TPM, which, through the seL4 capability-based mandatory access control mechanism, is only authorized to be called by the soft TPM trusted management component and can read and write critical TPM data. Each interface includes a notification interface based on the seL4 notification mechanism and a shared memory buffer based on the seL4 data port mechanism.

[0104] A software TPM trusted management component is implemented using the CAmkES framework. This component includes a TPM upgrade request interface for upgrading the software TPM component. The interface comprises a notification interface based on the seL4 notification mechanism and a shared memory buffer based on the seL4 data port mechanism. After loading, the component checks for the presence of external storage devices and the trusted upgrade package; if the trusted upgrade package is detected, it automatically performs a trusted upgrade.

[0105] The VMM component is implemented using the CAmkES framework. The VMM component includes a notification interface based on the seL4 notification mechanism, which is used to relay events between the Linux virtual machine and the software TPM component.

[0106] Implement a TPM Proxy component. The TPM Proxy component uses an API to intercept TPM call requests sent by the application to the TSS protocol stack, transparently passes them to the soft TPM component via seL4 IPC, receives the TPM call results from the soft TPM component, and returns them to the application. The TPM Proxy includes a TPM call request interface for obtaining standard TPM services from the soft TPM component. This interface includes a notification interface based on the seL4 notification mechanism and a shared memory buffer based on the seL4 data port mechanism.

[0107] S102. Implement the seL4 microkernel operating system using a Linux virtual machine based on the seL4 system components.

[0108] Step S102 specifically includes the following steps:

[0109] S1021. Install a Linux virtual machine into the VMM component;

[0110] S1022. Configure the Linux virtual machine, install the TSS protocol stack, TPM Proxy component, related kernel modules and trusted applications, and configure the TSS protocol stack and TPM Proxy component to start automatically at boot.

[0111] S1023. Use the CAmkES framework to establish links between the soft TPM component, VMM component and soft TPM trusted management component, and configure the soft TPM trusted management component as the first component to be loaded, and configure the VMM component to be loaded after the soft TPM component has finished loading.

[0112] S1024. Integrate the seL4 system components with the seL4 microkernel into the seL4 microkernel operating system.

[0113] Specifically, first, a Linux virtual machine is installed in the VMM component; then, the Linux virtual machine is configured to install the TSS protocol stack, TPM Proxy, related kernel modules, and trusted applications, and the TSS protocol stack and TPM Proxy are configured to start automatically at boot; then, the CAmkES framework is used to implement the linker between the various seL4 system components in step 101, establishing the link between the soft TPM component and the VMM component, and the soft TPM trusted management component, configuring the soft TPM trusted management component as the first component to be loaded, configuring the VMM component to be loaded after the soft TPM component is loaded, and integrating the seL4 system components and the seL4 microkernel in step S101 into the seL4 microkernel operating system.

[0114] S103, deploying the seL4 microkernel operating system based on embedded systems.

[0115] Step S103 specifically includes the following steps:

[0116] S1031. Create a bootable system image of the seL4 microkernel operating system, and copy the bootable system image and other files required to boot the seL4 microkernel operating system to the preset embedded system.

[0117] S1032. Start the embedded system and boot the seL4 microkernel operating system on the embedded system using the bootable system image and other files;

[0118] S1033. The configuration of the Linux virtual machine is loaded through the software TPM trusted management component, and the existence of external storage devices and trusted upgrade packages is detected.

[0119] S1034. Load the software TPM component through the seL4 microkernel operating system;

[0120] S1035. When the soft TPM component finishes loading, the interface between the soft TPM trusted management component and the soft TPM component is initialized through the soft TPM trusted management component.

[0121] S1036. The configuration of the Linux virtual machine is completed through the VMM component, and the Linux virtual machine is loaded and started, so that the TSS protocol stack and TPM Proxy component are started according to the configuration of the Linux virtual machine.

[0122] S1037. The interface between the TPM Proxy component and the soft TPM component is initialized through the TPM Proxy component. The seL4 microkernel operating system and the embedded system have completed startup.

[0123] Specifically, the configured seL4 microkernel operating system is created as a bootable system image and copied to the embedded system along with other files required to boot the seL4 microkernel operating system. The embedded system is then started, and the seL4 microkernel operating system is booted on the embedded system. The soft TPM trusted management component is loaded according to the configuration in step S1023 and checks for the presence of external storage devices and trusted upgrade packages. Since there are no external storage devices at this time, the seL4 microkernel operating system will continue to start and load the soft TPM component. After the soft TPM component is loaded, the soft TPM trusted management component initializes the interface between itself and the soft TPM component. The VMM component is loaded according to the configuration in step S1023 and starts the Linux virtual machine. During the Linux virtual machine startup process, the TSS protocol stack and TPM Proxy are started according to the configuration in step S1023. The TPM Proxy initializes the interface between itself and the soft TPM component. The seL4 microkernel operating system and the embedded system have finished starting.

[0124] S104. When the embedded system needs to be upgraded, a trusted upgrade is performed through the seL4 microkernel operating system.

[0125] Step S104 specifically includes the following steps:

[0126] S1041. Use a trusted signature tool to sign the update file to generate a trusted upgrade package, and store the trusted upgrade package in an external storage device;

[0127] S1042. Insert the external storage device into the embedded system and restart the embedded system;

[0128] S1043. During the startup process of the seL4 microkernel operating system, the software TPM trusted management component is loaded according to the configuration of the Linux virtual machine, and the existence of external storage devices and trusted upgrade packages is detected.

[0129] S1044. When the soft TPM trusted management component detects a trusted upgrade package, it verifies the signature, integrity, and update version number of the trusted upgrade package.

[0130] S1045. If the verification passes, perform a trusted upgrade using the soft TPM trusted management component.

[0131] S1046. Continue loading seL4 system components through the seL4 microkernel operating system until the system boots up completely, thus achieving a complete trusted system upgrade.

[0132] Specifically, such as Figure 3 and 4 The figures shown are flowcharts and timing diagrams for trusted upgrades of software TPM components and Linux virtual machines provided in embodiments of the present invention. The specific process is as follows:

[0133] The user uses a trusted signature tool to sign the file to be updated, generating a trusted upgrade package, and saves the trusted upgrade package to an external storage device (such as a USB flash drive or SD card); the external storage device is then inserted into the embedded system, and the embedded system is restarted; during the startup process of the seL4 microkernel operating system, the soft TPM trusted management component completes loading according to the configuration in step S1023 and detects the existence of the external storage device and the trusted upgrade package. At this time, the trusted upgrade package exists. After detecting the trusted upgrade package, the component verifies its signature, integrity, and update version number; if the verification passes, the soft TPM trusted management component performs a trusted upgrade; the seL4 microkernel operating system continues to load system components until the system startup is complete, completing a complete system trusted upgrade.

[0134] As an optional implementation, step S1045, which involves performing a trusted upgrade via a soft TPM trusted management component, specifically includes:

[0135] S10451. Initialize the data port between the TPM upgrade request interface and the TPM upgrade interface of the soft TPM component through the soft TPM trusted management component, allocate a shared memory buffer for the data port, and then map the address of the shared memory buffer to the process address space of the soft TPM trusted management component and the soft TPM component.

[0136] S10452. Extract trusted update data from the trusted upgrade package through the soft TPM trusted management component, and write the trusted update data into the shared memory buffer;

[0137] S10453. Send a trusted upgrade request to the TPM upgrade interface through the TPM upgrade request interface;

[0138] S10454. Decrypt the TPM key data using cryptographic primitives through the soft TPM component, and update the decrypted TPM key data by reading trusted update data in the shared memory buffer, and then re-encrypt the updated TPM key data using cryptographic primitives.

[0139] S10455. Check the trusted update data for any content that updates the Linux virtual machine using the software TPM component. If it does, update the files that need to be updated in the Linux virtual machine image and increment the Linux virtual machine image version number after the update is complete.

[0140] S10456. The version number is incremented by the software TPM component to complete the trusted upgrade.

[0141] Specifically, the soft TPM trusted management component uses the seL4SharedData data port linker to initialize the data port between the TPM upgrade request interface and the TPM upgrade interface of the soft TPM component. The seL4 microkernel allocates a shared memory buffer for this data port and maps the shared memory address to the process address space of the soft TPM trusted management component and the soft TPM component. The soft TPM trusted management component extracts trusted update data from the trusted upgrade package and writes the data to the shared memory buffer. The soft TPM trusted management component sends a notification to the notification interface of the TPM upgrade interface of the soft TPM component through the notification interface of the TPM upgrade request interface, informing the soft TPM component that the trusted update data is ready and requesting a trusted upgrade. The software TPM component contains a thread that polls the aforementioned notification interface. Upon receiving the message, the thread decrypts the TPM critical data using cryptographic primitives. Leveraging its ability to manipulate the TPM critical data, it reads trusted update data from the shared memory buffer and updates the decrypted TPM critical data. After the update, it re-encrypts the TPM critical data using cryptographic primitives. The software TPM component checks if the trusted update data contains any content that updates the Linux virtual machine. If so, it updates the files in the Linux virtual machine image that need updating. After the update, it increments the Linux virtual machine image version number. The software TPM component also increments its own version number to avoid duplicate upgrades. After the increment is complete, the upgrade is finished.

[0142] S105. When the embedded system is running normally, it obtains the TPM call request through the Linux virtual machine and returns the TPM call result through the TPMProxy component.

[0143] Step S105 specifically includes the following steps:

[0144] S1051. Send a TPM call request to the TSS protocol stack via a trusted application in a Linux virtual machine based on the standard API.

[0145] S1052. Use the TPM Proxy component to intercept and obtain TPM call requests via API, and use seL4 IPC to transparently pass the TPM call requests to the soft TPM component.

[0146] S1053. The TPM call request is processed by the software TPM component to obtain the TPM call interface, and the TPM call result is returned to the TPM Proxy component in the Linux virtual machine through seL4IPC.

[0147] S1054. The TPM call result is returned to the trusted application through the TPM Proxy, so that the trusted application can obtain the standard TPM service and realize a complete soft TPM call.

[0148] Specifically, a trusted application in a Linux virtual machine sends a TPM call request to the TSS protocol stack via a standard API; the TPM Proxy intercepts the TPM call request using the API and transparently passes it to the software TPM component running locally on seL4 via seL4 IPC; the software TPM component processes the TPM call request and returns the TPM call result to the TPM Proxy in the Linux virtual machine via seL4 IPC; the TPM Proxy returns the TPM call result to the trusted application that made the call, enabling it to obtain standard TPM services, thus completing a full software TPM call.

[0149] like Figure 5 and 6 The diagrams shown are flowcharts and timing diagrams of trusted applications obtaining standard TPM services in a Linux virtual machine according to embodiments of the present invention. Specifically, they are flowcharts and timing diagrams of trusted applications obtaining standard TPM services in a Linux virtual machine during normal operation of an embedded system. In this embodiment of the present invention, the shared memory buffer between the TPM Proxy and the software TPM component has been initialized by the seL4SharedDataWithCaps data port linker and the dataport kernel module. The specific process is as follows.

[0150] 1) Trusted applications running in Linux virtual machines send TPM call requests to the TSS protocol stack via standard APIs;

[0151] 2) The TPM Proxy uses the API to intercept and obtain TPM call requests, stores them in a shared memory buffer with the soft TPM component, and then the TPM Proxy's TPM call request interface calls the emits_event kernel module to send a notification to the soft TPM component, informing the latter to process the TPM call request;

[0152] 3) After the `emits_event` kernel module is invoked, it first sends a hypercall to the VMM component. The VMM component then sends a notification to the TPM call interface of the soft TPM component through its own notification interface. After the notification is sent, the TPM Proxy's TPM call request interface thread polls for the notifications from the soft TPM component.

[0153] 4) After receiving the notification, the soft TPM component retrieves the TPM call request from the shared memory buffer in step 2 and processes it;

[0154] 5) After the soft TPM component completes the processing, it writes the TPM call result into the shared memory buffer of step 2, and sends a notification to the TPM Proxy through its own TPM call interface to inform the latter to retrieve the TPM call result;

[0155] 6) The notification in step 5) is first received by the VMM component. The VMM component injects an interrupt into the Linux virtual machine. The consumes_event kernel module is called to handle the interrupt. The module retrieves the notification and delivers it to the TPM Proxy's TPM call request interface.

[0156] 7) After receiving the notification, the TPM Proxy retrieves the TPM call result from the shared memory buffer in step 2 and returns it to the trusted application that made the call through the standard API, thus completing a standard soft TPM service process.

[0157] The method steps of the embodiments of the present invention have been described above. It can be understood that the embodiments of the present invention build an seL4 microkernel operating system running on an embedded system using the seL4 microkernel and the CAmkES platform. The operating system implements a soft TPM component, a soft TPM trusted management component, a VMM component, and a Linux virtual machine image within the components. The soft TPM component is implemented according to the TPM standard and internally stores encrypted TPM key data, including the endorsement key. Data encryption and decryption are implemented using cryptographic primitives in the soft TPM. The component has two types of interfaces: a TPM call interface for providing standard TPM services to the Linux virtual machine, which only reads the TPM key data; and a TPM upgrade interface for upgrading the soft TPM. Through seL4's capability-based mandatory access control mechanism, only the soft TPM trusted management component is authorized to call the interface, which can read and write the TPM key data. During normal operation, the Linux virtual machine uses seL4... The IPC mechanism invokes the TPM call interface to obtain standard TPM services. When a trusted upgrade is required, the user uses a trusted signature tool to sign the file to be updated, generates a trusted upgrade package, stores it in an external storage device, inserts the external storage device into the system, and restarts. During system startup, the soft TPM trusted management component, as the first component loaded, detects the presence of the external storage device and the trusted upgrade package. After detecting the presence of the trusted upgrade package, the soft TPM trusted management component verifies it. If the verification is successful, it extracts trusted update data from it, calls the soft TPM component to update key TPM data, and upgrades the Linux virtual machine if the trusted update data includes Linux update data. This embodiment of the invention is aimed at the seL4 microkernel operating system. Based on seL4's complete formal verification and capability-based mandatory access control mechanism, it provides soft TPM trusted upgrade services and TPM call services for embedded systems that cannot integrate hardware TPM, thereby improving the trusted computing capabilities of embedded systems.

[0158] Reference Figure 7 This invention provides a trusted platform module invocation system, comprising:

[0159] The component implementation module is used to implement the seL4 system components and TPM Proxy components using the CAmkES framework. The seL4 system components include the soft TPM component, the soft TPM trusted management component, and the VMM component.

[0160] The system implementation module is used to implement the seL4 microkernel operating system through a Linux virtual machine based on the seL4 system components;

[0161] The system deployment module is used to deploy the seL4 microkernel operating system based on embedded systems;

[0162] The trusted upgrade module is used to perform a trusted upgrade through the seL4 microkernel operating system when the embedded system needs to be upgraded.

[0163] The TPM invocation module is used to obtain TPM invocation requests through the Linux virtual machine when the embedded system is running normally, and to return the TPM invocation results through the TPM Proxy component.

[0164] The content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0165] Reference Figure 8 This invention provides a trusted platform module invocation device, comprising:

[0166] At least one processor;

[0167] At least one memory for storing at least one program;

[0168] When the above-mentioned at least one program is executed by the above-mentioned at least one processor, the above-mentioned at least one processor implements the above-mentioned trusted platform module invocation method.

[0169] The content of the above method embodiments is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0170] This invention also provides a computer-readable storage medium storing a processor-executable program that, when executed by a processor, performs the aforementioned trusted platform module invocation method.

[0171] A computer-readable storage medium according to an embodiment of the present invention can execute a trusted platform module invocation method provided in an embodiment of the present invention, and can execute any combination of implementation steps of the method embodiment, and has the corresponding functions and beneficial effects of the method.

[0172] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform... Figure 1 The method shown.

[0173] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the aforementioned blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0174] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the aforementioned functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0175] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0176] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0177] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the aforementioned program can be printed, because the aforementioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or, if necessary, processing in other suitable ways, and then stored in computer memory.

[0178] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0179] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0180] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0181] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for invoking a trusted platform module, characterized in that, Includes the following steps: The seL4 system components and TPM Proxy components are implemented using the CAmkES framework. The seL4 system components include a soft TPM component, a soft TPM trusted management component, and a VMM component. The seL4 system components are implemented using a Linux virtual machine to create the seL4 microkernel operating system. The seL4 microkernel operating system is deployed based on an embedded system. When the embedded system needs to be upgraded, a trusted upgrade is performed through the seL4 microkernel operating system. When the embedded system is running normally, it obtains TPM call requests through the Linux virtual machine and returns TPM call results through the TPM Proxy component; The step of implementing the seL4 system components and TPM Proxy components using the CAmkES framework specifically includes: A soft TPM component is implemented using the CAmkES framework. The soft TPM component is used to encrypt and protect key TPM data. The soft TPM component has a TPM call interface and a TPM upgrade interface. The TPM call interface is used to read the key TPM data, and the TPM upgrade interface is used to upgrade the soft TPM component. A software TPM trusted management component is implemented using the CAmkES framework. The software TPM trusted management component has a TPM upgrade request interface, which is used to request the software TPM component to be upgraded. A VMM component is implemented using the CAmkES framework. The VMM component has a relay interface, which is used to relay events between the Linux virtual machine and the software TPM component. A TPM Proxy component is implemented using the CAmkES framework. The TPM Proxy component is used to intercept and obtain the TPM call request sent by the trusted application, and transparently pass the TPM call request to the soft TPM component through seL4 IPC. It is also used to receive the TPM call result of the soft TPM component and return it to the trusted application.

2. The trusted platform module invocation method according to claim 1, characterized in that, The step of implementing the seL4 microkernel operating system through a Linux virtual machine based on the seL4 system components specifically includes: Install the Linux virtual machine into the VMM component; Configure the Linux virtual machine to install the TSS protocol stack, the TPM Proxy component, related kernel modules, and the trusted application, and configure the TSS protocol stack and the TPM Proxy component to start automatically at boot. The CAmkES framework is used to establish links between the soft TPM component, the VMM component, and the soft TPM trusted management component. The soft TPM trusted management component is configured as the first component to be loaded, and the VMM component is configured to be loaded after the soft TPM component has been loaded. The seL4 system components are integrated with the seL4 microkernel to form the seL4 microkernel operating system.

3. The trusted platform module invocation method according to claim 2, characterized in that, The step of deploying the seL4 microkernel operating system based on the embedded system specifically includes: The seL4 microkernel operating system is made into a bootable system image, and the bootable system image and other files required to boot the seL4 microkernel operating system are copied to the preset embedded system; Start the embedded system, and boot the seL4 microkernel operating system on the embedded system using the bootable system image and the other files; The configuration of the Linux virtual machine is loaded through the software TPM trusted management component, and the presence of external storage devices and trusted upgrade packages is detected. The software TPM component is loaded through the seL4 microkernel operating system; Once the soft TPM component has finished loading, the interface between the soft TPM trusted management component and the soft TPM component is initialized through the soft TPM trusted management component. The configuration of the Linux virtual machine is loaded and started through the VMM component, so that the TSS protocol stack and the TPM Proxy component are started according to the configuration of the Linux virtual machine; The interface between the TPM Proxy component and the software TPM component is initialized by the TPM Proxy component, the seL4 microkernel operating system starts up, and the embedded system starts up.

4. The trusted platform module invocation method according to claim 1, characterized in that, The step of performing a trusted upgrade through the seL4 microkernel operating system when the embedded system needs to be upgraded specifically includes: The update file is signed using a trusted signature tool to generate a trusted upgrade package, and the trusted upgrade package is stored in an external storage device. Insert the external storage device into the embedded system and restart the embedded system; During the startup process of the seL4 microkernel operating system, the software TPM trusted management component is loaded according to the configuration of the Linux virtual machine, and the presence of the external storage device and the trusted upgrade package is detected. When the soft TPM trusted management component detects the trusted upgrade package, it verifies the signature, integrity, and update version number of the trusted upgrade package; If the verification passes, a trusted upgrade is performed using the soft TPM trusted management component. The seL4 microkernel operating system continues to load the seL4 system components until the system boots up completely, thus achieving a complete trusted system upgrade.

5. The trusted platform module invocation method according to claim 4, characterized in that, The step of performing trusted upgrades through the soft TPM trusted management component specifically includes: The data port between the TPM upgrade request interface and the TPM upgrade interface of the soft TPM component is initialized by the soft TPM trusted management component, and a shared memory buffer is allocated for the data port. Then, the address of the shared memory buffer is mapped to the process address space of the soft TPM trusted management component and the soft TPM component. The trusted update data is extracted from the trusted upgrade package by the soft TPM trusted management component, and the trusted update data is written into the shared memory buffer; Send a trusted upgrade request to the TPM upgrade interface through the TPM upgrade request interface; The software TPM component uses cryptographic primitives to decrypt the TPM key data, reads the trusted update data in the shared memory buffer to update the decrypted TPM key data, and then uses cryptographic primitives to re-encrypt the updated TPM key data. The software TPM component checks whether there is any content in the trusted update data that updates the Linux virtual machine. If so, the files in the Linux virtual machine image that need to be updated are updated, and the version number of the Linux virtual machine image is incremented after the update is completed. The software TPM component increments its own version number to complete a trusted upgrade.

6. The trusted platform module invocation method according to claim 2, characterized in that, The step of obtaining TPM call requests through the Linux virtual machine and returning TPM call results through the TPM Proxy component when the embedded system is running normally specifically includes: The trusted application in the Linux virtual machine sends the TPM call request to the TSS protocol stack based on the standard API. The TPM Proxy component uses API interception to obtain the TPM call request, and then transparently passes the TPM call request to the soft TPM component via seL4 IPC. The software TPM component processes the TPM call request to obtain the TPM call interface, and returns the TPM call result to the TPM Proxy component in the Linux virtual machine via seL4 IPC; The TPM Proxy returns the TPM call result to the trusted application, enabling the trusted application to obtain standard TPM services and realize a complete software TPM call.

7. A trusted platform module invocation system, characterized in that, include: The component implementation module is used to implement the seL4 system components and TPM Proxy components using the CAmkES framework. The seL4 system components include a soft TPM component, a soft TPM trusted management component, and a VMM component. The system implementation module is used to implement the seL4 microkernel operating system through a Linux virtual machine based on the seL4 system components; The system deployment module is used to deploy the seL4 microkernel operating system based on the embedded system; A trusted upgrade module is used to perform a trusted upgrade through the seL4 microkernel operating system when the embedded system needs to be upgraded. The TPM invocation module is used to obtain TPM invocation requests through the Linux virtual machine and return TPM invocation results through the TPM Proxy component when the embedded system is running normally. The component implementation module is specifically used for: A soft TPM component is implemented using the CAmkES framework. The soft TPM component is used to encrypt and protect key TPM data. The soft TPM component has a TPM call interface and a TPM upgrade interface. The TPM call interface is used to read the key TPM data, and the TPM upgrade interface is used to upgrade the soft TPM component. A software TPM trusted management component is implemented using the CAmkES framework. The software TPM trusted management component has a TPM upgrade request interface, which is used to request the software TPM component to be upgraded. A VMM component is implemented using the CAmkES framework. The VMM component has a relay interface, which is used to relay events between the Linux virtual machine and the software TPM component. A TPM Proxy component is implemented using the CAmkES framework. The TPM Proxy component is used to intercept and obtain the TPM call request sent by the trusted application, and transparently pass the TPM call request to the soft TPM component through seL4 IPC. It is also used to receive the TPM call result of the soft TPM component and return it to the trusted application.

8. A trusted platform module invocation device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements a trusted platform module invocation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to perform a trusted platform module invocation method as described in any one of claims 1 to 6.

Images