Method, device and equipment for encrypted data communication, storage medium

Abstract

The application provides an encrypted data communication method, device, equipment and storage medium. The method comprises the following steps: receiving a data request of a client, wherein the data request comprises a request parameter, a target key index and request content; obtaining a target key according to the target key index, decrypting the request content by using the target key, performing business processing, and generating response data; and sending the response data to the client after symmetric encryption by using the target key, and the client performs decryption by using the target key. The application generates a key by introducing the request parameter of the client to perform dispersion calculation on the quantum random number, so that the key issued in each application and each key negotiation is different, the client randomly obtains a group of keys from the local storage key for data encryption and decryption, and the local storage key is deleted after being used once, so that the security is ensured.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an encrypted data communication method, apparatus, device, and storage medium. Background Technology

[0002] To prevent sensitive data (such as personal information and payment information) from being stolen or leaked during transmission and to protect user privacy, data communication between client apps and server APIs typically requires encryption. Currently, the encryption methods for data communication between client apps and server APIs mainly include two modes: symmetric and asymmetric.

[0003] Symmetric encryption uses the same key for both encryption and decryption. Specifically, before data communication, a communication key is typically distributed through key negotiation. During key negotiation, the client initiates a key negotiation request, including a random number generated by the client, which is encrypted using a non-interface algorithm with the public key. The server receives the request, decrypts it using its private key to obtain the random number, and generates a communication key. The server's response data includes the communication key and is symmetrically encrypted using the random number. The client decrypts the random number to obtain the communication key. In subsequent data communication, both the client and server use the negotiated communication key and the symmetric encryption algorithm to encrypt and decrypt data. Asymmetric encryption uses a public and private key pair for encryption and decryption. The client's data request includes a random number generated by the client, which is encrypted using the public key. The server decrypts the data using its private key and returns a response data, which is symmetrically encrypted using the random number. The client receives the response and decrypts it using the random number to obtain the data. Asymmetric encryption offers higher security but is slower.

[0004] For symmetric encryption data communication, the key is relatively fixed, and prolonged use may lead to its cracking. To control the key's usage duration, the frequency of key negotiation needs to be adjusted, but frequent key negotiations can negatively impact overall communication efficiency. For asymmetric encryption data communication, the random numbers used for encryption and decryption are generated by the client, typically using the SecureRandom method encapsulated in the Java SDK. This method provides both true and pseudo-random number generation. True random number generation has lower performance and can cause blocking issues; while pseudo-random numbers, once obtained by an attacker, can potentially deduce the initial seed and completely predict the content of subsequent generated random number sequences. Therefore, existing encrypted communication methods all have significant security vulnerabilities, and key management is quite complex. Summary of the Invention

[0005] This application provides an encrypted data communication method, apparatus, device, and storage medium to solve the problems of easy key cracking, poor security, and complex key management in existing encrypted communication technologies.

[0006] Firstly, this application provides an encrypted data communication method, applied on a server side, comprising:

[0007] Receive a data request from a client, the data request including request parameters, a target key index and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index;

[0008] The target key is obtained according to the target key index. The request content is decrypted and processed using the target key to generate response data. The target key is a quantum random number obtained from the quantum random number pool in advance according to the request parameters and the target key index. The quantum random number is then distributed and processed. The quantum random number and the key index have a one-to-one correspondence.

[0009] The response data is symmetrically encrypted using the target key and then sent to the client.

[0010] Optionally, in the method described above, obtaining the target key based on the target key index includes:

[0011] The target quantum random number corresponding to the target key index is obtained from the quantum random number pool using the target key index;

[0012] After obtaining the target quantum random number, the quantum random number is dispersed using the request parameters to obtain the target key.

[0013] Optionally, the method described above, before receiving the client's data request, further includes:

[0014] Receive a key negotiation request from a client, the key negotiation request including request parameters;

[0015] Multiple sets of quantum random numbers are obtained, and each quantum random number has a unique corresponding key index;

[0016] The request parameters are used to disperse each quantum random number to obtain multiple keys. The dispersed keys and their corresponding key indices are then returned to the client.

