Data processing method, service side, client, storage medium, and computer program product

Abstract

The application provides a data processing method and related products. A method executed by a service side includes: receiving a backup data package corresponding to ciphertext data, the ciphertext data being encrypted plaintext data, and the backup data package including a second public key; receiving a signed first recovery strategy package from a third client; the first recovery strategy package including a recovery strategy for recovering the ciphertext data, and the first recovery strategy package having a first signature obtained by signing the first recovery strategy package using a second private key; and in a case where the first signature is verified to be passed using the second public key, determining the first recovery strategy package as a recovery strategy package corresponding to the ciphertext data. By separating and managing the recovery strategy from the data backup package, the recovery strategy can be flexibly adjusted after data backup is completed. The recovery strategy can be updated according to changing security requirements and business scenarios without re-backing up data, thereby providing higher flexibility and adaptability for data recovery and protection.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data processing, in particular to a data processing method, a service side, a client, a storage medium and a computer program product. BACKGROUND

[0002] In cloud storage and distributed systems, data backup and recovery is an important measure to ensure data security and system reliability. Traditional backup systems usually tightly couple data recovery strategies with backup data packages, that is, there is a high dependency relationship between data recovery strategies and backup data. For example, when a data recovery strategy needs to be updated, the backup data package closely related to it also needs to be modified at the same time, resulting in a lack of flexibility in updating data recovery strategies. Once the data backup is completed, the recovery strategy cannot be modified. This design makes it difficult for the system to adapt to changes in different application scenarios and security requirements. SUMMARY

[0003] The purpose of the embodiments of the present application is to provide a data processing method, a service side, a client, a storage medium and a computer program product.

[0004] The embodiments of the present application adopt the following technical solutions: a data processing method applied to a service side, the method comprising:

[0005] receiving a backup data package corresponding to ciphertext data, the ciphertext data being encrypted plaintext data, and the backup data package comprising at least a second public key;

[0006] receiving a signed first recovery strategy package from a third client, wherein the first recovery strategy package comprises a recovery strategy for recovering the ciphertext data, the first recovery strategy package has a first signature, and the first signature is obtained by signing the first recovery strategy package using the second private key, and the second private key corresponds to the second public key;

[0007] In the case where the first signature is verified to be valid using the second public key, the first recovery strategy package is determined as the recovery strategy package corresponding to the ciphertext data.

[0008] In some embodiments, determining the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data comprises:

[0009] In the case where the service side has a second recovery strategy package corresponding to the ciphertext data, updating the second recovery strategy package to the first recovery strategy package;

[0010] wherein the second recovery strategy package is different from the first recovery strategy package.

[0011] In some embodiments, the recovery strategy includes any one of the following recovery manners:

[0012] Single key recovery;

[0013] Multi-factor combination recovery;

[0014] Directly providing the recovery of the plaintext data.

[0015] In some embodiments, further comprising:

[0016] In response to a request from a first client to recover the ciphertext data, generating a second temporary key;

[0017] Encrypting the first temporary key using the second temporary key to obtain a first ciphertext;

[0018] Based on the number of factors required to recover the ciphertext data in the recovery strategy, dispersing the second temporary key into a plurality of sub-keys, wherein the number of sub-keys is the same as the number of factors;

[0019] Generating a corresponding first factor key for each factor, respectively, and encrypting the corresponding sub-key using the first factor key to obtain a plurality of second ciphertexts;

[0020] Returning a recovery data packet to the first client, the recovery data packet including the first ciphertext and the plurality of second ciphertexts.

[0021] In some embodiments, further comprising:

[0022] Receiving a message authentication code corresponding to the backup data packet; the backup data packet further includes a third ciphertext;

[0023] Decrypting the third ciphertext to obtain the first temporary key;

[0024] In the case where the message authentication code based on the backup data packet is verified, saving the backup data packet.

[0025] The embodiments of the present application also provide a data processing method, applied to a third client, the method comprising:

[0026] Setting a first recovery strategy package, wherein the first recovery strategy package includes a recovery strategy for recovering ciphertext data, and the ciphertext data is encrypted plaintext data;

[0027] Obtaining the first signature, which is obtained by signing the first recovery strategy package using the second private key;

[0028] The first recovery policy package after signature is sent to a service side, so that the service side determines the first recovery policy package as the recovery policy package corresponding to the ciphertext data if the first signature is verified by using a second public key; the second public key corresponds to the second private key.

[0029] In some embodiments, obtaining the first signature comprises:

[0030] determining a second private key for signature;

