A blockchain-based talent data credible sharing and security management method

Abstract

The present application relates to the field of computer security devices and blockchain technology, and discloses a talent data trusted sharing and safe management and control method based on blockchain. The method comprises the following steps: a data owner node generates a nested ciphertext structure containing a main access strategy and a revocation sub-strategy and stores the nested ciphertext structure into an off-chain distributed storage system; when an attribute revocation event occurs, an intelligent contract updates a global attribute state tree and sends a proof of state verification failure back to a data requester node; the data requester node replaces an attribute verification matrix ciphertext corresponding to the revocation sub-strategy in the nested ciphertext structure with a full-zero string according to the proof, stops performing linear operation and discards an intermediate decryption key component, and truncates a decryption path of a second layer ciphertext component to a first layer ciphertext component. The present application maps the attribute revocation state to a blocking operation of a decryption path in the ciphertext, and eliminates attribute revocation delay and underlying ciphertext vulnerabilities.

Description

Technical Field

[0001] This invention relates to the fields of computer security devices and blockchain technology, and discloses a blockchain-based method for trusted sharing and secure management of talent data. Background Technology

[0002] In blockchain-based talent data sharing technology, data owners typically use attribute-based encryption algorithms to encrypt talent data and publish their access policies to the blockchain. When it's necessary to revoke attribute permissions for a node, existing conventional solutions employ two approaches. One approach involves the data owner continuously monitoring the revocation list on the blockchain. Upon discovering that a specific attribute has been revoked, a new access policy is generated, and the talent data is re-encrypted using the new policy. The resulting ciphertext is then uploaded to an off-chain storage system to overwrite the original ciphertext. The other approach involves maintaining an attribute blacklist in a smart contract. When a data requester initiates a decryption request, the smart contract compares the requester's attribute set with the blacklist. If the requester's attribute is determined to be on the blacklist, the smart contract refuses to issue the decryption key.

[0003] The core technical problem with the aforementioned conventional solutions is that attribute revocation cannot be applied to the underlying ciphertext structure immediately and forcefully. Using re-encryption by the data owner introduces a time lag between the revocation event and the generation of the new ciphertext, and the re-encryption process consumes significant computational resources. During this time lag, the original ciphertext can still be decrypted normally. Using smart contracts to maintain a blacklist represents application-level interception; the underlying cryptographic structure of the ciphertext remains unchanged due to attribute revocation. If the data requester bypasses the smart contract's verification logic and directly obtains the off-chain ciphertext, the ciphertext still retains the decryption components corresponding to the revoked attributes, making it vulnerable to unauthorized parsing of plaintext data. Summary of the Invention

[0004] The purpose of this invention is to provide a blockchain-based method for trusted sharing and secure management of talent data, which can effectively solve the problems mentioned in the background.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A blockchain-based method for trusted sharing and secure management of talent data includes: extracting multi-dimensional attribute tags from talent data by the data owner node, generating a nested ciphertext structure containing a main access policy and a revocation sub-policy, storing the nested ciphertext structure in an off-chain distributed storage system, and submitting the hash value of the main access policy and the root of the attribute set to the blockchain. When an attribute revocation event occurs, the smart contract receives the revocation request, updates the global attribute state tree, and broadcasts the updated attribute set root to all nodes in the network. The data requesting node obtains the nested ciphertext structure and generates a decryption request based on the currently valid attribute set. When the smart contract verifies the matching relationship between the attribute set in the decryption request and the global attribute state tree, if it detects that the attribute set contains a revoked attribute, it sends back proof of state verification failure to the off-chain. The data requesting node, based on the proof of the failed state verification, locally truncates the decryption path corresponding to the revocation sub-policy in the nested ciphertext structure, so that the nested ciphertext structure cannot be parsed to extract plaintext talent data.

[0006] Preferably, the generation of the nested ciphertext structure containing the main access policy and the revocation sub-policy includes: The data owner node divides the multi-dimensional attribute labels into core attribute labels and edge attribute labels, uses the core attribute labels to construct the access control tree corresponding to the main access policy, and uses the edge attribute labels to construct the attribute verification matrix corresponding to the revocation sub-policy. The plaintext of the talent data is encrypted using an attribute-based encryption algorithm to generate a first-layer ciphertext component corresponding to the main access policy. The decryption key corresponding to the first-layer ciphertext component is encrypted using a symmetric encryption algorithm. The second-layer ciphertext component corresponding to the revocation sub-policy is generated by combining the attribute verification matrix. The first-layer ciphertext component is concatenated with the second-layer ciphertext component, and a pointer to the first-layer ciphertext component is added to the header of the second-layer ciphertext component to generate the nested ciphertext structure.

[0007] Preferably, updating the global attribute state tree includes: The smart contract parses the target revocation attribute identifier carried in the revocation request and locates the leaf node corresponding to the target revocation attribute identifier in the locally maintained global attribute state tree; The smart contract modifies the attribute status value stored in the leaf node from a valid state to a revoked state, and recalculates the hash value of the leaf node based on the revoked state. The smart contract updates the hash values ​​of all parent nodes on the path from the leaf node to the root node layer by layer from bottom to top based on the recalculated leaf node hash value, until a new root node hash value is calculated, and the new root node hash value is used as the root of the updated attribute set.

