Historical root key preservation and batch re-encryption methods, apparatuses, and devices

Abstract

The application discloses a history root key reservation and batch re-encryption method, device and equipment, and belongs to the technical field of data security. It comprises reading and analyzing a root certificate to obtain a new root key corresponding to a current use root key index of the root certificate; determining whether a plurality of pre-stored root key indexes in a database are consistent with the current use root key index; screening all root key inconsistent data keys from the database; locating all root key inconsistent data keys corresponding to respective old root keys, and decrypting the corresponding root key inconsistent data keys by using the old root keys; and batch re-encrypting all root key inconsistent data keys by using the new root key. The technical scheme of the application reserves the history root key in the root certificate and automatically completes the batch re-encryption migration of the data key, without manual intervention, effectively shortens the migration period, avoids the expansion of the service window, ensures the consistency of the root key indexes among the distributed nodes, and prevents decryption failure.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a method, apparatus and device for preserving historical root keys and batch re-encryption. Background Technology

[0002] In scenarios such as cloud platforms, IoT, and smart hardware, cryptographic machine services typically employ a two-layer key architecture: a root key is used to encrypt stored business data keys, and data keys are used to encrypt actual business data. The root key, as the root point of trust, needs to be rotated periodically to meet security compliance requirements. However, root key rotation can lead to the new root key being unable to decrypt historical data key ciphertext encrypted by the old root key, thus posing a risk of business decryption chain interruption. Typically, decryption capability can only be restored by migrating the historical data keys.

[0003] After root key rotation, existing technologies typically employ offline batch processing scripts or manual re-encryption of each database and table to complete data key migration. Specifically, this involves locating the ciphertext of historical data keys to be migrated based on the business database structure and key pool metadata, decrypting it using the old root key, re-encrypting it with the new root key, and updating the database. In distributed cryptographic machine cluster scenarios, manual intervention or reliance on maintenance processes is also required to ensure consistency between the root key version and index on each node to avoid decryption failures due to inconsistent migration statuses between nodes. However, this approach has the following problems: First, the long migration cycle passively expands the downtime window, requiring significant maintenance time for script writing, troubleshooting, and batch execution; second, in multi-database, multi-table scenarios, data keys are easily overlooked, resulting in a semi-migration state of "partially decryptable, partially decryptable"; third, inconsistent root key indexes across multiple nodes can easily lead to business decryption failures. Summary of the Invention

[0004] Existing technologies suffer from problems such as long processing time, missing data keys, and decryption failures due to inconsistent root key indexes. To address these issues, this application provides a method, apparatus, and device for preserving historical root keys and performing batch re-encryption.

[0005] To achieve the above objectives, the first technical solution adopted in this application is: a method for preserving historical root keys and batch re-encrypting, comprising: reading and parsing a root certificate to obtain a new root key corresponding to the currently used root key index of the root certificate, wherein the root certificate has an old root key array consisting of one or more old root keys; determining whether multiple pre-stored root key indices in the database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index; if at least one of the multiple pre-stored root key indices is inconsistent with the currently used root key index, filtering out all inconsistent root key data keys from the database, wherein the inconsistent root key data keys are the data keys corresponding to the pre-stored root key indexes in the database that are inconsistent with the currently used root key index; locating each old root key corresponding to all inconsistent root key data keys from the old root key array according to the pre-stored root key indexes corresponding to all inconsistent root key data keys, and decrypting the corresponding inconsistent root key data keys using the old root key; and batch re-encrypting all the decrypted inconsistent root key data keys using the new root key to obtain the corresponding new data key.

[0006] The second technical solution adopted in this application is: a historical root key retention and batch re-encryption device, comprising: a root certificate reading module, which reads and parses the root certificate to obtain the new root key corresponding to the currently used root key index of the root certificate, wherein the root certificate has an old root key array consisting of one or more old root keys; an index consistency determination module, which determines whether multiple pre-stored root key indices in the database that correspond one-to-one with multiple data keys are consistent with the currently used root key index; a data key filtering module, which, when it is determined that at least one of the multiple pre-stored root key indices is inconsistent with the currently used root key index, filters out all inconsistent root key data keys from the database, wherein the inconsistent root key data keys are the data keys corresponding to the pre-stored root key indexes in the database that are inconsistent with the currently used root key index; a decryption module, which, based on the pre-stored root key indices corresponding to all inconsistent root key data keys, locates each old root key corresponding to all inconsistent root key data keys from the old root key array, and decrypts the corresponding inconsistent root key data keys using the old root key; and a re-encryption module, which uses the new root key to batch re-encrypt all the decrypted inconsistent root key data keys to obtain the corresponding new data keys.

