Data transmission method, apparatus and system

This application relates to the technical field of network communication, and particularly to data transmission methods, devices, and systems.

Today, people are paying more and more attention to data security, especially data security in transit. Taking offline payments as an example, the server device can send a strategy for generating a payment code to the client device, which remembers the strategy. When the user needs to use a payment code, the client device can use a strategy to generate the payment code. The seller scans the payment code with a scanning device. The scanning device sends the information obtained as a result of the scan to the server device for verification. Money will be deducted after the information passes verification. In the process by which the server device sends the strategy to the client device, the security of the channel between the client device and the server device needs to be ensured. If a strategy issued by a server device is intercepted by a third-party hacker, users of the client device will incur significant losses.

In related technology, the same key is preset for all client devices and server devices. The server device can encrypt the transmitted information and use the key to send the ciphertext to the client device. The client device uses the key to break the ciphertext. However, if the key of the client device or the server device is leaked, all the client device and the server device share the same key, and all the client device and the server device are exposed to the security risk.

In another related technology, the client device can generate a pair of asymmetric keys, store the private key, and upload the public key to the server device. The server device uses the public key to encrypt the information that needs to be sent and sends the ciphertext to the client device. The client device uses the private key to decrypt the ciphertext. Since the asymmetric key algorithm uses different random numbers during each calculation, different asymmetric key pairs are generated during each calculation. Therefore, the asymmetric key pairs generated by different clients are also different, avoiding the problem of security risk of all client devices and server devices due to key leakage of client devices and server devices. On the other hand, since the ciphertext can be decrypted only with the private key corresponding to the public key pair, even if the public key is intercepted during the transmission of the public key, the ciphertext cannot be decrypted with the public key yet. This ensures information security. However, asymmetric keys require a complex encryption algorithm for encryption and a complex decryption algorithm for decryption, which takes a long time to encrypt and decrypt.

The present application provides data transmission methods, devices, and systems for solving information security and long-term encryption and decryption problems in current technology.

According to the first aspect of the embodiment of the present application, a data transmission method is provided. This method is applicable to the client, with the steps of generating an asymmetric key pair containing a first public key and a first private key, and sending a data request carrying the first public key to the server. The step of receiving the cryptography sent from the server and the second public key, where the second public key is the public key in the asymmetric key pair obtained by the server and obtained by the server. The asymmetric key pair created further contains a second private key, and the cryptography is shared. It is the information that encrypts the seed parameter for generating the offline payment code using key), and the shared key is used as the second private key and the first public key using the preset key agreement algorithm. A step that is a key generated based on, a step that uses a key agreement algorithm to generate a shared key based on a first private key and a second public key, and a cipher using the shared key. Includes steps to decrypt and get seed parameters. Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first secret generated using the key agreement algorithm. It is the same as the shared key based on the key and the second public key.

According to a second aspect of an embodiment of the present application, a data transmission method is provided, the method is applicable to a server, and a step of receiving a data request transmitted by a client carrying a first public key. And here the data request is to request the server to return a seed parameter to generate an offline payment code, and the first public key is of the asymmetric key pair generated by the client. The public key inside, and the asymmetric key pair generated by the client also contains a first private key, and a step to obtain an asymmetric key pair containing a second public key and a second private key. A step to generate a shared key based on a second private key and a first public key using a preset key agreement algorithm, and using the shared key to encrypt the seed parameter that the data request corresponds to. And using the key agreement algorithm, the client generates a shared key based on the first private key and the second public key, and then uses the shared key to decrypt the cipher and set the seed parameters. Includes a step of sending the cryptographic text obtained from the encryption and a second public key to the client so that it can be obtained.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

According to a third aspect of the embodiment of the present application, a data transmission method is provided, the data requester terminal generates an asymmetric key pair containing a first public key and a first private key, and the first The step of sending a data request carrying the public key of 1 to the data provider terminal, and the data provider terminal acquire an asymmetric key pair including the second public key and the second private key, and are preset. The step of generating a shared key based on the second private key and the first public key using the key agreement algorithm, and the target that the data provider terminal uses the shared key to correspond to the data request. The step of encrypting the data and sending the encrypted text obtained from the encryption and the second public key to the data requester terminal, and the data requester terminal uses the key agreement algorithm to use the first private key. And a second public key to generate a shared key, and then use the shared key to decrypt the cipher and retrieve the target data.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

According to a fourth aspect of an embodiment of the present application, a data transmission device is provided with a key generation module that generates an asymmetric key pair containing a first public key and a first private key, and a first public key. A request transmission module that sends a data request to the server, and an information reception module that receives the code sent by the server and the second public key. The second public key is acquired by the server. The public key in the asymmetric key pair that was created, the asymmetric key pair obtained by the server also contains a second private key, and the cipher is a seed parameter for generating an offline payment code using the shared key. The shared key is an information receiving module and its key, which is a key generated based on a second private key and a first public key using a preset key agreement algorithm. A shared key generator that uses a key agreement algorithm to generate a shared key based on a first private key and a second public key, and a shared key to decrypt the cipher to get seed parameters. It is equipped with an information decoding module.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key using the key agreement algorithm. And the same as the shared key generated based on the second public key.

According to a fifth aspect of the embodiment of the present application, a data transmission device is provided, which is a request receiving module for receiving a data request for carrying a first public key transmitted by a client, and is a data request. Is for requesting the server to return a seed parameter to generate an offline payment code, and the first public key is the public key in the asymmetric key pair generated by the client, which is the client. The asymmetric key pair generated by is further preliminarily with a request receiving module containing a first private key and a key acquisition module for acquiring an asymmetric key pair containing a second public key and a second private key. A shared key generation module that uses a configured key agreement algorithm to generate a shared key based on a second private key and a first public key, and a seed parameter that the data request corresponds to using the shared key. An information encryption module for encrypting the data and an information transmission module for transmitting the encryption text obtained from the encryption and the second public key to the client. The client uses a key agreement algorithm. It includes an information transmission module that generates a shared key based on a first private key and a second public key, decrypts a cipher using the shared parameter, and obtains a seed parameter.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key using the key agreement algorithm. And the same as the shared key generated based on the second public key.

According to a sixth aspect of the embodiment of the present application, a data transmission system is provided, which comprises a data requester device and a data provider device. The data requester device generates an asymmetric key pair containing a first public key and a first private key, and sends a data request carrying the first public key to the data provider device. The data contributor device obtains an asymmetric key pair containing a second public key and a second private key, and uses a preset key agreement algorithm to obtain the second private key and the first public key. Generate a shared key based on. The data provider device uses the shared key to encrypt the target data corresponding to the data request, and sends the ciphertext obtained from the encryption to the second public key in correspondence with the data requester device. .. The data requester device uses its key agreement algorithm to generate a shared key based on the first private key and the second public key, and then uses the shared key to decrypt the ciphertext and target it. Get the data.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

