WO2018014723A1 - Key management method, apparatus, device and system - Google Patents

Abstract

Disclosed are a key management method, apparatus, device and system, belonging to the technical field of information security. The method comprises: a client generating a temporary key, using a public key provided by a server to encrypt the temporary key so as to obtain a first ciphertext, and sending same to a server; the server using a private key corresponding to the public key to decrypt the first ciphertext so as to obtain the temporary key, acquiring a session key and a key identifier, using the temporary key to encrypt the session key so as to obtain a second ciphertext, and sending same to the client; and the client using the temporary key to decrypt the second ciphertext so as to obtain the session key, wherein the session key is used for encrypting data of a session. According to the invention, on the premise that the security of a key and the efficiency of encryption and decryption are taken into consideration, the complexity in managing the key by a server is also simplified and processing and storage resources of the server are saved.

Description

Key management method, device, device and system

The present application claims priority to Chinese Patent Application No. 201610579122.X, entitled "Key Management Method, Apparatus and System", filed on July 20, 2016, the entire contents of which are incorporated by reference. In this application.

Technical field

The embodiments of the present invention relate to the field of information security technologies, and in particular, to a key management method, apparatus, device, and system.

Background technique

Currently, data encryption methods include Symmetric Cryptography and Asymmetric Cryptography.

Symmetric encryption is a fast and simple way to encrypt. The same key (secret key) is used for encryption and decryption. Symmetric encryption usually uses a relatively small key, typically less than 256 bits (bits). Because the larger the key, the stronger the encryption, but the slower the process of encryption and decryption. The size of the key needs to be balanced against security and efficiency. Typically, AES (Advanced Encryption Standard) uses symmetric encryption, also known as Rijndael encryption in cryptography. In 256 Bytes (bytes), the estimated speed is 900,000 times/second. Symmetric encryption method uses the same key for encryption and decryption. Therefore, the advantage is that the encryption and decryption speed is fast, but the disadvantage is that the communication parties need to agree on the key in advance. If the key is transmitted through the network, the security cannot be guaranteed. .

Asymmetric encryption provides a very secure method for encrypting and decrypting data using a pair of keys, a public key and a private key. The private key can only be safely kept by one party and cannot be leaked, and the public key can be sent to any demander. Asymmetric encryption is usually encrypted using public key and decrypted using a private key. Unlike the symmetric encryption method, security is improved because the private key is not transmitted over the network. Currently, the commonly used asymmetric encryption algorithm is RSA (Rivest Shamir Adleman, a public key encryption algorithm) algorithm. The advantage of asymmetric encryption is that it is highly secure, but its disadvantage is that encryption and decryption are slow. With a 1024-bit key, the estimated decryption speed is 1000-1400. Times/second, depending on the hardware.

Based on this, the data to be transmitted is encrypted and decrypted by symmetric encryption, but the key used in the symmetric encryption mode is transmitted by asymmetric encryption, which ensures that the key used in the symmetric encryption mode is not directly exposed to the network. On top, it ensures the efficiency of encryption and decryption. Specifically, in the related art, the communication party first generates a random number as a symmetric key, encrypts the symmetric key by using the public key provided by the communication peer, and sends the encrypted symmetric key to the communication peer; The communication peer decrypts the encrypted symmetric key by using the private key corresponding to the above public key to obtain a symmetric key. Then, the communication party and the communication peer use the symmetric key to encrypt and decrypt the data transmitted between the two.

Considering the current business scenarios using the C/S (Client/Server, Client/Server) architecture, the number of clients can reach 10 million or even hundreds of millions of days. The number of sessions between the client and the server is quite large. This causes the server to consume a lot of resources to manage symmetric keys.

Summary of the invention

In order to solve the problem that the server in the related art requires a large amount of resources to manage the symmetric key, the embodiment of the present invention provides a key management method, device, device and system. The technical solution is as follows:

In a first aspect, a key management method is provided, the method comprising:

Generate a temporary key;

Encrypting the temporary key by using a public key provided by the server to obtain a first ciphertext;

Sending an authentication request to the server, where the authentication request carries the first ciphertext;

Receiving an authentication response sent by the server, where the authentication response carries a second ciphertext, where the second ciphertext is a ciphertext obtained by encrypting the session key by using the temporary key; wherein the session The key is used to encrypt data of the session;

Decrypting the second ciphertext by using the temporary key to obtain the session key.

In a second aspect, a key management method is provided, the method comprising:

Receiving an authentication request sent by the client, where the authentication request carries the first ciphertext, and the first ciphertext is a ciphertext obtained by encrypting the temporary key by using the public key provided by the local end;

Decrypting the first ciphertext by using a private key corresponding to the public key to obtain the temporary key;

Encrypting the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session;

Sending an authentication response to the client, where the second ciphertext is carried in the authentication response.

In a third aspect, a key management apparatus is provided, the apparatus comprising:

a key generation module, configured to generate a temporary key;

a first encryption module, configured to encrypt the temporary key by using a public key provided by a server to obtain a first ciphertext;

a request sending module, configured to send an authentication request to the server, where the first ciphertext is carried in the authentication request;

The response receiving module is configured to receive an authentication response sent by the server, where the authentication response carries a second ciphertext, and the second ciphertext is a ciphertext obtained by encrypting the session key by using the temporary key. Wherein the session key is used to encrypt data of the session;

The first decryption module is configured to decrypt the second ciphertext by using the temporary key to obtain the session key.

In a fourth aspect, a key management apparatus is provided, the apparatus comprising:

The request receiving module is configured to receive an authentication request sent by the client, where the authentication request carries a first ciphertext, and the first ciphertext is a ciphertext obtained by encrypting the temporary key by using a public key provided by the local end. ;

a second decrypting module, configured to decrypt the first ciphertext by using a private key corresponding to the public key, to obtain the temporary key;

a second encryption module, configured to encrypt the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session;

The response sending module is configured to send an authentication response to the client, where the second ciphertext is carried in the authentication response.

In a fifth aspect, a key management system is provided, the system comprising: a client and a server;

The client includes the key management device as described in the third aspect;

The server includes the key management device as described in the fourth aspect.

According to a sixth aspect, a terminal is provided, where the terminal includes a processor and a memory, where the memory stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program The code set or instruction set is loaded and executed by the processor to implement the key management method as described in the first aspect.

In a seventh aspect, a server is provided, the server comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program The code set or instruction set is loaded and executed by the processor to implement the key management method as described in the second aspect.

According to an eighth aspect, a computer readable storage medium is provided, where the storage medium stores at least one instruction, at least one program, a code set, or a set of instructions, the at least one instruction, the at least one program, and the code The set or set of instructions is loaded and executed by the processor to implement the key management method as described in the first aspect.

According to a ninth aspect, a computer readable storage medium is provided, wherein the storage medium stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program The code set or instruction set is loaded and executed by a processor to implement the key management method as described in the second aspect.

According to a tenth aspect, there is provided a computer program product for performing the key management method of the first aspect described above when the computer program product is executed.

In an eleventh aspect, there is provided a computer program product for performing the key management method of the second aspect described above when the computer program product is executed.

The beneficial effects brought by the technical solutions provided by the embodiments of the present invention include:

The temporary encryption key is encrypted by the client and then sent to the server. After the server decrypts the temporary key, the temporary key is used to encrypt the session key to obtain the second ciphertext, and the second ciphertext is sent to the server. The client decrypts the second ciphertext by using the temporary key to obtain the session key, so that the client encrypts and decrypts the session data by using the session key when the client performs a session with the server. Because the number of sessions between the client and the server is quite large, the server needs to spend a lot of resources to manage the problem of the symmetric key; compared with the related technology, the symmetric data generated by the client directly uses the symmetric key generated by the client to encrypt and decrypt the session data. The embodiment of the present invention uses the session key provided by the server to encrypt and decrypt the session data, so that the server only needs to manage the session key, and does not need to manage the keys generated by a large number of clients, thereby simplifying the server confidentiality. The complexity of the key management and helps save server resources. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

