A cloud host encryption credential field-level repair method and system

Abstract

The application provides a cloud host encryption credential field level repair method and system, the method comprises the following steps: creating an independent field level MPT side chain for each encryption credential field, and storing the data to a distributed key value storage system; synchronizing all side chain root hashes to a lightweight consensus protocol cluster main chain, and the main chain multiplexes the consensus resources of the side chain; positioning a healthy copy through a target field side chain, reading the ciphertext data to replace the local damaged data and completing the repair, the application realizes field level isolated storage and rapid repair, does not need to add new hardware and independent blockchain nodes, reduces resource overhead, adheres to the encryption security boundary, and guarantees the consistency of the cluster data and the availability of the credentials.

Description

Technical Field

[0001] This application belongs to the field of cloud host security and data preservation and repair technology, and in particular relates to a method and system for repairing cloud host encrypted credentials at the field level. Background Technology

[0002] During the operation of a cloud server cluster, out-of-band management credentials of physical nodes need to be stored with independent encryption at the field level to ensure data security. The ciphertext of related credentials is often stored in a distributed storage system with multiple copies. Existing distributed storage solutions do not have a dedicated repair mechanism for single-field ciphertext corruption. After ciphertext corruption, it is necessary to traverse the entire credential data to complete the repair. The repair process will touch other encrypted field data, which will destroy the security boundary of field-level independent encryption. At the same time, traditional blockchain evidence storage solutions require independent deployment of nodes and maintenance of a complete block structure, which consumes a lot of storage and computing resources and cannot adapt to the lightweight operation requirements of cloud server clusters. The cluster cannot complete the rapid repair of single-field ciphertext and ensure the consistency of data across the entire cluster while adhering to field-level encryption isolation, thus affecting the fault isolation execution stability of the cloud server high-availability system. Summary of the Invention

[0003] This application provides a cloud host encryption credential field-level repair method and system. While adhering to the independent encryption security boundary of the cloud host encryption credential field level, it reuses the existing storage and consensus resources of the cluster to achieve targeted and rapid repair of single-field ciphertext corruption and ensure data consistency across the entire cluster.

[0004] This application discloses a method for repairing cloud host encryption credentials at the field level, including: Create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster, and store the field-level MPT sidechain data in a distributed key-value storage system. The field-level MPT sidechain is used to store the ciphertext hash, version information and replica node information of the corresponding encrypted credential field. The distributed key-value storage system is a cluster storage component that uses a consistency protocol to implement multi-replica data storage. The root hash of all field-level MPT sidechains is synchronized to the consensus protocol cluster main chain. The consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data. Based on the field-level MPT sidechain of the target field, locate the healthy replica node, read the ciphertext data of the healthy replica node and replace the local damaged ciphertext data to complete the repair of the encrypted credential field.

[0005] Optionally, create a separate field-level MPT sidechain for each cryptographic credential field in the cloud host cluster, including: Obtain the field partitioning results of the encrypted credentials in the cloud host cluster; Generate a unique field identifier for each independent encrypted credential field based on the field segmentation results; Construct a field-level MPT sidechain based on a unique field identifier to store only single-field evidence data; The field partitioning result is the result of splitting the encrypted certificate into independent data units according to the certificate data type.

[0006] Optionally, a field-level MPT sidechain for storing only single-field evidence data can be constructed based on a unique field identifier, including: The unique field identifier and version number are used as the index key for the field-level MPT sidechain; The encrypted hash, replica node information, and update timestamp are combined as the index value of the field-level MPT sidechain; A field-level MPT sidechain with no block header and transaction pool structure is constructed based on index keys and index values; Update the timestamp to the time record data written to the distributed key-value storage system from the field-level MPT sidechain data.

[0007] Optionally, the field-level MPT sidechain data can be stored in a distributed key-value store system, including: Map the index keys and index values ​​of the field-level MPT sidechain to key-value pairs in a distributed key-value storage system; Write the mapped key-value pairs to the specified storage path in the distributed key-value storage system; A consistency protocol is used to synchronize key-value pairs to multiple storage nodes in a distributed key-value storage system. The specified storage path is a dedicated storage area for credential storage within a distributed key-value storage system.

[0008] Optionally, synchronize the root hashes of all field-level MPT sidechains to the consensus protocol cluster main chain, including: Calculate the current root hash of each field-level MPT sidechain; Add the current root hash to the hash anchor set of the consensus protocol cluster main chain; The hash anchor set is synchronized to all control nodes in the cluster through a consensus protocol; The hash anchor set is an ordered data set that stores the root hashes of all field-level MPT sidechains in the main chain of the consensus protocol cluster.

[0009] Optionally, healthy replica nodes can be located based on the field-level MPT sidechain of the target field, including: Extract the unique field identifier corresponding to the target field; The corresponding field-level MPT sidechain is invoked from the distributed key-value storage system based on a unique field identifier; Parse replica node information and node health status from the field-level MPT sidechain; Node health status is identifier data that characterizes the operating status and data availability of storage nodes.

[0010] Optionally, read the ciphertext data from the healthy replica node and replace the locally corrupted ciphertext data, including: Healthy replica nodes are selected from the replica node information based on their health status. Add a field-level distributed lock to the target field; Encrypted ciphertext data of the target field is read from a healthy replica node based on a remote data access protocol; A field-level distributed lock is a mutually exclusive access control identifier that applies only to a single encrypted credential field.

[0011] Optionally, reading the ciphertext data from the healthy replica node and replacing the locally corrupted ciphertext data also includes: The corrupted ciphertext data is overwritten with encrypted ciphertext data; Remove the field-level distributed lock from the target field; Calculate the real-time hash value of the local encrypted data after overwriting.

[0012] Optionally, after calculating the real-time hash value of the overwritten local ciphertext data, the following steps are also included: The real-time hash value is compared with the ciphertext hash stored in the field-level MPT sidechain; If the comparison matches, the update timestamp of the field-level MPT sidechain is updated, the root hash of the field-level MPT sidechain is recalculated and synchronized to the consensus protocol cluster main chain; If the comparison is inconsistent, the encrypted data reading operation of the healthy replica node will be re-executed.

[0013] This application also discloses a cloud host encrypted credential field-level repair system, including: a sidechain creation unit, a data storage unit, a main chain synchronization unit, and a repair execution unit; The sidechain creation unit is used to create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster; The data storage unit is used to store field-level MPT sidechain data to a distributed key-value storage system; The main chain synchronization unit is used to synchronize the root hash of all field-level MPT sidechains to the consensus protocol cluster main chain; The repair execution unit is used to locate healthy replica nodes based on the field-level MPT sidechain of the target field, read the ciphertext data of the healthy replica node and replace the local corrupted ciphertext data; The distributed key-value storage system is a cluster storage component that uses a consensus protocol to achieve multi-replica data storage, and the consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data.

