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

Abstract

The present application provides a data processing method, a hardware security module, a client, a storage medium and a computer program product. The data processing method applied to the hardware security module includes: when receiving a data recovery request from a first client, the hardware security module generates a second temporary key, uses 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; 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 subkeys based on the number of multiple factors required for recovering the ciphertext data in the data recovery strategy; the hardware security module generates a first factor key for each factor, encrypts the subkey using the first factor key, and obtains 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.

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] Data security is crucial in cloud storage, enterprise disaster recovery, and distributed storage systems. However, existing technologies lack hardware-level isolation and protection, allowing attackers to 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 embodiments of the present application adopt the following technical solution: a data processing method applied to a hardware security module; the hardware security module is provided 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, encrypts the first temporary key using the second temporary key to obtain a first ciphertext, and uses the first temporary key 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;

[0006] The hardware security module disperses the second temporary key into a plurality of subkeys based on the number of multiple factors required to recover 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 multiple 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 encrypting the first temporary key using the second 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 on the service side include a server, and before the hardware security module encrypts the first temporary key using the second temporary key, further include:

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

[0021] Decrypting the third ciphertext by the hardware security module 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 multiple 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] In a case where 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 present application also provides a data processing method, which is applied to a first client and includes:

[0028] Send a data recovery request to the server to restore the backed-up encrypted data.

[0029] receiving a first ciphertext and a plurality of 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;

[0030] determining corresponding at least two second factor keys for each of the 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 further includes:

[0035] Obtain 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 present application also provides a data processing method, which is applied to a second client. 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 to recover the ciphertext data;

[0040] The data recovery strategy is sent to the hardware security module of the service side or other modules of the service side; wherein the hardware security module is physically isolated from the hardware of other modules of 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 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 further 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 includes:

[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 further provides a hardware security module, wherein the hardware security module is provided 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 subkeys based on the number of multiple 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 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.

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

[0055] At least one third processor is configured to send a data recovery request to a service side to request recovery of 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 as input by a user; 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; and decrypt the ciphertext data using the first temporary key to obtain plaintext data.

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

[0057] At least one fourth processor is configured to encrypt the plaintext data to be backed up to generate ciphertext data; set a data recovery strategy, wherein the data recovery strategy includes multiple factors required to recover the ciphertext data; and send the data recovery strategy 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.

[0058] An embodiment of the present application further 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 is set up on the service side, which is hardware-isolated from other modules 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 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 related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

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

[0064] Figure 2 This is a flowchart of a data backup and data recovery method according to 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 the 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 merely 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 certain specific examples, those skilled in the art will readily be able to 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 from the following detailed description when taken in conjunction with the accompanying drawings.

[0074] Specific embodiments of the present application will be described hereinafter with reference to the accompanying drawings; however, it should be understood that the embodiments described are merely examples of the present application and may be implemented in a variety of ways. Familiar and / or repetitive functions and structures are not described in detail to avoid obscuring the present application with unnecessary or redundant details. Therefore, the specific structural and functional details described herein are not intended to be limiting, but rather serve merely as a basis and representative basis for the claims to teach those skilled in the art to variously utilize the present application 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," which may all 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 server can communicate and exchange data. The server can include a hardware security module (HSM) and, of course, other modules. The HSM is hardware-isolated from other modules on the server side. Specifically, the HSM can integrate secure cryptographic algorithms and key management functions and is a hardware device. The HSM provides hardware-level protection, isolating it from other modules on the server side. These modules can be hardware or software. For example, the server side can be software deployed on a cloud server.

[0077] Hardware security modules (HSMs) can be directly connected to computers or network servers via expansion cards or external devices, providing strong security for the server side. "Hardware isolation" refers to the physical and / or logical separation between the HSM and other modules on the server side. This separation prevents unauthorized access or tampering of keys and sensitive information within the HSM, thereby enhancing overall system security. Physical isolation refers to the HSM typically existing as a standalone hardware device, connected to the server via a physical connection (such as USB or PCI-E). This physical separation prevents keys and sensitive information within the HSM from being accessed or tampered with by other software or hardware components on the server. Logical isolation, in addition to physical isolation, enhances HSM security through additional logical isolation. For example, users can run specially developed modules on the HSM's internal processor, isolated from the HSM's native programs. This isolation ensures that user-defined programs do not compromise the security of the HSM itself and also prevents malware attacks.

[0078] The client can be one or more. For example, for ease of description and distinction, in the embodiments of the present application, the client that performs steps related to data backup is referred to as the second client, and the client that performs 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 can be an application, software, or a combination of software and hardware, installed 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 key.

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

[0081] It is understood that in some cases, the first client and the second client can be the same client. That is, the same client can interact with the service side during data backup and restoration. It can be two clients. This is merely an example and does not limit the scope of protection of the claims.

[0082] The following example illustrates that 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] An 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 household number, and send the encrypted ciphertext data and the data recovery strategy for recovering the ciphertext data to the service side.

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