The technical solution provided by the embodiment of the invention simplifies the complexity of managing the key by the server on the premise of balancing the security of the key and the efficiency of the encryption and decryption, and saves the processing and storage resources of the server. Therefore, the key management solution provided by the embodiment of the present invention can be well applied to a large number of high-concurrency service scenarios, such as a C/S architecture business scenario, even if the number of daily activities of the client reaches tens of millions or even hundreds of millions of levels. Even if the number of sessions between the client and the server is quite large, the server can easily and efficiently manage the keys needed for encryption and ensure the security of data transmission between the client and the server. Sex and encryption efficiency.

DRAWINGS

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only some embodiments of the present invention. Other drawings may also be obtained from those of ordinary skill in the art in light of the inventive work.

1 is a schematic diagram of an implementation environment provided by an embodiment of the present invention;

2 is a schematic diagram of an implementation environment provided by another embodiment of the present invention;

3 is a flowchart of a key management method according to an embodiment of the present invention;

4 is a flowchart of a key management method according to another embodiment of the present invention;

FIG. 5 is a flowchart of an authentication phase according to an embodiment of the present invention; FIG.

6 is a flow chart of a data communication phase according to an embodiment of the present invention;

FIG. 7 is a block diagram of a key management apparatus according to an embodiment of the present invention; FIG.

FIG. 8 is a block diagram of a key management apparatus according to another embodiment of the present invention; FIG.

9 is a block diagram of a key management system according to an embodiment of the present invention;

FIG. 10 is a schematic structural diagram of a terminal according to an embodiment of the present invention;

FIG. 11 is a schematic structural diagram of a server according to an embodiment of the present invention.

detailed description

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

Please refer to FIG. 1, which shows a schematic diagram of an implementation environment provided by an embodiment of the present invention. For example, a service scenario of a C/S architecture includes at least one terminal 11 and a server 12.

A running client can be installed in the terminal 11. In the embodiment of the present invention, the type of the client is not limited. For example, the client may be an instant messaging client, a social application client, a payment application client, a video playing client, and the like. The terminal 11 may be an electronic device such as a mobile phone, a tablet computer, an e-book reader, a multimedia playback device, a laptop portable computer, or a desktop computer.

A communication connection can be established between the terminal 11 and the server 12 via a wired network or a wireless network.

The server 12 can be a server or a server cluster composed of multiple servers. Or a cloud computing service center. The server 12 is configured to provide a background service for the client to implement various functions of the client.

In one example, the server 12 is a server cluster composed of a plurality of servers. As shown in FIG. 2, the server 12 includes: an access server 121, a service server 122, an authentication center server 123, and a key management server 124. .

The access server 121 is a medium for data transfer and distribution between the client and the service server 122 and the authentication center server 123. The access server 121 establishes a communication connection with the service server 122, the authentication center server 123, and the key management server 124 via the network, respectively.

The service server 122 is configured to provide business services to clients. In the embodiment of the present invention, the types of services provided by the service server 122 are not limited, such as instant messaging services, social services, payment services, video services, and the like.

The authentication center server 123 is configured to provide an authentication service to the client, and provide the client with a key required for encryption. The authentication center server 123 establishes a communication connection with the key management server 124 via the network.

The key management server 124 is used to manage keys. Alternatively, the authentication center server 123 and the key management server 124 may be two mutually independent servers, or the authentication center server 123 and the key management server 124 may be integrated into one server.

The technical solution provided by the embodiment of the present invention can be applied to any service scenario that needs to encrypt data transmitted between two ends of a communication. In the embodiment of the present invention, the service scenario of the C/S architecture is taken as an example for illustration. However, the embodiments of the present invention do not limit the devices at both ends of the communication. For example, the devices at both ends of the communication may be a terminal and a server running a client, a terminal and a base station, or a server and a server, and the like.

Please refer to FIG. 3, which shows a flowchart of a key management method provided by an embodiment of the present invention. This method can be applied to the implementation environment shown in FIG. The method can include the following steps.

In step 301, the client generates a temporary key.

Step 302: The client encrypts the temporary key by using a public key provided by the server to obtain a first ciphertext.

Step 303: The client sends an authentication request to the server, where the first ciphertext is carried in the authentication request.

Accordingly, the server receives an authentication request sent by the client.

Step 304: The server decrypts the first ciphertext by using a private key corresponding to the public key to obtain a temporary key.

Step 305: The server encrypts the session key by using a temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session.

Step 306: The server sends an authentication response to the client, where the authentication response carries the second ciphertext.

Accordingly, the client receives an authentication response sent by the server.

Optionally, the authentication response further carries a key identifier, where the key identifier is used to identify the session key. In a possible implementation manner, the key identifier carried in the authentication response is not encrypted by using a temporary key; in another possible implementation manner, the key identifier carried in the authentication response also uses a temporary key. encryption. In the case where there are multiple session keys managed in the server, different session keys can be distinguished by using the key identifier.

Step 307: The client decrypts the second ciphertext by using a temporary key to obtain a session key.

Optionally, if the authentication response further carries an unencrypted key identifier, the client directly reads the key identifier from the authentication response; if the authentication response further carries the encrypted key identifier, the client The encrypted key identifier is decrypted by using a temporary key to obtain a key identifier.

In summary, the method provided in this embodiment encrypts the temporary key by using the asymmetric encryption method and sends the temporary key to the server. After the server decrypts the temporary key, the temporary key is used to encrypt the session key. The second ciphertext is sent to the client, and the client decrypts the second ciphertext by using the temporary key to obtain the session key, so that the client subsequently uses the session key pair when performing a session with the server. The data of the session is encrypted and decrypted; the problem that the server needs to consume a large amount of resources to manage the symmetric key due to the relatively large number of sessions between the client and the server in the related art is solved; compared with the related technology, the client directly adopts The generated symmetric key encrypts and decrypts the data of the session. In the embodiment of the present invention, the session key provided by the server is used to encrypt and decrypt the session data, so that the server only needs to manage the session key, and does not need to generate a large number of clients. Key management, which simplifies the complexity of server management of keys and helps save service resource of. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

The technical solution provided by the embodiment of the invention simplifies the complexity of managing the key by the server on the premise of balancing the security of the key and the efficiency of the encryption and decryption, and saves the processing and storage resources of the server. Therefore, the key management solution provided by the embodiment of the present invention can be well applied to a large number of high-concurrency service scenarios, such as a C/S architecture business scenario, even if the number of daily activities of the client reaches tens of millions or even hundreds of millions of levels. Even if the number of sessions between the client and the server is quite large, the server can easily and efficiently manage the keys needed for encryption and ensure the security and encryption and decryption efficiency of data transmission between the client and the server.

In the embodiment of the present invention, a session refers to a communication interaction between two devices during a specific operation time that is not interrupted. During a session, all packets transmitted between two devices belong to the session. In an example, taking the business scenario of the C/S architecture as an example, the session may be a “call process” between the client and the server, and a complete request and reply process.

Please refer to FIG. 4, which is a flowchart of a key management method according to another embodiment of the present invention. This method can be applied to the implementation environment shown in FIG. The method can include the following steps.

In step 401, the client generates a temporary key.

In one example, a temporary key is generated using a random number generator. The temporary key is a symmetric key.