[0014] As can be seen from the above technical solution, this application provides a cloud host encrypted certificate field-level repair method and system. By creating an independent field-level MPT sidechain for each encrypted certificate field, the single-field notarization and repair operations only operate within their own data scope and do not touch other field data, thus adhering to the security boundary of independent field-level encryption. The field-level MPT sidechain data is directly mapped and stored to the existing distributed key-value storage system, eliminating the need for independent deployment of blockchain nodes and reducing the additional occupation of storage and computing resources. The root hash of all field-level MPT sidechains is synchronized to the lightweight consensus protocol cluster main chain. The sidechain and the main chain reuse the same set of consensus processing resources, avoiding resource redundancy caused by independent consensus of multiple chains. The operations of locating healthy copies and ciphertext replacement are all performed based on the field-level MPT sidechain data of the target field, without traversing the entire certificate data. The input and output of the repair process are all closed loops around the target field. The various technical features are sequentially connected, enabling the cluster to complete the rapid repair of single-field ciphertext without breaking encryption isolation or increasing resource overhead during operation, while ensuring the consistency of data across the entire cluster. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating a cloud host encryption credential field-level repair method in an embodiment of this application; Figure 2 This is a schematic diagram of the process for creating an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster in this embodiment of the application; Figure 3 This is a flowchart illustrating the process of constructing a field-level MPT sidechain that stores only single-field evidence data based on a unique field identifier in an embodiment of this application. Figure 4 This is a schematic diagram of the process of storing field-level MPT sidechain data to a distributed key-value storage system in an embodiment of this application; Figure 5 This is a schematic diagram of the process of synchronizing the root hash of all field-level MPT sidechains to the consensus protocol cluster main chain in the embodiments of this application; Figure 6 This is a schematic diagram of the process for locating healthy replica nodes based on the field-level MPT sidechain of the target field in the embodiments of this application; Figure 7 This is one of the flowcharts illustrating the process of reading encrypted data from a healthy replica node and replacing locally corrupted encrypted data in this application embodiment; Figure 8 This is the second schematic diagram of the process of reading the encrypted data of the healthy replica node and replacing the locally corrupted encrypted data in the embodiments of this application; Figure 9 This is a flowchart illustrating the process after calculating the real-time hash value of the overwritten local encrypted data in an embodiment of this application. Figure 10 This is a schematic diagram of the structure of a cloud host encryption credential field-level repair system in an embodiment of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] Cloud server clusters are the core operating environment for ensuring business continuity in cloud computing data centers. When physical nodes experience hardware failures or system anomalies, the cluster needs to isolate the failed nodes through out-of-band management interfaces. Secure storage and reliable retrieval of out-of-band management credentials are fundamental to the isolation operation. Taking a cloud server cluster in a cloud computing data center as an example, the cluster deploys 500 physical computing nodes. Each node's out-of-band management credential is split into four independent encrypted fields: address, port, username, and password. The ciphertext is stored in a three-copy manner in the distributed storage components of three control nodes. Traditional methods do not set up independent storage structures for each encrypted field, requiring ciphertext integrity verification. When reading full credential data, if the ciphertext of a single password field on a single control node is damaged due to storage media failure, the system needs to traverse the full credential data of all nodes to locate a healthy copy. The verification process will read the ciphertext data of other encrypted fields such as address and port, breaking through the security boundary of independent encryption at the field level. At the same time, traditional blockchain notarization solutions require the separate deployment of blockchain nodes for credential notarization, maintaining redundant structures such as block headers and transaction pools, which consumes the cluster's computing and storage resources, resulting in reduced response efficiency for cluster fault isolation. Furthermore, after ciphertext repair, it is not possible to quickly complete the data consistency synchronization of the entire cluster, which can easily lead to inconsistent credential data on different nodes, affecting the execution effect of fault isolation operations.

[0019] It should be noted that the technical solution provided in this application optimizes the above-mentioned defects of the prior art. It solves the core contradiction between the storage and repair of encrypted credentials by combining field-level independent evidence storage, lightweight storage, consensus resource reuse and targeted repair. The specific implementation process will be described in detail below with reference to the technical solution defined in the claims.

[0020] For example, the first aspect of this application proposes a method for repairing cloud host encryption credential fields, such as... Figure 1 As shown, the method includes: S100: Create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster, and store the field-level MPT sidechain data in the distributed key-value storage system. In this step, the field-level MPT sidechain is used to store the ciphertext hash, version information and replica node information of the corresponding encrypted credential field. The distributed key-value storage system is a cluster storage component that uses a consistency protocol to implement multi-replica data storage.

[0021] This component is a basic storage facility already deployed in the cloud host cluster, requiring no additional hardware. The field-level MPT sidechain is constructed using a Merkel-Patricia tree structure, storing only single-field notarization-related data, without containing redundant structures of the blockchain system, and is compatible with the key-value pair storage mode of distributed key-value storage systems.

[0022] S200: The root hash of all field-level MPT sidechains is synchronized to the consensus protocol cluster main chain. The consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data. The consensus protocol cluster main chain reuses the consensus processing resources of the field-level MPT sidechains.

[0023] This structure removes redundant modules such as block generation and transaction verification from traditional blockchains, and is only responsible for storing and synchronizing the root hash data of the field-level MPT sidechains. The consensus protocol cluster main chain reuses the consensus processing resources of the field-level MPT sidechains, eliminating the need to configure a separate consensus processing unit for the consensus protocol cluster main chain, thus reducing the allocation and consumption of cluster resources. The root hashes of all field-level MPT sidechains constitute a hash anchor data set, which serves as the consistency anchor point for the entire cluster's credential storage data, ensuring that the credential storage data obtained by all nodes in the cluster remains consistent.

[0024] S300: Locate the healthy replica node based on the field-level MPT sidechain of the target field, read the ciphertext data of the healthy replica node and replace the damaged ciphertext data locally to complete the repair of the encrypted credential field.

[0025] In this step, the target field is the single encrypted credential field where the ciphertext is detected to be corrupted. The location operation only calls the field-level MPT sidechain data corresponding to the target field and does not access the evidence storage information of other fields. The healthy copy node is the storage node that stores the complete ciphertext data of the target field. The read and replace operations are only performed on the ciphertext data of the target field. Once completed, the single encrypted credential field can be repaired without processing other field data.

[0026] It should be noted that this application creates an independent field-level MPT sidechain for each encrypted credential field, ensuring that single-field notarization and repair operations only affect the data within their own scope and do not touch other field data, thus adhering to the security boundary of independent encryption at the field level. The field-level MPT sidechain data is directly mapped and stored in the existing distributed key-value storage system, eliminating the need for independent deployment of blockchain nodes and reducing the additional occupation of storage and computing resources. The root hash of all field-level MPT sidechains is synchronized to the lightweight consensus protocol cluster main chain, and the sidechains and the main chain reuse the same set of consensus processing resources, avoiding resource redundancy caused by independent consensus of multiple chains. The operations of locating healthy copies and ciphertext replacement are all performed based on the field-level MPT sidechain data of the target field, without traversing the entire credential data. The input and output of the repair process are all closed loops around the target field, and the various technical features are sequentially connected, enabling the cluster to complete the rapid repair of single-field ciphertext during operation without breaking encryption isolation or increasing resource overhead, while ensuring the consistency of data across the entire cluster.

