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

Abstract

The invention provides a data processing method and a related product. The method executed by the service side comprises the steps that a backup data packet corresponding to ciphertext data is received, the ciphertext data is encrypted plaintext data, and the backup data packet comprises a second public key; receiving a signed first recovery strategy packet from a third client; the first recovery strategy packet comprises a recovery strategy for recovering the ciphertext data, and a first signature of the first recovery strategy packet is obtained by signing the first recovery strategy packet by using a second private key; and determining the first recovery strategy packet as a recovery strategy packet corresponding to the ciphertext data under the condition that the first signature is verified to pass by using the second public key. The recovery strategy and the data backup packet are separately managed, so that the recovery strategy can still be flexibly adjusted after data backup is completed. According to the method, the recovery strategy can be updated according to changed security requirements and business scenes without re-backup of data, so that higher flexibility and adaptability are provided for data recovery and protection.

Description

Technical Field

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

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

[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 embodiment of the present application adopts the following technical solution: a data processing method, applied to the service side, the method comprising:

[0005] receiving a backup data packet corresponding to the ciphertext data, wherein the ciphertext data is encrypted plaintext data, and the backup data packet includes at least a second public key;

[0006] Receiving a signed first recovery strategy package from a third client; wherein the first recovery strategy package includes a recovery strategy for recovering ciphertext data, the first recovery strategy package has a first signature, 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] When the first signature is successfully verified 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 includes:

[0009] If there is a second recovery strategy package corresponding to the ciphertext data on the service side, updating the second recovery strategy package to the first recovery strategy package;

[0010] 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 methods:

[0012] Single key recovery;

[0013] Multi-factor combination recovery;

[0014] Directly provide recovery of the plaintext data.

[0015] In some embodiments, it also includes:

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

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

[0018] Dispersing the second temporary key into a plurality of subkeys based on the number of multiple factors required for recovering the ciphertext data in the recovery strategy, wherein the number of the subkeys is the same as the number of the factors;

[0019] Generate a corresponding first factor key for each factor, and use the first factor key to encrypt the corresponding subkey to obtain multiple second ciphertexts;

[0020] A recovery data packet is returned to the first client, where the recovery data packet includes the first ciphertext and the plurality of second ciphertexts.

[0021] In some embodiments, it also includes:

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

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

[0024] When the message authentication code is verified successfully based on the backup data packet, the backup data packet is saved.

[0025] The present application also provides a data processing method, which is applied to a third client, and the method includes:

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

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

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

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

[0030] Determine a second private key for signing;

[0031] Based on the usage authority owned 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;

[0032] The first signature is received.

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

[0034] Determine a second private key for signing;

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

[0036] The method further comprises:

[0037] A backup data packet corresponding to the ciphertext data is sent to a service side, wherein the backup data packet includes at least the second public key.

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

[0039] generating a first temporary key;

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

[0041] The first temporary key is encrypted to generate a third ciphertext; the backup data packet also includes the third ciphertext.

[0042] The embodiment of the present application further provides a data processing method, which is applied to a second client, and the method includes:

[0043] generating a first temporary key;

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

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

[0046] Determine 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;

[0047] A backup data packet corresponding to the ciphertext data is sent to a service side, wherein the backup data packet includes the third ciphertext and the second public key.

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

[0049] Using the first temporary key, determining a message authentication code of the backup data packet;

[0050] The message authentication code is sent to the service side.

[0051] The embodiment of the present application also provides a service side, including:

[0052] At least one first processor is used to receive a backup data packet corresponding to ciphertext data, wherein the ciphertext data is encrypted plaintext data and the backup data packet includes at least a second public key; receive a signed first recovery strategy package from a third client; wherein the first recovery strategy package includes 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; when the first signature is verified using the second public key, the first recovery strategy package is determined as the recovery strategy package corresponding to the ciphertext data.

[0053] The embodiment of the present application also provides a client, which implements some steps of the above-mentioned method when the computer program / instructions of the client are executed by the processor.

