A method, device and medium for cooperative encryption based on multiple cryptographic devices

Abstract

This invention discloses a method, device, and medium for collaborative encryption protection based on multiple cryptographic devices, relating to the field of data security technology. Multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and encrypt the corresponding symmetric keys with public keys. All symmetric keys are XORed bitwise to synthesize a core data protection key, which is then used to encrypt core data to form core data ciphertext. The core data ciphertext, each public key, and each encrypted symmetric key are assembled into a backup file. The backup file is parsed to obtain the corresponding data. Each cryptographic device is matched with the public key in the backup file; devices that successfully match decrypt using their private keys to obtain the corresponding symmetric key. All decrypted symmetric keys are XORed to restore the core data protection key, and finally, the core data is decrypted. This invention requires all authorized cryptographic devices to participate in the encryption and decryption operations, solving the problem of secure collaborative control of core data in scenarios where multiple parties do not trust each other.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a method, device and medium for collaborative encryption protection based on multiple cryptographic devices. Background Technology

[0002] In the field of internet and information security technology, encrypted backup and secure recovery of core data is a fundamental and critical requirement. Existing technologies widely employ cryptographic algorithms to encrypt data, with decryption and recovery operations entirely dependent on the corresponding key. In this model, the key holder has sole control over complete access to and management of the data. This approach is effective in most scenarios where a single party is responsible for operation and management.

[0003] The inventors of this application have discovered that in practical applications, there are special scenarios such as multi-party cooperation, separation of powers and responsibilities, or mutual distrust, requiring the joint participation and mutual checks and balances of multiple independent entities to authorize the execution of encryption and decryption operations on core data. Existing single-key control mechanisms have inherent limitations in such scenarios and cannot meet the technical requirements of equal and collaborative control among multiple parties. Summary of the Invention

[0004] This invention provides a method, device, and medium for collaborative encryption protection based on multiple cryptographic devices. The technical problem it aims to solve is: how to provide a secure collaborative control scheme that requires the joint participation of multiple authorized entities to complete the encryption and decryption of core data.

[0005] Firstly, embodiments of the present invention provide a method for collaborative encryption protection based on multiple cryptographic devices. This includes the encrypted backup process and the decryption and recovery process; The encrypted backup process includes the following steps: Multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and use the public key in the asymmetric key pair to encrypt the corresponding symmetric key to obtain multiple encrypted symmetric keys; The core data protection key is obtained by performing a bitwise XOR operation on multiple symmetric keys generated by multiple cryptographic devices. The core data is encrypted using the core data protection key to obtain the core data ciphertext; The core data ciphertext, the public keys of multiple cryptographic devices, and multiple symmetric encryption keys are assembled and backed up to form a backup file; The decryption and recovery process includes the following steps: Parse the backup file to obtain the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys; Multiple cryptographic devices are matched with the multiple public keys respectively. The cryptographic devices that are successfully matched use their own private keys to decrypt the corresponding encrypted symmetric keys to obtain multiple symmetric keys. Perform a bitwise XOR operation on the multiple decrypted symmetric keys to restore the core data protection key; The core data ciphertext is decrypted using the restored core data protection key to obtain the core data plaintext.

[0006] Optionally, the plurality of cryptographic devices respectively generate asymmetric key pairs and symmetric keys, including: The cryptographic device internally generates an asymmetric encryption key pair and derives the public key; Cryptographic devices use an internal random number generator to generate a symmetric key; Cryptographic devices use their own public key to encrypt their own symmetric key.

[0007] Optionally, the step of assembling and backing up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple cryptographic symmetric keys to form a backup file includes: The core data ciphertext, along with the public key generated by each cryptographic device and the symmetric key ciphertext encrypted with that public key, are stored together to form a structured backup file.

[0008] Optionally, the step of matching multiple cryptographic devices with the multiple public keys respectively, and the successfully matched cryptographic device using its own private key to decrypt the corresponding encrypted symmetric key to obtain multiple symmetric keys, including: Read the public key inside a cryptographic device; Search among the multiple public keys contained in the backup file for the public key that matches the one read. If the same public key is found, the encrypted symmetric key associated with the public key is retrieved from the backup file; The cryptographic device uses its own stored private key, which corresponds to the public key, to decrypt the acquired symmetric encryption key.

[0009] Optionally, the bitwise XOR operation is represented as: FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^ SecretKeyN, where SecretKey1 to SecretKeyN are symmetric keys generated or decrypted by multiple cryptographic devices respectively, N is the total number of cryptographic devices, and FinalSecretKey is the core data protection key.

[0010] Optionally, the core data is encrypted using a core data protection key, and the core data ciphertext is decrypted using a symmetric encryption algorithm.