[0017] Optionally, in the method described above, the request parameters include an application-unique identifier (AppID) and a message-unique identifier (MsgID). The step of distributing the quantum random numbers using the request parameters to obtain multiple keys includes:

[0018] Combine the AppID and the MsgID into a string using a preset data structure;

[0019] The string is hashed using a hash function to generate a hash value;

[0020] The hash value is combined with each quantum random number to obtain the key corresponding to each quantum random number.

[0021] Secondly, this application provides an encrypted data communication method applied to a client, comprising:

[0022] Initiate a key negotiation request, which includes request parameters;

[0023] Obtain multiple sets of keys fed back by the server, the key validity period of each key, and the key index corresponding to each key. The key is a key generated based on quantum random numbers and dispersed by the request parameters. Store the request parameters, the key and its corresponding key validity period and key index locally securely.

[0024] A set of target keys and their corresponding target key indexes are randomly obtained locally. The request content is encrypted based on the target keys to generate a data request, which is then sent to the server.

[0025] The system receives response data from the server, decrypts the response data using the target key, and deletes the target key and its corresponding target key index from local secure storage.

[0026] Optionally, the method described above, before randomly obtaining a set of target keys and the target key index corresponding to those keys from the local machine, further includes:

[0027] Each key in the local secure storage is checked for status, which includes available, unavailable, and pending update.

[0028] Asynchronously update the keys that are in the unavailable and pending update states;

[0029] The key that is in the available state is used as the selectable key.

[0030] Thirdly, this application provides an encrypted data communication device for use on a server side, comprising:

[0031] A data request receiving module is used to receive data requests from clients. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index.

[0032] The encrypted data processing module obtains a target key based on the target key index, decrypts the request content using the target key, performs business processing, and generates response data. The target key is a quantum random number obtained from a quantum random number pool in advance based on the request parameters and the target key index, and then the quantum random number is distributed and processed. The quantum random number and the key index have a one-to-one correspondence.

[0033] An encryption module is used to symmetrically encrypt the response data using the target key before sending it to the client.

[0034] Fourthly, this application provides an encrypted data communication device for use on a client side, comprising:

[0035] The request module is used to initiate a key negotiation request, which includes request parameters.

[0036] The key storage module is used to obtain multiple sets of keys fed back by the server, the key validity period of each key, and the key index corresponding to each key. The key is a key generated based on quantum random numbers and dispersed by the request parameters. The request parameters, the key and its corresponding key validity period and key index are stored locally in a secure manner.

[0037] The data encryption module is used to randomly obtain a set of target keys and the target key index corresponding to the key from the local machine, encrypt the request content based on the target key, generate a data request, and send the data request to the server.

[0038] The decryption module is used to receive response data from the server, decrypt the response data using the target key, and delete the target key and its corresponding target key index from local secure storage.

[0039] Fifthly, this application provides an electronic device, including a memory, a processor, and computer-executable instructions stored in the memory and executable on the processor, wherein the processor executes the computer-executable instructions to implement the encrypted data communication method described in any one of the first or second aspects above.

[0040] In a sixth aspect, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the encrypted data communication method described in any one of the first or second aspects above.

[0041] In a seventh aspect, this application provides a computer program product that, when run on a terminal device, causes the terminal device to execute the encrypted data communication method described in either the first or second aspect above.

[0042] The encrypted data communication method, apparatus, device, and storage medium provided in this application receive a data request from a client. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using a target key corresponding to the target key index. A target key is obtained based on the target key index. The request content is decrypted using the target key and processed for business logic, generating response data. The target key is a quantum random number obtained from a quantum random number pool based on the request parameters and the target key index, and then distributed. The quantum random number and the key index have a one-to-one correspondence. The response data is symmetrically encrypted using the target key and sent to the client, which then decrypts it using the target key. This application introduces the client's request parameters to distribute and calculate the distributed quantum random number to generate a key, ensuring that each application and each key negotiation generates a different key. The client randomly obtains a set of keys from its locally stored keys for data encryption and decryption. The server calculates the key used for this communication based on the data request. Furthermore, the client's locally stored key is deleted after each use, ensuring one-time key exchange and security. Attached Figure Description