According to a seventh aspect of an embodiment of the present application, the data requester terminal generates a first symmetric key and sends a data request carrying the first symmetric key to the data provider terminal. In the sending step, the data provider terminal obtains the second symmetric key and uses a preset key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. The second symmetric key is different from the first symmetric key, the step and the data provider terminal use the shared key to encrypt the target data corresponding to the data request destination. , The step of associating the cryptographic text obtained from the encryption with the second symmetric key and sending it to the data requester terminal, and the data requester terminal using the key agreement algorithm to use the first symmetric key. A data transmission method is provided that includes a step of generating a shared key based on the second symmetric key, decrypting the cryptogram using the shared key, and retrieving the target data.

According to the eighth aspect of the embodiment of the present application, a data transmission system including a data requester device and a data provider device is provided. The data requester device generates a first symmetric key, sends a data request carrying the first symmetric key to the data provider device, and the data provider device acquires the second symmetric key and is preset. A shared key is generated based on the first symmetric key and the second symmetric key using the key agreement algorithm. Here, the second symmetric key is different from the first symmetric key. The data provider device uses the shared key to encrypt the target data to which the data request corresponds, and sends the ciphertext obtained from the encryption and the second symmetric key to the data requester device. The data requester device uses a key agreement algorithm to generate a shared key based on the first and second symmetric keys, and uses the shared key to decrypt the ciphertext and obtain the target data. ..

In the application of the data transmission methods, devices, and systems provided in the embodiments of the present application, an asymmetric key pair containing a first public key and a first private key is generated via a data requester terminal. A data request carrying the first public key is sent to the data provider terminal, and an asymmetric key pair containing the second public key and the second private key is obtained through the data provider terminal. A shared key is generated based on the second private key and the first public key using a preset key agreement algorithm, and then the shared key is used to generate the target data that the data request corresponds to. It is encrypted, and finally, the encryption text obtained from the encryption and the second public key are transmitted to the data requester terminal. The data requester terminal uses the same key agreement algorithm to generate a shared key based on the first private key and the second public key. The shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the second public key using the key agreement algorithm. Since it is the same as the shared key generated based on the public key, the provider terminal can use the shared key for encryption, and the data requester terminal uses the shared key for decryption. Can be done. Since the key for encrypting the target data and the key for decrypting the target data are the same, the symmetric encryption and decryption algorithm can be used to encrypt and decrypt the data. The symmetric encryption algorithm usually encrypts by a method such as shift encryption, while the asymmetric encryption algorithm encrypts by a method such as finding a large prime number. It turns out that the encryption process of the symmetric encryption algorithm is simpler than the encryption process of the asymmetric encryption algorithm. Therefore, this embodiment can avoid the drawbacks of long encryption and decryption times resulting from complex asymmetric encryption, and improve the efficiency of the decryption algorithm and encryption and decryption. In addition, it makes no sense for a hacker to hijack the public key because the full key is not exposed throughout the sending process.

In the application of the data transmission methods, devices, and systems provided in the embodiments of the present application, the first symmetric key can be obtained through the data requester terminal and the data request carrying the first symmetric key is data. Sent to the provider terminal, the second symmetric key is obtained through the data provider terminal, and a shared key is generated based on the first symmetric key and the second symmetric key using the pre-shared key agreement algorithm. The shared key is used to encrypt the target data to which the data request corresponds, and finally the cipher obtained from the encryption and the second symmetric key are sent to the data requester terminal. The data requester terminal uses the same key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. Since the data provider terminal and the data requester terminal use the same key agreement algorithm, the shared key generated by the data provider terminal and the shared key generated by the data requester terminal are the same, and the data request The person terminal decrypts the ciphertext via the generated shared key and acquires the target data. Since the shared key is different from the first and second symmetric keys, even if a hacker hijacks the symmetric key, the hacker will not know which key agreement algorithm the application used. As a result, hackers will not be able to decrypt the ciphertext, which will ensure data security throughout the transmission process. Also, because the key for encrypting the target data and the key for decrypting the target data are the same, the symmetric key encryption and decryption algorithms are long ciphers resulting from complex asymmetric encryption and decryption algorithms. Used for data encryption and decryption to avoid encryption and decryption time, thereby improving encryption and decryption efficiency.

It should be understood that the above general description and subsequent detailed description are only exemplary and descriptive and cannot limit the present application.

The accompanying drawings of the present specification are included in the present specification, which form a part thereof, show embodiments conforming to the present application, and are used together with the present specification to explain the principles of the present application.<figref num="1A">FIG. 1A is a schematic diagram of a data transmission application scenario provided by an exemplary embodiment of the present application.</figref><figref num="1B">FIG. 1B is a flowchart of an embodiment of the data transmission method provided by the present application.</figref><figref num="2">FIG. 2 is a flowchart of another embodiment of the data transmission method provided by the present application.</figref><figref num="3">FIG. 3 is a flowchart of another embodiment of the data transmission method provided by the present application.</figref><figref num="4">FIG. 4 is a block diagram of an embodiment of the data transmission system provided by the present application.</figref><figref num="5">FIG. 5 is a block diagram of an embodiment of the data transmission device provided by the present application.</figref><figref num="6">FIG. 6 is a block diagram of another embodiment of the data transmission apparatus provided by the present application.</figref><figref num="7">FIG. 7 is a flowchart of another embodiment of the data transmission method provided by the present application.</figref><figref num="8">FIG. 8 is a block diagram of another embodiment of the data transmission system provided by the present application.</figref>

Here, an exemplary embodiment will be described in detail with reference to the accompanying drawings. When the following description includes attached drawings, the same numbers in different attached drawings represent the same or similar elements unless otherwise noted. The embodiments described in the following embodiments do not represent all embodiments consistent with the present application. Conversely, they are merely examples of devices and methods described in detail in the appended claims and consistent with some aspects of the present application.

The terms used in this application are for purposes of explaining exemplary embodiments only and are not intended to limit this application. The singular forms "one," "the," and "this," as used in this application and the appended claims, have their meanings clearly stated in the context. Unless otherwise intended, it is intended to cover the plural. It is also understood that the term "and / or (and / or)" as used in the text refers to any or all possible combinations, including one or more related listed items. It should be.