[0031] based on the use permission owned by the third client, calling the second private key to sign the first recovery policy package to obtain a first signature; the second private key is not stored on the third client;

[0032] receiving the first signature.

[0033] In some embodiments, obtaining the first signature comprises:

[0034] determining a second private key for signature;

[0035] using the second private key to sign the first recovery policy package to obtain a first signature;

[0036] The method further comprises:

[0037] sending a backup data package corresponding to the ciphertext data to a service side, the backup data package at least including the second public key.

[0038] In some embodiments, the method further comprises:

[0039] generating a first temporary key;

[0040] encrypting plaintext data using the first temporary key to generate ciphertext data;

[0041] encrypting the first temporary key to generate a third ciphertext; the backup data package further includes the third ciphertext.

[0042] Embodiments of the present application also provide a data processing method, applied to a second client, the method comprising:

[0043] generating a first temporary key;

[0044] encrypting plaintext data using the first temporary key to generate ciphertext data;

[0045] encrypting the first temporary key to generate a third ciphertext;

[0046] determining a second private key and a corresponding second public key, wherein the second private key is used to sign a recovery policy package, and the recovery policy package comprises a recovery policy for recovering the ciphertext data;

[0047] sending a backup data package corresponding to the ciphertext data to a service side, wherein the backup data package comprises the third ciphertext and the second public key.

[0048] In some embodiments, the method further comprises:

[0049] determining a message authentication code of the backup data package using the first temporary key;

[0050] sending the message authentication code to the service side.

[0051] Embodiments of the present application also provide a service side, comprising:

[0052] at least one first processor configured to receive a backup data package corresponding to ciphertext data, wherein the ciphertext data is encrypted plaintext data, and the backup data package comprises at least a second public key; receive a signed first recovery policy package from a third client; wherein the first recovery policy package comprises a recovery policy for recovering the ciphertext data, and the first recovery policy package has a first signature, and the first signature is obtained by signing the first recovery policy package using a second private key, and the second private key corresponds to the second public key; and in a case where the first signature is verified to be valid using the second public key, determine the first recovery policy package as a recovery policy package corresponding to the ciphertext data.

[0053] Embodiments of the present application also provide a client, wherein a computer program / instruction of the client, when executed by a processor, implements part of the steps of the method.

[0054] Embodiments of the present application also provide a storage medium having a computer program / instruction stored thereon, and the computer program / instruction, when executed by a processor, implements the method according to any one of the above embodiments.

[0055] Embodiments of the present application also provide a computer program product comprising a computer program / instruction, and the computer program / instruction, when executed by a processor, implements the steps of the method according to any one of the above embodiments.

[0056] The embodiments of the present application have the following beneficial effects:

[0057] By separating the recovery strategy from the data backup package for management, that is, sending the recovery strategy package including the recovery strategy corresponding to the recovery ciphertext data to the service side as a separate data package, the user can update the recovery strategy according to the changing security requirements and business scenarios without re-updating the backup data package, that is, the recovery strategy can be updated at any time after the backup data package is backed up up, so that the update of the recovery strategy is more flexible, and higher flexibility and adaptability are provided for data recovery and protection. BRIEF DESCRIPTION OF DRAWINGS

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the drawings needed to be used in the embodiments or the related art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0059] Figure 1 The architecture schematic diagram of the service side and the client of the embodiments of the present application;

[0060] Figure 2 The flowchart of a data backup, data recovery strategy setting and data recovery method shown by an exemplary embodiment of the present application;

[0061] Figure 3 The flowchart of the backup data package sending method executed by the second client of the present application;

[0062] Figure 4 The flowchart of the first recovery strategy package sending method executed by the third client of the present application;

[0063] Figure 5 The flowchart of the data processing method executed by the service side of the present application;

[0064] Figure 6 The structure block diagram of the service side of the present application. DETAILED DESCRIPTION

[0065] The various schemes and features of the present application are described herein with reference to the accompanying drawings.

[0066] It should be understood that various modifications can be made to the embodiments of the present application. Therefore, the above description should not be regarded as limiting, but only as an example of the embodiments. Those skilled in the art will think of other modifications within the scope and spirit of the present application.

[0067] The drawings included in the specification and forming a part of the specification illustrate embodiments of the present application and serve to explain the principles of the present application together with the above general description of the present application and the following detailed description of the embodiments.

[0068] These and other features of this application will become apparent from the following description of preferred forms of embodiments given as non-limiting examples, with reference to the accompanying drawings.