[0027] This application addresses the technical deficiencies in the storage and repair of encrypted credentials in cloud server clusters. First, it creates an independent field-level MPT sidechain for each encrypted credential field. The field-level MPT sidechain data is then stored in a distributed key-value storage system. Next, the root hashes of all sidechains are synchronized to the lightweight consensus protocol cluster main chain, which reuses consensus resources. Finally, the ciphertext replacement and repair are completed by locating a healthy copy through the sidechain of the target field. This application achieves field-level isolated storage through independent sidechains, its lightweight structure adapts to existing cluster storage resources, consensus reuse reduces resource consumption, and targeted repair avoids out-of-bounds operations. It solves the compatibility problem between field encryption isolation and rapid single-field repair without adding new hardware or independent blockchain nodes.

[0028] In one embodiment that can be implemented in this application, such as Figure 2 As shown, an independent field-level MPT sidechain is created for each encrypted credential field in the cloud host cluster, including: S110, obtain the field partitioning result of the encrypted credentials in the cloud host cluster. The field partitioning result is the partitioning result of independent data units obtained after splitting the encrypted credentials according to the data type of the credentials. S120, Generate a unique field identifier for each independent encrypted credential field based on the field segmentation results; S130, constructs a field-level MPT sidechain based on a unique field identifier to store only single-field evidence data.

[0029] This application first obtains the field partitioning result of the encryption credential in the cloud host cluster. The encryption credential is split into multiple independent fields in the cluster according to the data type and usage scenario. The field partitioning result is the partitioning result of the independent data units after splitting. This partitioning result has been configured during the cluster deployment phase and is stored in the basic configuration area of ​​the distributed key-value storage system, which can be directly called to obtain it.

[0030] Based on the field partitioning results, a unique field identifier is generated for each independent encryption credential field. The unique field identifier is generated by combining the node number, field type and random sequence to ensure that the identifiers of all encryption credential fields in the cluster are not duplicated, thus avoiding index conflicts in the stored data.

[0031] Based on a unique field identifier, a field-level MPT sidechain is constructed to store only single-field evidence data. Each field-level MPT sidechain corresponds one-to-one with a unique field identifier. The sidechain only stores the ciphertext hash, version information, and replica node information of the current field, and does not store data of any other fields, thus achieving complete isolation of evidence data between fields.

[0032] For example, the out-of-band management credentials of a physical computing node in a cloud host cluster are divided into four independent encrypted fields: address field, port field, username field, and password field. The system first obtains the field division result of the credentials from the basic configuration area, confirms the division form of the four independent fields, and then generates a corresponding unique field identifier for each field. The unique identifier of the address field includes the node number and address type field, and the unique identifier of the port field includes the node number and port type field. Each identifier has no duplicate content. Finally, four independent field-level MPT sidechains are built based on each unique identifier. Each sidechain only stores the evidence data of the corresponding field.

[0033] It should be noted that the granularity of the field partitioning results can be adjusted according to the security requirements of the cluster. In addition to the four basic fields of address, port, username, and password, information such as credential timeout configuration and permission level can also be split into independent encrypted fields. Each independent field corresponds to a dedicated field-level MPT sidechain, ensuring that all encrypted fields are independently stored and isolated. The generation rule for the unique field identifier can be adapted according to the node scale of the cluster. When the node scale is large, the length of the random sequence can be increased to ensure the uniqueness of the identifier and avoid duplicate identifiers for different nodes and different fields, which could cause index conflicts in the stored data.

[0034] In one embodiment that can be implemented in this application, such as Figure 3 As shown, a field-level MPT sidechain is constructed based on a unique field identifier to store only single-field evidence data, including: S131 uses a combination of a unique field identifier and a version number as the index key for the field-level MPT sidechain; S132, combine the ciphertext hash, replica node information and update timestamp as the index value of the field-level MPT sidechain, and the update timestamp is the time record data of the field-level MPT sidechain data being written to the distributed key-value storage system; S133 is a field-level MPT sidechain built on index keys and index values, without block headers or transaction pool structures.

[0035] This application uses a combination of a unique field identifier and a version number as the index key for the field-level MPT sidechain. The version number is used to distinguish between evidence data with different update times for the same field. The index key is generated using a prefix concatenation method, which is compatible with the hierarchical index structure of the Merkel-Patricia tree.

[0036] The ciphertext hash, replica node information, and update timestamp are combined to form the index value of the field-level MPT sidechain. The ciphertext hash is the result of hashing the ciphertext data of the encrypted credential field. The replica node information is the set of node numbers that store three copies of the ciphertext of this field. The update timestamp is the time record data of the field-level MPT sidechain data being written to the distributed key-value storage system. The combination of these three types of data forms the complete index value content.

[0037] The field-level MPT sidechain, built on index keys and index values, has no block header or transaction pool structure. This sidechain removes the redundant structure of traditional blockchains, retaining only the mapping relationship between index keys and index values. It has a small storage size, fast read and write speed, and is fully adapted to the lightweight operation requirements of cloud host clusters.

[0038] It should be noted that the Merkel-Patricia tree index structure reduces the complexity of data retrieval. Using a combination of a unique field identifier and a version number as the index key, it can quickly locate the specified version of the evidence data for the target field without traversing the entire field-level MPT sidechain data, thus improving the efficiency of evidence data retrieval. The version number update rule can be adjusted according to the cluster's credential management strategy. Each time a credential field is updated, the version number is incremented, ensuring that evidence data from different update batches can be accurately distinguished and avoiding version confusion.

[0039] For example, when the unique field identifier of any encrypted credential field is compute001_pwd and the current version number is 1, the index key is compute001_pwd_1. The index value contains the hash result of the ciphertext of this version, the numbers of the three storage nodes, and the time record of data writing. The field-level MPT sidechain built based on this index key and index value only contains the evidence data of this cryptographic field, without any related content of other fields, and without the redundant structures such as block headers and transaction pools of traditional blockchains. The storage volume is only one-tenth of that of traditional blockchain evidence storage structures.

[0040] In one embodiment that can be implemented in this application, such as Figure 4 As shown, storing field-level MPT sidechain data in a distributed key-value store system includes: S140 maps the index keys and index values ​​of the field-level MPT sidechain to key-value pairs in the distributed key-value storage system; S150, Write the mapped key-value pairs to the specified storage path of the distributed key-value storage system. The specified storage path is the dedicated storage area for credential storage in the distributed key-value storage system. S160 synchronizes key-value pairs to multiple storage nodes in a distributed key-value storage system through a consistency protocol.

[0041] This application maps the index keys and index values ​​of the field-level MPT sidechain to key-value pairs in a distributed key-value storage system. The index key corresponds to the key in the distributed key-value storage system, and the index value corresponds to the value in the distributed key-value storage system. The mapping process follows the storage specifications of the distributed key-value storage system.

[0042] The mapped key-value pairs are written to the specified storage path of the distributed key-value storage system. The specified storage path is a dedicated storage area for credential storage in the distributed key-value storage system. This area is isolated from the storage areas of other business data in the cluster to avoid data read and write conflicts.

[0043] The consistency protocol synchronizes key-value pairs to multiple storage nodes in the distributed key-value storage system. The consistency protocol ensures that key-value pairs remain consistent across multiple storage nodes, and the failure of a single storage node will not result in the loss of evidence data.

