Data processing method, hardware security module, client, storage medium and computer program product

Abstract

The invention provides a data processing method, a hardware security module, a client, a storage medium and a computer program product, and the data processing method applied to the hardware security module comprises the steps that under the condition that a data recovery request from a first client is received, the hardware security module generates a second temporary key, encrypting the first temporary key by using a second temporary key to obtain a first ciphertext, the first temporary key being used for encrypting the backup plaintext data to obtain ciphertext data; hardware isolation exists between the hardware security module and other modules on the service side; the hardware security module disperses the second temporary key into a plurality of sub-keys based on the number of a plurality of factors required when ciphertext data is recovered in a data recovery strategy; the hardware security module generates a first factor key for each factor, and encrypts the sub-keys by using the first factor keys to obtain a plurality of second ciphertexts; and returning the first ciphertext and the plurality of second ciphertexts to the first client, so that the first client recovers the backed-up ciphertext data.

Description

Technical Field

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

[0002] In cloud storage, enterprise disaster recovery, and distributed storage systems, data security is key. However, existing technologies lack hardware-level isolation and protection, and attackers may directly obtain keys or data through physical access, leading to the risk of key leakage. Summary of the invention

[0003] The purpose of the embodiments of the present application is to provide a data processing method, a hardware security module, 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 is applied to a hardware security module; the hardware security module is set on the service side, and the method includes:

[0005] When the service side receives a data recovery request from the first client, the hardware security module generates a second temporary key, uses the second temporary key to encrypt the first temporary key, and obtains a first ciphertext, wherein the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data; wherein the hardware security module is hardware-isolated from other modules of the service side;

[0006] The hardware security module disperses the second temporary key into a plurality of subkeys based on the number of a plurality of factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of the subkeys is the same as the number of the factors;

[0007] The hardware security module generates a corresponding first factor key for each factor, and uses the first factor key to encrypt the corresponding subkey to obtain a plurality of second ciphertexts;

[0008] The first ciphertext and the plurality of second ciphertexts are returned to the first client, so that the first client can restore the backed-up ciphertext data.

[0009] In some embodiments, the ciphertext data is stored on the first client, other clients, or other modules on the service side.

[0010] In some embodiments, the hardware security module generates a corresponding first factor key for each factor, including:

[0011] Based on different types of factors, the hardware security module generates a corresponding first factor key using a generation algorithm corresponding to the type of the factor.

[0012] In some embodiments, the multiple factors include a combination of any two or more of the following factors:

[0013] password;

[0014] Verification code;

[0015] One-time password;

[0016] Biometrics.

[0017] In some embodiments, before the hardware security module uses the second temporary key to encrypt the first temporary key, the hardware security module further includes:

[0018] The hardware security module uses the second private key to decrypt the third ciphertext from the second client to obtain the first temporary key; the third ciphertext is obtained by the second client encrypting the first temporary key using the second public key corresponding to the second private key.

[0019] In some embodiments, the other modules of the service side include a server, and before the hardware security module encrypts the first temporary key using the second temporary key, further includes:

[0020] The server receives a backup data packet from the second client and a message authentication code corresponding to the backup data packet, wherein the backup data packet at least includes the third ciphertext;

[0021] Decrypting, by the hardware security module, the third ciphertext to obtain the first temporary key;

[0022] The hardware security module verifies the message authentication code based on the backup data packet;

[0023] When the message authentication code passes the verification, the server saves the backup data packet.

[0024] In some embodiments, before the hardware security module disperses the second temporary key into a plurality of sub-keys, the method further includes:

[0025] The hardware security module verifies a first signature of the first recovery policy package using a first public key, wherein the first recovery policy package includes at least the data recovery policy, and the first signature is obtained by the second client signing the first recovery policy package using a first private key corresponding to the first public key;

[0026] When the first signature verification passes, the hardware security module determines the data recovery strategy as a recovery strategy for recovering the ciphertext data.

[0027] The embodiment of the present application also provides a data processing method, which is applied to a first client, and the method includes:

[0028] Send a data recovery request to the service side to request the recovery of the backed-up ciphertext data;

[0029] Receiving a first ciphertext and a plurality of second ciphertexts from a hardware security module of the service side; wherein the hardware security module is hardware-isolated from other modules of the service side;

[0030] determining corresponding at least two second factor keys, respectively, for at least two factors received in response to user input;