[0069] It should also be understood that although this application has been described with reference to some specific examples, those skilled in the art can certainly implement many other equivalent forms of this application.

[0070] The above and other aspects, features and advantages of this application will become more apparent when taken in conjunction with the accompanying drawings and in view of the following detailed description.

[0071] Specific embodiments of this application are described thereafter with reference to the accompanying drawings; however, it should be understood that the claimed embodiments are merely examples of this application, which can be implemented in various ways. Well-known and / or repeated functions and structures are not described in detail to avoid unnecessary or redundant details that could obscure the application. Therefore, the specific structural and functional details claimed herein are not intended to be limiting, but merely serve as the basis and representative basis for the claims to teach those skilled in the art to use this application in a variety of substantially any suitable detailed structures.

[0072] This specification may use the phrases “in one embodiment,” “in another embodiment,” “in yet another embodiment,” or “in other embodiments,” all of which may refer to one or more of the same or different embodiments according to this application.

[0073] like Figure 1 As shown, the client and server can communicate and interact with each other. The server can include a server, and there can be one or more clients. For example, for ease of description and distinction, in this embodiment, the client performing data backup-related steps is referred to as the second client, the client performing data recovery-related steps is referred to as the first client, and the client performing steps related to setting recovery strategy packages is referred to as the third client. The first client, second client, and third client can all interact with the server. The client can be an application, software, or a combination of hardware and software set up on the network terminal.

[0074] It can be understood that in some cases, the first client and the second client can be the same client, that is, the client interacting with the service side when backing up and restoring the backup data can be the same client. In some cases, the first client and the third client can be the same client, that is, the client interacting with the service side when restoring the backup data can also have the ability to set the recovery policy. In some cases, the second client and the third client can also be the same client, that is, the client interacting with the service side when backing up the data can also have the ability to set the recovery policy. In some cases, the first client, the second client and the third client can also be the same client. This is only an example and does not limit the scope of protection of the claims.

[0075] In cloud storage, metal or medical systems, the recovery policy of data can change constantly, the requirement for data security is high, and the data backup and recovery need to flexibly configure and dynamically adjust the recovery policy.

[0076] Based on the above application scenarios, the client can send a backup data packet and a first recovery policy packet to the service side, and can also receive data processed based on a recovery policy packet corresponding to the ciphertext data corresponding to the backup data packet when restoring the backup data, and then restore the backup data.

[0077] The following takes the second client sending a backup data packet to the service side and the first client restoring the ciphertext data as an example for description.

[0078] The embodiments of the present application also provide a data backup method, mainly involving a second client and a service side. In combination with Figure 2 and Figure 3 , the second client can generate a temporary key and encrypt data, encrypt the temporary key, and send the encrypted temporary key and the public key of the signed recovery policy packet to the service side.

[0079] S110: The second client can generate a first temporary key (KEK).

[0080] S120: The second client encrypts the plaintext data (Data) to be backed up using the first temporary key to obtain encrypted data, that is, generates ciphertext data (DataCipher).

[0081] S130: The second client can encrypt the first temporary key using the public key (also referred to as the first public key) in the backup key on the service side to generate a third ciphertext (KEKCipher), and can construct the third ciphertext into a backup data packet and send the backup data packet to the service side, so as to ensure that even if the third ciphertext is intercepted, the interceptor cannot obtain the first temporary key through the third ciphertext, and thus cannot decrypt the ciphertext data to obtain the plaintext data through the first temporary key, thereby ensuring the security of the data.

[0082] S140: The second client determines a second private key and a corresponding second public key. For example, the second client can generate or select a pair of public and private keys from existing public and private keys as the second private key (VK) and the second public key (pK) corresponding to the second private key. The second private key is used to sign a recovery policy package, and the recovery policy package includes a recovery policy for recovering the ciphertext data.

[0083] In some implementations, the second client can sign the recovery policy package itself using the second private key to ensure the integrity and authenticity of the recovery policy package. In other implementations, the second client can also authorize other clients (for example, a third client) to use the second private key, so that other clients have the ability to set the recovery policy package. It can be understood that no matter which client sets the recovery policy package, it can be flexibly set when the data is backed up or after the data backup is completed. Some implementations of setting the recovery policy package will be further described in the embodiments below.

[0084] In the case that the service side receives a recovery policy package, the service side can verify the signature using the second public key in the backup data packet to ensure that the recovery policy package has not been tampered with and is from a trusted source.