The present application may use terms such as first, second, and third to describe various types of information, but it is understood that the information should not be limited to these terms. It should be. These terms are only intended to distinguish the same type of information. For example, without departing from the scope of the present application, the first information can also be referred to as the second information, and similarly, the second information can also be referred to as the first information. Depending on the context, the term "if" as used herein shall be construed as "at the time of ...", "at the time of ...", or "depending on the decision of ...". obtain.

People are paying more and more attention to data security, especially data security in transit. As shown in FIG. 1A, it is a schematic diagram of an application scenario of data transmission provided by an exemplary embodiment of the present application, in which data transmission is performed between different client devices and server devices. It is also possible. For example, the client device sends a data request to the server device, and the server device returns the corresponding target data according to the data request. In the sending process, hackers can intercept the target data being sent, which can result in loss to the user.

The same key can be preset for all client and server devices to ensure data security during transmission. The server device can encrypt the transmitted information and use the key to send the ciphertext to the client device. The client device uses the key to break the ciphertext. However, since all client devices and server devices share the same key, if the client device or server device key is leaked, all client devices and server devices are exposed to security risks. To avoid this situation, in other related technologies, the client device generates a pair of asymmetric keys, stores the private key, and uploads the public key to the server device. The server device uses the public key to encrypt the information that needs to be sent and sends the ciphertext to the client device. The client device uses the private key to decrypt the ciphertext. Since the asymmetric key algorithm uses different random numbers during each calculation, different asymmetric key pairs are generated during each calculation. Therefore, the asymmetric key pairs generated by different clients are also different, avoiding security risk issues for all client and server devices due to key leaks on the client or server devices. On the other hand, since the ciphertext can be decrypted only with the private key corresponding to the public key pair, even if the public key is intercepted during the transmission of the public key, the ciphertext cannot be decrypted with the public key. This ensures information security. However, asymmetric keys require a complex encryption algorithm for encryption and a complex decryption algorithm for decryption, which takes a long time to encrypt and decrypt.

To avoid information security issues in current technology and time-consuming encryption and decryption issues, the present application provides a data transmission method, as shown in FIG. 1B. FIG. 1B is a flowchart of an embodiment of the data transmission method provided by the present application. The method can include the following steps 101-108:

In step 101, the data requester terminal generates an asymmetric key pair that includes a first public key and a first private key.

In step 102, the data requester terminal transmits a data request carrying the first public key to the data provider terminal.

In step 103, the data provider terminal acquires an asymmetric key pair that includes a second public key and a second private key.

In step 104, the data provider terminal uses a preset key agreement algorithm to generate a shared key based on the second private key and the first public key.

In step 105, the data provider terminal uses the shared key to encrypt the target data to which the data request corresponds.

In step 106, the data provider terminal transmits the ciphertext obtained from the encryption and the second public key to the data requester terminal.

In step 107, the data requester terminal uses a key agreement algorithm to generate a shared key based on the first private key and the second public key.

In step 108, the data requester terminal uses the shared key to decrypt the ciphertext and acquire the target data.

Here, the data requester terminal is a terminal that requests data, and the data provider terminal is a terminal that provides data. In one example, the data requester terminal can be a client, the data provider terminal can be a server, and the client requests the server to return the target data. As an example, taking the target data, which is the seed parameter for generating an offline payment code, the data request can be a request to activate offline payment, the data requester terminal is the client, and And the data provider terminal is a server. The client sends a request to the server to activate offline payment, and the server returns seed parameters to the client according to the request. In another example, the server can also request data from the client, thus the data requester terminal can be the server and the data provider terminal can be the client. There are no restrictions on this.

From the above embodiments, an asymmetric key pair containing the first public key and the first private key can be generated via the data requester terminal, and the data request carrying the first public key is the data provider. It is sent to the terminal, an asymmetric key pair containing a second public key and a second private key is obtained through the data provider terminal, and the shared key is obtained using a preset key agreement algorithm. Generated based on the private key of 2 and the 1st public key, then the shared key is used to encrypt the target data that the data request corresponds to, and finally the cipher obtained from the encryption and the 2nd The public key is sent to the data requester terminal, and the data requester terminal uses the same key agreement algorithm to generate a shared key based on the first private key and the second public key. You can see that. The shared key generated based on the second private key and the first public key using the pre-shared key agreement algorithm uses the key agreement algorithm to create the first private key and the second public key. Since it is the same as the shared key generated based on, the data provider terminal can use the shared key for encryption, and the data requester terminal can use the shared key for decryption. it can. Since the key for encrypting the target data and the key for decrypting the target data are the same, the symmetric encryption and decryption algorithm can be used to encrypt and decrypt the data. The symmetric encryption algorithm usually encrypts by a method such as shift encryption, while the asymmetric encryption algorithm encrypts by a method such as finding a large prime number, so the encryption process of the symmetric encryption algorithm is It turns out to be simpler than the cryptographic process of an asymmetric cryptographic algorithm. Therefore, as a result of complex asymmetric encryption and decryption algorithms, this embodiment can avoid the drawbacks of long encryption and decryption times. Improve the efficiency of encryption and decryption. Since a different random number is used each time, a different asymmetric key pair is generated each time. Therefore, the asymmetric key pairs generated by different clients are also different for client and server devices. You can avoid security risk issues for all client and server devices as a result of key leakage. Moreover, since the complete key is not exposed throughout the sending process, it makes no sense for a hacker to hijack the public key. This ensures data security throughout the transmission process.

There are no special restrictions on the timing of generating an asymmetric key pair that includes the first public key and the first private key. For example, an asymmetric key pair may be generated prior to each data request transmission. As another example, an asymmetric key pair allows the data request to be retrieved so that a previously generated asymmetric key pair can be retrieved when the data request is sent, such as when other conditions are met. It may be generated at a timing other than immediately before transmission. For example, asymmetric key pairs can be generated at set intervals, and each newly generated asymmetric key pair replaces a previously generated asymmetric key pair.

In one example, the first public key and the first private key can be an asymmetric key pair generated using a key generation algorithm. Before each data request is sent, the data requester terminal uses a key generation algorithm to generate an asymmetric key pair containing a first public key and a first private key. Since the asymmetric key pair generated by the asymmetric key algorithm is different each time under normal conditions, this avoids the problem of leaking key pairs stored in a fixed way, resulting in insecure key pairs. It is used to encrypt all subsequent information.

After the data requester terminal acquires the first public key and the first private key, the data requester terminal can send a data request carrying the first public key to the data provider terminal. Here, the data request is a request for the target data.

In one example, the data requester terminal can include the first public key directly in the data request. This speeds up sending data requests.

In another example, sending a data request carrying the first public key to the data provider terminal causes the data requester terminal to use the private key in the requester's certificate to become the first public key. Includes signing and obtaining the first signature information. The requester certificate is a certificate issued by the designated organization to the data requester terminal.