[0031] determining a second temporary key based on the at least two second factor keys and the plurality of second ciphertexts;

[0032] Decrypting the first ciphertext using the second temporary key to obtain a first temporary key;

[0033] The ciphertext data is decrypted using the first temporary key to obtain plaintext data.

[0034] In some embodiments, it also includes:

[0035] Acquire the ciphertext data from the first client or other clients; or,

[0036] The ciphertext data is obtained from other modules on the service side.

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

[0038] Encrypt the plaintext data to be backed up and generate ciphertext data;

[0039] Setting a data recovery strategy, wherein the data recovery strategy includes a plurality of factors required for recovering the ciphertext data;

[0040] The data recovery strategy is sent to a hardware security module on the service side or other modules on the service side; wherein the hardware security module is physically isolated from the hardware resources of other modules on the service side.

[0041] In some embodiments, encrypting the plaintext data to be backed up to generate ciphertext data includes:

[0042] generating a first temporary key;

[0043] Encrypting the plaintext data to be backed up by using the first temporary key to generate ciphertext data;

[0044] The method further comprises:

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

[0046] The third ciphertext is sent to the hardware security module of the service side or other modules of the service side.

[0047] In some embodiments, it also includes:

[0048] Using the first temporary key, determining a message authentication code of a backup data packet including the third ciphertext and the data recovery strategy;

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

[0050] In some embodiments, encrypting the first temporary key comprises:

[0051] The first temporary key is asymmetrically encrypted using a second public key of the hardware security module, wherein a first private key corresponding to the second public key is only stored in the hardware security module.

[0052] The embodiment of the present application also provides a hardware security module, wherein the hardware security module is arranged on the service side;

[0053] The hardware security module includes at least one first processor, and the at least one first processor is used to generate a second temporary key by the hardware security module when the service side receives a data recovery request from the first client, and use the second temporary key to encrypt the first temporary key to obtain a first ciphertext, and the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data; wherein the hardware security module is hardware-isolated from other modules on the service side; the hardware security module disperses the second temporary key into multiple sub-keys based on the number of multiple factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of the sub-keys is the same as the number of the factors; the hardware security module generates a corresponding first factor key for each factor, and uses the first factor key to encrypt the corresponding sub-key to obtain multiple second ciphertexts; the first ciphertext and the multiple second ciphertexts are returned to the first client, so that the first client can recover the backed-up ciphertext data.

[0054] The embodiment of the present application further provides a first client, including:

[0055] At least one third processor is used to send a data recovery request to the service side to request the recovery of the backed-up ciphertext data; receive a first ciphertext and multiple second ciphertexts from a hardware security module of the service side; wherein the hardware security module is hardware-isolated from other modules of the service side; determine at least two corresponding second factor keys respectively in response to at least two factors received by user input; determine a second temporary key based on the at least two second factor keys and the multiple second ciphertexts; decrypt the first ciphertext by the second temporary key to obtain the first temporary key; decrypt the ciphertext data by the first temporary key to obtain plaintext data.

[0056] The embodiment of the present application further provides a second client, including:

[0057] At least one fourth processor is used to encrypt the plaintext data to be backed up and generate ciphertext data; set a data recovery strategy, wherein the data recovery strategy includes multiple factors required to recover the ciphertext data; send the data recovery strategy to the hardware security module on the service side or other modules on the service side; wherein the hardware security module is physically isolated from the hardware resources of other modules on the service side.

[0058] 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.

[0059] 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.

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

[0061] A hardware security module that is hardware-isolated from other modules on the service side is set up on the service side. Key management, encryption and decryption, key dispersion and derivation are performed through the hardware security module on the service side, avoiding the risk of key leakage and ensuring the high security of the data backup and recovery process. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] 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.

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

[0064] Figure 2 A flowchart of a data backup and data recovery method is shown as an exemplary embodiment of the present application;

[0065] Figure 3 This is a structural diagram of the hardware security module for this application;

[0066] Figure 4 This is a structural diagram of the first client of this application;

[0067] Figure 5 This is a structural block diagram of the second client of this application. DETAILED DESCRIPTION

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

[0069] 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] like Figure 1 As shown, the client and the service side can communicate and exchange data. The service side can include a hardware security module (HSM), and of course other modules. The hardware security module is hardware-isolated from other modules on the service side, that is, the hardware security module can be integrated with secure cryptographic algorithms and key management functions, and is a hardware device. The hardware security module has hardware-level protection, so it can be isolated from other modules on the service side. Other modules can be hardware or software. For example, the server side of the service side can be a software deployed on a cloud server.