[0054] An embodiment of the present application also provides a storage medium on which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, a method as described in any one of the above embodiments is implemented.

[0055] An embodiment of the present application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the method described in any one of the above embodiments.

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

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

[0058] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0059] Figure 1 This is a schematic diagram of the architecture of the service side and the client side of the embodiment of the present application;

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

[0061] Figure 3 A flowchart of a method for sending a backup data packet executed by a second client of the present application;

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

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

[0064] Figure 6 This is the structural diagram of the service side of this application. DETAILED DESCRIPTION

[0065] Various aspects and features of the present application are described herein with reference to the accompanying drawings.

[0066] It should be understood that various modifications may be made to the embodiments of the present application. Therefore, the above description should not be considered as limiting, but only as an example of an embodiment. Other modifications within the scope and spirit of the present application will occur to those skilled in the art.

[0067] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the present application and, together with the general description of the present application given above and the detailed description of the embodiments given below, serve to explain the principles of the present application.

[0068] These and other characteristics of the present application will become apparent from the following description of a preferred form of embodiment given as a non-limiting example with reference to the accompanying drawings.

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

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

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

[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 the present application.

[0073] like Figure 1 As shown, the client and the service side can communicate and exchange data, the service side may include a server, and the client may be one or more. For example, for ease of description and distinction, in the embodiment of the present application, the client that performs the steps related to data backup is referred to as the second client, the client that performs the steps related to data recovery is referred to as the first client, and the client that performs the steps related to setting the recovery policy package is referred to as the third client. The first client, the second client, and the third client can all exchange data with the service side. The client can be an application, software, or a combination of software and hardware that is set on a network terminal.

[0074] It is understandable that in some cases, the first client and the second client may be the same client, that is, the client that interacts with the service side during data backup and restoration of backup data may be the same client. In some cases, the first client and the third client may be the same client, that is, the client that interacts with the service side during restoration of backup data may also have the ability to set a recovery policy. In some cases, the second client and the third client may also be the same client, that is, the client that interacts with the service side during data backup may also have the ability to set a recovery policy. In some cases, the first client, the second client, and the third client may also be the same client. This is only used as an example and does not constitute a limitation on the scope of protection of the claims.

[0075] In cloud storage, metal or medical systems, data recovery strategies may change constantly, requiring high data security and data backup and recovery with flexible configuration and dynamic adjustment of recovery strategies.

[0076] Based on the above application scenarios, the client can send a backup data packet and a first recovery strategy package to the service side, and can also receive data processed by the service side based on the recovery strategy package 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 is an example in which the second client sends a backup data packet to the service side and the first client restores the ciphertext data.

[0078] The present application embodiment also provides a data backup method, which mainly involves the second client and the service side. 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 signature recovery policy package to the service side.

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

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

[0081] S130: The second client can use the public key in the backup key of the service side (also called the first public key) to encrypt the first temporary key to generate a third ciphertext (KEKCipher). The third ciphertext can be constructed into a backup data packet and sent to the service side together with the backup data packet to ensure that even if the third ciphertext is intercepted, the interceptor cannot obtain the first temporary key through the third ciphertext, and further cannot decrypt the ciphertext data using the first temporary key to obtain the plaintext data, thereby ensuring data security.

[0082] S140: The second client determines the second private key and the corresponding second public key. For example, the second client may 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, which includes a recovery policy for recovering ciphertext data.

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

[0084] When the service side receives a recovery policy package, the service side can use the second public key in the backup data package to verify the signature to ensure that the recovery policy package has not been tampered with and the source is credible.

[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 is understandable that the second client can also send the backup data packet to the service side through other forms of transmission.

[0086] Combination Figure 2 and Figure 5 , S310: The service side may receive a backup data packet corresponding to the ciphertext data from the second client, where the ciphertext data is encrypted plaintext data, and the backup data packet includes at least the second public key.

[0087] The backup data package may also include ciphertext data. Of course, it is understandable that the second client may also choose not to put the ciphertext data into the backup data package, but store it separately in other locations to meet different storage requirements.

[0088] For example, when the ciphertext data is constructed into a backup data packet, the backup data packet BackupPacket can be expressed as:

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

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

[0091] MAC1=HMAC_KEK(BackupPacket).

[0092] The message authentication code is sent to the service side so that the service side verifies the integrity of the backup data packet through the message authentication code generated by the service side. 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 attached to the end of the message and sent to the service side.

[0093] The service side obtains the third ciphertext in the backup data packet while receiving the backup data packet. The service side can use the private key (also called the first private key) in the backup key of the service side to decrypt the third ciphertext 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, generates a message authentication code MAC2, and compares the generated MAC2 value with the received MAC1 value to see if they are consistent. If they are consistent, the backup data packet is considered complete and authentic. That is, if the message authentication code based on the backup data packet is verified, 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 the message authentication code MAC2 of the service side. When MAC2 is the same as MAC1, it means that the backup data packet received by the service side has not been damaged or tampered with, and is complete and credible. The service side can save the received backup data packet. When MAC2 is different from MAC1, it means that the data in the backup data packet received by the service side may have been stolen and lost, or may have been tampered with, and the backup data packet received by the service side is unreliable. In this case, the service side can choose not to save the received backup data packet, and can send a signal to the second client that the backup data packet is unreliable. Optionally, after receiving the above signal sent by the service side, the second client can resend the backup data packet to the service side. Then the service side regenerates the message authentication code MAC3 in a similar manner to the above, 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 mentioned above, in some implementations, the steps related to setting the recovery policy package can also be implemented jointly by the third client and the service side. Figure 2 and Figure 4 The embodiment of the present application also provides a method for setting a recovery strategy package for data recovery, the method comprising:

[0097] S210: The third client sets a first recovery strategy package, wherein the first recovery strategy package includes a recovery strategy for recovering ciphertext data, where the ciphertext data is encrypted plaintext data. The recovery strategy for recovering the ciphertext data may include selecting a required recovery method (e.g., a single key, a factor combination, direct plaintext recovery, etc.).

[0098] Among them, "factors" refer to different types of information or elements that users need to provide to prove their 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 leakage of one factor should not affect the security of other factors. For example, even if one factor in the factor combination (such as a password) is leaked, as long as other factors (such as mobile phone verification codes, biometrics, etc.) are still safe. By combining multiple different types of factors, stronger security can be provided for data backup and data recovery. These factors have attribute characteristics such as independence, diversity and ease of use, and may contain a variety of specific content. The appropriate factor combination can be selected according to the specific needs of the user, security level, and application scenarios to achieve the best security effect.

[0099] For example, the recovery strategy for recovering ciphertext data included in the first recovery strategy package uses a single key recovery method for recovering ciphertext data. 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, where the biometric factor may be a fingerprint, facial feature, iris, voiceprint, etc.

[0100] Of course, the recovery strategy for recovering ciphertext data included in the first recovery strategy package can also be a factor combination for recovering ciphertext data, and the factor combination includes at least two or more factors, for example, it can be a combination of any two or more of a password factor, a SMS verification code factor, an OTP factor, and a biometric factor. It is understandable that the factor combination can also be a combination of two or more factors of the same factor type, for example, it can be a combination of fingerprints and irises in 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 factor input by the received user. The first client can determine the second temporary key based on the second factor key and multiple second ciphertexts. The first ciphertext is decrypted by the second temporary key to obtain the first temporary key; the first client can send the first temporary key to the service side. When the service side determines that the temporary key from the first client is the same as the first temporary key of the service side, the service side uses the first key to decrypt the ciphertext data to obtain the plaintext data, and returns the plaintext data directly to the first client.

[0102] S220: The third client obtains a first signature (hereinafter referred to as the first signature for the convenience of distinction and description). The first signature may 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 package to the service side. Of course, the signed first recovery policy package can also be sent by the second client to the service side, that is, the second client and the third client can be the same client. For example, the third client can send it to the service side through a secure channel to reduce the possibility of the first recovery policy being intercepted. In the case where the third client and the second client are the same client, the secure channel between the third client and the service side and the secure channel between the second client and the service side can be the same secure channel. Of course, it can be understood that the third client can also send the first recovery policy package to the service side through other forms of transmission.

[0104] S320: In addition to receiving the backup data package, the service side also receives the signed first recovery strategy package from the third client.

[0105] S330: When the service side verifies the first signature by using the second public key, the service side determines the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data. The ciphertext data can be recovered by the recovery strategy corresponding to the first recovery strategy package. The second public key corresponds to the second private key.

[0106] The first recovery strategy package is determined as the recovery strategy package corresponding to the ciphertext data. It can be understood that before the third client sends the first recovery strategy package to the service side, the service side may not have a recovery strategy corresponding to the ciphertext data. Of course, before the third client sends the first recovery strategy package to the service side, the service side may already have a recovery strategy corresponding to the ciphertext data. For example, before the third client sends the first recovery strategy package to the service side, the service side already has a second recovery strategy package corresponding to the ciphertext data, and the second recovery strategy package includes a recovery strategy corresponding to the ciphertext data. The second recovery strategy package may be different from the first recovery strategy package. For example, the recovery strategy included in the second recovery strategy package is to use a single key to recover the ciphertext data. As the user's demand for the recovery strategy of the ciphertext data changes or the application scenario changes, it is necessary to use a multi-factor key combination to recover the ciphertext data. At this time, the recovery strategy corresponding to the ciphertext data included in the second recovery strategy package already on the service side will not meet the user's needs. Therefore, the updated first recovery policy package can be sent to the service side, so that the second recovery policy package is updated to the first recovery policy package, and the ciphertext data is restored by the recovery policy corresponding to the ciphertext data included in the first recovery policy package.

[0107] In the case where the user's recovery strategy for ciphertext data changes, the third client can update the first recovery strategy package, update the recovery method (single key, factor combination, direct plaintext recovery, etc.) corresponding to the recovery strategy for ciphertext data currently required by the user 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 for ciphertext data is high. Even if the service side has received and saved the recovery strategy for ciphertext data, the recovery strategy for ciphertext data can still be updated and adjusted at any time, so that the recovery of ciphertext data can better adapt to different application scenarios and changes in security requirements. That is, the first recovery strategy package is sent to the service side independently of the backup data package, realizing independent management and dynamic adjustment of the recovery strategy for ciphertext data. Even if the user's recovery strategy for ciphertext data changes, there is no need to send the backup data package to the service side again, reducing the risk of security problems when the backup data package is sent again. In addition, it also avoids the occupation of transmission channel resources when the recovery strategy of ciphertext data is built in the backup data package and the recovery strategy is sent to the service side together with other information or data in the backup data package.

[0108] For example, in the same application scenario, for convenience, the user may initially want to use only a single key as the recovery method of the recovery strategy corresponding to the ciphertext data. The third client sends the first recovery strategy package to the service side. The recovery strategy corresponding to the ciphertext data included in the first recovery strategy package only includes the recovery method of the single key. After using it for a period of time, the user's demand for data security becomes higher, and a multi-factor combination method may be required as the recovery method of the recovery strategy for the ciphertext data. At this time, the third client needs to update the first recovery strategy package, update the multi-factor combination recovery method to the first recovery strategy package, and then send the updated first recovery strategy package to the service side, so as to realize the update of the recovery strategy package corresponding to the ciphertext data at any time. In the above process, there is no need to update and repeatedly send the backup data package.

[0109] Wherein, in the case that the third client and the second client are not the same client, the third client obtaining the first signature may include:

[0110] The third client determines the second private key used for signing, and based on the usage permission possessed by the third client, calls the second private key to sign the first recovery policy package; wherein the second private key is not stored on the third client. For example, the second private key is stored on the second client, and the second client sets the permission for calling the second private key for the third client, so that the third client can send a request to call the second private key to the second client when the second private key is needed to sign the first recovery policy package. After receiving the call request from the third client, the second client sends the second private key to the third client. In this way, the second private key used to sign the first recovery policy package is stored on the second client different from the third client, which further ensures the security of the second private key, and then ensures the integrity and credibility of the first signature.

[0111] After the first recovery policy package is signed using the called second private key, the third client receives the first signature, thereby enabling the third client to obtain the signature of the first recovery policy package.

[0112] In some embodiments, when the third client and the second client are the same client, the third client obtains the first signature, including:

[0113] Determine the second private key for signing, and use the second private key to sign the first recovery policy package. 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 to calculate and verify the signature of the recovery policy package. The second private key is stored on the third client, and the third client no longer needs to obtain the second private key by calling, and can directly use its own stored second private key to sign the first recovery policy package, which simplifies the process of signing the first recovery policy.

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

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

[0116] In some possible implementations, when the data recovery strategy is a multi-factor key, the service side generates a second temporary key in response to a request from the first client to recover the ciphertext data, and uses the second temporary key to encrypt the first temporary key to obtain the first ciphertext. The service side disperses the second temporary key into multiple subkeys based on the number of multiple factors required to recover the ciphertext data in the recovery strategy, where the number of subkeys is the same as the number of factors.

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

[0118] The service side generates a corresponding first factor key for each factor, and uses the first factor key to encrypt the corresponding subkey to obtain multiple second ciphertexts.

[0119] For example, the service side generates a corresponding first factor key Yi for each factor, and uses it to encrypt the subkey F(i) to obtain multiple second ciphertexts FCi. For example, the first factor key can be generated in the following way:

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

[0121] SMS verification code factor: can generate a verification code and derive a key;

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

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

[0124] Of course, it is understandable that the first factor key may also be generated in other ways, which is only used as an example and does not constitute a limitation on the scope of protection of the claims.

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

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

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

[0128] The first client can determine the second temporary key based on at least two second factor keys and multiple 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 data recovery.

[0129] Combination Figure 6 , the embodiment of the present application further provides a service side, including:

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

[0131] The embodiment of the present application also provides a client, and when the computer program / instruction of the client is executed by the processor, some steps of the method described above are implemented, that is, the method steps executed by the client are implemented. The client can be a 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 used as an example and does not constitute a limitation on the scope of protection of the claims.

[0132] An embodiment of the present application also provides a storage medium on which a computer program / instruction is stored. When the computer program / instruction is executed by a processor, a method as described in any one of the above embodiments is implemented.

[0133] An embodiment of the present application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the method described in any one of the above embodiments.

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

[0135] Multiple embodiments of the present application are described in detail above, but the present application is not limited to these specific embodiments. Those skilled in the art can make various variations and modifications to the embodiments based on the concept of the present application, and these variations and modifications should all fall within the scope of protection required by the present application.

Claims

1. A data processing method, applied to a service side, characterized in that: The method comprises: receiving a backup data packet corresponding to the ciphertext data, wherein the ciphertext data is encrypted plaintext data, and the backup data packet includes at least a second public key; Receiving a signed first recovery strategy package from a third client; wherein the first recovery strategy package includes a recovery strategy for recovering ciphertext data, the first recovery strategy package has a first signature, 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; When the first signature is successfully verified using the second public key, the first recovery strategy package is determined as the recovery strategy package corresponding to the ciphertext data.

2. The data processing method according to claim 1, characterized in that: Determining the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data includes: If there is a second recovery strategy package corresponding to the ciphertext data on the service side, updating the second recovery strategy package to the first recovery strategy package; The second recovery strategy package is different from the first recovery strategy package.

3. The data processing method according to any one of claims 1 to 2, characterized in that: in, The recovery strategy includes any one of the following recovery methods: Single key recovery; Multi-factor combination recovery; Directly provide recovery of the plaintext data.

4. The data processing method according to any one of claims 1 to 3, characterized in that: Also includes: In response to a request from the first client to recover the ciphertext data, generating a second temporary key; Encrypt the first temporary key using the second temporary key to obtain a first ciphertext; Dispersing the second temporary key into a plurality of subkeys based on the number of multiple factors required for recovering the ciphertext data in the recovery strategy, wherein the number of the subkeys is the same as the number of the factors; Generate a corresponding first factor key for each factor, and use the first factor key to encrypt the corresponding subkey to obtain multiple second ciphertexts; A recovery data packet is returned to the first client, where the recovery data packet includes the first ciphertext and the plurality of second ciphertexts.

5. The data processing method according to any one of claims 1 to 4, characterized in that: Also includes: Receiving a message authentication code corresponding to the backup data packet; The backup data packet also includes a third ciphertext; Decrypting the third ciphertext to obtain a first temporary key; When the message authentication code is verified successfully based on the backup data packet, the backup data packet is saved.

6. A data processing method, characterized in that: Applied to a third client, the method includes: Setting a first recovery strategy package, wherein the first recovery strategy package includes a recovery strategy for recovering ciphertext data, wherein the ciphertext data is encrypted plaintext data; Obtaining a first signature, where the first signature is obtained by signing the first recovery policy package using the second private key; The first recovery strategy package after signing is sent to the service side, so that the service side determines the first recovery strategy package as the recovery strategy package corresponding to the ciphertext data when the first signature is verified by using the second public key; wherein the second public key corresponds to the second private key.

7. The data processing method according to claim 6, characterized in that: Get the first signature, including: Determine a second private key for signing; Based on the usage authority owned 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; The first signature is received.

8. The data processing method according to claim 6, characterized in that: Get the first signature, including: Determine a second private key for signing; Sign the first recovery policy package using the second private key to obtain a first signature; The method further comprises: A backup data packet corresponding to the ciphertext data is sent to a service side, wherein the backup data packet includes at least the second public key.

9. The data processing method according to claim 8, characterized in that: The method further comprises: generating a first temporary key; Encrypt the plaintext data using the first temporary key to generate ciphertext data; The first temporary key is encrypted to generate a third ciphertext; the backup data packet also includes the third ciphertext.

10. A data processing method, characterized in that: Applied to the second client, the method includes: generating a first temporary key; Encrypt the plaintext data using the first temporary key to generate ciphertext data; Encrypting the first temporary key to generate a third ciphertext; Determine 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; A backup data packet corresponding to the ciphertext data is sent to a service side, wherein the backup data packet includes the third ciphertext and the second public key.

11. The data processing method according to claim 10, characterized in that: Among them, it also includes: Using the first temporary key, determining a message authentication code of the backup data packet; The message authentication code is sent to the service side.

12. A service side, characterized in that: include: at least one first processor, configured to receive a backup data packet corresponding to the ciphertext data, the ciphertext data being encrypted plaintext data, the backup data packet comprising at least a second public key; Receive a first recovery strategy package after signing from a third client; wherein, the first recovery strategy package includes a recovery strategy for recovering ciphertext data, the first recovery strategy package has a first signature, 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; when the first signature is verified using the second public key, the first recovery strategy package is determined as the recovery strategy package corresponding to the ciphertext data.

13. A client, characterized in that: When the computer program / instructions of the client are executed by a processor, the method described in any one of claims 6 to 9 or the method described in any one of claims 10 to 11 is implemented.

14. A storage medium, characterized in that: A computer program / instruction is stored thereon, and when the computer program / instruction is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

15. A computer program product, characterized in that The method comprises a computer program / instruction which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 11.

Images