Confidential-computing method and system, and device, storage medium and product
Patent Information
- Application Number
- PCT/CN2024/141769
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-03-06
- Filing Date
- 2024-12-24
- Publication Date
- 2025-10-02
AI Technical Summary
Existing confidential computing technologies have untrusted operating system management in resource management and system calls, resulting in weak side-channel attack defense capabilities and the inability to effectively call accelerators.
By setting up a trusted instance in the confidential computing board, using a dedicated confidential computing board to isolate confidential computing power from general computing power, using the master application to call the target function through a trusted connection for confidential computing, and implementing accelerated computing through the onboard accelerator, resource isolation and security are ensured.
It achieves better resource isolation, avoids side-channel attacks, and ensures the security of confidential computing and the effective calling of accelerators.
Smart Images

Figure CN2024141769_02102025_PF_FP_ABST
Abstract
Description
Confidential computing methods, systems, equipment, storage media and products
[0001] Cross-references
[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on March 6, 2024, with application number 202410255740.3 and invention name “Confidential Computing Methods, Systems, Devices, Storage Media and Products”. The entire contents of the application are incorporated by reference into this application. Technical Field
[0003] The present application relates to the field of computer technology, and in particular to a confidential computing method, system, device, storage medium and product. Background Art
[0004] Today's confidential computing technologies mainly include Intel SGX, ARM TrustZone, etc., which can perform general computing and confidential computing simultaneously on a CPU.
[0005] Intel SGX technology uses a new set of instruction set extensions and access control mechanisms to isolate the code and data in the enclave from other privileged or unprivileged applications, ensuring the security of confidential data. However, resource management and system calls are still managed by the untrusted operating system, making SGX technology less capable of defending against side-channel attacks. Furthermore, SGX applications are unable to call accelerators.
[0006] ARM TrustZone introduces a permission control bit within the CPU, dividing the operating environment into the Normal World and the Secure World, and resource access into Normal and Secure. The Normal World runs operating systems such as Linux and Android, while the Secure World runs a smaller TEE kernel. A Monitor Mode is introduced to facilitate context switching between the Normal World and the Secure World. Applications in the Normal World that wish to access Secure World capabilities, such as verifying a user's fingerprint, must call relevant Secure World applications. Because the TEE kernel includes device drivers, the trusted base is not effectively reduced, allowing attackers to exploit these software vulnerabilities to launch attacks. Summary of the Invention
[0007] The main purpose of this application is to provide a confidential computing method, system, device, storage medium and product.
[0008] An embodiment of the present application provides a confidential computing method, which is applied to a confidential computing board, in which at least one trusted instance is provided; the confidential computing method includes: when a target trusted instance receives a confidential computing request, reading a function identifier from the received confidential computing request, wherein the confidential computing request is sent by a master application to the target trusted instance through a trusted connection; obtaining a target function corresponding to the function identifier; and executing the target function to perform confidential computing.
[0009] An embodiment of the present application also proposes a confidential computing device, which includes: a receiving module, which is used to read a function identifier from the received confidential computing request when the target trusted instance receives the confidential computing request, and the confidential computing request is sent to the target trusted instance by the master application through a trusted connection; an acquisition module, which is used to obtain the target function corresponding to the function identifier; and an execution module, which is used to execute the target function to perform confidential computing.
[0010] An embodiment of the present application also proposes a confidential computing device, which includes: a processor, a memory, and a confidential computing program stored in the memory and executable on the processor, wherein the confidential computing program implements the steps of the confidential computing method described above when executed by the processor.
[0011] An embodiment of the present application further provides a computer-readable storage medium, on which a confidential computing program is stored. When the confidential computing program is executed, the steps of the confidential computing method described above are implemented.
[0012] An embodiment of the present application further provides a computer program product, which includes a confidential computing program, and when the confidential computing program is executed, the steps of the confidential computing method described above are implemented. BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG1 is a schematic diagram of the structure of an electronic device in a hardware operating environment according to an embodiment of the present application;
[0014] FIG2 is a flow chart of a first embodiment of the confidential computing method of the present application;
[0015] FIG3 is an architecture diagram of a confidential computing system according to an embodiment of the present application;
[0016] FIG4 is a schematic diagram of resource isolation according to an embodiment of the present application;
[0017] FIG5 is a schematic diagram of an onboard accelerator calling process according to an embodiment of the present application;
[0018] FIG6 is a flow chart of a second embodiment of the confidential computing method of the present application;
[0019] FIG7 is a flowchart of a third embodiment of the confidential computing method of the present application;
[0020] FIG8 is a schematic diagram of a function call flow according to an embodiment of the present application;
[0021] FIG9 is a schematic diagram of a legality verification process according to an embodiment of the present application;
[0022] FIG10 is a schematic diagram of a trusted instance uninstallation process according to an embodiment of the present application;
[0023] FIG11 is a structural block diagram of the first embodiment of the confidential computing device of the present application.
[0024] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION
[0025] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.
[0026] Refer to Figure 1, which is a schematic diagram of the confidential computing device structure of the hardware operating environment involved in the embodiment of the present application.
[0027] As shown in Figure 1, the electronic device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to implement connection and communication between these components. The user interface 1003 may include a display screen (Display) and an input unit such as a keyboard (Keyboard). In one embodiment, the user interface 1003 may also include a standard wired interface and a wireless interface. In one embodiment, the network interface 1004 may include a standard wired interface and a wireless interface (such as a wireless fidelity (WI-FI) interface). The memory 1005 may be a high-speed random access memory (RAM) or a stable non-volatile memory (NVM), such as a disk storage. In one embodiment, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.
[0028] Those skilled in the art will appreciate that the structure shown in FIG1 does not limit the electronic device and may include more or fewer components than shown, or combine certain components, or arrange the components differently.
[0029] As shown in FIG1 , the memory 1005 as a storage medium may include an operating system, a network communication module, a user interface module, and a confidential computing program.
[0030] In the electronic device shown in Figure 1, the network interface 1004 is mainly used for data communication with the network server; the user interface 1003 is mainly used for data interaction with the user; the processor 1001 and the memory 1005 in the electronic device of this application can be set in a confidential computing device, and the electronic device calls the confidential computing program stored in the memory 1005 through the processor 1001, and executes the confidential computing method provided by the embodiment of this application.
[0031] An embodiment of the present application provides a confidential computing method. Referring to FIG. 2 , FIG. 2 is a flow chart of a first embodiment of a confidential computing method of the present application.
[0032] In this embodiment, the confidential computing method is applied to a confidential computing board, which is provided with at least one trusted instance. The confidential computing method includes the following steps:
[0033] Step S10: When the target trusted instance receives the confidential computing request, it reads the function identifier from the received confidential computing request.
[0034] It should be noted that the execution subject of this embodiment can be the confidential computing device, and the confidential computing device can be a confidential computing board, or a terminal device with a confidential computing board installed inside, such as a computer or server equipped with a confidential computing board. This embodiment does not limit this. In this embodiment and the following embodiments, the confidential computing method of this application is described using a confidential computing board as an example.
[0035] It should be noted that the target trusted instance can be a trusted instance configured on a confidential computing board that currently receives a confidential computing request. The confidential computing request is sent by the master application to the target trusted instance via a trusted connection. The function identifier can be the unique identifier of the function that the master application is currently attempting to call.
[0036] For ease of understanding, the following description is provided in conjunction with Figures 3 and 4, but does not limit this solution. Figure 3 is a diagram of the confidential computing system architecture of this embodiment. Figure 4 is a schematic diagram of resource isolation of this embodiment.
[0037] As shown in Figure 3, the confidential computing system includes a master control terminal (Host) and a confidential computing board (RISC-V board, but other similar boards are also possible). Remote users can control the Host through the network.
[0038] This embodiment proposes a heterogeneous structure in which general computing and confidential computing are separated, where the main control end (Host end) is the node for general computing, which can be any of the architectures such as x86, ARM, etc., and confidential computing is executed on the heterogeneous confidential computing board. The Host and the confidential computing board can be connected via a PCIe bus or other functionally similar methods.
[0039] The host runs a regular operating system, such as Linux, on which a load balancer can run.
[0040] The RISC-V board runs Penglai-supported trusted firmware (OpenSBI) in M-mode; an operating system (which can be a tailored Linux or other trusted operating system); a daemon and a trusted instance (enclave); and hardware accelerators such as GPUs and FPGAs can be installed on the board.
[0041] The host application and the enclave each contain a Penglai distributed module. This module exposes a set of interfaces to developers while hiding specific implementation details. The darker portion in Figure 3 represents the trusted base, namely the enclave, OpenSBI, and the Penglai distributed runtime.
[0042] On confidential computing boards, the data and hardware resources of each trusted instance are isolated from each other. As shown in Figure 4, to achieve more effective resource isolation within the same board, a hardware resource grouping mechanism can be introduced. Enclaves can exclusively access all resources within the group, including CPU cores, peripherals, and interrupts. Device configuration space isolation is achieved through PMP, meaning only CPU cores within the same group are allowed to access the DMA and MMIO address spaces. Device data plane isolation can be achieved through IOPMP. Interrupt isolation can be achieved by configuring the PLIC platform interrupt controller to enable and disable specific interrupts. A daemon runs on a separate core and statically configures hardware resources for the enclave through the secure monitor before the enclave is loaded and after it exits. The secure monitor runs at the highest privilege level (firmware code). Since the secure monitor is solely responsible for checking secure resources, its code size is minimal and rigorously verified, ensuring its inherent security.
[0043] Step S20: Obtain the target function corresponding to the function identifier.
[0044] It should be noted that the function identifier is a unique identifier of the function. Based on the function identifier, the target function that the master application currently needs to call can be found. The target function can be a function in the target trusted instance, a function in another trusted instance, or a function in the master application, which is not limited in this embodiment.
[0045] Step S30: Execute the target function to perform confidential computing.
[0046] In actual use, after the target function is determined, the target function can be executed to complete the confidential computing.
[0047] In a specific implementation, in some cases, when a confidential computing function is executed, it is necessary to call an accelerator (such as a GPU, FPGA, or other hardware accelerator), and rely on the accelerator's function to achieve accelerated computing. In order to ensure that the trusted base is reduced and the attack surface is reduced, the trusted instance does not include the accelerator driver. Instead, an onboard accelerator is set on the confidential computing board. The onboard accelerator only communicates with the driver instance. At this time, if the trusted instance needs to call the accelerator when performing confidential computing, the onboard accelerator can be called through the driver instance. Therefore, step S30 described in this embodiment may include: remotely calling the driver instance to access the onboard accelerator; and accelerating the execution of the target function through the onboard accelerator to perform confidential computing.
[0048] It should be noted that a driver instance can communicate with multiple trusted instances at the same time. However, during the communication process, in the driver instance, the data between the trusted instances are isolated from each other and do not affect each other.
[0049] For ease of understanding, the following description will be made with reference to Figure 5 , but this solution is not limited thereto. Figure 5 is a schematic diagram of the onboard accelerator calling process of this embodiment.
[0050] As shown in Figure 5, a board equipped with an onboard accelerator will run a driver enclave. The accelerator only communicates with the driver enclave, which can implement fine-grained allocation of accelerator resources.
[0051] If a user-created enclave needs to use accelerator resources, it must first connect to the driver enclave and indirectly use the onboard accelerator by calling the driver enclave. The driver enclave can accept connections from multiple enclaves simultaneously but must manage data isolation between them. User enclaves using accelerators must additionally trust both the driver enclave and the onboard accelerator. The driver enclave should provide an interface to verify the legitimacy of the accelerator hardware.
[0052] Since the user-side code no longer includes the accelerator driver, even if the driver enclave is compromised, only the data flowing through the accelerator in the user enclave can be accessed; the rest of the enclave remains protected. If the user enclave is compromised, even if the driver enclave implements data isolation, data from other enclaves cannot be read. Accelerator DMA security is an orthogonal issue, for which solutions such as IOPMP exist.
[0053] Generally speaking, the user enclave and the driver enclave are on the same board, and fast communication can be achieved through shared memory. In this case, the confidentiality of the channel (that is, the security of the shared memory area) is guaranteed by the RISC-V PMP mechanism.
[0054] This embodiment performs confidential computing by reading a function identifier from a confidential computing request received by a target trusted instance. The confidential computing request is sent by the master application to the target trusted instance via a trusted connection; obtaining a target function corresponding to the function identifier; and executing the target function. When confidential computing is required, the master application uses a trusted connection to call the corresponding function on the confidential computing board to perform confidential computing. During this process, the dedicated confidential computing board isolates confidential computing power from general computing power, achieving better resource isolation and preventing side-channel attacks.
[0055] Refer to Figure 6, which is a flow chart of a second embodiment of a confidential computing method of the present application.
[0056] Based on the first embodiment described above, step S30 of the confidential computing method of this embodiment includes:
[0057] Step S301: Determine the function call type.
[0058] Step S302: If the function call type is a local call type, then according to the function identifier, a corresponding target function is searched in a function table corresponding to the target trusted instance.
[0059] It should be noted that when the master application calls a function in the confidential computing board, it may directly call a function in the target trusted instance, call a function in a trusted instance other than the target trusted instance, or call a function in the master terminal. In order to quickly determine the target function, the calling method can be distinguished to determine the function call type. The function call type can be determined based on the interface accessed by the master application when calling the function or by setting additional request parameters, which is not limited in this embodiment.
[0060] In actual use, if the function call type is a local call type, it means that the function in the target trusted instance is being called. Therefore, the corresponding target function can be found in the function table corresponding to the target trusted instance based on the function identifier. The function table corresponding to the target trusted instance can store function information for each function in the target trusted instance.
[0061] In a specific implementation, a remote function may be called. In order to quickly determine the target function, after step S301 in this embodiment, the following steps may be further performed:
[0062] If the function call type is a remote call type, then the target function corresponding to the function identifier is searched in other instances or a main control terminal.
[0063] It should be noted that other instances can be other trusted instances in the confidential computing board except the target trusted instance, and the master terminal can be the terminal running the master application.
[0064] It can be understood that if the function call type is a remote call type, the identifier is calling a function in other trusted instances or calling a function in the main control terminal. At this time, the target function corresponding to the function identifier can be searched in other instances or the main control terminal.
[0065] In actual use, after determining the target function, if the target function is a function in the target trusted instance, the target trusted instance will directly call the target function to perform confidential computing. In the process of executing the target function, the target trusted instance can also remotely call functions of other trusted instances or functions in the master application;
[0066] If the target function is a function in a trusted instance other than the target trusted instance, or a function in the master application, the target trusted instance can execute the target function through remote call to perform confidential computing.
[0067] When searching for a target function, this embodiment first distinguishes the function call type, then determines the target of the function to be searched based on the function call type, and then searches for the target function based on the function identifier, ensuring that the target function can be quickly determined.
[0068] Refer to Figure 7, which is a flow chart of a third embodiment of a confidential computing method of the present application.
[0069] Based on the first embodiment described above, the confidential computing method of this embodiment further includes, before step S10:
[0070] Step S01: after receiving a connection request sent by the master application, a trusted connection is created for the master application and a target trusted instance.
[0071] It should be noted that the connection request may be sent based on the connection parameters of the target trusted instance, where the target trusted instance is the trusted instance to which the master application requests a connection, wherein the connection parameters may include the address and port for accessing the target trusted instance.
[0072] Step S02: Performing legitimacy verification based on the trusted connection.
[0073] It is understandable that after the trusted connection is established, in order to avoid malicious exploitation by malicious attackers, the master application and the target trusted instance can perform mutual legitimacy verification through the trusted connection.
[0074] Step S03: When the legitimacy verification passes, the master control application is allowed to send a confidential computing request through the trusted connection.
[0075] It can be understood that if the legitimacy check passes, it means that the master application and the target trusted instance are not forged by malicious attackers. At this time, the two parties can communicate securely. Therefore, the master application can be allowed to send confidential computing requests through the trusted connection.
[0076] In a specific implementation, in order to ensure security, step S02 described in this embodiment may include: receiving a random number and verification data sent by the master control application through the trusted connection; detecting whether the master control application is trustworthy based on the random number and the verification data; if the master control application is trustworthy, performing local verification on the target trusted instance; feeding back the local verification report to the master control application, so that the master control application performs instance trustworthiness verification based on the local verification report; if it is detected that the instance trustworthiness verification passes, determining that the legitimacy verification passes.
[0077] It should be noted that the master application may include an encryption key, which may be pre-programmed into the master terminal by the chip manufacturer. The target trusted instance also includes a public key or certificate corresponding to the encryption key in the master application. The verification data can be ciphertext data generated by encrypting a random number using the encryption key in the master application, or a signed certificate constructed using the random number and encryption key.
[0078] In actual use, the confidential computing board or target trusted instance can verify the random number and verification data sent by the master application through the trusted connection through the public key or certificate to determine whether the master application is trustworthy. If the master application is trustworthy, the target trusted instance can also be locally verified through the trusted firmware, and then the local verification report is sent back to the master application, so that the master application can perform instance trustworthiness verification based on the local verification report to determine whether the target trusted instance is trustworthy. If the instance trustworthiness verification passes, it can be determined that the overall legitimacy verification passes.
[0079] For ease of understanding, the following description is provided in conjunction with Figures 8 and 9, but this does not limit the present solution. Figure 8 is a schematic diagram of the function call flow of this embodiment. Figure 9 is a schematic diagram of the legitimacy verification flow of this embodiment.
[0080] As shown in Figure 8, the host application must first connect to the enclave before calling it. When the enclave is started, the Penglai distributed runtime automatically creates a socket, and its address and port are sent to the host application at the time of creation. The connection process is as follows:
[0081] The host application initiates a connection request, calling the connection function (Socket / PCI-e) in the Penglai distributed runtime. The Penglai distributed runtime connects to the enclave based on the address and port. At this point, the enclave must call a function similar to the accept function in the socket. Once connected to the enclave, a trusted connection (such as a TLS connection) is automatically established, allowing the host application to securely call functions in the remote enclave. The host application calls the ecall (enclave call) function, and the Penglai distributed runtime sends the request to the enclave via a TLS connection. The Penglai distributed runtime on the enclave searches the function table for the ecall function and executes it. During function execution, it can also call functions in other enclaves or on the host. After the function completes, the return value is transmitted back to the calling method via the Penglai distributed runtime via the TLS connection. The Penglai distributed runtime on the host then receives the remote function data and determines whether it is a request to call a function on the host.
[0082] If the request is to call a host function, the host function table is searched, the host function is executed, and the result is sent over the TLS connection. If it is a return value, it is used as the return value of the ecall function. The above process allows remote functions to be included in the ecall / ocall processing function.
[0083] The inter-enclave calling mechanism is similar, but the difference is that before connecting, the daemon must be queried for the socket address of the other enclave. Before connecting to another enclave, the target enclave must be verified to ensure that the target enclave is trustworthy.
[0084] As shown in Figure 9, the Penglai distributed TEE has implemented local and remote verification. The local verification report includes the enclave's measurements, a random number nonce, and a digital signature for the report. This digital signature is generated using a key pre-programmed by the chip manufacturer. After receiving the report, the user can verify its legitimacy with the chip manufacturer. Remote verification also requires the enclave to include the user's public key or certificate so that the enclave can verify the user's legitimacy. After the enclave is created, the legitimacy verification process is as follows:
[0085] 1. The user establishes a secure connection with the enclave and sends a nonce.
[0086] 2. The enclave verifies whether the user is trustworthy through certificates or public keys.
[0087] 3. If the user is trusted (i.e., has the private key), call OpenSBI to perform local verification; OpenSBI should only allow verification of itself within the enclave, and not allow verification in an unsecured state or initiating verification of other enclaves within the enclave.
[0088] 4. Send the report back to the user via a secure connection.
[0089] 5. User verifies nonce, enclave measurement, and manufacturer signature.
[0090] In addition to enclave measurements, an attacker needs to obtain the nonce and hardware key to generate a valid verification report. The nonce is user-generated and cannot be obtained directly by the attacker, but they can obtain the nonce by accepting a TLS connection. However, even if they obtain the nonce, they cannot generate a valid report. If they impersonate the user in the user enclave, they cannot pass the enclave's verification of the user and therefore cannot send a valid verification request. They also cannot impersonate the user enclave to OpenSBI because they cannot generate an enclave with the same measurements. They also cannot request verification of the user enclave from OpenSBI outside the user enclave. Finally, they do not have the key in the hardware and cannot generate a report on their own. In summary, even if an attacker has hardware-level privileges (can replace malicious hardware), they cannot forge a remote attestation report for the user. This allows the user to know that their enclave is running on trusted hardware and can then send confidential information to the enclave through confidential computing requests.
[0091] If the user's enclave is connected to another enclave (such as the driver enclave), the user must also verify the connected enclave and wait for the verification process to complete before continuing to execute their own code. Verification between enclaves is no longer achieved through verification reports, but through certificates or public keys to prevent attackers from impersonating the driver enclave through replay attacks. After the user remotely verifies, the enclave's private key and certificate can be sent to the enclave, and the corresponding public key can be made public. The driver enclave should also provide a hardware verification report.
[0092] In a specific implementation, the master control application can create a trusted instance in the confidential computing board according to its own needs. In this case, before step S01 in this embodiment, the following steps may also be included:
[0093] After receiving the instance creation request sent by the master application, the instance binary file corresponding to the instance creation request is obtained; a trusted instance is created according to the instance binary file; when the creation is completed, the connection parameters corresponding to the trusted instance are fed back to the master application.
[0094] It can be understood that if an instance creation request is received from the master application, it means that the master application wants to create a new trusted instance in the confidential computing bound card. At this time, the instance binary file can be extracted from the instance creation request, and then a new trusted instance is created in the confidential computing board based on the instance binary file. In order to ensure that the subsequent master application can normally call the trusted instance it created, after the trusted instance is created, the connection parameters of the trusted instance can be fed back to the master application. When the master application needs to call the trusted instance subsequently, it can establish a connection with the trusted instance through the connection parameters.
[0095] In actual use, in order to ensure successful creation of a trusted instance, the step of creating a trusted instance according to the instance binary file may include:
[0096] A trusted instance is created according to the instance binary file through a daemon program, and a daemon process corresponding to the trusted instance is created.
[0097] It should be noted that the daemon can be a program with the highest control authority set in the confidential computing board. By creating a trusted instance based on the instance binary file through the daemon, the creation failure caused by insufficient authority can be avoided. Afterwards, in order to ensure the security of the trusted instance, a corresponding daemon process can be created for it, and the daemon process can be used to execute the trusted instance.
[0098] In the specific implementation, since the resources in the confidential computing board are actually limited, it is impossible to create trusted instances infinitely. In order to ensure the successful creation of trusted instances, the main control application can first detect whether there are available boards (that is, detect whether there are confidential computing boards with sufficient resources to create trusted instances) before trying to create trusted instances. When there are available boards, the instance creation request is sent to the confidential computing board.
[0099] For ease of understanding, the following description will be made with reference to Figure 10 , but this solution is not limited thereto. Figure 10 is a schematic diagram of the trusted instance uninstallation process of this embodiment.
[0100] It should be noted that trusted instance uninstallation refers to uninstalling the trusted instance that could have been set up in the master terminal and setting it up in the confidential computing board. For example, the master terminal originally has the function of creating a trusted instance, but this function can be used instead of creating a trusted instance in the master terminal. Instead, a trusted instance can be created in the confidential computing board.
[0101] As shown in Figure 10, the trusted instance (enclave) uninstallation process may include:
[0102] 1. The host application sends a create request and calls a function in the Penglai Distributed Module.
[0103] 2. The Penglai distributed runtime queries the load balancer for available boards (i.e., confidential computing boards that can currently create trusted instances).
[0104] 3. The Penglai distributed runtime sends the enclave binary file to the available board.
[0105] 4. The daemon receives the message from the host and creates an enclave locally.
[0106] 5. The daemon creates a daemon process for the enclave, which starts executing the enclave.
[0107] In this embodiment, after the master application connects to the trusted instance, a corresponding trusted connection will be created for it, and then a legitimacy verification will be performed based on the trusted connection. Only after the legitimacy verification is passed will the master application be allowed to send confidential computing requests through the trusted connection, thereby ensuring the security of confidential computing.
[0108] In addition, an embodiment of the present application also proposes a storage medium, on which a confidential computing program is stored. When the confidential computing program is executed by a processor, the steps of the confidential computing method described above are implemented.
[0109] In addition, an embodiment of the present application also proposes a computer program product, which includes a confidential computing program, and when the confidential computing program is executed, it implements the steps of the confidential computing method described above.
[0110] Refer to Figure 11, which is a structural block diagram of the first embodiment of the confidential computing device of the present application.
[0111] As shown in Figure 11, the confidential computing device proposed in the embodiment of the present application includes: a receiving module 10, which is used to read the function identifier from the received confidential computing request after the target trusted instance receives the confidential computing request, and the confidential computing request is sent to the target trusted instance by the master application through a trusted connection; an acquisition module 20, which is used to obtain the target function corresponding to the function identifier; and an execution module 30, which is used to execute the target function to perform confidential computing.
[0112] This embodiment performs confidential computing by reading a function identifier from a confidential computing request received by a target trusted instance. The confidential computing request is sent by the master application to the target trusted instance via a trusted connection; obtaining a target function corresponding to the function identifier; and executing the target function. When confidential computing is required, the master application uses a trusted connection to call the corresponding function on the confidential computing board to perform confidential computing. During this process, the dedicated confidential computing board isolates confidential computing power from general computing power, achieving better resource isolation and preventing side-channel attacks.
[0113] In a possible implementation of the present application, the receiving module 10 is also used to create a trusted connection for the master application and the target trusted instance after receiving a connection request sent by the master application, the connection request being sent based on the connection parameters of the target trusted instance, and the target trusted instance being the trusted instance to which the master application requests a connection; performing legitimacy verification based on the trusted connection; and allowing the master application to send a confidential computing request through the trusted connection when the legitimacy verification passes.
[0114] In a possible implementation of the present application, data and hardware resources between trusted instances are isolated from each other.
[0115] In a possible implementation of the present application, the receiving module 10 is further used to obtain the instance binary file corresponding to the instance creation request after receiving the instance creation request sent by the master application; create a trusted instance based on the instance binary file; and when the creation is completed, feed back the connection parameters corresponding to the trusted instance to the master application.
[0116] In a possible implementation of the present application, the receiving module 10 is further configured to create a trusted instance according to the instance binary file through a daemon program, and to create a daemon process corresponding to the trusted instance, wherein the daemon process is configured to execute the trusted instance.
[0117] In a possible implementation of the present application, the instance creation request is sent by the master control application when it detects that there is an available board.
[0118] In a possible implementation of the present application, the receiving module 10 is also used to receive the random number and verification data sent by the master control application through the trusted connection, where the verification data is ciphertext data generated by encrypting the random number or a signature certificate constructed based on the random number; detect whether the master control application is trustworthy based on the random number and the verification data; if the master control application is trustworthy, perform local verification on the target trusted instance; feed back the local verification report to the master control application, so that the master control application performs instance trustworthiness verification based on the local verification report; if it is detected that the instance trustworthiness verification passes, determine that the legitimacy verification passes.
[0119] In a possible implementation of the present application, the acquisition module 20 is also used to determine the function call type; if the function call type is a local call type, the corresponding target function is searched in the function table corresponding to the target trusted instance according to the function identifier.
[0120] In a possible implementation of the present application, the acquisition module 20 is also used to search for the target function corresponding to the function identifier in other instances or master terminals if the function call type is a remote call type. The other instances are other trusted instances other than the target trusted instance, and the master terminal is the terminal running the master application.
[0121] In one possible implementation of the present application, an onboard accelerator is provided in the confidential computing board, and the onboard accelerator communicates with the driver instance; the execution module 30 is also used to access the onboard accelerator by remotely calling the driver instance; and the target function is accelerated by the onboard accelerator to perform confidential computing.
[0122] In a possible implementation of the present application, the driver instance communicates with multiple trusted instances simultaneously, and data between the trusted instances in the driver instance is isolated from each other.
[0123] It should be understood that the above is only an example and does not constitute any limitation to the technical solution of the present application. In specific applications, technicians in this field can make settings as needed, and the present application does not impose any restrictions on this.
[0124] It should be noted that the workflow described above is merely illustrative and does not limit the scope of protection of this application. In actual applications, technicians in this field can select part or all of it according to actual needs to achieve the purpose of this embodiment scheme, and no restrictions are imposed here.
[0125] In addition, for technical details not fully described in this embodiment, please refer to the confidential computing method provided in any embodiment of this application, and will not be repeated here.
[0126] In addition, it should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or system. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or system comprising the element.
[0127] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.
[0128] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus the necessary general hardware platform, or of course by hardware, but in many cases the former is a better embodiment. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory (ROM) / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.
[0129] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A confidential computing method, wherein: The confidential computing method is applied to a confidential computing board, wherein the confidential computing board is provided with at least one trusted instance; The confidential computing method includes: When the target trusted instance receives the confidential computing request, the function identifier is read from the received confidential computing request, and the confidential computing request is sent by the master application to the target trusted instance through the trusted connection; Obtaining the target function corresponding to the function identifier; Execute the target function to perform confidential computing.
2. The confidential computing method according to claim 1, wherein: After the target trusted instance receives the confidential computing request, before reading the function identifier from the received confidential computing request, the method further includes: Upon receiving a connection request from the master application, creating a trusted connection between the master application and a target trusted instance, wherein the connection request is sent based on connection parameters of the target trusted instance, and the target trusted instance is the trusted instance to which the master application requested a connection; Performing legitimacy verification based on the trusted connection; When the legitimacy verification passes, the master control application is allowed to send confidential computing requests through the trusted connection.
3. The confidential computing method according to claim 2, wherein: The data and hardware resources between each trusted instance are isolated from each other.
4. The confidential computing method according to claim 2, wherein: After receiving the connection request sent by the master application, before creating a trusted connection between the master application and the target trusted instance, the method further includes: Upon receiving the instance creation request sent by the master application, obtaining the instance binary file corresponding to the instance creation request; Creating a trusted instance based on the instance binary file; When the creation is completed, the connection parameters corresponding to the trusted instance are fed back to the main control application.
5. The confidential computing method according to claim 4, wherein: The step of creating a trusted instance according to the instance binary file includes: A trusted instance is created according to the instance binary file through a daemon program, and a daemon process corresponding to the trusted instance is created. The daemon process is used to execute the trusted instance.
6. The confidential computing method according to claim 4, wherein: The instance creation request is sent by the master control application when detecting that there is an available board.
7. The confidential computing method according to claim 2, wherein: The performing of legitimacy verification based on the trusted connection includes: receiving a random number and verification data sent by the master control application through the trusted connection, where the verification data is ciphertext data generated by encrypting the random number or a signature certificate constructed based on the random number; detecting whether the master control application is credible according to the random number and the verification data; If the master application is trustworthy, locally verify the target trusted instance; Feedback the local verification report to the master control application, so that the master control application performs instance credibility verification according to the local verification report; If it is detected that the instance has passed the credibility verification, it is determined that the legitimacy verification has passed.
8. The confidential computing method according to claim 1, wherein: The obtaining of the target function corresponding to the function identifier includes: Determine the function call type; If the function call type is a local call type, the corresponding target function is searched in the function table corresponding to the target trusted instance according to the function identifier.
9. The confidential computing method according to claim 8, wherein: After determining the function call type, the method further includes: If the function call type is a remote call type, the target function corresponding to the function identifier is searched in other instances or master terminals, where the other instances are other trusted instances except the target trusted instance, and the master terminal is the terminal running the master application.
10. The confidential computing method according to claim 1, wherein: The confidential computing board is provided with an onboard accelerator, and the onboard accelerator communicates with the driver instance; The executing the target function to perform confidential computing includes: Accessing the onboard accelerator by remotely calling the driver instance; The target function is accelerated by the onboard accelerator to perform confidential computing.
11. The confidential computing method according to claim 10, wherein: The driver instance communicates with multiple trusted instances simultaneously, and data between the trusted instances in the driver instance are isolated from each other.
12. A confidential computing system, wherein: The confidential computing system includes a main control terminal and a confidential computing board card, and the confidential computing board card executes the confidential computing method according to any one of claims 1 to 11 when running.
13. The confidential computing system of claim 12, wherein: The master control terminal is used to detect whether there is an available board, and when there is an available board, sends an instance creation request to the confidential computing board.
14. A confidential computing device, wherein: The confidential computing device includes: a processor, a memory, and a confidential computing program stored in the memory and executable on the processor. When the confidential computing program is executed by the processor, the steps of the confidential computing method according to any one of claims 1 to 11 are implemented.
15. A computer-readable storage medium, wherein: The computer-readable storage medium stores a confidential computing program, which, when executed, implements the steps of the confidential computing method according to any one of claims 1 to 11.
16. A computer program product, wherein The computer program product includes a confidential computing program, which implements the steps of the confidential computing method according to any one of claims 1 to 11 when executed.