[0077] Hardware security modules can be directly connected to computers or network servers in the form of expansion cards or external devices, providing strong security for the service side. "Hardware isolation" means that there can be physical and / or logical separation between the HSM and other modules on the service side. This separation ensures that the keys and sensitive information in the HSM will not be accessed or tampered with by unauthorized persons, thereby improving the security of the entire system. Among them, physical isolation means that the HSM usually exists as an independent hardware device and is connected to the server through a physical connection (such as USB, PCI-E, etc.). This physical separation ensures that the keys and sensitive information in the HSM will not be accessed or tampered with by other software or hardware components on the server. Logical isolation means that in addition to physical isolation, the HSM also enhances security through logical isolation. For example, users can run specially developed modules on the internal processor of the HSM, and there is isolation between these modules and the programs of the HSM itself. This isolation ensures that user-defined programs will not affect the security of the HSM itself, and also prevents malware attacks.

[0078] 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, and the client that performs the steps related to data recovery is referred to as the first client. Both the first client and the second client can interact with the service side. The client may be an application, software, or a combination of software and hardware, which is set on a network terminal.

[0079] In cloud storage, enterprise disaster recovery or distributed storage systems, high data security requirements are required, and the security of data backup and recovery is the key.

[0080] Based on the above application scenarios, the client can send a backup data packet to the server, and can also receive a recovery strategy package corresponding to the ciphertext data corresponding to the backup data packet sent by the server, and restore the ciphertext data based on the recovery strategy in the backup data packet.

[0081] 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. It may be two clients. This is only used as an example and does not constitute a limitation on the scope of protection of the claims.

[0082] The following is an example in which the second client sends a backup data packet to the service side, the first client receives the recovery strategy corresponding to the ciphertext data corresponding to the backup data packet sent by the service side, and recovers the ciphertext data based on the recovery strategy.

[0083] The embodiment of the present application also provides a data processing method, which is applied to a second client. The second client is used for data backup, can encrypt the plaintext user number, and send the encrypted ciphertext data and the data recovery strategy for restoring the ciphertext data to the service side.

[0084] Combination Figure 2 , the data backup method in the embodiment of the present application includes:

[0085] Exemplarily, the method comprises:

[0086] S110: The second client encrypts the plaintext data to be backed up to generate ciphertext data DataCipher.

[0087] The plaintext data to be backed up may be sensitive data or ordinary data.

[0088] S111: For example, the second client may generate a first temporary key KEK, and encrypt the plaintext data to be backed up by using the first temporary key to generate ciphertext data, wherein the first temporary key may be, but is not limited to, a symmetric key.

[0089] S112: The second client encrypts the first temporary key to generate a third ciphertext. For example, the second client can use the second public key PK_backup of the service side to encrypt the first temporary key to generate a third ciphertext KEKCipher. Specifically, the second client uses the second public key of the hardware security module to asymmetrically encrypt the first temporary key, wherein the second private key corresponding to the second public key is only stored in the hardware security module. Since the hardware security module is hardware-isolated from other modules on the service side, the second public key and the second private key stored in the hardware security module will not be leaked to other modules on the service side, thereby ensuring the security of the first temporary key. At the same time, since the hardware isolation module does not have the ciphertext data corresponding to the first temporary key, it cannot obtain the plaintext data. However, other modules on the service side and the first client that needs to restore the ciphertext data do not have the key corresponding to the ciphertext data even if they have the ciphertext data, if they do not obtain the corresponding key returned by the hardware security module, and therefore, they cannot obtain the plaintext data corresponding to the ciphertext data. In addition, the data backed up by the second client can only be decrypted by the first client that receives at least two factors input by the user, and neither the hardware security module nor other modules on the service side can obtain the plaintext data corresponding to the ciphertext data, so that the backed up data can achieve end-to-end (i.e. client-to-client) security.

[0090] S113: The second client sends the third ciphertext to the hardware security module on the service side or other modules on the service side. For example, the second client can directly interact with the hardware security module on the service side, and the second client can directly send the third ciphertext to the hardware security module. The second client can also interact with other modules on the service side, and the second client can send the third ciphertext to other modules on the service side, which are then sent to the hardware security module by the other modules. However, other modules on the service side cannot obtain data such as keys from the hardware security module.