[0043] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0044] Figure 1 This is an interactive diagram of an existing encrypted data communication method.

[0045] Figure 2 This is an interactive schematic diagram of the encrypted data communication method provided in the embodiments of this application.

[0046] Figure 3 A flowchart illustrating an encrypted data communication method applied to a server, as provided in an embodiment of this application.

[0047] Figure 4 A flowchart illustrating an encrypted data communication method applied to a client, as provided in an embodiment of this application.

[0048] Figure 5 This is a schematic diagram of a server-side encrypted data communication device provided in an embodiment of this application.

[0049] Figure 6 This is a schematic diagram of a client-side encrypted data communication device provided in an embodiment of this application.

[0050] Figure 7 This is a schematic diagram of the structure of an electronic device for data storage based on object storage, provided in an embodiment of this application.

[0051] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0053] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0054] In related technologies, such as Figure 1 As shown, Figure 1 This diagram illustrates an existing encrypted data communication method. Before data communication, a communication key is typically distributed through key negotiation. During key negotiation, the client initiates a key negotiation request, including a random number generated by the client, which is encrypted using a non-interface algorithm and the public key. Upon receiving the request, the server decrypts it using its private key to obtain the random number and generates a communication key. The server's response data contains the communication key and is symmetrically encrypted using the random number. The client decrypts the data using the random number to obtain the communication key. In subsequent data communication, both the client and server use the negotiated communication key to encrypt and decrypt data using a symmetric encryption algorithm. However, in this method, the key is relatively fixed, and prolonged use may lead to its cracking, resulting in poor security. Furthermore, controlling the key's usage duration requires adjusting the key negotiation frequency, which can negatively impact overall communication efficiency.

[0055] To address the aforementioned technical problems, this application aims to propose an encrypted data communication method, apparatus, device, and storage medium. The core concept of this method is as follows: a massive number of keys are generated and key indices are recorded using a quantum random number generator. The client's request parameters are introduced to perform distributed calculations on the issued quantum random numbers to generate keys, ensuring that the keys issued for each application and each key negotiation are different. The client randomly obtains a set of keys from the locally stored keys for data encryption and decryption. Furthermore, the locally stored keys are deleted after each use, ensuring one-time key exchange and thus guaranteeing security.

[0056] To better understand the solutions of the embodiments of this application, an application scenario involved in the embodiments of this application will be introduced below.

[0057] Please see Figure 2 , Figure 2 This is an interactive schematic diagram of the encrypted data communication method provided in the embodiments of this application, such as... Figure 2 As shown, the system includes an application client 100 and an application server 200. The application server 200 includes a key management service module, which in turn includes a quantum random number pool. Specifically, the encrypted data communication between the client app and the server API can include two phases: key negotiation and data communication.

[0058] (1) Key negotiation phase

[0059] The client initiates a key negotiation request. The request parameters include AppID and MsgID information, where MsgID is a random number generated by the client. The request parameters use an asymmetric encryption mode and are encrypted with the public key.

[0060] After receiving the key negotiation request, the server obtains multiple sets of quantum random numbers in batches from the key management service;

[0061] The key management service obtains multiple sets of quantum random numbers from the quantum random number pool. The quantum random number pool consists of a large number of random numbers generated and stored in advance by the quantum random number generator, and each quantum random number has a unique corresponding key index.

[0062] The quantum random number pool returns multiple sets of quantum random numbers and their corresponding key indices;

[0063] After obtaining the quantum random number, the key management service uses AppID and MsgID to distribute the quantum random number to obtain the final key. The purpose of distributing the random number is to ensure that each application obtains a different key for each key negotiation.

[0064] The server returns multiple sets of keys and key indices;

[0065] The client stores multiple sets of keys, key indexes, AppID, and MsgID information in the keystore / keychain of the mobile device. The mobile device's operating system ensures that only the current application can read the data stored by this application.

