Local key escrow method, device, equipment and medium based on trusted computing

Abstract

Embodiments of the present application provide a local key escrow method, apparatus, device, and medium based on trusted computing. The method includes: upon obtaining an enclave interface definition file in local memory, determining an executable file associated with an untrusted environment and a dynamically linked file associated with a trusted environment; upon loading the dynamically linked file based on the executable file, determining an environment access interface using a container identifier indicated by the trusted environment; upon accessing an enclave container in the trusted environment through the environment access interface, reading a sealed data file in the untrusted environment after encrypting serialized data using a local key; and decrypting and deserializing the sealed data file in the enclave container using the local key to obtain business data for loading into the trusted memory indicated by the enclave container. By using the local key to decrypt and obtain business data in the enclave container, the present application can improve the security of locally stored business data.

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a local key escrow method, apparatus, device, and medium based on trusted computing. Background Art

[0002] In today's network environment, data encryption is commonly used to ensure the security of user data. This involves encrypting the user data of a user (e.g., User H) using an encryption key. Currently, data encryption primarily relies on computer hardware key storage solutions. For example, these hardware-based key storage solutions require the use of an additional encryption machine to store the encryption key. This encryption key, stored in the encryption machine, is then used to encrypt and decrypt user data. This means that the encryption machine must open different ports (e.g., service port, management port, and monitoring port) during normal operation.

[0003] Therefore, when a client uses an external encryption machine to provide encryption and decryption services, it is necessary to open a service port to remotely provide key escrow services for user H corresponding to the client to encrypt and decrypt user data. Since open ports often pose certain security risks, for example, if an unauthorized user illegally accesses the external encryption machine through the open port, they may be able to steal the encryption key stored in the encryption machine for encrypting and decrypting user data to a certain extent, thereby reducing the security of the encryption key and, consequently, the security of the user data. Summary of the Invention

[0004] Embodiments of the present application provide a local key escrow method, apparatus, device, and medium based on trusted computing. By using a local key to decrypt business data in an enclave container, the security of locally stored business data can be improved.

[0005] The present invention provides a local key escrow method based on trusted computing, including:

[0006] Obtaining an enclave interface definition file for environment compilation in a local memory, and determining an executable file associated with an untrusted environment and a dynamic link file associated with a trusted environment based on the enclave interface definition file;

[0007] When loading a dynamic link file based on the executable file, determining an environment access interface associated with the trusted environment through a container identifier indicated by the trusted environment;

[0008] When accessing the trusted environment through the environment access interface, determine to access the enclave container created in the trusted environment, and read the sealed data file obtained by encrypting the serialized data based on the local key in the enclave container from the untrusted environment through the enclave container; the serialized data is obtained by serializing the business data requested by the application client in the enclave container;

[0009] Obtain the local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, deserialize the serialized data to obtain business data for loading into the trusted memory indicated by the enclave container.

[0010] An embodiment of the present application provides a local key escrow device based on trusted computing, including:

[0011] a file compilation module, configured to obtain an enclave interface definition file for environment compilation in a local memory, and determine an executable file associated with the untrusted environment and a dynamic link file associated with the trusted environment based on the enclave interface definition file;

[0012] An interface access module, configured to determine an environment access interface associated with a trusted environment through a container identifier indicated by the trusted environment when loading a dynamic link file based on an executable file;

[0013] The container access module is configured to, when accessing a trusted environment through an environment access interface, determine access to an enclave container created in the trusted environment, and, through the enclave container, read a sealed data file from an untrusted environment obtained by encrypting serialized data using a local key within the enclave container; the serialized data is obtained by serializing the service data requested by the application client in the enclave container;

[0014] The data determination module is used to obtain the local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, and deserialize the serialized data to obtain business data for loading into the trusted memory indicated by the enclave container.

[0015] Among them, the file compilation module includes:

[0016] a file compilation unit, configured to obtain, from local memory, an enclave interface definition file for environment compilation, and compile, based on interface definition data in the enclave interface definition file, to obtain untrusted glue data corresponding to the untrusted environment and trusted glue data corresponding to the trusted environment; the untrusted glue data includes an untrusted header file and an untrusted source file, and the trusted glue data includes a trusted header file and a trusted source file;

[0017] A first compiling unit is configured to obtain, in an untrusted environment, a request receiving file for receiving a user call request, and compile the request receiving file, the untrusted header file, and the untrusted source file to obtain an executable file associated with the untrusted environment;

[0018] The second compiling unit is used to compile the trusted header file and the trusted source file to obtain a dynamic link file associated with the trusted environment.

[0019] The local services indicated by the untrusted environment include key management services; the local services indicated by the trusted environment include trusted storage services;

[0020] The interface access module includes:

[0021] A dynamic link unit, configured to configure a file path of a dynamic link file in a non-trusted environment, and dynamically link the dynamic link file to an executable file based on the file path of the dynamic link file;

[0022] The container creation unit is used to create an enclave container containing a startup token in a trusted environment and obtain a container identifier of the enclave container; the startup token is used to indicate that the key management service and the trusted storage service have completed signature verification;

[0023] The interface determination unit is configured to determine an environment access interface associated with the enclave container based on the container identifier of the enclave container.

[0024] The device further comprises:

[0025] A handle creation module is used to run a service process of the key management service in the untrusted environment when starting the key management service indicated by the untrusted environment, create a resource handle for the file resource descriptor management tool through the main thread of the service process, and monitor events for the file descriptor registered on the resource handle through the event waiting function indicated by the file resource descriptor management tool;

[0026] a socket creation module, configured to create a communication socket on a worker thread of a service process, set an addressing parameter of the communication socket to a target parameter for indicating local process communication in the same device, and generate a service descriptor based on the communication socket carrying the target parameter;

[0027] An address binding module is used to bind a first file path indicated by a service socket file for process communication to a communication socket through an address binding function, and to monitor a connection event of the first file path bound to the address binding function through a monitoring function of the communication socket;

[0028] The first registration module is used to register the service descriptor carrying the non-blocking mode to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread when the service descriptor is set to non-blocking mode through the working thread; the service descriptor belongs to the file descriptor monitored by the resource handle.

[0029] The device further comprises:

[0030] a first calling module configured to, upon receiving a process connection request sent by a client process of an application client, monitor a connection event for pointing to a first file path carried in the process connection request through a resource handle on a main thread, and call a monitoring callback function corresponding to a service descriptor to generate a first callback message; the process connection request is sent by the client process based on a second file path indicated by a local socket file used for process communication;

[0031] A first determining module is configured to obtain, through a working thread, a confirmation reception request instruction in the first callback information, and generate a communication descriptor associated with the client process based on the confirmation reception request instruction;

[0032] The second registration module registers the communication descriptor to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread; the communication descriptor belongs to the file descriptor monitored by the resource handle.

[0033] The communication descriptor is used to indicate that the service process and the client process have successfully established a communication connection relationship;

[0034] The device also includes:

[0035] The second calling module is configured to receive a service call request sent by a client process based on a communication connection relationship, monitor a call event for pointing to the first file path carried in the service call request through a resource handle on a main thread, and call a monitoring callback function corresponding to the communication descriptor to generate a second callback message; the service call request is sent by the client process based on the communication connection relationship;

[0036] A second determining module is configured to obtain a data receiving instruction in the second callback information through a working thread, receive a business data packet carried in the service call request based on the data receiving instruction, and temporarily store the business data packet in a cache indicated by the untrusted environment;

[0037] The service determination module is used to parse and process the business data packet in the cache to obtain the business data requested by the client process, and determine the associated business service associated with the trusted environment based on the business type indicated by the business data.

[0038] The service determination module includes:

[0039] A parsing and processing unit, configured to parse and process the service data packet in the cache based on the communication connection relationship, obtain the service data requested by the client process, and determine the service type indicated by the service data;

[0040] The data encryption unit is configured to, if the service type is a data encryption type, obtain a service logic interface provided by the enclave container through the container identifier, determine a first service logic interface corresponding to the data encryption type in the service logic interface, and use the data encryption service corresponding to the first service logic interface as an associated service service associated with the trusted environment; the key generation service is configured to instruct the enclave container to encrypt the data to be encrypted indicated by the service data using the user key of the application client; the user key is generated based on the data encryption program in the enclave container.

[0041] The service determination module further includes:

[0042] The first copying unit is configured to generate encryption success indication information based on the encrypted business data obtained through the encryption process when the associated business service indicates that the data to be encrypted indicated by the business data has been successfully encrypted in the enclave container, and copy the encryption success indication information to the untrusted environment.

[0043] The service determination module further includes:

[0044] a key generation unit configured to, if the service type is a key generation type, obtain a service logic interface provided by the enclave container through the container identifier, determine a second service logic interface corresponding to the key generation type in the service logic interface, and use the key generation service corresponding to the second service logic interface as an associated service service associated with the trusted environment; the key generation service is configured to instruct the enclave container to generate a user key for encryption processing based on a data encryption program;

[0045] The second copy unit is configured to generate key success indication information corresponding to the user key when the associated business service indicates that the user key is successfully generated in the enclave container, and copy the key success indication information to the untrusted environment.

[0046] The service determination module further includes:

[0047] The result parsing unit is used to return the key success indication information to the client process based on the communication connection relationship when the key success indication information is copied to the non-trusted environment, so that the client process can perform result parsing on the key success indication information.

[0048] The device further comprises:

[0049] The data parsing module is used to parse the business data into a key-value pair consisting of a client identifier and a user key based on the data parsing format corresponding to the trusted memory when loading the business data into the trusted memory indicated by the enclave container; the user key is generated by the data encryption program in the enclave container when the application client requests to call the business logic interface provided by the enclave container; the client identifier is used to identify the identity of the application client in an untrusted environment.

[0050] The device further comprises:

[0051] A serialization processing module, configured to serialize the business data stored in the trusted memory in the enclave container when the key management service indicated by the untrusted environment is closed, to obtain serialized data corresponding to the business data;

[0052] The encryption processing module is used to obtain a local key in the enclave container, encrypt the serialized data using the local key, obtain a sealed data file for copying to the untrusted memory indicated by the untrusted environment, and release the enclave container on the trusted environment.

[0053] In one aspect, an embodiment of the present application provides a computer device, including: a processor and a memory;

[0054] The processor is connected to a memory, wherein the memory is used to store a computer program. When the computer program is executed by the processor, the computer device executes the method provided in the embodiment of the present application.

[0055] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program is suitable for being loaded and executed by a processor so that a computer device having the processor executes the method provided by the embodiment of the present application.

[0056] In one aspect, embodiments of the present application provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in the embodiments of the present application.