It should be noted that, in the embodiment of the present invention, the temporary key is not used to encrypt and decrypt the data of the session, and the temporary key is only used to encrypt and decrypt the session key, and the session key is actually used. The key used to encrypt and decrypt the data of the session.

Step 402: The client encrypts the temporary key by using a public key provided by the server to obtain a first ciphertext.

The public key is pre-delivered to the client by the server. In one example, the server writes the public key to a binary file that carries the digital signature of the development company corresponding to the client, and the server sends the binary file with the digital signature to the client to ensure that the file is not It has been tampered with and forged to ensure the safe issuance of public keys. Alternatively, the public key may be updated with the update of the binary file, and after the server enables the new public key, the binary file with the new public key may be resent to the client.

After the client generates the temporary key, the temporary key is encrypted by using the public key provided by the server according to the asymmetric encryption method to obtain the first ciphertext.

Step 403: The client sends an authentication request to the server, where the first ciphertext is carried in the authentication request.

The authentication request is used to request the server to authenticate the client, and allocate the key required for encrypting the session data to the client if the authentication is passed.

Accordingly, the server receives an authentication request sent by the client.

In addition, since the temporary key is encrypted by using the public key provided by the server, even if the authentication request is intercepted by the malicious user, since the private key corresponding to the public key is not available, the first ciphertext cannot be decrypted. A temporary key is issued. Therefore, the security of the temporary key can be guaranteed, so that the security of the session key transmitted later can also be guaranteed.

Step 404: The server decrypts the first ciphertext by using a private key corresponding to the public key to obtain a temporary key.

After receiving the authentication request, the server adopts the private key corresponding to the public key according to the asymmetric encryption method. The key decrypts the first ciphertext to obtain a temporary key.

In step 405, the server acquires a session key and a key identifier.

The key identifier is used to identify the session key, and the session key is used to encrypt the data of the session. The session key is a symmetric key. Optionally, the session key is a contiguous stream of bytes, typically an integer multiple of 128 bits, generated by a random number generator. The key identifier is used to uniquely identify the session key. Different sessions can use the same key identifier. Different key identifiers correspond to different session keys. Optionally, the key identifier is a 64-bit integer.

In one example, the server generates a session key using a random number generator and generates a key identification corresponding to the session key. In addition, the server corresponds to the storage session key and the key identifier.

In another example, the server picks a set of corresponding session keys and key identities from the pre-stored keys. The pre-stored key includes at least one set of corresponding session key and key identifier. The pre-stored key is pre-generated and stored by the server. The pre-stored key can be stored in the server's Cache (cache) or it can be stored in a target file. In one example, the pre-stored key is stored both in the Cache and backed up in the target file to facilitate backup in the event of a Cache failure.

There is a one-to-one correspondence between the key identifier and the session key. Optionally, each session key has a corresponding validity period, and the session key is valid within the validity period, otherwise the session key is invalid. The validity period of the session key can be set correspondingly when the session key is generated. For different session keys, the duration of the validity period is usually the same, but it may be different. This embodiment does not limit this. In addition, in this embodiment, the validity time of the validity period of the session key is not limited. For example, the validity period of the session key may be effective when the session key is generated, or when the server sends the session key to the client. Effective at the beginning, or when the client receives the session key.

The client encrypts and decrypts the session data using the session key of the valid state (that is, the expiration date is not exceeded). After the session key is invalidated (that is, the validity period is exceeded), the client can request a new valid session key from the server. . Therefore, the execution timing of the above step 403 may be when the existing session key has expired, or when the client needs to initiate a session to the server and the existing session key has expired. If the existing session key has not expired, the client can use the existing session key to encrypt and decrypt the session data without re-requesting the new session key from the server.

Optionally, the server selects a corresponding set of session keys and key identifiers from the pre-stored keys, and may include the following sub-steps:

1. The server obtains an IP (Internet Protocol) address corresponding to the client;

For example, the server parses the data packet of the authentication request sent by the client, and parses and obtains the IP address corresponding to the client from the packet header.

2. The server determines a key selection range according to the IP address, and the key selection range includes a corresponding session key and a key identifier of the pre-stored key;

The server may segment the pre-stored key, and the server divides the pre-stored key into multiple segments, each segment including a part of the corresponding session key and key identifier. For example, the server calculates a hash value of the IP address corresponding to the client, and maps the data to a certain pre-stored key according to the hash value, where the pre-stored key is the key selection range. For another example, the server may also randomly select a pre-stored key from the pre-stored key after segmentation, and the selected pre-stored key of the segment is the key selection range.

3. The server selects a corresponding set of session keys and key identifiers from the key selection range.

In this way, it is possible to prevent the server from being dragged, because the session key that can be obtained by the same IP address is a fixed range, not all pre-stored keys.

It should be noted that, in this embodiment, only a plurality of session keys are managed in the server for description, so the server also needs to generate a key identifier corresponding to the session key, so as to distinguish different session keys. . If only one session key is managed in the server, there is no need to generate a key identifier. In addition, managing multiple session keys is relatively more secure than managing only one session key.

Step 406: The server encrypts the session key by using a temporary key to obtain a second ciphertext.

The server encrypts the session key by using a temporary key according to a symmetric encryption method to obtain a second ciphertext.

Optionally, the server further encrypts the key identifier by using a temporary key, and obtains the encrypted key identifier.

Step 407: The server sends an authentication response to the client, where the authentication response carries the second ciphertext and the key identifier.

Accordingly, the client receives an authentication response sent by the server. The key identifier carried in the authentication response may be an unencrypted key identifier or an encrypted key identifier.

Optionally, after receiving the authentication request sent by the client, the server may further perform the following steps: the server obtains a GUID (Globally Unique Identifier) corresponding to the device where the client is located, and obtains an authentication request corresponding to the GUID. The number of times; determining whether the number of authentication requests is greater than a preset threshold; if the number of authentication requests is greater than a preset threshold, refusing to respond to the authentication request; if the number of authentication requests is less than a preset threshold, responding to the authentication request, for example, performing The above steps 404 to 407. The GUID corresponding to the device where the client is located can be parsed and obtained from the packet header of the data packet of the authentication request. In the above manner, the number of authentication requests of the same GUID is limited, and the server can be effectively prevented when the server is subjected to frequent malicious attacks.

Step 408: The client decrypts the second ciphertext by using a temporary key to obtain a session key.

After receiving the authentication response, the client decrypts the second ciphertext by using the temporary key according to the symmetric encryption method to obtain the session key. After that, the client uses the session key to symmetrically encrypt the communication content with the server. During the subsequent session between the client and the server, the client encrypts and decrypts the data of the session transmitted between the server by using the session key, and the server uses the session key to add the data of the session transmitted between the client and the client. Decrypt.

Optionally, if the authentication response further carries an unencrypted key identifier, the client directly reads the key identifier from the authentication response; if the authentication response further carries the encrypted key identifier, the client The encrypted key identifier is decrypted by using a temporary key to obtain a key identifier.

The following describes and describes the flow of the data communication phase between the client and the server. Steps 409 to 411 are uplink transmission procedures, and steps 412 to 414 are downlink transmission procedures.

Step 409: The client encrypts the uplink data of the session by using the session key, and obtains the encrypted uplink data.

The uplink data refers to the data transmitted by the client to the server.

In step 410, the client sends an uplink data packet to the server.

The packet header of the uplink data packet carries the key identifier, and the packet body of the uplink data packet carries the encrypted uplink data. Optionally, if the client does not receive the key identifier, the packet identifier of the uplink data packet does not carry the key identifier.

Correspondingly, the server receives the uplink data packet sent by the client.

