Key management method and device, computer readable medium and electronic device

Abstract

The application belongs to the technical field of computers, and particularly relates to a key management method, a key management device, a computer readable medium and an electronic device. The method comprises the following steps: performing decryption processing on a sealed data file in a secure area of a memory to obtain user-hosted key data, the key data comprising a key identifier and a user key associated with the key identifier, and the secure area being a trusted area created in the memory based on trusted computing; in response to a received key management request, traversing the key data to determine whether there is a target key identifier matching the key management request; and generating response data for the key management request according to the traversal result of the key data, and returning the response data to the sender of the key management request. The method can improve the reliability of key management and reduce the cost of key management.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a key management method, a key management device, a computer-readable medium, and an electronic device. Background Technology

[0002] In today's network environment, data encryption is generally used for data transmission and storage to ensure user data security. However, the keys used to encrypt data are also at risk of leakage during transmission and storage. Therefore, how to reliably manage user keys is an urgent problem to be solved. Summary of the Invention

[0003] The purpose of this application is to provide a key management method, key management device, computer-readable medium, and electronic device, which at least to some extent overcomes the technical problem of poor key management reliability in related technologies.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a key management method is provided, the method comprising: decrypting a sealed data file in a secure area of ​​memory to obtain user-managed key data, the key data including a key identifier and a user key associated with the key identifier, the secure area being a trusted region created in memory based on trusted computing; in response to a received key management request, traversing the key data to determine whether there exists a target key identifier that matches the key management request; generating response data for the key management request based on the traversal result of the key data, and returning the response data to the sender of the key management request.

[0006] According to one aspect of the embodiments of this application, a key management apparatus is provided, the apparatus comprising: a key acquisition module configured to decrypt a sealed data file within a secure area in memory to obtain user-managed key data, the key data including a key identifier and a user key associated with the key identifier, the secure area being a trusted region created in memory based on trusted computing; a key matching module configured to, in response to a received key management request, traverse the key data to determine whether there exists a target key identifier that matches the key management request; and a request response module configured to generate response data to the key management request based on the traversal result of the key data, and return the response data to the sender of the key management request.

[0007] In some embodiments of this application, based on the above technical solutions, the key acquisition module includes: a data loading unit configured to load a sealed data file stored in an untrusted area into a secure area in memory; a key decryption unit configured to use a secure area key derived from processor hardware to decrypt the ciphertext data in the sealed data file to obtain plaintext data; and a deserialization unit configured to deserialize the decrypted plaintext data to obtain user-managed key data.

[0008] In some embodiments of this application, based on the above technical solutions, the untrusted area is a local disk or a storage area in memory other than the secure area; the data loading unit includes: a disk reading subunit, configured to read the sealed data file stored in the local disk into the secure area of ​​memory; or, a memory reading subunit, configured to read the sealed data file stored in the other storage area into the secure area of ​​memory.

[0009] In some embodiments of this application, based on the above technical solutions, the key matching module includes: a request encapsulation unit configured to encapsulate the key management request into a request data packet through a client process; a request sending unit configured to send the request data packet to a server process through a local socket, wherein the server process is a local service process providing Key Management Service (KMS); a request parsing unit configured to parse the request data packet through the server process to obtain a request key identifier carried in the request data packet; and a key traversal unit configured to traverse the key data to determine whether there is a target key identifier in the key data that is the same as the request key identifier.

[0010] In some embodiments of this application, based on the above technical solutions, the request data packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, concatenated sequentially; the request parsing unit includes: a decapsulation subunit, configured to decapsulate the request data packet through the server process to obtain the message body in the request data packet; and a body parsing subunit, configured to parse the message body to obtain the request key identifier carried in the message body.

[0011] In some embodiments of this application, based on the above technical solutions, the apparatus further includes: a serialization module configured to serialize the key data stored in the secure area to obtain plaintext data in the form of a byte sequence; an encryption module configured to encrypt the plaintext data using a secure area key derived from the processor hardware to obtain ciphertext data; and a writing module configured to write the ciphertext data into a sealed data file stored in an untrusted area.

[0012] In some embodiments of this application, based on the above technical solutions, the apparatus further includes: a parsing module configured to parse the key management request to obtain the request type carried in the key management request, wherein the request type includes at least one of a key creation request, a key deletion request, a data encryption request, a data decryption request, and a data re-encryption request.

[0013] In some embodiments of this application, based on the above technical solutions, the request type of the key management request is a key creation request; the request response module includes: a first response unit, configured to generate response data indicating key creation failure due to duplicate key identifiers if the traversal result of the key data contains a target key identifier that matches the key management request; and a key creation unit, configured to generate a new key based on a true random number generator if the traversal result of the key data contains no target key identifier that matches the key management request, associate the new key with the target key identifier, insert it into the key data, and generate response data indicating successful key creation.

[0014] In some embodiments of this application, based on the above technical solutions, the request type of the key management request is a key deletion request; the request response module includes: a second response unit configured to generate key deletion success response data if the traversal result of the key data does not contain a target key identifier that matches the key management request; and a key deletion unit configured to remove the target key identifier and the user key associated with the target key identifier from the key data if the traversal result of the key data does contain a target key identifier that matches the key management request, and generate key deletion success response data.

[0015] In some embodiments of this application, based on the above technical solutions, the request type of the key management request is a data encryption request; the request response module includes: a third response unit, configured to generate response data indicating that data encryption fails due to the absence of a key if the traversal result of the key data does not contain a target key identifier matching the key management request; and a data encryption unit, configured to encrypt the plaintext data to be encrypted using a target user key associated with the target key identifier to obtain ciphertext data if the traversal result of the key data does contain a target key identifier matching the key management request, and generate response data carrying the target key identifier and the ciphertext data.

[0016] In some embodiments of this application, based on the above technical solutions, the request type of the key management request is a data decryption request; the request response module includes: a fourth response unit, configured to generate response data indicating that data decryption failed due to the absence of a key if the traversal result of the key data does not contain a target key identifier matching the key management request; and a data decryption unit, configured to use a target user key associated with the target key identifier to decrypt the ciphertext data to be decrypted to obtain plaintext data if the traversal result of the key data does contain a target key identifier matching the key management request, and generate response data carrying the plaintext data.

[0017] In some embodiments of this application, based on the above technical solutions, the request type of the key management request is a data re-encryption request, and the target key identifier includes a first key identifier for data decryption and a second key identifier for data encryption; the request response module includes: a fifth response unit, configured to generate response data indicating that data re-encryption fails due to the absence of a key if the traversal result of the key data does not contain at least one of the first key identifier and the second key identifier; and a data re-encryption unit, configured to decrypt the first ciphertext data using the first key identifier to obtain plaintext data, encrypt the plaintext data using the second key identifier to obtain second ciphertext data, and generate response data carrying the second key identifier and the second ciphertext data if the traversal result of the key data contains both the first key identifier and the second key identifier.