[0011] Optionally, during the decryption and recovery process, if the internal public key read by a cryptographic device fails to be found among the multiple public keys contained in the backup file, it is determined that the cryptographic device does not have decryption and recovery authority, and the decryption process is terminated.

[0012] Optionally, the order in which multiple cryptographic devices operate is not restricted during the encryption backup process and the decryption recovery process.

[0013] Secondly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0014] Thirdly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0015] This invention provides a method, device, and medium for collaborative encryption protection based on multiple cryptographic devices. The method includes an encryption backup process and a decryption recovery process. The encryption backup process includes the following steps: multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and encrypt the corresponding symmetric keys using the public key in the asymmetric key pairs to obtain multiple encrypted symmetric keys; perform a bitwise XOR operation on the multiple symmetric keys generated by the multiple cryptographic devices to obtain a core data protection key; encrypt core data using the core data protection key to obtain core data ciphertext; assemble and back up the core data ciphertext, the public keys of the multiple cryptographic devices, and the multiple encrypted symmetric keys to form a backup file. The decryption recovery process includes the following steps: parsing the backup file to obtain the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys; matching the multiple cryptographic devices with the multiple public keys respectively, and decrypting the corresponding encrypted symmetric keys using the private key of the successfully matched cryptographic devices to obtain multiple symmetric keys; performing a bitwise XOR operation on the decrypted multiple symmetric keys to restore the core data protection key; and decrypting the core data ciphertext using the restored core data protection key to obtain core data plaintext. This invention utilizes the collaborative operation of multiple cryptographic devices. During the encryption backup process, each device independently generates an asymmetric key pair and a symmetric key, and encrypts its own symmetric key using a public key. The symmetric keys of all devices are then XORed to synthesize a core data protection key to encrypt the core data. During decryption and recovery, all devices must match and decrypt their respective symmetric keys, and then perform the same XOR operation to restore the core data protection key, thus successfully decrypting the core data. This method, from a cryptographic perspective, mandates the participation of all authorized devices, ensuring that no single party can independently complete the encryption and decryption operations. This achieves strict multi-party equal governance and effectively solves the problem of secure collaborative control of core data in scenarios where multiple parties distrust each other. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a collaborative encryption protection method based on multiple cryptographic devices provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a backup file provided in an embodiment of the present invention; Figure 3 A schematic block diagram of a computer device provided for an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0023] Please see Figure 1 This invention provides a method for collaborative encryption protection based on multiple cryptographic devices. The method includes an encryption backup process and a decryption recovery process. The encryption backup process includes the following steps: S1-S4.

[0024] S1, multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and use the public key in the asymmetric key pair to encrypt the corresponding symmetric key to obtain multiple encrypted symmetric keys.

[0025] In practice, the cryptographic device generates an asymmetric encryption key pair within its internal secure environment. This key pair includes a public key and a uniquely corresponding private key, where the public key can be exported for external use. Next, the same cryptographic device uses its built-in physical random number generator or a high-strength cryptographic pseudo-random number generator to generate a symmetric key of a specific length. Then, the cryptographic device uses its newly generated public key to encrypt its own generated symmetric key using an asymmetric encryption algorithm such as RSA or ECC, resulting in an encrypted symmetric key. This process is executed by multiple cryptographic devices, ultimately yielding multiple sets of data. Each set contains a public key, the ciphertext of the symmetric key (i.e., the encrypted symmetric key), and a private key stored only internally and never exported.

[0026] In some preferred embodiments, the plurality of cryptographic devices generate asymmetric key pairs and symmetric keys respectively, including: the cryptographic device internally generates a pair of asymmetric encryption key pairs and derives a public key; the cryptographic device uses an internal random number generator to generate a symmetric key; and the cryptographic device uses its own generated public key to encrypt its own generated symmetric key.

[0027] In practice, a cryptographic device, such as a smart key (UKey) conforming to PKCS#11 or the Chinese national cryptographic standard, invokes a key generation function within its internal protected cryptographic chip or secure area. This function generates a public-private key pair based on specified elliptic curve parameters or large prime numbers. The public key can be securely exported outside the device for later use, while the corresponding private key, after generation, is strictly confined to a secure storage area within the device, ensuring it cannot be read, copied, or exported, thus guaranteeing the exclusivity of the private key.

[0028] Furthermore, within the same cryptographic device, its random number generation module is invoked. This module preferably generates truly random numbers based on physical entropy sources (such as hardware noise), or employs a cryptographically certified pseudo-random number generation algorithm. Using the generated random numbers, a symmetric key with the required length and format for the specific algorithm is created. For example, for the AES-256 algorithm, a 256-bit key is generated. This symmetric key is also generated and temporarily stored within a secure environment within the device.