[0091] S120: The second client sets a data recovery strategy, where the data recovery strategy includes a plurality of factors required for recovering the ciphertext data.

[0092] 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.

[0093] S130: The second client sends the data recovery strategy to the hardware security module on the service side or other modules on the service side. Among them, there is hardware isolation between the hardware security module and the hardware of other modules on the service side. Similarly, the second client can directly interact with the hardware security module on the service side, and the second client can send the data recovery strategy directly to the hardware security module. The second client can also interact with other modules on the service side, and the second client can send the data recovery strategy to other modules on the service side, and then the other modules send it to the hardware security module. However, other modules on the service side cannot obtain data such as keys from the hardware security module.

[0094] For example, after receiving the third ciphertext, the hardware security module may decrypt and store the first temporary key from the third ciphertext. The first temporary key decrypted by the hardware security module will not leave the hardware security module. At the same time, the first temporary key is not stored in other locations on the service side, and other modules on the service side cannot obtain the first temporary key from the hardware security module. In other words, the first temporary key decrypted by the hardware security module will not leave the hardware security module, which prevents the first temporary key from leaving the hardware security module and entering other locations on the service side. The security of the plaintext data on the service side is threatened when there are both ciphertext data and the first temporary key. For example, when the service side has both ciphertext data and the first temporary key, the operator or attacker on the service side may have the opportunity to obtain the ciphertext data, causing the plaintext data to be stolen.

[0095] 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 including the third ciphertext and the data recovery strategy to ensure the integrity of the data packet. The second client may assemble the third ciphertext and the data recovery strategy into a backup data packet. It is understandable that the backup data packet may also include other data, for example, the ciphertext data may also be assembled into the backup data packet. Of course, it is understandable that the second client may also choose not to put the ciphertext data into the backup data packet, but to store it separately in other locations to meet different storage requirements.

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

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

[0098] The second client can also use the first temporary key to determine the message authentication code MAC1 of the backup data packet including the third ciphertext and the data recovery strategy, where the MAC1 value can be expressed as:

[0099] MAC1=HMAC_KEK(BackupPacket).

[0100] The message authentication code MAC1 is sent to the service side so that the service side verifies the integrity of the backup data packet through the message authentication code MAC2 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 MAC1 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.

[0101] The service side can use the same key and algorithm to perform the same operation on the received message, generate the message authentication code MAC2, and compare 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.

[0102] 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; after receiving the above signal sent by the service side, the second client can send the backup data packet to the service side. Then the service side compares the message authentication code MAC2 it generates with the received message authentication code MAC1 until MAC2 is the same as MAC1, and the service side saves the backup data packet.

[0103] In some embodiments, the second client determines the first private key and the corresponding first 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 first private key (VK) and the first public key (pK) corresponding to the second private key. The first private key is used to sign a recovery policy package, and the recovery policy package includes a recovery policy for recovering ciphertext data.

[0104] The first client is a client that needs to recover the ciphertext data and obtain the plaintext data. For example, the second client uploads the ciphertext data to the cloud (service side). When the first client needs the plaintext data corresponding to the ciphertext data, it needs to obtain the key corresponding to the ciphertext data from the cloud. The first client can decrypt the key obtained from the cloud based on the factors input by the received user, thereby obtaining the first temporary key, and then decrypt the ciphertext data with the first temporary key to finally obtain the plaintext data.

[0105] The data recovery method in the embodiment of the present application includes:

[0106] S210: The first client may send a data recovery request to the service side to request recovery of the backed-up ciphertext data.

[0107] S310: When the service side receives a data recovery request from the first client, the hardware security module on the service side generates a second temporary key K, and uses the second temporary key to encrypt the first temporary key to obtain the first ciphertext KEKC, wherein the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data. For example, when the service side receives a data recovery request from the first client, the hardware security module can be called to generate the second temporary key through the hardware security module. The generated second temporary key will not be separated from the hardware security module, and external devices or software cannot access the second temporary key. Of course, other modules on the service side cannot access the hardware security module to obtain the second temporary key, thereby ensuring the security of the second temporary key.

[0108] The ciphertext data is stored on the first client, other clients or other modules on the service side, but the hardware security module does not store the ciphertext data, so the hardware security module cannot decrypt the ciphertext data to obtain the plaintext data. The ciphertext data and the key for decrypting the ciphertext data are stored separately, which ensures the security of the ciphertext data.