[0007] The third technical solution adopted in this application is: a computer device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the historical root key retention and batch re-encryption method in Solution 1.

[0008] The beneficial effects of the technical solution presented in this application are as follows: When applied, this solution retains all historical root keys in the root certificate. During rotation, only the new key is appended and the index of the currently used root key is updated, ensuring that old keys can always be loaded. After service startup, the system automatically reads the root certificate, compares the index of each data key in the database with the index of the currently used root key, and if they do not match, automatically filters, locates the old key, and completes decryption, re-encryption, and batch updates. The entire process requires no manual script writing or database-by-database and table-by-table operations, effectively shortening the migration cycle, avoiding extended downtime, and reducing operational burden. Furthermore, since all nodes start based on the same root certificate and have consistent root key indexes, decryption failures caused by inconsistent states between nodes in a distributed scenario are avoided. Attached Figure Description

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

[0010] Figure 1 This is a flowchart illustrating a specific implementation example of a historical root key preservation and batch re-encryption method according to this application; Figure 2 This is a schematic diagram of the root key rotation and migration in a historical root key preservation and batch re-encryption method of this application; Figure 3 This is a flowchart of the migration execution of a historical root key preservation and batch re-encryption method according to this application; Figure 4 This is a timing diagram of the multi-node collaborative migration state verification of a historical root key preservation and batch re-encryption method according to this application; Figure 5 This is the overall flowchart of the root key rotation and migration of the historical root key preservation and batch re-encryption method of this application; Figure 6 This is a flowchart of the old root key dual-path matching in the historical root key preservation and batch re-encryption method of this application; Figure 7 This is an architecture diagram of a historical root key preservation and batch re-encryption system according to this application; Figure 8 This is a schematic diagram of a specific embodiment of a historical root key retention and batch re-encryption device according to this application.

[0011] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concepts of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0012] The preferred embodiments of this application will now be described in detail with reference to the accompanying drawings, so that the advantages and features of this application can be more easily understood by those skilled in the art, thereby providing a clearer and more definite definition of the scope of protection of this application.

[0013] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0014] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. The specific embodiments described below can be combined with each other to form new embodiments. The same or similar ideas or processes described in one embodiment may not be repeated in other embodiments.

[0015] Figure 1 This paper illustrates a specific implementation of a historical root key preservation and batch re-encryption method according to this application.

[0016] In this specific implementation, the historical root key retention and batch re-encryption method includes: Step S101, reading and parsing the root certificate to obtain the new root key corresponding to the currently used root key index of the root certificate, wherein the root certificate has an old root key array consisting of one or more old root keys. The root certificate can be used to store a historical collection of multiple versions of root keys. The root certificate may include an old root key array and the new root key corresponding to the currently used root key index. The root key can be used to encrypt and store business data keys. The new root key can be the most recently stored key in the root certificate. The currently used root key index can be used to identify which root key in the root key array should be used in the root certificate to encrypt newly generated data keys.

[0017] In one specific embodiment of this implementation, each service node reads and parses the new root key corresponding to the currently used root key index in the root certificate through the root key resolver.

[0018] In one specific embodiment of this specific implementation, such as Figure 5 As shown, the current root key index of the root certificate can be updated through the following steps: In this specific embodiment, a new root key is generated and added to the root key array in the root certificate. Specifically, the new root key is generated by the operating platform or administrator and appended to the root key array of the root certificate.

[0019] In this specific embodiment, the index of the currently used root key in the root certificate is updated to the index of the new root key. Specifically, the index of the currently used root key is updated to the index position of the new root key in the root key array.

[0020] In one specific embodiment of this implementation, the root certificate can be distributed and verified through the following steps: In this specific embodiment, the root certificate is distributed to a designated directory on each service node.

[0021] In this specific embodiment, the integrity of the distributed root certificate is verified. Specifically, the updated root certificate is distributed to the designated directory of each node and verified, for example, by MD5 (Message Digest Algorithm 5) or SHA256 (Secure Hash Algorithm 256-bit).