[0029] Furthermore, the device takes the public key and symmetric key it generated in the previous two steps as input and performs asymmetric encryption operations internally. Specifically, the symmetric key is used as the plaintext to be encrypted, and an encryption algorithm corresponding to the public key generated by the device (such as RSA or ECC encryption) is used to encrypt it. The encryption process is completed internally, and the output is an encrypted symmetric key, i.e., the ciphertext of the symmetric key. This ciphertext can be securely transmitted out of the device. At this point, a single cryptographic device has completed the preparation of all its key materials: a derivable public key, a private key known only internally, an original symmetric key known only internally, and a derivable encrypted symmetric key obtained by encrypting the symmetric key with the public key. All cryptographic devices execute the above three identical sub-steps independently and in parallel.

[0030] S2 performs a bitwise XOR operation on multiple symmetric keys generated by multiple cryptographic devices to obtain the core data protection key.

[0031] In practice, after preparing the independent keys for each device, the key synthesis phase begins. The system collects the original symmetric keys (i.e., the plaintext symmetric keys before encryption) generated by all cryptographic devices. These symmetric keys are used as input to perform a bitwise XOR operation. Specifically, the symmetric key generated by the first device is XORed with the symmetric key generated by the second device, and the result is then XORed with the symmetric key of the third device, and so on, until the symmetric keys of all N devices participate in the operation, ultimately outputting a core data protection key of the same length as the input key. The generation of this key strictly depends on the original symmetric keys of all participating devices.

[0032] It should be noted that the bitwise XOR operation requires all symmetric keys involved in the operation to have the same length. In this embodiment, each cryptographic device should follow a unified key length specification (e.g., generate a 256-bit key) when generating symmetric keys to ensure that the XOR operation can be executed correctly.

[0033] S3, use the core data protection key to encrypt the core data to obtain the core data ciphertext.

[0034] In practice, this core data protection key is used to perform encryption operations on the core data to be protected using a symmetric encryption algorithm such as AES, generating core data ciphertext.

[0035] S4. Assemble and back up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple encrypted symmetric keys to form a backup file.

[0036] In practice, data assembly and backup are performed. The system creates a backup file whose content is organized with the core encrypted data as the main data block. Simultaneously, the public keys previously obtained from each cryptographic device, along with the encrypted symmetric keys derived from those public keys, are stored in this backup file in an associative manner (e.g., through an index table, pairing list, or a specific data encapsulation format). At this point, the encryption backup process is complete, generating a backup file containing the encrypted core data and all necessary decryption metadata.

[0037] For example, in one embodiment, the structure of the backup file is as follows: Figure 2 As shown, where: EncryptedText contains the encrypted core data. PubKey1-PubKeyN are the public keys. EncryptedSecretkeyl-EncryptedSecretkeyN are the encryption symmetric keys.

[0038] In some preferred embodiments, the step of assembling and backing up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple encrypted symmetric keys to form a backup file includes: associating and storing the core data ciphertext, the public key generated by each cryptographic device, and the symmetric key ciphertext encrypted by the public key, to form a structured backup file.

[0039] In specific implementation, the format of the assembled backup file is defined. The core data ciphertext, the public key of each cryptographic device, and the ciphertext of the symmetric key encrypted with that public key are stored together to form a structured backup file. In the final stage of the encrypted backup process, the system needs to integrate all necessary data elements into a persistently stored file. These data elements include: the core data ciphertext obtained by encrypting the core data with the core data protection key; N public keys collected from the N participating cryptographic devices; and the corresponding N symmetric keys, where each symmetric key is generated by encrypting its own symmetric key with the public key of its corresponding device.

[0040] Implementing associated storage means explicitly establishing the pairing relationship between public keys and their corresponding cryptographic symmetric keys within the internal data structure of the backup file, ensuring that they form a logical whole with the core data ciphertext. One specific implementation is to use a serialization encoding format to construct this structured file. For example, a file header can be defined, indicating information such as the file version and the number of participants (N). Subsequently, the file body can contain an array or list of data blocks. Each item in this list corresponds to a data unit contributed by a cryptographic device, and each data unit contains at least two explicitly associated subfields: one subfield stores the device's public key data, and the other subfield stores the ciphertext data of the corresponding cryptographic symmetric key. These two subfields are stored contiguously, or logically bound through a common index value or unique identifier, allowing the parser to unambiguously identify them as belonging to the same device pair. After storing all the device data units, the core data ciphertext is stored as a separate data segment at the end of the file, or at a specific location after the file header.

