Conversation-based negotiation key data processing method, client, server and system

Abstract

The invention provides a session-based negotiation key data processing method, a client, a server and a session-based negotiation key data processing system. The method is applied to a client and comprises the following steps: receiving a user login request, and requesting to call an SM2 public key; receiving the UUID and the SM2 public key returned by the server, generating a dynamic SM4 key, and encrypting the dynamically generated SM4 key according to the SM2 public key; calling a negotiation key interface, and sending the UUID and the dynamically generated SM4 key after encryption to a server; caching the UUID and the dynamic SM4 key after the processing returned by the server side is successful; user login information is encrypted according to the UUID and the SM4 secret key, a user login request message is packaged, and a login request is sent to a server side; and according to login success information and the user token returned by the server, caching the encrypted user token and the dynamic SM4 key, and displaying a login success page to the user. According to the method, the security of data interaction is greatly improved, the risk of data leakage and tampering is reduced, and the network information security is enhanced.

Description

Technical Field

[0001] The present invention relates to the field of secure communication technology, and in particular to a session-based negotiated key data processing method, a client, a server and a system. Background Art

[0002] A lot of network data transmission contains sensitive information, even confidential information, which will attract various man-made attacks from all over the world (such as information leakage, information theft, data tampering, data deletion, etc.). The Internet is an open network without a control organization. At the same time, Internet data transmission is based on the TCP / IP communication protocol, which lacks security measures to prevent information from being stolen during transmission. The data transmission process needs to go through a large number of gray intermediate links. The plaintext data flows through multiple physical nodes such as intermediate proxy servers, routers, wifi hotspots, and communication service operators. The middleman can sniff data information at will at any node, steal privacy, or even tamper with the transmitted data, resulting in the leakage of sensitive information.

[0003] In the process of front-end and back-end interaction, the front-end is directly facing the user and belongs to the client. The user can obtain the front-end code and all request messages through technical means. The fixed key involved in the existing technology or the message is not encrypted, which is easy to be intercepted and cracked by hackers. Hackers can easily attack and crack the system, or simulate user behavior to perform illegal operations, which has great security risks. The leakage of user passwords or personal information is extremely harmful, and the leakage of confidential information of enterprises and institutions also has a high risk. Summary of the invention

[0004] The purpose of this application is to use an asymmetric encryption algorithm (SM2) and a block cipher algorithm (SM4) to encrypt the transmitted data during the front-end and back-end data interaction process, and at the same time generate a dynamic message encryption key and bind it to the login session information. Each dynamic key generated is only valid for a short time, which greatly improves the security of data interaction, reduces the risk of data leakage and tampering, and enhances network information security.

[0005] According to one aspect of an embodiment of the present invention, a session-based negotiated key data processing method is provided, which is applied to a client, and the method includes: receiving a user login request, requesting a server to call a public key of an asymmetric encryption algorithm; receiving a universal unique identifier UUID and the asymmetric encryption algorithm public key returned by the server, generating a dynamic block cipher algorithm key, and encrypting the dynamically generated block cipher algorithm key according to the asymmetric encryption algorithm public key; calling a negotiated key interface, and sending the UUID and the encrypted block cipher algorithm key to the server; caching the UUID and the block cipher algorithm key after successful processing returned by the server; encrypting the user login information according to the UUID and the block cipher algorithm key, encapsulating the user login request message, and sending the login request to the server; and caching the encrypted user token and the block cipher algorithm key according to the successful login information and user token returned by the server, and displaying a successful login page to the user.

[0006] Optionally, the method also includes: receiving a user service operation request, encrypting the service operation request message data by a block cipher algorithm through a negotiated key; carrying the user token and the encrypted service operation request message, requesting a service operation interface from the server; and displaying the operation result to the user based on the operation result returned by the server.