[0018] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the key management method as described in the above technical solutions.

[0019] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform a key management method as described above by executing the executable instructions.

[0020] According to one aspect of the embodiments of this application, a computer program product or computer program is provided, 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 key management method as described in the above technical solutions.

[0021] The technical solution provided in this application embodiment creates a secure zone in memory based on trusted computing to manage user-managed key data. This enables reliable key protection in a local environment without the need for an encryption machine. This application embodiment changes the traditional method of relying on encryption machines, greatly reducing the cost of hardware-based user key protection.

[0022] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 A system architecture block diagram for implementing key management using a traditional cryptographic machine is shown.

[0025] Figure 2 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0026] Figure 3 A schematic diagram of the composition of a local KMS service in one embodiment of this application is shown.

[0027] Figure 4 A flowchart illustrating the steps for implementing KMS local services in one embodiment of this application is shown.

[0028] Figure 5 A flowchart illustrating the steps of a key management method according to one embodiment of this application is shown.

[0029] Figure 6 A flowchart illustrating the steps of responding to a user's key management request in one embodiment of this application is shown.

[0030] Figure 7 The response flow for a key creation request in one embodiment of this application is illustrated.

[0031] Figure 8 The response flow for a key deletion request is shown in one embodiment of this application.

[0032] Figure 9 The response flow for a data encryption request is shown in one embodiment of this application.

[0033] Figure 10The response flow for a data decryption request in one embodiment of this application is shown.

[0034] Figure 11 The following is an example of a response flow to a data re-encryption request in one embodiment of this application.

[0035] Figure 12 A schematic block diagram of the key management device provided in the embodiments of this application is shown.

[0036] Figure 13 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0037] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0038] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0039] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0040] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0041] In the related technologies of this application, key storage schemes include two methods: software-based storage and hardware-based storage. From a security perspective, software environments run in memory, which always carries unavoidable risks. Therefore, both from a national compliance perspective and a user security perspective, hardware-based key protection is generally required.

[0042] Hardware-based key protection commonly employs cryptographic cards or encryption machines. Cryptographic cards and encryption machines operate within a closed environment. To interact with applications, they typically follow the international PKCS#11 standard or use SDF (Software-Defined Functions). Implementing this interaction is relatively complex and requires the development of specific programs. To monitor the encryption machine's performance, in addition to opening external business ports, management and monitoring ports are often also required.

[0043] Figure 1 A system architecture block diagram is shown for implementing key management using a traditional encryption machine. (For example...) Figure 1 As shown, client 110, which requires a key, communicates with encryption machine 130 (HSM) through software development kit 120 (SDK) provided by the encryption machine manufacturer. The key is generated and stored internally in encryption machine 130. When client 110 needs to use the key, it can transmit sensitive information to encryption machine 130 for encryption and decryption via Hypertext Transfer Protocol over Secure Socket Layer (HTTPS), thus ensuring the security of the information.

[0044] While using encryption machines for key management can address security issues in encrypted scenarios to some extent, the following problems still exist:

[0045] (1) High configuration cost and inefficient use of resources. The encryption machine itself is very expensive, and only some large enterprises can afford it.

[0046] (2) High usage cost and long development cycle. Users need to develop programs based on the vendor's SDK, and the vendor's SDK runtime environment also needs to be configured in each client environment.

[0047] (3) The architecture is inflexible and cannot cope with changing needs. There is network transmission between the client and the encryption machine. If a two-way SSL authentication method is used, it will lead to low transmission efficiency; if a plaintext communication method is used, there will be information security problems.

[0048] To address the problems existing in the above-mentioned related technologies, the embodiments of this application utilize the characteristic of the CPU of the user's existing machine to support trusted computing. A program developed based on trusted computing is placed locally on the user's machine. The user no longer needs to use an encryption machine and can achieve key protection function based on the local environment.

[0049] Trusted computing typically relies on computer hardware, such as the CPU, to ensure program security. Early trusted computing technologies included TPM (Trusted Platform Module) and TXT (Trusted Execution Technology), but their reliability and ease of use were inferior to the later-developed SGX (Software Guard Extension). SGX is an extension of the Intel instruction set architecture that provides an encrypted trusted execution region in memory, where the CPU protects data and privacy from malicious code. This application primarily uses SGX as an example to illustrate how to implement a key escrow scheme using SGX.

[0050] Figure 2 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0051] like Figure 2 As shown, the system architecture 200 may include terminal device 210, network 220, and server 230. Terminal device 210 may include various electronic devices such as smartphones, tablets, laptops, and desktop computers. Server 230 may be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Network 220 may be a communication medium of various connection types capable of providing a communication link between terminal device 210 and server 230, such as a wired communication link or a wireless communication link.

[0052] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, server 230 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to terminal device 210, or to server 230, or can be implemented jointly by terminal device 210 and server 230. This application does not impose any special limitations on this.

[0053] In some embodiments of this application, multiple servers 230 may form a blockchain network, and each server may be a blockchain node on the blockchain network.

[0054] In some embodiments of this application, server 230 may be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0055] Cloud technology is a collective term for network technologies, information technologies, integration technologies, management platform technologies, and application technologies applied based on the cloud computing business model. It can form resource pools, providing flexible and convenient on-demand access. The backend services of cloud computing systems require substantial computing and storage resources, such as those for video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may eventually possess its own identification mark, requiring transmission to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will all require robust system support, which can only be achieved through cloud computing.

[0056] Cloud computing is a computing model that distributes computing tasks across a resource pool composed of a large number of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, and expandable, with payment based on usage. As the foundational providers of cloud computing capabilities, they establish cloud resource pools (referred to as cloud platforms, generally called IaaS (Infrastructure as a Service) platforms), deploying various types of virtual resources within these pools for external customers to choose from. The cloud resource pool primarily includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0057] Cloud security refers to the collective term for security software, hardware, users, organizations, and security cloud platforms based on cloud computing business models. Cloud security integrates emerging technologies and concepts such as parallel processing, grid computing, and the identification of unknown virus behavior. Through a large network of clients, it monitors abnormal software behavior on the network, obtains the latest information on Trojans and malware on the internet, sends it to the server for automatic analysis and processing, and then distributes solutions for viruses and Trojans to each client.