In step 411, the server decrypts the encrypted uplink data by using the session key corresponding to the key identifier carried in the packet header to obtain uplink data.

After receiving the uplink data packet, the server queries the pre-stored key to obtain the session key corresponding to the key identifier carried in the packet header of the uplink data packet, and then encrypts the session key pair according to the symmetric encryption mode. After the uplink data is decrypted, the uplink data is obtained.

Optionally, the server may further verify the validity period of the queried session key before performing the decryption operation, and if the expiration date has expired, the process ends, and if the validity period is not exceeded, the decryption operation is performed.

Step 412: The server encrypts the downlink data of the session by using the session key, and obtains the encrypted downlink data.

Downstream data refers to the data that the server transmits to the client.

In step 413, the server sends a downlink data packet to the client.

The packet header of the downlink data packet carries the key identifier, and the packet body of the downlink data packet carries the encrypted downlink number. according to. Optionally, if only one session key is managed in the server, it is not necessary to generate a key identifier, and the key identifier of the downlink data packet does not carry the key identifier.

Correspondingly, the client receives the downlink data packet sent by the server.

Step 414: The client decrypts the encrypted downlink data by using a session key corresponding to the key identifier carried in the packet header to obtain downlink data.

After receiving the downlink data packet, the client obtains the session key corresponding to the key identifier carried in the packet header of the downlink data packet, and then uses the queried session key pair to encrypt the downlink data according to the symmetric encryption mode. Decrypt, get the downlink data.

It should be added that the server can also obtain an initialization vector (Init Vector, IV) corresponding to the session key, and send the initialization vector to the client. This initialization vector is used by the client for symmetric encryption and decryption using the session key. Accordingly, the client receives an initialization vector sent by the server. For example, the authentication response sent by the server to the client also carries an initialization vector. The initialization vector may be sent by using a temporary key or may not be encrypted. This embodiment does not limit this. The initialization vector can be generated by the server using a random number generator to generate a random number, and combined with the random number and the session key. During use, the initialization vector can be dynamically changed according to the relevant algorithm. Optionally, the initialization vector is a 12 byte byte stream. In the above manner, the same session key must be used together with the corresponding initialization vector to complete the decryption, so as to achieve further optimization and reinforcement.

In summary, the method provided in this embodiment encrypts the temporary key by using the asymmetric encryption method and sends the temporary key to the server. After the server decrypts the temporary key, the temporary key is used to encrypt the session key. The second ciphertext is sent to the client, and the client decrypts the second ciphertext by using the temporary key to obtain the session key, so that the client subsequently uses the session key pair when performing a session with the server. The data of the session is encrypted and decrypted; the problem that the server needs to consume a large amount of resources to manage the symmetric key due to the relatively large number of sessions between the client and the server in the related art is solved; compared with the related technology, the client directly adopts The generated symmetric key encrypts and decrypts the data of the session. In the embodiment of the present invention, the session key provided by the server is used to encrypt and decrypt the session data, so that the server only needs to manage the session key, and does not need to generate a large number of clients. Key management, which simplifies the complexity of server management of keys and helps save service resource of. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

In addition, by setting the corresponding validity period for the session key, even if the session key is not expired, the client can use the session key to encrypt and decrypt the session data, A new session key needs to be re-requested from the server to save processing overhead and communication resources of the device and server where the client is located.

It is also necessary to add that the speed of decryption using the asymmetric encryption algorithm is slower, and the decryption speed is usually about 2200 times/second in a single thread. Therefore, multi-thread parallel decryption can be used to make the server not When a lot of machines are put into use, it does not become a system bottleneck. In addition, if OpenSLL (Open Secure Sockets Layer) library is used, since the OpenSLL library is not multi-thread safe, only one thread can complete the decryption work in a service process. To multi-thread parallel, it needs to run more. Processes, which have a large impact on development and release, are not convenient to maintain. In the embodiment of the present invention, code adjustment is performed on the rsa function api of the OpenSLL library, so as to implement the step of separating the multi-thread unsafe, and placing it in a safe place, and the remaining security steps can be located in the multi-thread environment. Thereby achieving the requirement of multi-threaded parallel decryption.

In the foregoing method embodiment, the step on the client side can be separately implemented as a key management method on the client side, and the steps on the server side can be separately implemented as a key management method on the server side.

The technical solutions provided by the embodiments of the present invention are described and illustrated in the following with reference to the application scenarios shown in FIG.

Figure 5 shows a flow chart of the authentication phase. As shown in FIG. 5, the authentication phase may include the following steps.

In step 501, the client generates a temporary key.

Step 502: The client encrypts the temporary key by using the public key provided by the authentication center server to obtain the first key.

Step 503: The client sends an authentication request to the access server, where the first ciphertext is carried in the authentication request.

Correspondingly, the access server receives an authentication request sent by the client.

Step 504: The access server forwards the authentication request to the authentication center server.

Correspondingly, the authentication center server receives the authentication request sent by the access server.

Step 505: The authentication center server decrypts the first ciphertext by using a private key corresponding to the public key to obtain a temporary key.

Step 506: The authentication center server acquires a session key and a key identifier.

The key identifier is used to identify the session key, and the session key is used to encrypt the data of the session.

In one example, step 506 includes the following sub-steps:

Step 506a: The authentication center server generates a session key by using a random number generator.

Step 506b: The authentication center server sends a session key to the key management server.

Correspondingly, the key management server receives the session key sent by the authentication center server;

Step 506c: The key management server generates a key identifier corresponding to the session key.

Step 506d, the key management server correspondingly stores the key identifier and the session key;

Step 506e: The key management server sends a key identifier to the authentication center server.

Correspondingly, the authentication center server receives the key identifier sent by the key management server.

In another example, step 506 includes the following sub-steps:

In step 506f, the authentication center server selects a corresponding set of session keys and key identifiers from the pre-stored keys.

The pre-stored key includes at least one set of corresponding session key and key identifier. The pre-stored key can be pre-generated by the key management server and provided to the authentication center server. For example, the key management server writes the pre-stored key into the target file and sends the target file to the authentication center server. After the authentication center server is started, the pre-stored key in the target file is loaded into the memory, and a corresponding set of session key and key identifier are randomly selected from each time.

In step 507, the authentication center server encrypts the session key by using a temporary key to obtain a second ciphertext.

Step 508: The authentication center server sends an authentication response to the access server, where the authentication response carries the second ciphertext and the key identifier.

Correspondingly, the access server receives the authentication response sent by the authentication center server.

The key identifier carried in the authentication response may be an unencrypted key identifier or an encrypted key identifier.

In step 509, the access server forwards the authentication response to the client.

Correspondingly, the client receives an authentication response sent by the access server.

Step 510: The client decrypts the second ciphertext by using a temporary key to obtain a session key.

Figure 6 shows a flow chart of the data communication phase. As shown in FIG. 6, the data communication phase can include the following steps.

Step 601: The client encrypts the uplink data of the session by using the session key, and obtains the encrypted uplink data.

Step 602: The client sends an uplink data packet to the access server.

The packet header of the uplink data packet carries the key identifier, and the packet body of the uplink data packet carries the encrypted uplink number. according to.

Correspondingly, the access server receives the uplink data packet sent by the client.

Step 603: The access server queries to obtain a session key corresponding to the key identifier carried in the packet header.

In one example, step 603 includes the following sub-steps:

Step 603a: The access server queries, from the local cache, the session key corresponding to the key identifier carried in the packet header.

For example, the access server obtains a preset key from the key management server in advance and stores it in the local cache.

In another example, step 603 includes the following sub-steps:

Step 603b: The access server sends a query request to the key management server, where the query request carries the key identifier carried in the packet header.

Correspondingly, the key management server receives the query request sent by the access server;

Step 603c: The key management server queries, by using a preset key, a session key corresponding to the key identifier carried in the query request.

Step 603d: The key management server sends a query response to the access server, where the query response carries the session key obtained by the query;

Accordingly, the access server receives the query response sent by the key management server.

Step 604: The access server decrypts the encrypted uplink data by using the session key obtained by the query to obtain uplink data.

Step 605: The access server sends uplink data to the service server.

Correspondingly, the service server receives the uplink data sent by the access server.

In one example, the access server sends the clear text of the uplink data to the service server. In another example, the access server encrypts the uplink data and sends it to the service server by using an encryption method and a key that are negotiated in advance with the service server.

After receiving the uplink data, the service server processes the uplink data and feeds back the packet to the client if necessary.

Step 606: The service server sends downlink data to the access server.

Correspondingly, the access server receives downlink data sent by the service server.

In one example, the service server sends the clear text of the downlink data to the access server. In another example, the service server adopts an encryption method and a key that are pre-negotiated with the access server, and the number of downlinks is used. After being encrypted, it is sent to the access server.

Step 607: The access server encrypts the downlink data by using the session key obtained by the query, and obtains the encrypted downlink data.

Step 608: The access server sends a downlink data packet to the client.

The packet header of the downlink data packet carries the key identifier, and the packet body of the downlink data packet carries the encrypted downlink data.

Correspondingly, the client receives the downlink data packet sent by the access server.

Step 609: The client decrypts the encrypted downlink data by using a session key corresponding to the key identifier carried in the packet header to obtain downlink data.

The following is an embodiment of the apparatus of the present invention, which can be used to carry out the method embodiments of the present invention. For details not disclosed in the embodiment of the device of the present invention, please refer to the method embodiment of the present invention.

Please refer to FIG. 7, which shows a block diagram of a key management apparatus according to an embodiment of the present invention. The device has a function of implementing the above-mentioned client side key management method, and the function may be implemented by hardware or by executing corresponding software by hardware. The apparatus may include a key generation module 710, a first encryption module 720, a request transmission module 730, a response receiving module 740, and a first decryption module 750.

The key generation module 710 is configured to generate a temporary key.

The first encryption module 720 is configured to encrypt the temporary key by using a public key provided by the server to obtain a first ciphertext.

The request sending module 730 is configured to send an authentication request to the server, where the first ciphertext is carried in the authentication request.

The response receiving module 740 is configured to receive an authentication response sent by the server, where the authentication response carries a second ciphertext, and the second ciphertext is a secret obtained by encrypting the session key by using the temporary key. Text. The session key is used to encrypt data of the session.

The first decryption module 750 is configured to decrypt the second ciphertext by using the temporary key to obtain the session key.

In summary, the device provided in this embodiment encrypts the temporary key by using the asymmetric encryption method and sends the temporary ciphertext to the server, and receives the second ciphertext obtained by encrypting the session key by using the temporary key. The temporary cipher is used to decrypt the second ciphertext to obtain the session key, so that the client can encrypt and decrypt the session data by using the session key when the client performs a session with the server. The related technology is solved by the client and the client. The number of sessions between servers is quite large, causing the server to consume A large amount of resources are used to manage the problem of the symmetric key; the session data is encrypted and decrypted by the symmetric key generated by the client, and the session key provided by the server is used for the session. The data is encrypted and decrypted, so that the server only needs to manage the session key, and does not need to manage the keys generated by a large number of clients, thereby simplifying the complexity of managing the keys by the server and saving the resources of the server. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

Please refer to FIG. 8, which is a block diagram of a key management apparatus according to another embodiment of the present invention. The device has a function of implementing the above-mentioned server-side key management method, and the function may be implemented by hardware or by executing corresponding software by hardware. The apparatus may include a request receiving module 810, a second decryption module 820, a second encryption module 840, and a response sending module 850.

The request receiving module 810 is configured to receive an authentication request sent by the client, where the authentication request carries the first ciphertext, and the first ciphertext is a secret obtained by encrypting the temporary key by using the public key provided by the local end. Text.

The second decryption module 820 is configured to decrypt the first ciphertext by using a private key corresponding to the public key to obtain the temporary key.

The second encryption module 840 is configured to encrypt the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session.

The response sending module 850 is configured to send an authentication response to the client, where the second ciphertext is carried in the authentication response.

In summary, the device provided in this embodiment encrypts the temporary key by using the asymmetric encryption method and sends the temporary key to the server. After the server decrypts the temporary key, the temporary key is used to encrypt the session key. Two ciphertexts, and the second ciphertext is sent to the client, so that the client subsequently encrypts and decrypts the session data by using the session key when the client performs a session with the server; the related technology is solved by the client and the server. The number of sessions is quite large, which causes the server to use a large amount of resources to manage the problem of the symmetric key. The data of the session is encrypted and decrypted by using the symmetric key generated by the client. The session key provided by the server encrypts and decrypts the data of the session, so that the server only needs to manage the session key, and does not need to manage the keys generated by a large number of clients, thereby simplifying the complexity of managing the keys by the server. And help save server resources. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

Please refer to FIG. 9, which shows a block diagram of a key management system provided by an embodiment of the present invention. The system includes a client 700 and a server 800.

Client 700 can include a key management device. The device has a function of implementing the above-mentioned client side key management method, and the function may be implemented by hardware or by executing corresponding software by hardware. The apparatus may include a key generation module 710, a first encryption module 720, a request transmission module 730, a response receiving module 740, and a first decryption module 750.

The key generation module 710 is configured to generate a temporary key.

The first encryption module 720 is configured to encrypt the temporary key by using a public key provided by the server 800 to obtain a first ciphertext.

The request sending module 730 is configured to send an authentication request to the server 800, where the first ciphertext is carried in the authentication request.

The response receiving module 740 is configured to receive an authentication response sent by the server 800, where the authentication response carries a second ciphertext, where the second ciphertext is encrypted by using the temporary key to encrypt the session key. Cipher text. The session key is used to encrypt data of the session.

The first decryption module 750 is configured to decrypt the second ciphertext by using the temporary key to obtain the session key.

Optionally, the authentication response further carries a key identifier, where the key identifier is used to identify the session key.

Optionally, the device further includes: an uplink data encryption module 762 and an uplink data sending module 764.

The uplink data encryption module 762 is configured to encrypt the uplink data of the session by using the session key to obtain encrypted uplink data.

The uplink data sending module 764 is configured to send an uplink data packet to the server 800, where a packet header of the uplink data packet carries the key identifier, and a packet of the uplink data packet carries the encrypted uplink data.

Optionally, the device further includes: a downlink data receiving module 766 and a downlink data decrypting module 768.

The downlink data receiving module 766 is configured to receive the downlink data packet sent by the server 800, where the packet header of the downlink data packet carries the key identifier, and the packet body of the downlink data packet carries the encrypted downlink data.

The downlink data decryption module 768 is configured to decrypt the encrypted downlink data by using a session key corresponding to the key identifier carried in the packet header to obtain downlink data.

In one example, the key generation module 710 is configured to generate the temporary key by using a random number generator.

Optionally, the device further includes: a vector receiving module 770.

The vector receiving module 770 is configured to receive an initialization vector that is sent by the server 800 and that is corresponding to the session key, where the initialization vector is used when the local end uses the session key for symmetric encryption and decryption.

Server 800 can include a key management device. The device has a function of implementing the above-mentioned server-side key management method, and the function may be implemented by hardware or by executing corresponding software by hardware. The apparatus may include a request receiving module 810, a second decryption module 820, a second encryption module 840, and a response sending module 850.

