Block chain-driven hierarchical key management method and system

Abstract

The invention discloses a block chain-driven hierarchical key management method and system, and relates to the field of information security. According to the method, a key derivation system for dividing users according to regions is designed. From a root key of the system, a regional key and a terminal user key are derived in sequence. The KGC is used as a trusted root mechanism, system initial parameters and a root key are generated, area keys are generated for different areas, and then an administrator of each area uses the area keys to derive user keys for users in the areas. The hierarchical structure enables management of secret keys of users in different areas to be more convenient, and only users with corresponding permissions can decrypt and access specific data, so that the security and confidentiality of the data are effectively improved.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a blockchain-driven hierarchical key management method and system. Background Art

[0002] With the rapid development of information technology, cloud storage, as an efficient and flexible data storage model, has gained widespread adoption in both enterprise and personal sectors. By integrating vast amounts of storage resources in the cloud and leveraging distributed storage and virtualization technologies, cloud storage provides users with an on-demand, elastically scalable storage service model. Users no longer need to invest significant capital and effort in building and maintaining local storage infrastructure. Instead, they can access and manage their data stored in the cloud anytime, anywhere, simply through a network connection, greatly improving the flexibility and efficiency of data storage. Enterprises can store large amounts of data on the servers of cloud service providers (CSPs), eliminating the need to build and maintain a large local storage infrastructure themselves, thereby reducing storage costs and management complexity. Individual users can also use cloud storage to access and share their data anytime, anywhere.

[0003] However, data security in cloud storage environments faces numerous challenges. When data is stored in the cloud, enterprises and users lose direct physical control over the data, posing threats to its privacy, integrity, and availability. For example, cloud storage service providers may leak user data due to technical vulnerabilities, poor internal management, or external attacks. Data can also be tampered with during transmission and storage, compromising its authenticity and reliability. A common industry response to this problem is to encrypt cloud-stored data with cryptographic keys.

[0004] The traditional centralized key management model stores and manages all keys in a central node. While this approach facilitates unified key management to a certain extent, it carries a significant single point of failure risk. If this central node is attacked—for example, by hackers gaining access to keys, or if keys are lost or damaged due to hardware failure or software errors—the entire encryption system will instantly collapse, exposing all data encrypted with these keys to the risk of being compromised. Furthermore, the traditional single-layer key management approach requires all users to use the same or similar keys for data encryption and decryption, making it impossible to flexibly manage keys for users in different regions. Summary of the Invention

[0005] Based on this, it is necessary to provide a blockchain-driven hierarchical key management method and system that can improve the security and confidentiality of data to address the above technical problems.

[0006] In a first aspect, the present application provides a blockchain-driven hierarchical key management method. The method comprises:

[0007] Generate a root key, derive a master private key based on the root key, obtain a master public key based on the master private key, and publish public parameters including the master public key;

[0008] Based on the regional unique identifier submitted by the regional administrator and the regional authorization code issued by KGC, the regional combination identifier is obtained; based on the regional combination identifier, root key, and public parameters, the regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded in the blockchain;

[0009] Based on the identity identifier submitted by the user, combined with the regional combination identifier corresponding to the user's region, the user combination identifier is obtained; based on the user combination identifier, the master private key, and the public parameters, the user private key is generated and distributed to the corresponding user;

[0010] Use public parameters to verify the legitimacy of the zone private key or user private key.

[0011] In one embodiment, an incremental factor is randomly selected, and an incremental update is performed based on the old root key to obtain a new master private key. An incremental update is performed based on the old master public key to obtain a new master public key. The blockchain records the association of the master private keys before and after the update.

[0012] Generate new regional private keys in batches based on the old regional private keys. After passing the legitimacy verification, mark the new regional private keys as activated on the blockchain.

[0013] A new user private key is generated using the new region private key and user combined identifier. It becomes effective after passing the legitimacy verification, and the old user private key is saved to the historical version pool.

[0014] In one embodiment, if a regional private key leak in a single region is detected, all user private keys in the leaked region are frozen, and a local update of the master private key corresponding to the leaked region is triggered;

[0015] If a root key leak is detected, the system will roll back to the previous version of the root key based on the blockchain's historical records to update the global key.