[0058] The main research directions in cloud security include: 1. Cloud computing security, which mainly studies how to ensure the security of the cloud itself and various applications on the cloud, including cloud computer system security, secure storage and isolation of user data, user access authentication, information transmission security, network attack protection, and compliance auditing; 2. Cloudification of security infrastructure, which mainly studies how to use cloud computing to build and integrate security infrastructure resources and optimize security protection mechanisms, including building a large-scale security event and information collection and processing platform through cloud computing technology to achieve the collection and correlation analysis of massive amounts of information and improve the ability to control network-wide security events and risks; 3. Cloud security services, which mainly studies various security services provided to users based on cloud computing platforms, such as antivirus services.

[0059] This application uses the example of building a KMS local service on terminal device 210 to illustrate the general approach to building a local service suitable for trusted computing. KMS stands for Key Manager Server, used to protect user keys. To build an absolutely secure environment, Intel demarcates an independent area in memory called the Enclave. Regardless of the privilege and mode of the processor CPU, the memory outside the Enclave is inaccessible. User applications can only call their own Enclave interfaces through EDL (Enclave Interface Definition Language).

[0060] Figure 3 This diagram illustrates the composition of a local KMS service in one embodiment of this application. Local KMS is an untrusted zone that implements user key management services locally. Local KMS itself does not store keys; instead, it encapsulates the functionality of SGX_KMS through SGX_KMS.EDL, providing an HTTPS-based service interface. SGX_KMS is an SGX module, a trusted zone, which encapsulates basic key operations and stores user keys.

[0061] To implement the aforementioned KMS local service, this embodiment uses Domain Socket + EPOLL to build a high-efficiency local service response framework that supports simultaneous calls from multiple clients. Domain Socket is a method for inter-process communication on Unix systems. Compared to network protocol communication, it is more efficient, eliminating the need for network protocol stacks, packet packing / unpacking, checksum calculation, sequence number maintenance, and acknowledgment processing. EPOLL is an improved polling method suitable for handling large batches of file descriptors, improving event response efficiency.

[0062] Figure 4The flowchart illustrating the steps of implementing KMS local service in one embodiment of this application is shown, which generally includes three parts: initializing KMS, initializing SGX_KMS, and initializing local service.

[0063] Based on the call relationship between the KMS local service and SGX_KMS, the initialization of the KMS local service requires the pre-construction of a trusted environment and the implementation of its initialization. The initialization of KMS includes the following three steps.

[0064] Step S411: Compile a trusted environment.

[0065] This step compiles the IDL and trusted environment code, generating the corresponding Glue code and SGX_KMS.so file.

[0066] Step S412: Create a container, obtain the container's EID, and build the Enclave's runtime environment.

[0067] This step sets the file path for SGX_KMS.so, which is typically placed in the same directory as the ELF file KMS. An Enclave container containing the token is created, and the container's identifier (EID) is obtained, thus providing the Enclave's runtime environment.

[0068] Step S413: Call the interface implemented by the trusted environment through EID to obtain the corresponding value.

[0069] The Enclave container can be released when the process exits.

[0070] The SGX_KMS initialization process mainly involves loading the saved key into memory. This process includes the following three steps.

[0071] Step S421: Read the local sealed data file, which uses the Enclave identity.

[0072] Sealing is a secure data storage service provided by Intel using SGX. To ensure that some data in memory can be persisted when a process exits, the data in memory needs to be serialized beforehand, then sealed into ciphertext and stored in a sealed data file. This ciphertext is encrypted using a key derived from the CPU hardware; this key is unique, and Intel guarantees that even the manufacturer does not know its specific content. Sealing data can be done using either the Enclave identity (MRENCLAVE) or the Signer identity (MRSIGNER). The MRENCLAVE method generates a key unique to the security zone, which can only be decrypted by the same security zone on the same computer. The MRSIGNER method generates a sealing key based on the developer's signing key, which can be decrypted by different security zones on the same computer, as long as they belong to the same developer. This application's embodiment uses the MRENCLAVE method as an example for illustration.

[0073] Step S422: Decrypt the sealed data using the key derived from the CPU hardware. The decrypted data is stored in the secure area.

[0074] Step S423: Deserialize the decrypted sealed data and parse it into KeyID-Key pairs in memory. All KeyID-Key information is created by the user through API calls and is used to encrypt and decrypt user data.

[0075] The process of initializing local services includes the following 8 steps.

[0076] Step S431: Create the EFD resource for EPOLL on the main thread.

[0077] For example, you can set the maximum number of detections to 16.

[0078] Step S432: Use epoll_wait to wait for the event to occur.

[0079] If no event occurs, the main thread will remain blocked.

[0080] Step S433: Create a communication socket in the worker thread.

[0081] Setting the family parameter to AF_UNIX will create a socket file on the system. Different processes communicate by reading and writing to this file.

[0082] Step S434: Bind a local domain socket, with the parameter being a path of type local.

[0083] Domain sockets do not use IP addresses and ports as parameters; instead, they specify a local socket file path. Communication is conducted via local files, not over the network, making it more secure and efficient.

[0084] Step S435: Detect the socket.

[0085] The service is provided by binding the address (i.e., the socket file), and this process does not block the thread.

[0086] Step S436: Set the detected FD to O_NONBLOCK mode and register the detected FD to the EPOLL handle EFD.

[0087] Step S437: When a client connects, the thread waiting for EPOLL (the main thread) receives the event (EPOLLIN) and generates a callback.

[0088] Call accept in the callback to generate a file descriptor (FD) waiting to receive data.

[0089] The file descriptor (FD) waiting to receive data is registered with the EPOLL handle EFD. When a client sends data, the EPOLL waiting thread (the main thread) receives an event (EPOLLIN) and generates a data reception callback. In the data reception callback, all data is received and stored in a buffer.

[0090] Step S438: After parsing the message, send the data packet to the application layer for processing.

[0091] Compared with the traditional Select method, EPOLL's data reception method has the following advantages: (1) EPOLL only needs to copy the FD to the kernel and wait for the event when adding the FD. Select, on the other hand, copies the FD to the kernel every time, increasing the response time.

[0092] (2) EPOLL has a ready queue. When an event occurs, the corresponding FD will be moved to the ready queue. Select does not have this feature. In this way, EPOLL only needs to check the ready queue, while Select needs to traverse all FDs.

[0093] (3) Based on the above principles, EPOLL theoretically has no limit on the number of FDs detected, and the throughput depends on the machine's response performance. However, the upper limit of FDs for Select is 1024.

[0094] EPOLL has two modes: ET and LT. ET is Edge Triggered mode, which generates a notification when the state changes, requiring the service to read all data until an error occurs. LT is Level Triggered mode, which generates a new notification as long as there is unprocessed data in the cache. The local KMS service in this embodiment can use LT mode.

[0095] In order to invoke the local KMS service, the client also needs to establish a domain socket for communication with the server. The server's application layer, upon receiving the data packet assembled from the domain socket, can then respond to the message.