[0085] Exemplarily, the method includes:

[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 can 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 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 on 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, if the other modules on the service side and the first client that needs to recover the ciphertext data do not obtain the corresponding key returned by the hardware security module, even if they have the ciphertext data, they do not have the key corresponding to the ciphertext data. 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, while 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 another module on the service side. For example, the second client can directly exchange data with the hardware security module on the service side and send the third ciphertext directly to the hardware security module. The second client can also exchange data with other modules on the service side and send the third ciphertext to other modules on the service side, which then 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.

[0091] S120: The second client sets a data recovery strategy, where the data recovery strategy includes multiple factors required to recover the ciphertext data.

[0092] Here, "factors" refer to the different types of information or elements that users need to provide to prove their identity. These factors are generally 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 a factor combination (such as a password) is leaked, as long as the other factors (such as mobile phone verification code, biometrics, etc.) remain secure. By combining multiple different types of factors, stronger security can be provided for data backup and data recovery. These factors have attributes 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 user's specific needs, security level, and application scenario to achieve the best security effect.

[0093] S130: The second client sends the data recovery policy to the hardware security module on the service side or other modules on the service side. The hardware security module is hardware-isolated from other modules on the service side. Similarly, the second client can directly interact with the hardware security module on the service side and send the data recovery policy directly to the hardware security module. The second client can also interact with other modules on the service side and send the data recovery policy to other modules on the service side, which then 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 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, preventing the first temporary key from leaving the hardware security module and entering other locations on the service side. When the service side has both ciphertext data and the first temporary key, the security of the plaintext data is threatened. 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 can also use the first temporary key to determine the message authentication code MAC1 of the backup data packet that includes the third ciphertext and the data recovery policy to ensure the integrity of the data packet. The second client can assemble the third ciphertext and the data recovery policy into a backup data packet. It is understood that the backup data packet can also include other data, for example, the ciphertext data can also be assembled into the backup data packet. Of course, it is understood that the second client can also choose not to include the ciphertext data in the backup data packet, but instead store it separately in another location 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 may also use the first temporary key to determine a message authentication code MAC1 of a backup data packet including the third ciphertext and the data recovery strategy, where the MAC1 value may be expressed as:

[0099] MAC1=HMAC_KEK(BackupPacket).

[0100] The message authentication code MAC1 is sent to the server, allowing the server to verify the integrity of the backup data packet using the message authentication code MAC2 generated by the server. A message authentication code is a keyed hash function used to ensure message integrity and source authentication. The MAC1 value can be calculated by the second client using the first temporary key and the message as input using a preset algorithm, and appended to the end of the message and sent to the server.

[0101] The server can use the same key and algorithm to perform the same operation on the received message to generate a message authentication code (MAC2). The server then 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. In other words, if the message authentication code based on the backup data packet is verified successfully, the backup data packet is saved.

[0102] For example, when the service side receives the message authentication code MAC1 corresponding to the backup data packet, the service side can generate the service-side message authentication code MAC2. If 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 authentic. The service side can save the received backup data packet. If MAC2 is different from MAC1, it means that the data in the backup data packet received by the service side may have been stolen and lost, or may have been tampered with, and the backup data packet received by the service side is untrustworthy. 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 untrustworthy; after receiving the above signal sent by the service side, the second client can send the backup data packet to the service side. The service side then compares the message authentication code MAC2 it generated 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 from existing public and private keys a pair of 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, which includes a recovery policy for recovering ciphertext data.

[0104] The first client is the 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 user, thereby obtaining a first temporary key. The first client then decrypts 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 a 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, it can call the hardware security module to generate a 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] Ciphertext data is stored on the first client, other clients, or other modules on the server side, but not in the hardware security module. Therefore, the hardware security module cannot decrypt the ciphertext data to obtain the plaintext data. Ciphertext data and the decryption key are stored separately, ensuring the security of the ciphertext data.