[0044] For example, the index key of the field-level MPT sidechain is compute001_pwd_1, and the index value is a combination of encrypted hash, replica node information and update timestamp. The system maps this set of data into a key-value pair of the distributed key-value storage system, writes it into the dedicated storage area for credential storage, and then synchronizes the key-value pair to the three storage nodes through the consistency protocol to complete the multi-replica storage of the field-level MPT sidechain data.

[0045] The consistency protocol of the distributed key-value storage system in this application can be adapted to the deployment architecture of the cluster. Any protocol that can achieve strong data consistency across multiple nodes can be applied to the technical solutions of the embodiments of this application. The division of specified storage paths can be adjusted according to the storage resource configuration of the cluster. In addition to dividing dedicated storage areas, secondary storage paths can be further divided within the dedicated storage areas for different nodes and different types of credential fields, so as to achieve fine-grained management of evidence data and improve the efficiency of data reading and writing.

[0046] It should be noted that the writing and synchronization operations of field-level MPT sidechain data are all performed during the low-peak hours of the cluster's business. This will not occupy the computing and network resources of the cluster's fault isolation business, nor will it affect the normal operation of the cluster's core business. After the data synchronization is completed, all control nodes in the cluster can access the complete field-level MPT sidechain data, ensuring that subsequent repair operations can be executed normally.

[0047] In one embodiment that can be implemented in this application, such as Figure 5 As shown, the root hashes of all field-level MPT sidechains are synchronized to the consensus protocol cluster main chain, including: S210, calculate the current root hash of each field-level MPT sidechain; S220, add the current root hash to the hash anchor set of the consensus protocol cluster main chain. The hash anchor set is an ordered data set in the consensus protocol cluster main chain that stores the root hashes of all field-level MPT side chains. S230 synchronizes the hash anchor set to all control nodes in the cluster through a consensus protocol.

[0048] This application calculates the current root hash of each field-level MPT sidechain. The root hash is the top-level hash value of the Merkel-Patricia tree, which can represent the data integrity of the entire tree. After the field-level MPT sidechain data is updated, the root hash will change synchronously.

[0049] The current root hash is added to the hash anchor set of the consensus protocol cluster main chain. The hash anchor set is an ordered data set in the consensus protocol cluster main chain that stores the root hashes of all field-level MPT side chains. The root hashes in the set are arranged in the order of the field identifiers, which facilitates fast retrieval and comparison.

[0050] The consensus protocol synchronizes the hash anchor set to all control nodes in the cluster. The consensus protocol only performs data consistency verification and synchronization operations, and does not perform mining, block packaging and other operations of traditional blockchains. The synchronization time is short and the resource consumption is low.

[0051] It should be noted that the consensus protocol cluster main chain only stores the hash anchor set and does not store the full set of field-level MPT sidechain data, reducing the storage pressure on the main chain. Simultaneously, the hash anchor set serves as the consistency anchor for all cluster credential data, ensuring that the credential storage status obtained by all control nodes remains consistent. The consensus protocol of the consensus protocol cluster main chain reuses the same consensus processing resources as the consistency protocol of the distributed key-value storage system, eliminating the need to deploy a separate consensus service for the consensus protocol cluster main chain, reducing cluster resource consumption, and ensuring consistency between the data on the consensus protocol cluster main chain and the field-level MPT sidechain data in the distributed key-value storage system.

[0052] For example, there are two hundred encrypted credential fields in the cluster, each field corresponding to a field-level MPT sidechain. The system calculates the current root hash of each of the two hundred sidechains, adds all root hashes to the hash anchor set in the order of field identifiers, and then synchronizes the hash anchor set to the three control nodes of the cluster through the consensus protocol. All three control nodes obtain a completely consistent hash anchor set, which serves as the consistency anchor point for the entire cluster's credential storage data.

[0053] Those skilled in the art will understand that the calculation frequency of the root hash can be adjusted according to the cluster's credential update frequency. After a credential field is updated and the field-level MPT sidechain data changes, the system immediately recalculates the root hash of the corresponding sidechain and updates the hash anchor set of the consensus protocol cluster main chain to ensure that the anchor data stored on the main chain is always up-to-date and synchronized with the field-level MPT sidechain data. The sorting rules of the hash anchor set can be adjusted according to the cluster's management needs. In addition to sorting by field identifier, it can also be sorted by node number or field update time, as long as it ensures that the root hash within the set can be accurately retrieved and compared.

[0054] In one embodiment that can be implemented in this application, such as Figure 6 As shown, the healthy replica node is located based on the field-level MPT sidechain of the target field, including: S310, Extract the unique field identifier corresponding to the target field; S320, based on a unique field identifier, calls the corresponding field-level MPT sidechain from the distributed key-value storage system; S330 parses replica node information and node health status from the field-level MPT sidechain. Node health status is identifier data that characterizes the operating status and data availability of storage nodes.

[0055] This application extracts the unique field identifier corresponding to the target field. The target field is the encryption credential field where the system detects that the encrypted data is corrupted. The unique field identifier is generated during the field creation stage and can be directly extracted from the local configuration information.

[0056] The corresponding field-level MPT sidechain is retrieved from the distributed key-value store system based on the unique field identifier. The distributed key-value store system retrieves the corresponding key-value pair based on the unique field identifier and returns the complete field-level MPT sidechain data.

[0057] The replica node information and node health status are parsed from the field-level MPT sidechain. The replica node information includes all node numbers of the stored target field ciphertext. The node health status is the identifier data that characterizes the running status and data availability of the storage node. A node whose health status is marked as available is a healthy replica node.

[0058] For example, if the ciphertext of the password field of a physical computing node is corrupted, the system extracts the unique field identifier of the password field, calls the corresponding field-level MPT sidechain, and parses out the number and health status of the three storage nodes. Among them, two nodes are in a usable health status and one node is in an unusable health status. The system selects the two usable nodes as healthy replica nodes.

[0059] Those skilled in the art will understand that ciphertext corruption detection of target fields can be performed through a scheduled integrity verification task. This task runs at a preset time interval, reads the ciphertext of the encrypted credential field from locally stored data, calculates the real-time hash value, and compares it with the standard ciphertext hash stored in the field-level MPT sidechain. If the comparison is inconsistent, the ciphertext is determined to be corrupted, triggering the repair process. The execution cycle of the scheduled verification task can be adjusted according to the cluster's security requirements. A shorter cycle results in faster ciphertext corruption detection, but also increases the consumption of cluster resources. This can be adapted and adjusted based on the actual operating conditions of the cluster.

[0060] It should be noted that the node health status data is updated in real time by the cluster's node monitoring module. The node monitoring module detects the running status and data availability of all storage nodes according to a preset time period, updates the node health status identifier, and synchronizes the updated health status data to the field-level MPT sidechain. This ensures that the node health status data stored in the sidechain is always up-to-date, providing an accurate basis for the selection of healthy replica nodes.

[0061] In one embodiment that can be implemented in this application, such as Figure 7 As shown, the process of reading ciphertext data from a healthy replica node and replacing locally corrupted ciphertext data includes: S340: Select healthy replica nodes from the replica node information based on the node health status; S350, add a field-level distributed lock to the target field. The field-level distributed lock is a mutually exclusive access control identifier that applies only to a single encrypted credential field. S360 reads encrypted ciphertext data of target fields from healthy replica nodes based on a remote data access protocol.