The data requester terminal transmits a data request carrying the first public key and the first signature information to the data provider terminal.

In this method, the data provider terminal further verifies the first signature information based on the public key and the first public key in the requester's certificate, and if the verification is successful, the data provider terminal sends the ciphertext. Includes a step of sending a second public key to the data requester terminal.

Here, the designated institution usually refers to an institution that has authority and can issue a certificate. The certificate issued by the designated authority to the data requester terminal includes at least a private key and a public key. In other words, the requester certificate contains a private key and a public key.

As one signing method, the data requester terminal can perform a hash operation on the first public key using a hash algorithm. To obtain the first information summary, use the private key of the requester's certificate to encrypt the first information summary and obtain the first signature information. Next, based on the first signature information, a data request containing the first public key and the first signature information is generated. Then, the data request is transmitted to the data provider terminal. After the data provider terminal receives the data request, the data provider terminal can verify the first signature information based on the public key of the requester certificate and the first public key. If the verification is successful, the ciphertext and the second public key are sent to the data provider terminal.

Here, the data provider terminal may acquire the public key of the requester certificate by the following method. The data requester terminal broadcasts the data request to the data provider terminal while transmitting the data request in advance, or the data requester terminal transmits the data request to the data provider terminal.

As one of the verification methods, the data provider terminal can use a hash algorithm to perform a hash operation on the received first public key, obtain a second information summary, and request it. The public key of the personal certificate can be used to decrypt the first signature information to obtain a summary of the first information, and the summary of the first information matches the summary of the second information. Verify if it is. If consistent, it means that the verification was successful. The data provider terminal can execute the operation of transmitting the ciphertext and the second public key to the data requester terminal only after the verification is successful.

From the above-described embodiment, the following can be understood. Signing the first public key and successfully verifying the first signature information can ensure that the first public key has not been tampered with. On the other hand, the requester certificate guarantees that the data requester terminal is a secure terminal certified by a trusted authority. This ensures the security of the shared key negotiation process.

After the data provider terminal receives the data request, the data provider terminal can acquire an asymmetric key pair containing a second public key and a second private key. Here, the second public key and the second private key may be a key pair generated by using the key generation algorithm. It can be seen that the asymmetric key pair containing the first public key and the first private key, and the asymmetric key pair containing the second public key and the second private key are generated by the same key generation algorithm. Since the key generation algorithm uses different random numbers during each calculation, the asymmetric key pairs generated during different timing calculations are almost always different. Therefore, the asymmetric key pair generated by the data requester terminal is different from the asymmetric key pair generated by the data provider terminal under normal circumstances.

There are no special restrictions on the timing of generating an asymmetric key pair that includes the second public key and the second private key. For example, an asymmetric key pair may be generated each time a data request is received. As another example, an asymmetric key pair may be generated when the data request is received, but not when other conditions are met, so that the previously generated asymmetry when the data request is received. You can get a key pair. For example, asymmetric key pairs may be generated at set intervals. Each newly generated asymmetric key pair replaces a previously generated asymmetric key pair.

In one example, each time a data request is received, the data provider terminal uses a key generation algorithm to generate an asymmetric key pair containing a second public key and a second private key. Since the asymmetric key pair generated by the asymmetric key algorithm is different each time under normal conditions, this avoids the problem of leaking the fixedly stored key pair and encrypts using the key pair. All subsequent information that has been encrypted will be insecure.

After the data contributor terminal obtains an asymmetric key pair containing a second public key and a second private key, the data contributor terminal uses a preset key agreement algorithm to obtain the second private key. A shared key can be generated based on and the first public key. The data requester terminal then uses a key agreement algorithm to generate a shared key based on the first private key and the second public key.

The key consensus algorithm, also known as the key exchange algorithm, can be, for example, the ECDH algorithm. Here, ECDH is a DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve Cryptosystems). Therefore, both parties can negotiate to obtain a common key without sharing confidential information.

In this embodiment, the shared key generated based on the second private key and the first public key using the preset shared key agreement algorithm is the first secret using the key agreement algorithm. It is the same as the shared key generated based on the key and the second public key. As one of the implementation methods, the key agreement algorithm used by the data provider terminal and the data requester terminal is the same. The key generation algorithm used by the data provider terminal is also the same for the data requester terminal. The key agreement algorithm and the key generation algorithm satisfy the following conditions. A key agreement algorithm when the public key of one of the two asymmetric key pairs and the private key of the other asymmetric key pair are selected for any two asymmetric key pairs generated using the key generation algorithm. The negotiation results obtained using are the same.

It can be seen that the first public key is typically not equal to the second public key and the first private key is typically not equal to the second private key. It is not possible to infer the first private key from the first public key or the second private key from the second public key. Then, the shared key negotiated from the first private key and the second public key is the same as the shared key negotiated from the second private key and the first public key. The complete key is not always exposed throughout the sending process and data security is guaranteed throughout the sending process. Furthermore, the symmetric key encryption and decryption algorithms result from complex and asymmetric encryption and decryption algorithms because the key for encrypting the target data and the key for decrypting the target data are the same. Used for data encryption and decryption to avoid long encryption and decryption times. This improves the efficiency of encryption and decryption.

After the data provider terminal generates the shared key, the data provider terminal can use the shared key to encrypt the target data corresponding to the data request destination, and the ciphertext obtained from the encryption and the first The public key of 2 can be sent to the data requester terminal.

In one example, the data provider terminal can transmit the second public key directly to the data requester terminal in order to improve transmission efficiency.

In another example, the method further comprises the data provider terminal signing the second public key using the private key in the provider certificate to obtain the second signature information. The provider certificate is a certificate issued to the data provider terminal by a designated institution.

When the data provider terminal transmits the ciphertext obtained from the encryption and the second public key to the data requester terminal, the data provider terminal further transmits the second signature information to the data requester terminal.

The data requester terminal verifies the second signature information based on the public key of the provider certificate and the second public key. If the verification is successful, the data requester terminal decrypts the ciphertext.

Here, the designated institution can be an institution capable of issuing a certificate. The certificate issued to the data provider terminal by the designated institution includes at least a private key and a public key. In other words, the provider certificate contains a private key and a public key.

As one of the signing methods, the data provider terminal can use a hash algorithm to perform a hash operation on the second public key in order to obtain a third information summary. Encrypt the third information summary using the private key in the provider certificate, get the second signature information, and request the ciphertext, the second public key, and the second signature information. Send to the terminal.

The data requester terminal verifies the second signature information based on the public key of the provider certificate and the second public key. If the verification is successful, the data requester terminal decrypts the ciphertext.