[0109] In some examples, before the hardware security module encrypts the first temporary key using the second temporary key, the hardware security module further includes:

[0110] The hardware security module uses the second private key to decrypt the third ciphertext from the second client to obtain the first temporary key. The third ciphertext is obtained by the second client using the second public key corresponding to the second private key to encrypt the first temporary key. The second public key and the second private key belong to the hardware security module, and the second private key is only stored in the hardware security module, which ensures the security of the second private key. Other modules on the service side and operators on the service side cannot obtain the second private key by accessing the hardware security module. Therefore, other modules on the service side and operators on the service side cannot decrypt the third ciphertext with the second private key to obtain the first temporary key, and cannot decrypt the ciphertext data with the first temporary key to obtain the plaintext data, which ensures the security of the plaintext data.

[0111] In some embodiments, the other modules on the service side include a server, and before the hardware security module encrypts the first temporary key using the second temporary key, further includes:

[0112] The server receives a backup data packet and a message authentication code MAC1 corresponding to the backup data packet from the second client, wherein the backup data packet at least includes a third ciphertext.

[0113] The hardware security module decrypts the third ciphertext to obtain the first temporary key.

[0114] Exemplarily, when the ciphertext data is constructed into a backup data packet, the backup data packet BackupPacket can be expressed as:

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

[0116] The second client can 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 can be expressed as:

[0117] MAC1=HMAC_KEK(BackupPacket).

[0118] The second client sends the message authentication code MAC1 to the server, so that the server verifies the integrity of the backup data packet through the message authentication code generated by the server. 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 server.

[0119] When receiving the backup data packet, the server obtains the third ciphertext in the backup data packet. The hardware security module can use the second private key to decrypt the third ciphertext to obtain the first temporary key.

[0120] The hardware security module verifies the message authentication code based on the backup data packet. If the message authentication code passes the verification, the server saves the backup data packet.

[0121] The server 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 is verified based on the backup data packet, the backup data packet is saved.

[0122] 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.

[0123] S320: The hardware security module disperses the second temporary key into multiple subkeys based on the number of multiple factors required to recover the ciphertext data in the data recovery strategy, where the number of subkeys is the same as the number of factors.

[0124] Among them, multiple factors include any combination of two or more of the following factors:

[0125] password;

[0126] Verification code;

[0127] One-time password;

[0128] Biometrics.

[0129] For example, the number of multiple factors is n, where n is a positive integer greater than or equal to 2. The second temporary key is K, and K can be dispersed into n subkeys F(1), F(2), ..., F(n). For example, n is 3, one of the multiple factors can be a password, another can be a verification code, and the third can be a biometric feature. Of course, the number and combination of multiple factors can also be set according to the needs of the user, which is only used as an example and does not constitute a limitation on the scope of protection of the claims.

[0130] In some embodiments, before the hardware security module disperses the second temporary key into a plurality of sub-keys, the method further includes:

[0131] S321: The hardware security module uses the first public key pK to verify the first signature of the first recovery policy package, wherein the first recovery policy package includes at least a data recovery policy, and the first signature is obtained by the second client signing the first recovery policy package using the first private key VK corresponding to the first public key pK.

[0132] When the service side receives a recovery policy package, the hardware security module can use the first 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.

[0133] S322: When the first signature verification passes, the hardware security module determines the data recovery strategy as the recovery strategy for recovering the ciphertext data. The verification of the first signature can ensure that the recovery strategy is issued by an authorized signer (the second client), thereby ensuring the security of data recovery. Since the signer has the authority to issue the data recovery strategy, the signer can legally modify the relevant information in the data recovery strategy before or after the data is lost, thereby reducing the risk of data being unrecoverable and increasing the flexibility of data recovery. At the same time, the above method also helps to improve the security of data recovery.

[0134] S330: The hardware security module 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. For example, the hardware security module 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 subkey F(1) can be encrypted by the first factor key Y1 to obtain the second ciphertext FC1; the subkey F(2) can be encrypted by the first factor key Y2 to obtain the second ciphertext FC2, ..., the subkey F(n) can be encrypted by the first factor key Yn to obtain the second ciphertext FCn.