[0016] In one embodiment, a user-uploaded file is obtained, the file is divided into several data blocks, and a security level is marked for each data block, and corresponding security labels are generated for data blocks of different security levels;

[0017] Among them, the security levels include high security level, medium security level and low security level; the high security level corresponds to dynamic tags; the medium security level corresponds to hybrid tags, and uses Merkle tree for aggregation storage optimization; the low security level corresponds to tags generated by lightweight hash algorithm.

[0018] In one embodiment, a random number r is generated. t , calculate the hash value of the data block According to the random number r t and hash value Generate dynamic tags i ;

[0019] Use the regional private key of the user's region to sign the dynamic tag and obtain the tag signature σ i ;

[0020] Combined with the public parameters, the ciphertext C is constructed. The ciphertext C includes the temporary public key, the joint information of the user's region and the root key, and the encrypted random number r t ;

[0021] The dynamic tag of the high security level data block is stored as (tag i ,σ i ,C).

[0022] In one embodiment, an audit request is initiated through a blockchain smart contract;

[0023] Generate a challenge message based on the audit request and send it to the CSP;

[0024] Based on the challenge message, the CSP performs differentiated processing on the corresponding tags of data blocks with different security levels, and constructs an aggregate proof that includes integrity proof and cross-validation parameters;

[0025] The smart contract verifies the aggregated proof using a preset verification algorithm;

[0026] The smart contract summarizes the verification results and generates an audit report.

[0027] In a second aspect, this application also provides a blockchain-driven hierarchical key management system. The system includes:

[0028] The key generation center is responsible for generating the root key, deriving the master private key from the root key, obtaining the master public key from the master private key, and publishing public parameters including the master public key;

[0029] Furthermore, based on the regional unique identifier submitted by the regional administrator and the regional authorization code issued by KGC, the regional combination identifier is obtained; based on the regional combination identifier, root key, and public parameters, the regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded in the blockchain; based on the identity identifier submitted by the user and the regional combination identifier corresponding to the user's region, the user combination identifier is obtained; based on the user combination identifier, master private key, and public parameters, the user private key is generated and distributed to the corresponding user;

[0030] Hierarchical users are used to verify the legitimacy of regional private keys or user private keys using public parameters;

[0031] The blockchain network is used to record the key distribution records of the key generation center.

[0032] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above-mentioned blockchain-driven hierarchical key management method when executing the computer program.

[0033] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-mentioned blockchain-driven hierarchical key management method.

[0034] In a fifth aspect, the present application further provides a computer program product, comprising a computer program that, when executed by a processor, implements the steps in the above-mentioned blockchain-driven hierarchical key management method.

[0035] The blockchain-driven hierarchical key management method and system generates a root key, derives a master private key from the root key, obtains a master public key from the master private key, and publishes public parameters containing the master public key. Based on the unique regional identifier submitted by the regional administrator and the regional authorization code issued by the KGC, a regional combination identifier is obtained. Based on the regional combination identifier, the root key, and the public parameters, a regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded on the blockchain. Based on the user's identity submitted and the regional combination identifier corresponding to the user's region, a user combination identifier is obtained. Based on the user combination identifier, the master private key, and the public parameters, a user private key is generated and distributed to the corresponding user. The public parameters are used to verify the legitimacy of the regional or user private keys. The present invention designs a key derivation system that divides users by region. Starting from the system's root key, regional keys and end-user keys are derived in sequence. The KGC, acting as a trusted root authority, generates system initial parameters and root keys, and generates regional keys for different regions. The administrator of each region then uses the regional key to derive user keys for users within that region. This hierarchical structure makes it easier to manage keys for users in different regions, and only users with corresponding permissions can decrypt and access specific data, effectively improving data security and confidentiality. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 Schematic diagram of a flowchart of a blockchain-driven hierarchical key management method in one embodiment. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] This application provides a blockchain-driven hierarchical key management method, such as Figure 1 As shown, the following entities are involved:

[0039] (1) Key Generation Center (KGC): As the trusted root organization of the system, it is responsible for generating the system initial parameters and root keys, deriving and distributing regional keys, monitoring the key life cycle (update, revocation, expiration mark), synchronizing key operation logs with the blockchain through a secure channel, maintaining the global identity library, and preventing end-user ID duplication.