Here, while the data requester terminal is transmitting the ciphertext and the second public key, the data provider terminal pre-broadcasts it to the data requester terminal, or the data provider terminal broadcasts it. The public key of the provider certificate can be obtained by sending it to the data requester terminal.

As one of the verification methods, the data requester terminal can use a hash algorithm to perform a hash operation on the received second public key in order to obtain a fourth information summary. Decrypt the second signature information using the public key in the provider certificate to obtain the third information summary, and verify that the third information summary matches the fourth information summary. To do. If consistent, it means that the verification was successful. The data requester terminal can execute the operation of decrypting the ciphertext only after the verification is successful.

From the above embodiment, signing the second public key and successfully verifying the second signature information can guarantee that the second public key has not been tampered with, while certifying the provider. It can be seen that the document guarantees that the data provider terminal is a secure terminal certified by a trusted authority, thereby ensuring the security of the shared key negotiation process.

As shown in FIG. 2, FIG. 2 is a flowchart of another embodiment of the data transmission method provided by the present application. In this embodiment, the data transmission method is applied to the transmission of seed parameters. This method is applicable to the client and may include the following steps 201-203:

In step 201, an asymmetric key pair containing a first public key and a first private key is generated, and a data request carrying the first public key is sent to the server.

Here, it is not necessary to set a special restriction on the generation timing of the asymmetric key pair consisting of the first public key and the first private key. For example, an asymmetric key pair may be generated prior to each data request transmission. As another example, the asymmetric key pair meets other conditions so that it can retrieve the asymmetric key pair that was generated before, but at a time other than just before the data request was sent. May be generated when For example, asymmetric key pairs may be generated at set intervals, and each newly generated asymmetric key pair replaces a previously generated asymmetric key pair.

In one example, the first public key and the first private key can be an asymmetric key pair generated using a key generation algorithm. Before the data request is sent, the client uses a key generation algorithm each time to generate an asymmetric key pair containing a first public key and a first private key. Since the asymmetric key pair generated by the asymmetric key algorithm is different each time under normal conditions, this avoids the problem of leaking fixedly stored key pairs, resulting in the use of key pairs. All subsequent encrypted information becomes insecure.

After the first public key and the first private key are obtained, a data request carrying the first public key can be sent to the server. Here, the data request is for requesting the server to return a seed parameter for generating an offline payment code.

In one example, the first public key is carried directly within the data request, which can speed up the transmission of the data request.

In another example, sending a data request carrying the first public key to the server includes:

Sign the first public key using the private key of the client certificate to get the first signing information. Here, the client certificate is a certificate issued to the client by the designated organization.

Sends a data request containing the first public key and the first signature information to the server and validates the first signature information so that the server uses the public key and the first public key in the client certificate. , If the verification is successful, send the ciphertext and the second public key to the client.

Here, the designated institution may be any institution capable of issuing a certificate. The certificate issued to the client by the designated authority includes at least a private key and a public key. That is, the client certificate consists of a private key and a public key. The server can obtain the public key of the client certificate either by the client pre-broadcasting it to the server or by sending the data request while the client sends it to the server.

In this embodiment, the private key in the client certificate can be used to sign the first public key. For example, a client can use a hash algorithm to perform a hash operation on a first public key to get a first summary of information. The private key in the client certificate is used to encrypt the first information summary to obtain the first signature information. Then, a data request for carrying the first public key and the first signature information is transmitted to the data provider terminal.

From the above embodiments, it can be seen that signing the first public key facilitates the server to verify the first signature information. Successful verification ensures that the first public key has not been tampered with. The client certificate, on the other hand, ensures that the client is a secure terminal certified by a trusted authority. This ensures the security of the shared key negotiation process.

In step 202, it receives the ciphertext and the second public key sent by the server. Here, the second public key is the public key in the asymmetric key pair obtained by the server. The asymmetric key pair obtained by the server also contains a second private key. The ciphertext is information in which seed parameters for generating an offline payment code using a shared key are encrypted. A shared key is a key generated based on a second private key and a first public key using a preset key agreement algorithm. In step 203, a key agreement algorithm is used to generate a shared key based on the first private key and the second public key. Then, the ciphertext is decrypted using the shared key to obtain the seed parameter.

Here, the key consensus algorithm, also known as the key exchange algorithm, can be, for example, the ECDH algorithm. Here, ECDH is a DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve Cryptography System). Therefore, both parties can negotiate a common key without sharing confidential information.

In this embodiment, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key using the key agreement algorithm. And the same as the shared key generated based on the second public key. In one embodiment, the key agreement algorithm used by the data provider terminal and the data requester terminal is the same. The key generation algorithm used by the data provider terminal and the data requester terminal is also the same. The key agreement algorithm and the key generation algorithm satisfy the following conditions. For any two asymmetric key pairs generated using the key generation algorithm. If the public key of one of the two asymmetric key pairs and the private key of the other asymmetric key pair are selected, the negotiation results obtained using the key agreement algorithm are the same.

The first public key is typically not equal to the second public key, and the first private key is typically not equal to the second private key, so the first public key to the first private key It is impossible to infer the second private key from the second public key, and the shared key negotiated between the first private key and the second public key is the second. It is the same as the shared key negotiated between the second private key and the first public key, the complete key is not always exposed throughout the sending process, and data security is guaranteed throughout the sending process. You can see that. In addition, because the key for encrypting the seed parameter and the key for decrypting the seed parameter are the same, the symmetric key encryption and decryption algorithm encrypts and decrypts the seed parameter to avoid long encryption. Used to decrypt, it improves the decryption time resulting from complex asymmetric encryption and decryption algorithms, thereby improving encryption and decryption efficiency.

In an optional implementation, the client can be in an electronic device, especially a wearable device. Since wearable devices often have configurations that support relatively low performance, symmetric encryption and decryption algorithms are less demanding on resources when this solution is used in wearable devices. While ensuring the security of the transmission, this solution significantly improves performance and improves the efficiency of the entire transmission process. In addition, wearable devices may include smart bracelets. Implementing the embodiment through the smart bracelet can not only guarantee the transmission security of the seed parameters, but also the efficiency of the entire transmission process.

In one example, the method in the embodiment can be performed via a secure element (SE). This makes it possible to generate an asymmetric key, generate a shared key, and decrypt a ciphertext in the SE. In addition, seed parameters can also be stored in the SE. Since the SE has an anti-cracking function, the SE can provide seed parameters with a very high level of security.

Seed parameters can also be stored in the SE, while SE access rights can also be set by generating payment codes controlled through fingerprint recognition, pulse recognition, face recognition, or other verification methods. , Thereby providing the entire payment code with a very high level of security.