[0085] S150: After the backup data packet construction step is completed, the second client sends the backup data packet corresponding to the ciphertext data to the service side, wherein the backup data packet includes the third ciphertext and the second public key. The backup data packet can be sent to the service side through a secure channel to reduce the possibility of the backup data packet being intercepted during transmission. Of course, it can be understood that the second client can also send the backup data packet to the service side through other forms of transmission.

[0086] In combination with Figure 2 and Figure 5 S310: The service side can receive the backup data packet corresponding to the ciphertext data from the second client, the ciphertext data being the encrypted plaintext data, and the backup data packet including at least the second public key.

[0087] The backup data packet can also include cipher data. Of course, it can be understood that the second client can also choose not to put the cipher data into the backup data packet, but to store it separately in other locations to meet different storage needs.

[0088] Exemplarily, in the case of constructing the cipher data into the backup data packet, the backup data packet BackupPacket can be represented as:

[0089] BackupPacket = {KEKCipher, pK, [DataCipher]}.

[0090] In some embodiments, the second client can also determine the message authentication code (MAC1) of the backup data packet using the first temporary key to ensure the integrity of the data packet. Wherein the MAC1 value can be represented as:

[0091] MAC1 = HMAC KEK (BackupPacket).

[0092] The message authentication code is sent to the service side to make the service side verify the integrity of the backup data packet through the message authentication code generated by the service side. Wherein the message authentication code is a keyed hash function used to ensure the integrity and source authentication of the message. The MAC value can be calculated by the second client using the first temporary key and the message as input through a preset algorithm, and is sent to the service side at the end of the message.

[0093] The service side obtains the third cipher text in the backup data packet when receiving the backup data packet. The service side can use the private key (also known as the first private key) in the backup key of the service side to decrypt the third cipher text to obtain the first temporary key.

[0094] The service side uses the decrypted first temporary key and the same algorithm to perform the same operation on the received message to generate a message authentication code MAC2, and compares whether the generated MAC2 value is consistent with the received MAC1 value. If consistent, the backup data packet is considered to be complete and trusted. That is, in the case of passing the message authentication code based on the backup data packet, the backup data packet is saved.

[0095] For example, the service side receives the message authentication code MAC1 corresponding to the backup data packet, and the service side can generate a message authentication code MAC2 of the service side. If MAC2 is the same as MAC1, it means that the backup data packet received by the service side is not damaged or tampered with, and is complete and reliable, and the service side can save the received backup data packet. If MAC2 is different from MAC1, it means that the data in the backup data packet received by the service side may have been stolen or lost, or may have been tampered with, and the backup data packet received by the service side is not reliable. In this case, the service side can choose not to save the received backup data packet, and can send a signal that the backup data packet is not reliable to the second client. Alternatively, the second client can resend the backup data packet to the service side after receiving the above signal sent by the service side. Then the service side re-generates the message authentication code MAC3 in a manner similar to the foregoing, and compares MAC3 with the received message authentication code MAC1. If MAC3 is the same as MAC1, the service side saves the backup data packet.

[0096] As described above, in some implementations, the related steps of setting the recovery policy package can also be jointly implemented by the third client and the service side. In combination with Figure 2 and Figure 4 The embodiment of the present application also provides a method for setting a recovery policy package for data recovery, which comprises:

[0097] S210: The third client sets a first recovery policy package, wherein the first recovery policy package comprises a recovery policy for recovering ciphertext data, and the ciphertext data is encrypted plaintext data. The recovery policy for recovering ciphertext data can include selecting a required recovery mode (such as single key, factor combination, direct plaintext recovery, etc.).

[0098] Wherein, the "factor" refers to different types of information or elements that a user needs to provide to prove his identity. These factors are usually divided into several categories such as knowledge factors, possession factors and biometric factors. Each factor can be independent, that is, the disclosure of one factor should not affect the security of other factors. For example, even if one factor (such as a password) in the factor combination is disclosed, as long as other factors (such as a mobile phone verification code, a biometric feature, etc.) are still secure. By combining multiple different types of factors, stronger security can be provided for data backup and data recovery. These factors have independent, diverse and easy-to-use properties and may contain a variety of specific contents. Suitable factor combinations can be selected according to the specific needs of users, security levels and application scenarios, etc. to achieve the best security effect.

[0099] For example, the recovery strategy package includes a recovery strategy for recovering encrypted data. The recovery method for encrypted data is single-key recovery. The single key may include, but is not limited to, a fixed key, or a key derived from a single password factor, a single SMS verification code factor, a single OTP factor (one-time password), or a single biometric factor. The biometric factor may be fingerprint, facial features, iris, and voiceprint, etc.