[0008] Preferably, verifying the matching relationship between the attribute set in the decryption request and the global attribute state tree includes: The smart contract extracts the current valid attribute set of the data requester node and the corresponding Merkel proof path carried in the decryption request; The smart contract determines the corresponding set of leaf nodes in the global attribute state tree based on the current valid attribute set, and calculates the first verification hash value from the leaf node set to the root node from bottom to top using the hash values ​​of adjacent sibling nodes contained in the Merkel proof path. The smart contract compares the first verification hash value with the updated attribute set root stored on the blockchain. If the first verification hash value is inconsistent with the updated attribute set root, it is determined that the current valid attribute set contains revoked attributes.

[0009] Preferably, the proof of failure to send back the state verification to the chain includes: When the smart contract determines that the current valid attribute set contains a revoked attribute, it extracts the conflict leaf node identifier corresponding to the revoked attribute in the global attribute state tree. The smart contract obtains the hash values ​​of all parent nodes and branch direction identifiers on the path from the conflicting leaf node to the root node, and combines and packages the conflicting leaf node identifiers, the parent node hash values, the branch direction identifiers, and the digital signature of the smart contract to generate the proof of the state verification failure. The smart contract sends the proof of the failed state verification to the data requester node that initiated the decryption request via the transaction receipt field of the blockchain.

[0010] Preferably, the step of locally truncating the decryption path corresponding to the revocation sub-policy in the nested ciphertext structure based on the proof of the state verification failure includes: The data requesting node parses the proof of the status verification failure and extracts the identifier of the conflicting leaf node; The data requesting node locates the row and column of the attribute verification matrix in the revocation sub-policy corresponding to the conflicting leaf node identifier in the locally cached nested ciphertext structure; The data requesting node replaces the ciphertext fragments stored in the rows and columns of the attribute verification matrix with all-zero strings, stops performing linear operations on the attribute verification matrix, and discards the generated intermediate decryption key components, thus blocking the process of transmitting the key from the second-layer ciphertext component corresponding to the revocation sub-policy to the first-layer ciphertext component.

[0011] Preferably, the component for generating the second-layer ciphertext corresponding to the revocation sub-policy further includes: The data owner node introduces a proxy re-encryption key to perform layered encapsulation of the key for the symmetric encryption algorithm; The data owner node divides the proxy re-encryption key into key fragments equal to the number of edge attribute labels, and embeds the key fragments into each leaf node of the attribute verification matrix. When generating the second-layer ciphertext component, the data owner node uses the attribute verification matrix to perform matrix multiplication on the combined ciphertext carrying the key fragments, and encapsulates the operation result into a second-layer ciphertext component with a hierarchical structure, so that the decryption process of the second-layer ciphertext component depends on the complete extraction and combination of all the key fragments.

[0012] Preferably, the step of changing the attribute status value stored in the leaf node from a valid state to a revoked state further includes: Before modifying the attribute state value, the smart contract obtains the timestamp of the latest block on the blockchain; The smart contract concatenates the timestamp of the latest block with the node identifier of the leaf node to generate a timestamp status identifier; The smart contract uses a hash function to calculate the timestamp status identifier, and writes the calculated hash digest as the revocation status into the leaf node, overwriting the original valid status value in the leaf node, so that the leaf node forms a status change record with a time dimension in the global attribute state tree.

[0013] Preferably, the step of calculating the first verification hash value from the leaf node set to the root node from bottom to top using the hash values ​​of adjacent sibling nodes contained in the Merkel proof path further includes: During the hash value calculation process, the smart contract extracts the hash values ​​of adjacent sibling nodes at each level in the Merkel proof path and performs an XOR operation between the hash values ​​of the adjacent sibling nodes and the hash value of the node at the current level. After each XOR operation, the smart contract performs a bitwise AND operation with the result and a confusion factor generated by a preset random number generator. The result of the bitwise AND operation is used as the input node hash value for the next level of calculation, until the first verification hash value is output at the root node level.

[0014] Preferably, after discarding the generated intermediate decryption key component and blocking the process of transmitting the key from the second-layer ciphertext component corresponding to the revocation sub-policy to the first-layer ciphertext component, the method further includes: The data requesting node establishes a process control block in memory for the decryption task of the nested ciphertext structure. The data requesting node marks the decryption status of the second-layer ciphertext component recorded in the decryption task process control block as abnormal termination, and clears the memory space allocated to the attribute verification matrix in the decryption task process control block. Based on the abnormal termination status, the data requesting node sends an abnormal termination notification containing the identifier of the conflicting leaf node to the data owning node, and deletes the first-layer ciphertext component and the second-layer ciphertext component in the nested ciphertext structure stored locally.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention constructs a nested ciphertext structure containing a main access policy and a revocation sub-policy, mapping the attribute revocation state to a physical blocking operation of the decryption path within the ciphertext. After the smart contract updates the global attribute state tree and issues a proof of state verification failure, the data requesting node replaces the ciphertext fragment of the attribute verification matrix in the revocation sub-policy with a string of all zeros based on the proof, stops executing linear operations, and discards intermediate decryption key components, directly truncating the process of the second-layer ciphertext component transmitting the key to the first-layer ciphertext component. This mechanism ensures that the underlying nested ciphertext structure loses its decryption possibility the instant the attribute is revoked, eliminating the time delay of attribute revocation and the vulnerability of the underlying ciphertext.