[0022] Therefore, all historical root keys are retained in the root certificate root key array, and rotation only adds new root keys and updates the index of the currently used root key, thus ensuring that the old keys required for migration and decryption can be loaded by the service.

[0023] In this specific implementation, the historical root key retention and batch re-encryption method includes: step S102, determining whether multiple pre-stored root key indices in the database, each corresponding one-to-one with multiple data keys, are consistent with the currently used root key index. The database may include actual business data encrypted with the data keys, data keys encrypted with the root keys, and pre-stored root key indices corresponding one-to-one with the data keys. The data keys can be used to encrypt actual business data. The pre-stored root key index corresponding to a data key can be a unique identifier of the root key used when encrypting that data key.

[0024] In one specific embodiment of this specific implementation, such as Figure 3As shown, determine whether the multiple pre-stored root key indices in the encryption database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index, including: In this specific embodiment, a distributed lock is acquired. A distributed lock is a mechanism in a distributed system that coordinates mutual exclusion access to shared resources by multiple nodes or servers.

[0025] In this specific embodiment, upon successfully acquiring the distributed lock, it is determined whether each root key index corresponding to each data key in the database is consistent with the currently used root key index. This can be understood as follows: Figure 4 As shown, in a distributed multi-node scenario, multiple nodes or servers simultaneously acquire a distributed lock. Only the server that successfully acquires the distributed lock can query the database to determine if the key numbers of all data keys have been updated to the current number. Other nodes that fail to acquire the distributed lock wait and retry. When any node successfully acquires the distributed lock, other nodes, when querying the migration status, if the migration status is still "migrifying," continue to wait and retry, thus avoiding the incorrect judgment that the index has been updated before the master node's transaction is committed. If the migration status is "migration complete," the root key index can be queried and consistency confirmed, and then the root key can be directly loaded, skipping the migration.

[0026] Therefore, in a distributed multi-node scenario, the distributed lock and migration status identifier work together to avoid misjudgment between nodes, thus achieving a balance between concurrency control, status verification and single-node migration execution.

[0027] In this specific embodiment, the historical root key retention and batch re-encryption method includes: step S103, where, if at least one of the multiple pre-stored root key indices is inconsistent with the currently used root key index, all inconsistent root key data keys are filtered out from the database. The inconsistent root key data keys can be data keys corresponding to pre-stored root key indices in the database that are inconsistent with the currently used root key index.

[0028] In one specific embodiment of this specific implementation, such as Figure 2 As shown, if at least one of the multiple pre-stored root key indexes is inconsistent with the currently used root key index, all inconsistent data keys are filtered out from the database, including: In this specific embodiment, if at least one of the multiple pre-stored root key indexes is determined to be inconsistent with the currently used root key index, the migration status in the database is set to "migration in progress," and the distributed lock period is renewed. Specifically, when the master node discovers that there are old data keys in the database that need to be migrated, it sets the migration status to "migration in progress," performs data key re-encryption migration, and periodically renews the lock during the execution process to ensure that the lock does not expire during the migration.

[0029] In this specific embodiment, data keys whose root key index is inconsistent with the currently used root key index are filtered out from the database.

[0030] In this specific implementation, the historical root key retention and batch re-encryption method includes: Step S104, based on the pre-stored root key index corresponding to all inconsistent root key data keys, locating each old root key corresponding to all inconsistent root key data keys from the old root key array, and using the old root key to decrypt the corresponding inconsistent root key data key. Specifically, after completing the old root key location, the corresponding old root key matched for each data key is used to perform a decryption operation on the ciphertext of the data key. During the decryption process, when performing decryption on the ciphertext of the data key using the corresponding old root key matched for each data key, if decryption fails, a limited number of retries are performed, for example, 3 retries. If decryption still fails after retries... In one specific embodiment of this specific implementation, such as Figure 6 As shown, based on the pre-stored root key indices corresponding to all inconsistent root key data keys, the old root keys corresponding to all inconsistent root key data keys are located from the old root key array, including: In this specific embodiment, the old root key array in the root certificate is parsed. Specifically, the old root key array in the root certificate can be parsed using a root key parser.

[0031] In this specific embodiment, the arrays of new and old root keys are sorted according to the creation time of each old root key and the creation time of each new root key. Specifically, the arrays of new and old root keys are sorted in the order of their creation times, with earlier creation times listed first and later creation times listed last.