[0007] Optionally, based on the successful login information and user token returned by the server, the encrypted user token and the key of the dynamic block cipher algorithm are cached, and a successful login page is displayed to the user. The method also includes: when the login session expires, the bound block cipher algorithm key information is deleted, and the negotiated key becomes invalid.

[0008] According to another aspect of an embodiment of the present invention, a session-based negotiation key data processing method is provided, which is applied to a server, and the method includes: receiving a request for calling an asymmetric encryption algorithm public key sent by a client, and determining whether the asymmetric encryption algorithm public key exists; generating a UUID according to the asymmetric encryption algorithm public and private keys, and binding the UUID and the asymmetric encryption algorithm private key into a key-value pair database Redis cache, and returning the UUID and the asymmetric encryption algorithm public key to the client; receiving a negotiation key interface call request sent by the client, querying the corresponding asymmetric encryption algorithm private key according to the UUID, and decrypting the encrypted block cipher algorithm key through the asymmetric encryption algorithm private key; caching the UUID and the block cipher algorithm key, and returning a successful processing to the client; after receiving a login request, obtaining the corresponding block cipher algorithm key according to the UUID, and decrypting the encrypted login request message; and after verifying that the user login information is passed, creating login session information, generating a user token, and binding the user token with the block cipher algorithm key and caching it in Redis, and returning login success information and the user token to the client.

[0009] Optionally, the method further includes: receiving a call request for a business operation interface sent by a client; obtaining a corresponding negotiation key through the user token, and decrypting the encrypted business operation request message data; after decryption, executing the business operation according to the plaintext data, and returning the operation result to the client.

[0010] According to another aspect of an embodiment of the present invention, a client is provided, comprising a memory and a processor, wherein the processor is configured to execute the session-based negotiated key data processing method applied to the client.

[0011] According to another aspect of an embodiment of the present invention, a server is provided, comprising a memory and a processor, wherein the processor is configured to execute the session-based negotiated key data processing method applied to the server.

[0012] According to another aspect of an embodiment of the present invention, a system is provided, comprising the client and the server.

[0013] According to another aspect of an embodiment of the present invention, a non-volatile storage medium is further provided, wherein the non-volatile storage medium is used to store a program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above-mentioned session-based negotiated key data processing method.

[0014] According to another aspect of an embodiment of the present invention, an electronic device is provided, including: a memory and a processor, wherein the processor is used to run a program stored in the processor, wherein the program executes the above-mentioned session-based negotiated key data processing method when running.

[0015] Compared with the prior art, the advantages of this application are:

[0016] 1. Through the database dynamic log method, the "minimization" of cross-border data synchronization is achieved, the efficiency of cross-border data synchronization is improved, and resource consumption is effectively reduced.

[0017] 2. Through data table authorization and dynamic data log, ensure that only recorded data can be synchronized to protect the security of original data.

[0018] 3. Ensure that the data synchronization process complies with the data protection regulations of various countries and reduce legal risks.

[0019] 4. Not restricted by database type, cross-type data synchronization can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of this application. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention. In the drawings:

[0021] Figure 1 is a processing flow chart of a session-based negotiated key data processing method applied to a client according to an embodiment of the present invention;

[0022] Figure 2 is an interaction sequence diagram between a client and a server according to an embodiment of the present invention;

[0023] Figure 3 It is a processing flow chart of a session-based negotiation key data processing method applied to a server according to an embodiment of the present invention;

[0024] Figure 4 It is a structural block diagram of a computer terminal according to an embodiment of the present invention. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] According to an embodiment of the present invention, an embodiment of a session-based negotiated key data processing method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0028] The acquisition, transmission, storage, use, and processing of data in the technical solution of this application are in compliance with the relevant provisions of national laws and regulations. In addition, it should be noted that in the embodiments of this application, some existing solutions in the industry such as certain software, components, and models may be mentioned, which should be considered as exemplary, and their purpose is only to illustrate the feasibility of the implementation of the technical solution of this application, but it does not mean that the applicant has or will necessarily use the solution.