[0016] 2. When updating the global attribute state tree, this invention recalculates the hash values ​​of all parent nodes on the path from the leaf node to the root node layer by layer from bottom to top. It then compares the hash values ​​of adjacent sibling nodes in the Merkel proof path layer by layer, ensuring the immutability of attribute state changes throughout the network and the determinism of verification results. By dividing the proxy re-encryption key into multiple key fragments and embedding them into each leaf node of the attribute verification matrix, the decryption process is forced to rely on the complete extraction of all key fragments. After the decryption path is truncated, the memory space allocated to the attribute verification matrix in the decryption task process control block is cleared, and the local ciphertext component is deleted, eliminating the possibility of key leakage after the reversal operation. Attached Figure Description

[0017] Figure 1 This is the main flowchart of the present invention; Figure 2 This is a flowchart illustrating the process of generating the nested ciphertext structure according to the present invention. Figure 3 This is a flowchart of the global attribute state tree update process of the present invention; Figure 4 This is a flowchart illustrating the verification process for the matching relationship between the attribute set and the state tree in this invention. Figure 5 This is a flowchart illustrating the generation and distribution of status verification failure proofs for this invention. Figure 6 This is a flowchart of the decryption path truncation and exception handling process of the present invention. Detailed Implementation

[0018] Please refer to the attached document. Figure 1This embodiment provides a blockchain-based method for trusted sharing and secure management of talent data. This method is applied to talent data sharing scenarios under a consortium blockchain architecture. The consortium blockchain nodes include talent data owner nodes, talent data requester nodes, blockchain consensus nodes, and smart contract execution nodes. The off-chain distributed storage system is a decentralized storage cluster that complements the blockchain network. Each storage node maintains a complete encrypted copy, and all nodes follow a unified cryptographic algorithm specification and data interaction protocol.

[0019] The data-owning node performs structured parsing of talent data, which includes structured and unstructured data with clear business meaning, such as personal basic qualification data, professional experience data, professional skills certification data, project performance data, and credit rating data. The data-owning node extracts multi-dimensional attribute tags from the parsed talent data. Each attribute tag corresponds to a unique attribute identifier, attribute name, attribute value range, and attribute status bit. The attribute identifier is generated using globally unified coding rules to ensure its uniqueness throughout the entire blockchain network.

[0020] Based on the extracted multi-dimensional attribute tags, the data owner node generates a nested ciphertext structure containing a main access policy and revocation sub-policies. The main access policy is a set of policies used to control the core access permissions of talent data, and the revocation sub-policies are a set of policies used to control the decryption path after attribute status changes. The nested ciphertext structure is a cryptographic structure with a two-level nested relationship. The main access policy corresponds to the access control logic of the outer ciphertext, and the revocation sub-policies correspond to the permission verification logic of the inner ciphertext. The two-level structure is uniquely associated through address pointers with a fixed format.

[0021] The data-owning node stores the generated nested ciphertext structure in an off-chain distributed storage system. After storage, it obtains the content addressing identifier corresponding to the ciphertext. The content addressing identifier is generated based on the hash value of the ciphertext content and has content uniqueness and immutability. The data-owning node submits the hash value of the main access strategy and the root of the attribute set, along with the content addressing identifier, to the blockchain network and writes them into the transaction data field of the block, thus completing the on-chain storage of the data.

[0022] When an attribute revocation event occurs, such as attribute permission revocation initiated by the data owner node, automatic status change triggered by the expiration of the attribute validity period, or status adjustment of non-compliant attributes initiated by the regulatory node, the smart contract receives the revocation request sent by the triggering node. The revocation request is digitally signed by the triggering node using its own private key and sent to the blockchain network. The revocation request carries the target revocation attribute identifier, the revocation initiator identifier, the reason for revocation, and the digital signature.

[0023] Upon receiving a revocation request, the smart contract first verifies the initiator's signature validity and operational permissions. If verification is successful, it updates the locally maintained global attribute state tree. This tree is a Merkle tree-based attribute state management tree, where each leaf node corresponds to a unique attribute identifier. Leaf nodes store the state value of the corresponding attribute, while non-leaf nodes store the hash value of the concatenated hash values ​​of their child nodes. The root node stores the hash value of the attribute set root. After updating the global attribute state tree, the smart contract writes the updated attribute set root into the blockchain's world state and broadcasts it to all nodes in the network via the blockchain's peer-to-peer network. Upon receiving the broadcast, all nodes synchronously update their locally maintained copies of the global attribute state tree, ensuring that the attribute states of all nodes in the network remain consistent.

[0024] When a data requesting node needs to obtain plaintext talent data, it first obtains the content addressing identifier corresponding to the nested ciphertext structure through the blockchain's transaction query interface. Based on the content addressing identifier, it retrieves the complete nested ciphertext structure from the off-chain distributed storage system. At the same time, it obtains a synchronized copy of the latest attribute set root and the global attribute state tree from the blockchain. Based on its own valid attribute set, it generates a decryption request. The decryption request carries the data requesting node's digital signature, the current valid attribute set, the Merkel proof path of the corresponding attribute set, and the unique identifier of the nested ciphertext structure.

[0025] The data requesting node sends a decryption request to the blockchain network, where a smart contract deployed on the blockchain executes the verification logic for the decryption request. Upon receiving the decryption request, the smart contract first verifies the validity of the data requesting node's signature, then extracts the attribute set from the decryption request and performs a matching verification against the locally maintained global attribute state tree. The core of this matching verification is checking whether the current state of each attribute in the attribute set is valid in the global attribute state tree. If, during the verification process, the smart contract detects that the attribute set contains at least one attribute with a revoked state, it terminates the subsequent verification process and sends a proof of state verification failure back to the data requesting node that initiated the decryption request off-chain.