[0135] Based on the different types of factors, the hardware security module can use the generation algorithm corresponding to the type of factor to generate the corresponding first factor key. For example, the first factor key Yi can be generated based on the different types of factors (password factor, SMS verification code factor, OTP factor, and biometric factor) in the following way:

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

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

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

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

[0140] 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.

[0141] S340: The hardware security module returns the first ciphertext and the plurality of second ciphertexts to the first client, so that the first client can restore the backed-up ciphertext data.

[0142] Exemplarily, the hardware security module can directly return the first ciphertext and multiple second ciphertexts to the first client, or can return them to the first client through other modules on the service side, such as forwarding through the server. For example, the first client and the hardware security module can directly interact with the hardware module through a preset interface, and the hardware security module can return the first ciphertext and multiple second ciphertexts directly to the first client. In the case where the first client and the hardware security module cannot directly interact with data, the hardware security module can send the first ciphertext and multiple second ciphertexts to the server on the service side, and then the server sends them to the first client. In addition, the first ciphertext and multiple second ciphertexts can be sent to the first client separately, or the first ciphertext and multiple second ciphertexts can be packaged together and sent to the first client.

[0143] S220: The first client receives the first ciphertext and the multiple second ciphertexts from the hardware security module of the service side. The first client may receive the first ciphertext and the multiple second ciphertexts from the hardware security module of the service side through a port directly connected to the hardware security module, or may receive the first ciphertext and the multiple second ciphertexts from the hardware security module of the service side through a server of the service side.

[0144] S230: The first client determines corresponding at least two second factor keys respectively in response to the at least two factors received by the user input.

[0145] The user can input at least two factors to the first client, and the input method is related to the type of factor. For example, when the factor is a fingerprint, the user can press the fingertips of the finger to the fingerprint collection terminal, and the fingerprint collection terminal will send the collected fingerprint of the user to the first client. The fingerprint collection terminal can be a component of the first client, or it can be independent of the first client. When the factor is a text message verification code, the user can input the text message verification code into the text message verification code collection terminal of the first client. Of course, it can be understood that the first client can also obtain the factors input by the user in other ways. This is only used as an example and does not constitute a limitation on the scope of protection of the claims. The specific number of at least two factors received by the first client can be the same as the number of factors in the multiple factor combinations on the service side, or it can be less than the number of multiple factors in the multiple factor combinations on the service side, as long as it is higher than the minimum threshold value.

[0146] The first client calculates the second factor key Y2i corresponding to the at least two factors based on the at least two factors input by the user. The calculation method of the second factor key can be the same as the generation method of the first factor key, that is:

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

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

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

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

[0151] S240: The first client recovers the second temporary key: The first client determines the second temporary key based on at least two second factor keys and multiple second ciphertexts. The first client can decrypt corresponding at least two second ciphertexts in the multiple second ciphertexts based on the at least two second factor keys to obtain corresponding at least two subkeys; based on the at least two subkeys, reconstruct the second temporary key.

[0152] For example, the first client decrypts the corresponding second ciphertext according to the determined second factor key to recover the second temporary key. For example, the second ciphertext YC1 can be decrypted by the second factor key Y21, thereby recovering the subkey F(1) from the second ciphertext YC1, ..., the second ciphertext YC4 can be decrypted by the second factor key Y24, thereby recovering the subkey F(4) from the second ciphertext YC4, and then combining the recovered subkeys to obtain the second temporary key K. Of course, the recovered subkey is related to the factor input by the user, which is only used as an example and does not constitute a limitation on the scope of protection of the claims.

[0153] S250: The first client decrypts the data: the first client decrypts the first ciphertext KEKC using the second temporary key K to obtain the first temporary key KEK.

[0154] S260: The first client decrypts the ciphertext data DataCipher using the first temporary key to obtain the plaintext data, thereby realizing data recovery.

[0155] The ciphertext data may be sent by the second client to the service side through a backup data packet, and the first client may obtain the ciphertext data from other modules of the service side.

[0156] Of course, the ciphertext data may also be stored in other locations, for example, in the first client or other clients. In this implementation, when the first client restores the ciphertext data, it may obtain the ciphertext data from the first client or other clients.

[0157] In some embodiments, the plaintext data that needs to be backed up may be relatively large. The second client can encrypt the plaintext data that needs to be backed up in segments, and the first client can decrypt the ciphertext data in segments, saving time and encryption resources consumed during data backup and recovery, and reducing the cost of backing up and restoring data.