[0029] The back-end server of this application is developed in JAVA language, and the front-end page uses Vue framework. During the data interaction between the front-end and back-end, the invention conceives to use an asymmetric encryption algorithm (SM2) and a block cipher algorithm (SM4) based on the login session, that is, the national secret algorithm SM2 and SM4 dynamically generate encryption keys to encrypt and transmit data.

[0030] See also Figure 1 and Figure 2 , a session-based negotiation key data processing method is applied to the client, as follows:

[0031] In S101, a user login request is received, requesting to call the public key of the asymmetric encryption algorithm. Specifically, it involves the acquisition and generation of the SM2 public key. When the user logs in to the system, the front-end page, i.e. the client, first calls the interface for obtaining the public key, and the back-end service, i.e. the server, determines whether the SM2 key exists in the Redis cache. If not, a pair of SM2 public and private keys are generated and cached in Redis. The validity period of the public and private key information can be set in the configuration file according to business needs. Redis is an open source, high-performance key-value database, which is often used as a data structure server, cache solution, or message agent. After obtaining a pair of SM2 public and private keys from the cache Redis, the back-end service generates a non-repeating random string UUID and records the SM2 private key information in Redis in the following format:

[0032] auth:privatekey:{uuid}=sm2 private key,

[0033] At the same time, the public key information of SM2 and the generated random string UUID are returned to the front-end page for encrypting the block cipher algorithm (SM4) key. UUID (Universally Unique Identifier) ​​is a software-built standard for unique identification information in distributed systems without central coordination. UUID is a 128-bit value, usually represented by 32 hexadecimal digits, and generated by a specific algorithm to ensure that each UUID is unique.

[0034] In S102, the random string UUID and the asymmetric encryption algorithm public key returned by the server are received, a dynamic block cipher algorithm key is generated, and the dynamically generated block cipher algorithm key is encrypted according to the asymmetric encryption algorithm public key. Specifically, after the front-end page, i.e., the client obtains the random UUID and SM2 public key returned in S101, a SM4 key string is dynamically and randomly generated, and the dynamically generated SM4 key is encrypted with the SM2 public key.

[0035] In S103, the negotiation key interface is called to send the UUID and the encrypted dynamically generated block cipher algorithm key to the server. Specifically, the front-end and back-end block cipher algorithm (SM4) keys are negotiated, and the UUID and the encrypted dynamically generated SM4 key are sent to the back-end service by calling the negotiation key interface of the back-end service. The message is as follows:

[0036] {

[0037] "uuid":"274664584263",

[0038] "secret":"b3d2d332eb37a1d34e3bfb56ef0a2b31730bcb54"

[0039] }

[0040] The backend service queries the SM2 private key cached in S101 based on the UUID, decrypts the encrypted key message secret in the request message with the SM2 private key, and updates it to the cache in the following format:

[0041] auth:privatekey:{uuid}=sm4 key,

[0042] In S104, after the processing is successful according to the server, the UUID and the dynamic key of the block cipher algorithm are cached. Specifically, after the processing is completed, the interface is returned successfully, and the front-end page caches the UUID and the dynamic key in the front-end browser. At this point, through the UUID, the front-end page and the back-end service complete the initial binding of the negotiated key, wherein the negotiated key is used in the method of this application for data transmission and conversion with the negotiated key value.

[0043] In S105, the user login information is encrypted according to the UUID and the key of the block cipher algorithm, the user login request message is encapsulated, and the login request is sent to the server. Specifically, for the login request, the front-end page obtains the cached UUID and places it in the header of the HTTP request, obtains the SM4 key to perform SM4 encryption on the user login account, password and other information, and encapsulates the user login request message. The front-end page requests the back-end service to log in to the service interface, and passes the encapsulated request message to the back-end service. After the back-end service receives the request, it first obtains the bound random string UUID from the header, obtains the corresponding SM4 key information from Redis according to the random string, decrypts the encrypted login message through the SM4 key, obtains the user's account, password and other information, verifies the user's information, and returns login failure if the verification fails. After the verification passes, the login session information is created, the user token is generated, and the user token is bound to the SM4 key and cached in Redis, and the login success and user token information are returned. At this time, the negotiated key takes effect.