[0066] (2) Data Communication Stage

[0067] When a client needs to communicate with a server, the client first reads multiple sets of key information from the keystore / keychain, randomly selects one set of keys as a backup, and records the key, key index, AppID, and MsgID information.

[0068] The client initiates a data request, which includes a key index, AppID, MsgID, and encrypted information. The encrypted information is generated by encrypting the request data using a symmetric encryption algorithm with a key obtained from the client.

[0069] After receiving the data request, the server uses the key index, AppID, and MsgID to obtain the key from the key management service;

[0070] The key management service uses a key index to obtain quantum random numbers from a quantum random number pool;

[0071] The quantum random number pool returns a quantum random number corresponding to the key index;

[0072] After obtaining the quantum random number, the key management service uses AppID and MsgID to distribute the quantum random number, obtains the final key, and returns it.

[0073] After obtaining the key, the server uses a symmetric encryption algorithm to decrypt the request data and then performs subsequent business processing.

[0074] After the business process is completed, the response data is symmetrically encrypted using the key returned from the quantum random number pool and then returned.

[0075] The client uses the key from the data request to decrypt the response information using a symmetric encryption algorithm to obtain the data; then deletes the key used in this instance from local storage.

[0076] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0077] Figure 3 A flowchart illustrating an encrypted data communication method applied to a server, as provided in an embodiment of this application. Figure 3 As shown, the method in this embodiment includes:

[0078] S301: Receive a data request from a client. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index.

[0079] The execution entity of this application embodiment can be an application server or a key management system in the application server, wherein the key management module system can be implemented by software.

[0080] Understandably, during data communication, data content is typically encrypted to ensure communication security and data integrity. In a data request sent by the client, the request content is encrypted using a target key. The purpose of the target key index is to enable the server to find the target key and thus decrypt the request content.

[0081] S302: Obtain the target key according to the target key index, use the target key to decrypt the request content and perform business processing, and generate response data. The target key is a quantum random number obtained from the quantum random number pool in advance according to the request parameters and the target key index, and then the quantum random number is distributed and processed. The quantum random number and the key index have a one-to-one correspondence.

[0082] Understandably, a quantum random number pool is used to store quantum random numbers generated by multiple quantum random number generators, possessing a physically secure source of random numbers. Quantum random numbers, in principle, guarantee absolute data security and true randomness. Furthermore, a mapping table can be created to associate each key with a specific location (index) in the quantum random number pool. This could be a simple hash table or other data structure, enabling quick lookup of the index corresponding to a target key.

[0083] In this step, the target key can be obtained from the quantum random number pool using the target key index, and then the request content is decrypted using the target key. The server can then perform corresponding business processing on the decrypted request content to generate response data.

[0084] S303: The response data is symmetrically encrypted using the target key and then sent to the client.

[0085] Understandably, symmetric encryption uses a secret key shared between the client and server. By using a target key for encryption, it's ensured that only the client possessing that key can decrypt and read the data, thus protecting data confidentiality. Furthermore, sending a target key index instead of the key itself simplifies key management; the server only needs to look up the corresponding key using the index, eliminating the need to transmit the key in every communication. This also reduces the risk of key leakage.

[0086] The encrypted data communication method provided in this embodiment receives a data request from a client. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index. A target key is obtained according to the target key index. The request content is decrypted using the target key and processed for business logic to generate response data. The target key is a quantum random number obtained from a quantum random number pool in advance based on the request parameters and the target key index, and then the quantum random number is distributed. The quantum random number and the key index have a one-to-one correspondence. The response data is symmetrically encrypted using the target key and sent to the client. The client decrypts the data using the target key. This application introduces the client's request parameters to distribute and calculate the distributed quantum random number to generate a key, ensuring that each application and each key negotiation generates a different key. The client randomly obtains a set of keys from its locally stored keys for data encryption and decryption. The server calculates the key used for this communication based on the data request. Furthermore, the client's locally stored key is deleted after each use, ensuring one-time key exchange and security.