[0062] This application selects healthy replica nodes from the replica node information based on the node health status. The selection process excludes nodes whose health status is marked as unavailable and only retains storage nodes that are running normally and have complete data.

[0063] Add a field-level distributed lock to the target field. The field-level distributed lock is a mutual exclusion access control identifier that only applies to a single encrypted credential field. After the lock is added, other processes cannot access the stored data of the target field, thus avoiding data conflicts during the repair process.

[0064] The encrypted ciphertext data of the target field is read from the healthy replica node based on the remote data access protocol. The remote data access protocol adopts an encrypted transmission method to ensure that the ciphertext data is not stolen or tampered with during transmission.

[0065] Those skilled in the art will understand that a field-level distributed lock operates only on a single target field and will not affect the normal access and use of other encrypted credential fields, ensuring the continuous operation of cluster services. When multiple healthy replica nodes exist, the system can select the optimal healthy replica node to read the encrypted data based on the node's network latency and load, improving data reading efficiency and shortening the repair process time. The remote data access protocol can be adapted according to the cluster's network architecture; as long as it can achieve secure and stable transmission of encrypted data, it can be applied to the technical solutions of the embodiments of this application.

[0066] For example, the replica node information of the target field contains three storage nodes, two of which are in a healthy and available state. The system selects these two nodes as healthy replica nodes, checks the network latency and load of the two nodes, and selects the node with lower network latency and lower load as the data reading node. Then, a field-level distributed lock is added to the target field to lock the local storage area of ​​the target field. Based on the encrypted remote data access protocol, the encrypted ciphertext data of the target field is read from the selected healthy replica node.

[0067] It should be noted that the holding time of the field-level distributed lock has a timeout threshold. If the repair process is not completed within the timeout threshold, the lock will be automatically released to prevent the target field from being locked for a long time due to repair process abnormalities, thus preventing it from being called by cluster services. The lock timeout threshold can be adjusted according to the cluster node size and network conditions to ensure that the lock holding time meets the execution requirements of the repair process without causing long-term locking.

[0068] In one embodiment that can be implemented in this application, such as Figure 8 As shown, reading the ciphertext data from the healthy replica node and replacing the corrupted ciphertext data locally also includes: S370 uses encrypted ciphertext data to overwrite the damaged ciphertext data stored locally; S380, remove the field-level distributed lock on the target field; S390, calculates the real-time hash value of the local encrypted data after overwriting.

[0069] This application uses encrypted ciphertext data to overwrite locally stored corrupted ciphertext data. The overwrite operation uses an atomic write method to ensure that no data is truncated or corrupted during the write process.

[0070] Remove the field-level distributed lock on the target field. After the lock is removed, the target field returns to normal access status, and the repaired ciphertext data can be accessed normally by the cluster.

[0071] Calculate the real-time hash value of the local encrypted data after overwriting. The hash operation adopts the same operation rules as the standard encrypted hash to ensure that the operation results can be directly compared to verify the integrity of the repaired encrypted data.

[0072] For example, the real-time hash value of the repaired password field ciphertext data is obtained through hash operation. After comparison with the standard ciphertext hash stored in the field-level MPT sidechain, it is completely consistent. The system updates the update timestamp of the sidechain to the current repair time to complete the data verification.

[0073] It should be noted that the implementation of atomic write operations can be adapted to the type of storage medium to ensure that data corruption or loss does not occur in the event of system anomalies or network interruptions during the write process. Either all ciphertext data is written completely, or the original damaged ciphertext data is retained; no incomplete data in the intermediate state will occur. After the ciphertext data is overwritten, the system will immediately perform a data persistence operation, writing the repaired ciphertext data completely to the persistent storage medium to prevent data loss due to system anomalies.

[0074] It should be noted that the removal operation of field-level distributed locks must be performed after the encrypted data has been completely written and persisted. This ensures that the locally stored encrypted data has been repaired and can be normally called by cluster services when the lock is removed, thus avoiding the situation where the lock is released prematurely, causing the unrepaired data to be called by services and resulting in the failure of the fault isolation operation.

[0075] In one embodiment that can be implemented in this application, such as Figure 9 As shown, after calculating the real-time hash value of the overwritten local ciphertext data, the process also includes: S391, compare the real-time hash value with the ciphertext hash stored in the field-level MPT sidechain; S392, if the comparison is consistent, update the update timestamp of the field-level MPT sidechain, recalculate the root hash of the field-level MPT sidechain and synchronize it to the consensus protocol cluster main chain; S393, if the comparison is inconsistent, the encrypted data reading operation of the healthy replica node will be re-executed.

[0076] This application compares the real-time hash value with the ciphertext hash stored in the field-level MPT sidechain. The comparison operation directly compares the character sequences of the two sets of hash data to confirm whether the data is consistent.

[0077] If the comparison is consistent, the update timestamp of the field-level MPT sidechain is updated, the root hash of the field-level MPT sidechain is recalculated and synchronized to the consensus protocol cluster main chain. The update timestamp is the time record of the current data being written, representing the latest repair time of the ciphertext data. After the recalculated root hash is synchronized to the consensus protocol cluster main chain, the consistency anchor data of the entire cluster is updated synchronously.

[0078] If the comparison is inconsistent, the encrypted data reading operation of the healthy replica node is re-executed, and the data is reread and overwritten until the real-time hash value is consistent with the standard encrypted hash, ensuring that the repaired data is complete and valid.

[0079] It should be noted that hash mismatches are mostly caused by anomalies during data transmission or temporary failures of the storage medium. Re-executing the read and overwrite operations of the encrypted data will resolve the issue. If the hash match remains inconsistent after multiple re-executions, the system will trigger an anomaly alarm, notifying operations and maintenance personnel to investigate storage node and network link failures to prevent the repair process from continuously failing due to underlying hardware faults.

[0080] It should be noted that the synchronization and update operations of the root hash do not require restarting the cluster service or interrupting the execution of fault isolation services, and the cluster's operating status remains unaffected. After the hash anchor set of the consensus protocol cluster main chain is updated, the system will synchronize the updated hash anchor set to all control nodes in the cluster through the consensus protocol, ensuring that the consistent anchor point data obtained by all nodes remains unified and that there will be no inconsistencies in the data views of different nodes.

[0081] For example, after the repair is completed, the system calculates the real-time hash value of the target field ciphertext and compares it with the standard ciphertext hash stored in the field-level MPT sidechain. If the two sets of hash data are completely consistent, the system updates the update timestamp of the sidechain to the current repair time, recalculates the root hash of the field-level MPT sidechain, updates the new root hash to the hash anchor set of the consensus protocol cluster main chain, and synchronizes the updated hash anchor set to the three control nodes of the cluster through the consensus protocol to complete the data consistency update of the entire cluster.