[0041] Furthermore, another approach is to use self-describing structured data formats such as JSON, XML, or ASN.1 to encapsulate this information, clearly expressing the relationship between the public key and the cryptographic symmetric key, as well as their parallel relationship with the core data ciphertext, by defining objects and key-value pairs.

[0042] The structured backup file implementation method defined in this embodiment provides a reliable and efficient data foundation for the subsequent decryption and recovery process by mandating clear and orderly associated storage of key metadata in the backup file, and enhances the robustness and manageability of the solution.

[0043] Furthermore, the decryption and recovery process includes the following steps: S5-S8.

[0044] S5 parses backup files to obtain core data ciphertext, multiple public keys, and multiple encrypted symmetric keys.

[0045] In practice, the system reads and parses the backup file generated in the aforementioned steps, and extracts the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys from it.

[0046] S6, match multiple cryptographic devices with the multiple public keys respectively, and use the private key of the successfully matched cryptographic device to decrypt the corresponding encrypted symmetric key to obtain multiple symmetric keys.

[0047] In practice, device identity matching and key decryption are performed. For each cryptographic device that needs to participate in decryption, the system reads the public key stored internally by the device and compares it with the public key set extracted from the backup file. If an identical public key is found, the device is determined to be one of the legitimate authorized devices, and the corresponding encrypted symmetric key is retrieved from the backup file. Subsequently, the cryptographic device uses its internally stored private key, corresponding to the successfully matched public key, to perform asymmetric decryption on the retrieved encrypted symmetric key, thereby restoring the original symmetric key generated by the device during the encryption phase. This step must be successfully executed on all authorized cryptographic devices.

[0048] In some preferred embodiments, the step of matching multiple cryptographic devices with multiple public keys, and having a successfully matched cryptographic device decrypt the corresponding symmetric key using its own private key to obtain multiple symmetric keys, includes: reading a public key stored within a cryptographic device; searching for a public key identical to the read public key among multiple public keys contained in a backup file; if an identical public key is found, obtaining the symmetric key associated with the public key from the backup file; and the cryptographic device decrypting the obtained symmetric key using its own stored private key corresponding to the public key.

[0049] In practice, the following series of sub-operations are performed for each cryptographic device that needs to participate in decryption. First, the system reads the public key certificate or public key data object stored internally in the device's secure storage area by calling the interface provided by the cryptographic device, and then reads this public key data into the system memory as the identity identifier of the current device.

[0050] Further, the system compares the public key data read from the device in the previous step with a list of multiple public keys obtained after parsing the backup file. This comparison is either a precise byte-by-byte comparison or a comparison based on public key fingerprints (such as SHA-256 hash values) to confirm whether the public key read from the device is identical to a public key pre-stored in the backup file. This search process is a crucial criterion for determining whether the current device has legitimate decryption and recovery permissions.

[0051] Furthermore, if an identical public key is found in the second step, it indicates that the currently inserted cryptographic device was one of the legitimate participants in the original encryption backup process. The system then accurately locates and retrieves the specific symmetric key ciphertext stored along with the public key, based on the association of the public key in the backup file data structure (such as through an index or its position in a data pair).

[0052] Furthermore, after receiving the ciphertext of the encrypted symmetric key associated with its public key from the system, the cryptographic device calls a decryption function internally. This function uses a private key, securely stored within the device and strictly corresponding to the previously read public key, to perform an asymmetric decryption operation on the incoming ciphertext. The decryption operation is completed within the device's secure chip, ensuring the private key is not exposed. If the operation is successful, the original plaintext symmetric key is output; this symmetric key is the secret share generated by the device during the encryption phase. This symmetric key is then securely transmitted back to the system (and may be temporarily stored in secure memory if necessary) for subsequent synthesis operations. Each authorized device must successfully complete these four steps before contributing its own symmetric key.

[0053] This embodiment designs a standardized matching and decryption process that includes reading, searching, obtaining, and decryption, providing a precise and secure authorization verification and key extraction mechanism for multi-party collaborative decryption, and realizing precise identity authentication and data association based on cryptographic credentials.

[0054] In some preferred embodiments, during the decryption and recovery process, if the internal public key read by a cryptographic device fails to be found among the multiple public keys contained in the backup file, it is determined that the cryptographic device does not have decryption and recovery authority, and the decryption process is terminated.

[0055] In practice, when searching for a public key that is the same as the public key read by the current cryptographic device among the multiple public keys contained in the backup file, there are two possible results: the search is successful or the search fails.