[0087] The technical solution of the above-mentioned encrypted data communication method will be described in detail below.

[0088] In one possible implementation, the encrypted data communication method provided in this embodiment obtains the target quantum random number corresponding to the target key index, and then obtains the target key based on the target quantum random number.

[0089] Specifically, obtaining the target key based on the target key index includes: using the target key index to obtain a target quantum random number corresponding to the target key index from the quantum random number pool; after obtaining the target quantum random number, dispersing the quantum random number using request parameters to obtain the target key.

[0090] Understandably, in a quantum random number pool, each quantum random number has its own unique position, which can be used as the key index for each quantum random number. The server performs a scatter operation on the request parameters (e.g., AppID and MsgID) and the target quantum random number. For example, the scatter operation can be a cryptographic hash function (such as HMAC-SHA256) or other secure pseudo-random function, in which case the target key = HMAC-SHA256(target quantum random number, AppID||MsgID), where "||" represents a string concatenation operation. The result generated by the scatter operation is the target key.

[0091] In this embodiment, the target quantum random number corresponding to the target key index is obtained, and then the target key is obtained based on the target quantum random number. Since quantum random numbers are highly unpredictable, using quantum random numbers as the basic key material can significantly enhance the security of the key. Obtaining the target key through the target key index instead of directly transmitting the key can simplify key management and updates and reduce the risk of key leakage.

[0092] In one possible implementation, the encrypted data communication method provided in this embodiment further includes, before receiving the data request from the client: receiving a key negotiation request from the client, the key negotiation request including request parameters; obtaining multiple sets of quantum random numbers, each quantum random number having a unique corresponding key index; dispersing each quantum random number using the request parameters to obtain multiple keys; and returning the dispersed keys and their corresponding key indexes to the client.

[0093] Furthermore, the request parameters include an application unique identifier (AppID) and a message unique identifier (MsgID). The step of dispersing each quantum random number using the request parameters to obtain multiple keys includes: combining the AppID and the MsgID into a string using a preset data structure; hashing the string using a hash function to generate a hash value; and combining the hash value with each quantum random number to obtain the key corresponding to each quantum random number.

[0094] Understandably, Quantum Random Number Generation (QRNG) is a method for generating truly random numbers using the principles of quantum mechanics. To ensure the security and uniqueness of the random numbers, it is usually necessary to distribute the generated random numbers. Using AppID and MsgID to distribute the quantum random numbers generates a unique and secure final key. This method ensures that even if the quantum random number generator is compromised, attackers cannot easily predict or reproduce the final key because the combination of AppID and MsgID is unique and unpredictable.

[0095] In this embodiment, the target quantum random number corresponding to the target key index is obtained, and then the target key is obtained based on the target quantum random number. Since the quantum random number has a high degree of unpredictability, and attributes such as App ID and negotiation message ID are introduced to perform distributed calculation on the issued key, the key issued for each application and each key negotiation is different, which can significantly enhance the security of the key.

[0096] Figure 4 A flowchart illustrating an encrypted data communication method applied to a client, as provided in an embodiment of this application. Figure 4 As shown, the method in this embodiment includes:

[0097] S401: Initiate a key negotiation request, which includes request parameters.

[0098] Understandably, the request parameters can include AppID and MsgID information, where MsgID is a random number generated by the client. The request parameters can also use asymmetric encryption mode, encrypted with a public key. Therefore, based on the key negotiation request, the server will distribute multiple sets of quantum random numbers obtained from the quantum random number pool using the request parameters to obtain the key.

[0099] S402: Obtain multiple sets of keys fed back by the server, the key validity period of each key, and the key index corresponding to each key. The key is a key generated based on quantum random numbers and dispersed by the request parameters. Store the request parameters, the key and its corresponding key validity period and key index locally securely.

[0100] It is understandable that using request parameters such as AppID and MsgID to distribute quantum random numbers serves two purposes: firstly, to ensure that each application obtains a different key for each key negotiation; and secondly, by combining AppID and MsgID for distribution, it can ensure that each generated target key is unique, thus preventing replay attacks.