[0096] Figure 5 This illustration shows a flowchart of a key management method according to one embodiment of the present application. This key management method is executed by a terminal device or server configured with the aforementioned KMS service, or it can be executed jointly by the terminal device and the server. This embodiment uses a key management method executed on a terminal device as an example for illustration. Figure 5 As shown, the key management method mainly includes the following steps S510 to S530.

[0097] Step S510: Decrypt the sealed data file within the secure area of ​​memory to obtain user-managed key data. The key data includes a key identifier and a user key associated with the key identifier. The secure area is a trusted region created in memory based on trusted computing.

[0098] In one embodiment of this application, a method for decrypting a sealed data file may include: loading the sealed data file stored in an untrusted area into a secure area in memory; decrypting the ciphertext data in the sealed data file using a secure area key derived from processor hardware to obtain plaintext data; and deserializing the decrypted plaintext data to obtain user-managed key data.

[0099] Because remote communication and transmission are required between the client process and the local service process, the plaintext data obtained after decryption in this embodiment is in the form of a byte sequence. After deserialization, the byte sequence can be restored to the form of a data object. This embodiment can use the Protocol Buffer (PROTOBUF) format for serialization / deserialization, following the PB3 syntax.

[0100] In one embodiment of this application, the untrusted area may be a local disk or a storage area in memory other than the secure area. When the untrusted area is a local disk, the method for loading the sealed data file may include: reading the sealed data file stored on the local disk into the secure area of ​​memory. When the untrusted area is a storage area in memory other than the secure area, the method for loading the sealed data file may include: reading the sealed data file stored in another storage area into the secure area of ​​memory.

[0101] Step S520: In response to the received key management request, traverse the key data to determine whether there is a target key identifier that matches the key management request.

[0102] This application embodiment establishes a local service response framework and, based on inter-process communication, provides key management services to client processes through a local service process. Data communication between the client and server processes is achieved through a pre-established local domain socket.

[0103] In one embodiment of this application, when the client process receives a key management request triggered by the user, the client process encapsulates the key management request into a request data packet; the request data packet is sent to the server process through a local socket, the server process being a local service process that provides Key Management Service (KMS); the server process parses and processes the request data packet to obtain the request key identifier carried in the request data packet; and iterates through the key data to determine whether there is a target key identifier in the key data that is the same as the request key identifier.

[0104] In one embodiment of this application, before traversing the key data to determine whether there is a target key identifier that matches the key management request, the request type carried in the key management request can be obtained by parsing the key management request. The request type includes at least one of key creation request, key deletion request, data encryption request, data decryption request, and data re-encryption request.

[0105] In one embodiment of this application, the format of the request data packet is: STX_C + dwHeadLen + dwBodyLen + Head + Body + ETX_C.

[0106] Wherein, STX_C is a fixed header, for example, it can be 0x2E. ETX_C is a fixed trailer, for example, it can be 0x36. dwHeadLen is the common header length, and dwBodyLen is the message body length. Head is the common header, serialized using the PROTOBUF format and following PB3 syntax. The common header Head in this embodiment is defined as follows: message Head { uint32 uint32_command = 1; / / Main command number uint32 uint32_subcmd = 2; / / The subcommand number is an extended field, currently invalid, and can be set to any value. uint32 uint32_seq = 3; / / Sequence value, used to distinguish different request responses from the requester. uint32 uint32_result = 4; / / Return value; 0 -- successful processing, 1-1999 -- custom return code } The main command number indicates the request type for key management requests. The correspondence between the main command number values ​​and request types is as follows: 0x01 Creating a Key 0x02 Deleting the key 0x03 Encryption 0x04 Decryption 0x05 Re-encryption In this embodiment of the application, by parsing the common header (Head) of the request data packet and obtaining the value of the main command number therein, the request type of the key management request corresponding to the request data packet can be determined.

[0107] The Body is the message body, which, like the common header, is serialized using the PROTOBUF format. Different main command numbers correspond to different content in their message bodies.

[0108] For example, when the main command number is 0x01, the request type is "create key", and the corresponding Body message format is as follows.

[0109] / / Create key request package messageCreateKeyReq { byteskey_id=1; / / Creates the key ID, which must be globally unique. Returns an error if duplicates are found. } / / Create key return packet messageCreateKeyRsp { byteskey_id=1; / / Creates the key ID, which must be globally unique. Returns an error if duplicates are found. } For example, when the main command number is 0x03, the request type is data encryption, and the corresponding Body message format is as follows.

[0110] / / Encrypted request packet messageEncryptReq { byteskey_id=1; / / The key ID used for encryption. Returns an error if it does not exist. bytes plain_text = 2; / / Request the plain text to be encrypted } / / Encrypted response packet messageEncryptRsp { byteskey_id=1; / / The key ID used for encryption. Returns an error if it does not exist. bytes cipher_text = 2; / / Encrypted ciphertext } As shown in the above examples, the message body carries the request key identifier (key id) for this key management request. In one embodiment of this application, obtaining the request key identifier carried in the request data packet by parsing the request data packet through the server process may further include: decapsulating the request data packet through the server process to obtain the message body in the request data packet; and parsing the message body to obtain the request key identifier carried in the message body.

[0111] Step S530: Generate response data for the key management request based on the traversal results of the key data, and return the response data to the sender of the key management request.

[0112] In one embodiment of this application, after returning response data to the sender of the key management request, the method further includes resealing the data key and releasing the secure area. The method of resealing the data key includes: serializing the key data stored in the secure area to obtain plaintext data in the form of a byte sequence; encrypting the plaintext data using the secure area key derived from the processor hardware to obtain ciphertext data; and writing the ciphertext data into a sealed data file stored in an untrusted area.

[0113] Figure 6 A flowchart illustrating the steps of responding to a user's key management request in one embodiment of this application is shown. Based on the above embodiments, the local KMS can act as a server process, providing a calling interface to one or more client processes simultaneously, to perform key management in a trusted in-memory environment. Figure 6As shown, the complete process of responding to a user's key management request may include the following steps.

[0114] Step S601: The server process loads the sealed data file stored in the untrusted area into the secure area of ​​memory.

[0115] A sealed data file is an encrypted file obtained by sealing user-managed key data using trusted computing. This encrypted file can only be decrypted within a designated secure area. A secure area is a trusted region created in memory based on trusted computing; one or more secure areas can be created simultaneously in the memory of a computer device.

[0116] Step S602: Use the security zone key derived from the processor hardware to decrypt the ciphertext data in the sealed data file to obtain plaintext data.

[0117] Trusted computing can employ two different data sealing methods: MRENCLAVE and MRSIGNER. MRENCLAVE generates a separate security key for each security zone. Under this method, sealed data files encapsulated within a single security zone can only be decrypted within the same security zone on the same computer device. MRSIGNER, on the other hand, generates a shared security key for each security zone based on the developer's signing key. Under this method, sealed data files encapsulated within a single security zone can be decrypted in any security zone on the same computer device.