[0056] This branch of the process is triggered when the system performs a comparison and search, and confirms that the public key read by the current device is different from all the public keys parsed from the backup file (i.e., no match is found in the list). The system first performs a judgment operation, logically based on the condition that the device's public key is not in the authorized public key list. Based on this judgment, the system concludes that the currently inserted cryptographic device does not have the legitimate authority to decrypt and restore the backup data. The device was not a participant in the original encryption backup process, or its public key information is inconsistent with the backup record.

[0057] After determining that the device lacks decryption and recovery permissions, the system immediately terminates the process. Terminating the decryption process means that the system will not attempt subsequent decryption steps (i.e., using the private key to decrypt the encrypted symmetric key) for the device, and will typically interrupt the entire decryption and recovery session.

[0058] In this embodiment, by introducing an explicit permission verification failure handling mechanism for the decryption and recovery process, the security, robustness, and auditability of the entire technical solution are significantly enhanced.

[0059] S7 performs a bitwise XOR operation on the multiple decrypted symmetric keys to restore the core data protection key.

[0060] In practice, after all authorized cryptographic devices have contributed their original decrypted symmetric keys, the system performs a bitwise XOR operation again. The multiple decrypted symmetric keys are then XORed using the same logic as the encryption backup time to reconstruct the core data protection key used during encryption.

[0061] In some preferred embodiments, the bitwise XOR operation is represented as: FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^ SecretKeyN, where SecretKey1 to SecretKeyN are symmetric keys generated or decrypted by multiple cryptographic devices respectively, and N is the total number of cryptographic devices.

[0062] In practice, the expression FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^SecretKeyN defines the rules for generating and restoring the core data protection key. In this expression, the symbol "^" represents a bitwise XOR Boolean operation. SecretKey1 to SecretKeyN represent symmetric keys generated (during encryption backup) or decrypted (during decryption recovery) by N cryptographic devices respectively, with FinalSecretKey being the core data protection key. These symmetric keys are typically binary data existing as a sequence of bytes, such as a 32-byte (256-bit) AES key.

[0063] The bitwise XOR operation explicitly defined in this embodiment, as a specific key synthesis and decryption function, brings crucial and unique cryptographic characteristics to the entire multi-party collaborative encryption scheme, achieving fully equivalent and indispensable collaborative control. The XOR operation has a vital property: a unique correct output value is obtained only if all input values ​​participating in the operation are completely correct. In this scheme, this means that the core data protection key, FinalSecretKey, is the collective product of N independent symmetric keys. During decryption, the same N symmetric keys used in encryption must be XORed to reconstruct the same FinalSecretKey. The absence of any one key, or any incorrect key, will result in a completely different, seemingly random bit string that cannot be used to decrypt the core data ciphertext.

[0064] S8. Use the restored core data protection key to decrypt the core data ciphertext to obtain the core data plaintext.

[0065] In practice, the restored core data protection key is used to perform decryption operations on the core data ciphertext using the same symmetric decryption algorithm as during encryption, outputting the original core data plaintext and completing the entire data recovery process.

[0066] This invention effectively solves the problem of secure data access under multi-party collaborative control by constructing a two-stage process that includes encrypted backup and decryption recovery, thus realizing a mandatory multi-party co-governance mechanism. The core of this method lies in designing the core data protection key, ultimately used to encrypt core data, as a synthesis of the independent symmetric keys of all participating cryptographic devices through a bitwise XOR operation. This mathematical property dictates that during decryption recovery, the symmetric keys of all participants must be collected and the same operation performed to accurately restore the core data protection key. The absence of any one device's key contribution will result in an incorrect key, leading to subsequent decryption failure. This cryptographically mandates that all authorized parties participate simultaneously, thus satisfying the need for joint control of data access rights in scenarios such as multi-party distrust. Furthermore, this scheme maintains a clear and efficient architecture while achieving high-level security goals. It cleverly combines the advantages of asymmetric and symmetric encryption, using asymmetric encryption to securely transmit the secret shares (symmetric keys) of each device and using symmetric encryption to efficiently process the core data itself. The entire process is logically coherent, with each step interconnected. The encryption backup process pre-sets all the necessary and interrelated conditions (public key, encrypted secret share, and synthesized ciphertext) for the decryption and recovery process, while the decryption and recovery process verifies the conditions and restores the data through reverse matching and calculation, forming a complete technical closed loop. Furthermore, since the core data protection key is temporarily synthesized and not stored permanently, the backup file only stores the encrypted secret share and public key. This reduces the security requirements for the backup file itself and enhances the overall security of the solution.

[0067] In some preferred embodiments, the encryption of core data using a core data protection key and the decryption of the core data ciphertext employ a symmetric encryption algorithm.