[0100] Of course, the recovery strategy package includes recovery strategies for ciphertext data that can also be factor combinations. A factor combination can include at least two factors, such as any combination of two or more of the following: password factors, SMS verification code factors, OTP factors, and biometric factors. It is understood that a factor combination can also be a combination of two or more factors of the same factor type; for example, it could be a combination of fingerprint and iris data from biometric factors.

[0101] When the recovery method corresponding to the first recovery strategy package is direct plaintext recovery, the first client can determine the corresponding second factor key based on the received user-input factor. The first client can then determine a second temporary key based on the second factor key and multiple second ciphertexts. Using the second temporary key, the first ciphertext is decrypted to obtain the first temporary key. The first client can send the first temporary key to the server. If the server determines that the temporary key from the first client is the same as its first temporary key, the server uses the first key to decrypt the ciphertext data to obtain the plaintext data, and then directly returns the plaintext data to the first client.

[0102] S220: The third client obtains the first signature (hereinafter referred to as the first signature for ease of distinction and description). The first signature can be obtained by signing the first recovery policy package using the second private key.

[0103] S230: The third client sends the signed first recovery policy packet to the server. Of course, the signed first recovery policy packet can also be sent to the server by the second client; that is, the second and third clients can be the same client. For example, the third client can send it to the server through a secure channel to reduce the possibility of the first recovery policy being intercepted. When the third and second clients are the same client, the secure channel between the third client and the server can be the same as the secure channel between the second client and the server. Of course, it is understood that the third client can also send the first recovery policy packet to the server through other transmission methods.

[0104] S320: In addition to receiving backup data packets, the server also receives the first recovery policy packet signed by the aforementioned third client.

[0105] S330: The service side determines the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data in a case that the first signature is verified to be passed using the second public key. The ciphertext data can be recovered through the recovery strategy corresponding to the first recovery strategy package. The second public key corresponds to the second private key.

[0106] Determining the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data can be understood as that the service side can not have the recovery strategy corresponding to the ciphertext data before the third client sends the first recovery strategy package to the service side. Of course, the service side can already have the recovery strategy corresponding to the ciphertext data before the third client sends the first recovery strategy package to the service side. For example, the service side already has a second recovery strategy package corresponding to the ciphertext data before the third client sends the first recovery strategy package to the service side, the second recovery strategy package includes the recovery strategy corresponding to the ciphertext data, and the second recovery strategy package can be different from the first recovery strategy package. For example, the recovery strategy included in the second recovery strategy package is to recover the ciphertext data by using a single key, and as the user's demand for the recovery strategy of the ciphertext data changes or the application scenario changes, it is necessary to recover the ciphertext data by using a multi-factor key combination. At this time, the existing second recovery strategy package of the service side includes the recovery strategy corresponding to the ciphertext data, which cannot meet the user's demand. Therefore, the updated first recovery strategy package can be sent to the service side to update the second recovery strategy package to the first recovery strategy package, and the ciphertext data is recovered through the recovery strategy corresponding to the ciphertext data included in the first recovery strategy package.

[0107] In a case that the user's recovery strategy of the ciphertext data changes, the third client can update the first recovery strategy package, update the recovery mode (single key, factor combination, direct plaintext recovery, etc.) corresponding to the user's current required recovery strategy of the ciphertext data to the first recovery strategy package, and then send the updated first recovery strategy package to the service side. The adjustment flexibility of the recovery strategy of the ciphertext data is high, and even in a case that the service side has received and saved the recovery strategy of the ciphertext data, the recovery strategy of the ciphertext data can still be updated and adjusted at any time, so that the recovery of the ciphertext data can better adapt to changes in different application scenarios and security requirements. That is, the first recovery strategy package is sent to the service side independently of the backup data package, which realizes independent management and dynamic adjustment of the recovery strategy of the ciphertext data. Even in a case that the user's recovery strategy of the ciphertext data changes, the backup data package does not need to be sent to the service side again, which reduces the risk of security problems when the backup data package is sent again, and also avoids occupying the transmission channel resources when the recovery strategy of the ciphertext data is constructed in the backup data package and the recovery strategy and other information or data in the backup data package are sent to the service side.