[0118] Step S603: Deserialize the decrypted plaintext data to obtain the user-managed key data.

[0119] User-managed key data is serialized and encrypted, then encapsulated in a sealed data file for persistent and reliable storage in untrusted areas. When decryption yields plaintext data, it can be deserialized to convert it into a memory format where key identifiers are paired with user keys, allowing for key management within a secure memory area.

[0120] Step S604: The client process creates a local socket, binds it to the local socket file, and establishes a communication connection with the server process.

[0121] Since local sockets do not have the concepts of IP addresses and ports, in order to enable inter-process communication between client and server processes, a local socket file needs to be bound to the client to distinguish between different clients. Additionally, the client process needs to specify the path to the server process's local socket file, which must be the same as the path to the local socket file bound to the server.

[0122] Step S605: The client process sends a request data packet containing a key management request to the server process through a local socket.

[0123] The data packet structure of a request packet may include a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, which are concatenated in sequence. The common header may carry the request type for the key management request, and the message body may carry the request key identifier for the key management request, as well as other request data such as plaintext to be encrypted, ciphertext to be decrypted, etc.

[0124] Step S606: The server process parses and processes the received request data packet to obtain the key management request and request key identifier carried in it.

[0125] After parsing and processing, the request type and request key identifier of the key management request can be determined. Request types for key management can include, for example, key creation requests, key deletion requests, data encryption requests, data decryption requests, and data re-encryption requests.

[0126] Step S607: Traverse the key data in the secure area to determine whether there is a target key identifier in the key data that is the same as the requested key identifier.

[0127] Step S608: Based on the request type of the key management request and the traversal results of the key data, generate and return response data to the client process.

[0128] Step S609: The server process serializes the key data stored in the secure area to obtain plaintext data in byte sequence form.

[0129] Step S610: Encrypt the plaintext data using the security zone key derived from the processor hardware to obtain ciphertext data.

[0130] Step S611: Write the encrypted data into a sealed data file stored in an untrusted area.

[0131] After completing the response process for a key management request, the sealed data stored in the secure area can be repackaged into a sealed data file and written again to a non-trusted area other than the secure area, such as the local disk. Finally, the secure area in memory is released, and the server process exits.

[0132] The following describes methods for responding to various types of key management requests using multiple embodiments.

[0133] In one embodiment of this application, the request type of the key management request is a key creation request; step S530, generating response data for the key management request based on the traversal result of the key data, may include: if the traversal result of the key data is that there is a target key identifier in the key data that matches the key management request, then generating response data indicating that key creation failed due to duplicate key identifier; if the traversal result of the key data is that there is no target key identifier in the key data that matches the key management request, then generating a new key based on a true random number generator, associating the new key with the target key identifier, inserting it into the key data, and generating response data indicating that key creation was successful.

[0134] Figure 7 The following diagram illustrates a response flow to a key creation request in one embodiment of this application. For example... Figure 7 As shown, the response process may include the following steps.

[0135] Step S710: The local KMS calls the key creation interface of SGX_KMS.

[0136] When the local KMS receives a request to create a key (main command number 0x01), it uses the EDL key creation interface to call the SGX_KMS service.

[0137] Step S720: Determine whether the target key identifier KeyID exists in the key data.

[0138] Within the trusted environment, first iterate through the existing local key identifiers KeyID. If the target key identifier KeyID already exists, proceed to step S730; if the target key identifier KeyID does not exist, i.e., the target key identifier KeyID is a new identifier, proceed to step S740.

[0139] Step S730: SGX_KMS returns response data to the local KMS indicating that key creation failed due to a duplicate KeyID error.

[0140] Step S740: Generate a newly created key associated with the target key identifier. This embodiment of the application can use a hardware-based true random number generator to generate a 256-bit AES key. Further, the newly created key and the target key identifier KeyID are inserted into a key queue stored in memory.

[0141] Step S750: After serializing the key queue, encrypt it using the sealing function. The encrypted data is stored in the local sealed data file keys.seal. The sealed data is encrypted using MRENCLAVE mode and can only be decrypted within the specified enclave on the designated machine. Even if the local ciphertext data is lost, it will not cause data leakage.

[0142] Step S760: SGX_KMS returns a response indicating that the key creation was successful to the local KMS.

[0143] In one embodiment of this application, the request type of the key management request is a key deletion request. Step S530, generating response data for the key management request based on the key data traversal result, may include: if the key data traversal result shows that there is no target key identifier in the key data that matches the key management request, then generating response data indicating successful key deletion; if the key data traversal result shows that there is a target key identifier in the key data that matches the key management request, then removing the target key identifier and the user key associated with the target key identifier from the key data, and generating response data indicating successful key deletion.

[0144] Figure 8 The following diagram illustrates a response flow to a key deletion request in one embodiment of this application. For example... Figure 8 As shown, the response process may include the following steps.

[0145] Step S810: The local KMS calls the SGX_KMS key deletion interface.

[0146] When the local KMS receives a request to delete the key (command word 0x02), it calls the key deletion interface of SGX_KMS.

[0147] Step S820: Determine whether the target key identifier KeyID exists in the key data.

[0148] Within the trusted environment, first iterate through the existing local key identifiers KeyID. If the target key identifier KeyID does not exist, proceed to step S830; if the target key identifier KeyID exists, proceed to step S840.

[0149] Step S830: SGX_KMS returns a response data indicating successful key deletion to the local KMS.

[0150] Step S840: Clear the target key corresponding to the target key identifier KeyID from memory.

[0151] Step S850: Serialize the remaining KeyID-Key key pair queue. Since the content of the key is a binary string, which may contain a string terminator, this embodiment of the application can first encode the user key key, and then serialize the user key key and the corresponding key identifier KeyID. The encoding method for encoding the user key key can be, for example, Base64.

[0152] Step S860: Encrypt the key data queue using the sealing function. The encrypted data is stored in the local keys.seal file, ensuring the persistence of the modification results.

[0153] Step S870: SGX_KMS returns a response data indicating successful key deletion to the local KMS.

[0154] In one embodiment of this application, the request type of the key management request is a data encryption request. Step S530, generating response data for the key management request based on the key data traversal result, may include: if the key data traversal result shows that no target key identifier matching the key management request exists in the key data, then generating response data indicating data encryption failure due to the absence of a key; if the key data traversal result shows that a target key identifier matching the key management request exists in the key data, then using the target user key associated with the target key identifier to encrypt the plaintext data to be encrypted to obtain ciphertext data, and generating response data carrying the target key identifier and the ciphertext data.