[0158] Combination Figure 3 , the embodiment of the present application further provides a hardware security module, the hardware security module is arranged on the service side;

[0159] The hardware security module includes at least one first processor, and at least one first processor is used for generating a second temporary key by the hardware security module when the service side receives a data recovery request from the first client, and encrypting the first temporary key with the second temporary key to obtain a first ciphertext, wherein the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data; wherein the hardware security module is hardware-isolated from other modules on the service side; the hardware security module disperses the second temporary key into multiple sub-keys based on the number of multiple factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of sub-keys is the same as the number of factors; the hardware security module generates a corresponding first factor key for each factor, and encrypts the corresponding sub-keys with the first factor key to obtain multiple second ciphertexts; and returns the first ciphertext and the multiple second ciphertexts to the first client so that the first client can recover the backed-up ciphertext data.

[0160] Combination Figure 4 , the embodiment of the present application further provides a first client, including:

[0161] At least one third processor is used to send a data recovery request to the service side to request the recovery of the backed-up ciphertext data; receive a first ciphertext and multiple second ciphertexts from a hardware security module on the service side; wherein the hardware security module is hardware-isolated from other modules on the service side; determine at least two corresponding second factor keys respectively in response to at least two factors received by user input; determine a second temporary key based on at least two second factor keys and the multiple second ciphertexts; decrypt the first ciphertext by the second temporary key to obtain the first temporary key; decrypt the ciphertext data by the first temporary key to obtain plaintext data.

[0162] Combination Figure 5 The embodiment of the present application further provides a second client, including:

[0163] At least one fourth processor is used to encrypt the plaintext data to be backed up and generate ciphertext data; set a data recovery strategy, wherein the data recovery strategy includes multiple factors required for recovering the ciphertext data; send the data recovery strategy to the hardware security module on the service side or other modules on the service side; wherein the hardware security module is physically isolated from the hardware resources of other modules on the service side.

[0164] 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.

[0165] An embodiment of the present application also provides a computer program product, characterized in that it includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of the method described in any one of the above embodiments are implemented.

[0166] 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.

[0167] Several embodiments of the present application have been 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 claimed by the present application.

Claims

1. A data processing method, characterized in that: Applied to hardware security modules; The hardware security module is arranged on the service side, and the method comprises: When the service side receives a data recovery request from the first client, the hardware security module generates a second temporary key, uses the second temporary key to encrypt the first temporary key, and obtains a first ciphertext, wherein the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data; wherein the hardware security module is hardware-isolated from other modules of the service side; The hardware security module disperses the second temporary key into a plurality of subkeys based on the number of a plurality of factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of the subkeys is the same as the number of the factors; The hardware security module generates a corresponding first factor key for each factor, and uses the first factor key to encrypt the corresponding subkey to obtain a plurality of second ciphertexts; The first ciphertext and the plurality of second ciphertexts are returned to the first client, so that the first client can restore the backed-up ciphertext data.

2. The data processing method according to claim 1, characterized in that: The ciphertext data is stored on the first client, other clients or other modules on the service side.

3. The data processing method according to any one of claims 1 to 2, characterized in that: The hardware security module generates a corresponding first factor key for each factor, including: Based on different types of factors, the hardware security module generates a corresponding first factor key using a generation algorithm corresponding to the type of the factor.

4. The data processing method according to any one of claims 1 to 3, characterized in that: The multiple factors include any two or more of the following factors: password; Verification code; One-time password; Biometrics.

5. The data processing method according to any one of claims 1 to 4, characterized in that: Before the hardware security module uses the second temporary key to encrypt the first temporary key, the hardware security module further includes: The hardware security module uses the second private key to decrypt the third ciphertext from the second client to obtain the first temporary key; the third ciphertext is obtained by the second client encrypting the first temporary key using the second public key corresponding to the second private key.

6. The data processing method according to any one of claims 1 to 5, characterized in that: The other modules of the service side include a server, and before the hardware security module encrypts the first temporary key using the second temporary key, further include: The server receives a backup data packet from the second client and a message authentication code corresponding to the backup data packet, wherein the backup data packet at least includes the third ciphertext; Decrypting, by the hardware security module, the third ciphertext to obtain the first temporary key; The hardware security module verifies the message authentication code based on the backup data packet; When the message authentication code passes the verification, the server saves the backup data packet.