[0026] Upon receiving proof of failed state verification from the smart contract, the data requesting node locally performs a decryption path truncation operation on the nested ciphertext structure. First, the data requesting node verifies the signature validity of the proof of failed state verification. If the verification passes, it parses the identifier information corresponding to the revoked attribute carried in the proof. Based on this identifier information, it locates the decryption path node corresponding to the revocation sub-policy within the locally obtained nested ciphertext structure. It then irreversibly modifies the ciphertext component corresponding to this decryption path node, truncating the decryption path corresponding to the revocation sub-policy. This prevents the decryption process of the nested ciphertext structure from completing key transmission and restoration, ultimately making it impossible to decipher the plaintext talent data.

[0027] In this embodiment, by constructing a nested ciphertext structure, synchronizing all nodes of the global attribute state tree, performing on-chain verification of decryption requests, and truncating the decryption path locally, the direct binding of attribute state change events with the ciphertext structure decryption capability is achieved, completing all the core technical processes corresponding to this method.

[0028] Table 1. Relationship between multi-dimensional attribute labels and strategy mapping of talent data.

[0029] This table clarifies the classification rules and policy types of multi-dimensional attribute tags, providing a structured attribute foundation for the construction of main access policies and revocation sub-policies. It ensures that each attribute tag corresponds to a unique policy control logic, providing a corresponding location basis for decryption path control after subsequent attribute status changes.

[0030] refer to Figure 2 In one optional embodiment, after extracting multi-dimensional attribute tags, the data owner node classifies the attribute tags into core attribute tags and edge attribute tags. Core attribute tags are fixed attribute tags used to determine whether the data requester has basic access permissions. The attribute status of these tags does not change frequently during the lifecycle of the talent data. Edge attribute tags are variable attribute tags used to implement dynamic permission control. The attribute status of these tags can be adjusted according to changes in the business scenario.

[0031] The data owner node constructs an access control tree corresponding to the main access policy using the partitioned core attribute labels. The access control tree is constructed using a threshold structure, where each non-leaf node is a threshold node, including AND gates, OR gates, etc. Threshold gates, each leaf node corresponds to a core attribute label, and the root node of the access control tree corresponds to the final authorization result of the main access policy. Only when the attribute set held by the data requesting node satisfies the threshold logic of the access control tree does it have the basic permission to obtain the decryption key of the first-level ciphertext component. For the AND gate node, its threshold logic mathematical expression is: ; in, For the first The state of the core attribute tags corresponding to each leaf node, with a value of 1 indicating that the attribute is satisfied and a value of 0 indicating that the attribute is not satisfied. The output of the AND gate node takes a value of 1 to indicate that the threshold logic is satisfied, and a value of 0 to indicate that the threshold logic is not satisfied. For the OR gate node, the mathematical expression for its threshold logic is: ; against The threshold gate node, whose threshold logic mathematical expression is: ; in, For threshold value, This represents the total number of child nodes corresponding to the threshold node.

[0032] The data owner node uses the partitioned edge attribute labels to construct the attribute verification matrix corresponding to the revocation sub-policy. The attribute verification matrix is ​​as follows: OK A binary matrix of columns, where The total number of edge attribute tags. The number of columns in the linear secret sharing scheme for revoking the sub-strategy is given. Each row of the matrix corresponds to an edge attribute label. The elements of the matrix take values ​​of 0 or 1, which are used to characterize the weight coefficient of the corresponding edge attribute label in the secret sharing process. The secret can only be restored when the matrix row vectors corresponding to the valid edge attribute set held by the data requesting node can span the target vector of the matrix.

[0033] The data owner node encrypts the plaintext talent data using a ciphertext policy attribute-based encryption algorithm, generating a first-layer ciphertext component corresponding to the main access policy. During encryption, the access control tree corresponding to the main access policy is embedded into the ciphertext structure. The input parameters for encryption include the plaintext talent data, system public parameters, and the access control tree corresponding to the main access policy. The output is the first-layer ciphertext component, which contains the ciphertext body, an access control tree structure description, and a public parameter index. The mathematical expression for its encryption process is as follows: ; in, For the first layer of ciphertext components, These are common system parameters. For plain text talent data, The access control tree corresponding to the primary access policy. This is the encryption function for the ciphertext policy attribute-based encryption algorithm.

[0034] The data owner node uses an Advanced Encryption Standard (AES) algorithm to encrypt the decryption key corresponding to the first-layer ciphertext component. Combined with the attribute verification matrix, it generates the second-layer ciphertext component corresponding to the revocation sub-policy. The input parameters for encryption include the decryption key of the first-layer ciphertext component and the symmetric encryption key. The output is the symmetrically encrypted key ciphertext. This symmetrically encrypted key ciphertext is then bound to the attribute verification matrix to generate the second-layer ciphertext component. The second-layer ciphertext component contains the symmetric key ciphertext, the attribute verification matrix, and the mapping relationship between edge attribute labels and matrix rows. The mathematical expression for its symmetric encryption process is as follows: ; in, The ciphertext is the key after symmetric encryption. For symmetric encryption keys, This is the decryption key corresponding to the first-layer ciphertext component. This refers to the encryption function of the Advanced Encryption Standard (AES) algorithm.