[0040] (2) Hierarchical users: manage end users according to regional scope to achieve top-down key derivation and data control. The root key is the highest authority key and can generate regional keys. It supervises the use records of all subordinate keys, has the authority to forcibly revoke, and participates in multi-institutional collaborative decision-making (such as emergency key freezing). The regional administrator is responsible for the regional keys derived from the root key, can generate and distribute end-user keys, maintain the access control list (ACL, Access Control List) of users in the region, can initiate data sharing requests in the region, and review user operation logs. The user key is the terminal operation key derived from the regional key, performs daily data encryption / decryption operations, and generates file tags according to the security level of the file. It can interact with the CSP to complete data upload, retrieval and integrity verification, and can locally maintain the tag index table, supporting Merkle path fast verification.

[0041] (3) Cloud Service Provider (CSP): Provides distributed storage infrastructure that can store encrypted data blocks and associated metadata, performs multi-granularity deduplication based on file blocks with different security levels, stores operation logs synchronously with the blockchain, and accepts real-time monitoring by a third-party auditor (TPA).

[0042] (4) Blockchain network: records key distribution, data operation logs and audit results, deploys audit smart contracts, and automatically executes the challenge generation, proof verification, and result on-chain processes.

[0043] In one embodiment, the method includes a key derivation mechanism that divides the user's region into zones, allowing the KGC to dynamically allocate zones. The KGC first generates a root key and then derives zone keys based on information about each zone. Each zone has an administrator responsible for managing the zone's keys. End-user keys are also derived based on the user's region.

[0044] The specific steps include:

[0045] S101, system parameter initialization. KGC generates the root key and initializes the public parameters when the system starts. The steps are as follows:

[0046] S1011. Select bilinear group

[0047] Select two prime-order multiplicative cyclic groups G1 and G2 of order p (a large prime number), and a computable bilinear map e:G1×G1→G2; select the generator g1 of G1 and the generator g2 of G2.

[0048] S1012. Define hash function

[0049] Choose 4 collision-resistant hash functions:

[0050]

[0051] S1013. Generate root key

[0052] Randomly select a master private key Calculate the master public key

[0053] S1014, publish public parameters

[0054] Public parameters pp = (g1, g2, e, H1, H2, H3, H4, mpk), secret root key msk.

[0055] S102, regional key generation. When the administrator makes a request, KGC will generate the regional key based on the administrator's region. The steps are as follows:

[0056] S1021. Submit regional identification

[0057] The regional administrator submits the unique identifier ID of the region to KGC reg , then combine RID=ID reg ||AuthCode, where AuthCode is the regional authorization code issued by KGC to achieve dynamic expansion and contraction.

[0058] S1022. Calculate the regional hash value

[0059] KGC calculates the hash value of RID: hreg =H1(RID)mod p.

[0060] S1023. Generate the administrator's regional private key

[0061] Use the root key msk and hash value h reg , calculate the zone private key

[0062] S1024: Distribute regional keys

[0063] KGC will It is sent to the administrator of each area through a secure channel, and the key distribution event (including ID reg , timestamp, operator signature).

[0064] S103, regional key validity verification. The regional administrator needs to verify the validity of the regional key. The steps are as follows:

[0065] S1031. Calculate verification parameters

[0066] Calculate h reg =H1(ID reg )mod p and obtain the master public key mpk.

[0067] S1032. Verify the bilinear pairing equation

[0068] Check that the following equality holds: The derivation process is as follows:

[0069]

[0070] If the equality holds, the administrator verifies that the zone key is legitimate; otherwise, it is rejected and an exception is reported.

[0071] S104: Generate terminal user key

[0072] S1041. End user submits identity information

[0073] When a user registers, the regional administrator will verify the user's identity and submit the end user's identity ID u , combined with the user's region and user identity: UID = ID reg ||ID u .

[0074] S1042, derive user key

[0075] Calculate the hash value h UID =H1(UID)mod p.

[0076] Generate user private key

[0077] S1043. Verification and distribution of user keys

[0078] Similar to the verification of the zone key, the following equation is calculated:

[0079]