[0044] In S106, according to the successful login information and user token returned by the server, the encrypted user token and the key of the dynamic block cipher algorithm are cached, and the successful login page is displayed to the user. Specifically, after the front-end page obtains the successful login information, the user token and SM4 key information are encrypted and cached on the front-end page to complete the login. When the login session expires, the bound SM4 key information is deleted at the same time, and the negotiated key is invalid, wherein the SM4 key information is transmitted via the SM4 private key.

[0045] In S107, a user business operation request is received, and the business operation request message data is encrypted by a block cipher algorithm through the negotiated key value. Specifically, when the user performs a business operation, the front-end page obtains the user token from the cache and puts it into the request header as a credential for successful login. At the same time, the negotiated key value is used to encrypt the business operation request message data by SM4, and after encryption, the back-end service is requested to perform the business operation. After receiving the request, the back-end service obtains the user token for validity verification. If the verification fails, an error prompt indicating that the user login session is invalid is returned; if the verification succeeds, the user token and the encrypted business operation request message are carried to request the service operation interface from the server in S108; and according to the operation result returned by the server, the operation result is displayed to the user. Specifically, the negotiated key value corresponding to the user token is obtained to decrypt the request message, and the plaintext data of the business is obtained after decryption. The business operation is performed according to the plaintext data, and the operation result is returned to the front-end page after the operation is completed.

[0046] Figure 2 is an interaction sequence diagram between a client and a server according to an embodiment of the present invention, Figure 3 1 is a processing flow chart of a session-based negotiation key data processing method applied to a server according to an embodiment of the present invention. Figure 2 , Figure 3 , the embodiment of the present application provides a session-based negotiation key data processing method, which is applied to the server, as follows:

[0047] In S301, a request for calling the asymmetric encryption algorithm SM2 public key sent by the client is received to determine whether the asymmetric encryption algorithm public key exists. Specifically, it involves the acquisition and generation of the SM2 public key. When the user logs in to the system, the front-end page, i.e., the client, first calls the interface for obtaining the public key, and the back-end service, i.e., the server, determines whether the SM2 key exists in the Redis cache. If not, a pair of SM2 public and private keys is generated and cached in Redis. The validity period of the public and private key information can be set in the configuration file according to business needs. Redis is an open source, high-performance key-value database that is often used as a data structure server, cache solution, or message agent.

[0048] In S302, a random string UUID is generated based on the public and private keys of the asymmetric encryption algorithm, and the random string UUID and the asymmetric encryption algorithm private key are bound and put into the Redis cache, and the random string UUID and the asymmetric encryption algorithm public key are returned to the client. Specifically, after obtaining a pair of SM2 public and private keys from the cache Redis, the backend service generates a non-repeating random string UUID and records the SM2 private key information in Redis in the following format:

[0049] auth:privatekey:{uuid}=sm2 private key,

[0050] At the same time, the public key information of SM2 and the generated random string UUID are returned to the front end for encrypting the block cipher algorithm (SM4) key. UUID (Universally Unique Identifier) ​​is a software-built standard for unique identification information in distributed systems without central coordination. UUID is a 128-bit value, usually represented by 32 hexadecimal digits, and generated by a specific algorithm to ensure that each UUID is unique.

[0051] The client receives the random string UUID and the asymmetric encryption algorithm public key returned by the server, generates a dynamic block cipher algorithm key, and encrypts the dynamically generated block cipher algorithm SM4 key according to the asymmetric encryption algorithm SM2 public key. Specifically, after the front-end page, i.e., the client obtains the random UUID and SM2 public key returned in S101, it dynamically and randomly generates an SM4 key string, and encrypts the dynamically generated SM4 key with the SM2 public key.