[0035] The data owner node concatenates the first-layer ciphertext component with the second-layer ciphertext component and adds a pointer to the first-layer ciphertext component at the head of the second-layer ciphertext component, generating a nested ciphertext structure. The pointer is a fixed-length addressing identifier used to establish the association between the symmetric key recovered from the second-layer ciphertext component and the decryption process of the first-layer ciphertext component during the decryption process. The storage order of the nested ciphertext structure is: the second-layer ciphertext component header pointer, the second-layer ciphertext component body, and the first-layer ciphertext component body. This ensures that the decryption process must complete the decryption of the second-layer ciphertext component first, and only after obtaining the symmetric key can the decryption process of the first-layer ciphertext component be executed.

[0036] The data owner node introduces a proxy re-encryption key to perform layered encapsulation of the symmetric encryption algorithm key. This proxy re-encryption key is generated using a bilinear mapping-based algorithm and includes a public key and a private key. The public key is used for encryption encapsulation, and the private key is used for re-encryption transformation. The data owner node divides the proxy re-encryption key into key fragments equal to the number of edge attribute labels. This division process uses a secret-sharing algorithm to ensure that the complete proxy re-encryption key can only be reconstructed after obtaining all key fragments. These key fragments are then embedded into the leaf nodes of the attribute verification matrix, with each leaf node corresponding to an edge attribute label and a unique key fragment.

[0037] When generating the second-layer ciphertext component, the data owner node uses the attribute verification matrix to perform matrix multiplication on the combined ciphertext carrying the key fragments. The result is encapsulated into a hierarchical second-layer ciphertext component, making the decryption process of the second-layer ciphertext component dependent on the complete extraction and combination of all key fragments. The mathematical expression for its matrix operation process is as follows: ; in, This is the core computation result of the second-layer ciphertext component. For attribute validation matrix, It is a column vector composed of key fragments. This is the matrix multiplication operator.

[0038] In this embodiment, by classifying and dividing core attribute tags and edge attribute tags, an access control tree corresponding to the main access policy and an attribute verification matrix corresponding to the revocation sub-policy are constructed. This completes the generation of a two-layer nested ciphertext structure and the fragmented embedding of the proxy re-encryption key, realizing the hierarchical management of main access permissions and dynamic revocation permissions, and fully covering all the detailed technical features corresponding to the generation of nested ciphertext structures.

[0039] Table 2 Attribute Verification Matrix Structure and Key Sharding Mapping Table

[0040] This table clarifies the correspondence between the row vectors of the attribute verification matrix and the edge attribute labels and key fragments, providing the corresponding positioning basis for the generation of the second-layer ciphertext components and the truncation of the decryption path, and ensuring that the state change operation of each edge attribute can directly correspond to the specified row vector of the matrix.

[0041] refer to Figure 3 In one optional embodiment, after receiving a valid revocation request, the smart contract executes an update operation on the global attribute state tree. The smart contract first parses the target revocation attribute identifier carried in the revocation request. This target revocation attribute identifier is a globally unique string encoding that corresponds to a leaf node in the global attribute state tree. The smart contract locates the leaf node corresponding to the target revocation attribute identifier in the locally maintained global attribute state tree through the index mapping relationship of the attribute identifiers. The global attribute state tree is constructed using a binary Merkle tree structure, and the tree depth is dynamically adjusted according to the total number of attributes. Each leaf node stores the attribute identifier, attribute state value, and node hash value. Each non-leaf node stores the hash values ​​of its left and right children, and the current node hash value. The current node hash value is the result of concatenating the hash values ​​of its left and right children and then calculating it using a hash function.

[0042] Before modifying attribute state values, the smart contract obtains the timestamp of the latest block on the blockchain. The timestamp of the latest block is the block time when it was confirmed and packaged by consensus nodes, ensuring network-wide consistency and immutability. The smart contract concatenates the timestamp of the latest block with the node identifier of the leaf node to generate a timestamp state identifier. The concatenation uses a fixed-length prefix encoding method to ensure that the concatenated string has a unique parsing format. The smart contract uses a secure hash algorithm to calculate the timestamp state identifier and writes the calculated hash digest as the reversal state into the leaf node, overwriting the original valid state value in the leaf node. This creates a time-dimensional state change record for the leaf node in the global attribute state tree. The mathematical expression for its hash calculation process is: ; in, This is the hash digest corresponding to the revocation state. For a secure hash algorithm, The timestamp of the latest block on the blockchain. This is the node identifier for the leaf node. This is a string concatenation operator.

[0043] The smart contract recalculates the hash value of the leaf node based on the revocation state. The hash value of the leaf node is the result of concatenating the attribute identifier stored in the leaf node, the new attribute state value, and the node identifier, and then calculating it using a hash function. The mathematical expression for this calculation process is as follows: ; in, The recalculated hash value of the leaf node. Remove the attribute identifier from the target.

[0044] The smart contract updates the hash values ​​of all parent nodes along the path from the leaf node to the root node, layer by layer, from bottom to top, based on the recalculated hash values ​​of the leaf nodes, until a new root node hash value is calculated. This new root node hash value is then used as the root of the updated attribute set. The smart contract first locates the parent node of a leaf node, replaces the hash values ​​of the corresponding child nodes in that parent node with the recalculated leaf node hash value, then calculates the new hash value of the parent node, and repeats this process, updating the grandparent nodes, great-grandparent nodes, and so on, until the root node is reached, completing the update of the root node hash value. The mathematical expression for the parent node hash value update process is: ; in, This is the updated hash value of the parent node. The hash value of the left child node of the parent node. This is the hash value of the right child node of the parent node.