[0082] In summary, distributed storage typically uses replica groups or whole nodes as the basic granularity for data repair. Repairing a single corrupted field often requires traversing the entire set of credentials or synchronizing the entire data shard, implicitly assuming that the repair granularity is roughly aligned with the storage granularity. In the blockchain notarization field, to ensure data immutability, it tends to incorporate complete objects or batches of data into a single Merkle tree structure, using a single root hash as the integrity verification anchor. This structure naturally excludes independent notarization and verification of individual fields. While both paradigms work well within their respective domains, when cloud server clusters require both adherence to field-level encryption isolation boundaries and millisecond-level single-field repair without additional hardware resources, directly combining the two immediately exposes a structural contradiction: the repair granularity requires field-level isolation, while the notarization structure uses the entire object as the basic unit, and resource constraints preclude the introduction of independent blockchain nodes.

[0083] This application breaks away from the inherent structural units of the two aforementioned paradigms, elevating the MPT tree from a subordinate structure of the chain to an independent entity for evidence storage. It constructs a lightweight sidechain for each encrypted credential field, maintaining only a single-field index key and index value. Then, it abstracts the root hash of all sidechains into a hash anchor set for the main chain of a consensus protocol cluster. This abstraction transforms the traditional vertical hierarchical structure of blockchains into a horizontal sharding anchor structure, ensuring that each field has a physically independent evidence storage path while also converging to a consistent integrity view across the entire cluster through the root hash. This structural reorganization not only breaks the existing distributed storage model based on replica groups but also the blockchain model that uses full data upload as the evidence storage unit.

[0084] At the implementation level, the field-level MPT sidechain needs to abandon the traditional blockchain's block header and transaction pool structure, retaining only the mapping relationship between index keys and index values. This prevents the sidechain from using existing blockchain middleware or libraries, requiring it to implement lightweight read / write, persistence, and key-value mapping with the distributed key-value storage system. Simultaneously, the sidechain embeds replica node health status information. This embedding requires real-time linkage between the MPT sidechain's data update chain and the cluster node monitoring module's detection cycle, but the frequency of this linkage must be controlled to avoid pressure on the notarization write. The consensus protocol of the cluster main chain only needs to synchronize the ordered data of the hash anchor set, but it must ensure that it shares the same consensus processing resources with the distributed key-value storage system of the control node, simplifying the consensus steps while avoiding resource contention with the underlying storage protocol. The field-level distributed lock introduced in the repair process also needs to strike a balance between locking granularity and lock timeout strategy. The lock acts on a single field rather than the entire certificate; therefore, the locking mechanism must be able to identify the field division results of the encrypted certificate, and strictly verify the atomic write before releasing the lock after the repair is completed.

[0085] The sequential connection of the aforementioned technical features under the guidance of structural reorganization indicates that this application does not involve a conventional replacement or parameter adjustment of existing technologies. Instead, it reorganizes the ownership relationship between consensus resources and storage paths based on redefining the basic unit of evidence storage and the basic granularity of repair, enabling the previously mutually exclusive isolation and repairability to coexist compatiblely within the same cluster facility. This effect stems from the transformation of the MPT data structure from in-chain components to independent anchored units, and the resulting lightweight main chain synchronization and field-level targeted repair mechanism, rather than any improvement to a single technical feature. This cross-paradigm structural reorganization concept and its refined engineering adaptation constitute the foundation for this solution to overcome the inherent contradictions of existing technologies.

[0086] Based on the same principle, this application also provides a cloud host encryption credential field-level repair system, such as... Figure 10As shown, the system includes a sidechain creation unit, a data storage unit, a main chain synchronization unit, and a repair execution unit.

[0087] Sidechain creation unit 01 is used to create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster. This unit completes the sidechain construction based on the field division results and the unique field identifier, and outputs independent field-level MPT sidechain data.

[0088] Data storage unit 02 is used to store field-level MPT sidechain data to a distributed key-value storage system. This unit completes the mapping between field-level MPT sidechain data and key-value pairs in the distributed key-value storage system and performs multi-replica synchronous storage operations.

[0089] Main chain synchronization unit 03 is used to synchronize the root hash of all field-level MPT sidechains to the consensus protocol cluster main chain. This unit completes the synchronization of root hash calculation and hash anchor set, and reuses consensus resources to complete data consistency processing.

[0090] Repair execution unit 04 is used to locate healthy replica nodes based on the field-level MPT sidechain of the target field, read the ciphertext data of the healthy replica node and replace the local damaged ciphertext data. This unit completes the operations of healthy node filtering, ciphertext reading, atomic overwriting and data verification, and finally realizes the repair of the encrypted credential field.

[0091] The distributed key-value storage system is a cluster storage component that uses a consensus protocol to achieve multi-replica data storage. The consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data. The system reuses the existing hardware and software resources of the cluster throughout the process, without the need to add any independent equipment or modules.

[0092] Those skilled in the art will understand that the four functional units of the system can be deployed on the same control node of the cluster, or distributed across multiple control nodes, as long as stable data interaction and collaborative work can be achieved between the units. Each functional unit of the system adopts a stateless design; in the event of a single node failure, the corresponding functional units on other nodes can immediately take over the relevant work, ensuring the continuous availability of the system's evidence preservation and repair services, and preventing service interruption due to a single point of failure.

[0093] It should be noted that all functional units of the system are fully compatible with the existing monitoring, fault isolation, and storage modules of the cluster. It can directly obtain node health status data, credential field partitioning results, and storage node operational data without requiring any modifications to the existing cluster architecture, demonstrating strong adaptability. The system's operational logs are synchronously written to the cluster's log management module. The logs only record the operation time, target field, and execution result, without containing any sensitive credential information, thus preventing the leakage of sensitive information.

[0094] For example, the complete implementation process of the technical solution of this application is described in conjunction with an actual operating scenario. The cloud host cluster includes three control nodes and two hundred physical computing nodes. The out-of-band management credentials of each physical computing node are divided into four independent encrypted fields: address field, port field, username field, and password field. The ciphertext data of all encrypted fields is stored on the three control nodes in a three-replica manner. The distributed key-value storage system uses a consistency protocol to ensure the consistency of data across multiple replicas. The consensus protocol cluster main chain has a lightweight consensus structure and reuses the consensus processing resources of the side chains. If the ciphertext of the password field of a physical computing node stored locally on a certain control node is corrupted due to a storage media failure, the system first detects through the integrity verification module that the ciphertext hash of the password field is inconsistent with the standard hash stored on the side chain, triggering the repair process. The side chain creation unit has pre-created an independent field-level MPT side chain for this password field. The field-level MPT side chain data is stored in the credential storage area of ​​the distributed key-value storage system, and the main chain synchronization unit has synchronized the root hash of the side chain to the hash anchor set of the consensus protocol cluster main chain. The repair execution unit extracts the unique field identifier of the password field, calls the corresponding field-level MPT sidechain, parses the IDs and health status of the three storage nodes, selects two healthy replica nodes, reads the encrypted ciphertext data from one of the healthy replica nodes via a remote data access protocol, adds a field-level distributed lock to the password field, atomically overwrites the locally corrupted ciphertext data, removes the distributed lock, calculates the real-time hash value, compares it with the sidechain's standard hash, updates the sidechain's update timestamp, recalculates the sidechain root hash, and synchronizes it to the consensus protocol cluster main chain, completing the consistency update. The entire repair process only executes on the password field, without accessing other encrypted fields such as addresses, ports, or usernames, adhering to the security boundary of independent field-level encryption. The repair process does not add any storage or computing resources, the repair time is controlled within milliseconds, the cluster fault isolation service is not affected, and after the repair, the credential storage data of the entire cluster remains consistent, and the ciphertext data can be normally called by the cluster to perform fault isolation operations.