As shown in FIG. 3, FIG. 3 is a flowchart of another embodiment of the data transmission method provided by the present application. In this embodiment, the seed parameter is transmitted using the data transmission method. When this method is used on a server, it may include steps 301-303 below.

In step 301, the first public key is carried and the data request sent by the client is received. Here, the data request is for requesting the server to return a seed parameter for generating an offline payment code. The first public key is the public key in the asymmetric key pair generated by the client, and the asymmetric key pair generated by the client further contains the first private key.

Here, when the data request is received, step 302 can be executed directly if the data request carries only the first public key. When the data request carries the first public key and the first signature information, the first signature information is validated based on the public key and the first public key in the client certificate. Step 302 is performed only after successful verification.

Here, the server can obtain the public key of the client certificate by the method that the client broadcasts it to the server in advance or the client sends it to the server while sending the data request.

As one of the verification methods, the server can use a hash algorithm to perform a hash operation on the received first public key to obtain the second summary information, which is published in the client certificate. The key can be used to decrypt the first signature information to obtain the first information summary, and verify that the first information summary matches the second information summary. can do. If consistent, it means that the verification was successful. The server then returns the ciphertext and the second key to the client.

In step 302, an asymmetric key pair containing a second public key and a second private key is obtained and based on the second private key and the first public key using a preset key agreement algorithm. To generate a shared key.

In step 303, the shared key is used to encrypt the seed parameter corresponding to the data request, and the ciphertext obtained from the encryption and the second public key are sent to the client. It uses a key agreement algorithm to allow the client to generate a shared key based on the first private key and the second public key, use the shared key to decrypt the ciphertext, and get the seed parameters. ..

Here, it is not necessary to set a special restriction on the generation timing of the asymmetric key pair including the second public key and the second private key. For example, an asymmetric key pair may be generated each time a data request is received. As another example, an asymmetric key pair is otherwise satisfied at a time other than when the data request is received so that when the data request is received, the previously generated asymmetric key pair can be obtained. Sometimes it may be generated. For example, asymmetric key pairs may be generated at set intervals, and each newly generated asymmetric key pair replaces a previously generated asymmetric key pair.

In one example, the second public key and the second private key can be a key pair generated using a key generation algorithm. For example, each time a data request is received, the server uses a key generation algorithm to generate an asymmetric key pair containing a second public key and a second private key. Since the asymmetric key pair generated by the asymmetric key algorithm is different each time under normal conditions, this avoids the problem of leaking fixedly stored key pairs, resulting in the use of key pairs. All subsequent encrypted information becomes insecure.

Here, the asymmetric key pair including the first public key and the first private key, and the asymmetric key pair including the second public key and the second private key are generated by the same key generation algorithm. Since the key generation algorithm uses different random numbers during each calculation, the asymmetric key pairs generated during the calculation at different times appear to be different. Therefore, the asymmetric key pair generated by the client is different from the asymmetric key pair generated by the server under normal circumstances.

After the server obtains the second public key and the second private key, the server uses a preset key agreement algorithm to obtain a shared key based on the second private key and the first public key. Can be generated.

The key consensus algorithm, also known as the key exchange algorithm, can be, for example, the ECDH algorithm. Here, ECDH is a DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve Cryptography System). Therefore, both parties can negotiate a common key without sharing confidential information.

In this embodiment, the shared key generated based on the second private key and the first public key using the pre-shared key agreement algorithm is the first private key and the first private key generated using the key agreement algorithm. It is the same as the shared key generated based on the public key of 2. In one embodiment, the key agreement algorithm used by the data provider terminal and the data requester terminal is the same, and the key generation algorithm used by the data provider terminal and the data requester terminal is also the same. The key agreement and key generation algorithms are for any two asymmetric key pairs generated using the key generation algorithm, the public key of one of the two asymmetric key pairs and the private key of the other asymmetric key pair. If is selected, it satisfies the condition that, as a result of negotiation, what is obtained using the key agreement algorithm is the same.

After the server obtains the shared key, the server uses the shared key to encrypt the seed parameters that the data request corresponds to, and sends the ciphertext obtained from the encryption and the second public key to the client. Can be done. The seed parameter is a seed parameter for generating an offline payment code. After the server receives the data request, the server can get the seed parameters according to the data request. The seed parameters supported by the client may be the same or different, depending on the actual requirements.

Regarding the transmission of the second public key, in one example, the second public key can be transmitted directly to the client in order to increase the transmission speed.

In another example, the method of the present application further comprises signing the second public key with the private key in the server certificate to obtain the second signature information. Here, the server certificate is a certificate issued to the server by the designated organization.

So that the client validates the second signature information based on the public key and the second public key in the server certificate while sending the ciphertext obtained from the encryption and the second public key to the client. The second signature information is also sent to the client. If the verification is successful, the client decrypts the ciphertext.

Here, the designated institution can be an institution capable of issuing a certificate. The certificate issued to the server by the designated authority includes at least a private key and a public key. In other words, the server certificate contains a private key and a public key. The client can obtain the public key of the server certificate either by the server pre-broadcasting it to the client or by sending it to the client while the server sends the ciphertext and the second public key. it can.

As one signing method, the server can use a hash algorithm to perform a hash operation on the second public key to obtain a summary of the third piece of information. You can use the private key in the server certificate to encrypt the third information and get the second signature information, then the ciphertext, the second public key, and the second signature information. Can be sent to the client.

The client can verify the second signature information based on the public key and the second public key in the server certificate. If successful, the client decrypts the ciphertext.

As one of the validation methods, the client can use a hash algorithm to perform a hash operation on the second public key to obtain a fourth information summary, which is the public key of the server certificate. Can be used to decrypt the second signature information, obtain the third information summary, and verify that the third information summary matches the fourth information summary. If consistent, it means that the verification was successful. The client can perform the ciphertext decryption operation only after the verification is successful.

From the above embodiments, it can be seen that signing the second public key and successfully verifying the second signature information can ensure that the second public key is not tampered with. The server certificate, on the other hand, ensures that the server is a secure end authenticated by an authorized authority, thereby ensuring the security of the shared key negotiation process.

Corresponding to one embodiment of the data transmission method provided by the present application, the present application further provides embodiments of a data transmission device and a data transmission system.

Referring to FIG. 4, it is a block diagram of an embodiment of the data transmission system provided by the present application.

The system 40 includes a data requester device 41 and a data provider device 42.

The data requester device 41 generates an asymmetric key pair including the first public key and the first private key, and transmits a data request carrying the first public key to the data provider device 42.