[0155] Figure 9 This illustration shows a response flow to a data encryption request in one embodiment of this application. This embodiment uses AES256 CBC mode encryption as an example, based on Intel's IPP encryption library. Figure 9 As shown, the response process may include the following steps.

[0156] Step S910: The local KMS calls the data encryption interface of SGX_KMS.

[0157] When the local KMS receives a request for encrypted data (command word 0x03), it calls the data encryption interface of SGX_KMS.

[0158] Step S920: Determine whether the target key identifier KeyID exists in the key data.

[0159] Within the trusted environment, the existing key identifiers KeyID are first traversed. If the target key identifier KeyID does not exist, step S930 is executed; if the target key identifier KeyID exists, step S940 is executed to begin the encryption process.

[0160] Step S930: SGX_KMS returns response data to the local KMS indicating that data encryption failed due to the absence of a key.

[0161] Step S940: Obtain the AES256 context size.

[0162] Step S950: AES initialization, setting the key content of the found target user key Key.

[0163] Step S960: Randomly generate a 16-byte initialization vector and call the AES CBC mode encryption interface for encryption.

[0164] Step S970: SGX_KMS returns response data carrying the target key identifier and ciphertext data to the local KMS. The 36-byte target key identifier KeyID, initialization vector, and ciphertext are concatenated into a single string. To ensure the data is not modified, a CRC check is added, and then the string is base64 encoded before being returned to the user.

[0165] Finally, the key is removed and the context data is cleaned up to complete the data encryption process.

[0166] In one embodiment of this application, the request type of the key management request is a data decryption request. Step S530, generating response data for the key management request based on the key data traversal result, may include: if the key data traversal result shows that no target key identifier matching the key management request exists in the key data, then generating response data indicating data decryption failure due to the absence of a key; if the key data traversal result shows that a target key identifier matching the key management request exists in the key data, then using the target user key associated with the target key identifier to decrypt the ciphertext data to be decrypted to obtain plaintext data, and generating response data carrying the plaintext data.

[0167] Figure 10 This illustration shows a response flow to a data decryption request in one embodiment of this application. For example... Figure 10 As shown, the response process may include the following steps.

[0168] Step S1010: The local KMS calls the SGX_KMS data decryption interface. The local KMS receives a request to decrypt data (command word 0x04) and calls the SGX_KMS data decryption interface.

[0169] Step S1020: Parse the ciphertext data. After base64 decoding, verify the ciphertext data. Once the data is confirmed to be correct, parse the ciphertext data to obtain the ciphertext, the target key identifier KeyID, and the initialization vector.

[0170] Step S1030: Determine whether the target key identifier KeyID exists in the key data.

[0171] Within the trusted environment in memory, the existing key identifiers KeyID are traversed first to find the key content corresponding to the target key identifier KeyID. If the target key identifier KeyID does not exist in the key data, step S1040 is executed; if the target key identifier KeyID exists in the key data, step S1050 is executed to start the decryption process.

[0172] Step S1040: SGX_KMS returns response data to the local KMS indicating that data decryption failed due to the absence of a key.

[0173] Step S1050: Obtain the AES256 context size.

[0174] Step S1060: AES initialization, setting the key content of the parsed target user key Key.

[0175] Step S1070: Set the ciphertext, encryption context, and initialization vector to the decryption function to obtain the decrypted plaintext data.

[0176] Step S1080: After base64 encoding the plaintext data, return the response data carrying the plaintext data to the local KMS system.

[0177] Finally, remove the key and clean up the context data to complete the data decryption process.

[0178] In one embodiment of this application, the request type of the key management request is a data re-encryption request, and the target key identifier includes a first key identifier for data decryption and a second key identifier for data encryption. Step S530, generating response data for the key management request based on the key data traversal result, may include: if the key data traversal result shows that at least one of the first key identifier and the second key identifier is not present in the key data, then generating response data indicating that data re-encryption failed due to the absence of the key; if the key data traversal result shows that both the first key identifier and the second key identifier are present in the key data, then the first key identifier is used to decrypt the first ciphertext data to obtain plaintext data, the second key identifier is used to encrypt the plaintext data to obtain second ciphertext data, and response data carrying the second key identifier and the second ciphertext data is generated.

[0179] Re-encryption is primarily used to address key rotation scenarios. Users may find that an old key has been in use for too long and could pose security risks. A new key can be created to replace the old one. Since the old key has already encrypted some data, this portion needs to be decrypted before re-encrypting with the new key. The old key is only deleted after ensuring it has not been used again; otherwise, the old data will be undecryptable.

[0180] Figure 11 The following diagram illustrates a response flow to a data re-encryption request in one embodiment of this application. For example... Figure 11 As shown, the response process may include the following steps.

[0181] Step S1110: The local KMS calls the SGX_KMS data re-encryption interface. The local KMS receives a request to re-encrypt data (command word 0x05) and calls the SGX_KMS data re-encryption interface.

[0182] Step S1120: Parse the ciphertext data. After base64 decoding, verify the ciphertext data. Once the data is confirmed to be correct, parse the ciphertext data to obtain the ciphertext, key ID, and initialization vector.

[0183] Step S1130: Determine whether the target key identifier KeyID exists in the key data.

[0184] The target key identifier includes a first key identifier (old key identifier) ​​used for data decryption and a second key identifier (new key identifier) ​​used for data encryption. The key content corresponding to the old key ID and the new key ID is searched within the trusted environment of memory. If the target key identifier KeyID does not exist in the key data, step S1140 is executed; if the target key identifier KeyID exists in the key data, step S1150 is executed, and the re-encryption process begins.

[0185] Step S1140: SGX_KMS returns response data to the local KMS indicating that data re-encryption failed due to the absence of a key.

[0186] Step S1150: Obtain the AES256 context size.

[0187] Step S1160: After two AES initializations, set the contents of the old key Key and the new key Key. The old key Key is used to decrypt data, and the new key Key is used to encrypt data.

[0188] Step S1170: Set the ciphertext, encryption context, and initialization vector to the decryption function to obtain the decrypted plaintext data.

[0189] Step S1180: Set the plaintext data to the encryption function and encrypt the data with the new key Key to obtain the new ciphertext.

[0190] Step S1190: SGX_KMS returns response data carrying the new key identifier and new ciphertext data to the local KMS. The 36-byte key identifier KeyID, initialization vector, and new ciphertext are concatenated into a single string. To ensure the data is not modified, a CRC check is added, and after base64 encoding, the string is returned to the user.

[0191] Finally, remove the key and clean up the context data to complete the data re-encryption process.