[0095] Those skilled in the art will understand that the technical solutions provided in the embodiments of this application, through the sequential connection and mutual cooperation of various technical features, achieve the technical effects of field-level encrypted isolation, lightweight storage, consensus resource reuse, and targeted rapid repair. All operations are adapted to the operating scenarios of cloud host clusters, do not require modification of the existing cluster architecture, can be directly deployed and implemented, and the logical closed-loop design of the repair process ensures the accuracy and reliability of data processing, meeting the usage requirements of cloud computing data centers for secure storage and efficient repair of out-of-band management credentials.

[0096] In this embodiment, the construction and use of field-level MPT sidechains can be flexibly adapted to the cluster size. When the cluster has more than 1,000 physical computing nodes, the nodes can be grouped according to racks and availability zones, and a group main chain can be created for each group. The group main chain stores the root hashes of all field-level MPT sidechains within the corresponding group, while the consensus protocol cluster main chain only stores the root hashes of all group main chains, forming a three-level hash anchoring architecture. This further reduces the storage pressure on the consensus protocol cluster main chain and improves the synchronization and retrieval efficiency of the root hashes. In the three-level hash anchoring architecture, the group main chain also reuses the consensus processing resources of the field-level MPT sidechains without adding additional resource overhead, while ensuring that the data consistency anchoring effect of the entire cluster is not affected.

[0097] It should be noted that when the encrypted credential fields are periodically rotated, the system generates a new version number for the new credential ciphertext, constructs the new version of the field-level MPT sidechain data, synchronizes it to the distributed key-value storage system, recalculates the root hash of the sidechain, and updates the hash anchor set of the consensus protocol cluster main chain. Throughout the credential rotation process, the old version of the field-level MPT sidechain data is retained for a preset time period. If the new version of the credential encounters an anomaly, it can be quickly rolled back to the old version of the credential data, ensuring the continuous availability of cluster fault isolation services. The retention period for the old version of the field-level MPT sidechain data can be adjusted according to the cluster's credential management strategy. After the retention period ends, the system automatically cleans up the expired field-level MPT sidechain data, releasing storage resources.

[0098] For example, the cluster's credential management strategy requires a full credential rotation every ninety days. After operations and maintenance personnel complete the out-of-band management credential update for all physical computing nodes, the system generates a new version number for each encrypted field, constructs the new version of the field-level MPT sidechain data, synchronizes it to the distributed key-value storage system, recalculates the root hash of all sidechains, updates the hash anchor set of the consensus protocol cluster main chain, and completes the data consistency synchronization of the entire cluster. The old version of the field-level MPT sidechain data is retained for thirty days. If the new version of the credential is abnormal within thirty days, the system can immediately roll back to the old version of the field-level MPT sidechain data and credential ciphertext to ensure that the fault isolation operation can be executed normally. After the thirty-day retention period ends, the system automatically cleans up the old version of the field-level MPT sidechain data and releases the storage resources of the distributed key-value storage system.

[0099] It should be noted that during the voucher rotation process, the system will retain both the old and new versions of the field-level MPT sidechain data. When the cluster performs fault isolation operations, it will prioritize the use of the new version of the voucher data. If the verification of the new version of the voucher fails, it will automatically switch to the old version of the voucher data to ensure that the fault isolation operation will not fail due to the voucher rotation, thus achieving seamless voucher rotation and not affecting the normal operation of the cluster's core business.

[0100] In this embodiment, when a control node is added or removed from the cluster, the system automatically adjusts the replica node information of the field-level MPT sidechain, updates the field-level MPT sidechain data and synchronizes it to the distributed key-value storage system, recalculates the sidechain root hash, and updates the hash anchor set of the consensus protocol cluster main chain. This ensures that the newly added control node can obtain complete field-level MPT sidechain data and credential ciphertext data. After the control node is removed, the evidence storage data and ciphertext data of the remaining nodes still maintain triple-replica redundancy, preventing data loss. Throughout the entire node adjustment process, the cluster's fault isolation services are unaffected, and the evidence storage and repair services remain continuously available.

[0101] For example, when a cluster expands its capacity and adds a new control node, the system includes this node in the replica node information, creates replicas of the ciphertext data for all encrypted credential fields in the new node, updates the replica node information of all field-level MPT sidechains, synchronizes it to the distributed key-value storage system, recalculates the root hash of all sidechains, updates the hash anchor set of the consensus protocol cluster main chain, and completes data consistency synchronization across the entire cluster. The new node can normally access all field-level MPT sidechain data and ciphertext data, and can normally perform evidence storage and repair operations. The cluster's fault isolation services are not affected in any way.

[0102] It's important to note that when removing a control node, the system first verifies the number of ciphertext replicas of the remaining nodes. This ensures that after removing the node, at least three complete ciphertext replicas remain in the remaining nodes before performing the node removal operation. This prevents data loss due to insufficient ciphertext replicas caused by node removal. After node removal is complete, the system updates the replica node information of all field-level MPT sidechains, removing the relevant data of offline nodes to ensure that the replica node information stored in the sidechain remains accurate and valid.

[0103] In this embodiment, the system periodically performs integrity checks on all field-level MPT sidechain data and consensus protocol cluster main chain data. The check cycle can be adjusted according to the security requirements of the cluster. During the check, the system recalculates the root hash of each field-level MPT sidechain and compares it with the root hash stored in the hash anchor set of the consensus protocol cluster main chain. If an inconsistency is found, the system immediately triggers the field-level MPT sidechain data repair process, reads complete field-level MPT sidechain data from other healthy nodes, overwrites the locally damaged field-level MPT sidechain data, and resynchronizes the hash anchor set of the consensus protocol cluster main chain to ensure the consistency and integrity of the field-level MPT sidechain data and the consensus protocol cluster main chain data.

[0104] For example, the system's integrity verification cycle is set to 24 hours, with verification operations performed during daily off-peak business hours. During the verification process, the system recalculates the root hashes of the MPT sidechains for two hundred encrypted fields and compares them one by one with the root hashes in the hash anchor set of the consensus protocol cluster main chain. If the system finds that the root hash of the sidechain for one field is inconsistent, it immediately triggers the field-level MPT sidechain data repair process. It reads the complete field-level MPT sidechain data for that field from other health control nodes, overwrites the locally corrupted field-level MPT sidechain data, recalculates the root hash, and updates the hash anchor set of the consensus protocol cluster main chain, thus completing the repair of the field-level MPT sidechain data. The entire verification and repair process does not affect the normal business operation of the cluster.

[0105] It should be noted that the integrity verification and repair process of field-level MPT sidechain data is consistent with the repair process of ciphertext. Both are based on independent field-level sidechains to achieve targeted repair, without touching field-level MPT sidechain data of other fields, adhering to the security boundary of field-level isolation, and reusing the existing storage and consensus resources of the cluster without adding any additional resource overhead, thus ensuring the integrity and consistency of the cluster's evidence storage data.

