CN115203710A

CN115203710A - Key management method, key management device, computer readable medium and electronic equipment

Info

Publication number: CN115203710A
Application number: CN202110379401.2A
Authority: CN
Inventors: 林委坤; 姬生利; 董志强; 李滨
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2021-04-08
Filing date: 2021-04-08
Publication date: 2022-10-18

Abstract

The present application belongs to the field of computer technologies, and in particular, relates to a key management method, a key management apparatus, a computer-readable medium, and an electronic device. The method comprises the following steps: decrypting the sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone established in the memory based on trusted computing; traversing the key data to determine whether a target key identification matching the key management request exists in response to the received key management request; and generating response data to the key management request according to the traversal result of the key data, and returning the response data to a sender of the key management request. The method can improve the reliability of key management and reduce the cost of key management.

Description

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

Technical Field

The present application belongs to the field of computer technologies, and in particular, relates to a key management method, a key management apparatus, a computer-readable medium, and an electronic device.

Background

In the current network environment, in order to ensure the data security of the user, a data encryption mode is generally adopted for data transmission and storage. However, the key used to encrypt the data is also at risk of leakage during transmission and storage. Therefore, how to reliably manage the user key is a problem to be solved urgently at present.

Disclosure of Invention

An object of the present application is to provide a key management method, a key management apparatus, a computer-readable medium, and an electronic device, which overcome, at least to some extent, the technical problem of poor reliability of key management in the related art.

Other features and advantages of the present application will be apparent from the following detailed description, or may be learned by practice of the application.

According to an aspect of an embodiment of the present application, there is provided a key management method, including: decrypting the sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone established in the memory based on trusted computing; traversing the key data to determine whether a target key identification matching the key management request exists in response to the received key management request; and generating response data to the key management request according to the traversal result of the key data, and returning the response data to a sender of the key management request.

According to an aspect of an embodiment of the present application, there is provided a key management apparatus including: the key acquisition module is configured to decrypt a sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone created in the memory based on trusted computing; a key matching module configured to traverse the key data to determine whether a target key identification matching the key management request exists in response to the received key management request; and the request response module is configured to generate response data to the key management request according to the traversal result of the key data and return the response data to the sender of the key management request.

In some embodiments of the present application, based on the above technical solution, the key obtaining module includes: the data loading unit is configured to load the sealed data file stored in the untrusted area into a secure area of the memory; the key decryption unit is configured to decrypt ciphertext data in the sealed data file by using a secure area key derived from processor hardware to obtain plaintext data; and the deserializing unit is configured to deserialize the decrypted plaintext data to obtain the key data hosted by the user.

In some embodiments of the present application, based on the above technical solutions, the untrusted area is a local disk or another storage area in the memory except for the secure area; the data loading unit includes: the magnetic disk reading subunit is configured to read the sealed data file stored in the local magnetic disk into a safe area of the memory; or the memory reading subunit is configured to read the sealed data file stored in the other storage area into a secure area of the memory.

In some embodiments of the present application, based on the above technical solution, the key matching module includes: a request encapsulation unit configured to encapsulate the key management request into a request packet by a client process; a request sending unit configured to send the request data packet to a server process through a local socket, where the server process is a local service process providing a key management service KMS; the request analysis unit is configured to analyze the request data packet through the server process to obtain a request key identifier carried in the request data packet; a key traversal unit configured to traverse the key data to determine whether a target key identification identical to the request key identification exists in the key data.

In some embodiments of the present application, based on the above technical solution, the request packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, which are sequentially spliced; the request parsing unit includes: the decapsulation subunit is configured to decapsulate the request data packet by the server process to obtain a message body in the request data packet; and the main body analysis subunit is configured to analyze the message main body to obtain the request key identifier carried in the message main body.

In some embodiments of the present application, based on the above technical solutions, the apparatus further includes: the serialization module is configured to perform serialization processing on the key data stored in the security zone to obtain plaintext data in a byte sequence form; the encryption module is configured to encrypt the plaintext data by using a secure area key derived from processor hardware to obtain ciphertext data; and the writing module is configured to write the ciphertext data into the sealed data file stored in the non-trusted area.

In some embodiments of the present application, based on the above technical solutions, the apparatus further includes: and the analysis module is configured to analyze the key management request to obtain a request type carried in the key management request, wherein the request type comprises 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.

In some embodiments of the present application, based on the above technical solution, the request type of the key management request is a request for creating a key; the request response module comprises: a first response unit configured to generate response data in which key creation fails due to repetition of key identification if a target key identification matching the key management request exists in the key data as a result of traversal of the key data; and the key creating unit is configured to generate a newly created key based on a true random number generator if the key data does not have a target key identifier matched with the key management request as a result of traversal of the key data, associate the newly created key with the target key identifier, insert the newly created key into the key data, and generate response data with successful key creation.

In some embodiments of the present application, based on the above technical solution, the request type of the key management request is a request for deleting a key; the request response module comprises: a second response unit configured to generate response data with successful key deletion if the traversal result of the key data indicates that the target key identifier matching the key management request does not exist in the key data; and the key deleting unit is configured to clear the target key identification and the user key associated with the target key identification from the key data and generate response data with successful key deletion if the traversal result of the key data indicates that the target key identification matched with the key management request exists in the key data.

In some embodiments of the present application, based on the above technical solution, the request type of the key management request is a data encryption request; the request response module comprises: a third response unit configured to generate response data in which data encryption fails due to absence of a key if the traversal result of the key data is that a target key identifier matching the key management request does not exist in the key data; and the data encryption unit is configured to encrypt plaintext data to be encrypted by using a target user key associated with the target key identifier to obtain ciphertext data and generate response data carrying the target key identifier and the ciphertext data if the traversal result of the key data indicates that the target key identifier matched with the key management request exists in the key data.

In some embodiments of the present application, based on the above technical solution, the request type of the key management request is a data decryption request; the request response module comprises: a fourth response unit configured to generate response data that causes data decryption failure due to absence of a key if a result of traversal of the key data is that a target key identifier matching the key management request does not exist in the key data; and the data decryption unit is configured to decrypt ciphertext data to be decrypted by using a target user key associated with the target key identifier to obtain plaintext data and generate response data carrying the plaintext data if the traversal result of the key data indicates that the target key identifier matched with the key management request exists in the key data.