[0108] For example, in the same application scenario, a user may initially only want to use a single key as a recovery method of the recovery policy corresponding to the ciphertext data for convenience, and the third client sends the first recovery policy package to the service side, and the first recovery policy package includes only the single key recovery method in the recovery policy corresponding to the ciphertext data. After using for a period of time, the user's demand for data security becomes higher, and a multi-factor combination method may be needed as a recovery method of the recovery policy of the ciphertext data, at which time the third client needs to update the first recovery policy package to update the multi-factor combination recovery method to the first recovery policy package, and then send the updated first recovery policy package to the service side to realize real-time updating of the recovery policy package corresponding to the ciphertext data. In the above process, the backup data package does not need to be updated and repeatedly sent.

[0109] In the case where the third client and the second client are not the same client, the third client obtaining the first signature can include:

[0110] The third client determines a second private key for signing, and calls the second private key to sign the first recovery policy package based on the use authority possessed by the third client. The second private key is not stored on the third client. For example, the second private key is stored in the second client, and the second client sets the authority of calling the second private key for the third client, so that the third client can send a request for calling the second private key to the second client when it needs to use the second private key to sign the first recovery policy package. The second client sends the second private key to the third client after receiving the calling request from the third client. In this way, the second private key used to sign the first recovery policy package is stored in the second client different from the third client, further ensuring the security of the second private key, and further ensuring the integrity and credibility of the first signature.

[0111] After signing the first recovery policy package using the called second private key, the third client receives the first signature, so that the third client can obtain the signature of the first recovery policy package.

[0112] In some embodiments, in the case where the third client and the second client are the same client, the third client obtaining the first signature includes:

[0113] A second private key is determined for signing, and the first recovery policy package is signed using the second private key. That is, the second public key and the second private key are a pair of keys belonging to the third client, which can be used by the second client and the service side in the process of setting the recovery policy package, for calculating and verifying the signature of the recovery policy package. The second private key is stored on the third client, and the third client does not need to obtain the second private key through a call, but can directly use the second private key stored by itself to sign the first recovery policy package, simplifying the process of signing the first recovery policy.

[0114] The third client constructs the second public key into the backup data package corresponding to the ciphertext data, and sends the backup data package to the service side. Of course, in addition to including the second public key, the backup data package can also include other information or data such as ciphertext data.

[0115] The first client, as the recovery end of data recovery, can send a data recovery request to the service side to request to recover the backed-up ciphertext data.

[0116] In some possible implementations, in the case where the data recovery policy is a multi-factor key, the service side generates a second temporary key in response to the request of the first client to recover the ciphertext data, and encrypts the first temporary key using the second temporary key to obtain a first ciphertext. The service side disperses the second temporary key into a plurality of sub-keys based on the number of factors required for recovering the ciphertext data in the recovery policy, where the number of sub-keys is the same as the number of factors.

[0117] For example, the number of factors is n, where n is a positive integer greater than or equal to 2. The second temporary key is K2, which can be dispersed into n sub-keys F(1), F(2),..., F(n).

[0118] The service side generates a corresponding first factor key for each factor, respectively encrypts the corresponding sub-key using the first factor key, and obtains a plurality of second ciphertexts.

[0119] For example, the service side generates a corresponding first factor key Yi for each factor, and encrypts the sub-key F(i) using the first factor key to obtain a plurality of second ciphertexts FCi. For example, the first factor key can be generated in the following manner:

[0120] Password factor: the key can be derived through a PBKDF algorithm;

[0121] SMS verification code factor: the key can be derived by generating a verification code;

[0122] OTP factor: the key can be generated through an OTP algorithm;

[0123] Biometric factor: the key is derived by hashing the biometric data.

[0124] Of course, it can be understood that the first factor key can also be generated in other ways, which is only an example and does not limit the scope of claims.

[0125] The service side returns the recovery data packet to the first client, and the recovery data packet includes the first ciphertext and the plurality of second ciphertexts.

[0126] The first client receives the data recovery packet returned by the service side in response to the data recovery request, wherein the data recovery packet includes the plaintext data obtained by recovering the ciphertext data according to the first recovery strategy packet.

[0127] In some embodiments, the first client determines the corresponding at least two second factor keys in response to the at least two factors received by the user input. The number of the at least two factors received by the first client can be the same as the number of factors in the plurality of factor combinations in the service side, or can be less than the number of factors in the plurality of factor combinations in the service side, as long as it is higher than the minimum threshold value.

[0128] The first client can determine a second temporary key based on the at least two second factor keys and the plurality of second ciphertexts. The first ciphertext is decrypted by the second temporary key to obtain the first temporary key, and then the ciphertext data is decrypted by the first temporary key to obtain the plaintext data, thereby realizing the recovery of the data.