[0045] After receiving a decryption request from a data requesting node, the smart contract performs a verification of the matching relationship between the attribute set and the global attribute state tree. The smart contract first extracts the current valid attribute set of the data requesting node carried in the decryption request and the corresponding Merkle proof path. The Merkle proof path is the set of hash values ​​and branch direction identifiers of all adjacent sibling nodes along the path from the leaf node corresponding to the current valid attribute set to the root node of the global attribute state tree. The branch direction identifier indicates whether the current node is the left or right child of its parent node.

[0046] The smart contract determines the corresponding set of leaf nodes in the global attribute state tree based on the current valid attribute set. Using the hash values ​​of adjacent sibling nodes included in the Merkel proof path, it calculates the first verification hash value from the leaf node set to the root node from the bottom up. During the hash value calculation process, the smart contract extracts the hash values ​​of adjacent sibling nodes at each level of the Merkel proof path and performs an XOR operation between the hash values ​​of adjacent sibling nodes and the hash value of the node at the current level. The mathematical expression for this operation is: ; in, This is the temporary result of the XOR operation. This is the hash value of the node at the current level. The hash value of the adjacent sibling node. This is the bitwise XOR operator.

[0047] After each XOR operation, the smart contract performs a bitwise AND operation with the result and a confusion factor generated by a preset random number generator. The result of the bitwise AND operation is used as the input hash value for the next level of calculation, until the first verification hash value is output at the root node level. The mathematical expression for this calculation process is as follows: ; in, The hash value of the input node for the next level of calculation. The confusion factor generated by the preset random number generator. This is the bitwise AND operator.

[0048] The smart contract compares the first verification hash value with the updated attribute set root stored on the blockchain. If the first verification hash value is inconsistent with the updated attribute set root, it is determined that the current valid attribute set contains attributes in the revoked state, and the verification process is terminated.

[0049] In this embodiment, the immutability of attribute state changes and the determinism of decryption request attribute verification are achieved through timestamped attribute state modification, bottom-up hash update of the global attribute state tree, layer-by-layer verification of Merkel proof path and hash operation with confusion factor, which fully covers all the detailed technical features corresponding to global attribute state tree update and attribute verification.

[0050] Table 3 Global Attribute State Tree Node Structure and State Change Record Table

[0051] This table records the process of node hash value changes in the global attribute state tree after an attribute revocation event is triggered, clearly defining the entire path update trajectory from the leaf node to the root node, and providing data support for the traceability of attribute state changes and the determinism of verification logic.

[0052] refer to Figure 4 and 5 In one optional embodiment, when the smart contract determines that the current valid attribute set contains attributes with a revoked state, it generates and issues a proof of state verification failure. The smart contract first extracts the conflicting leaf node identifiers corresponding to the revoked attributes in the global attribute state tree. The conflicting leaf node identifiers are globally unique node codes of the leaf nodes corresponding to the revoked attributes, and have a corresponding mapping relationship with the row vectors in the attribute verification matrix.

[0053] The smart contract retrieves the hash values ​​of all parent nodes and branch direction identifiers along the path from the conflicting leaf node to the root node. The branch direction identifier uses single-bit encoding: 0 indicates the current node is the left child of its parent node, and 1 indicates the current node is the right child. The parent node hash values ​​along the path are arranged in order from the leaf node to the root node, forming a continuous hash value sequence. The smart contract combines the conflicting leaf node identifiers, the parent node hash value sequence, the branch direction identifier sequence, and the smart contract's digital signature into a package to generate a proof of state verification failure. The smart contract's digital signature is generated using an asymmetric encryption algorithm based on blockchain network consensus, ensuring the proof's unforgeability and legitimacy.

[0054] The smart contract sends proof of the failed state verification to the data requester node that initiated the decryption request through the transaction receipt field of the blockchain. The transaction receipt field is a fixed field used to return the execution result to the transaction initiator after the blockchain transaction is executed. The content of this field will be synchronized to all nodes in the network and has traceability and immutability.

[0055] Upon receiving proof of failed state verification, the data requesting node first verifies the legality of the smart contract's digital signature in the proof. If the verification passes, it parses the proof of failed state verification and extracts the conflicting leaf node identifier. Within a locally cached nested encrypted structure, the data requesting node uses a pre-defined mapping table to locate the row and column of the attribute verification matrix in the revocation sub-policy corresponding to the conflicting leaf node identifier. This mapping table stores the correspondence between leaf node identifiers of the global attribute state tree and row numbers of the attribute verification matrix, ensuring the uniqueness and accuracy of the location result.

[0056] The data requesting node replaces the ciphertext fragments stored in the rows and columns of the attribute verification matrix with all-zero strings. The length of the all-zero strings is exactly the same as the length of the original ciphertext fragments, ensuring that the matrix dimensions do not change after the replacement and preventing the decryption process from continuing due to error handling logic triggered by dimension anomalies. The data requesting node stops executing linear operations on the attribute verification matrix. Linear operations are linear combination operations of matrix row vectors required to restore the symmetric key in the second-layer ciphertext component. The execution of this operation depends on the integrity of the ciphertext fragments corresponding to all rows in the attribute verification matrix. After replacing them with all-zero strings, the output of the linear operations cannot meet the conditions for secret restoration.