[0192] As can be seen from the above embodiments, this application provides a scheme for local key escrow based on trusted computing. By utilizing the local CPU's support for trusted computing, the cost of key escrow is greatly reduced compared to schemes using encryption machines. This application also provides an IPC communication method based on Domain Socket + EPOLL, which greatly reduces network latency and improves efficiency and security compared to the previous method of using encryption machines through network requests.

[0193] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0194] The following describes an apparatus embodiment of this application, which can be used to execute the key management method in the above embodiments of this application. Figure 12 A schematic block diagram of a key management device provided in an embodiment of this application is shown. Figure 12 As shown, the key management device 1200 mainly includes: a key acquisition module 1210, configured to decrypt a sealed data file in a secure area of ​​memory to obtain user-managed key data, the key data including a key identifier and a user key associated with the key identifier, the secure area being a trusted region created in memory based on trusted computing; a key matching module 1220, configured to traverse the key data in response to a received key management request to determine whether there is a target key identifier that matches the key management request; and a request response module 1230, configured to generate response data for the key management request based on the traversal result of the key data and return the response data to the sender of the key management request.

[0195] In some embodiments of this application, based on the above embodiments, the key acquisition module 1210 includes: a data loading unit configured to load a sealed data file stored in an untrusted area into a secure area in memory; a key decryption unit configured to use a secure area key derived from processor hardware to decrypt the ciphertext data in the sealed data file to obtain plaintext data; and a deserialization unit configured to deserialize the decrypted plaintext data to obtain user-managed key data.

[0196] In some embodiments of this application, based on the above embodiments, the untrusted area is a local disk or a storage area in memory other than the secure area; the data loading unit includes: a disk reading subunit configured to read a sealed data file stored in the local disk into the secure area of ​​memory; or, a memory reading subunit configured to read a sealed data file stored in the other storage area into the secure area of ​​memory.

[0197] In some embodiments of this application, based on the above embodiments, the key matching module 1220 includes: a request encapsulation unit configured to encapsulate the key management request into a request data packet through a client process; a request sending unit configured to send the request data packet to a server process through a local socket, wherein the server process is a local service process providing Key Management Service (KMS); a request parsing unit configured to parse the request data packet through the server process to obtain a request key identifier carried in the request data packet; and a key traversal unit configured to traverse the key data to determine whether there is a target key identifier in the key data that is the same as the request key identifier.

[0198] In some embodiments of this application, based on the above embodiments, the request data packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, concatenated sequentially; the request parsing unit includes: a decapsulation subunit, configured to decapsulate the request data packet through the server process to obtain the message body in the request data packet; and a body parsing subunit, configured to parse the message body to obtain the request key identifier carried in the message body.

[0199] In some embodiments of this application, based on the above embodiments, the key management device 1200 further includes: a serialization module configured to serialize the key data stored in the secure area to obtain plaintext data in the form of a byte sequence; an encryption module configured to encrypt the plaintext data using a secure area key derived from the processor hardware to obtain ciphertext data; and a writing module configured to write the ciphertext data into a sealed data file stored in an untrusted area.

[0200] In some embodiments of this application, based on the above embodiments, the key management device 1200 further includes: a parsing module configured to parse the key management request to obtain the request type carried in the key management request, wherein the request type includes at least one of key creation request, key deletion request, data encryption request, data decryption request, and data re-encryption request.

[0201] In some embodiments of this application, based on the above embodiments, the request type of the key management request is a key creation request; the request response module 1230 includes: a first response unit, configured to generate response data indicating key creation failure due to duplicate key identifier if the traversal result of the key data contains a target key identifier that matches the key management request; and a key creation unit, configured to generate a new key based on a true random number generator if the traversal result of the key data contains no target key identifier that matches the key management request, associate the new key with the target key identifier, insert it into the key data, and generate response data indicating successful key creation.

[0202] In some embodiments of this application, based on the above embodiments, the request type of the key management request is a key deletion request; the request response module 1230 includes: a second response unit configured to generate key deletion success response data if the traversal result of the key data does not contain a target key identifier that matches the key management request; and a key deletion unit configured to remove the target key identifier and the user key associated with the target key identifier from the key data if the traversal result of the key data does contain a target key identifier that matches the key management request, and generate key deletion success response data.

[0203] In some embodiments of this application, based on the above embodiments, the request type of the key management request is a data encryption request; the request response module 1230 includes: a third response unit configured to generate response data indicating that data encryption fails due to the absence of a key if the traversal result of the key data does not contain a target key identifier that matches the key management request; and a data encryption unit configured to encrypt the plaintext data to be encrypted using a target user key associated with the target key identifier to obtain ciphertext data if the traversal result of the key data does contain a target key identifier that matches the key management request, and generate response data carrying the target key identifier and the ciphertext data.

[0204] In some embodiments of this application, based on the above embodiments, the request type of the key management request is a data decryption request; the request response module 1230 includes: a fourth response unit, configured to generate response data indicating that data decryption failed due to the absence of a key if the traversal result of the key data does not contain a target key identifier that matches the key management request; and a data decryption unit, configured to use a target user key associated with the target key identifier to decrypt the ciphertext data to be decrypted to obtain plaintext data if the traversal result of the key data does contain a target key identifier that matches the key management request, and generate response data carrying the plaintext data.

[0205] In some embodiments of this application, based on the above embodiments, the request type of the key management request is a data re-encryption request, and the target key identifier includes a first key identifier for data decryption and a second key identifier for data encryption; the request response module 1230 includes: a fifth response unit configured to generate response data indicating that data re-encryption fails due to the absence of a key if the traversal result of the key data does not contain at least one of the first key identifier and the second key identifier; and a data re-encryption unit configured to, if the traversal result of the key data does contain both the first key identifier and the second key identifier, decrypt the first ciphertext data using the first key identifier to obtain plaintext data, encrypt the plaintext data using the second key identifier to obtain second ciphertext data, and generate response data carrying the second key identifier and the second ciphertext data.

[0206] The specific details of the key management device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0207] Figure 13A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0208] It should be noted that, Figure 13 The computer system 1300 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0209] like Figure 13 As shown, the computer system 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1302 or programs loaded from storage section 1308 into random access memory (RAM). The RAM 1303 also stores various programs and data required for system operation. The CPU 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output interface 1305 (I / O interface) is also connected to the bus 1304.

[0210] The following components are connected to the input / output interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a local area network card, modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the input / output interface 1305 as needed. Removable media 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on the drive 1310 as needed so that computer programs read from them can be installed into the storage section 1308 as needed.

[0211] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1309, and / or installed from removable medium 1311. When the computer program is executed by central processing unit 1301, it performs various functions defined in the system of this application.