[0080] In one embodiment, the method further includes a key update mechanism. To reduce the key update overhead and achieve the association between the old and new keys, an incremental key derivation and versioned key management mechanism is designed. The specific steps are as follows:

[0081] S201, KGC generates a new master private key based on the old root key and randomly selects the increment factor Calculate the new master private key msk new =msk old +δmodp. The linear relationship between the new and old keys is verified by bilinear pairing: This equation ensures that the new master public key The correctness of the old master public key is guaranteed, and the middleman attack is avoided. In addition, the old master public key is incrementally updated to reduce repeated calculations. Then the association between the new and old keys is recorded in the blockchain, that is, the storage tuple (msk old ,δ,VersionID,T expire ), set the old key expiration time T expire =T current +7d.

[0082] S202, batch generate new regional keys, for each regional identifier RID, using the old regional key Quickly derive new keys Reuse the old key by exponential operation to avoid recalculating the bilinear group elements; when the regional administrator receives sk new After that, verify that the following equation automatically takes effect: After verification, the blockchain marks the new key as active.

[0083] S203, the regional administrator uses the new regional key sk new And user ID UID, directly generate user key The hash difference between the regional key and the user ID is dynamically adjusted to avoid resubmitting identity information; when the user terminal subscribes to the key version change event through the blockchain, the new key sk is automatically downloaded. u,new , and verify that: After successful verification, the new key takes effect immediately and the old key is moved to the historical version pool (the client maintains multiple versions of keys and automatically selects the corresponding key based on the data timestamp).

[0084] S204, expired keys are automatically frozen.current >T expire , the smart contract marks the old key as read-only, prohibiting new operations from using it, but it can still decrypt historical data. If a key leak in a single area is detected, the smart contract freezes all user keys in that area and triggers a local update. The update formula is: msk emergency =H(msk new || RID) only affects the key for that region, while other regions operate normally. If the global root key is leaked, i.e., if the root key operation log is abnormal or multiple regions trigger simultaneous alarms, the key is rolled back to the previous secure version based on the blockchain history, and then the key is regenerated according to steps S101 to S104. When a user logs out, the key becomes invalid immediately, and the CSP revokes their access rights and marks them on the blockchain.

[0085] In one embodiment, after the user uploads a file, the file F is divided into n data blocks. For each block F i Marked safety level S i ∈{S3,S2,S1}, where S3 represents the highest security level, S2 represents the medium security level, and S1 represents the low security level. Different security labels are generated for data files of different security levels to save storage overhead.

[0086] The steps for generating S3 security level file tags are as follows: Generate a random number Calculate the file block hash: Generate dynamic tags Using the zone private key Sign the label Then encrypt the random number r t : Select Constructing ciphertext Among them, C1 is the temporary public key, C2 contains the joint information of the user's region and the root key, and C3 is the encrypted random number r t . Last stored (tag i ,σ i ,C), Attach access control lists (ACLs) to restrict access rights so that only authorized users can see ,and generate a unique tag for each upload to prevent cross-user association.

[0087] When the user has a legitimate zone private key It can be decrypted by following the steps below:

[0088] Calculate pairing values Recover random numbers Using the restored r t , check whether the dynamic tag meets Final verification signature If rt Leaked, the blockchain can locate the leaker (through signature σ i Bind uploader identity).

[0089] The steps for generating S2 security level file labels are as follows: For medium security level file blocks, a mixed label can be used, that is, for each file block F i Calculate tags i =H3(F i ||ID reg ||TimeStamp). Then, the generated tags are aggregated and stored through the Merkle tree: first, leaf nodes are generated, and the hash value leaf is calculated for each tag. i =SHA-256(tag i )(1≤i≤n), if the number of leaf nodes n is not a power of 2, fill the empty nodes to the minimum of 2 m (2 m ≥n). In the Merkle tree structure, using SHA-256 can ensure that the hash value of each leaf node and intermediate node is unique, and generate a fixed-length 256-bit (32-byte) hash value, achieving a balance between security and storage efficiency, thereby ensuring data integrity. Every two adjacent leaf nodes generate a parent node parent i =SHA-256(leaf 2i ||leaf 2i+1 ), recursively calculate upward until a unique root hash Root is generated. For a Merkle tree with a depth of d, the node is at position j in layer l, and its parent node is Root hash expression