[0052] In S303, the negotiation key interface call request sent by the client is received, and the private key of the corresponding asymmetric encryption algorithm is queried according to the random string UUID, and the encrypted block cipher algorithm key is decrypted by the private key of the asymmetric encryption algorithm. Specifically, by calling the negotiation key interface of the backend service, the backend service receives the received UUID and the encrypted dynamically generated SM4 key, and the message is as follows:

[0053] {

[0054] "uuid":"274664584263",

[0055] "secret":"b3d2d332eb37a1d34e3bfb56ef0a2b31730bcb54"

[0056] }

[0057] The backend service queries the cache for the corresponding SM2 private key based on the UUID, uses the SM2 private key to decrypt the encrypted SM4 key message secret in the request message, and updates it to the cache in the following format:

[0058] auth:privatekey:{uuid}=sm4 key,

[0059] In S304, the UUID and the dynamic block cipher algorithm key are cached, and the processing success is returned to the client. Specifically, after the processing is completed, the interface is returned successfully, and the front-end page caches the UUID and the dynamic key in the front-end browser. At this point, the front-end page and the back-end service complete the negotiation of the initial key binding through the UUID.

[0060] In S305, after receiving the login request, the corresponding block cipher algorithm key is obtained according to the random string UUID, and the encrypted login request message is decrypted. Specifically, for the login request, the front-end page obtains the cached UUID and places it in the header of the HTTP request, obtains the SM4 key to perform SM4 encryption on the user's login account, password and other information, and encapsulates the user login request message. The front-end page requests the back-end service to log in to the service interface, and passes the encapsulated request message to the back-end service. After receiving the request, the back-end service first obtains the bound random string UUID from the header, obtains the corresponding SM4 key information from Redis according to the random string, and decrypts the encrypted login message through the SM4 key to obtain the user's account, password and other information.

[0061] In S306, after verifying the user login information, the login session information is created, the user token is generated, and the user token is bound to the block cipher algorithm key and cached in Redis, and the login success information and user token are returned to the client. Specifically, the user information is verified, and if the verification fails, the login failure is returned. After verifying the user login information, the login session information is created, the user token is generated, and the user token is bound to the SM4 key and cached in Redis, and the login success and user token information are returned. At this time, the negotiated key takes effect. After the front-end page obtains the login success information, the user token and SM4 key information are encrypted and cached on the front-end page to complete the login. When the login session expires, the bound SM4 key information is deleted at the same time, which can be understood as the SM4 private key information, and the negotiated key is invalid.

[0062] In S307, a request for calling a business interface sent by the client is received, and the corresponding negotiation key is obtained through the user token to decrypt the encrypted business operation request message data; after decryption, the business operation is performed according to the plaintext data, and the operation result is returned to the client. Specifically, when the user performs a business operation, the front end obtains the user token from the cache and puts it into the request header as a credential for successful login. At the same time, the business operation request message data is SM4 encrypted using the negotiation key value, and after encryption, the back-end service is requested to perform the business operation. After receiving the request, the back-end service obtains the user token for validity verification. If the verification fails, an error prompt indicating that the user login session is invalid is returned; if the verification succeeds, the negotiation key value corresponding to the user token is obtained to decrypt the request message, and the plaintext data of the business is obtained after decryption. The business operation is performed according to the plaintext data, and the operation result is returned to the front-end after the operation is completed.

[0063] The beneficial technical effects of this application are:

[0064] 1. Encrypt the data during transmission to improve the security of data transmission and reduce the risk of data leakage;

[0065] 2. A new SM4 encryption key value is dynamically generated each time the user logs in, and the key value is bound to the login session. The key value is only valid during the session validity period. The dynamic key value that is valid for a certain period of time greatly reduces the risk of the key being cracked;