[0101] In this step, to securely store and manage encryption keys and prevent unauthorized access, the key and key index can be securely stored locally on the client using a KeyStore or KeyChain mechanism. Taking KeyStore as an example, a symmetric key (e.g., an AES key) is generated using KeyGenerator. Then, the target key, target key index, AppID, key negotiation message ID, key validity period, etc., are encrypted using the key generated by KeyGenerator with AES and stored in SharedPreferences or an application-embedded database. When needed, the key is first retrieved from KeyGenerator and then decrypted for use.

[0102] S403: Randomly obtain a set of target keys and the target key index corresponding to the target keys from the local machine, encrypt the request content based on the target keys, generate a data request, and send the data request to the server.

[0103] In this step, a set of keys is randomly selected from the local cache key list to encrypt the data. The encryption algorithm supports both international and national cryptographic methods, thereby generating a data request.

[0104] S404: Receive the response data from the server, decrypt the response data using the target key, and delete the target key and the target key index corresponding to the target key from the local secure storage.

[0105] In this step, since the server's response data is also encrypted using the target key, the client can decrypt the response data using the target key, thus completing the data communication. The used target key is deleted from locally stored secure keys, ensuring key uniqueness.

[0106] In one possible implementation, the encrypted data communication method provided in this embodiment further includes, before randomly obtaining a set of target keys and the target key index corresponding to the keys from the local storage, the following steps: performing state detection on each key in the local secure storage, the state including available, unavailable, and pending update; asynchronously updating the keys in the unavailable and pending update states; and using the keys in the available state as selectable keys.

[0107] Understandably, keys may have a lifespan limit, and expired keys are no longer secure. Continuing to use a key that has been revoked (e.g., discovered to be leaked or cracked) poses a security risk. Therefore, before using a key, it is necessary to determine its usability; otherwise, encryption failures and other problems may occur. The key's status can be determined based on whether the AppID matches the AppID of the pre-fetch number request, or whether the key's preset validity period has expired.

[0108] In this embodiment, determining the key status before randomly obtaining the target key can prevent the use of keys that may have been tampered with or damaged, thus ensuring the security of data encryption and decryption.

[0109] Furthermore, the aforementioned client may include a quantum key module for secure key storage and management. This quantum key module comprises four sub-modules: local key caching, state management, keystore / keychain operations, and encryption / decryption tools. The external interfaces provided by the quantum key module mainly include five methods: module initialization, quantum key update, encryption, decryption, and abnormal state settings. Internally, the quantum key module has three states: available, unavailable, and pending update. In the unavailable and pending update states, asynchronous quantum key updates will be initiated. When the module is in the available or pending update state, it will attempt to encrypt and decrypt data using the quantum key module. The server returns a key list, and a random key is read from the keystore / keychain to encrypt the result before storing it locally on the device.

[0110] For the quantum key module, the initialization process requires checking if the locally cached key exists and if the keystore / keychain can read the key normally. If the keystore / keychain read fails, the locally cached key needs to be cleared, and the module should be set to unavailable. If the AppId of the locally cached key does not match the AppId of the current pre-fetch request, or if the key's validity period has expired, the locally cached key will be cleared, and the module will be set to unavailable. If the locally cached key has exceeded its optimal usage time but not yet expired, a random set of keys will be temporarily stored for this data communication, and the module will be set to await updating.

[0111] Furthermore, when using the quantum key module to encrypt data, the module first randomly selects a set of keys from the local cached key list (a temporary key is used when the module status is pending update) to encrypt the data. The encryption algorithm supports both international and national cryptographic methods. After selecting a key from the local cached key list, the keystore / keychain key needs to be read and decrypted using AES before it can be used.

[0112] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0113] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0114] Figure 5 This is a schematic diagram of a server-side encrypted data communication device provided in an embodiment of this application. Figure 5 As shown, the encrypted data communication device includes:

[0115] The data request receiving module 51 is used to receive a data request from a client. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index.