[0129] In combination Figure 6 , the embodiments of the present application also provide a service side, comprising:

[0130] At least one first processor is configured to receive a backup data packet corresponding to ciphertext data, the ciphertext data being encrypted plaintext data, and the backup data packet including at least a second public key. Receive a signed first recovery strategy packet from a third client; wherein the first recovery strategy packet includes a recovery strategy for recovering the ciphertext data, and the first recovery strategy packet has a first signature, and the first signature is obtained by signing the first recovery strategy packet using a second private key, and the second private key corresponds to the second public key. In the case where the first signature is verified to be passed using the second public key, the first recovery strategy packet is determined as the recovery strategy packet corresponding to the ciphertext data.

[0131] The embodiments of the present application further provide a client, which implements part of the steps of the method when the computer program / instructions of the client are executed by a processor, i.e., implements the method steps executed by the client. The client can be one client, or a first client, a second client and a third client, wherein the first client and the second client can be the same client, the first client and the third client can be the same client, and the second client and the third client can also be the same client. This is only an example, and does not limit the protection scope of the claims.

[0132] The embodiments of the present application further provide a storage medium, which stores computer programs / instructions, and the computer programs / instructions are executed by a processor to implement the method according to any one of the above embodiments.

[0133] The embodiments of the present application further provide a computer program product, which includes computer programs / instructions, and the computer programs / instructions are executed by a processor to implement the steps of the method according to any one of the above embodiments.

[0134] It should be noted that the computer storage medium of the present application can be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable medium may, for example, but not limited to, be an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or apparatus. In the present application, the computer readable signal medium can include a data signal carried in a baseband or as a part of a carrier wave, which carries computer readable program code. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal or any suitable combination thereof. The computer readable signal medium can also be any computer readable medium other than the computer readable storage medium, which can send, propagate or transmit a program configured for use by or in conjunction with an instruction execution system, device or apparatus. The program code contained on the computer readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, cable, RF, etc., or any suitable combination thereof.

[0135] The above has carried out the detailed explanation to the multiple embodiments of the application, but the application is not limited to these specific embodiments, and the person skilled in the art can make various modified embodiments on the basis of the concept of the application, and these modifications shall fall within the scope of the application claimed.

Claims

1. A data processing method applied to a service side, characterized in that, The method comprises: receiving a backup data packet corresponding to ciphertext data, the ciphertext data being plaintext data encrypted by a first temporary key generated at a client side when backed up, the backup data packet comprising at least a second public key; receiving a signed first recovery strategy packet from a third client; wherein the first recovery strategy packet comprises a recovery strategy for recovering the ciphertext data, the first recovery strategy packet having a first signature, the first signature being obtained by signing the first recovery strategy packet using a second private key corresponding to the second public key; determining the first recovery strategy packet as a recovery strategy packet corresponding to the ciphertext data when the first signature is verified to be passed using the second public key; after the step of receiving the backup data packet corresponding to the ciphertext data, further comprising: generating a second temporary key in response to a request of the first client for recovering the ciphertext data; encrypting the first temporary key using the second temporary key to obtain a first ciphertext; in a case where the recovery strategy comprises a recovery mode of multi-factor combination recovery, dispersing the second temporary key into a plurality of sub-keys based on a number of factors required when recovering the ciphertext data, wherein the number of sub-keys is the same as the number of factors, and the factors are different types of information or elements proving the identity of a user; generating a corresponding first factor key for each factor, and encrypting the corresponding sub-key using the first factor key to obtain a plurality of second ciphertexts; returning a recovery data packet to the first client, the recovery data packet comprising the first ciphertext and the plurality of second ciphertexts.

2. The data processing method according to claim 1, characterized in that, determining the first recovery strategy packet as the recovery strategy packet corresponding to the ciphertext data comprises: in a case where a second recovery strategy packet corresponding to the ciphertext data exists at the service side, updating the second recovery strategy packet to the first recovery strategy packet; wherein the second recovery strategy packet is different from the first recovery strategy packet.

3. The data processing method according to any one of claims 1 to 2, characterized in that, wherein the recovery strategy further comprises any one of the following recovery modes: single key recovery; directly providing the recovery of the plaintext data.

4. The data processing method according to any one of claims 1 to 2, characterized in that, further comprising: receiving a message authentication code corresponding to the backup data packet; the backup data packet further comprises third ciphertext; decrypting the third ciphertext to obtain the first temporary key; in a case where the message authentication code is verified to be passed based on the backup data packet, saving the backup data packet.