The request receiving module 810 is configured to receive an authentication request sent by the client 700, where the authentication request carries the first ciphertext, and the first ciphertext is obtained by encrypting the temporary key by using the public key provided by the local end. Cipher text.

The second decryption module 820 is configured to decrypt the first ciphertext by using a private key corresponding to the public key to obtain the temporary key.

The second encryption module 840 is configured to encrypt the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session.

The response sending module 850 is configured to send an authentication response to the client 700, where the second ciphertext is carried in the authentication response.

Optionally, the authentication response further carries a key identifier, where the key identifier is used to identify the session key.

Optionally, the device further includes: a key acquisition module 830.

The key obtaining module 830 is configured to acquire a session key and a key identifier.

In an example, the key obtaining module 830 is configured to generate the session key by using a random number generator to generate a key identifier corresponding to the session key.

In another example, the key obtaining module 830 is configured to select a corresponding set of session keys and key identifiers from the pre-stored keys. The pre-stored key includes at least one set of corresponding session key and key identifier.

Optionally, the key obtaining module 830 includes: an address obtaining unit, a range determining unit, and Key selection unit.

An address obtaining unit is configured to obtain an IP address corresponding to the client 700.

a range determining unit, configured to determine a key selection range according to the IP address, where the key selection range includes a part of the session key and a key identifier corresponding to the pre-stored key.

The key selection unit is configured to select a corresponding set of session keys and key identifiers from the key selection range.

Optionally, the device further includes: an uplink data receiving module 862 and an uplink data decrypting module 864.

The uplink data receiving module 862 is configured to receive the uplink data packet sent by the client 700, where the packet header of the uplink data packet carries the key identifier, and the packet of the uplink data packet carries the encrypted uplink data.

The uplink data decryption module 864 is configured to decrypt the encrypted uplink data by using a session key corresponding to the key identifier carried in the packet header to obtain uplink data.

Optionally, the device further includes: a downlink data encryption module 866 and a downlink data sending module 868.

The downlink data encryption module 866 is configured to encrypt the downlink data of the session by using the session key to obtain encrypted downlink data.

The downlink data sending module 868 is configured to send a downlink data packet to the client 700, where a packet header of the downlink data packet carries the key identifier, and a packet of the downlink data packet carries the encrypted downlink data.

Optionally, the device further includes: an identifier obtaining module 812 and a number obtaining module 814.

The identifier obtaining module 812 is configured to obtain a GUID corresponding to the device where the client 700 is located.

The number obtaining module 814 is configured to acquire the number of authentication requests corresponding to the GUID.

The second decryption module 820 is further configured to: when the number of the authentication requests is less than a preset threshold, decrypt the first ciphertext by using a private key corresponding to the public key to obtain the temporary key.

Optionally, the device further includes: a vector obtaining module 870 and a vector sending module 880.

The vector acquisition module 870 is configured to acquire an initialization vector corresponding to the session key.

The vector sending module 880 is configured to send the initialization vector to the client 700, where the initialization vector is used when the client 700 performs symmetric encryption and decryption using the session key.

In summary, the system provided in this embodiment encrypts the temporary key by using the asymmetric encryption method and sends the temporary key to the server. After the server decrypts the temporary key, the temporary key pair is used. The session key is encrypted to obtain the second ciphertext, and the second ciphertext is sent to the client, and the client decrypts the second ciphertext by using the temporary key to obtain the session key, so that the client subsequently performs a session with the server. The session key is used to encrypt and decrypt the session data; the related art has a problem that the server needs to spend a large amount of resources to manage the symmetric key due to the relatively large number of sessions between the client and the server; The technology directly encrypts and decrypts the data of the session by using the symmetric key generated by the client. In the embodiment of the present invention, the session key provided by the server is used to encrypt and decrypt the session data, so that the server only needs to manage the session key. There is no need to manage a large number of client-generated keys, which simplifies the complexity of managing keys by the server and helps save server resources. Moreover, since the session key is not directly transmitted in the plaintext on the network, it is encrypted by using a temporary key, so security is also guaranteed.

It should be noted that, when the device provided by the foregoing embodiment implements its function, only the division of each functional module described above is illustrated. In an actual application, the function distribution may be completed by different functional modules according to requirements, that is, the device is required. The internal structure is divided into different functional modules to perform all or part of the functions described above. In addition, the apparatus and method embodiments provided in the foregoing embodiments are in the same concept, and the specific implementation process is described in detail in the method embodiment, and details are not described herein again.

Please refer to FIG. 10, which is a schematic structural diagram of a terminal according to an embodiment of the present invention. The terminal is used to implement the client side key management method provided in the foregoing embodiment. Specifically:

The terminal 1000 may include an RF (Radio Frequency) circuit 1010, a memory 1020 including one or more computer readable storage media, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, and a WiFi (wireless fidelity, wireless). The fidelity module 1070 includes a processor 1080 having one or more processing cores, and a power supply 1090 and the like. It will be understood by those skilled in the art that the terminal structure shown in FIG. 10 does not constitute a limitation to the terminal, and may include more or less components than those illustrated, or combine some components, or different component arrangements. among them:

The RF circuit 1010 can be used for receiving and transmitting signals during and after receiving or transmitting information, in particular, receiving downlink information of the base station and then processing it by one or more processors 1080; in addition, transmitting data related to the uplink to the base station . Generally, the RF circuit 1010 includes, but is not limited to, an antenna, at least one amplifier, a tuner, one or more oscillators, a Subscriber Identity Module (SIM) card, a transceiver, a coupler, an LNA (Low Noise Amplifier). , duplexer, etc. In addition, The RF circuit 1010 can also communicate with the network and other devices via wireless communication. The wireless communication may use any communication standard or protocol, including but not limited to GSM (Global System of Mobile communication), GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access). , Code Division Multiple Access), WCDMA (Wideband Code Division Multiple Access), LTE (Long Term Evolution), e-mail, SMS (Short Messaging Service), and the like.

The memory 1020 can be used to store software programs and modules, and the processor 1080 executes various functional applications and data processing by running software programs and modules stored in the memory 1020. The memory 1020 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application required for at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may be stored according to The data created by the use of the terminal 1000 (such as audio data, phone book, etc.) and the like. Moreover, memory 1020 can include high speed random access memory, and can also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, memory 1020 can also include a memory controller to provide access to memory 1020 by processor 1080 and input unit 1030.

Input unit 1030 can be used to receive input numeric or character information, as well as to generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function controls. Specifically, the input unit 1030 may include an image input device 1031 and other input devices 1032. The image input device 1031 may be a camera or an optical scanning device. In addition to the image input device 1031, the input unit 1030 may also include other input devices 1032. Specifically, other input devices 1032 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, switch buttons, etc.), trackballs, mice, joysticks, and the like.

Display unit 1040 can be used to display information entered by the user or information provided to the user and various graphical user interfaces of terminal 1000, which can be constructed from graphics, text, icons, video, and any combination thereof. The display unit 1040 may include a display panel 1041. Alternatively, the display panel 1041 may be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), or the like.