[0032] In this specific embodiment, the key index of the old root key preceding the new root key is matched with the pre-stored root key index corresponding to each data key. This can be understood as matching the key index number of the previous old root key with the root key index corresponding to each data key. This is because, typically, after one rotation, the number of the old data key should be the same as the number of the previous root key. Matching with the previous bit of the new root key is the fastest and most direct method of location, and in most cases, it will be successful on the first try.

[0033] In this specific embodiment, if a match is successful, the old root key with the bit preceding the new root key is used as the old root key corresponding to each data key.

[0034] In one specific embodiment of this implementation, based on the pre-stored root key index corresponding to all inconsistent root key data keys, the old root keys corresponding to all inconsistent root key data keys are located from the old root key array, including: In this specific embodiment, if a match fails, the old root key array is traversed in descending order, starting from the old root key one position above the new root key. The key index of each old root key in the old root key array is then matched against the pre-stored root key index corresponding to each data key. This can be understood as follows: if a match fails, it indicates that multiple iterations may have occurred, or there may be special circumstances. In this case, a second path, i.e., descending traversal, is used as a fallback.

[0035] In this specific embodiment, if an old root key is matched, the matched old root key is used as the old root key corresponding to each data key.

[0036] In this specific embodiment, if the old root key is not matched, an error is logged and an alarm is triggered.

[0037] Specifically, when the first path match fails, it indicates that the current data key was not encrypted by the previous root key preceding the new root key. In this case, the system uses the second path as a fallback: starting from the previous root key preceding the new root key, the entire array of old root keys is traversed in descending order of key index number. The key index number of each encountered old root key is compared with the root key index recorded for the current data key. If a match is found, the matched old root key is used for decryption. If no old root key is found after traversing the entire array, an error is recorded and an alarm is triggered, preventing service startup. This step, as a fallback to the first path, improves the robustness of old root key location.

[0038] Furthermore, by maintaining the mapping relationship between the key index of the old root key and the pre-stored root key index of the database data key, the old root key can be manually specified and the migration can be triggered before the service starts, thereby reducing the automatic location capability but still requiring manual intervention.

[0039] Therefore, the dual-path location mechanism and migration integrity verification work together to ensure that the service will not enter an inconsistent state based on an incorrect key. Furthermore, if the old index remnant verification fails or the old root key location fails, service startup is refused, preventing the system from entering an uncontrollable state and improving migration reliability and security.

[0040] In this specific implementation, the historical root key retention and batch re-encryption method includes: Step S105, using the new root key, batch re-encrypting all decrypted root key inconsistent data keys to obtain the corresponding new data keys. Specifically, after completing the decryption operation of all data keys to be migrated and obtaining the plaintext data keys, the new root key corresponding to the currently used root key index is used to re-encrypt these plaintext data keys one by one to generate new data key ciphertext.

[0041] Therefore, by automatically performing historical data key migration, batch re-encryption, and integrity verification during the service startup phase, the manual script writing, database-by-database investigation, and batch migration operations are significantly reduced, thereby reducing the manpower required for operation and maintenance. Furthermore, by using batch re-encryption migration and supporting batch migration strategies, the scale of a single batch migration can be controlled to reduce database pressure and shorten the downtime window, keeping the migration downtime within an acceptable range.

[0042] In one specific embodiment of this implementation, after using the new root key to batch re-encrypt all decrypted data keys with inconsistent root keys to obtain the corresponding new data keys, the method further includes: In this specific embodiment, the database is updated based on the new data keys obtained after re-encryption. Specifically, the ciphertext of the new data keys obtained after batch re-encryption is written back to the corresponding record position in the database, replacing the original old ciphertext, and the pre-stored root key index of each data key is updated to the currently used root key index simultaneously, thereby completing the physical update of the data keys in the database.

[0043] In this specific embodiment, a consistency check is performed again on each data key in the updated database based on the currently used root key index. Specifically, the pre-stored root key index of all data keys in the database is rechecked to ensure that there are no residual data keys from the old index due to anomalies in the update process.

[0044] In this specific embodiment, if the consistency check passes, the migration status in the database is set to migration complete. At this point, other servers can query the pre-stored stub key index in the database and confirm consistency.