[0106] In this application embodiment, all operations involving encrypted hash calculations employ hash calculation algorithms that conform to industry-standard norms to ensure the uniqueness and immutability of the calculation results. The hash calculation algorithm can be adapted and adjusted according to the security and compliance requirements of the cluster. Any calculation algorithm that can achieve data integrity representation can be applied to the technical solution of this application embodiment. All operations involving encrypted transmission employ encrypted transmission protocols that conform to industry-standard norms to ensure data security during transmission and prevent data theft or tampering. The encrypted transmission protocol can be adapted and adjusted according to the network architecture and security requirements of the cluster.

[0107] It should be noted that the technical solutions provided in this application embodiment can be applied not only to out-of-band management credential storage and repair scenarios in cloud host clusters, but also to sensitive credential storage and repair scenarios in other distributed systems, such as access credentials for distributed databases, node management credentials for container clusters, and authentication credentials for storage systems. As long as there is a sensitive credential management scenario that requires independent encryption storage at the field level and targeted repair, the technical solutions in this application embodiment can be adapted to achieve secure storage and efficient repair of sensitive credentials.

[0108] For example, the technical solution of this application embodiment is applied to the scenario of access credential management of a distributed database. The distributed database contains multiple data nodes and multiple management nodes. The access credential of each data node is split into five independent encrypted fields: address, port, username, password, and permission level. An independent field-level MPT sidechain is created for each encrypted field. The field-level MPT sidechain data is stored in a distributed key-value storage system. The root hash of all sidechains is synchronized to the lightweight consensus protocol cluster main chain. When the ciphertext of a single password field of a management node is damaged, the system locates a healthy replica node through the corresponding sidechain, reads the ciphertext data, and completes targeted repair. The entire repair process is only performed on the password field and does not touch other encrypted fields, thus adhering to the security boundary of independent encryption at the field level. The repair time is short and does not affect the normal access and business operation of the distributed database.

[0109] It should be noted that the technical solutions of this application have strong adaptability. The granularity of field division, the rules for sidechain construction, the number of replicas stored, the type of consensus protocol, and other technical parameters can be adjusted according to the needs of different application scenarios. As long as they do not deviate from the core concept of the technical solutions of this application, all adjustments and adaptations are within the protection scope of this application.

[0110] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for repairing cloud server encryption credentials at the field level, characterized in that, include: Create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster, and store the field-level MPT sidechain data in a distributed key-value storage system. The field-level MPT sidechain is used to store the ciphertext hash, version information and replica node information of the corresponding encrypted credential field. The distributed key-value storage system is a cluster storage component that uses a consistency protocol to implement multi-replica data storage. The root hash of all field-level MPT sidechains is synchronized to the consensus protocol cluster main chain. The consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data. Based on the field-level MPT sidechain of the target field, locate the healthy replica node, read the ciphertext data of the healthy replica node and replace the local damaged ciphertext data to complete the repair of the encrypted credential field.

2. The method according to claim 1, characterized in that, Create independent field-level MPT sidechains for each encrypted credential field in the cloud host cluster, including: Obtain the field partitioning results of the encrypted credentials in the cloud host cluster; Generate a unique field identifier for each independent encrypted credential field based on the field segmentation results; Construct a field-level MPT sidechain based on a unique field identifier to store only single-field evidence data; The field partitioning result is the result of splitting the encrypted certificate into independent data units according to the certificate data type.

3. The method according to claim 2, characterized in that, A field-level MPT sidechain is constructed based on a unique field identifier to store only single-field evidence data, including: The unique field identifier and version number are used as the index key for the field-level MPT sidechain; The encrypted hash, replica node information, and update timestamp are combined as the index value of the field-level MPT sidechain; A field-level MPT sidechain with no block header and transaction pool structure is constructed based on index keys and index values; Update the timestamp to the time record data written to the distributed key-value storage system from the field-level MPT sidechain data.

4. The method according to claim 1, characterized in that, Store field-level MPT sidechain data in a distributed key-value store system, including: Map the index keys and index values ​​of the field-level MPT sidechain to key-value pairs in a distributed key-value storage system; Write the mapped key-value pairs to the specified storage path in the distributed key-value storage system; A consistency protocol is used to synchronize key-value pairs to multiple storage nodes in a distributed key-value storage system. The specified storage path is a dedicated storage area for credential storage within a distributed key-value storage system.

5. The method according to claim 1, characterized in that, Synchronize the root hashes of all field-level MPT sidechains to the consensus protocol cluster main chain, including: Calculate the current root hash of each field-level MPT sidechain; Add the current root hash to the hash anchor set of the consensus protocol cluster main chain; The hash anchor set is synchronized to all control nodes in the cluster through a consensus protocol; The hash anchor set is an ordered data set that stores the root hashes of all field-level MPT sidechains in the main chain of the consensus protocol cluster.

6. The method according to claim 1, characterized in that, Locating healthy replica nodes based on the field-level MPT sidechain of the target field, including: Extract the unique field identifier corresponding to the target field; The corresponding field-level MPT sidechain is invoked from the distributed key-value storage system based on a unique field identifier; Parse replica node information and node health status from the field-level MPT sidechain; Node health status is identifier data that characterizes the operating status and data availability of storage nodes.

7. The method according to claim 6, characterized in that, Read the ciphertext data from the healthy replica node and replace the corrupted ciphertext data locally, including: Healthy replica nodes are selected from the replica node information based on their health status. Add a field-level distributed lock to the target field; Encrypted ciphertext data of the target field is read from a healthy replica node based on a remote data access protocol; A field-level distributed lock is a mutually exclusive access control identifier that applies only to a single encrypted credential field.

8. The method according to claim 7, characterized in that, Reading the ciphertext data from the healthy replica node and replacing the corrupted ciphertext data locally also includes: The corrupted ciphertext data is overwritten with encrypted ciphertext data; Remove the field-level distributed lock from the target field; Calculate the real-time hash value of the local encrypted data after overwriting.

9. The method according to claim 8, characterized in that, After calculating the real-time hash value of the overwritten local ciphertext data, the following is also included: The real-time hash value is compared with the ciphertext hash stored in the field-level MPT sidechain; If the comparison matches, the update timestamp of the field-level MPT sidechain is updated, the root hash of the field-level MPT sidechain is recalculated and synchronized to the consensus protocol cluster main chain; If the comparison is inconsistent, the encrypted data reading operation of the healthy replica node will be re-executed.

10. A cloud host encrypted credential field-level repair system, characterized in that, include: Sidechain creation unit, data storage unit, main chain synchronization unit, and repair execution unit; The sidechain creation unit is used to create an independent field-level MPT sidechain for each encrypted credential field in the cloud host cluster; The data storage unit is used to store field-level MPT sidechain data to a distributed key-value storage system; The main chain synchronization unit is used to synchronize the root hash of all field-level MPT sidechains to the consensus protocol cluster main chain; The repair execution unit is used to locate healthy replica nodes based on the field-level MPT sidechain of the target field, read the ciphertext data of the healthy replica node and replace the local corrupted ciphertext data; The distributed key-value storage system is a cluster storage component that uses a consensus protocol to achieve multi-replica data storage, and the consensus protocol cluster main chain is a blockchain structure that uses a consensus protocol to maintain hash-anchored data.

Images