[0057] The data requesting node discards the generated intermediate decryption key component, which is the result of combining fragments of the temporary key generated during the linear operation. The discarding operation is implemented using an irreversible memory overwrite method, blocking the process of transmitting the key from the second-level ciphertext component corresponding to the revocation sub-policy to the first-level ciphertext component. The mathematical expression for its key restoration process is as follows: ; in, The restored symmetric key. The coefficients are linear combination coefficients. For the attribute validation matrix, the first The row vector of a row. For the first The corresponding ciphertext fragments of the line, This is the summation operator.

[0058] When the When the ciphertext fragment corresponding to the line is replaced with an all-zero string, At this point, the key decryption operation expression becomes: ; Because the design of the attribute verification matrix requires the participation of all row vectors to span the target vector, the missing first row vector... After the contribution of the line, the calculation result cannot restore the correct symmetric key.

[0059] After blocking the key transmission process, the data requesting node establishes a process control block in memory for the decryption task of the nested ciphertext structure. The process control block is a fixed data structure in the operating system kernel used to manage the decryption task process, storing core data such as the process status of the decryption task, memory allocation information, file handle, register context, etc.

[0060] The data requesting node marks the decryption status of the second-layer ciphertext component recorded in the decryption task process control block as abnormally terminated. The abnormal termination status is a preset process status code used to indicate that the decryption task cannot continue execution due to permission verification failure. The data requesting node clears the memory space allocated to the attribute verification matrix in the decryption task process control block. The clearing operation is implemented by overwriting all zeros byte by byte to ensure that there is no residual data of the attribute verification matrix and intermediate decryption key components in memory.

[0061] Based on the abnormal termination status, the data requesting node sends an abnormal termination notification containing the identifier of the conflicting leaf node to the data owning node. The abnormal termination notification is transmitted through an encrypted channel to ensure the security of the notification content. The data requesting node deletes the first-level and second-level ciphertext components from the nested ciphertext structure stored locally. The deletion operation is implemented using an irreversible file overwrite method, overwriting all storage sectors of the original ciphertext file to prevent the ciphertext components from being illegally recovered.

[0062] In this embodiment, please refer to the appendix. Figure 6 By generating and validating the proof of failure of state verification, replacing all zeros in the corresponding rows and columns of the attribute verification matrix, terminating the decryption linear operation, discarding the intermediate key components, modifying the state of the decryption process control block and clearing memory, and irreversibly deleting the local ciphertext components, the system achieves the forced blocking of the decryption path and the thorough cleaning of sensitive data after the attribute state changes. It fully covers all the detailed technical features corresponding to the decryption path truncation and subsequent data processing.

[0063] Table 4. Field Structure and Verification Logic Table for Status Verification Failure Proof

[0064] This table is used to clarify the field composition and corresponding verification logic of the status verification failure proof, ensuring that the data requesting node can verify the legality and integrity of the proof, and providing a legal basis for the subsequent decryption path truncation operation.

Claims

1. A blockchain-based method for trusted sharing and secure management of talent data, characterized in that, include: The data owner node extracts multi-dimensional attribute tags from talent data, generates a nested ciphertext structure containing a main access strategy and a revocation sub-strategy, stores the nested ciphertext structure in an off-chain distributed storage system, and submits the hash value of the main access strategy and the root of the attribute set to the blockchain. When an attribute revocation event occurs, the smart contract receives the revocation request, updates the global attribute state tree, and broadcasts the updated attribute set root to all nodes in the network. The data requesting node obtains the nested ciphertext structure and generates a decryption request based on the currently valid attribute set. When the smart contract verifies the matching relationship between the attribute set in the decryption request and the global attribute state tree, if it detects that the attribute set contains a revoked attribute, it sends back proof of state verification failure to the off-chain. The data requesting node, based on the proof of the failed state verification, locally truncates the decryption path corresponding to the revocation sub-policy in the nested ciphertext structure, so that the nested ciphertext structure cannot be parsed to extract plaintext talent data.

2. The blockchain-based method for trusted sharing and secure management of talent data according to claim 1, characterized in that, The generation of a nested ciphertext structure containing a main access policy and a revocation sub-policy includes: The data owner node divides the multi-dimensional attribute labels into core attribute labels and edge attribute labels, uses the core attribute labels to construct the access control tree corresponding to the main access policy, and uses the edge attribute labels to construct the attribute verification matrix corresponding to the revocation sub-policy. The plaintext of the talent data is encrypted using an attribute-based encryption algorithm to generate a first-layer ciphertext component corresponding to the main access policy. The decryption key corresponding to the first-layer ciphertext component is encrypted using a symmetric encryption algorithm. The second-layer ciphertext component corresponding to the revocation sub-policy is generated by combining the attribute verification matrix. The first-layer ciphertext component is concatenated with the second-layer ciphertext component, and a pointer to the first-layer ciphertext component is added to the header of the second-layer ciphertext component to generate the nested ciphertext structure.

3. The blockchain-based trusted sharing and security management method for talent data as described in claim 1, characterized in that, The update of the global attribute state tree includes: The smart contract parses the target revocation attribute identifier carried in the revocation request and locates the leaf node corresponding to the target revocation attribute identifier in the locally maintained global attribute state tree; The smart contract modifies the attribute status value stored in the leaf node from a valid state to a revoked state, and recalculates the hash value of the leaf node based on the revoked state. The smart contract updates the hash values ​​of all parent nodes on the path from the leaf node to the root node layer by layer from bottom to top based on the recalculated leaf node hash value, until a new root node hash value is calculated, and the new root node hash value is used as the root of the updated attribute set.