5. A data processing method, characterized by, applied to a third client, the method comprising: setting a first recovery strategy packet, wherein the first recovery strategy packet comprises a recovery strategy for recovering ciphertext data, the ciphertext data being plaintext data encrypted by a first temporary key generated at a client side when backed up; the recovery strategy comprising a plurality of factors required when recovering the ciphertext data, wherein a factor is different types of information or elements proving the identity of a user; the recovery strategy being capable of being used by a service side to disperse a second temporary key generated by the service side into a plurality of sub-keys based on the number of factors required when recovering the ciphertext data; wherein the number of sub-keys is the same as the number of factors; obtain a first signature, the first signature being obtained by signing the first recovery policy package using a second private key; send the signed first recovery policy package to a service side, so that the service side determines the first recovery policy package as a recovery policy package corresponding to the ciphertext data if the first signature is verified to be correct using a second public key corresponding to the second private key.

6. The data processing method according to claim 5, characterized in that, obtaining a first signature includes: determining a second private key for signing; based on the use permission possessed by the third client, calling the second private key to sign the first recovery policy package to obtain a first signature; wherein the second private key is not stored on the third client; receiving the first signature.

7. The data processing method according to claim 5, characterized in that, obtaining a first signature includes: determining a second private key for signing; signing the first recovery policy package using the second private key to obtain a first signature; The method further includes: sending a backup data package corresponding to the ciphertext data to a service side, the backup data package including at least the second public key.

8. The data processing method according to claim 7, characterized in that, The method further includes: generating a first temporary key; encrypting the plaintext data using the first temporary key to generate ciphertext data; encrypting the first temporary key to generate a third ciphertext; the backup data package further includes the third ciphertext.

9. A data processing method, characterized by, Applied to the second client, the method includes: generating a first temporary key; encrypting the plaintext data using the first temporary key to generate ciphertext data; encrypting the first temporary key to generate a third ciphertext; determining a second private key and a corresponding second public key, wherein the second private key is used to sign a recovery policy package, and the recovery policy package includes a recovery policy for recovering ciphertext data; the recovery policy includes a plurality of factors required when recovering the ciphertext data, wherein a factor is different types of information or elements proving the identity of a user; the recovery policy can be used by a service side to disperse a second temporary key generated by the service side into a plurality of sub-keys based on the number of factors required when recovering the ciphertext data; wherein the number of sub-keys is the same as the number of factors; sending a backup data package corresponding to the ciphertext data to a service side, wherein the backup data package includes the third ciphertext and the second public key.

10. The data processing method according to claim 9, characterized in that, wherein further comprising: determining a message authentication code of the backup data package using the first temporary key; sending the message authentication code to the service side.

11. A service side, characterized by, including: at least one first processor for receiving a backup data package corresponding to ciphertext data, the ciphertext data being encrypted plaintext data, the backup data package including at least a second public key; receive a signed first recovery policy package from the third client, wherein the first recovery policy package comprises a recovery policy for recovering the ciphertext data, the first recovery policy package has a first signature, and the first signature is obtained by signing the first recovery policy package using a second private key corresponding to the second public key; determine the first recovery policy package as the recovery policy package corresponding to the ciphertext data when the first signature is verified to be valid using the second public key; after receiving the backup data package corresponding to the ciphertext data, in response to a request for recovering the ciphertext data issued by the first client, generate a second temporary key; encrypt the first temporary key using the second temporary key to obtain a first ciphertext; when the recovery policy comprises a multi-factor combined recovery mode, disperse the second temporary key into a plurality of sub-keys based on a number of factors required for recovering the ciphertext data according to the recovery policy, wherein the number of the sub-keys is the same as the number of the factors, and the factors are different types of information or elements for proving the identity of the user; generate a corresponding first factor key for each factor, and encrypt the corresponding sub-key using the first factor key to obtain a plurality of second ciphertexts; and return a recovery data package to the first client, wherein the recovery data package comprises the first ciphertext and the plurality of second ciphertexts.

12. A client, characterized in that, The computer program / instructions, when executed by the processor of the client, implement the method of any one of claims 5-8 or the method of any one of claims 9-10.

13. A storage medium, characterized by The computer program / instructions, when executed by the processor of the client, implement the method of any one of claims 5-8 or the method of any one of claims 9-10.

14. A computer program product, characterised in that, The computer program / instructions, when executed by the processor of the client, implement the method of any one of claims 5-8 or the method of any one of claims 9-10.

Images