The data contributor device 42 obtains an asymmetric key pair containing a second public key and a second private key, and uses a preset key agreement algorithm to obtain the second private key and the first public key. Generate a shared key based on the key.

The data provider device 42 encrypts the target data corresponding to the data request using the shared key, and transmits the ciphertext obtained by the encryption and the second public key to the data requester device 41.

The data requester device 41 uses a key agreement algorithm to generate a shared key based on the first private key and the second public key, and then uses the shared key to decrypt the ciphertext and target it. Get the data.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

In the optional implementation method, the data requester device 41 uses the private key in the requester certificate to sign the first public key to obtain the first signature information, and the first public key and A data request carrying the first signature information is transmitted to the data provider device 42. Here, the requester certificate is a certificate issued to the data requester device by the designated organization.

Before the data provider device 42 returns the ciphertext and the second public key to the data requester device 41, the data provider device 42 first based on the public key of the requester certificate and the first public key. Verify the signature information of and judge that the verification was successful.

In an optional implementation method, the data provider device 42 signs the second public key using the private key in the provider certificate to obtain the second signature information. When the ciphertext obtained by the encryption and the second public key are transmitted to the data requester device 41, the data provider device 42 also transmits the second signature information to the data requester device 41. Here, the provider certificate is a certificate issued to the data provider device 42 by the designated organization.

Before the data requester device 41 decrypts the ciphertext, the data requester device 41 verifies and verifies the second signature information based on the public key and the second public key in the provider certificate. Judges as successful.

Referring to FIG. 5, it is a block diagram of an embodiment of the data transmission apparatus provided by the present application.

This device includes a key generation module 51, a request transmission module 52, an information reception module 53, a shared key generation module 54, and an information decryption module 55.

The key generation module 51 is for generating an asymmetric key pair including a first public key and a first private key.

The request transmission module 52 is for transmitting a data request carrying the first public key to the server.

The information receiving module 53 is for receiving the ciphertext and the second public key sent by the server. The second public key is the public key in the asymmetric key pair obtained by the server, and the asymmetric key pair obtained by the server further includes a second private key. The ciphertext is information that encrypts the seed parameter for generating an offline payment code using a shared key, and the shared key is a second private key and a second using a preset key agreement algorithm. It is a key generated based on the public key of 1.

The shared key generation module 54 is for generating a shared key based on the first private key and the second public key by using a key agreement algorithm.

The information decryption module 55 is for decrypting the ciphertext using the shared key and acquiring the seed parameter.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

In an optional implementation, the request sending module 52 signs the first public key with the private key of the client certificate, which is the certificate issued to the client by the designated authority, and the first signature. It retrieves the information and sends a data request to the server that carries the first public key and the first signing information so that the server uses the public key and the first public key in the client certificate. The purpose is to verify the signature information of and, if the verification is successful, send the cryptography and the second public key to the client.

Referring to FIG. 6, it is a block diagram of another embodiment of the data transmission apparatus provided by the present application.

This device includes a request receiving module 61, a key acquisition module 62, a shared key generation module 63, an information encryption module 64, and an information transmission module 65.

Here, the request receiving module 61 is for receiving a data request carrying the first public key sent by the client, so that the data request returns a seed parameter for generating an offline payment code. The first public key is the public key in the asymmetric key pair generated by the client. The asymmetric key pair generated by the client further contains a first private key.

The key acquisition module 62 is for acquiring an asymmetric key pair including a second public key and a second private key.

The shared key generation module 63 is for generating a shared key based on the second private key and the first public key by using a preset key sharing algorithm.

The information encryption module 64 is for encrypting the seed parameter corresponding to the data request by using the shared key.

The information transmission module 65 uses a key agreement algorithm to generate a ciphertext and a second ciphertext obtained from the encryption so that the client generates a shared key based on the first private key and the second public key. It is for sending the public key to the client and then using the shared key to decrypt the ciphertext and get the seed parameters.

Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

In an optional implementation, device 60 further comprises a signing module for signing the second public key with the private key in the server certificate to obtain the second signature information (see FIG. 6). Is not shown). Here, the server certificate is a certificate issued to the server by the designated organization.

The information transmission module 65 also provides the ciphertext and the second public key obtained from the cryptography so that the client validates the second signature information based on the public key and the second public key in the server certificate. Is used to send a second signature information to the client when sending to the client. After successful verification, the client decrypts the ciphertext.

Based on this, the present application further provides wearable devices. The wearable device generates an asymmetric key pair containing a first public key and a first private key, and sends a data request carrying the first public key to the server, so that the ciphertext and the first sent by the server are sent. It consists of an SE chip to receive 2 public keys. Here, the second public key is the public key of the asymmetric key pair obtained by the server, the asymmetric key pair further obtained by the server includes the second private key, and the cipher statement is the shared key. Information obtained by encrypting the seed parameter for generating an offline payment code using, and the shared key is a second private key and a first public key using a preset key agreement algorithm. It is a key generated based on the key. The wearable device also uses a key agreement algorithm to generate a shared key based on a first private key and a second public key, which is then used to decrypt the ciphertext and seed parameters. It consists of SE chips to get. Here, the shared key generated based on the second private key and the first public key using the preset key agreement algorithm is the first private key and the first private key generated based on the key agreement algorithm. It is the same as the shared key generated based on the public key of 2.

From the above-described embodiment, it can be seen that the generation of the asymmetric key pair, the generation of the shared key, the storage of the target data, and the decryption of the ciphertext are performed by the SE through the configuration of the SE in the wearable device. In addition, the SE has a cracking prevention feature, which allows the SE to provide target data with a very high level of security.

To avoid information security and long-term encryption and decryption issues in current technology, the present application further provides alternative data transmission methods, as shown in FIG. FIG. 7 is a flowchart of another embodiment of the data transmission method provided by the present application. This method can include the following steps 701-708. In step 701, the data requester terminal generates a first symmetric key. In step 702, the data requester terminal sends a data request carrying the first symmetric key to the data provider terminal. In step 703, the data provider terminal acquires a second symmetric key that is different from the first symmetric key. At step 704, the data provider terminal uses a preset key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. At step 705, the data provider terminal uses the shared key to encrypt the target data to which the data request corresponds. In step 706, the data provider terminal transmits the ciphertext obtained from the encryption and the second symmetric key to the data requester terminal. At step 707, the data requester terminal uses a key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. At step 708, the data requester terminal uses the shared key to decrypt the ciphertext and obtain the target data.