[0090] The CSP only stores the root hash Root, not the original label or intermediate node. This reduces the storage space. Instead of storing n labels, only one Root needs to be stored, saving n-1 label space.

[0091] The user end locally saves the tag index table: record tags i The corresponding Merkle tree path (leaf node position and sibling node sequence).

[0092] S2 security level file tags need to be deduplicated and integrity verified. When uploading a new data block c', an S2 tag tag'=H3(c'||ID reg ), calculate the leaf node hash leaf i '=SHA-256(tag'). The user requests the root hash of the current group from the CSP and provides leaf i' and its corresponding Merkle path (all sibling hash values from the leaf node to the root node), and calculate the parent hash layer by layer to see if the final result is equal to the root. If the verification passes, it means that the data block exists, triggering deduplication; otherwise, a new tag is added and the Merkle tree is updated.

[0093] The steps for generating the S1 security level file tag are as follows: For the tag generation of the file block with lower security level, lightweight hash is used. The user generates the file block F i Compute collision-resistant hash tags: Use K=H3(F i ) as the key to symmetric encrypt the file block: C i =AES-Encrypt(K,F i ).

[0094] CSP maintains a global hash table (GHT) to store the tags of all S1 data blocks. i Its metadata includes the following fields: (1) Tag i : Hash value that uniquely identifies the data block; (2) Ciphertext reference pointer Ref i : Points to the actual encrypted data C i Storage location; (3) reference count Count(tag i ): Records the number of times a data block with the same label is referenced.

[0095] User sent (tag i ,C i ) to CSP, CSP checks whether the tag exists in GHT i , triggering deduplication verification conditions: sttag j =tag i If it already exists, return the reference pointer Ref of the existing stored data block i , and increment the reference count: Count(tag i )←Count(tag i )+1, the user discards the local C i , use Ref directly i ; If it does not exist, store C i , generate a unique Ref i , and record the tag i Go to GHT and initialize the count: Count(tag i )←1. That is, when uploading, Count(tag i )←Count(tag i )+Δ, Count(tag i )←max(Count(tag i )-1,0).

[0096] When the user requests to delete the Ref i When CSP executes: Count(tag i )←Count(tag i )-1, if count Count(tag i )=0, then delete the ciphertext C i And remove the tag in GHT i entry.

[0097] Hash collision probability: Assume that the output length of H2 is log2 p bits, then different file blocks F i ≠F j Generate the same tag i The probability is: When p is a large prime number (such as 256 bits), this probability can be ignored. Encryption key K = H3(F i ) depends on the anti-collision property of H3. Even if the attacker knows the tag i , nor can F be reversed i (Because H2 and H3 are independent).

[0098] In one embodiment, in order to improve the fairness and efficiency of audits and eliminate the reliance on trusted third-party auditors, an automated audit mechanism based on blockchain smart contracts was designed. The specific process is as follows:

[0099] S301: Audit request stage.

[0100] The user initiates an audit request through a blockchain smart contract and specifies the unique identifier ID of the file to be audited. f The smart contract performs the following operations: (1) retrieves the file metadata stored in the blockchain: total number of blocks s, security level, data block index mapping table; (2) generates an audit request unique identifier ID audit =H1(ID f ||TimeStamp); (3) Trigger the audit logic in the smart contract and generate the initial parameters (T start ,ΔT), where T start is the current timestamp, and ΔT is the validity period, which is set to 300s.

[0101] The smart contract verifies the hierarchical key sk held by the user L2 Is it related to ID f The access control list (ACL) matches and checks the user's zone ID. regWhether it has audit permissions (through the group policy recorded on the blockchain). If verification fails, an error code is returned; otherwise, it enters the challenge generation stage.

[0102] S302, challenge generation phase. The smart contract performs the following operations:

[0103] S3021. Determine the number of challenge data blocks z = [log2 s] + 1 (ensuring 1 ≤ z ≤ s);

[0104] S3022, generate random seed seed=H2(T start ,ID audit ), generate the index set {a1, a2, ..., a z}←PRF(seed,z);

[0105] S3023. Generate a random coefficient matrix: (used to confuse the aggregation proof). Then the smart contract encapsulates the following parameters into a challenge message Chal=(ID audit ,{a i},{b i},r1,r2,T start ,ΔT), is sent to the CSP through the blockchain event channel and recorded on the chain.

[0106] S303, proof generation phase. When the CSP receives Chal, it executes:

[0107] S3031. Verify the current time T current ≤T start +ΔT;

[0108] S3032, according to the index set {a i} Retrieve the corresponding data block and its metadata (label, signature, security level), and then perform differentiated processing on the labels of data blocks with different security levels;

[0109] For each data block with the highest security level Extract dynamic tags Extract signature Calculate the confusion factor

[0110] For each medium security level data block Get the Merkle path from the local index table Calculate the path hash aggregation value (The XOR operation is irreversible, and the attacker cannot pass the β iReverse the original sibling node hash);

[0111] For each data block with a lower security level Verify the global hash table entry, check and efficient;

[0112] S3033, CSP builds aggregate proof:

[0113] (1) Integrity Proof (2) Cross-validation parameters

[0114] Finally, CSP returns the proof With digital signature CSP =Sign CSP_pri (Proof||ID audit ).

[0115] S304, Proof Verification Phase. The smart contract performs the following verifications:

[0116] (1) Bilinear pairing verification:

[0117] (2) Cross-factor consistency: calculation Verify χ'=χ. For the data block of S2, the Merkle path needs to be verified. For each data block of S2 (1) From the leaf node First, calculate the parent node hash layer by layer: parent j =SHA-256(child 2j ||child 2j+1 ); (2) Verify that the final root hash is consistent with the blockchain record: Root calc =Root blockchain For data with a lower security level, check the global hash table: verify and Has not been tampered with.

[0118] S305. Audit results are uploaded to the blockchain.

[0119] Smart contract summarizes verification results and generates audit report: Report = (ID audit ,Result,Reason fail ,TimeStamp). Where: The result is written into the blockchain. If the result is 1, it means that all verifications have passed. If the result is 0, the access rights to the relevant data will be automatically frozen, and the TPA will be notified to start the manual review process.

[0120] Traditional cloud storage encryption has the following problems:

[0121] (1) The traditional centralized key management model stores and manages all keys in a central node. Although this approach facilitates unified key management to a certain extent, it poses a serious risk of single point failure. Once this central node is attacked, such as by hackers who obtain keys, or keys are lost or damaged due to hardware failure, software errors, etc., the encryption system of the entire system will collapse instantly, and all data encrypted by these keys will be at risk of leakage. At the same time, the traditional single-layer key management method, in which all users use the same or similar keys for data encryption and decryption, cannot perform flexible key management for users in different regions.

[0122] (2) Traditional key management solutions have limitations in their update mechanisms. For example, centralized systems require the regeneration and distribution of all keys, resulting in high latency and computational costs, making them difficult to scale, especially in large-scale user scenarios. Most solutions force the abandonment of old keys, making historical encrypted data inaccessible or requiring complex data migration processes, impacting business continuity.

[0123] (3) In traditional data storage systems, tags are usually added to each file to facilitate data retrieval and management. When the data volume is small, randomized file tags greatly enhance the confidentiality of the files and can meet basic retrieval requirements. However, as the data volume continues to increase, the number of tags will also increase exponentially. If a random tag generation mechanism is used in all cases, it will not only lead to a significant increase in storage overhead and occupy a large amount of storage space, but also sharply reduce the efficiency of data retrieval.

[0124] (4) The audit process relies on third-party agencies, which is inefficient and costly.

[0125] To effectively address the aforementioned cloud storage data security issues, this solution leverages the decentralized and tamper-proof nature of blockchain technology, deriving keys based on user regions and combining this with file tag optimization strategies to construct a blockchain-driven key derivation and multi-level data security collaboration solution. The specific contributions are as follows:

[0126] (1) To address the issues of single-point failure in traditional key management and user key management, a key derivation system was designed that divides users by region. Starting from the system's root key, regional keys and end-user keys are derived in sequence. The Key Generation Center (KGC), as a trusted root institution, generates the system's initial parameters and root keys, and generates regional keys for different regions. The administrator of each region then uses the regional keys to derive user keys for users within the region. This hierarchical structure makes it easier to manage the keys of users in different regions, and only users with corresponding permissions can decrypt and access specific data, effectively improving data security and confidentiality.

[0127] (2) In order to optimize the existing inefficient key update problem, this paper innovatively introduces a random increment factor, and the designed incremental key update mechanism realizes efficient iteration of new and old keys through mathematical association. Using a version control mechanism, the old key retains read-only permission within a certain time window to ensure that historical data can be decrypted and avoid service interruption. The smart contract automatically marks expired keys and freezes operations, while allowing emergency root keys to be generated through hash chains in emergency situations, taking into account both security and business continuity. When a key leak is detected, the system generates an emergency root key through the hash chain and triggers a cascade update to quickly isolate the risk. The update of regional and user keys relies on hierarchical derivation relationships to avoid redistribution of keys across the entire network and improve response speed. Key updates are based on regional divisions, and different regions can perform update operations independently, supporting dynamic expansion and contraction. Regional administrators only need to verify the validity of local keys, without the need for global coordination, reducing management complexity.

[0128] (3) To solve the storage overhead problem caused by the random file tag generation mechanism, a tag generation and storage optimization scheme based on data security level is designed. Data is divided into three levels according to its security level, and different tag generation and storage strategies are adopted for data of different levels. For data of the highest security level, a random file tag generation mechanism is used to generate dynamic tags containing encrypted random numbers and signatures, and an access control list (ACL) is attached to restrict access rights. Once the random number is leaked, the blockchain can quickly locate the identity of the leaker through the signature, thereby ensuring the security of the data; for data of medium security level, a hybrid tag is generated, and the hybrid tag is aggregated and stored by constructing a Merkle tree. The CSP only stores the root hash, reducing the storage volume. At the same time, the user side locally stores the tag index table to support fast integrity verification; for data of lower security level, ordinary tags are used, and deduplication storage is achieved through hash tags and global hash tables, reducing storage costs. Through these strategies, the storage space of tags is effectively reduced, and the storage efficiency and data retrieval efficiency of the system are improved.

[0129] (4) To improve the fairness and efficiency of audits and eliminate reliance on trusted third-party auditors, an automated audit mechanism based on blockchain smart contracts was designed. Users initiate audit requests through blockchain smart contracts, which automatically generate audit challenges and send them to the cloud service provider (CSP). The CSP generates and returns a proof based on the challenge, which the smart contract then verifies. The entire audit process is automated, reducing human intervention and improving the fairness and efficiency of audits.

[0130] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0131] Based on the same inventive concept, embodiments of the present application also provide a blockchain-driven hierarchical key management system for implementing the aforementioned blockchain-driven hierarchical key management method. The implementation solution provided by this system is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more blockchain-driven hierarchical key management system embodiments provided below can be found in the above-mentioned limitations of the blockchain-driven hierarchical key management method and will not be repeated here.

[0132] In one embodiment, a blockchain-driven hierarchical key management system is provided, comprising: a key generation center, configured to generate a root key, derive a master private key based on the root key, obtain a master public key based on the master private key, and publish public parameters including the master public key;

[0133] Furthermore, based on the regional unique identifier submitted by the regional administrator and the regional authorization code issued by KGC, the regional combination identifier is obtained; based on the regional combination identifier, root key, and public parameters, the regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded in the blockchain; based on the identity identifier submitted by the user and the regional combination identifier corresponding to the user's region, the user combination identifier is obtained; based on the user combination identifier, master private key, and public parameters, the user private key is generated and distributed to the corresponding user;

[0134] Hierarchical users are used to verify the legitimacy of regional private keys or user private keys using public parameters;

[0135] The blockchain network is used to record the key distribution records of the key generation center.

[0136] The system also includes a cloud service provider that provides a distributed storage infrastructure that can store encrypted data blocks and associated metadata, perform multi-granularity deduplication based on file blocks with different security levels, store operation logs synchronously with the blockchain, and accept real-time monitoring by TPA.

[0137] Each module in the aforementioned blockchain-driven hierarchical key management system may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor within a computer device in hardware form, or may be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0138] In one embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in all the above method embodiments when executing the computer program.