[0116] The encrypted data processing module 52 is used to obtain a target key according to the target key index, decrypt the request content using the target key and perform business processing to generate response data. The target key is a quantum random number obtained from the quantum random number pool in advance according to the request parameters and the target key index, and then the quantum random number is distributed and processed. The quantum random number and the key index have a one-to-one correspondence.

[0117] The encryption module 53 is used to symmetrically encrypt the response data using the target key and then send it to the client.

[0118] In one possible design, the encrypted data processing module 52 is specifically used for:

[0119] Use the target key index to obtain the target quantum random number corresponding to the target key index from the quantum random number pool;

[0120] After obtaining the target quantum random number, the quantum random number is dispersed using the request parameters to obtain the target key.

[0121] In one possible design, a key generation module is also included, which is specifically used for:

[0122] Receive a key negotiation request from a client, the key negotiation request including request parameters;

[0123] Multiple sets of quantum random numbers are obtained, and each quantum random number has a unique corresponding key index;

[0124] The request parameters are used to disperse each quantum random number to obtain multiple keys. The dispersed keys and their corresponding key indices are then returned to the client.

[0125] In one possible design, the request parameters include an application-unique identifier (AppID) and a message-unique identifier (MsgID), and the key generation module is specifically used for:

[0126] Combine the AppID and the MsgID into a string using a preset data structure;

[0127] The string is hashed using a hash function to generate a hash value;

[0128] The hash value is combined with each quantum random number to obtain the key corresponding to each quantum random number.

[0129] Figure 6 This is a schematic diagram of a client-side encrypted data communication device provided in an embodiment of this application. Figure 6 As shown, the encrypted data communication device includes:

[0130] Request module 61 is used to initiate a key negotiation request, the key negotiation request including request parameters;

[0131] The key storage module 62 is used to obtain multiple sets of keys fed back by the server, the key validity period of each key and the key index corresponding to each key. The key is a key generated based on quantum random numbers and dispersed by the request parameters. The request parameters, the key and its corresponding key validity period and key index are stored locally in a secure manner.

[0132] The data encryption module 63 is used to randomly obtain a set of target keys and the target key index corresponding to the local key, encrypt the request content based on the target key, generate a data request, and send the data request to the server.

[0133] The decryption module 64 is used to receive the response data fed back by the server, decrypt the response data using the target key, and delete the target key and the target key index corresponding to the key from the local secure storage.

[0134] In one possible design, the key storage module 62 is also specifically used for:

[0135] Each key in the local secure storage is checked for status, which includes available, unavailable, and pending update.

[0136] Asynchronously update the keys that are in the unavailable and pending update states;

[0137] The key that is in the available state is used as the selectable key.

[0138] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0139] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0140] Figure 7 This is a schematic diagram of the structure of an electronic device for data storage based on object storage, provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device of this embodiment includes: at least one processor 70 ( Figure 7 (Only one is shown) a processor, a memory 71, and a computer program stored in the memory 71 and executable on at least one processor 70, which executes the computer program to implement the steps in any of the above method embodiments.

[0141] The electronic device may include, but is not limited to, a processor 70 and a memory 71. Those skilled in the art will understand that... Figure 7 This is merely an example of an electronic device and does not constitute a limitation on electronic devices. It may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, it may also include input / output devices, network access devices, etc.

[0142] The processor 70 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0143] The specific implementation process of processor 701 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0144] In some embodiments, memory 71 may be an internal storage unit of an electronic device, such as the memory of the electronic device. In other embodiments, memory 71 may be an external storage device of the electronic device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. Furthermore, memory 71 may include both internal and external storage units of the electronic device. Memory 71 is used to store operating systems, applications, bootloaders, data, and other programs, such as program code for computer programs. Memory 71 can also be used to temporarily store data that has been output or will be output.

[0145] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0146] The aforementioned computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0147] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the aforementioned electronic device.

[0148] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0149] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0150] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

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

Claims