[0066] 3. The front end uses the SM2 public key to encrypt SM4 for transmission, and the back end decrypts it through the SM2 private key. To improve performance, the SM2 generated by the back end is a global public and private key, which is replaced regularly to improve the security of key transmission and prevent key leakage or simulation.

[0067] This session-based negotiated key data processing method can encrypt data transmitted over the network through a dynamic negotiated key that is valid for a certain period of time, effectively preventing problems such as information leakage, information theft, and data tampering during network data transmission, while reducing the risk of keys being cracked by brute force, greatly improving the security of data transmission and enhancing network information security.

[0068] An embodiment of the present application provides a client, comprising a memory and a processor, wherein the processor is configured to execute a session-based negotiated key data processing method applied to the client.

[0069] An embodiment of the present application provides a server, comprising a memory and a processor, wherein the processor is configured to execute a session-based negotiated key data processing method applied to the server.

[0070] An embodiment of the present application provides a system, including a client and a server.

[0071] The embodiment of the present application may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal may also be replaced by a terminal device such as a mobile terminal.

[0072] Optionally, in this embodiment, the computer terminal may be located in at least one network device among a plurality of network devices of the computer network.

[0073] In this embodiment, the above-mentioned computer terminal can execute the program code of the following steps in the client of the session-based negotiated key data processing method: receiving a user login request and requesting the server to call the asymmetric encryption algorithm public key; receiving the universal unique identification code UUID and the asymmetric encryption algorithm public key returned by the server, generating a dynamic block cipher algorithm key, and encrypting the dynamically generated block cipher algorithm key according to the asymmetric encryption algorithm public key; calling the negotiated key interface, sending the UUID and the encrypted block cipher algorithm key to the server; caching the UUID and the block cipher algorithm key after successful processing returned by the server; encrypting the user login information according to the UUID and the block cipher algorithm key, encapsulating the user login request message, and sending the login request to the server; and caching the encrypted user token and the block cipher algorithm key according to the login success information and user token returned by the server, and displaying the login success page to the user.

[0074] In this embodiment, the above-mentioned computer terminal can execute the program code of the following steps in the server side of the session-based negotiation key data processing method: receiving a request for calling an asymmetric encryption algorithm public key sent by the client, and determining whether the asymmetric encryption algorithm public key exists; generating a UUID based on the asymmetric encryption algorithm public and private keys, and binding the UUID and the asymmetric encryption algorithm private key into the key-value pair database Redis cache, and returning the UUID and the asymmetric encryption algorithm public key to the client; receiving a negotiation key interface call request sent by the client, querying the corresponding asymmetric encryption algorithm private key based on the UUID, and decrypting the encrypted block cipher algorithm key through the asymmetric encryption algorithm private key; caching the UUID and the block cipher algorithm key, and returning a successful processing to the client; after receiving a login request, obtaining the corresponding block cipher algorithm key based on the UUID, and decrypting the encrypted login request message; and after verifying the user login information, creating login session information, generating a user token, and binding the user token to the block cipher algorithm key and caching it in Redis, and returning login success information and the user token to the client.

[0075] Optionally, Figure 4 is a structural block diagram of a computer terminal according to an embodiment of the present invention. Figure 4As shown, the computer terminal 40 may include: one or more (only one is shown in the figure) processors 42 , and a memory 44 .

[0076] Among them, the memory can be used to store software programs and modules, such as the session-based negotiated key data processing method in the embodiment of the present invention is applied to the program instructions / modules corresponding to the client and the server, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned session-based negotiated key data processing method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal 40 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0077] The processor can call the information and application programs stored in the memory through the transmission device to execute the above-mentioned session-based negotiated key data processing method, which is applied to various steps of the client and the server.

[0078] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the computer terminal may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a handheld computer, a mobile Internet device (Mobile Internet Devices, MID), a PAD, or other terminal devices. Figure 4 The structure of the electronic device is not limited. For example, the computer terminal 40 may also include Figure 4 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 4 Different configurations are shown.