[0139] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in all the above method embodiments are implemented.

[0140] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in all the above method embodiments when executed by a processor.

[0141] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions.

[0142] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database data blocks or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database data blocks involved in the various embodiments provided herein may include at least one of relational database data blocks and non-relational database data blocks. Non-relational database data blocks may include, but are not limited to, distributed database data blocks based on blockchain. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processors (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), data processing logic devices based on quantum computing, and the like.

[0143] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0144] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A blockchain-driven hierarchical key management method, characterized in that: The method comprises: Generate a root key, derive a master private key based on the root key, obtain a master public key based on the master private key, and publish public parameters including the master public key; Based on the regional unique identifier submitted by the regional administrator and the regional authorization code issued by KGC, the regional combination identifier is obtained; based on the regional combination identifier, root key, and public parameters, the regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded in the blockchain; Based on the identity identifier submitted by the user, combined with the regional combination identifier corresponding to the user's region, the user combination identifier is obtained; based on the user combination identifier, the master private key, and the public parameters, the user private key is generated and distributed to the corresponding user; Use public parameters to verify the legitimacy of the zone private key or user private key.

2. The method according to claim 1, characterized in that The method further comprises: Randomly select an incremental factor, perform an incremental update based on the old root key to obtain a new master private key, and perform an incremental update based on the old master public key to obtain a new master public key. The master private keys before and after the blockchain record update are associated; Generate new regional private keys in batches based on the old regional private keys. After passing the legitimacy verification, mark the new regional private keys as activated on the blockchain. A new user private key is generated using the new region private key and user combined identifier. It becomes effective after passing the legitimacy verification, and the old user private key is saved to the historical version pool.