[0057] In an embodiment of the present application, a computer device can provide an efficient local service construction framework based on a trusted computing application scenario, and then provide efficient local services to application clients through the constructed local service framework, such as local key escrow services. It is understandable that the embodiment of the present application can obtain an efficient service program associated with the local service framework to be built in the local memory (that is, the enclave interface definition file used for environment compilation can be obtained in the local memory), and then, by compiling the enclave interface definition file, a dynamic link file associated with the trusted environment and an executable file associated with the untrusted environment can be obtained. In this way, when the dynamic link file is loaded through the executable file, the environment access interface provided by the enclave container created in the trusted environment can be directly called based on the container identifier of the enclave container. Then, when the environment access interface is called, the enclave container created in the trusted environment can be accessed, and the enclave container can read the sealed data file from the untrusted environment after serialized data is encrypted based on the local key in the enclave container to initialize the enclave container. It should be understood that the initialization here can copy the sealed data file stored in the non-trusted environment to the enclave container in the trusted environment, and then decrypt and deserialize the sealed data file using the local key derived from the enclave container to obtain the business data requested by the application client in the enclave container. Based on this, when using a local service built on the local terminal to provide efficient local key escrow services for the application client, the business data requested by the application client can be securely and efficiently protected in the enclave container. This business data may include, but is not limited to, the user key generated by the application client. It should be understood that the user key can be used to encrypt other types of business data requested by the application client (i.e., data to be encrypted, for example, data that needs to be sent over the network). It should be understood that by utilizing the enclave container created in the trusted environment, the security of the local key can be effectively ensured, so that when the business data is encrypted and decrypted using the local key derived from the secure and trusted enclave container, the security of the business data stored in the trusted memory can be guaranteed. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0059] Figure 1 This is a schematic diagram of a network architecture provided by an embodiment of the present application;

[0060] Figure 2 This is a schematic diagram of a data communication scenario provided by an embodiment of the present application;

[0061] Figure 3 This is a flow chart of a local key escrow method based on trusted computing provided by an embodiment of the present application;

[0062] Figure 4 This is a schematic diagram of the structure of a local service provided by an embodiment of the present application;

[0063] Figure 5 This is a schematic diagram of a scenario for implementing local services provided by an embodiment of the present application;

[0064] Figure 6a This is a schematic diagram of a scenario for generating a sealed data file provided by an embodiment of the present application;

[0065] Figure 6b This is a schematic diagram of a scenario for reading a sealed data file provided by an embodiment of the present application;

[0066] Figure 7 This is a flow chart of a local key escrow method based on trusted computing provided by an embodiment of the present application;

[0067] Figure 8 This is a flowchart of a local key management system provided by an embodiment of the present application;

[0068] Figure 9 This is a flow chart of implementing client process logic provided by an embodiment of the present application;

[0069] Figure 10 This is a flow chart of an inter-process communication process provided by an embodiment of the present application;

[0070] Figure 11 This is a schematic diagram of a scenario in which multiple clients call a local key management service, provided by an embodiment of the present application;

[0071] Figure 12 This is a structural diagram of a local key escrow device based on trusted computing provided in an embodiment of the present application;

[0072] Figure 13 It is a structural diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0074] For details, see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided by an embodiment of the present application. Figure 1 As shown, the network architecture may include a server 2000 and a user terminal cluster. The user terminal cluster may specifically include one or more user terminals, and the number of user terminals in the user terminal cluster is not limited here. Figure 1 As shown, the multiple user terminals may specifically include user terminal 3000a, user terminal 3000b, user terminal 3000c, ..., user terminal 3000n; user terminal 3000a, user terminal 3000b, user terminal 3000c, ..., user terminal 3000n may respectively be directly or indirectly connected to the server 2000 via wired or wireless communication, so that each user terminal may exchange data with the server 2000 via the network connection.

[0075] Among them, server 2000 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, as well as big data and artificial intelligence platforms.

[0076] Each user terminal in the user terminal cluster may include: smart phones, tablet computers, laptop computers, desktop computers, smart TVs, smart watches, smart speakers, vehicle-mounted devices and other smart terminals with data processing functions. Figure 1 Each user terminal in the user terminal cluster shown can be integrated with an application client. When the application client runs in each user terminal, it can be respectively connected to the above-mentioned Figure 1 Data is exchanged between the servers 2000 shown. The application clients may include: in-vehicle clients, smart home clients, entertainment clients (e.g., game clients), multimedia clients (e.g., video clients), social clients, and information clients (e.g., news clients).

[0077] For ease of understanding, the embodiments of the present application can be Figure 1Select one user terminal from the multiple user terminals shown as the target user terminal. For example, the embodiment of the present application can Figure 1 The user terminal 3000a shown is used as a target user terminal, and the target user terminal may be integrated with a target application (ie, application client) having a data processing function. At this time, the target user terminal may implement data interaction with the server 2000 through the application client.

[0078] It should be understood that Figure 1 Each user terminal in the user terminal cluster shown can be equipped with a local service (the local service here can provide a local key escrow solution). When the local service is started in the target user terminal, the application client in the target user terminal can request to call the local service (i.e., the local service in the target user terminal can provide services to the application client) to achieve data communication between the local service in the target user terminal and the application client. Specifically, data communication between the local service on the target user terminal and the application client can be achieved through inter-process communication.

[0079] It is understandable that if Figure 1 The server 2000 shown can be integrated with the above-mentioned application client and can be equipped with the above-mentioned local service (the local service here can provide a local key escrow solution). When the local service is started in the server 2000, the application client in the server 2000 can request to call the service from the local service (that is, the local service in the server 2000 can provide services to the application client) to realize data communication between the local service in the server 2000 and the application client. Among them, data communication can be realized between the local service on the server 2000 and the application client through inter-process communication. In this way, after data communication is carried out between the local service in the server 2000 and the application client, data interaction can be realized between the application client in the server 2000 (for example, application client C1) and the application client in the above-mentioned target user terminal (for example, application client C2), thereby realizing data interaction between the server 2000 and the target user terminal.

[0080] It can be understood that the local key hosting method based on trusted computing provided in the embodiments of the present application may involve the field of cloud technology. The so-called cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and network within a wide area network or local area network to realize data calculation, storage, processing and sharing.

[0081] Cloud technology is a general term for network technology, information technology, integration technology, management platform technology, and application technology based on the cloud computing business model. It can form a resource pool that can be used on demand with flexibility and convenience. Cloud computing technology will become a key support. Backend services of technical network systems, such as video websites, image websites, and more portals, require extensive computing and storage resources. With the rapid development and application of the internet industry, every item will likely have its own unique identification mark, which will need to be transmitted to backend systems for logical processing. Different levels of data will be processed separately. All kinds of industry data require strong system support to achieve cloud computing.

[0082] It is understandable that the local key escrow method based on trusted computing disclosed in this application can be applied to blockchain systems. Figure 1 The server 2000 shown may be a blockchain node in a blockchain system. Business scenarios within a blockchain system may specifically include: electronic bill scenarios, social scenarios, credit purchase scenarios, loan scenarios, payment scenarios, etc. The specific types of business scenarios will not be listed here. In this case, transaction data within the corresponding business scenarios (e.g., data to be encrypted indicated by business data) may specifically include: electronic bill information within the electronic bill scenario, data interaction information within the social scenario, item order information within the credit purchase scenario, loan data information within the loan scenario, and asset transfer records within the payment scenario. The specific content of the transaction data within the corresponding business scenarios will not be listed here.

[0083] It should be understood that before the target user's application client needs to write business data (i.e., data to be encrypted) carrying personal privacy information into the blockchain, it is necessary to pre-use the local signature service provided by the local key escrow method, that is, the target user's user private key stored in the enclave container can be used to sign the data to be encrypted. For example, in the embodiment of the present application, when the user private key is stored in the enclave container created in the trusted environment, the data to be encrypted that needs to be uploaded to the blockchain can be pre-signed using the local service framework built locally, thereby generating corresponding signature information. The signature information and the data to be encrypted can be encrypted together using the local key derived from the enclave container to obtain encrypted business data. When the application client obtains the encrypted business data, the encrypted business data carrying the signature information can be sent to the packaging node in the blockchain network, so that the packaging node can broadcast the block containing the encrypted business data to the consensus nodes in the blockchain network for block consensus. When these consensus nodes reach block consensus, the packaging node can be allowed to write the aforementioned block containing the encrypted business data into the blockchain. It should be understood that the embodiment of the present application can fundamentally ensure the security and privacy of business data carrying personal privacy information stored on the blockchain by writing the encrypted business data for the target user into the blockchain.

[0084] It should be understood that the trusted computing involved in the embodiments of the present application is a trusted computing platform based on hardware security modules and widely used in computer and communication systems to improve the overall security of the system. Trusted computing technology provides an encrypted trusted execution area in memory (i.e., a secure area provided by a trusted execution environment (TEE)). The CPU (Central Processing Unit) can protect the data and privacy in the trusted execution area from being stolen by malicious code, thereby ensuring the confidentiality and integrity of the data and privacy in the trusted execution area.

[0085] It should be understood that different platforms implement different trusted computing technologies for trusted execution zones. For example, the trusted computing technology used to implement trusted execution zones on the ARM (Acorn RISC Machine) platform is TrustZone, and the trusted computing technology used to implement trusted execution zones on the Intel (i.e., Intel) platform is SGX (Intel Software Guard Extensions). We will not list all trusted computing technologies here. For ease of understanding, the embodiments of this application will be described using SGX as an example of trusted computing technology.

[0086] It should be understood that hardware-based protection offers higher security. Optionally, hardware-based protection can also be achieved by collecting hardware fingerprints to protect data. When the firmware is highly stable, fixed programs can run in the environment to which the firmware belongs. In this way, hardware information (e.g., hard drive serial number, MAC address, etc.) can be bound to the program.

[0087] For further understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of a data communication scenario provided by an embodiment of the present application. Figure 2 The terminal Z shown can be the above Figure 1 For ease of understanding, any user terminal in the user terminal cluster of the corresponding embodiment is described in the embodiment of the present application. Figure 1 User terminal 3000a is shown as an example of terminal Z to illustrate the data interaction between application client C and local services implemented in terminal Z. It should be understood that application client C can be any of multiple application clients on terminal Z, and local services can include a trusted storage service indicated by a trusted environment and a key management service indicated by an untrusted environment. The local memory of terminal Z can include both trusted and untrusted environments. In terminal Z, application client C and the local service providing the key management service both run in an untrusted environment, while another local service providing the trusted storage service runs in the trusted environment corresponding to the enclave container.

[0088] Among them, it is understandable that when Figure 2 When the key management service is activated in Terminal Z, the key management service and trusted storage service are first initialized in Terminal Z, thereby completing the initialization of the local service. Initialization of the key management service and trusted storage service can be understood as determining, based on the enclave interface definition file associated with trusted computing, a dynamic link file associated with the trusted environment and an executable file associated with the untrusted environment. Thus, when the dynamic link file is linked to the executable file, an enclave container can be created in the trusted environment. Furthermore, based on the obtained container identifier of the enclave container, the environment access interface associated with the enclave container is determined, thereby completing the initialization of the key management service on Terminal Z. Therefore, when a sealed data file is copied from the untrusted environment to the trusted environment, the sealed data file can be decrypted and deserialized in the enclave container via the environment access interface to obtain the service data requested by the application client, thereby completing the initialization of the trusted storage service on Terminal Z.

[0089] Among them, the application client here may include Figure 2The application client C shown may also include application client C1, application client C2, ..., application client CN. Therefore, the enclave container can be used to store the service data requested by the above application client C, application client C1, application client C2, ..., application client CN. The number of application clients is not limited here.

[0090] Among them, the enclave container can be used to store key-value pairs consisting of client identifiers and user keys, such as Figure 2 The enclave container shown may include M key-value pairs, where M may be a positive integer. Specifically, the M key-value pairs may include: (client identifier K1, user key V1), ..., (client identifier KM, user key VM), where (client identifier K1, user key V1) may be a key-value pair associated with application client C. The number of key-value pairs associated with application client C is not limited.