In some embodiments of the present application, based on the above technical solution, 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 comprises: a fifth response unit configured to generate response data that causes data re-encryption failure due to absence of a key if a traversal result of the key data is that at least one of the first key identifier and the second key identifier does not exist in the key data; and the data re-encryption unit is configured to decrypt first ciphertext data by using the first key identifier to obtain plaintext data, encrypt the plaintext data by 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 indicates that the first key identifier and the second key identifier exist in the key data.

According to an aspect of the embodiments of the present application, there is provided a computer readable medium, on which a computer program is stored, and the computer program, when executed by a processor, implements a key management method as in the above technical solutions.

According to an aspect of an embodiment of the present application, there is provided an electronic apparatus including: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the key management method as in the above technical solution via executing the executable instructions.

According to an aspect of an embodiment of the present application, there is provided a computer program product or a computer program comprising computer instructions 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 executes the computer instructions, so that the computer device executes the key management method as in the above technical solution.

In the technical scheme provided by the embodiment of the application, the secure zone is created in the memory based on the trusted computing, the key data managed by the user is managed, and the reliable key protection function can be realized based on the local environment without using an encryption machine. The embodiment of the application changes the use mode of the traditional dependent encryption machine, and greatly reduces the cost of protecting the user key based on hardware.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application. It is obvious that the drawings in the following description are only some embodiments of the application, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.

Fig. 1 shows a block diagram of a system architecture for implementing key management using a conventional encryptor.

Fig. 2 schematically shows a block diagram of an exemplary system architecture to which the solution of the present application applies.

Fig. 3 shows a schematic composition diagram of a local KMS service in an embodiment of the present application.

Fig. 4 shows a flow chart of the steps of implementing KMS local services in one embodiment of the present application.

FIG. 5 is a flow chart illustrating steps of a key management method in one embodiment of the present application.

FIG. 6 shows a flow chart of the steps of responding to a user's key management request in one embodiment of the present application.

FIG. 7 illustrates a response flow for a create key request in one embodiment of the present application.

FIG. 8 illustrates a flow of a response to a delete key request in one embodiment of the present application.

FIG. 9 shows a flow of a response to a request for data encryption in one embodiment of the present application.

FIG. 10 shows a flow of responses to a data decryption request in one embodiment of the application.

FIG. 11 illustrates a flow of a response to a data re-encryption request in one embodiment of the application.

Fig. 12 schematically shows a block diagram of a key management device according to an embodiment of the present application.

FIG. 13 schematically illustrates a block diagram of a computer system suitable for use in implementing an electronic device of an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

In the related art of the present application, there are two ways of saving the key, namely, saving based on software and saving based on hardware. From the perspective of safety, the software environment runs in the memory, and the risk that the software environment cannot avoid always exists. Thus, the use of hardware-based key protection is typically required, whether from the national compliance level, or the user security level.

The key protection based on hardware is currently commonly performed by using a cryptographic card or an encryption machine. The inside of the password card and the encryption machine is a set of closed environment, in order to interact with the application program, the international PKCS #11 standard is generally followed or an SDF mode is used, the process of realizing the interaction is relatively troublesome, and a specific program needs to be developed. In order to monitor the performance data of the encryption machine, in addition to the external development of the service port, a management port and a monitoring port are often opened.

Fig. 1 shows a block diagram of a system architecture for implementing key management using a conventional encryptor. As shown in fig. 1, a client 110 that needs to use a key communicates with an encryption machine 130 (HSM) through a software development kit 120 (SDK) provided by the crypto machine vendor. The key is generated and stored inside the encryption machine 130, and when the client 110 needs to use the key, sensitive information can be transmitted to the encryption machine 130 through a hypertext Transfer Protocol over secure key Layer (HTTPS) for encryption and decryption, so that the security of the information can be ensured.

Although the problem of security of an encryption scene can be solved to a certain extent by using an encryptor for key management, the following problems still exist:

(1) The configuration cost is high, and resources cannot be reasonably utilized. The cost of the encryption machine is high, and only a few large enterprises can bear the encryption machine.

(2) The use cost is high, and the development cycle is long. The user needs to develop the program based on the SDK of the manufacturer, and in each client environment, needs to configure the SDK running environment of the manufacturer.

(3) The framework is inflexible and cannot meet the variable requirements. Network transmission exists between the client and the encryption machine, and if a bidirectional SSL authentication mode is used, the transmission efficiency is low; if a plaintext communication mode is used, the information security problem exists.

In view of the above problems in the related art, in the embodiments of the present application, a program developed based on trusted computing is placed in a local area of a user by using the characteristic that a CPU of an existing machine of the user supports trusted computing, and the user can realize a key protection function based on a local environment without using an encryption engine.

Trusted computing is typically secured to programs by computer hardware, such as the CPU. Early Trusted computing was TPM (Trusted Platform Module), TXT (Trusted Execution Technology), but reliability and ease of use were less than the later-appearing SGX (Software Guard Extension). The SGX is an extension of an Intel instruction set architecture, provides an encrypted trusted execution area in a memory, and protects data and privacy from being stolen by malicious codes by a CPU. The embodiments of the present application mainly use SGX as an example, and describe how to use SGX to implement a scheme for key escrow.

As shown in fig. 2, the system architecture 200 may include a terminal device 210, a network 220, and a server 230. The terminal device 210 may include various electronic devices such as a smart phone, a tablet computer, a notebook computer, and a desktop computer. The server 230 may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing cloud computing services. The network 220 may be any of a variety of connection types of communication media capable of providing a communication link between the terminal device 210 and the server 230, such as a wired communication link or a wireless communication link.

The system architecture in the embodiments of the present application may have any number of terminal devices, networks, and servers, according to implementation needs. For example, server 230 may be a server group consisting of a plurality of server devices. In addition, the technical solution provided in the embodiment of the present application may be applied to the terminal device 210, or may be applied to the server 230, or may be implemented by both the terminal device 210 and the server 230, which is not particularly limited in this application.

In some embodiments of the present application, multiple servers 230 may form a blockchain network, with each server being a blockchain node on the blockchain network.

In some embodiments of the present application, the server 230 may be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, web services, cloud communications, middleware services, domain name services, security services, CDNs, and big data and artificial intelligence platforms.

Cloud technology (Cloud technology) is a generic term of network technology, information technology, integration technology, management platform technology, application technology and the like based on Cloud computing business model application, can form a resource pool, is used as required, and is flexible and convenient. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have an own identification mark and needs to be transmitted to a background system for logic processing, data of different levels can be processed separately, and various industry data need strong system background support and can be realized only through cloud computing.