From the above-described embodiment, the first symmetric key may be acquired via the data requester terminal, and the data request carrying the first symmetric key is transmitted to the data provider terminal and via the data provider terminal. The second symmetric key is obtained, a shared key is generated based on the first symmetric key and the second symmetric key using a preset key agreement algorithm, and then the shared key is used. The target data corresponding to the data request is encrypted, and finally the ciphertext obtained from the encryption and the second symmetric key are transmitted to the data requester terminal. It can be seen that the data requester terminal uses the same key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. Since the data provider terminal and the data requester terminal use the same key agreement algorithm, the shared key generated by the data provider terminal and the shared key generated by the data requester terminal are the same, and the data requester terminal Can decrypt the ciphertext via the generated shared key. It gets the target data. Since the asymmetric key algorithm uses different random numbers during each calculation, it can be seen that different asymmetric key pairs are generated during each calculation. Therefore, the asymmetric key pairs generated by different clients are also different, avoiding security risk issues for all client and server devices resulting from key leaks on the client or server devices. On the other hand, since the shared key is different from the first symmetric key and the second symmetric key, even if the hacker hijacks the symmetric key, the hacker does not know which key agreement algorithm the application used. As a result, hackers cannot decrypt the ciphertext, which ensures data security throughout the transmission process. Furthermore, since the key for encrypting the target data and the key for decrypting the target data are the same, the data is encrypted and decrypted using symmetric key encryption and decryption algorithms, which is complex and asymmetric. Avoid long encryption and decryption times resulting from encryption and decryption algorithms, thereby encrypting

Here, the key generation algorithm for generating the first symmetric key and the key generation algorithm for generating the second symmetric key may be the same or different, and are not particularly limited. The second symmetric key is different from the first symmetric key because the symmetric key generated by the key generation algorithm is different each time.

After acquiring the first symmetric key, the data requester terminal can generate a data request that carries the first symmetric key based on the first symmetric key. Here, the data request is used to request the target data. After the data request is generated, it can be sent to the data provider terminal.

In one example, the data requester terminal can speed up sending a data request by using the data request to carry the first symmetric key directly.

In another example, sending a data request carrying the first symmetric key to the data provider terminal causes the data requester terminal to use the private key in the requester certificate to become the first symmetric key. Includes signing and obtaining the first signature information. Here, the requester certificate is a certificate issued by the designated organization to the data requester terminal.

The data requester terminal transmits a data request carrying the first symmetric key and the first signature information to the data provider terminal.

Here, the designated institution may be any institution capable of issuing a certificate. The certificate issued to the data requester terminal by the designated institution includes at least a private key and a public key.

After the data provider terminal receives the data request, the data provider terminal can verify the first signature information based on the public key of the requester certificate and the first symmetric key. After successful verification, the data provider terminal performs an operation of returning the ciphertext and the second symmetric key to the data requester terminal.

From the above embodiment, it may be guaranteed by signing the first symmetric key and successfully verifying the first signature information, the first symmetric key has not been tampered with, while requesting. It can be seen that the person certificate ensures that the data requester terminal is a secure terminal authenticated by a trusted authority, thereby ensuring the security of the shared key negotiation process.

After the data provider terminal receives the data request, the data provider terminal can acquire the second symmetric key. After the data contributor terminal obtains the second symmetric key, the data contributor terminal uses a preset key agreement algorithm to obtain a shared key based on the first symmetric key and the second symmetric key. Can be generated.

Here, the key consensus algorithm, also known as the key exchange algorithm, can be, for example, the ECDH algorithm. Here, ECDH is a DH (Diffie-Hellman) key exchange algorithm based on ECC (Elliptic Curve Cryptography System). Therefore, both parties can negotiate a common key without sharing confidential information.

The data provider terminal can use the shared key to encrypt the target data that the data request responds to and sends the ciphertext obtained from the encryption and the second symmetric key to the data requester terminal. ..

In one example, the data provider terminal transmits the second symmetric key directly to the data requester terminal to improve transmission efficiency.

In another example, the data provider terminal uses the private key in the provider certificate to sign the second symmetric key to obtain the second signature information. Here, the provider certificate is a certificate issued to the data provider terminal by the designated organization.

When the data provider terminal transmits the ciphertext obtained from the encryption and the second symmetric key to the data requester terminal, the data provider terminal further transmits the second signature information to the data requester terminal.

Here, the designated institution can be an institution capable of issuing a certificate. The certificate issued to the data provider terminal by the designated institution includes at least a private key and a public key. In other words, the provider certificate contains a private key and a public key.

The data requester terminal verifies the second signature information based on the public key and the second symmetric key in the provider certificate. After successful verification, the data requester terminal performs a step of decrypting the ciphertext.

From the above embodiment, signing the second symmetric key and successfully verifying the second signature information can ensure that the second symmetric key has not been tampered with, while the provider certificate. Will ensure that the data contributor terminal is a secure terminal certified by a trusted authority, which will ensure the security of the shared key negotiation process.

Corresponding to the embodiment of the data transmission method provided by the present application, the present application further provides an embodiment of a data transmission system.

FIG. 8 is a block diagram of another embodiment of the data transmission system provided by the present application.

The system 80 includes a data requester device 81 and a data provider device 82.

The data requester device 81 generates the first symmetric key and transmits the data request carrying the first symmetric key to the data provider device 82.

The data contributor device 82 acquires the second symmetric key and uses a preset key agreement algorithm to generate a shared key based on the first symmetric key and the second symmetric key. Here, the second symmetric key is different from the first symmetric key.

The data provider device 82 uses the shared key to encrypt the target data to which the data request corresponds, and sends the ciphertext obtained from the encryption and the second common key to the data requester device 81. To do.

The data requester device 81 uses a key agreement algorithm to generate a shared key based on a first symmetric key and a second symmetric key. Decrypt the ciphertext using the shared key to get the target data.

The process for achieving the effects of each module in the above apparatus is detailed in the process of accomplishing the corresponding steps in the method described above, and unnecessary details are not repeated.

Since the embodiment of the device basically corresponds to the embodiment of the method, refer to the corresponding part of the embodiment of the method of the present application for the related part of the device. Embodiments of the above-mentioned device are merely examples. The units described as separate components may or may not be physically separate, and the components displayed as units may or may not be physical units, i.e. They may be co-located or distributed across multiple network units. Some or all of the modules may be selected according to the actual need to achieve the objectives of the solution of this application. Those skilled in the art can understand and carry it out without creative effort.

After reviewing the specification and implementing the inventions applicable herein, one of ordinary skill in the art will readily come up with other embodiments of the present application. This application is intended to cover any amendment, use, or adaptive modification of this application. These modifications, uses, or adaptive changes are subject to the general principles of this application. It includes general general knowledge or conventional technical means in the technical field not filed by this application. The description and embodiments are merely exemplary. The true scope and purpose of this application is stated in the appended claims.

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