[0091] Among them, the initialization of local service can be understood as: when Figure 2 When the key management service is started in the terminal Z shown, a service process associated with the key management service (the service process may also be referred to as a server process) may be run on the terminal Z. A domain socket (the domain socket herein may be a communication socket) for local inter-process communication may be created through the service process. It is understood that when an instance (i.e., a resource handle) of a file resource descriptor management tool (e.g., EPOLL) is created on the service process, the communication socket may be registered with the resource handle, and the resource handle may then be used to efficiently monitor the communication socket, thereby completing the initialization of the local service on the terminal Z.

[0092] It should be understood that when Figure 2 When application client C is started in terminal Z, the client process of application client C can be run on terminal Z. In this way, when application client C needs to request a service from the established local service, it can first create a domain socket (here, the domain socket can be a local socket) for local inter-process communication through the client process. Based on the local socket, a process connection request is sent to the communication socket, thereby establishing a communication connection relationship between the client process and the service process. It should be understood that the client processes of multiple application clients can establish a communication connection relationship with the same service process.

[0093] Furthermore, if Figure 2As shown, the client process can send a service call request to the service process based on the above communication connection relationship. It should be understood that when the service process receives the service call request sent by the client process, it can parse and process the business data packet carried by the service call request, and then obtain the business data requested by the client process. It is understandable that the service process can determine the associated business service requested by the application client C based on the business data requested by the client process, and then obtain the business logic interface provided by the enclave container and call the business logic interface corresponding to the associated business service.

[0094] It can be understood that if the associated business service requested by the application client C is a key generation service, the service process can call the second business logic interface corresponding to the key generation service, and then generate a key-value pair associated with the application client C in the enclave container, for example, (client identifier K(M+1), user key V(M+1)). Based on the key-value pair (client identifier K(M+1), user key V(M+1)), the request result information corresponding to the key success indication information can be generated. Therefore, the service process can obtain the request result information returned by the enclave container, and then return the request result information to the client process based on the communication connection relationship.

[0095] It can be understood that if the associated business service requested by the application client C is a data encryption service, the service process can call the first business logic interface corresponding to the data encryption service, and then obtain the key-value pair associated with the application client C in the enclave container, for example, (client identifier K1, user key V1). Based on the user key V1 in the key-value pair (client identifier K1, user key V1), the data to be encrypted indicated by the business data is encrypted to obtain encrypted business data. Based on the encrypted business data, request result information corresponding to the encryption success indication information can be generated. Therefore, the service process can obtain the request result information returned by the enclave container, and then return the request result information to the client process based on the communication connection relationship.

[0096] It can be understood that if the associated business service requested by the application client C is a data decryption service, the service process can call the third business logic interface corresponding to the data decryption service. It should be understood that the specific process of decrypting the data to be decrypted indicated by the business data in the enclave container can refer to the above description of encrypting the data to be encrypted indicated by the business data, and will not be further described here.

[0097] It should be understood that the associated business services requested by application client C include, but are not limited to, the aforementioned key generation service, data encryption service, data decryption service, and local signature service. The specific types of associated business services are not listed here. It should be understood that after receiving the request result information returned by the local service, application client C can parse the request result information to obtain the request result data.