Cloud computing (cloud computing) is a computing model that distributes computing tasks over a large pool of computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network that provides the resources is referred to as the "cloud". Resources in the "cloud" appear to the user as if they are infinitely expandable and can be acquired at any time, used on demand, expanded at any time, and paid for use. As a basic capability provider of cloud computing, a cloud computing resource pool (called as an ifas (Infrastructure as a Service) platform for short is established, and multiple types of virtual resources are deployed in the resource pool and are selectively used by external clients.

Cloud Security (Cloud Security) refers to a generic term for Security software, hardware, users, organizations, secure Cloud platforms based on Cloud computing business model applications. The cloud security integrates emerging technologies and concepts such as parallel processing, grid computing and unknown virus behavior judgment, the latest information of Trojan horses and malicious programs in the internet is obtained through abnormal monitoring of a large number of netted clients on software behaviors in the network, the latest information is sent to a server for automatic analysis and processing, and then the solutions of viruses and Trojan horses are distributed to each client.

The main research directions of cloud security include: 1. the cloud computing security mainly researches how to guarantee the security of the cloud and various applications on the cloud, including the security of a cloud computer system, the secure storage and isolation of user data, user access authentication, information transmission security, network attack protection, compliance audit and the like; 2. the cloud of the security infrastructure mainly researches how to adopt cloud computing to newly build and integrate security infrastructure resources and optimize a security protection mechanism, and comprises the steps of constructing a super-large-scale security event and an information acquisition and processing platform through a cloud computing technology, realizing the acquisition and correlation analysis of mass information, and improving the handling control capability and the risk control capability of the security event of the whole network; 3. the cloud security service mainly researches various security services such as anti-virus services and the like provided for users based on a cloud computing platform.

The embodiment of the application takes the establishment of the KMS local service on the terminal device 210 as an example, and illustrates a general idea of establishing the local service suitable for trusted computing. The KMS is a Key management service Key Manager Server and is used for protecting a Key of a user. Intel circles out a separate area in memory called secure area Enclave in order to build an absolutely secure environment. The memory of the Enclave is not readable and writable no matter what privilege and mode the processor CPU is in. The application program of the user needs to call the own Enclave interface and can only be realized through the EDL (Enclave interface definition language).

Fig. 3 shows a schematic composition diagram of a local KMS service in an embodiment of the present application. The Local KMS is an untrusted area, and realizes the key management service of the user in a Local service mode. Local KMS does not store keys, but provides an HTTPS-based service interface to the outside through the function of SGX _ KMS encapsulated by EDL. The SGX _ KMS is an SGX module, is a trusted area, encapsulates basic operation of keys and stores user keys.

In order to realize the KMS local service, an efficient local service response framework is established by using a mode of Domain Socket + EPOLL in the embodiment of the application, and a plurality of Client clients are supported to call simultaneously. The Domain Socket is a mode for realizing interprocess communication on a Unix system, is more efficient compared with communication by using a network protocol, does not need to pass through a network protocol stack, and does not need to pack and unpack, calculate a checksum, maintain a serial number, answer and the like. EPOLL is an improved poll mode, and can be suitable for users to process large-batch file descriptors, thereby improving the response efficiency of events.

Fig. 4 shows a flowchart illustrating steps of implementing the KMS local service in one embodiment of the present application, which includes three parts, namely, an initialization KMS, an initialization SGX _ KMS, and an initialization local service.

Based on the calling relationship between the KMS local service and the SGX _ KMS, the KMS local service is initialized, a trusted environment needs to be constructed in advance, and initialization of the trusted environment is realized. Therein, initializing the KMS includes the following 3 steps.

Step S411: the trusted environment is compiled.

The IDL and the trusted environment code are compiled in the step, and a corresponding Glue code and an SGX _ KMS.

Step S412: creating a container, acquiring the EID of the container, and constructing an Enclave running environment.

So, the file path of the SGX _ KMS is set, typically in the same directory as the ELF file KMS. Creating an Enclave container containing the label token, and acquiring the identifier EID of the container to obtain the operating environment of the Enclave.

Step S413: and calling an interface realized by a trusted environment through the EID to acquire a corresponding value.

The Enclave container may be released when the process exits.

The SGX _ KMS initialization process mainly implements loading of a stored Key into a memory, and includes the following 3 steps.

Step S421: and reading a local sealed data file, wherein the sealed data uses an Enclave identity.

Sealing (Sealing) is a service provided by Intel using SGX for safely storing data, in order to ensure that a process can persist data in a part of memory when exiting, the data in the memory needs to be serialized in advance, then Sealing is performed to form a ciphertext, the ciphertext is stored in a sealed data file, the ciphertext is encrypted by using a key derived from CPU hardware, the key is unique, and the Intel ensures that manufacturers do not know specific contents. The sealed data is divided into an Enclave identity (MRENCLAVE) and a signer identity (MRSIGNER). The MRENCLAVE mode generates a unique key of the security zone, and only the same security zone of the same computer can decrypt the key. The MRSIGNER generates a Sealing key based on the signature key of a developer, and different security areas of the same computer can be decrypted, so long as the MRSIGNER and the developer are the same. The embodiment of the present application will be described by taking the mrencave method as an example.

Step S422: the sealed data is decrypted using a key derived based on the CPU hardware. The decrypted data is stored in the secure area.

Step S423: deserializing the decrypted sealing data, and analyzing the data into a memory form of KeyID-Key pairs. All the information of the KeyID-Key is created by the user call interface and is used for encrypting and decrypting the data of the user.

The process of initializing the local service includes the following 8 steps.

Step S431: the resource EFD of the EPOLL is created at the main thread.

For example, a maximum number of listens may be set to 16.

Step S432: wait for the generation of an event using epoll _ wait.

If no event is generated, the main thread will always block.

Step S433: a communication socket is created at the worker thread.

The family parameter is set to AF _ UNIX, which creates a socket file on the system. Different processes communicate by reading and writing this file.

Step S434: and binding a local socket domain socket, wherein the parameter type is a path of the local type.

The parameters of domain socket are not in the manner of an IP + port, but rather are specified as a local socket-type file path. The communication is not through the network, but the mode of local file, and is safer and more efficient.

Step S435: and monitoring the socket.

This process does not block threads by serving by binding the address of a bind (i.e., the socket file).

Step S436: the snooped FD is set to O _ NONBLOCK mode and registered into the handle EFD of the EPOLL.

Step S437: when a client is connected, the thread (main thread) on which the EPOLL waits receives the Event (EPOLLIN) and generates a callback.

An accept is called in the callback, resulting in an FD waiting to receive data.

A File Descriptor (FD) waiting for data reception is registered in a handle EFD of an EPOLL, and when data is sent by a client, a thread (main thread) waiting for the EPOLL receives an Event (EPOLLIN) and generates a received data callback. In the callback of the received data, all the received data is stored in the cache.

Step S438: and after the message is analyzed, sending the data packet to an application layer for processing.

Compared with the traditional Select mode, the mode of receiving data by the EPOLL has the following advantages:

(1) EPOLLs need to copy FD to kernel only when FD is added, waiting for an event. And the FD is copied to the kernel every time the Select needs to be executed, so that the response time is prolonged.

(2) There is a ready queue in EPOLL, and when an event occurs, the corresponding FD will be moved to the ready queue, while Select does not, so EPOLL mode only needs to check the ready queue, while Select needs to traverse all FDs.

(3) Based on the above principle, EPOLLs theoretically have no limit on the FD that is listened to, and the throughput depends on the response performance of the machine. And Select has an upper FD limit of 1024.

EPOLL has two modes, ET and LT, where ET is an Edge Triggered (Edge Triggered) mode, and when the state changes, a notification is generated to request the service to read all data completely until an error occurs. The LT is a Level Triggered (Level Triggered) mode, which generates a new notification as long as there is data in the cache that has not been processed. The local KMS service in the embodiments of the present application may employ LT mode.

In order for the client to call the local KMS service, a domain socket needs to be established for communicating with the server. And the application layer of the server can respond to the message after receiving the data packet assembled by the domain socket.

Fig. 5 is a flowchart illustrating steps of a key management method in an embodiment of the present application, where the key management method is executed by a terminal device or a server configuring the KMS service, or by both the terminal device and the server. In the embodiment of the present application, a key management method executed on a terminal device is taken as an example for explanation, and as shown in fig. 5, the key management method may mainly include the following steps S510 to S530.

Step S510: and decrypting the sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone established in the memory based on trusted computing.

In one embodiment of the present application, a method of decrypting a sealed data file may include: loading the sealed data file stored in the untrusted area into a secure area of a memory; decrypting ciphertext data in the sealed data file by using a security zone key derived from processor hardware to obtain plaintext data; and performing deserialization processing on the plaintext data obtained by decryption to obtain the key data managed by the user.

Since remote communication transmission between the client process and the local service process is required, plaintext data obtained through decryption in the embodiment of the application is in a byte sequence form, and after deserialization processing, the byte sequence can be restored to a data object form. The embodiment of the application can adopt a protocol buffer (PROTOBUF) format to carry out serialization/deserialization, and conforms to the PB3 grammar.

In one embodiment of the present application, the untrusted area may be a local disk or other storage area in the memory except for a secure area. When the untrusted region is a local disk, the method for loading the sealed data file may include: and reading the sealed data file stored in the local disk into a safe area of the memory. When the untrusted region is a storage region other than the secure region in the memory, the method for loading the sealed data file may include: and reading the sealed data files stored in other storage areas into a safe area of the memory.

Step S520: in response to a received key management request, the key data is traversed to determine whether there is a target key identification that matches the key management request.

According to the method and the device, the key management service can be provided for the client process through the local service process by building the local service response framework and based on inter-process communication. And the data communication between the client process and the server process is realized through a pre-established local socket between the client process and the server process.

In one embodiment of the application, when a client process receives a key management request triggered by a user, the key management request is packaged into a request data packet through the client process; sending the request data packet to a server process through a local socket, wherein the server process is a local service process for providing a Key Management Service (KMS); analyzing the request data packet through the server process to obtain a request key identifier carried in the request data packet; the key data is traversed to determine whether a target key identification identical to the request key identification exists in the key data.

In an embodiment of the present application, before traversing key data to determine whether a target key identifier matching a key management request exists, a request type carried in the key management request may be obtained by parsing the key management request, where the request type includes at least one of a request for creating a key, a request for deleting a key, a request for encrypting data, a request for decrypting data, and a request for re-encrypting data.

In one embodiment of the present application, the format of the request packet is: STX _ C + dwHeadLen + dwBodyLen + Head + Body + ETX _ C.

Here, STX _ C is a fixed head, and may be, for example, 0x2E. ETX _ C is a fixed tail, which may be, for example, 0x36.dwHeadLen is the length of the common header and dwbody len is the length of the message body. Head is the public header, serialized in the PROTOBUF format, following the PB3 syntax. The common header Head in the embodiment of the present application is defined as follows:

the main command number is used for representing the request type of the key management request, and the corresponding relation between the value of the main command number and the request type is as follows:

0x01 Create Key

0x02 delete Key

0x03 encryption

0x04 decryption

0x05 re-encryption

In the embodiment of the application, the value of the main command number is obtained by analyzing the public header Head of the request data packet, so that the request type of the key management request corresponding to the request data packet can be determined.

Body is the message Body, and is serialized with the public header in a PROTOBUF format, and the message Body corresponding to different main command numbers has different contents.

For example, when the master command number is 0x01, the request type is the creation key, and the corresponding Body message format is as follows.

For another example, when the master command number is 0x03, the request type is data encryption, and the corresponding Body message format is as follows.

As can be seen from the above example, the request key identifier key id of the key management request at this time is carried in the packet Body. In an embodiment of the present application, analyzing the request data packet through the server process to obtain the request key identifier carried in the request data packet, may further include: decapsulating the request data packet through a server process to obtain a message main body in the request data packet; and analyzing the message main body to obtain the request key identification carried in the message main body.

Step S530: and generating response data to 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.

In one embodiment of the present application, after returning response data to a sender of a key management request, the method further includes an operation of resealing the data key and releasing the secure area, and the method of resealing the data key includes: carrying out serialization processing on the key data stored in the security zone to obtain plaintext data in a byte sequence form; encrypting plaintext data by using a security zone key derived from processor hardware to obtain ciphertext data; and writing the ciphertext data into the sealed data file stored in the non-trusted area.

FIG. 6 shows a flow chart of the steps of responding to a user's key management request in one embodiment of the present application. Based on the above embodiments, the local KMS may serve as a server process to provide a call interface to one or more client processes at the same time, so as to perform key management in a trusted environment of the memory. As shown in fig. 6, a complete process of responding to a key management request of a user may include the following steps.

Step S601: and the server process loads the sealed data file stored in the untrusted area into a secure area of the memory.

The sealed data file is an encrypted file obtained by sealing key data managed by a user based on trusted computing, and the encrypted file can be decrypted only in a specified security zone. A security zone is a trusted zone created in memory based on trusted computing, and one or more security zones may be created in the memory of a computer device at the same time.

Step S602: and decrypting the ciphertext data in the sealed data file by using a security zone key derived from processor hardware to obtain plaintext data.

Two different data sealing methods, security zone identity Mode (MRENCLAVE) or signer identity Mode (MRSIGNER), can be used based on trusted computing. The security zone identity mode can generate a security zone key for each security zone independently, and in the sealing mode, a sealed data file obtained by sealing in a certain security zone can be decrypted only in the same security zone of the same computer device. The signer identity mode is to generate a common security zone key for each security zone based on the signature key of the developer, and in the sealing mode, the sealed data file packaged in a certain security zone can be decrypted in any security zone of the same computer device.

Step S603: and performing deserialization processing on the plaintext data obtained by decryption to obtain the key data managed by the user.

User-hosted key data is encrypted and packaged in a sealed data file after serialization for persistent, reliable storage in an untrusted region. When the plaintext data is obtained through decryption, deserialization can be performed again, the plaintext data is analyzed into a memory form in which the key identification and the user key are associated in pairs, and then key management can be performed in a security area of the memory.

Step S604: and the client process creates a local socket, binds a local socket file and establishes communication connection with the server process.

Since local sockets do not have the concept of IP and port, in order to implement inter-process communication between a client process and a server process, a local socket file needs to be bound at the client so as to distinguish different clients. In addition, the client process needs to specify a local socket file path of the server process, which is consistent with the local socket file path bound by the server.

Step S605: and the client process sends a request data packet encapsulated with the key management request to the server process through the local socket.

The packet structure of the 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 sequentially concatenated. The public header may carry a request type of the key management request, and the message body may carry a request key identifier of the key management request, and other request data such as a plaintext to be encrypted and a ciphertext to be decrypted.

Step S606: and the server process analyzes the received request data packet to obtain a key management request and a request key identifier carried in the request data packet.

After the parsing process, the request type of the key management request and the request key identifier can be determined. The request types of the key management request may include, for example, a create key request, a delete key request, a data encryption request, a data decryption request, and a data re-encryption request.

Step S607: the key data in the secure zone is traversed to determine whether a target key identification identical to the request key identification exists in the key data.

Step S608: and generating and returning response data to the client process based on the request type of the key management request and the traversal result of the key data.

Step S609: and the server process carries out serialization processing on the key data stored in the security zone to obtain plaintext data in a byte sequence form.

Step S610: and encrypting the plaintext data by using a security zone key derived from processor hardware to obtain ciphertext data.

Step S611: and writing the ciphertext data into the sealed data file stored in the non-trusted area.

After the response process of the key management request is completed once, the sealed data stored in the secure area may be repackaged into a sealed data file, and written into an untrusted area such as the local disk, other than the secure area. And finally, releasing the security zone in the memory and exiting the server process.

The following description is made in conjunction with a plurality of embodiments to respectively respond to a plurality of different types of key management requests.

In one embodiment of the present application, the request type of the key management request is a create key request; the generating of the response data to the key management request according to the traversal result of the key data in step S530 may include: if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, generating response data which causes key creation failure due to repeated key identifiers; and if the traversal result of the key data is that the target key identifier matched with the key management request does not exist in the key data, generating a new created key based on the true random number generator, performing association processing on the new created key and the target key identifier, inserting the new created key and the target key identifier into the key data, and generating response data of successful key creation.

FIG. 7 illustrates a flow of a response to a create key request in one embodiment of the application. As shown in fig. 7, the response flow may include the following steps.

Step S710: the local KMS calls the create key interface of the SGX _ KMS.

The local KMS receives a request to create a key (master command number 0x 01), invokes the services of the SGX _ KMS using the EDL create key interface.

Step S720: and judging whether the target key identification KeyID exists in the key data.

The local existing key identification KeyID is first traversed inside the trusted environment. If the target key identification KeyID already exists, then step S730 is performed; if the target key identification KeyID does not exist, i.e. the target key identification KeyID is a new identification, step S740 is performed.

Step S730: the SGX _ KMS returns response data to the local KMS that results in a Failed key creation (Failed) due to a KeyID repetition error.

Step S740: a new creation key associated with the target key identification is generated. The embodiment of the application can use a hardware-based true random number generator to generate the AES key with 256 bits. Further, the newly created key and the target key identifier KeyID are inserted into the key queue stored in the memory.

Step S750: after the key queue is serialized, encryption is carried out by using a Sealing (Sealing) function, and the encrypted data is stored in a local sealed data file key. The seal data is encrypted based on the MRENCLAVE mode, and can be decrypted only in the local encrypt of the appointed machine, and even if the local ciphertext data is lost, the data leakage can not be caused.

Step S760: the SGX _ KMS returns response data of key creation Success (Success) to the local KMS.

In one embodiment of the present application, the request type of the key management request is a delete key request. The generating of the response data to the key management request according to the traversal result of the key data in step S530 may include: if the traversal result of the key data is that the target key identification matched with the key management request does not exist in the key data, generating response data of successful key deletion; and if the traversal result of the key data is that the target key identification matched with the key management request exists in the key data, clearing the target key identification and the user key associated with the target key identification from the key data, and generating response data with successful key deletion.

FIG. 8 illustrates a flow of a response to a delete key request in one embodiment of the present application. As shown in fig. 8, the response flow may include the following steps.

Step S810: the local KMS calls the delete key interface of the SGX _ KMS.

The local KMS receives a request to delete a key (command word 0x 02), calling the delete key interface of the SGX _ KMS.

Step S820: and judging whether the target key identification KeyID exists in the key data.

The locally existing key identification KeyID is first traversed inside the trusted environment. If the target key identification KeyID does not exist, performing step S830; if the target key identification KeyID exists, step S840 is performed.

Step S830: the SGX _ KMS returns response data to the local KMS that the key deletion was successful.

Step S840: and clearing the target key corresponding to the target key identification KeyID in the memory.

Step S850: the queues of remaining KeyID-Key pairs are serialized. Because the content of the Key is a binary string, which may contain an end symbol of the string, the embodiment of the present application may perform encoding processing on the user Key first, and then serialize the user Key and the corresponding Key identifier KeyID. The encoding method for encoding the user Key may be Base64, for example.

Step S860: the key data queue is encrypted using a Sealing function. The encrypted data is stored in a local keys.

Step S870: the SGX _ KMS returns response data to the local KMS that the key deletion was successful.

In one embodiment of the present application, the request type of the key management request is a data encryption request. The generating of the response data to the key management request according to the traversal result of the key data in step S530 may include: if the traversal result of the key data is that the target key identification matched with the key management request does not exist in the key data, generating response data which causes data encryption failure due to the absence of the key; and if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, encrypting the plaintext data to be encrypted by using a target user key associated with the target key identifier to obtain ciphertext data, and generating response data carrying the target key identifier and the ciphertext data.

FIG. 9 shows a flow of a response to a request for data encryption in one embodiment of the present application. In the embodiment of the application, the CBC mode encryption of AES256 is taken as an example, and the IPP encryption library is based on Intel. As shown in fig. 9, the response flow may include the following steps.

Step S910: the local KMS calls the data encryption interface of the SGX _ KMS.

The local KMS receives a request to encrypt data (command word 0x 03), calling the data encryption interface of the SGX _ KMS.

Step S920: and judging whether the target key identification KeyID exists in the key data.

The local existing key identification KeyID is first traversed inside the trusted environment. If the target key identification KeyID does not exist, step S930 is performed; if the target key identification KeyID exists, step S940 is performed to start the encryption flow.

Step S930: the SGX _ KMS returns response data to the local KMS that resulted in a data encryption failure due to the absence of the key.

Step S940: the context size of AES256 is obtained.

Step S950: AES is initialized, and the Key content of the searched target user Key is set.

Step S960: and randomly generating an initialization vector of 16 bytes, and calling an encryption interface of the AES CBC mode for encryption.

Step S970: and the SGX _ KMS returns response data carrying the target key identification and the ciphertext data to the local KMS. And splicing the target key identification KeyID of 36 bytes, the initialization vector and the ciphertext into a string, adding CRC (cyclic redundancy check) to ensure that data cannot be modified, encoding by base64, and returning to a user.

And finally removing the key and clearing the context data to finish the data encryption process.

In one embodiment of the present application, the request type of the key management request is a data decryption request. The generating of the response data to the key management request according to the traversal result of the key data in step S530 may include: if the traversal result of the key data is that the target key identification matched with the key management request does not exist in the key data, generating response data which causes data decryption failure due to the fact that the key does not exist; and if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, decrypting the ciphertext data to be decrypted by using the target user key associated with the target key identifier to obtain plaintext data, and generating response data carrying the plaintext data.

FIG. 10 shows a flow of responses to a data decryption request in one embodiment of the application. As shown in fig. 10, the response flow may include the following steps.

Step S1010: the local KMS calls the data decryption interface of the SGX _ KMS. The local KMS receives a request to decrypt data (command word 0x 04), calling the data decryption interface of the SGX _ KMS.

Step S1020: and analyzing the ciphertext data. After base64 decoding, the ciphertext data is checked, and the ciphertext data is analyzed after the data is confirmed to be correct to obtain a ciphertext, a target key identifier KeyID and an initialization vector.

Step S1030: and judging whether the target key identification KeyID exists in the key data or not.

Traversing the local existing key identifier KeyID in the trusted environment of the memory, and searching the key content corresponding to the target key identifier KeyID. If the target key identification KeyID does not exist in the key data, step S1040 is performed; if the target key identification KeyID exists in the key data, step S1050 is executed to start the decryption process.

Step S1040: the SGX _ KMS returns response data to the local KMS that resulted in a data decryption failure due to the absence of the key.

Step S1050: the context size of AES256 is obtained.

Step S1060: AES is initialized, and the Key content of the analyzed target user Key is set.

Step S1070: and setting the ciphertext, the encryption context and the initialization vector to a decryption function to obtain decrypted plaintext data.

Step S1080: and after base64 encoding is carried out on the plaintext data, returning response data carrying the plaintext data to the local KMS.

And finally, removing the key and clearing the context data to finish the data decryption process.

In one embodiment of the present 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. The generating of the response data to the key management request according to the traversal result of the key data in step S530 may include: if the traversal result of the key data is that at least one of the first key identification and the second key identification does not exist in the key data, generating response data which causes data re-encryption failure due to the absence of the key; if the traversal result of the key data is that the first key identification and the second key identification exist in the key data, the first key identification is used for decrypting the first ciphertext data to obtain plaintext data, the second key identification is used for encrypting the plaintext data to obtain second ciphertext data, and response data carrying the second key identification and the second ciphertext data are generated.

The re-encryption is mainly used for solving the key rotation scene, and a user finds that an old key is used for too long time and may have unsafe factors, and can newly create a new key to replace the old key. Because the old key has encrypted part of data, the data needs to be decrypted and then re-encrypted by the new key, so that the old key is ensured not to be used and deleted, otherwise, the old data cannot be decrypted.

FIG. 11 illustrates a flow of responses to a request for data re-encryption in one embodiment of the present application. As shown in fig. 11, the response flow may include the following steps.

Step S1110: the local KMS calls the data re-encryption interface of the SGX _ KMS. The local KMS receives a request to re-encrypt data (command word 0x 05), calling the data re-encryption interface of the SGX _ KMS.

Step S1120: and analyzing the ciphertext data. After base64 decoding, the ciphertext data is checked, and after the data is confirmed to be correct, the ciphertext data is analyzed to obtain a ciphertext, a secret key ID and an initialization vector.

Step S1130: and judging whether the target key identification KeyID exists in the key data.

The target key identification includes a first key identification (old key identification) for data decryption and a second key identification (new key identification) for data encryption. And searching the key content corresponding to the old key ID and the new key ID in the trusted environment of the memory. If the target key identification KeyID does not exist in the key data, step S1140 is performed; if the target key identification KeyID exists in the key data, step S1150 is performed, and the re-encryption flow is started.

Step S1140: the SGX _ KMS returns response data to the local KMS that failed the re-encryption of the data due to the absence of the key.

Step S1150: the context size of AES256 is obtained.

Step S1160: after two times of AES initialization, the content of an old Key and the content of a new Key are set, the old Key is used for decrypting data, and the new Key is used for encrypting data.

Step S1170: and setting the ciphertext, the encryption context and the initialization vector to a decryption function to obtain decrypted plaintext data.

Step S1180: and setting the plaintext data to an encryption function, and encrypting the data by using the new Key to obtain a new ciphertext.

Step S1190: and the SGX _ KMS returns response data carrying the new key identification and the new ciphertext data to the local KMS. And splicing the 36-byte key identification KeyID, the initialization vector and the new ciphertext into a string, adding CRC (cyclic redundancy check) to ensure that data cannot be modified, and returning the data to a user after base64 encoding.

And finally, removing the key and clearing the context data to finish the data re-encryption process.

Based on the above embodiments, the present application provides a scheme for implementing local key escrow based on trusted computing, and compared with a scheme using an encryption engine, the scheme using a local CPU to support trusted computing greatly reduces the cost of key escrow. Compared with the prior art of using an encryption machine through a network request, the IPC communication mode based on Domain Socket and EPOLL greatly reduces network delay and improves the use efficiency and the safety.

It should be noted that although the various steps of the methods in this application are depicted in the drawings in a particular order, this does not require or imply that these steps must be performed in this particular order, or that all of the shown steps must be performed, to achieve desirable results. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step execution, and/or one step broken down into multiple step executions, etc.

The following describes embodiments of the apparatus of the present application, which may be used to perform the key management method in the above embodiments of the present application. Fig. 12 schematically shows a block diagram of a key management device according to an embodiment of the present application. As shown in fig. 12, the key management apparatus 1200 may mainly include: a key obtaining module 1210 configured to decrypt a sealed data file in a secure area of a memory to obtain key data hosted by a user, where the key data includes a key identifier and a user key associated with the key identifier, and the secure area is a trusted area created in the memory based on trusted computing; a key matching module 1220 configured to, in response to a received key management request, traverse the key data to determine whether a target key identification matching the key management request exists; a request response module 1230 configured to generate response data to the key management request according to the traversal result of the key data, and return the response data to the sender of the key management request.

In some embodiments of the present application, based on the above embodiments, the key obtaining module 1210 includes: the data loading unit is configured to load the sealed data file stored in the untrusted area into a secure area of the memory; the key decryption unit is configured to decrypt ciphertext data in the sealed data file by using a secure area key derived from processor hardware to obtain plaintext data; and the deserializing unit is configured to deserialize the decrypted plaintext data to obtain the key data hosted by the user.

In some embodiments of the present application, based on the above embodiments, the untrusted region is a local disk or another storage region in the memory except for the secure region; the data loading unit includes: the disk reading subunit is configured to read the sealed data file stored in the local disk into a secure area of a memory; or the memory reading subunit is configured to read the sealed data file stored in the other storage area into a secure area of the memory.

In some embodiments of the present 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 packet by a client process; a request sending unit configured to send the request data packet to a server process through a local socket, where the server process is a local service process providing a key management service KMS; the request analysis unit is configured to analyze the request data packet through the server process to obtain a request key identifier carried in the request data packet; a key traversal unit configured to traverse the key data to determine whether a target key identification identical to the request key identification exists in the key data.

In some embodiments of the present application, based on the above embodiments, the request packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, which are sequentially spliced; the request parsing unit includes: the decapsulation subunit is configured to decapsulate the request data packet by the server process to obtain a message body in the request data packet; and the main body analysis subunit is configured to analyze the message main body to obtain the request key identifier carried in the message main body.

In some embodiments of the present application, based on the above embodiments, the key management apparatus 1200 further includes: the serialization module is configured to perform serialization processing on the key data stored in the security zone to obtain plaintext data in a byte sequence form; the encryption module is configured to encrypt the plaintext data by using a secure area key derived from processor hardware to obtain ciphertext data; and the writing module is configured to write the ciphertext data into the sealed data file stored in the non-trusted area.

In some embodiments of the present application, based on the above embodiments, the key management apparatus 1200 further includes: and the analysis module is configured to analyze the key management request to obtain a request type carried in the key management request, wherein the request type comprises 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.

In some embodiments of the present application, based on the above embodiments, the request type of the key management request is a request for creating a key; the request response module 1230 includes: a first response unit configured to generate response data that causes a key creation failure due to a key identification duplication if a target key identification that matches the key management request exists in the key data as a result of the traversal of the key data; and the key creating unit is configured to generate a new created key based on a true random number generator if the key data does not have a target key identifier matched with the key management request as a result of traversal of the key data, associate the new created key with the target key identifier, insert the new created key into the key data, and generate response data with successful key creation.

In some embodiments of the present application, based on the above embodiments, the request type of the key management request is a delete key request; the request response module 1230 includes: a second response unit configured to generate response data with successful key deletion if the traversal result of the key data indicates that the target key identifier matching the key management request does not exist in the key data; and the key deleting unit is configured to clear the target key identification and the user key associated with the target key identification from the key data and generate response data with successful key deletion if the key data has the target key identification matched with the key management request as a result of the traversal of the key data.

In some embodiments of the present 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 in which data encryption fails due to absence of a key if the traversal result of the key data is that a target key identifier matching the key management request does not exist in the key data; and the data encryption unit is configured to encrypt plaintext data to be encrypted by using a target user key associated with the target key identifier to obtain ciphertext data and generate response data carrying the target key identifier and the ciphertext data if the traversal result of the key data indicates that the target key identifier matched with the key management request exists in the key data.

In some embodiments of the present 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 that causes data decryption failure due to absence of a key if the traversal result of the key data is that a target key identifier matching the key management request does not exist in the key data; and the data decryption unit is configured to decrypt ciphertext data to be decrypted by using a target user key associated with the target key identifier to obtain plaintext data and generate response data carrying the plaintext data if the traversal result of the key data indicates that the target key identifier matched with the key management request exists in the key data.

In some embodiments of the present 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 that causes data re-encryption failure due to absence of a key if a traversal result of the key data is that at least one of the first key identifier and the second key identifier does not exist in the key data; and the data re-encryption unit is configured to decrypt first ciphertext data by using the first key identifier to obtain plaintext data, encrypt the plaintext data by 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 indicates that the first key identifier and the second key identifier exist in the key data.

The specific details of the key management device provided in each embodiment of the present application have been described in detail in the corresponding method embodiment, and are not described herein again.

Fig. 13 schematically shows a structural block diagram of a computer system of an electronic device for implementing the embodiment of the present application.

It should be noted that the computer system 1300 of the electronic device shown in fig. 13 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.

As shown in fig. 13, the computer system 1300 includes a Central Processing Unit (CPU) 1301 that can perform various appropriate actions and processes according to a program stored in a Read-Only Memory (ROM) 1302 or a program loaded from a storage section 1308 into a Random Access Memory (RAM) 1303. In the random access memory 1303, various programs and data necessary for system operation are also stored. The cpu 1301, the rom 1302, and the ram 1303 are connected to each other via a bus 1304. An Input/Output interface 1305 (Input/Output interface, i.e., I/O interface) is also connected to the bus 1304.

The following components are connected to the input/output interface 1305: an input portion 1306 including a keyboard, a mouse, and the like; an output section 1307 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like; a storage portion 1308 including a hard disk and the like; and a communication section 1309 including a network interface card such as a local area network card, modem, or the like. The communication section 1309 performs communication processing via a network such as the internet. The driver 1310 is also connected to the input/output interface 1305 as necessary. A removable medium 1311 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1310 as necessary, so that a computer program read out therefrom is mounted into the storage portion 1308 as necessary.

In particular, according to embodiments of the present application, the processes described in the various method flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated by the flow chart. In such embodiments, the computer program may be downloaded and installed from a network via communications component 1309 and/or installed from removable media 1311. When executed by the central processor 1301, the computer programs perform various functions defined in the system of the present application.

It should be noted that the computer readable media shown in the embodiments of the present application may be computer readable signal media or computer readable storage media or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a Read-Only Memory (ROM), an Erasable Programmable Read-Only Memory (EPROM), a flash Memory, an optical fiber, a portable Compact Disc Read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A key management method, comprising:

decrypting the sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone established in the memory based on trusted computing;

traversing the key data to determine whether a target key identification matching the key management request exists in response to the received key management request;

and generating response data to the key management request according to the traversal result of the key data, and returning the response data to a sender of the key management request.

2. The key management method of claim 1, wherein decrypting the sealed data file in the secure area of the memory to obtain the key data hosted by the user comprises:

loading the sealed data file stored in the untrusted area into a secure area of a memory;

decrypting ciphertext data in the sealed data file by using a security zone key derived from processor hardware to obtain plaintext data;

and performing deserialization processing on the plaintext data obtained by decryption to obtain the key data hosted by the user.

3. The key management method according to claim 2, wherein the untrusted area is a local disk or a storage area in the memory other than the secure area; loading the sealed data file stored in the untrusted area into a secure area of a memory, including:

reading the sealed data file stored in the local disk into a safe area of a memory;

or reading the sealed data file stored in the other storage area into a safe area of the memory.

4. The key management method of claim 1, wherein traversing the key data to determine whether a target key identification matching the key management request exists comprises:

packaging the key management request into a request data packet through a client process;

sending the request data packet to a server process through a local socket, wherein the server process is a local service process for providing a key management service KMS;

analyzing the request data packet through the server process to obtain a request key identifier carried in the request data packet;

the key data is traversed to determine whether a target key identification identical to the request key identification exists in the key data.

5. The key management method according to claim 4, wherein the request packet includes a fixed header, a common header length, a message body length, a common header, a message body, and a fixed trailer, which are sequentially concatenated; analyzing the request data packet through the server process to obtain a request key identifier carried in the request data packet, including:

decapsulating the request data packet through the server process to obtain a message body in the request data packet;

and analyzing the message main body to obtain a request key identifier carried in the message main body.

6. The key management method according to claim 1, wherein after returning the response data to a sender of the key management request, the method further comprises:

carrying out serialization processing on the key data stored in the safety area to obtain plaintext data in a byte sequence form;

encrypting the plaintext data by using a security zone key derived from processor hardware to obtain ciphertext data;

and writing the ciphertext data into the sealed data file stored in the non-trusted area.

7. The key management method of any of claims 1 to 6, wherein prior to traversing the key data to determine whether there is a target key identification matching the key management request, the method further comprises:

and analyzing the key management request to obtain a request type carried in the key management request, wherein the request type comprises 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.

8. The key management method according to claim 7, wherein the request type of the key management request is a create key request; generating response data to the key management request according to the traversal result of the key data, wherein the response data comprises:

if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, generating response data causing key creation failure due to repeated key identifiers;

and if the traversal result of the key data indicates that a target key identifier matched with the key management request does not exist in the key data, generating a new created key based on a true random number generator, performing association processing on the new created key and the target key identifier, inserting the new created key and the target key identifier into the key data, and generating response data of successful key creation.

9. The key management method of claim 7, wherein the request type of the key management request is a delete key request; generating response data to the key management request according to the traversal result of the key data, wherein the response data comprises:

if the traversal result of the key data indicates that the target key identification matched with the key management request does not exist in the key data, generating response data with successfully deleted keys;

and if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, clearing the target key identifier and a user key associated with the target key identifier from the key data, and generating response data with successful key deletion.

10. The key management method according to claim 7, wherein the request type of the key management request is a data encryption request; generating response data to the key management request according to the traversal result of the key data, wherein the response data comprises:

if the traversal result of the key data is that the target key identification matched with the key management request does not exist in the key data, generating response data which causes data encryption failure due to the fact that the key does not exist;

and if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, encrypting plaintext data to be encrypted by using a target user key associated with the target key identifier to obtain ciphertext data, and generating response data carrying the target key identifier and the ciphertext data.

11. The key management method according to claim 7, wherein the request type of the key management request is a data decryption request; generating response data to the key management request according to the traversal result of the key data, wherein the response data comprises:

if the traversal result of the key data is that the target key identification matched with the key management request does not exist in the key data, generating response data which causes data decryption failure due to the absence of the key;

and if the traversal result of the key data is that a target key identifier matched with the key management request exists in the key data, decrypting the ciphertext data to be decrypted by using a target user key associated with the target key identifier to obtain plaintext data, and generating response data carrying the plaintext data.

12. The key management method according to claim 7, wherein 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; generating response data to the key management request according to the traversal result of the key data, wherein the response data comprises:

if the traversal result of the key data indicates that at least one of the first key identifier and the second key identifier does not exist in the key data, generating response data which causes data re-encryption failure due to the absence of the key;

if the traversal result of the key data is that the first key identification and the second key identification exist in the key data, decrypting the first ciphertext data by using the first key identification to obtain plaintext data, encrypting the plaintext data by using the second key identification to obtain second ciphertext data, and generating response data carrying the second key identification and the second ciphertext data.

13. A key management apparatus, comprising:

the key acquisition module is configured to decrypt a sealed data file in a security zone of the memory to obtain key data hosted by a user, wherein the key data comprises a key identifier and a user key associated with the key identifier, and the security zone is a trusted zone created in the memory based on trusted computing;

a key matching module configured to traverse the key data to determine whether a target key identification matching the key management request exists in response to the received key management request;

and the request response module is configured to generate response data to the key management request according to the traversal result of the key data and return the response data to the sender of the key management request.

14. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the key management method of any one of claims 1 to 12.

15. An electronic device, comprising:

a processor; and

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the key management method of any one of claims 1 to 12 via execution of the executable instructions.