[0079] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a non-volatile storage medium. The non-volatile storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0080] The embodiment of the present invention further provides a non-volatile storage medium. Optionally, in this embodiment, the non-volatile storage medium can be used to store the program code executed by the session-based negotiated key data processing method provided in the above embodiment.

[0081] Optionally, in this embodiment, the non-volatile storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the embodiments, it should be understood by those skilled in the art that any modification or equivalent replacement of the technical solutions of the present invention does not depart from the spirit and scope of the technical solutions of the present invention and should be included in the scope of the claims of the present invention.

Claims

1. A session-based negotiation key data processing method, applied to a client, characterized in that: The method comprises: Receive user login request and request the server to call the asymmetric encryption algorithm public key; Receive the universal unique identifier UUID and the asymmetric encryption algorithm public key returned by the server, generate a dynamic block cipher algorithm key, and encrypt the dynamically generated block cipher algorithm key according to the asymmetric encryption algorithm public key; Calling the negotiation key interface to send the UUID and the encrypted block cipher algorithm key to the server; After the processing is successful according to the response from the server, the UUID and the block cipher algorithm key are cached; Encrypting the user login information according to the UUID and the block cipher algorithm key, encapsulating the user login request message, and sending the login request to the server; and According to the successful login information and user token returned by the server, the encrypted user token and the block cipher algorithm key are cached, and a successful login page is displayed to the user.

2. The method according to claim 1, characterized in that The method further comprises: Receive user service operation requests, and encrypt the service operation request message data using a block cipher algorithm by negotiating a key; Carrying the user token and the encrypted service operation request message, requesting the service operation interface from the server; and According to the operation result returned by the server, the operation result is displayed to the user.

3. The method according to claim 1, characterized in that The method further comprises: caching the encrypted user token and the key of the dynamic block cipher algorithm according to the login success information and the user token returned by the server, and displaying a login success page to the user. When the login session becomes invalid, the bound block cipher algorithm key information is deleted and the negotiated key becomes invalid.

4. A session-based negotiation key data processing method, applied to a server, characterized in that: The method comprises: Receive a request from a client to call a public key of an asymmetric encryption algorithm, and determine whether the public key of the asymmetric encryption algorithm exists; Generate a UUID based on the public and private keys of the asymmetric encryption algorithm, bind the UUID and the private key of the asymmetric encryption algorithm and put them into the key-value pair database Redis cache, and return the UUID and the public key of the asymmetric encryption algorithm to the client; Receive a negotiation key interface call request sent by the client, query the corresponding asymmetric encryption algorithm private key according to the UUID, and decrypt the encrypted block cipher algorithm key by using the asymmetric encryption algorithm private key; Cache the UUID and the block cipher algorithm key, and return a successful processing to the client; After receiving the login request, obtaining the corresponding block cipher algorithm key according to the UUID, and decrypting the encrypted login request message; and After verifying that the user login information is passed, the login session information is created, a user token is generated, and the user token is bound to the block cipher algorithm key and cached in Redis, and the login success information and the user token are returned to the client.

5. The method according to claim 4, characterized in that The method further comprises: Receive the calling request of the business operation interface sent by the client; Obtaining the corresponding negotiation key through the user token, and decrypting the encrypted service operation request message data; After decryption, business operations are performed based on the plaintext data and the operation results are returned to the client.

6. A client, comprising a memory and a processor, wherein the processor is configured to execute the method according to claims 1-3.

7. A server, comprising a memory and a processor, wherein the processor is configured to execute the method according to claims 4-5.

8. A system comprising the client according to claims 1-3 and the server according to claims 4-5.

9. A non-volatile storage medium, characterized in that: The non-volatile storage medium is used to store a program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the session-based negotiated key data processing method described in any one of claims 1 to 5.

10. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the processor, wherein the program, when running, executes the session-based negotiated key data processing method described in any one of claims 1 to 5.

Images