[0098] Further, see Figure 3 , Figure 3 This is a flow chart of a local key escrow method based on trusted computing provided by an embodiment of the present application. The method can be performed by a user terminal (for example, the above Figure 1 The user terminal 3000a shown in FIG. 3 may also be executed by a server (for example, the above Figure 1 For ease of understanding, this embodiment takes the method executed by the user terminal as an example. It should be understood that the user terminal may include an application client (for example, the above-mentioned Figure 2 Application client C) and local service (eg, Figure 2 The local key escrow method based on trusted computing may include at least the following steps S101 to S104:

[0099] Step S101: Obtain an enclave interface definition file for environment compilation in a local memory, and determine an executable file associated with an untrusted environment and a dynamically linked file associated with a trusted environment based on the enclave interface definition file.

[0100] Specifically, when the key management service is activated in a user terminal, the user terminal can retrieve from local memory an enclave interface definition file used for environment compilation. Based on the interface definition data in the enclave interface definition file, the file can be compiled to obtain untrusted glue data corresponding to the untrusted environment and trusted glue data corresponding to the trusted environment. The untrusted glue data includes an untrusted header file and an untrusted source file, while the trusted glue data includes a trusted header file and a trusted source file. Furthermore, the user terminal can retrieve a request reception file in the untrusted environment for receiving user call requests and compile the request reception file, the untrusted header file, and the untrusted source file to obtain an executable file associated with the untrusted environment. Furthermore, the user terminal can compile the trusted header file and the trusted source file to obtain a dynamically linked file associated with the trusted environment.

[0101] It is understood that the enclave interface definition file (e.g., SGX_KMS.edl) can be implemented using the Enclave Definition Language (EDL). A compilation tool can be used to compile the interface definition data in the enclave interface definition file into trusted glue data (i.e., reference code for the trusted portion) and untrusted glue data (reference code for the untrusted portion). The reference code for the trusted portion and the reference code for the untrusted portion do not have specific logic and primarily handle the secure transfer of parameters between the trusted and untrusted environments. By introducing the reference code for the trusted portion into the trusted environment and the reference code for the untrusted portion into the untrusted environment, data communication between the trusted and untrusted environments can be achieved.

[0102] It should be understood that embodiments of the present application can divide local memory into a trusted environment and an untrusted environment. The local memory indicated by the trusted environment is trusted memory, and the local memory indicated by the untrusted environment is untrusted memory. The trusted and untrusted environments are completely isolated from each other. Parameters are transferred from the trusted environment to the untrusted environment, and vice versa, and memory copies exist. The memory copies here can be understood as deep copies.

[0103] Step S102: When loading the dynamic link file based on the executable file, determine the environment access interface associated with the trusted environment through the container identifier indicated by the trusted environment;

[0104] Specifically, the user terminal can configure the file path of a dynamic link file in an untrusted environment and dynamically link the dynamic link file to an executable file based on the file path of the dynamic link file. Furthermore, the user terminal can create an enclave container in a trusted environment that includes a startup token and obtain the container identifier of the enclave container. The local services indicated by the untrusted environment include a key management service, while the local services indicated by the trusted environment include a trusted storage service. The startup token indicates that the key management service and the trusted storage service have completed signature verification. Furthermore, the user terminal can determine the environment access interface associated with the enclave container using the container identifier of the enclave container.

[0105] Among them, the signature verification between the key management service and the trusted storage service can be used to confirm the mutual access permissions between the key management service and the trusted storage service. In this way, the application client can call the key management service, and then call the trusted storage service through the key management service to realize the application client's call to the trusted storage service.

[0106] It is understood that both executable files and dynamically linked files are ELF (Executable Linkable Format) files. When the dynamically linked file and the executable file are in the same file directory, the executable file can directly load the dynamically linked file. When the dynamically linked file and the executable file are in different file directories, the executable file can load the dynamically linked file using the file path of the dynamically linked file. The embodiments of the present application do not limit the file paths of the dynamically linked file and the executable file.

[0107] It is understood that the local service in the embodiments of the present application can be understood as a security management service. This security management service can jointly create and manage (e.g., store) the keys of users (e.g., user H corresponding to the user terminal) through the key management service and the trusted storage service, protecting the confidentiality, integrity, and availability of the keys to meet the key management requirements of user H for multiple applications and multiple services. In addition, this security management service can also encrypt and decrypt user data using the above-mentioned keys. The types of services provided by the local service are not listed here one by one.

[0108] It should be understood that the key management service can be understood as a local KMS (LocalKeyManagerServer) service. This local KMS service belongs to the non-trusted area (i.e., the non-trusted memory indicated by the non-trusted environment) and is not used to store keys. It provides a service interface for the application client used by users by encapsulating the functions of the trusted storage service. The trusted storage service (i.e., SGX_KMS) can be understood as the SGX module in trusted computing technology (this SGX module can create enclave containers in a trusted environment). This SGX module belongs to the trusted area (i.e., the trusted memory indicated by the trusted environment) and can be used to store keys, encapsulating basic key-related operations. In this regard, regardless of the CPU privilege level (i.e., privilege) and mode (i.e., mode), data cannot be written to or read from the trusted memory indicated by the trusted environment in the non-trusted environment.

[0109] For easier understanding, see Figure 4 , Figure 4 This is a schematic diagram of the structure of a local service provided by an embodiment of the present application. The local service built by the embodiment of the present application may include Figure 4 The key management service (i.e. LocalKMS) and trusted storage service (i.e. SGX_KMS) shown, Figure 4 The enclave interface definition file shown may be the SGX_KMS.edl file, the key management service is a local service indicated by the untrusted environment, and the trusted storage service is a local service indicated by the trusted environment.

[0110] It can be understood that by compiling the SGX_KMS.edl file, the untrusted glue data corresponding to the key management service and the trusted glue data corresponding to the trusted storage service can be obtained. The untrusted glue data includes the untrusted functions in the interface definition data, and the trusted glue data includes the trusted functions in the interface definition data. Among them, trusted functions and untrusted functions can call each other, and trusted functions can be called by untrusted functions in untrusted environments and executed in trusted environments; untrusted functions can be called by trusted functions in trusted environments and executed in untrusted environments. Through the calling relationship between trusted functions and untrusted functions, it can be achieved Figure 4 The mutual calls between the key management service and the trusted storage service are shown.

[0111] For easier understanding, see Figure 5 , Figure 5 This is a schematic diagram of a scenario for implementing local services provided by an embodiment of the present application. Figure 4 The enclave interface definition file shown may be the SGX_KMS.edl file, the untrusted header file may be the SGX_KMS_u.h file, the untrusted source file may be the SGX_KMS_u.c file, the trusted header file may be the SGX_KMS_t.h file, the trusted source file may be the SGX_KMS_t.c file, the request receiving file may be the KMS.cpp file, and the logic implementation file may be the SGX_KMS.cpp file.

[0112] Among them, the number of requested received files, untrusted header files, untrusted source files, trusted header files, trusted source files and logical implementation files can be one or more, and the number of requested received files, untrusted header files, untrusted source files, trusted header files, trusted source files and logical implementation files is not limited here.

[0113] like Figure 5 As shown, by compiling the SGX_KMS.edl file, untrusted glue data corresponding to the untrusted environment and trusted glue data corresponding to the trusted environment can be obtained. The untrusted glue data can include the SGX_KMS_u.h and SGX_KMS_u.c files, and the trusted glue data can include the SGX_KMS_t.h and SGX_KMS_t.c files. Compiling the SGX_KMS_u.h, SGX_KMS_u.c, and KMS.cpp files in the untrusted environment can generate an executable file, which can be a KMS file. Compiling the SGX_KMS_t.h and SGX_KMS_t.c files in the trusted environment can generate a dynamic link file, which can be the SGX_KMS.so file.

[0114] In this way, when the application client on the local user terminal calls a service provided by the local service (for example, a key generation service), it can load the SGX_KMS.so file through the KMS file to call the interface provided by the trusted environment, and then call the SGX_KMS.cpp file through the SGX_KMS.so file to implement the key generation service requested by the application client in the trusted environment. Among them, the SGX_KMS.so file defines different methods. By loading the SGX_KMS.so file, different methods in the SGX_KMS.so file can be called (that is, different interfaces provided by the trusted environment are called).

[0115] It should be understood that when an enclave container (i.e., an enclave container) is created in a trusted area, different interfaces provided by the enclave container can be called through the container identifier of the enclave container. It should be understood that after the enclave container is created in the trusted area, the initialization interface (i.e., the environment access interface) provided by the enclave container can be called to initialize the enclave container in the trusted environment. The initialization of the enclave container can include the following steps S103 and S104.

[0116] Step S103: When accessing the trusted environment through the environment access interface, determine to access the enclave container created in the trusted environment, and read the sealed data file obtained by encrypting the serialized data based on the local key in the enclave container from the untrusted environment through the enclave container;

[0117] The serialized data is obtained by serializing the business data requested by the application client in the enclave container.

[0118] It should be understood that in order to ensure the security of business data in the enclave container, SGX provides a data sealing mechanism to Figure 5 The logic implementation file shown here persists the business data in the enclave container and saves the persisted business data to the non-feasible environment (i.e., the user environment). It is understood that the persistence of business data ensures that the state of the enclave container and business data are saved when the local service is shut down (i.e., normal shutdown or abnormal shutdown of the key management service in the local service). After the local service is restarted, the state and business data are restored to their previous state.

[0119] SGX technology provides two data sealing methods: one based on enclave identity (MRENCLAVE, secure zone identifier), and the other based on signer identity (MRSIGNER, seal identifier). The MRENCLAVE method generates a local key unique to the enclave (i.e., enclave container), allowing only the same enclave on the same computer to decrypt sealed data files. The MRSIGNER method generates a local key based on the developer's (e.g., Intel) signing key, allowing different enclaves on the same computer to decrypt sealed data files. It should be understood that the data sealing mechanism in the embodiments of this application uses the MRSIGNER method, which can derive a unique local key from the CPU hardware. It should be understood that the embodiments of this application do not limit the data sealing method.

[0120] It should be understood that when local services are shut down in a user terminal, persistence of business data can be triggered. By shutting down the key management service indicated by the untrusted environment, local services can be shut down in the user terminal. Thus, when the key management service indicated by the untrusted environment is shut down, the user terminal can serialize the business data stored in the trusted memory in the enclave container to obtain serialized data corresponding to the business data. Furthermore, the user terminal can obtain the local key in the enclave container, encrypt the serialized data using the local key, and obtain a sealed data file for copying to the untrusted memory indicated by the untrusted environment, and then release the enclave container in the trusted environment.

[0121] It should be understood that when the application client calls the create key interface provided by the enclave container, it can trigger the persistence of business data to protect the integrity of the business data in the enclave container when the local service unexpectedly exits. Thus, when the application client calls the create key interface provided by the enclave container, the user terminal can serialize the business data stored in the trusted memory within the enclave container to obtain serialized data corresponding to the business data. Furthermore, the user terminal can obtain the local key within the enclave container and encrypt the serialized data using the local key to obtain a sealed data file for copying to the non-trusted memory indicated by the non-trusted environment. In this case, there is no need to release the enclave container on the trusted environment.

[0122] It is understandable that the user terminal can store the sealed data file in the local terminal, and the local terminal may include a non-trusted environment of the local memory and a local disk (for example, a solid-state drive and a mechanical hard disk, etc.), so that when the sealed data file is needed, the sealed data file is loaded into the trusted environment of the local memory. Optionally, the user terminal can also store the sealed data file in an external disk (for example, a CD, a USB flash drive, and a mobile hard disk, etc.), so that when the sealed data file is needed, the sealed data file is loaded into the local disk. It should be understood that the embodiment of the present application does not limit the storage location of the sealed data file.

[0123] For easier understanding, see Figure 6a , Figure 6a This is a schematic diagram of a scenario for generating a sealed data file provided by an embodiment of the present application. Figure 6a The local memory 600a shown can be divided into a trusted environment 600b and a non-trusted environment 600c, and an enclave container is created in the trusted environment 600b.

[0124] like Figure 6a As shown, when business data persistence is triggered, the user terminal can obtain the business data 60a requested by the application client in the enclave container of the trusted environment 600b. After serializing the business data 60a requested by the application client, serialized data 60b can be obtained. Serialized data 60b is encrypted using the local key to obtain a sealed data file 60c. This sealed data file 60c can then be written from the trusted environment 600b to the untrusted environment 600c, that is, copied from the trusted memory indicated by the trusted environment 600b to the untrusted memory indicated by the untrusted environment 600c.

[0125] Step S104: Obtain a local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, deserialize the serialized data, and obtain business data for loading into the trusted memory indicated by the enclave container.

[0126] For easier understanding, see Figure 6b , Figure 6b This is a schematic diagram of a scenario for reading a sealed data file provided by an embodiment of the present application. Figure 6b The local memory 600d shown can be divided into a trusted environment 600e and a non-trusted environment 600f, and an enclave container is created in the trusted environment 600e.

[0127] like Figure 6bAs shown, when initialization of the enclave container is triggered, the user terminal can obtain sealed data file 60f in the untrusted environment 600f and read the sealed data file 60f from the untrusted environment 600f into the trusted environment 600e, that is, copying the sealed data file 60f from the untrusted memory indicated by the untrusted environment 600f to the trusted memory indicated by the trusted environment 600e. The sealed data file 60f is decrypted using the local key to obtain serialized data 60e. Furthermore, after deserializing the serialized data 60e, the service data 60d requested by the application client can be obtained.

[0128] It should be understood that when the user terminal loads the service data into the trusted memory indicated by the enclave container, it can parse the service data into a key-value pair consisting of a client identifier and a user key based on the data parsing format corresponding to the trusted memory. The user key is generated by the data encryption program in the enclave container when the application client requests to call the service logic interface provided by the enclave container; the client identifier is used to identify the identity of the application client in an untrusted environment.

[0129] The client identifier can be represented as a KeyID (i.e., key), and the user key can be represented as a Key (i.e., value). This means that business data can be parsed into a memory format of KeyID-Key (i.e., (KeyID, Key)). The client identifier can identify the identity of the application client. The same application client can correspond to multiple client identifiers, and different client identifiers of the same application client correspond to different user keys. When a user key is created in the enclave container, the enclave container can return the client identifier corresponding to the user key to the application client, allowing the application client to save the client identifier associated with it. When requesting a service from a local service, different user keys can be obtained in the enclave container using different client identifiers to implement the corresponding service (e.g., data encryption service).

[0130] In an embodiment of the present application, a computer device can provide an efficient local service construction framework based on a trusted computing application scenario, and then provide efficient local services to application clients through the constructed local service framework, such as local key escrow services. It is understandable that the embodiment of the present application can obtain an efficient service program associated with the local service framework to be built in the local memory (that is, the enclave interface definition file used for environment compilation can be obtained in the local memory), and then, by compiling the enclave interface definition file, a dynamic link file associated with the trusted environment and an executable file associated with the untrusted environment can be obtained. In this way, when the dynamic link file is loaded through the executable file, the environment access interface provided by the enclave container created in the trusted environment can be directly called based on the container identifier of the enclave container. Then, when the environment access interface is called, the enclave container created in the trusted environment can be accessed, and the enclave container can read the sealed data file from the untrusted environment after serialized data is encrypted based on the local key in the enclave container to initialize the enclave container. It should be understood that the initialization here can copy the sealed data file stored in the non-trusted environment to the enclave container in the trusted environment, and then decrypt and deserialize the sealed data file using the local key derived from the enclave container to obtain the business data requested by the application client in the enclave container. Based on this, when using a local service built on the local terminal to provide efficient local key escrow services for the application client, the business data requested by the application client can be securely and efficiently protected in the enclave container. This business data may include, but is not limited to, the user key generated by the application client. It should be understood that the user key can be used to encrypt other types of business data requested by the application client (i.e., data to be encrypted, for example, data that needs to be sent over the network). It should be understood that by utilizing the enclave container created in the trusted environment, the security of the local key can be effectively ensured, so that when the business data is encrypted and decrypted using the local key derived from the secure and trusted enclave container, the security of the business data stored in the trusted memory can be guaranteed.

[0131] Further, see Figure 7 , Figure 7 This is a flow chart of a local key escrow method based on trusted computing provided by an embodiment of the present application. The method can be performed by a user terminal (for example, the above Figure 1 The user terminal 3000a shown in FIG. 3 may also be executed by a server (for example, the above Figure 1For ease of understanding, this embodiment takes the method executed by the user terminal as an example. It should be understood that the user terminal may include an application client (for example, the above-mentioned Figure 2 Application client C) and local service (eg, Figure 2 The local key escrow method based on trusted computing may include the following steps:

[0132] Step S201: Obtain an enclave interface definition file for environment compilation in a local memory, and determine an executable file associated with an untrusted environment and a dynamically linked file associated with a trusted environment based on the enclave interface definition file.

[0133] The specific process of the user terminal determining the executable file and the dynamic link file based on the enclave interface definition file can be found in the above Figure 3 The description of step S101 in the corresponding embodiment will not be repeated here.

[0134] Step S202: When loading the dynamic link file based on the executable file, determine the environment access interface associated with the trusted environment through the container identifier indicated by the trusted environment;

[0135] The specific process of the user terminal determining the environment access interface associated with the trusted environment can be found in the above Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0136] Step S203: When accessing the trusted environment through the environment access interface, determine to access the enclave container created in the trusted environment, and read the sealed data file obtained by encrypting the serialized data using the local key in the enclave container from the untrusted environment through the enclave container;

[0137] The serialized data is obtained by serializing the business data requested by the application client in the enclave container.

[0138] The specific process of the user terminal accessing the enclave container in the trusted environment can be found in the above Figure 3 The description of step S103 in the corresponding embodiment will not be repeated here.

[0139] Step S204: Obtain a local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, deserialize the serialized data to obtain business data for loading into the trusted memory indicated by the enclave container;

[0140] The specific process of the user terminal determining the service data based on the sealed data file can be found in the above Figure 3 The description of step S104 in the corresponding embodiment will not be repeated here.

[0141] For easier understanding, see Figure 8 , Figure 8 This is a flow chart of a local key management system provided by an embodiment of the present application. Figure 8 Step S80 shown can be understood as starting the local key management service on the user terminal. When the local key management service is started on the user terminal, the user terminal can execute Figure 8 The steps S81 to S83 shown in FIG. 1 can be understood as executing the above steps S201 to S204 , and can be understood as initializing the key management service and initializing the trusted storage service. Step S83 includes steps S831 to S833 .

[0142] like Figure 8 As shown, when executing step S81, the user terminal can compile the code of the trusted environment, that is, by compiling the enclave interface definition file, to obtain untrusted glue data corresponding to the untrusted environment and trusted glue data corresponding to the trusted environment. The trusted glue data here is the code of the trusted environment. After compiling the code of the trusted environment, a dynamic link file associated with the trusted environment can be obtained. At the same time, after compiling the code of the untrusted environment (that is, the untrusted glue data), an executable file associated with the untrusted environment can be obtained.

[0143] Furthermore, the user terminal can execute step S82 to load the above-mentioned dynamic link file through the above-mentioned executable file, so as to create an enclave container in the trusted environment using the instructions provided by the CPU, and obtain the container identifier of the enclave container, so as to access the enclave container through the container identifier in subsequent steps, thereby constructing the operating environment of the enclave container. Furthermore, the user terminal can execute step S83 to call the initialization interface of the trusted environment (i.e., the environment access interface) through the container identifier obtained in step S82. The initialization interface can initialize the enclave container created in the trusted environment.

[0144] The process of initializing the enclave container can be: Figure 8In steps S831-S833, when executing step S831, the user terminal can read the local sealed data file. This sealed data file is obtained using the enclave identity (i.e., the enclave identity) and is stored in the untrusted environment. When executing step S832, the user terminal can copy the sealed data file from the untrusted environment to the trusted environment and decrypt the sealed data file in the enclave container based on the local key derived by the CPU. The keys used to decrypt and encrypt the sealed data file are both local keys. When executing step S833, the user terminal can obtain the decrypted sealed data file obtained by the decryption process and then deserialize the decrypted sealed data file to obtain the service data requested by the application client for storage in the enclave container.

[0145] Step S205: When loading the service data into the trusted memory indicated by the enclave container, the service data is parsed into a key-value pair consisting of a client identifier and a user key based on the data parsing format corresponding to the trusted memory;

[0146] Among them, the user key is generated by the data encryption program in the enclave container when the application client requests to call the business logic interface provided by the enclave container; the client identifier is used to identify the identity of the application client in an untrusted environment.

[0147] It should be understood that business data may include the parsed key-value pairs consisting of the client identifier and user key. Business data may also include the privacy data of the application client, data requested to be protected by the application client, etc. The data types of business data will not be listed one by one here.

[0148] Step S206: When the key management service indicated by the untrusted environment is started, a service process of the key management service is run in the untrusted environment, a resource handle for the file resource descriptor management tool is created through the main thread of the service process, and an event wait function indicated by the file resource descriptor management tool is used to monitor events for the file descriptor registered on the resource handle;

[0149] It can be understood that the service process of the key management service (the service process can also be called the server process) can be run in a non-trusted environment, and the client process of the application client can also be run in a non-trusted environment. The service process and the client process can implement IPC (Inter-Process Communication) communication through sockets. When the service process and the client process belong to two processes on the same user terminal, the service process and the client process can implement IPC communication through domain sockets (i.e., Domain Socket).

[0150] Domain sockets are a method for implementing inter-process communication on Unix / Linux systems. Compared to network protocol communication, domain sockets are more efficient. Domain sockets do not require the network protocol stack, and do not require packet unpacking, checksum calculation, sequence number maintenance, or acknowledgment.

[0151] It is understandable that the file resource descriptor management tool can be EPOLL, and the creation function indicated by the resource descriptor management tool EPOLL (i.e., the epoll_create() function) can create an EPOLL instance and return a file descriptor (e.g., FD1) that references the EPOLL instance. The EPOLL instance is the resource handle (e.g., the resource handle can be EFD). The file resource descriptor management tool can also be POLL, SELECT, etc. The embodiment of the present application does not limit the type of file resource descriptor management tool. EPOLL is an improved POLL method that can be used to process large quantities of file descriptors to improve the response efficiency of events.

[0152] When the main thread creates a resource handle through a create function, it can set the maximum number of file descriptors that the resource handle monitors. For example, the maximum number can be 16. It should be understood that in theory, the file resource descriptor management tool EPOLL has no limit on the number of file descriptors that it monitors. This depends on the response performance of the user terminal. The maximum number can be the maximum number of handles (i.e., file descriptors) that the operating system kernel can guarantee to process correctly.

[0153] It is understandable that through the event waiting function (i.e., the epoll_wait() function) indicated by the file resource descriptor management tool EPOLL, the resource handle can be used to monitor events on the file descriptor added to the resource handle. If no event is generated on the file descriptor monitored by the resource handle, the main thread will remain blocked; if an event is generated on the file descriptor monitored by the resource handle, the main thread will be awakened. It should be understood that the resource handle can monitor the registered file descriptors in various ways. For example, the EPOLLIN event indicates that the corresponding file descriptor can be read (including the normal closure of the client socket), and the EPOLLOUT event indicates that the corresponding file descriptor can be written.

[0154] It should be understood that EPOLL has two working modes, which can be: ET (EdgeTriggered) mode and LT (LevelTriggered) mode. ET mode means that when the state changes, ET mode will generate a notification, requiring the service to read all the data until an error occurs; LT mode means that as long as there is data in the cache that has not been processed, LT mode will generate a new notification. Therefore, the difference between edge triggering and level triggering is that as long as the file descriptor meets a certain state, level triggering will issue a notification, while edge triggering will only issue a notification when the state of the file descriptor changes. The embodiment of the present application can adopt the above-mentioned LT mode. It should be understood that the embodiment of the present application does not limit the working mode of EPOLL.

[0155] Step S207: Create a communication socket on the working thread of the service process, set the addressing parameter of the communication socket to a target parameter for indicating local process communication in the same device, and generate a service descriptor based on the communication socket carrying the target parameter;

[0156] It is understood that a communication socket can be created through a socket creation function (i.e., the socket() function). When creating a communication socket on a worker thread, the family parameter (i.e., the addressing parameter) in the socket() function can be set to AF_UNIX (the target parameter). The target parameter indicates that a communication socket for inter-process communication on the same device (the communication socket is a domain socket) is created. It should be understood that using AF_UNIX can create a socket file (i.e., a socket file) on the system. Different processes communicate by reading and writing this socket file. The socket file can be used to inform the client process of the name of the communication socket.

[0157] Step S208: Bind the communication socket to a first file path indicated by the service socket file for process communication through an address binding function, and monitor the connection event of the first file path bound to the address binding function through a monitoring function of the communication socket;

[0158] It can be understood that the socket type file path (i.e., the first file path indicated by the service socket file) can be bound to the communication socket through the address binding function (i.e., the bind() function), and the system can create a service socket file based on the first file path. Therefore, the service process can send and receive data through the communication socket.

[0159] It can be understood that the communication socket can perform a listening operation on the first file path through the listening function (i.e., the listen() function). Since the service descriptor corresponding to the communication socket (e.g., FD2) is set to non-blocking mode (i.e., 0_NONBLOCK mode), the listening operation of the communication socket will not block the working thread.

[0160] Step S209: When the service descriptor is set to non-blocking mode through the worker thread, the service descriptor carrying the non-blocking mode is registered with the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread;

[0161] Among them, the service descriptor belongs to the file descriptor monitored by the resource handle. It is understandable that the service descriptor can be added to the resource handle through the registration function (i.e., epoll_ctl() function) indicated by the file resource descriptor management tool EPOLL to monitor events on the service descriptor through the resource handle.

[0162] It should be understood that the file resource descriptor management tool EPOLL will create a listening queue, which is used to store connections from client processes. Therefore, when calling the epoll_ctl() function, the corresponding file descriptor (for example, service descriptor FD2) can be added to the listening queue, and the service descriptor FD2 and the events to be monitored can be copied from user space to kernel space. The copying process is only performed once.

[0163] For easier understanding, please refer to Figure 8 ,like Figure 8 Steps S84 to S89 shown can be understood as executing the above steps S206 to S209. Steps S84 to S89 can be understood as initializing local services. When executing step S90, the local service environment is set up to receive the service call request sent by the application client in subsequent steps.

[0164] like Figure 8As shown, when executing step S84, a resource handle (i.e., the above-mentioned EFD) of the file resource descriptor management tool can be created on the main thread, and then step S85 is executed, and the listening function corresponding to the resource handle is used to wait for the generation of the event. Here, steps S84 and S85 can correspond to the above-mentioned step S206. Further, when executing step S86, a communication socket can be created on the working thread, and then the communication socket can be bound in step S87, and then the communication socket is listened to in step S88, wherein the parameter type of the communication socket is a local type file. Here, steps S86-S88 can correspond to the above-mentioned steps S207-S208. Further, when executing step S89, the monitored file descriptor (i.e., the service descriptor corresponding to the communication socket) can be set to non-blocking mode, and the file descriptor can be registered in the resource handle of the file resource descriptor management tool. This step S89 can correspond to the above-mentioned step S209.

[0165] Step S210: upon receiving a process connection request sent by a client process of the application client, monitoring a connection event for pointing to the first file path carried in the process connection request through a resource handle on the main thread, and calling a monitoring callback function corresponding to the service descriptor to generate first callback information;

[0166] The process connection request is sent by the client process based on the second file path indicated by the local socket file for process communication. When the process connection request is received, the resource handle on the main thread can monitor the EPOLLIN event.

[0167] Step S211: obtaining a confirmation reception request instruction in the first callback information through a working thread, and generating a communication descriptor associated with the client process based on the confirmation reception request instruction;

[0168] It is understandable that the working thread can call the receiving function (i.e., the accept() function) in the first callback information to obtain the instruction to determine the reception request, thereby establishing a communication connection relationship between the service process and the client process, and generating a service socket associated with the client process (the service socket can also be referred to as a server socket) and a communication descriptor corresponding to the service socket (e.g., FD3). Therefore, the service process can communicate data with the client process through the service socket. Specifically, the service process can communicate data with the local socket of the client process through the service socket. Among them, the service socket can be created by the above-mentioned working thread (e.g., thread A1). Optionally, the service socket can also be created by another working thread (e.g., thread A2) independent of the above-mentioned working thread (e.g., thread A1).

[0169] Optionally, when establishing a process connection relationship between the service process and the client process, the working thread can generate a communication descriptor associated with the client process, and then communicate data with the client process through the communication descriptor. Specifically, the service process can communicate data with the local socket of the client process in parallel through the communication socket, wherein the communication socket uses different communication descriptors to indicate the local socket with which it communicates data.

[0170] Among them, it can be understood that the service process and the client process can communicate data by reading and writing file descriptors. Specifically, the service process can read and write communication descriptors, and the client process can read and write client descriptors (the client descriptor is the file descriptor corresponding to the local socket), and then realize data communication between the service process and the client process through communication descriptors and client descriptors.

[0171] Step S212: registering the communication descriptor to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread;

[0172] The communication descriptor is a file descriptor monitored by the resource handle. It is understandable that the communication descriptor can be added to the resource handle through the registration function (i.e., epoll_ctl() function) indicated by the file resource descriptor management tool EPOLL, so that the communication descriptor can be monitored for events through the resource handle.

[0173] It should be understood that the communication descriptor is used to indicate that a communication connection relationship has been successfully established between the service process and the client process. When a communication connection relationship is successfully established between the service process and the client process, the service process can send (i.e., return) data to the client process based on the communication connection relationship, or receive data sent by the client process. Similarly, the client process can send data to the service process based on the communication connection relationship, or receive data sent (i.e., returned) by the service process.

[0174] Step S213: receiving a service call request sent by the client process based on the communication connection relationship, monitoring a call event for pointing to the first file path carried in the service call request through the resource handle on the main thread, and calling a monitoring callback function corresponding to the communication descriptor to generate second callback information;

[0175] The service call request is sent by the client process based on the communication connection relationship. When the service call request is received, the resource handle on the main thread can monitor the EPOLLIN event.

[0176] It should be understood that the file resource descriptor management tool EPOLL will create a ready queue (i.e., a ready linked list), which is used to store ready file descriptors. When a listening event occurs in the corresponding file descriptor (for example, the communication descriptor FD3), the communication descriptor FD3 can be activated and added to the ready queue. Therefore, you only need to check the ready queue to process the data sent by the client process.

[0177] Step S214: Obtain a data receiving instruction in the second callback information through the working thread, receive the service data packet carried in the service call request based on the data receiving instruction, and temporarily store the service data packet in the cache indicated by the untrusted environment;

[0178] It is understandable that the working thread can call the receiving function (ie, the read() function) in the second callback information to obtain the data receiving instruction, and then receive the service data packet sent by the client process.

[0179] Step S215: Parse the service data packet in the cache to obtain the service data requested by the client process, and determine the associated service service associated with the trusted environment based on the service type indicated by the service data;

[0180] Specifically, the user terminal can parse the service data packet in the cache based on the communication connection relationship to obtain the service data requested by the client process and determine the service type indicated by the service data. Furthermore, if the service type is data encryption, the user terminal can obtain the service logic interface provided by the enclave container using the container identifier, determine the first service logic interface corresponding to the data encryption type within the service logic interface, and use the data encryption service corresponding to the first service logic interface as the associated service service associated with the trusted environment. The key generation service is used to instruct the enclave container to encrypt the data to be encrypted indicated by the service data using the client's user key; the user key is generated based on the data encryption program within the enclave container.

[0181] It is understood that when the associated business service indicates that the encryption processing of the data to be encrypted indicated by the business data has been successfully completed in the enclave container, the user terminal can generate encryption success indication information based on the encrypted business data obtained by the encryption processing, and copy the encryption success indication information to the non-trusted environment. It should be understood that when the encryption success indication information is copied to the non-trusted environment, the service process can return the encryption success indication information to the client process based on the communication connection relationship, so that the client process can interpret the encryption success indication information.

[0182] Optionally, it is understood that when the associated business service indicates that the encryption processing of the data to be encrypted indicated by the business data in the enclave container was unsuccessful, the user terminal can generate encryption failure indication information based on the unsuccessful encryption processing of the data to be encrypted indicated by the business data to obtain encrypted business data, and copy the encryption failure indication information to the non-trusted environment. It should be understood that when the encryption failure indication information is copied to the non-trusted environment, the service process can return the encryption failure indication information to the client process based on the communication connection relationship, so that the client process can interpret the encryption failure indication information.

[0183] Optionally, it is understood that if the service type is a key generation type, the user terminal can obtain the service logic interface provided by the enclave container through the container identifier, determine the second service logic interface corresponding to the key generation type within the service logic interface, and use the key generation service corresponding to the second service logic interface as the associated service service associated with the trusted environment. The key generation service is used to instruct the enclave container to generate a user key for encryption processing based on a data encryption program. Furthermore, when the associated service service indicates that the user key has been successfully generated within the enclave container, the user terminal can generate key success indication information corresponding to the user key and copy the key success indication information to the non-trusted environment. It should be understood that when the key success indication information is copied to the non-trusted environment, the service process can return the key success indication information to the client process based on the communication connection relationship, so that the client process can interpret the key success indication information.

[0184] Optionally, when the associated business service indicates that the user key was not successfully generated in the enclave container, the user terminal may copy the key failure indication information to the untrusted environment based on the key generation failure indication information indicating the unsuccessful generation of the user key. It should be understood that when the key failure indication information is copied to the untrusted environment, the service process may return the key failure indication information to the client process based on the communication connection relationship, so that the client process can interpret the key failure indication information.

[0185] Similarly, it can be understood that if the service type is a data decryption type, the user terminal can obtain the service logic interface provided by the enclave container through the container identifier, determine the third service logic interface corresponding to the data decryption type in the service logic interface, and use the data decryption service corresponding to the third service logic interface as the associated service service associated with the trusted environment. It should be understood that the specific process of the user terminal decrypting the service data process and returning the request result information (e.g., decryption success indication information or decryption failure indication information) to the client process can be referred to the description of the user terminal encrypting the data to be encrypted indicated by the service data and returning the request result information (e.g., encryption success indication information or encryption failure indication information) to the client process, and will not be repeated here.

[0186] It should be understood that the services requested by the application client include, but are not limited to, the aforementioned data encryption service, data decryption service, and key generation service. A comprehensive list of the associated business services requested by the application client is omitted. It should be understood that the aforementioned encryption success indication information, encryption failure indication information, key success indication information, key failure indication information, decryption success indication information, and decryption failure indication information can be collectively referred to as request result information. A comprehensive list of the request result information associated with the associated business services is omitted.

[0187] It is understood that the user key generated in the enclave container based on the data encryption program can be a symmetric user key. In this way, when the application client requests to call the data encryption service, the symmetric user key can be used to encrypt the data to be encrypted indicated by the business data; when the application client requests to call the data decryption service, the symmetric user key can be used to decrypt the data to be decrypted indicated by the business data.

[0188] Optionally, it can be understood that the user key generated in the enclave container based on the data encryption program can be an asymmetric user key. The asymmetric user key can be divided into a user public key and a user private key. The user private key can then be stored in the enclave container and the user public key can be sent to the application client. In this way, the client process can encrypt the service data requested by the application client using the user public key to obtain encrypted service data, and then send the encrypted service data to the service process to decrypt the encrypted service data using the user private key in the enclave container to obtain the service data requested by the application client. In addition, the service data requested by the application client can also be signed using the user private key.

[0189] It is understood that the process of parsing and processing the service data packet can include splicing, protocol-based parsing, etc. When the service data requested by the client process is obtained, the service process can send the service data to the application layer for processing. At this time, the service data requested by the client process can be copied from the non-trusted environment to the trusted environment to perform the above-mentioned data encryption services, key generation services, data decryption services, etc. in the enclave container. After the execution of the above-mentioned associated service services, the request result information can be copied from the trusted environment to the non-trusted environment. The worker thread in the service process can call the send function (i.e., the write() function) to return the request result information corresponding to the associated service to the application client.

[0190] For easier understanding, see Figure 9 , Figure 9 This is a flow chart of a client process logic implementation provided by the embodiment of the present application. Figure 9 As shown, step S901 indicates that when an application client is started in a non-trusted environment, the client process of the application client can be run in the non-trusted environment. When executing step S902, the client process can create a local socket through a socket creation function (i.e., the socket() function), and set the addressing parameter of the local socket to a target parameter for indicating local process communication in the same device, and generate a client descriptor based on the local socket carrying the target parameter.

[0191] like Figure 9 As shown, when executing step S903, the client process can bind the local socket to the second file path indicated by the local socket file for process communication through the address binding function (i.e., the bind() function). When the client process establishes a communication connection relationship with the service process, the service process can distinguish different client processes through the second file path. It should be understood that the client socket in network communication does not need to perform this binding step because the TCP (Transmission Control Protocol) service can distinguish different client processes based on IP addresses and ports, while the domain socket does not have the concept of IP addresses and ports.

[0192] like Figure 9As shown, when executing step S904, the local socket of the client process can specify the first file path bound to the communication socket, and send a process connection request to the service process through the connection function (i.e., the connect() function) to establish a communication connection relationship between the local socket of the client process and the service socket of the service process after the service process creates the service socket. After establishing the communication connection relationship between the client process and the service process, the client process can execute step S905, and send a service call request to the service process through the sending function (i.e., the write() function) based on the communication connection relationship. After the service process performs business processing on the service call request through the service socket, the client process can receive the request result information returned by the service process through the receiving function (i.e., the read() function), and parse the request result information to obtain the request result data after the result parsing, and then execute step S906 to end the service call request of the application client to the local service.

[0193] It is understandable that after the client process establishes a communication connection relationship with the service process, the client process can send service call requests to the service process multiple times without having to re-establish a communication connection relationship with the service process each time a service call request is sent.

[0194] It should be understood that client processes can be executed serially Figure 9 Steps S901 to S906 are shown. Optionally, when the performance requirements for the application client are high, the client process can be executed in parallel or asynchronously. Figure 9 As shown in steps S901 to S906, the embodiment of the present application does not limit the execution order of steps S901 to S906.

[0195] It should be understood that when the local service environment is built in the user terminal, the service process corresponding to the key management service can receive service call requests sent by the application client and provide services to the application client. For ease of understanding, please refer to Figure 10 , Figure 10 This is a flow chart of inter-process communication provided by the embodiment of the present application. Figure 10 As shown, the client process can be the process corresponding to the application client, and the service process can be the process corresponding to the key management service. Among them, the user terminal can implement the IPC communication method between the client process and the service process based on the domain socket and file resource descriptor management tool, and then through Figure 10 Steps S1 to S14 shown implement data communication between the application client on the user terminal and the key management service.

[0196] like Figure 10As shown, the service process can execute step S1 to create a resource handle through the epoll_create() function, and then execute step S2 to create a communication socket through the socket() function, and then execute step S3 to bind the communication socket to the first file path of the service socket file through the bind() function, and then when executing step S4, listen to the communication socket through the listen() function, and register the service descriptor of the communication socket to the resource handle through the epoll_ctl() function in step S5.

[0197] like Figure 10 As shown, when executing step S6, the client process can create a local socket through the socket() function, and then execute step S7, and bind the local socket to the second file path of the local socket file through the bind() function. When the client process executes step S8, a connection request (i.e., a process connection request) can be sent to the service process through the connect() function. In this way, the service process can receive the connection request sent by the client process through the accept() function in step S9, and generate a communication descriptor associated with the client process, and then register the communication descriptor to the resource handle through the epoll_ctl() function in step S10.

[0198] like Figure 10 As shown, after executing step S10, the service process can establish a communication connection relationship with the client process. In this way, the client process can execute step S11 to send data (i.e., a service call request) to the service process through the write() function. The service process can execute step S12 to receive the service call request sent by the client process through the read() function. After parsing the business data packet carried by the service call request, the service called by the client process is called, and then the data (i.e., the request result information) is returned to the client process through the write() function. Therefore, the client process can receive the request result information returned by the service process through the read() function, and then execute step S14 to parse the request result information.

[0199] It can be understood that the service process can include multiple threads, and the multiple threads here can specifically include a main thread and multiple working threads. The service process can jointly execute the above steps through multiple threads. Here, multiple threads can be collectively referred to as service processes, and the threads executing each step are not distinguished here.

[0200] For easier understanding, see Figure 11 , Figure 11 This is a schematic diagram of a scenario in which multiple clients call a local key management service according to an embodiment of the present application. Figure 11 As shown, the local key management service provided by the embodiment of the present application can support simultaneous calls by multiple clients. The multiple clients here can include N application clients, where N can be a positive integer. The N application clients can specifically include: client C1, client C2,..., client CN.

[0201] Based on this, when the aforementioned clients C1, C2, ..., and CN send service invocation requests to the same local service, the service process indicated by the local key management service can establish communication connections with clients C1, C2, ..., and CN, respectively, and create different communication descriptors for client process J1 indicated by client C1, client process J2 indicated by client C2, ..., and client process JN indicated by client CN. For example, the communication descriptor corresponding to client C1 can be F1, ..., and the communication descriptor corresponding to client CN can be FN. Therefore, the service process can receive the service invocation request sent by client process J1 via communication descriptor F1, ..., and receive the service invocation request sent by client process JN via communication descriptor FN.

[0202] Step S216: When the key management service indicated by the untrusted environment is closed, the business data stored in the trusted memory is serialized in the enclave container to obtain serialized data corresponding to the business data;

[0203] Step S217: Obtain the local key in the enclave container, encrypt the serialized data using the local key, obtain a sealed data file for copying to the untrusted memory indicated by the untrusted environment, and release the enclave container on the trusted environment.

[0204] It is understandable that the client process can close the local socket through the close function (ie, the close() function), and the service process can close the communication socket through the close function. It should be understood that the service process can also close the service socket through the close function.

[0205] As can be seen, embodiments of the present application can establish a local service for providing a key escrow solution on a local terminal based on an enclave interface definition file associated with trusted computing. Establishing the local service here primarily includes: compiling a dynamic link file associated with the trusted environment and an executable file associated with the untrusted environment based on the enclave interface definition file; loading the dynamic link file based on the executable file to create an enclave container in the trusted environment; and initializing the enclave container in the trusted environment based on the environment access interface associated with the trusted environment. It should be understood that when initializing the enclave container in the trusted environment, the enclave container can read a sealed data file from the untrusted environment, which is the result of encrypting serialized data using a local key within the enclave container. The sealed data file can then be decrypted and deserialized in the trusted environment using the local key derived from the enclave container. Based on this, when using the local service established on the local terminal (which may include a key management service or data encryption and decryption service provided to the application client), the security of business data (e.g., user keys and data requiring encryption and decryption, etc.) stored in the trusted memory can be improved.

[0206] Further, see Figure 12 , Figure 12 1 is a structural diagram of a local key escrow device based on trusted computing provided by an embodiment of the present application. The local key escrow device 10 based on trusted computing may include: a file compilation module 101, an interface access module 102, a container access module 103, and a data determination module 104. Furthermore, the local key escrow device 10 based on trusted computing may also include: a handle creation module 105, a socket creation module 106, an address binding module 107, a first registration module 108, a first call module 109, a first determination module 110, a second registration module 111, a second call module 112, a second determination module 113, a service determination module 114, a data parsing module 115, a serialization processing module 116, and an encryption processing module 117.

[0207] A file compilation module 101 is configured to obtain an enclave interface definition file for environment compilation from a local memory, and determine executable files associated with an untrusted environment and dynamically linked files associated with a trusted environment based on the enclave interface definition file;

[0208] The file compiling module 101 includes: a file compiling unit 1011, a first compiling unit 1012, and a second compiling unit 1013;

[0209] A file compiling unit 1011 is configured to obtain an enclave interface definition file for environment compilation from a local memory, and compile the file to obtain untrusted glue data corresponding to an untrusted environment and trusted glue data corresponding to a trusted environment based on the interface definition data in the enclave interface definition file; the untrusted glue data includes an untrusted header file and an untrusted source file, and the trusted glue data includes a trusted header file and a trusted source file;

[0210] A first compiling unit 1012 is configured to obtain a request receiving file for receiving a user call request in an untrusted environment, and compile the request receiving file, the untrusted header file, and the untrusted source file to obtain an executable file associated with the untrusted environment;

[0211] The second compiling unit 1013 is configured to compile the trusted header file and the trusted source file to obtain a dynamic link file associated with the trusted environment.

[0212] The specific implementation of the file compilation unit 1011, the first compilation unit 1012 and the second compilation unit 1013 can be found in the above Figure 3 The description of step S101 in the corresponding embodiment will not be repeated here.

[0213] The interface access module 102 is configured to determine an environment access interface associated with a trusted environment through a container identifier indicated by the trusted environment when loading a dynamic link file based on an executable file;

[0214] The local services indicated by the untrusted environment include key management services; the local services indicated by the trusted environment include trusted storage services;

[0215] The interface access module 102 includes: a dynamic link unit 1021, a container creation unit 1022, and an interface determination unit 1023;

[0216] The dynamic link unit 1021 is used to configure a file path of a dynamic link file in a non-trusted environment, and dynamically link the dynamic link file to an executable file based on the file path of the dynamic link file;

[0217] The container creation unit 1022 is configured to create an enclave container containing a startup token in a trusted environment and obtain a container identifier of the enclave container; the startup token is used to indicate that the key management service and the trusted storage service have completed signature verification;

[0218] The interface determination unit 1023 is configured to determine the environment access interface associated with the enclave container based on the container identifier of the enclave container.

[0219] The specific implementation of the dynamic link unit 1021, the container creation unit 1022 and the interface determination unit 1023 can be found in the above Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0220] The container access module 103 is configured to, when accessing a trusted environment through the environment access interface, determine to access an enclave container created in the trusted environment, and read, through the enclave container, a sealed data file obtained by encrypting serialized data using a local key within the enclave container from an untrusted environment; the serialized data is obtained by serializing the service data requested by the application client in the enclave container;

[0221] The data determination module 104 is configured to obtain a local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, and deserialize the serialized data to obtain business data for loading into the trusted memory indicated by the enclave container.

[0222] Optionally, the handle creation module 105 is configured to, when starting the key management service indicated by the untrusted environment, run a service process of the key management service in the untrusted environment, create a resource handle for the file resource descriptor management tool through the main thread of the service process, and monitor events for the file descriptor registered on the resource handle through the event waiting function indicated by the file resource descriptor management tool;

[0223] The socket creation module 106 is configured to create a communication socket on a worker thread of the service process, set an addressing parameter of the communication socket to a target parameter indicating communication between local processes in the same device, and generate a service descriptor based on the communication socket carrying the target parameter;

[0224] An address binding module 107 is configured to bind a first file path indicated by a service socket file for process communication to a communication socket through an address binding function, and to monitor a connection event of the first file path bound to the address binding function through a monitoring function of the communication socket;

[0225] The first registration module 108 is used to register the service descriptor carrying the non-blocking mode to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread when the service descriptor is set to non-blocking mode through the working thread; the service descriptor belongs to the file descriptor monitored by the resource handle.

[0226] Optionally, the first calling module 109 is configured to, upon receiving a process connection request sent by a client process of an application client, monitor a connection event for pointing to the first file path carried in the process connection request through a resource handle on the main thread, and call a monitoring callback function corresponding to the service descriptor to generate first callback information; the process connection request is sent by the client process based on the second file path indicated by the local socket file used for process communication;

[0227] A first determining module 110 is configured to obtain, through a working thread, a confirmation reception request instruction in the first callback information, and generate a communication descriptor associated with the client process based on the confirmation reception request instruction;

[0228] The second registration module 111 registers the communication descriptor to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread; the communication descriptor belongs to the file descriptor monitored by the resource handle.

[0229] The communication descriptor is used to indicate that the service process and the client process have successfully established a communication connection relationship;

[0230] Optionally, the second calling module 112 is configured to receive a service call request sent by the client process based on the communication connection relationship, monitor a call event for pointing to the first file path carried in the service call request through a resource handle on the main thread, and call a monitoring callback function corresponding to the communication descriptor to generate second callback information; the service call request is sent by the client process based on the communication connection relationship;

[0231] The second determining module 113 is configured to obtain a data receiving instruction in the second callback information through a working thread, receive a service data packet carried in the service call request based on the data receiving instruction, and temporarily store the service data packet in a cache indicated by the untrusted environment;

[0232] The service determination module 114 is configured to parse the service data packet in the cache to obtain the service data requested by the client process, and determine the associated service service associated with the trusted environment based on the service type indicated by the service data.

[0233] The service determination module 114 includes: a parsing and processing unit 1141, a data encryption unit 1142; optionally, the service determination module 114 may further include: a first copy unit 1143, a key generation unit 1144, a second copy unit 1145, and a result parsing unit 1146;

[0234] The parsing and processing unit 1141 is used to parse the service data packet in the cache based on the communication connection relationship, obtain the service data requested by the client process, and determine the service type indicated by the service data;

[0235] The data encryption unit 1142 is configured to, if the service type is data encryption, obtain a service logic interface provided by the enclave container through the container identifier, determine a first service logic interface corresponding to the data encryption type in the service logic interface, and use the data encryption service corresponding to the first service logic interface as an associated service service associated with the trusted environment; the key generation service is configured to instruct the enclave container to encrypt the data to be encrypted indicated by the service data using the user key of the application client; the user key is generated based on the data encryption program in the enclave container.

[0236] Optionally, the first copy unit 1143 is configured to generate encryption success indication information based on the encrypted business data obtained through the encryption process when the associated business service indicates that the data to be encrypted indicated by the business data has been successfully encrypted in the enclave container, and copy the encryption success indication information to the untrusted environment.

[0237] Optionally, the key generation unit 1144 is configured to, if the service type is a key generation type, obtain a service logic interface provided by the enclave container through the container identifier, determine a second service logic interface corresponding to the key generation type in the service logic interface, and use the key generation service corresponding to the second service logic interface as an associated service service associated with the trusted environment; the key generation service is used to instruct the enclave container to generate a user key for encryption processing based on a data encryption program;

[0238] The second copy unit 1145 is configured to generate key success indication information corresponding to the user key when the associated business service indicates that the user key is successfully generated in the enclave container, and copy the key success indication information to the untrusted environment.

[0239] Optionally, the result parsing unit 1146 is configured to return the key success indication information to the client process based on the communication connection relationship when the key success indication information is copied to the non-trusted environment, so that the client process performs result parsing on the key success indication information.

[0240] The specific implementation of the parsing unit 1141, the data encryption unit 1142, the first copy unit 1143, the key generation unit 1144, the second copy unit 1145 and the result parsing unit 1146 can be found in the above Figure 7 The description of step S215 in the corresponding embodiment will not be repeated here.

[0241] Optionally, the data parsing module 115 is configured to parse the business data into a key-value pair consisting of a client identifier and a user key based on the data parsing format corresponding to the trusted memory when loading the business data into the trusted memory indicated by the enclave container; the user key is generated by the data encryption program in the enclave container when the application client requests to call the business logic interface provided by the enclave container; the client identifier is used to identify the identity of the application client in a non-trusted environment.

[0242] Optionally, a serialization processing module 116 is configured to serialize the business data stored in the trusted memory in the enclave container when the key management service indicated by the untrusted environment is disabled, to obtain serialized data corresponding to the business data;

[0243] The encryption processing module 117 is used to obtain a local key in the enclave container, encrypt the serialized data using the local key, obtain a sealed data file for copying to the untrusted memory indicated by the untrusted environment, and release the enclave container on the trusted environment.

[0244] The specific implementation of the file compilation module 101, the interface access module 102, the container access module 103 and the data determination module 104 can be found in the above Figure 3 The description of steps S101 to S104 in the corresponding embodiment will not be repeated here. Optionally, the specific implementation of the handle creation module 105, the socket creation module 106, the address binding module 107, the first registration module 108, the first calling module 109, the first determination module 110, the second registration module 111, the second calling module 112, the second determination module 113, the service determination module 114, the data parsing module 115, the serialization processing module 116 and the encryption processing module 117 can be found in the above Figure 7 The description of steps S205 to S217 in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here either.

[0245] Further, see Figure 13 , Figure 13 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present application. Figure 13As shown, the computer device 1000 may include: a processor 1001, a network interface 1004 and a memory 1005. In addition, the above-mentioned computer device 1000 may also include: a user interface 1003, and at least one communication bus 1002. The communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. Optionally, the network interface 1004 may include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk storage. Optionally, the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001. As Figure 13 As shown, the memory 1005 as a computer-readable storage medium may include an operating system, a network communication module, a user interface module, and a device control application.

[0246] In such Figure 13 In the computer device 1000 shown, the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0247] Obtaining an enclave interface definition file for environment compilation in a local memory, and determining an executable file associated with an untrusted environment and a dynamic link file associated with a trusted environment based on the enclave interface definition file;

[0248] When loading a dynamic link file based on the executable file, determining an environment access interface associated with the trusted environment through a container identifier indicated by the trusted environment;

[0249] When accessing the trusted environment through the environment access interface, determine to access the enclave container created in the trusted environment, and read the sealed data file obtained by encrypting the serialized data based on the local key in the enclave container from the untrusted environment through the enclave container; the serialized data is obtained by serializing the business data requested by the application client in the enclave container;

[0250] Obtain the local key in the enclave container, decrypt the sealed data file using the local key to obtain serialized data, deserialize the serialized data to obtain business data for loading into the trusted memory indicated by the enclave container.

[0251] It should be understood that the computer device 1000 described in the embodiment of the present application can execute the above Figure 3 or Figure 7 The description of the local key escrow method based on trusted computing in the corresponding embodiment can also be performed as described above. Figure 12 The description of the local key escrow device 10 based on trusted computing in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of adopting the same method will not be repeated here either.

[0252] In addition, it should be noted that: the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores the computer program executed by the local key escrow device 10 based on trusted computing mentioned above, and the computer program includes program instructions. When the processor executes the program instructions, it can execute the above-mentioned Figure 3 or Figure 7 The description of the local key escrow method based on trusted computing in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer-readable storage medium embodiment involved in this application, please refer to the description of the method embodiment of this application.

[0253] In addition, it should be noted that: the embodiment of the present application also provides a computer program product or computer program, which may include computer instructions, which may be stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor may execute the computer instructions, so that the computer device performs the above Figure 3 or Figure 7 The description of the local key escrow method based on trusted computing in the corresponding embodiment will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here. For technical details not disclosed in the computer program product or computer program embodiments involved in this application, please refer to the description of the method embodiments of this application.

[0254] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing related hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When executed, the program can include the processes in the above-described method embodiments. The storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0255] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A local key escrow method based on trusted computing, characterized in that: The method is performed by a computer device including an application client and a local service, wherein the local memory of the computer device includes an untrusted environment and a trusted environment, the local service includes a key management service and a trusted storage service, the untrusted environment is used to run the application client and the key management service, and the trusted environment is used to run the trusted storage service, and the method includes: When building a local service framework for providing the local service for the application client, obtaining an enclave interface definition file for environment compilation in the local memory, and determining an executable file associated with the key management service in the non-trusted environment and a dynamic link file associated with the trusted storage service in the trusted environment based on the enclave interface definition file; When loading the dynamic link file based on the executable file, creating an enclave container in the trusted environment, and determining an environment access interface associated with the trusted environment through the container identifier of the enclave container; When the trusted environment is accessed through the environment access interface, determining to access an enclave container created in the trusted environment, and reading, through the enclave container, a sealed data file obtained by encrypting serialized data using a local key within the enclave container from the untrusted environment; the serialized data is obtained by serializing the service data requested by the application client in the enclave container when the key management service in the local service is disabled; Obtain the local key in the enclave container, decrypt the sealed data file using the local key to obtain the serialized data, and deserialize the serialized data to obtain the business data for loading into the trusted memory indicated by the enclave container.

2. The method according to claim 1, characterized in that When building a local service framework for providing the local service for the application client, obtaining an enclave interface definition file for environment compilation from the local memory, and determining an executable file associated with the key management service in the non-trusted environment and a dynamic link file associated with the trusted storage service in the trusted environment based on the enclave interface definition file, includes: When building a local service framework for providing the local service for the application client, obtaining an enclave interface definition file for environment compilation in the local memory, and compiling to obtain untrusted glue data corresponding to an untrusted environment and trusted glue data corresponding to a trusted environment based on interface definition data in the enclave interface definition file; the untrusted glue data includes an untrusted header file and an untrusted source file, and the trusted glue data includes a trusted header file and a trusted source file; Obtaining a request receiving file for receiving a user call request in the untrusted environment, and compiling the request receiving file, the untrusted header file, and the untrusted source file to obtain an executable file associated with the key management service in the untrusted environment; The trusted header file and the trusted source file are compiled to obtain a dynamic link file associated with the trusted storage service in the trusted environment.

3. The method according to claim 1, characterized in that The local service indicated by the non-trusted environment includes a key management service; the local service indicated by the trusted environment includes a trusted storage service; The step of creating an enclave container in the trusted environment when loading the dynamic link file based on the executable file, and determining an environment access interface associated with the trusted environment based on the container identifier of the enclave container, includes: Configuring a file path of the dynamic link file in the non-trusted environment, and dynamically linking the dynamic link file to the executable file based on the file path of the dynamic link file; Creating an enclave container containing a startup token in the trusted environment, and obtaining a container identifier of the enclave container; the startup token is used to indicate that the key management service and the trusted storage service have completed signature verification; Determine an environment access interface associated with the enclave container according to the container identifier of the enclave container.

4. The method according to claim 1, wherein The method further comprises: When starting the key management service indicated by the untrusted environment, running a service process of the key management service in the untrusted environment, creating a resource handle for a file resource descriptor management tool through a main thread of the service process, and monitoring events for a file descriptor registered on the resource handle through an event waiting function indicated by the file resource descriptor management tool; Creating a communication socket on a worker thread of the service process, setting an addressing parameter of the communication socket to a target parameter for indicating local process communication in the same device, and generating a service descriptor according to the communication socket carrying the target parameter; Binding a first file path indicated by a service socket file for process communication to the communication socket through an address binding function, and monitoring a connection event of the first file path bound to the address binding function through a monitoring function of the communication socket; When the service descriptor is set to non-blocking mode through the working thread, the service descriptor carrying the non-blocking mode is registered to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread; the service descriptor belongs to the file descriptor monitored by the resource handle.

5. The method according to claim 4, characterized in that The method further comprises: Upon receiving a process connection request sent by the client process of the application client, monitoring the connection event for pointing to the first file path carried in the process connection request through the resource handle on the main thread, and calling the monitoring callback function corresponding to the service descriptor to generate first callback information; the process connection request is sent by the client process based on the second file path indicated by the local socket file used for process communication; Obtaining, by the worker thread, a confirmation reception request instruction in the first callback information, and generating a communication descriptor associated with the client process based on the confirmation reception request instruction; The communication descriptor is registered to the resource handle through the registration function indicated by the file resource descriptor management tool on the main thread; the communication descriptor belongs to the file descriptor monitored by the resource handle.

6. The method according to claim 5, characterized in that The communication descriptor is used to indicate that the service process has successfully established a communication connection relationship with the client process; The method further comprises: Receiving a service call request sent by the client process based on the communication connection relationship, monitoring a call event for pointing to the first file path carried in the service call request through the resource handle on the main thread, and calling a monitoring callback function corresponding to the communication descriptor to generate second callback information; the service call request is sent by the client process based on the communication connection relationship; Obtaining a data receiving instruction in the second callback information through the working thread, receiving a business data packet carried in the service call request based on the data receiving instruction, and temporarily storing the business data packet in a cache indicated by the untrusted environment; The service data packet is parsed in the cache to obtain the service data requested by the client process, and an associated service service associated with the trusted environment is determined based on a service type indicated by the service data.

7. The method according to claim 6, characterized in that The parsing of the service data packet in the cache to obtain the service data requested by the client process, and determining the associated service service associated with the trusted environment based on the service type indicated by the service data, includes: parsing the service data packet in the cache based on the communication connection relationship to obtain the service data requested by the client process, and determining the service type indicated by the service data; If the service type is a data encryption type, a service logic interface provided by the enclave container is obtained through the container identifier, a first service logic interface corresponding to the data encryption type is determined in the service logic interface, and a data encryption service corresponding to the first service logic interface is used as an associated service service associated with the trusted environment; the key generation service is used to instruct the enclave container to encrypt the data to be encrypted indicated by the service data using a user key of the application client; the user key is generated based on a data encryption program in the enclave container.

8. The method according to claim 7, characterized in that The method further comprises: When the associated business service indicates that the data to be encrypted indicated by the business data is successfully encrypted in the enclave container, encryption success indication information is generated based on the encrypted business data obtained by the encryption process, and the encryption success indication information is copied to the untrusted environment.

9. The method according to claim 7, characterized in that The method further comprises: If the service type is a key generation type, obtaining the service logic interface provided by the enclave container through the container identifier, determining a second service logic interface corresponding to the key generation type in the service logic interface, and using the key generation service corresponding to the second service logic interface as an associated service associated with the trusted environment; the key generation service is used to instruct the enclave container to generate the user key for encryption processing based on the data encryption program; When the associated business service indicates that the user key is successfully generated in the enclave container, key success indication information corresponding to the user key is generated, and the key success indication information is copied to the untrusted environment.

10. The method according to claim 9, characterized in that The method further comprises: When the key success indication information is copied to the untrusted environment, the key success indication information is returned to the client process based on the communication connection relationship, so that the client process performs result analysis on the key success indication information.

11. The method according to claim 1, wherein The method further comprises: When loading the business data into the trusted memory indicated by the enclave container, the business data is parsed into a key-value pair consisting of a client identifier and a user key based on the data parsing format corresponding to the trusted memory; the user key is generated by a data encryption program in the enclave container when the application client requests to call the business logic interface provided by the enclave container; the client identifier is used to identify the identity of the application client in the non-trusted environment.

12. The method according to claim 1, characterized in that The method further comprises: When the key management service indicated by the non-trusted environment is disabled, serializing the business data stored in the trusted memory in the enclave container to obtain the serialized data corresponding to the business data; Obtaining the local key in the enclave container, encrypting the serialized data using the local key to obtain the sealed data file for copying to the untrusted memory indicated by the untrusted environment, and releasing the enclave container on the trusted environment.

13. A local key escrow device based on trusted computing, characterized in that: The apparatus is run on a computer device including an application client and a local service, wherein the local memory of the computer device includes an untrusted environment and a trusted environment, the local service includes a key management service and a trusted storage service, the untrusted environment is used to run the application client and the key management service, and the trusted environment is used to run the trusted storage service, and the apparatus includes: a file compilation module, configured to, when building a local service framework for providing the local service for the application client, obtain an enclave interface definition file for environment compilation from the local memory, and determine, based on the enclave interface definition file, an executable file associated with the key management service in the non-trusted environment and a dynamic link file associated with the trusted storage service in the trusted environment; an interface access module, configured to create an enclave container in the trusted environment when loading the dynamic link file based on the executable file, and determine an environment access interface associated with the trusted environment based on a container identifier of the enclave container; a container access module, configured to, when accessing the trusted environment through the environment access interface, determine an enclave container created in the trusted environment, and read, through the enclave container, a sealed data file from the untrusted environment obtained by encrypting serialized data using a local key within the enclave container; the serialized data being obtained by serializing service data requested by an application client in the enclave container when the key management service in the local service is disabled; A data determination module is configured to obtain the local key in the enclave container, decrypt the sealed data file using the local key to obtain the serialized data, and deserialize the serialized data to obtain the business data for loading into the trusted memory indicated by the enclave container.

14. A computer device, characterized in that: include: processor and memory; The processor is connected to a memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method according to any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 12.

Images