[0068] In practice, during the encryption backup process, after the core data protection key FinalSecretKey is synthesized through an XOR operation, this key is used as the key input for the symmetric encryption algorithm. The system selects a cryptographically secure symmetric encryption algorithm, such as the Advanced Encryption Standard (AES). Depending on the security level requirements, different key lengths such as AES-128, AES-192, or AES-256 can be selected. Simultaneously, an appropriate operating mode needs to be selected, such as CBC (Cryptographic Block Chaining) mode, CTR (Clock Counter) mode, or GCM (Galois / Counter mode), where GCM mode also provides authentication encryption functionality. After selecting the algorithm and mode, the system calls the corresponding encryption function, using the core data protection key FinalSecretKey as the encryption key and the plaintext core data to be protected as the input data, to perform the encryption operation. An initialization vector (IV) may also be needed during the operation; this IV can be randomly generated and stored along with the ciphertext. The output of the encryption operation is the ciphertext of the core data.

[0069] During the decryption and recovery process, once the core data protection key FinalSecretKey is successfully restored, the system uses the exact same symmetric encryption algorithm, operating mode, and parameters (such as the IV read from the backup file) as the encryption algorithm. The decryption function of this algorithm is called, using the restored FinalSecretKey as the decryption key and the ciphertext of the core data from the backup file as input, to perform the decryption operation. If the provided FinalSecretKey is correct and the ciphertext has not been tampered with, the decryption operation will successfully output the original plaintext core data. The encryption and decryption processes of the symmetric encryption algorithm use the same key, which is why it is called "symmetric." In this embodiment, encryption and decryption operations can be integrated into the same application software module. This module calls the corresponding encryption or decryption interface according to the current process (backup or recovery) and ensures the consistency of the algorithm, mode, and parameters.

[0070] In some preferred embodiments, the order in which multiple cryptographic devices operate is not restricted during the encryption backup process and the decryption recovery process.

[0071] In practice, the order in which multiple cryptographic devices operate during encryption backup and decryption recovery is unrestricted. This is reflected in the system's workflow design's inclusiveness regarding the order of operations, stemming from two key characteristics of the underlying technology design. First, the independence of key generation and submission. During encryption backup, each cryptographic device is limited to independently generating its own key materials (asymmetric key pairs, symmetric keys, and self-encryption). When collecting these materials, the system can be designed to process devices as they arrive. For example, the system provides an interface where each cryptographic device holder can sequentially insert a device. After the system calls the device's interface to complete key generation and data export, it temporarily stores the device's data and waits for the next device. The order in which devices are inserted and processed does not affect the randomness and independence of the keys generated within each device, nor does it affect the final collection of key materials.

[0072] Furthermore, the core operation (bitwise XOR) possesses commutative and associative properties. During encrypted backup, regardless of the order in which the system collects the N symmetric keys (SecretKey1 to SecretKeyN), when they are used to calculate FinalSecretKey, the XOR operation satisfies the commutative and associative laws, ensuring that the final result is identical regardless of the calculation order. In implementation, the system can perform cumulative XOR calculations on each key submitted by the devices in the order they are received, without requiring prior ordering. During decryption and recovery, the matching process is based on an exact lookup of the public key, not on a fixed order. The system can be designed to allow simultaneous access to all devices or sequential access. When each device connects, the system independently executes the process of "reading the public key - finding a match - decrypting the key," storing the decrypted symmetric key in a set. After all necessary devices have contributed their keys, the system retrieves all keys from this set and performs an XOR operation. Since the result of the XOR operation depends only on the key set itself and is independent of the order in which the keys are retrieved, the order of device access and decryption operations does not affect the final result.

[0073] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 can be a terminal or a server, wherein the server can be a standalone server or a server cluster composed of multiple servers.

[0074] The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0075] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, it causes the processor 502 to execute a method of encryption protection based on the collaborative use of multiple cryptographic devices.

[0076] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0077] The internal memory 504 provides an environment for the execution of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a method of encryption protection based on the collaborative encryption of multiple cryptographic devices.

[0078] The network interface 505 is used for network communication with other devices. Those skilled in the art will understand that the above structure is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. A specific computer device 500 may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.