[0212] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0213] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0214] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0215] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0216] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0217] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A key management method, executed by a terminal device, characterized in that, The method includes: The sealed data file is loaded from the untrusted region of the terminal device to the secure region, which is a trusted region created in the memory of the terminal device based on trusted computing. Using the security zone key derived from the processor hardware of the terminal device, the sealed data file is decrypted to obtain user-managed key data, which includes multiple key pairs consisting of KeyID and Key; wherein KeyID is a key identifier and Key is a user key associated with the key identifier. In response to a received key creation request or key deletion request, the key data is traversed to determine whether there is a target key identifier that matches the key creation request or key deletion request. The target key identifier is used to indicate the user key that the user requests to create or delete. Based on the traversal results of the key data, response data is generated for the key creation request or key deletion request, and the response data is returned to the sender of the key creation request or key deletion request. The response data is used to indicate whether the creation or deletion of the user key is successful or unsuccessful.

2. The key management method according to claim 1, characterized in that, The decryption of the sealed data file includes: The ciphertext data in the sealed data file is decrypted to obtain plaintext data; The decrypted plaintext data is deserialized to obtain the user-managed key data.

3. The key management method according to claim 2, characterized in that, The untrusted area is a storage area in the local disk or memory other than the secure area; Load the sealed data file stored in the untrusted area into the secure area in memory, including: The sealed data file stored on the local disk is read into the secure area of ​​memory; Alternatively, the sealed data file stored in the other storage area can be read into the secure area of ​​memory.

4. The key management method according to claim 1, characterized in that, Traverse the key data to determine if there is a target key identifier that matches the key creation request or key deletion request, including: The client process encapsulates the key creation request or key deletion request into a request data packet. The request data packet is sent to the server process via a local socket. The server process is a local service process that provides Key Management Service (KMS). The server process parses the request data packet to obtain the request key identifier carried in the request data packet. The key data is traversed to determine whether there is a target key identifier in the key data that is the same as the requested key identifier.

5. The key management method according to claim 4, characterized in that, The request data packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, concatenated sequentially. The server process parses the request data packet to obtain the request key identifier carried within it, including: The server process decapsulates the request data packet to obtain the message body of the request data packet. The message body is parsed to obtain the request key identifier carried in the message body.

6. The key management method according to claim 1, characterized in that, After returning the response data to the sender of the key creation request or key deletion request, the method further includes: The key data stored in the secure area is serialized to obtain plaintext data in byte sequence form; The plaintext data is encrypted using a security zone key derived from the processor hardware to obtain ciphertext data; The encrypted data is written into a sealed data file stored in an untrusted area.

7. The key management method according to any one of claims 1 to 6, characterized in that, The method further includes: Parse the key management request to obtain the request type carried in the key management request. The request type includes at least one of the following: key creation request, key deletion request, data encryption request, data decryption request, and data re-encryption request. The key data is traversed to determine whether a target key identifier matching the key management request exists; Based on the traversal results of the key data, generate response data for the key management request and return the response data to the sender of the key management request.

8. The key management method according to claim 7, characterized in that, The request type for the key management request is a key creation request; Based on the traversal results of the key data, response data for the key management request is generated, including: If the traversal result of the key data is that there is a target key identifier in the key data that matches the key management request, then response data is generated indicating that key creation failed due to duplicate key identifiers. If the traversal result of the key data is that there is no target key identifier in the key data that matches the key management request, then a new key is generated based on a true random number generator, the new key is associated with the target key identifier and inserted into the key data, and response data indicating successful key creation is generated.

9. The key management method according to claim 7, characterized in that, The request type for the key management request is a key deletion request; Based on the traversal results of the key data, response data for the key management request is generated, including: If the traversal result of the key data is that there is no target key identifier in the key data that matches the key management request, then a response data indicating successful key deletion is generated. If the traversal result of the key data is that there is a target key identifier in the key data that matches the key management request, then the target key identifier and the user key associated with the target key identifier are cleared from the key data, and response data indicating successful key deletion is generated.

10. The key management method according to claim 7, characterized in that, The request type for the key management request is a data encryption request; Based on the traversal results of the key data, response data for the key management request is generated, including: If the traversal result of the key data is that there is no target key identifier in the key data that matches the key management request, then response data is generated indicating that the data encryption failed due to the absence of a key. If the traversal result of the key data is that there is a target key identifier in the key data that matches the key management request, then the plaintext data to be encrypted is encrypted using the target user key associated with the target key identifier to obtain ciphertext data, and response data carrying the target key identifier and the ciphertext data is generated.

11. The key management method according to claim 7, characterized in that, The request type for the key management request is a data decryption request; Based on the traversal results of the key data, response data for the key management request is generated, including: If the traversal result of the key data is that there is no target key identifier in the key data that matches the key management request, then response data is generated indicating that the data decryption failed due to the absence of a key. If the traversal result of the key data is that there is a target key identifier in the key data that matches the key management request, then the target user key associated with the target key identifier is used to decrypt the ciphertext data to be decrypted to obtain plaintext data, and response data carrying the plaintext data is generated.

12. The key management method according to claim 7, characterized in that, The request type of the key management request is a data re-encryption request, and the target key identifier includes a first key identifier for data decryption and a second key identifier for data encryption; Based on the traversal results of the key data, response data for the key management request is generated, including: If the traversal result of the key data does not contain at least one of the first key identifier and the second key identifier, then response data is generated indicating that the data re-encryption failed due to the absence of the key. If the traversal result of the key data is that the first key identifier and the second key identifier exist in the key data, then the first key identifier is used to decrypt the first ciphertext data to obtain plaintext data, the second key identifier is used to encrypt the plaintext data to obtain second ciphertext data, and response data carrying the second key identifier and the second ciphertext data is generated.

13. A key management device, applied to a terminal device, characterized in that, The device includes: The key acquisition module is configured to load a sealed data file from an untrusted area of ​​the terminal device into a secure area, the secure area being a trusted area created in the memory of the terminal device based on trusted computing; and to decrypt the sealed data file using a secure area key derived from the processor hardware of the terminal device to obtain user-managed key data, the key data including multiple key pairs consisting of KeyID and Key; wherein KeyID is a key identifier and Key is a user key associated with the key identifier; The key matching module is configured to, in response to a received key creation request or key deletion request, traverse the key data to determine whether there is a target key identifier that matches the key creation request or key deletion request, the target key identifier being used to indicate the user key that the user requests to create or delete; The request-response module is configured to generate response data for the key creation request or key deletion request based on the traversal result of the key data, and return the response data to the sender of the key creation request or key deletion request. The response data is used to indicate whether the creation or deletion of the user key is successful or unsuccessful.

14. A computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the key management method according to any one of claims 1 to 12.

15. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the key management method according to any one of claims 1 to 12 by executing the executable instructions.

16. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the key management method as described in any one of claims 1 to 12.

Images