Terminal 1000 can also include at least one type of sensor 1050, such as a light sensor, motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor can adjust the brightness of the display panel 1041 according to the brightness of the ambient light, and the proximity sensor The display panel 1041 and/or the backlight can be turned off when the terminal 1000 is moved to the ear. As a kind of motion sensor, the gravity acceleration sensor can detect the magnitude of acceleration in all directions (usually three axes). When it is stationary, it can detect the magnitude and direction of gravity. It can be used to identify the gesture of the mobile phone (such as horizontal and vertical screen switching, related Game, magnetometer attitude calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for the terminal 1000 can also be configured with gyroscopes, barometers, hygrometers, thermometers, infrared sensors and other sensors, not here Let me repeat.

Audio circuit 1060, speaker 1061, and microphone 1062 can provide an audio interface between the user and terminal 1000. The audio circuit 1060 can transmit the converted electrical data of the received audio data to the speaker 1061, and convert it into a sound signal output by the speaker 1061; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, by the audio circuit 1060. After receiving, it is converted into audio data, and then processed by the audio data output processor 1080, transmitted to the terminal, for example, via the RF circuit 1010, or outputted to the memory 1020 for further processing. The audio circuit 1060 may also include an earbud jack to provide communication of the peripheral earphones with the terminal 1000.

WiFi is a short-range wireless transmission technology, and the terminal 1000 can help users to send and receive emails, browse web pages, and access streaming media through the WiFi module 1070, which provides wireless broadband Internet access for users. Although FIG. 10 shows the WiFi module 1070, it can be understood that it does not belong to the essential configuration of the terminal 1000, and may be omitted as needed within the scope of not changing the essence of the invention.

The processor 1080 is the control center of the terminal 1000, connecting various portions of the entire handset with various interfaces and lines, by running or executing software programs and/or modules stored in the memory 1020, and recalling data stored in the memory 1020, The various functions and processing data of the terminal 1000 are performed to perform overall monitoring of the mobile phone. Optionally, the processor 1080 may include one or more processing cores; preferably, the processor 1080 may integrate an application processor and a modem processor, where the application processor mainly processes an operating system, a user interface, an application, and the like. The modem processor primarily handles wireless communications. It will be appreciated that the above described modem processor may also not be integrated into the processor 1080.

The terminal 1000 also includes a power source 1090 (such as a battery) for powering various components. Preferably, the power source can be logically coupled to the processor 1080 through a power management system to manage functions such as charging, discharging, and power management through the power management system. The power supply 1090 may also include any one or more of a DC or AC power source, a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator, and the like.

Although not shown, the terminal 1000 may further include a Bluetooth module or the like, and details are not described herein again.

Specifically, in this embodiment, the terminal 1000 further includes a memory. Storing at least one instruction, at least one program, code set or instruction set in the memory, the at least one instruction, the at least one program, the code set or the instruction set being loaded and executed by the processor to implement the above Client-side key management method.

Please refer to FIG. 11 , which is a schematic structural diagram of a server according to an embodiment of the present invention. This server is used to implement the server-side key management method provided in the above embodiment. Specifically:

The server 1100 includes a central processing unit (CPU) 1101, a system memory 1104 including a random access memory (RAM) 1102 and a read only memory (ROM) 1103, and a system bus 1105 that connects the system memory 1104 and the central processing unit 1101. The server 1100 also includes a basic input/output system (I/O system) 1106 that facilitates transfer of information between various devices within the computer, and mass storage for storing the operating system 1113, applications 1114, and other program modules 1115. Device 1107.

The basic input/output system 1106 includes a display 1108 for displaying information and an input device 1109 such as a mouse or keyboard for user input of information. The display 1108 and the input device 1109 are both connected to the central processing unit 1101 via an input-output controller 1110 connected to the system bus 1105. The basic input/output system 1106 can also include an input output controller 1110 for receiving and processing input from a plurality of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, the input and output controller 1110 also provides output to a display screen, printer, or other type of output device.

The mass storage device 1107 is connected to the central processing unit 1101 by a mass storage controller (not shown) connected to the system bus 1105. The mass storage device 1107 and its associated computer readable medium provide non-volatile storage for the server 1100. That is, the mass storage device 1107 can include a computer readable medium (not shown) such as a hard disk or a CD-ROM drive.

Without loss of generality, the computer readable medium can include computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, EPROM, EEPROM, flash memory or other solid state storage technologies, CD-ROM, DVD or other optical storage, tape cartridges, magnetic tape, magnetic disk storage or other magnetic storage devices. Of course, those skilled in the art may know that the computer storage medium is not in use. Limited to the above several. The system memory 1104 and the mass storage device 1107 described above may be collectively referred to as a memory.

According to various embodiments of the present invention, the server 1100 may also be operated by a remote computer connected to the network through a network such as the Internet. That is, the server 1100 can be connected to the network 1112 through the network interface unit 1111 connected to the system bus 1105, or can also be connected to other types of networks or remote computer systems (not shown) using the network interface unit 1111. .

Storing at least one instruction, at least one program, code set or instruction set in the memory, the at least one instruction, the at least one program, the code set or the instruction set being loaded and executed by the processor to implement the above Key management method on the server side.

In an exemplary embodiment, there is also provided a computer readable storage medium having stored therein at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program The code set or instruction set is loaded and executed by the processor of the terminal to implement the steps of the terminal side in the above method embodiment.

In an exemplary embodiment, there is also provided a computer readable storage medium having stored therein at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program The code set or instruction set is loaded and executed by a processor of the server to implement the various steps of the server side in the above method embodiment.

Alternatively, the computer readable storage medium described above may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device.

In an exemplary embodiment, there is also provided a computer program product for performing the functions of the various steps of the terminal side in the above method embodiments when the computer program product is executed.

In an exemplary embodiment, there is also provided a computer program product for performing the functions of the various steps on the server side of the above method embodiments when the computer program product is executed.

It should be understood that "a plurality" as referred to herein means two or more. "and/or", describing the association relationship of the associated objects, indicating that there may be three relationships, for example, A and/or B, which may indicate that there are three cases where A exists separately, A and B exist at the same time, and B exists separately. The character "/" generally indicates that the contextual object is an "or" relationship.

The serial numbers of the embodiments of the present invention are merely for the description, and do not represent the advantages and disadvantages of the embodiments.

The above description is only exemplary embodiments of the present invention, and is not intended to limit the present invention. Any modifications, equivalents, improvements, etc., which are within the spirit and scope of the present invention, should be included in the protection of the present invention. Within the scope.

Claims (35)

A key management method, the method comprising: Generate a temporary key; Encrypting the temporary key by using a public key provided by the server to obtain a first ciphertext; Sending an authentication request to the server, where the authentication request carries the first ciphertext; Receiving an authentication response sent by the server, where the authentication response carries a second ciphertext, where the second ciphertext is a ciphertext obtained by encrypting the session key by using the temporary key; wherein the session The key is used to encrypt the data of the session; Decrypting the second ciphertext by using the temporary key to obtain the session key. The method according to claim 1, wherein the authentication response further carries a key identifier, and the key identifier is used to identify the session key. The method according to claim 2, wherein the decrypting the second ciphertext by using the temporary key to obtain the session key further comprises: Encrypting the uplink data of the session by using the session key to obtain encrypted uplink data; Sending an uplink data packet to the server, where a packet header of the uplink data packet carries the key identifier, and a packet body of the uplink data packet carries the encrypted uplink data. The method according to claim 2, wherein the decrypting the second ciphertext by using the temporary key to obtain the session key further comprises: Receiving a downlink data packet sent by the server, where a packet header of the downlink data packet carries the key identifier, and a packet body of the downlink data packet carries encrypted downlink data; Decrypting the encrypted downlink data by using a session key corresponding to the key identifier carried in the packet header to obtain downlink data. The method according to claim 1, wherein the generating the temporary key comprises: The temporary key is generated using a random number generator. The method of claim 1 further comprising: Receiving, by the server, an initialization vector corresponding to the session key, where the initialization vector is used when the local end performs symmetric encryption and decryption using the session key. A key management method, the method comprising: Receiving an authentication request sent by the client, where the authentication request carries the first ciphertext, and the first ciphertext is a ciphertext obtained by encrypting the temporary key by using the public key provided by the local end; Decrypting the first ciphertext by using a private key corresponding to the public key to obtain the temporary key; Encrypting the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session; Sending an authentication response to the client, where the second ciphertext is carried in the authentication response. The method according to claim 7, wherein the authentication response further carries a key identifier, and the key identifier is used to identify the session key. The method of claim 8 further comprising: Generating the session key using a random number generator; A key identifier corresponding to the session key is generated. The method of claim 8 further comprising: Selecting a corresponding set of session keys and key identifiers from the pre-stored keys; The pre-stored key includes at least one set of corresponding session key and key identifier. The method according to claim 10, wherein the selecting a corresponding set of session keys and key identifiers from the pre-stored keys comprises: Obtaining an internet protocol IP address corresponding to the client; Determining a key selection range according to the IP address, where the key selection range includes a part of the session key and a key identifier corresponding to the pre-stored key; A set of corresponding session keys and key identifiers are selected from the key selection range. The method according to claim 8, wherein after the sending the authentication response to the client, the method further comprises: Receiving, by the client, the uplink data packet, where the packet header of the uplink data packet carries the key identifier, and the packet of the uplink data packet carries the encrypted uplink data; Decrypting the encrypted uplink data by using a session key corresponding to the key identifier carried in the packet header to obtain uplink data. The method according to claim 8, wherein after the sending the authentication response to the client, the method further comprises: Encrypting the downlink data of the session by using the session key to obtain encrypted downlink data; Sending a downlink data packet to the client, the packet header of the downlink data packet carries the key identifier, and the packet body of the downlink data packet carries the encrypted downlink data. The method according to claim 7, wherein after receiving the authentication request sent by the client, the method further includes: Obtaining a globally unique identifier GUID corresponding to the device where the client is located; Obtaining the number of authentication requests corresponding to the GUID; And if the number of the authentication requests is less than a preset threshold, performing the step of decrypting the first ciphertext by using a private key corresponding to the public key to obtain the temporary key. The method of claim 7, wherein the method further comprises: Obtaining an initialization vector corresponding to the session key; The initialization vector is sent to the client, and the initialization vector is used when the client performs symmetric encryption and decryption using the session key. A key management device, characterized in that the device comprises: a key generation module, configured to generate a temporary key; a first encryption module, configured to encrypt the temporary key by using a public key provided by a server to obtain a first ciphertext; a request sending module, configured to send an authentication request to the server, where the first ciphertext is carried in the authentication request; The response receiving module is configured to receive an authentication response sent by the server, where the authentication response carries a second ciphertext, and the second ciphertext is a ciphertext obtained by encrypting the session key by using the temporary key. ; The session key is used to encrypt data of the session; The first decryption module is configured to decrypt the second ciphertext by using the temporary key to obtain the session key. The device according to claim 16, wherein the authentication response further carries a key identifier, and the key identifier is used to identify the session key. The device according to claim 17, wherein the device further comprises: An uplink data encryption module, configured to encrypt uplink data of the session by using the session key to obtain encrypted uplink data; The uplink data sending module is configured to send an uplink data packet to the server, where a packet header of the uplink data packet carries the key identifier, and a packet body of the uplink data packet carries the encrypted uplink data. The device according to claim 17, wherein the device further comprises: a downlink data receiving module, configured to receive a downlink data packet sent by the server, where a packet header of the downlink data packet carries the key identifier, and a packet body of the downlink data packet carries encrypted downlink data; The downlink data decryption module is configured to decrypt the encrypted downlink data by using a session key corresponding to the key identifier carried in the packet header to obtain downlink data. The device of claim 16 wherein: The key generation module is configured to generate the temporary key by using a random number generator. The device according to claim 16, wherein the device further comprises: The vector receiving module is configured to receive an initialization vector that is sent by the server and that is corresponding to the session key, where the initialization vector is used when the local end uses the session key for symmetric encryption and decryption. A key management device, characterized in that the device comprises: The request receiving module is configured to receive an authentication request sent by the client, where the authentication request carries a first ciphertext, and the first ciphertext is a ciphertext obtained by encrypting the temporary key by using a public key provided by the local end. ; a second decrypting module, configured to decrypt the first ciphertext by using a private key corresponding to the public key, to obtain the temporary key; a second encryption module, configured to encrypt the session key by using the temporary key to obtain a second ciphertext; wherein the session key is used to encrypt data of the session; The response sending module is configured to send an authentication response to the client, where the second ciphertext is carried in the authentication response. The device according to claim 22, wherein the authentication response further carries a key identifier, and the key identifier is used to identify the session key. The device of claim 23, wherein the device further comprises: And a key obtaining module, configured to generate the session key by using a random number generator, and generate a key identifier corresponding to the session key. The device of claim 23, wherein the device further comprises: a key obtaining module, configured to select a corresponding set of session key and key identifier from the pre-stored key; The pre-stored key includes at least one set of corresponding session key and key identifier. The device according to claim 25, wherein the key acquisition module comprises: An address obtaining unit, configured to obtain an internet protocol IP address corresponding to the client; a range determining unit, configured to determine a key selection range according to the IP address, where the key selection range includes a part of the corresponding session key and a key identifier of the pre-stored key; The key selection unit is configured to select a corresponding set of session keys and key identifiers from the key selection range. The device of claim 23, wherein the device further comprises: An uplink data receiving module, configured to receive an uplink data packet sent by the client, where a packet header of the uplink data packet carries the key identifier, and a packet body of the uplink data packet carries the encrypted uplink data; The uplink data decryption module is configured to decrypt the encrypted uplink data by using a session key corresponding to the key identifier carried in the packet header to obtain uplink data. The device of claim 23, wherein the device further comprises: a downlink data encryption module, configured to encrypt downlink data of the session by using the session key, Obtain encrypted downlink data; The downlink data sending module is configured to send a downlink data packet to the client, where a packet header of the downlink data packet carries the key identifier, and a packet body of the downlink data packet carries the encrypted downlink data. The device of claim 22, wherein the device further comprises: An identifier obtaining module, configured to obtain a global unique identifier GUID corresponding to the device where the client is located; a number obtaining module, configured to acquire the number of authentication requests corresponding to the GUID; The second decryption module is further configured to: when the number of the authentication requests is less than a preset threshold, decrypt the first ciphertext by using a private key corresponding to the public key, to obtain the temporary key. The device of claim 22, wherein the device further comprises: a vector obtaining module, configured to acquire an initialization vector corresponding to the session key; And a vector sending module, configured to send the initialization vector to the client, where the initialization vector is used by the client to perform symmetric encryption and decryption using the session key. A key management system, characterized in that the system comprises: a client and a server; The client includes the key management device according to any one of claims 16 to 21; The server includes the key management device according to any one of claims 22 to 30. A terminal, comprising: a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program, and the The code set or instruction set is loaded and executed by the processor to implement the key management method according to any one of claims 1 to 6. A server, comprising: a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program, the The code set or instruction set is loaded and executed by the processor to implement the key management method according to any one of claims 7 to 15. A computer readable storage medium, wherein the storage medium stores at least An instruction, at least one program, a code set, or a set of instructions, the at least one instruction, the at least one program, the code set, or the set of instructions being loaded and executed by a processor to implement any of claims 1 to 6. The key management method described. A computer readable storage medium, wherein the storage medium stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program, the code set or The instruction set is loaded and executed by the processor to implement the key management method according to any one of claims 7 to 15.

Images