[0079] The processor 502 is used to run a computer program 5032 stored in the memory to implement a collaborative encryption protection method based on multiple cryptographic devices, including an encryption backup process and a decryption recovery process. The encrypted backup process includes the following steps: Multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and use the public key in the asymmetric key pair to encrypt the corresponding symmetric key to obtain multiple encrypted symmetric keys; The core data protection key is obtained by performing a bitwise XOR operation on multiple symmetric keys generated by multiple cryptographic devices. The core data is encrypted using the core data protection key to obtain the core data ciphertext; The core data ciphertext, the public keys of multiple cryptographic devices, and multiple symmetric encryption keys are assembled and backed up to form a backup file; The decryption and recovery process includes the following steps: Parse the backup file to obtain the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys; Multiple cryptographic devices are matched with the multiple public keys respectively. The cryptographic devices that are successfully matched use their own private keys to decrypt the corresponding encrypted symmetric keys to obtain multiple symmetric keys. Perform a bitwise XOR operation on the multiple decrypted symmetric keys to restore the core data protection key; The core data ciphertext is decrypted using the restored core data protection key to obtain the core data plaintext.

[0080] Optionally, the plurality of cryptographic devices respectively generate asymmetric key pairs and symmetric keys, including: The cryptographic device internally generates an asymmetric encryption key pair and derives the public key; Cryptographic devices use an internal random number generator to generate a symmetric key; Cryptographic devices use their own public key to encrypt their own symmetric key.

[0081] Optionally, the step of assembling and backing up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple cryptographic symmetric keys to form a backup file includes: The core data ciphertext, along with the public key generated by each cryptographic device and the symmetric key ciphertext encrypted with that public key, are stored together to form a structured backup file.

[0082] Optionally, the step of matching multiple cryptographic devices with the multiple public keys respectively, and the successfully matched cryptographic device using its own private key to decrypt the corresponding encrypted symmetric key to obtain multiple symmetric keys, including: Read the public key inside a cryptographic device; Search among the multiple public keys contained in the backup file for the public key that matches the one read. If the same public key is found, the encrypted symmetric key associated with the public key is retrieved from the backup file; The cryptographic device uses its own stored private key, which corresponds to the public key, to decrypt the acquired symmetric encryption key.

[0083] Optionally, the bitwise XOR operation is represented as: FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^ SecretKeyN, where SecretKey1 to SecretKeyN are symmetric keys generated or decrypted by multiple cryptographic devices respectively, N is the total number of cryptographic devices, and FinalSecretKey is the core data protection key.

[0084] Optionally, the core data is encrypted using a core data protection key, and the core data ciphertext is decrypted using a symmetric encryption algorithm.

[0085] Optionally, during the decryption and recovery process, if the internal public key read by a cryptographic device fails to be found among the multiple public keys contained in the backup file, it is determined that the cryptographic device does not have decryption and recovery authority, and the decryption process is terminated.

[0086] Optionally, the order in which multiple cryptographic devices operate is not restricted during the encryption backup process and the decryption recovery process.

[0087] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0088] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program may be stored in a storage medium, which is a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0089] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program. When executed by a processor, the computer program causes the processor to perform a method for collaborative encryption protection based on multiple cryptographic devices, including an encryption backup process and a decryption recovery process; The encrypted backup process includes the following steps: Multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and use the public key in the asymmetric key pair to encrypt the corresponding symmetric key to obtain multiple encrypted symmetric keys; The core data protection key is obtained by performing a bitwise XOR operation on multiple symmetric keys generated by multiple cryptographic devices. The core data is encrypted using the core data protection key to obtain the core data ciphertext; The core data ciphertext, the public keys of multiple cryptographic devices, and multiple symmetric encryption keys are assembled and backed up to form a backup file; The decryption and recovery process includes the following steps: Parse the backup file to obtain the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys; Multiple cryptographic devices are matched with the multiple public keys respectively. The cryptographic devices that are successfully matched use their own private keys to decrypt the corresponding encrypted symmetric keys to obtain multiple symmetric keys. Perform a bitwise XOR operation on the multiple decrypted symmetric keys to restore the core data protection key; The core data ciphertext is decrypted using the restored core data protection key to obtain the core data plaintext.

[0090] Optionally, the plurality of cryptographic devices respectively generate asymmetric key pairs and symmetric keys, including: The cryptographic device internally generates an asymmetric encryption key pair and derives the public key; Cryptographic devices use an internal random number generator to generate a symmetric key; Cryptographic devices use their own public key to encrypt their own symmetric key.

[0091] Optionally, the step of assembling and backing up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple cryptographic symmetric keys to form a backup file includes: The core data ciphertext, along with the public key generated by each cryptographic device and the symmetric key ciphertext encrypted with that public key, are stored together to form a structured backup file.

[0092] Optionally, the step of matching multiple cryptographic devices with the multiple public keys respectively, and the successfully matched cryptographic device using its own private key to decrypt the corresponding encrypted symmetric key to obtain multiple symmetric keys, including: Read the public key inside a cryptographic device; Search among the multiple public keys contained in the backup file for the public key that matches the one read. If the same public key is found, the encrypted symmetric key associated with the public key is retrieved from the backup file; The cryptographic device uses its own stored private key, which corresponds to the public key, to decrypt the acquired symmetric encryption key.