3. The method according to claim 2, characterized in that The method further comprises: If a regional private key leak is detected for a single region, all user private keys in the leaked region will be frozen, and a local update of the master private key corresponding to the leaked region will be triggered; If a root key leak is detected, the system will roll back to the previous version of the root key based on the blockchain's historical records to update the global key.

4. The method according to claim 1, wherein The method further comprises: Obtain user-uploaded files, split the files into several data blocks, mark the security level of each data block, and generate corresponding security labels for data blocks of different security levels; Among them, the security levels include high security level, medium security level and low security level; the high security level corresponds to dynamic tags; the medium security level corresponds to hybrid tags, and uses Merkle tree for aggregation storage optimization; the low security level corresponds to tags generated by lightweight hash algorithm.

5. The method according to claim 4, characterized in that The generation of dynamic tags includes: Generate a random number r t , calculate the hash value of the data block According to the random number r t and hash value Generate dynamic tags i ; Use the regional private key of the user's region to sign the dynamic tag and obtain the tag signature σ i ; Combined with the public parameters, the ciphertext C is constructed. The ciphertext C includes the temporary public key, the joint information of the user's region and the root key, and the encrypted random number r t ; The dynamic tag of the high security level data block is stored as (tag i ,σ i ,C).

6. The method according to claim 4, characterized in that The method further comprises: Initiate audit requests through blockchain smart contracts; Generate a challenge message based on the audit request and send it to the CSP; Based on the challenge message, the CSP performs differentiated processing on the corresponding tags of data blocks with different security levels, and constructs an aggregate proof that includes integrity proof and cross-validation parameters; The smart contract uses a preset verification algorithm to verify the aggregated proof; The smart contract summarizes the verification results and generates an audit report.

7. A blockchain-driven hierarchical key management system, characterized in that: The system comprises: The key generation center is responsible for generating the root key, deriving the master private key from the root key, obtaining the master public key from the master private key, and publishing public parameters including the master public key; Furthermore, based on the regional unique identifier submitted by the regional administrator and the regional authorization code issued by KGC, the regional combination identifier is obtained; based on the regional combination identifier, root key, and public parameters, the regional private key is generated and distributed to the corresponding regional administrator, and the regional private key distribution event is recorded in the blockchain; based on the identity identifier submitted by the user and the regional combination identifier corresponding to the user's region, the user combination identifier is obtained; based on the user combination identifier, master private key, and public parameters, the user private key is generated and distributed to the corresponding user; Hierarchical users are used to verify the legitimacy of regional private keys or user private keys using public parameters; The blockchain network is used to record the key distribution records of the key generation center.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images