[0109] In some examples, before encrypting 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, operators on the service side, etc. 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, thereby ensuring 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 include:

[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 includes at least the third ciphertext.

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

[0114] For example, 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, allowing the server to verify the integrity of the backup data packet using the message authentication code generated by the server. A message authentication code is a keyed hash function used to ensure message integrity and source authentication. The MAC value can be calculated by the second client using the first temporary key and the message as input using a preset algorithm, and then appended 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, generating a message authentication code (MAC2). The server then 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. In other words, if the message authentication code based on the backup data packet is verified successfully, the backup data packet is saved.

[0122] For example, the service side receives the message authentication code MAC1 corresponding to the backup data packet. The service side can generate a message authentication code MAC2 for the service side. If 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, is complete and authentic, and the service side can save the received backup data packet. If MAC2 is different from MAC1, it means that the data in the backup data packet received by the service side may have been stolen and lost, or may have been tampered with, and the backup data packet received by the service side is untrustworthy. 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 untrustworthy. Optionally, after receiving the above signal sent by the service side, the second client can resend the backup data packet to the service side. The service side then regenerates the message authentication code MAC3 in a similar manner to the above, compares MAC3 with the received message authentication code MAC1, and 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 the subkeys is the same as the number of the factors.

[0124] The 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, if 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. This 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 using the first private key VK corresponding to the first public key pK to sign the first recovery policy package.

[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 trustworthy.

[0133] S322: If the first signature verification passes, the hardware security module determines the data recovery policy as the recovery policy for recovering the ciphertext data. The verification of the first signature can ensure that the recovery policy is issued by an authorized signer (the second client), thereby ensuring the security of data recovery. Because the signer has the authority to issue the data recovery policy, the signer can legally modify the relevant information in the data recovery policy 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 using the first factor key Y1 to obtain the second ciphertext FC1; the subkey F(2) can be encrypted using the first factor key Y2 to obtain the second ciphertext FC2, and so on. The subkey F(n) can be encrypted using 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 factor type 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 be used to generate a verification code and derive a key;

[0138] OTP factor: A 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. This is merely an example and does not limit 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 it can be forwarded to the first client through other modules on the service side, such as 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 a first ciphertext and multiple second ciphertexts from the hardware security module on the service side. The first client may receive the first ciphertext and multiple second ciphertexts from the hardware security module on the service side through a port directly connected to the hardware security module, or may receive the first ciphertext and multiple second ciphertexts from the hardware security module on the service side through a server on 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 tip 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 independent of the first client. When the factor is an SMS verification code, the user can input the SMS verification code into the SMS verification code collection terminal of the first client. Of course, it is understandable 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 the at least two factors received by the first client can be the same as the number of factors in the multiple factor combination on the service side, or it can 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.

[0146] The first client calculates a second factor key Y2i corresponding to 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 be used to generate a verification code and derive a key;

[0149] OTP factor: A 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 the at least two second factor keys and the plurality of second ciphertexts. The first client may decrypt at least two corresponding second ciphertexts from the plurality of second ciphertexts using the at least two second factor keys to obtain at least two corresponding subkeys. The first client then reconstructs the second temporary key based on the at least two subkeys.

[0152] For example, the first client decrypts the corresponding second ciphertext based on the determined second factor key to recover the second temporary key. For example, the second ciphertext YC1 can be decrypted using the second factor key Y21, thereby recovering subkey F(1) from the second ciphertext YC1, ..., the second ciphertext YC4 can be decrypted using the second factor key Y24, thereby recovering subkey F(4) from the second ciphertext YC4, and then the recovered subkeys are combined to obtain the second temporary key K. Of course, the recovered subkeys are related to the factors input by the user, and this 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 recovering the data.

[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 recovers 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 recovering data.

[0158] Combine Figure 3 , the embodiment of the present application further provides a hardware security module, which 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 to generate a second temporary key 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 subkeys based on the number of multiple factors required for recovering the ciphertext data in the data recovery strategy, wherein the number of subkeys is the same as the number of 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 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] Combine Figure 4 , the embodiment of the present application further provides a first client, including:

[0161] At least one third processor is configured to send a data recovery request to a service side to request recovery of 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 as input by a user; 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 the first temporary key; and decrypt the ciphertext data using the first temporary key to obtain plaintext data.

[0162] Combine Figure 5 , this embodiment of the 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 to recover the ciphertext data; and 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 further 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 further provides a computer program product, characterized in that it includes a computer program / instruction, which, when executed by a processor, implements the steps of the method described in any one of the above embodiments.

[0166] It should be noted that the computer storage medium of the present application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage medium, a magnetic storage medium, or any suitable combination of the above. In the present application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can 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 that can transmit, propagate, or transport a program configured for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, antenna, optical cable, RF, or any suitable combination thereof.

[0167] The above describes in detail several embodiments of the present application, 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 provided on the service side, and the method includes: When the service side receives a data recovery request from the first client, the hardware security module generates a second temporary key, encrypts the first temporary key using the second temporary key to obtain a first ciphertext, and uses the first temporary key 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 a plurality of subkeys based on the number of multiple factors required to recover the ciphertext data in the data recovery strategy, wherein the number of the subkeys is the same as the number of the factors, and the factors are different types of information or elements proving the identity of the user; 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; 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, wherein: 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 2, 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 2, characterized in that: Before encrypting the first temporary key using the second 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 2, characterized in that: 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 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 includes at least a third ciphertext; Decrypting the third ciphertext, by the hardware security module, 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 2, characterized in that: Before the hardware security module disperses the second temporary key into multiple subkeys, the method further includes: The hardware security module verifies a first signature of a 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; In a case where 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 server to restore the backed-up encrypted data. receiving a first ciphertext and a plurality of 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; Determining at least two corresponding second factor keys based on at least two factors received in response to user input; factors are different types of information or elements that prove the identity of the user; 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 claim 8, wherein: 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: generating a first temporary key; Encrypting the plaintext data to be backed up using the first temporary key to generate ciphertext data; setting a data recovery strategy, wherein the data recovery strategy includes multiple factors required to recover the ciphertext data; the factors are different types of information or elements that prove the identity of the user; Sending the data recovery strategy to the hardware security module of the service side or other modules of the service side; wherein the hardware security module is physically isolated from the hardware of other modules of the service side; encrypting the first temporary key to generate a third ciphertext; Sending the third ciphertext to a hardware security module on the service side or another module on the service side; The data recovery strategy can be used by the hardware security module to disperse the second temporary key generated by the hardware security module into multiple subkeys based on the number of multiple factors when recovering ciphertext data; the number of the subkeys is the same as the number of the factors; and the second temporary key is used to encrypt the first temporary key.

11. The data processing method according to claim 10, 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.

12. The data processing method according to claim 10, 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 second public key is only stored in the hardware security module.

13. A hardware security module, characterized in that: The hardware security module is provided 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 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 subkeys based on the number of multiple factors required for recovering ciphertext data in the data recovery strategy, wherein the number of subkeys is the same as the number of factors, and the factors are different types of information or elements that prove the user's identity; 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; 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.

14. 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; The method includes receiving 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; determining corresponding at least two second factor keys in response to at least two factors received as input by a user, where the factors are different types of information or elements that prove the identity of the user; determining a second temporary key based on the at least two second factor keys and the multiple second ciphertexts; decrypting the first ciphertext using the second temporary key to obtain the first temporary key; and decrypting the ciphertext data using the first temporary key to obtain plaintext data.

15. A second client, characterized in that: include: at least one fourth processor, configured to generate a first temporary key; Encrypting the plaintext data to be backed up using the first temporary key to generate ciphertext data; Setting a data recovery strategy, wherein the data recovery strategy includes multiple factors required to recover the ciphertext data, where the factors are different types of information or elements proving the identity of the user; sending the data recovery strategy 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 the other modules on the service side; encrypting the first temporary key to generate a third ciphertext; The fourth processor is also used to send the third ciphertext to the hardware security module on the service side or other modules on the service side; wherein, the data recovery strategy can be used by the hardware security module to disperse the second temporary key generated by the hardware security module into multiple sub-keys based on the number of multiple factors when recovering the ciphertext data; the number of the sub-keys is the same as the number of the factors; the second temporary key is used to encrypt the first temporary key.

16. 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 12 is implemented.

17. 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 12.

Images