1. A method for encrypted data communication, characterized in that, Applied to the server side, including: Before receiving a data request from a client, a key negotiation request from the client is received, the key negotiation request including request parameters generated by the client; In response to the key negotiation request, multiple sets of quantum random numbers are obtained from the quantum random number pool, each of which has a unique corresponding key index; the quantum random numbers are distributed using the request parameters to obtain multiple keys, and the distributed keys and their corresponding key indexes are returned to the client; Receive a data request from a client, the data request including request parameters, a target key index and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index; The target quantum random number corresponding to the target key index is obtained from the quantum random number pool using the target key index; after obtaining the target quantum random number, the quantum random number is dispersed using the request parameters to obtain the target key; the request content is decrypted and processed using the target key to generate response data; the quantum random number and the key index have a one-to-one correspondence. The response data is symmetrically encrypted using the target key and then sent to the client.

2. The method according to claim 1, characterized in that, The request parameters include an application-unique identifier (AppID) and a message-unique identifier (MsgID). These request parameters are used to distribute the quantum random numbers, resulting in multiple keys, including: Combine the AppID and the MsgID into a string using a preset data structure; The string is hashed using a hash function to generate a hash value; The hash value is combined with each quantum random number to obtain the key corresponding to each quantum random number.

3. A method for encrypted data communication, characterized in that, Applied to the client side, including: Initiate a key negotiation request, which includes request parameters; The system obtains multiple sets of keys, the key validity period of each key, and the key index corresponding to each key, which are generated based on quantum random numbers and dispersed by the request parameters. Each quantum random number has a unique corresponding key index. The system securely stores the request parameters, the keys, their corresponding key validity periods, and key indexes locally. The quantum random numbers and the key indexes have a one-to-one correspondence. A set of target keys and their corresponding target key indexes are randomly obtained locally. The request content is encrypted based on the target keys to generate a data request, which is then sent to the server. The system receives response data from the server, decrypts the response data using the target key, and deletes the target key and its corresponding target key index from local secure storage.

4. The method according to claim 3, characterized in that, Before the step of randomly obtaining a set of target keys and their corresponding target key indices from the local machine, the method further includes: Each key in the local secure storage is checked for status, which includes available, unavailable, and pending update. Asynchronously update the keys that are in the unavailable and pending update states; The key that is in the available state is used as the selectable key.

5. An encrypted data communication device, characterized in that, Applied to the server side, including: The key generation module is used to receive a key negotiation request from the client before receiving a data request from the client. The key negotiation request includes request parameters generated by the client. In response to the key negotiation request, multiple sets of quantum random numbers are obtained from the quantum random number pool, each of which has a unique corresponding key index; the quantum random numbers are distributed using the request parameters to obtain multiple keys, and the distributed keys and their corresponding key indexes are returned to the client; A data request receiving module is used to receive data requests from clients. The data request includes request parameters, a target key index, and request content, wherein the request content is data information encrypted using the target key corresponding to the target key index. An encrypted data processing module is used to obtain a target quantum random number corresponding to the target key index from a quantum random number pool using a target key index; after obtaining the target quantum random number, the quantum random number is dispersed using a request parameter to obtain a target key; the request content is decrypted using the target key and processed for business purposes to generate response data; the quantum random number and the key index have a one-to-one correspondence. An encryption module is used to symmetrically encrypt the response data using the target key before sending it to the client.

6. An encrypted data communication device, characterized in that, Applied to the client side, including: The request module is used to initiate a key negotiation request, which includes request parameters. A key storage module is used to obtain multiple sets of keys fed back by the server, the key validity period of each key, and the key index corresponding to each key. The keys are generated based on quantum random numbers and dispersed by the request parameters. Each quantum random number has a unique corresponding key index. The request parameters, the keys and their corresponding key validity periods and key indexes are stored locally and securely. The quantum random numbers and the key indexes have a one-to-one correspondence. The data encryption module is used to randomly obtain a set of target keys and the target key index corresponding to the key from the local machine, encrypt the request content based on the target key, generate a data request, and send the data request to the server. The decryption module is used to receive response data from the server, decrypt the response data using the target key, and delete the target key and its corresponding target key index from local secure storage.

7. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 4.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 4.

Images