[0093] Optionally, the bitwise XOR operation is represented as: FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^ SecretKeyN, where SecretKey1 to SecretKeyN are symmetric keys generated or decrypted by multiple cryptographic devices respectively, N is the total number of cryptographic devices, and FinalSecretKey is the core data protection key.

[0094] Optionally, the core data is encrypted using a core data protection key, and the core data ciphertext is decrypted using a symmetric encryption algorithm.

[0095] Optionally, during the decryption and recovery process, if the internal public key read by a cryptographic device fails to be found among the multiple public keys contained in the backup file, it is determined that the cryptographic device does not have decryption and recovery authority, and the decryption process is terminated.

[0096] Optionally, the order in which multiple cryptographic devices operate is not restricted during the encryption backup process and the decryption recovery process.

[0097] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk, or any other physical storage medium capable of storing program code. The computer-readable storage medium can be non-volatile or volatile.

[0098] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0099] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0100] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0101] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0102] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0103] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0104] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for collaborative encryption protection based on multiple cryptographic devices, characterized in that, This includes the encrypted backup process and the decryption and recovery process; The encrypted backup process includes the following steps: Multiple cryptographic devices generate asymmetric key pairs and symmetric keys respectively, and use the public key in the asymmetric key pair to encrypt the corresponding symmetric key to obtain multiple encrypted symmetric keys; The core data protection key is obtained by performing a bitwise XOR operation on multiple symmetric keys generated by multiple cryptographic devices. The core data is encrypted using the core data protection key to obtain the core data ciphertext; The core data ciphertext, the public keys of multiple cryptographic devices, and multiple symmetric encryption keys are assembled and backed up to form a backup file; The decryption and recovery process includes the following steps: Parse the backup file to obtain the core data ciphertext, multiple public keys, and multiple encrypted symmetric keys; Multiple cryptographic devices are matched with the multiple public keys respectively. The cryptographic devices that are successfully matched use their own private keys to decrypt the corresponding encrypted symmetric keys to obtain multiple symmetric keys. Perform a bitwise XOR operation on the multiple decrypted symmetric keys to restore the core data protection key; The core data ciphertext is decrypted using the restored core data protection key to obtain the core data plaintext.

2. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 1, characterized in that, The plurality of cryptographic devices respectively generate asymmetric key pairs and symmetric keys, including: The cryptographic device internally generates an asymmetric encryption key pair and derives the public key; Cryptographic devices use an internal random number generator to generate a symmetric key; Cryptographic devices use their own public key to encrypt their own symmetric key.

3. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 1, characterized in that, The process of assembling and backing up the core data ciphertext, the public keys of multiple cryptographic devices, and multiple symmetric encryption keys to form a backup file includes: The core data ciphertext, along with the public key generated by each cryptographic device and the symmetric key ciphertext encrypted with that public key, are stored together to form a structured backup file.

4. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 1, characterized in that, The process involves matching multiple cryptographic devices with the multiple public keys, and each successfully matched cryptographic device using its private key to decrypt the corresponding symmetric key, resulting in multiple symmetric keys, including: Read the public key inside a cryptographic device; Search among the multiple public keys contained in the backup file for the public key that matches the one read. If the same public key is found, the encrypted symmetric key associated with the public key is retrieved from the backup file; The cryptographic device uses its own stored private key, which corresponds to the public key, to decrypt the acquired symmetric encryption key.

5. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 1, characterized in that, The bitwise XOR operation is represented as: FinalSecretKey = SecretKey1 ^ SecretKey2 ^ … ^ SecretKeyN, where SecretKey1 to SecretKeyN are symmetric keys generated or decrypted by multiple cryptographic devices respectively, N is the total number of cryptographic devices, and FinalSecretKey is the core data protection key.

6. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 1, characterized in that, The core data is encrypted using a core data protection key, and the core data ciphertext is decrypted using a symmetric encryption algorithm.

7. The method for collaborative encryption protection based on multiple cryptographic devices according to claim 4, characterized in that, During the decryption and recovery process, if the internal public key read by a cryptographic device fails to be found among the multiple public keys contained in the backup file, it is determined that the cryptographic device does not have decryption and recovery authority, and the decryption process is terminated.

8. The method for collaborative encryption protection based on multiple cryptographic devices according to any one of claims 1 to 7, characterized in that, The order in which multiple cryptographic devices are operated is unrestricted during the encryption backup and decryption recovery processes.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-8.

Images