[0045] In this specific embodiment, encryption / decryption operations are performed by loading each data key from the updated database. The server loads the current root key into memory and, based on the data keys in the database that have all been updated to be protected by the new root key, normally provides data encryption and decryption services. At this point, all data keys can be correctly decrypted by the current root key, and the service enters a stable operating state.

[0046] If the consistency check fails, the migration status will not be set to migration complete; instead, the service will be refused to start and will await manual intervention.

[0047] Therefore, when the old index residue verification fails or the old root key location fails, the present invention denies service startup, avoiding the system from entering an uncontrollable state and improving migration reliability and security.

[0048] Furthermore, in offline mode, after rotation, the operation and maintenance personnel or the offline system can write scripts to migrate the data key ciphertext database by database, table by table, and key pool by key pool, and perform manual or semi-automatic verification of the migration results.

[0049] like Figure 7 As shown, the implementing entity of this application is a historical root key retention and batch re-encryption system. This system consists of a root certificate layer, a cryptographic machine service layer, and a storage layer, and the migration is completed collaboratively by a parser, a manager, and a key pool manager. The root certificate file stores a historical collection of multiple versions of the root key. The root key parser is responsible for parsing the root certificate, decrypting the root key information, and performing signature verification. The root key manager is responsible for loading the root key, performing encryption and decryption, and coordinating the migration process. The key pool manager manages the data keys and key pool metadata. The storage layer includes a database and a distributed lock component. The database can store metadata such as the data key ciphertext, root key index, and migration status. The distributed lock component can be used for single-node migration control in distributed scenarios. In this architecture, root key parsing and verification are interdependent with migration execution, ensuring that the key loading and data processing required for historical data key migration can be completed during the service startup phase.

[0050] The beneficial effects of the technical solution presented in this application are as follows: When applied, this solution retains all historical root keys in the root certificate. During rotation, only the new key is appended and the index of the currently used root key is updated, ensuring that old keys can always be loaded. After service startup, the system automatically reads the root certificate, compares the index of each data key in the database with the index of the currently used root key, and if they do not match, automatically filters, locates the old key, and completes decryption, re-encryption, and batch updates. The entire process requires no manual script writing or database-by-database and table-by-table operations, effectively shortening the migration cycle, avoiding extended downtime, and reducing operational burden. Furthermore, since all nodes start based on the same root certificate and have consistent root key indexes, decryption failures caused by inconsistent states between nodes in a distributed scenario are avoided.

[0051] Figure 8 This is a schematic diagram of a specific embodiment of a historical root key retention and batch re-encryption device according to this application.

[0052] exist Figure 8In the specific embodiment shown, the historical root key retention and batch re-encryption device includes: a root certificate reading module 801, which reads and parses the root certificate to obtain the new root key corresponding to the currently used root key index of the root certificate, wherein the root certificate has an old root key array consisting of one or more old root keys; an index consistency determination module 802, which determines whether multiple pre-stored root key indices in the database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index; and a data key filtering module 803, which, if it determines that at least one of the multiple pre-stored root key indices is inconsistent with the currently used root key index, selects a new root key from the database. All inconsistent root key data keys are filtered out, where inconsistent root key data keys are data keys corresponding to pre-stored root key indices in the database that are inconsistent with the currently used root key index; the decryption module 804 locates each old root key corresponding to all inconsistent root key data keys from the old root key array according to the pre-stored root key indexes corresponding to all inconsistent root key data keys, and uses the old root key to decrypt the corresponding inconsistent root key data keys; the re-encryption module 805 uses the new root key to batch re-encrypt all decrypted inconsistent root key data keys to obtain the corresponding new data keys.

[0053] The historical root key retention and batch re-encryption apparatus provided in this application can be used to execute the historical root key retention and batch re-encryption method described in any of the above embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.

[0054] In another specific embodiment of this application, a computer device includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the historical root key retention and batch re-encryption method described in any of the above embodiments.