4. The blockchain-based trusted sharing and secure management method for talent data as described in claim 1, characterized in that, The verification of the matching relationship between the attribute set in the decryption request and the global attribute state tree includes: The smart contract extracts the current valid attribute set of the data requester node and the corresponding Merkel proof path carried in the decryption request; The smart contract determines the corresponding set of leaf nodes in the global attribute state tree based on the current valid attribute set, and calculates the first verification hash value from the leaf node set to the root node from bottom to top using the hash values ​​of adjacent sibling nodes contained in the Merkel proof path. The smart contract compares the first verification hash value with the updated attribute set root stored on the blockchain. If the first verification hash value is inconsistent with the updated attribute set root, it is determined that the current valid attribute set contains revoked attributes.

5. The blockchain-based trusted sharing and secure management method for talent data according to claim 1, characterized in that, The proof of failure to send back the state verification to the chain includes: When the smart contract determines that the current valid attribute set contains a revoked attribute, it extracts the conflict leaf node identifier corresponding to the revoked attribute in the global attribute state tree. The smart contract obtains the hash values ​​of all parent nodes and branch direction identifiers on the path from the conflicting leaf node to the root node, and combines and packages the conflicting leaf node identifiers, the parent node hash values, the branch direction identifiers, and the digital signature of the smart contract to generate the proof of the state verification failure. The smart contract sends the proof of the failed state verification to the data requester node that initiated the decryption request via the transaction receipt field of the blockchain.

6. The blockchain-based trusted sharing and secure management method for talent data according to claim 5, characterized in that, The step of locally truncating the decryption path corresponding to the revocation sub-policy in the nested ciphertext structure based on the proof of the failure of the state verification includes: The data requesting node parses the proof of the status verification failure and extracts the identifier of the conflicting leaf node; The data requesting node locates the row and column of the attribute verification matrix in the revocation sub-policy corresponding to the conflicting leaf node identifier in the locally cached nested ciphertext structure; The data requesting node replaces the ciphertext fragments stored in the rows and columns of the attribute verification matrix with all-zero strings, stops performing linear operations on the attribute verification matrix, and discards the generated intermediate decryption key components, thus blocking the process of transmitting the key from the second-layer ciphertext component corresponding to the revocation sub-policy to the first-layer ciphertext component.

7. The blockchain-based trusted sharing and security management method for talent data as described in claim 2, characterized in that, The second-layer ciphertext component for generating the revocation sub-policy further includes: The data owner node introduces a proxy re-encryption key to perform layered encapsulation of the key for the symmetric encryption algorithm; The data owner node divides the proxy re-encryption key into key fragments equal to the number of edge attribute labels, and embeds the key fragments into each leaf node of the attribute verification matrix. When generating the second-layer ciphertext component, the data owner node uses the attribute verification matrix to perform matrix multiplication on the combined ciphertext carrying the key fragments, and encapsulates the operation result into a second-layer ciphertext component with a hierarchical structure, so that the decryption process of the second-layer ciphertext component depends on the complete extraction and combination of all the key fragments.

8. The blockchain-based method for trusted sharing and secure management of talent data according to claim 3, characterized in that, The step of changing the attribute status value stored in the leaf node from a valid state to a revoked state also includes: Before modifying the attribute state value, the smart contract obtains the timestamp of the latest block on the blockchain; The smart contract concatenates the timestamp of the latest block with the node identifier of the leaf node to generate a timestamp status identifier; The smart contract uses a hash function to calculate the timestamp status identifier, and writes the calculated hash digest as the revocation status into the leaf node, overwriting the original valid status value in the leaf node, so that the leaf node forms a status change record with a time dimension in the global attribute state tree.

9. The blockchain-based trusted sharing and secure management method for talent data according to claim 4, characterized in that, The step of calculating the first verification hash value from the leaf node set to the root node from bottom to top using the hash values ​​of adjacent sibling nodes contained in the Merkel proof path also includes: During the hash value calculation process, the smart contract extracts the hash values ​​of adjacent sibling nodes at each level in the Merkel proof path and performs an XOR operation between the hash values ​​of the adjacent sibling nodes and the hash value of the node at the current level. After each XOR operation, the smart contract performs a bitwise AND operation with the result and a confusion factor generated by a preset random number generator. The result of the bitwise AND operation is used as the input node hash value for the next level of calculation, until the first verification hash value is output at the root node level.

10. The blockchain-based trusted sharing and secure management method for talent data according to claim 6, characterized in that, After discarding the generated intermediate decryption key component and blocking the process of transmitting the key from the second-layer ciphertext component corresponding to the revocation sub-policy to the first-layer ciphertext component, the method further includes: The data requesting node establishes a process control block in memory for the decryption task of the nested ciphertext structure. The data requesting node marks the decryption status of the second-layer ciphertext component recorded in the decryption task process control block as abnormal termination, and clears the memory space allocated to the attribute verification matrix in the decryption task process control block. Based on the abnormal termination status, the data requesting node sends an abnormal termination notification containing the identifier of the conflicting leaf node to the data owning node, and deletes the first-layer ciphertext component and the second-layer ciphertext component in the nested ciphertext structure stored locally.

Images