7. The data processing method according to any one of claims 1 to 6, characterized in that: Before the hardware security module disperses the second temporary key into a plurality of sub-keys, the method further includes: The hardware security module verifies a first signature of the first recovery policy package using a first public key, wherein the first recovery policy package includes at least the data recovery policy, and the first signature is obtained by the second client signing the first recovery policy package using a first private key corresponding to the first public key; When the first signature verification passes, the hardware security module determines the data recovery strategy as a recovery strategy for recovering the ciphertext data.

8. A data processing method, characterized in that: Applied to a first client, the method includes: Send a data recovery request to the service side to request the recovery of the backed-up ciphertext data; Receiving a first ciphertext and a plurality of second ciphertexts from a hardware security module of the service side; wherein the hardware security module is hardware-isolated from other modules of the service side; determining corresponding at least two second factor keys, respectively, for at least two factors received in response to user input; determining a second temporary key based on the at least two second factor keys and the plurality of second ciphertexts; Decrypting the first ciphertext using the second temporary key to obtain a first temporary key; The ciphertext data is decrypted using the first temporary key to obtain plaintext data.

9. The data processing method according to any one of claim 8, characterized in that: Also includes: Obtain the ciphertext data from the first client and other clients; or, The ciphertext data is obtained from other modules on the service side.

10. A data processing method, characterized in that: Applied to the second client, the method includes: Encrypt the plaintext data to be backed up and generate ciphertext data; Setting a data recovery strategy, wherein the data recovery strategy includes a plurality of factors required for recovering the ciphertext data; The data recovery strategy is sent to a hardware security module on the service side or other modules on the service side; wherein the hardware security module is physically isolated from the hardware resources of other modules on the service side.

11. The data processing method according to claim 10, characterized in that: Encrypt the plaintext data to be backed up and generate ciphertext data, including: generating a first temporary key; Encrypting the plaintext data to be backed up by using the first temporary key to generate ciphertext data; The method further comprises: Encrypting the first temporary key to generate a third ciphertext; The third ciphertext is sent to the hardware security module of the service side or other modules of the service side.

12. The data processing method according to claim 11, characterized in that: Also includes: Using the first temporary key, determining a message authentication code of a backup data packet including the third ciphertext and the data recovery strategy; The message authentication code is sent to the service side.

13. The data processing method according to claim 11, characterized in that: Encrypting the first temporary key includes: The first temporary key is asymmetrically encrypted using a second public key of the hardware security module, wherein a second private key corresponding to the first public key is only stored in the hardware security module.

14. A hardware security module, characterized in that: The hardware security module is arranged on the service side; The hardware security module includes at least one first processor, and the at least one first processor is used to generate a second temporary key by the hardware security module when the service side receives a data recovery request from the first client, and use the second temporary key to encrypt the first temporary key to obtain a first ciphertext, and the first temporary key is used to encrypt the backed-up plaintext data to obtain the ciphertext data; wherein the hardware security module is hardware-isolated from other modules on the service side; the hardware security module disperses the second temporary key into multiple sub-keys based on the number of multiple factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of the sub-keys is the same as the number of the factors; the hardware security module generates a corresponding first factor key for each factor, and uses the first factor key to encrypt the corresponding sub-key to obtain multiple second ciphertexts; the first ciphertext and the multiple second ciphertexts are returned to the first client, so that the first client can recover the backed-up ciphertext data.

15. A first client, characterized in that: include: at least one third processor, configured to send a data recovery request to the service side to request recovery of the backed-up ciphertext data; Receive a first ciphertext and multiple second ciphertexts from a hardware security module on the service side; wherein the hardware security module is hardware-isolated from other modules on the service side; determine corresponding at least two second factor keys respectively in response to at least two factors received by user input; determine a second temporary key based on the at least two second factor keys and the multiple second ciphertexts; decrypt the first ciphertext using the second temporary key to obtain a first temporary key; decrypt the ciphertext data using the first temporary key to obtain plaintext data.

16. A second client, characterized in that: include: at least one fourth processor, configured to encrypt the plaintext data to be backed up and generate ciphertext data; A data recovery strategy is set, wherein the data recovery strategy includes multiple factors required to recover the ciphertext data; the data recovery strategy is sent to a hardware security module on the service side or other modules on the service side; wherein the hardware security module is physically isolated from the hardware resources of other modules on the service side.

17. 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 13 is implemented.

18. 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 as claimed in any one of claims 1 to 13.

Images