[0055] In the several embodiments provided in this application, 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 instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0056] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0057] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for preserving historical root keys and performing batch re-encryption, characterized in that, include: Read and parse the root certificate to obtain the new root key corresponding to the root key index currently used by the root certificate, wherein the root certificate has an array of old root keys consisting of one or more old root keys; Determine whether the multiple pre-stored root key indexes in the database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index; If it is determined that at least one of the plurality of pre-stored root key indexes is inconsistent with the currently used root key index, all inconsistent root key data keys are filtered out from the database, wherein the inconsistent root key data keys are the data keys in the database corresponding to the pre-stored root key indexes that are inconsistent with the currently used root key index. Based on the pre-stored root key index corresponding to all inconsistent root key data keys, locate each old root key corresponding to all inconsistent root key data keys from the old root key array, and use the old root key to decrypt the corresponding inconsistent root key data key. Using the new root key, all the decrypted data keys that do not match the root key are batch re-encrypted to obtain the corresponding new data keys.

2. The method according to claim 1, characterized in that, The step of determining whether the multiple pre-stored root key indices in the encrypted database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index includes: Acquire a distributed lock; If the distributed lock is successfully acquired, determine whether each root key index corresponding to each data key in the database is consistent with the currently used root key index.

3. The method according to claim 2, characterized in that, If at least one of the plurality of pre-stored root key indexes is inconsistent with the currently used root key index, all inconsistent root key data keys are filtered out from the database, including: If it is determined that at least one of the plurality of pre-stored root key indexes is inconsistent with the currently used root key index, the currently used root key index is set to migration in the database, and the distributed locking period is extended. Filter out all data keys with inconsistent root keys from the database. The current root key index is used.

4. The method according to claim 3, characterized in that, The step of locating each old root key corresponding to all inconsistent data keys from the old root key array based on the pre-stored root key index corresponding to all inconsistent data keys includes: Parse the old root key array in the root certificate; Sort the array of new root keys and the array of old root keys according to the creation time of each old root key and the creation time of the new root key; Match the key index of the old root key one bit above the new root key with the pre-stored root key index corresponding to each of the data keys. If a match is successful, the old root key corresponding to the previous bit of the new root key is used as the old root key for each data key.

5. The method according to claim 4, characterized in that, The step of locating each old root key corresponding to all inconsistent data keys from the old root key array based on the pre-stored root key index corresponding to all inconsistent data keys includes: If the match fails, start from the old root key one bit above the new root key and traverse the old root key array in descending order, and match the key index of each old root key in the old root key array with the pre-stored root key index corresponding to each data key in turn. If an old root key is matched, the matched old root key shall be used as the old root key corresponding to each data key. If the old root key is not matched, log the error and issue an alert.

6. The method according to claim 3, characterized in that, After using the new root key to batch re-encrypt all the decrypted data keys with inconsistent root keys to obtain the corresponding new data keys, the method further includes: The database is updated based on the newly re-encrypted data keys; Based on the currently used root key index, perform a consistency check again on each data key in the updated database; If the consistency check passes, the migration status in the database is set to migration complete. Encryption / decryption operations are performed by loading each data key from the updated database.

7. The method according to claim 1, characterized in that, The current root key index of the root certificate is updated through the following steps: Generate a new root key and add the root key to the root key array in the root certificate; Update the current root key index of the root certificate to the index of the new root key.

8. The method according to claim 7, characterized in that, The root certificate is distributed and verified through the following steps: The root certificate is distributed to the designated directory of each service node; Perform an integrity check on the distributed root certificate.

9. A device for preserving historical root keys and performing batch re-encryption, characterized in that, include: The root certificate reading module reads and parses the root certificate to obtain the new root key corresponding to the current root key index of the root certificate, wherein the root certificate has an old root key array consisting of one or more old root keys; The index consistency determination module determines whether the multiple pre-stored root key indexes in the database, which correspond one-to-one with multiple data keys, are consistent with the currently used root key index. The data key filtering module, when determining that at least one of the plurality of pre-stored root key indices is inconsistent with the currently used root key index, filters out all root key inconsistencies from the database, wherein the root key inconsistencies are data keys in the database corresponding to the pre-stored root key indexes that are inconsistent with the currently used root key index. The decryption module locates each old root key corresponding to all inconsistent root key data keys from the old root key array based on the pre-stored root key index corresponding to all inconsistent root key data keys, and uses the old root key to decrypt the corresponding inconsistent root key data key. The re-encryption module uses the new root key to batch re-encrypt all the decrypted data keys that do not match the root key, and obtains the corresponding new data keys.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the historical root key retention and batch re-encryption method as described in any one of claims 1-8.

Images