Data access authority control method and system based on block chain

Abstract

The invention discloses a data access permission control method and system based on a block chain, and relates to the technical field of block chains, the system is composed of a plurality of function modules, and the system comprises a hierarchical permission module which adopts a role hierarchical strategy and defines the access granularity of a role through an intelligent contract; the dynamic permission adjustment module is used for dynamically adjusting the permission range by analyzing user behaviors in real time through machine learning according to the principle of following the minimum permission in the permission distribution process; attribute encryption and zero-knowledge proof are introduced, an access key is dynamically generated according to user attributes, and sensitive information is hidden in the verification process; the multi-chain collaboration module is used for coding an intelligent contract through an authority rule, automatically executing access request verification, storing encrypted data through a private chain, managing an index and an access strategy through an alliance chain, isolating a storage domain from an access domain, and carrying out process traceability on a data request through a cross-chain verification mechanism; and the key management module is used for generating a true random number private key by adopting a hardware security unit.

Description

Technical Field

[0001] The present invention relates to the technical field of blockchain, and specifically to a method and system for controlling data access permissions based on blockchain. Background Art

[0002] In the initial stage of computer systems, simple access control lists were adopted, and permissions were directly bound to users or groups; the data access permission control system has become the core mechanism for ensuring data security through refined permission management; it restricts unauthorized users from accessing sensitive information, such as medical records and financial data, to prevent data leakage and abuse; for example, medical institutions ensure that only authorized personnel can view patient privacy data through permission control; its development process has evolved from simple authorization in the early stage to a dynamic and intelligent modern model, continuously coping with the security challenges of the digital age; in the future, with technological innovation, this system will further integrate AI and automation capabilities to provide more efficient security solutions for various industries.

[0003] In the digital age, the traditional role-based access control model has the following risks: its centralized authentication architecture not only has the risk of single-point failure, but also is difficult to adapt to dynamic business requirements due to its rigid permission management mechanism; permission allocation depends on manual policy configuration, and a trusted third-party intermediary is required to establish a trust channel during cross-organization collaboration, resulting in a decrease in permission granting efficiency; for example, when a top-three hospital initiates a cross-hospital consultation, the centralized system needs more than 72 hours to coordinate multiple parties to sign an agreement before temporarily opening the read-only permission of patient imaging data, seriously delaying the clinical decision-making time; the centralized data storage architecture exacerbates security risks, the probability of private key leakage in a system using a single PKI system is relatively high, and the traditional attribute encryption scheme lacks the ability of dynamic adjustment, and the audit and traceability mechanism also has structural defects. Log data is stored in a centralized database, and unauthorized access behaviors cannot be effectively traced. For example, the audit logs of medical systems only record field-level access on average, lacking fine-grained operation tracking. Summary of the Invention

[0004] To achieve the above objectives, the present invention is realized through the following technical solutions: A data access permission control system based on blockchain, including:

[0005] A hierarchical permission module, which adopts a role hierarchical strategy and defines the access granularity of roles through smart contracts;

[0006] A dynamic permission adjustment module, which follows the principle of least privilege during the permission allocation process, and dynamically adjusts the permission range by analyzing user behavior in real time through machine learning; introduces attribute encryption and zero-knowledge proof, dynamically generates access keys according to user attributes, and hides sensitive information during the verification process;

[0007] Multi-chain collaboration module, encoding smart contracts through permission rules, automatically executing access request verification, storing encrypted data through a private chain, managing indexes and access policies through a consortium chain, isolating storage domains and access domains, and enabling process traceability through a cross-chain verification mechanism for data requests;

[0008] Key management module, generating true random number private keys using a hardware security module, distributing and updating keys in combination with the PKI system; triggering key rotation after the end of the private key usage period, and retrieving keys through an off-chain CA institution; storing the data body through symmetric encryption, protecting the transmission channel through asymmetric encryption, and controlling key decryption permissions through smart contracts.

[0009] Furthermore, the process of defining the access granularity of roles through smart contracts is as follows:

[0010] Role hierarchy division: Divide system participants into super administrators, organizational administrators, department administrators, and ordinary user levels;

[0011] Write the mapping relationship between roles and permissions into the on-chain smart contract through Solidity language, and the smart contract forcibly restricts the scope of role permission allocation; access control driven by smart contracts, through on-chain evidence storage of permission rules, automates the permission verification process, and isolates permissions between organizations.

[0012] Furthermore, the process of dynamically adjusting the permission scope is as follows:

[0013] The principle of least privilege includes initial permission allocation and real-time permission revocation;

[0014] Initial permission allocation: Users initially only obtain the basic permissions necessary to complete the current task, with permission granularity refined to the API interface level or data field level. The smart contract has a built-in permission whitelist to automatically intercept permission requests that exceed the role scope;

[0015] Real-time permission revocation: Monitor user operations through blockchain event triggers, and automatically trigger the smart contract to revoke redundant permissions when permission idleness is detected.

[0016] Furthermore, the process of real-time analyzing user behavior through machine learning is as follows:

[0017] Collect user operation logs, build a user behavior baseline model through an LSTM neural network to identify normal behavior patterns, and use an unsupervised clustering algorithm to group users, and users of the same role share a behavior feature library.

[0018] Furthermore, the process of dynamically generating access keys based on user attributes is as follows:

[0019] Encode user attributes into a set of attributes; generate a dynamic access key through elliptic curve encryption; bind an attribute policy during data encryption. In the key lifecycle management, set the validity period of the private key to N hours. After the timeout, the attributes need to be re-authenticated by an off-chain CA institution to obtain a new key; in the verification phase, use the zk-SNARKs protocol, and the user only needs to submit a proof of the existence of the attributes without revealing the specific attribute values.

[0020] Further, the process of automatically verifying the access request is as follows:

[0021] The private chain stores encrypted data: responsible for storing the original encrypted data body, using symmetric encryption, and only allowing decryption with keys authorized by the smart contract;

[0022] The consortium chain manages the index and access policy: manage the data index, store the permission rules and metadata of the role attribute mapping table; encode the permission rules into executable logic on the chain through the smart contract.

[0023] Further, the process of the cross-chain verification mechanism is as follows:

[0024] S301: The user initiates a cross-chain data request through the local chain,

[0025] carrying a digital identity certificate and attribute proof;

[0026] S302: The consortium chain calls the smart contract to verify whether the user role attributes match the access policy of the target data;

[0027] S303: After the verification passes, the consortium chain generates a dynamic access token, triggering the smart contract of the private chain to release the decryption key fragment of the corresponding data

[0028] S304: Adopt a two-phase commit protocol to ensure that the cross-chain operation is "all successful" or "all rolled back";

[0029] Through policy templatization, combine RBAC and ABAC, define conditional judgment logic through Solidity smart contracts, and automatically synchronize the modified version to all consortium chain nodes after modification; set the maximum waiting time for cross-chain operations, and automatically trigger the smart contract to roll back after the timeout; and use Merkle proof to verify the cross-chain operation result. The requesting chain and the processing chain ensure data consistency by comparing the Merkle root hash.

[0030] Further, the process of generating a true random number private key using a hardware security module and distributing and updating the key in combination with the PKI system is as follows:

[0031] Generate true random number seeds using physical entropy source technology, generate private keys through the TRNG true random number generator built into the hardware security unit. After the private keys are generated, they are directly stored in the secure storage area of the HSM. Adopt physical anti-disassembly packaging technology to prevent side-channel attacks, and the plaintext of the private keys is not exposed outside the hardware; divide the private keys into multiple segments and store them distributedly in multiple HSM nodes through the Shamir secret sharing scheme. At least t segments need to be combined to recover the complete private key.

[0032] Further, the process of retrieving keys through off-chain CA institutions and the smart contract controlling key decryption permissions is as follows:

[0033] The root CA is entrusted by an off-chain authoritative institution, and the sub-CAs are dynamically authorized through smart contracts, supporting multi-level organizational structures, such as key issuance for the general hospital headquarters - sub-hospitals; the user certificates in the consortium chain are bound to the private chain identity through the cross-chain relay protocol for key mutual recognition between heterogeneous systems;

[0034] Adopt AES-256 symmetric encryption to store the original data, and the key is protected by the HSM and dynamically authorized for access through smart contracts; use RSA-4096 or ECC-521 asymmetric encryption to establish a secure communication link, and encode the access policy as smart contract logic.

[0035] A blockchain-based data access permission control method includes the following steps:

[0036] Step 1: Adopt a role stratification strategy and define the access granularity of roles through smart contracts;

[0037] Step 2: During the permission allocation process, follow the principle of least privilege, and dynamically adjust the permission range by analyzing user behavior in real time through machine learning; introduce attribute encryption and zero-knowledge proof, dynamically generate access keys according to user attributes, and hide sensitive information during the verification process;

[0038] Step 3: Encode permission rules for smart contracts, automatically execute access request verification, store encrypted data through the private chain, manage indexes and access policies through the consortium chain, isolate the storage domain and the access domain, and data requests need to pass through the cross-chain verification mechanism for process traceability;

[0039] Step 4: Use a hardware security unit to generate true random number private keys, combine with the PKI system to distribute and update keys; after the end of the private key usage period, trigger key rotation, and retrieve keys through off-chain CA institutions; store the data body through symmetric encryption and protect the transmission channel through asymmetric encryption, and the smart contract controls the key decryption permission.

[0040] The present invention provides a blockchain-based data access permission control method and system, having the following beneficial effects:

[0041] (1) The present invention realizes the on-chain definition and automated execution of role permissions through smart contracts, and uses the immutable feature of the blockchain to ensure the transparency and traceability of permission allocation records, effectively eliminating the risk of human tampering. Combining the role stratification strategy, the system supports fine-grained permission control, such as field-level access, improving the efficiency of permission management compared with the traditional RBAC model, and at the same time realizing cross-organization permission isolation to avoid unauthorized access.

[0042] (2) Introducing machine learning, such as LSTM neural networks to analyze the user behavior baseline, combined with unsupervised clustering algorithms, can detect abnormal operations in real time and dynamically adjust the permission scope; when verifying attributes through zero-knowledge proofs, sensitive information is hidden, reducing the risk of data exposure; under the principle of least privilege, idle permissions are automatically recycled, reducing the attack surface and significantly enhancing the system's dynamic defense capabilities.

[0043] (3) Adopting a separate architecture of private chain encrypted data storage and consortium chain management strategy, combined with a cross-chain two-phase commit protocol, ensures the physical isolation of the data storage domain and the access domain; Merkle root hash verification guarantees the consistency of cross-chain operations, reducing the risk of data leakage; supporting multi-institution collaboration scenarios, shortening the permission granting time and improving the collaboration efficiency; true random number generation based on a hardware security module and Shamir secret sharing scheme to achieve distributed storage of private keys and protection against side-channel attacks; the key rotation mechanism combined with multi-factor authentication of an off-chain CA institution makes the risk of key leakage approach zero, supporting AES-256 / RSA-4096 hybrid encryption and enhancing the ability of the data transmission channel to resist man-in-the-middle attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 is a schematic diagram of the system flow of the present invention;

[0045] Figure 2 is a schematic diagram of the overall method of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0046] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0047] Embodiment 1

[0048] Please refer to Figure 1 , this embodiment provides a blockchain-based data access permission control system, which includes:

[0049] Hierarchical permission module, adopting a role - hierarchical strategy, defines the access granularity of roles through smart contracts;

[0050] Role - level division: Divide system participants into levels such as super - administrator, organization administrator, department administrator, and ordinary user;

[0051] Super - administrator: Has the ability to manage permissions across organizations, can create / delete roles, and modify system core parameters such as access policy thresholds;

[0052] Department administrator: Manages the user permissions of this department and defines the data access scope, such as only being able to view the summary fields of contract documents in this department;

[0053] Ordinary user: Permissions are refined to field - level access, such as only being able to view non - sensitive fields in a data table or interface - level operations, such as only calling query interfaces and prohibiting write interfaces;

[0054] It should be noted that: Sub - roles automatically inherit the basic permissions of the parent role. For example, the department administrator inherits the log - viewing permission of the organization administrator, and at the same time supports the extension of exclusive permissions;

[0055] Dynamic binding of roles and permissions:

[0056] Write the mapping relationship between roles and permissions into the on - chain smart contract through languages such as Solidity. The smart contract forcibly restricts the scope of role - permission allocation. For example, a department administrator cannot grant permissions beyond the data scope of this department;

[0057] The code example is as follows:

[0058]

[0059]

[0060] Access control driven by smart contracts, through on - chain deposition of permission rules, automates the permission verification process and isolates permissions between organizations;

[0061] On - chain deposition of permission rules: Operations such as role creation and permission change are uploaded to the chain through transactions. Utilize the immutability of the blockchain to ensure that the permission allocation records are traceable; Use event logs to record key operations, such as role - permission updates, for the audit module to call;

[0062] Automated Permission Verification Process: When a user initiates a data access request, the smart contract executes the verification logic for role legitimacy, operation granularity matching, and cross-chain permission coordination. Among them, role legitimacy verification checks whether the role associated with the user's digital identity exists in the current permission list; for operation granularity matching, according to the request type, read / write / delete, it matches the interface whitelist in the role permissions; cross-chain permission coordination in a multi-chain architecture verifies the user's role status on other chains through a cross-chain smart contract, such as whether the organization administrator role in a consortium chain is valid.

[0063] Inter-organization Permission Isolation: Using the multi-channel technology of the consortium chain, the role permissions of different organizations are stored in independent channels, and cross-organization permission isolation is achieved through channel policies; and through a resource tagging system, data resources are labeled with the tags of the affiliated organization / department, and the smart contract dynamically filters the accessible resources according to the role hierarchy.

[0064] Example:

[0065] In the medical data sharing scenario, the hospital administrator creates a "cardiologist chief physician" role through the smart contract and authorizes it to access the diagnosis conclusion and medication record fields in the electronic medical record; when the physician transfers to the respiratory department, the smart contract automatically revokes the cardiologist data permission and synchronously grants the respiratory department data access permission; if it is necessary to consult patients in other hospitals, the cross-chain smart contract verifies the validity of its role and temporarily opens the read-only permission for specific medical records; by deeply integrating the role stratification strategy with the smart contract, the automation, fine-grained and cross-domain coordination of permission allocation are realized, and the permission management efficiency is improved compared with the traditional RBAC system.

[0066] Dynamic Permission Adjustment Module: During the permission allocation process, it follows the principle of least privilege and dynamically adjusts the permission range by analyzing user behavior in real time through machine learning; introducing attribute encryption and zero-knowledge proof, dynamically generating access keys according to user attributes, and hiding sensitive information during the verification process.

[0067] Implementation Mechanism of the Principle of Least Privilege:

[0068] The principle of least privilege includes initial permission allocation and real-time permission recovery.

[0069] Initial Permission Allocation: The user initially only obtains the basic permissions necessary to complete the current task, such as only being able to view specific data fields, and the permission granularity is refined to the API interface level or data field level. For example, interns in the medical system can only view the basic information of patients and cannot access the diagnosis records; the smart contract has a built-in permission whitelist to automatically intercept permission requests that exceed the role scope, such as when an ordinary user tries to call the administrator interface, the contract will reject it.

[0070] Real-time Permission Revocation: Monitor user operations through blockchain event triggers. When detecting idle permissions, such as a certain function not being used for 7 consecutive days or a scenario change, such as a user being transferred to another department, automatically trigger a smart contract to revoke redundant permissions. For example, in a hospital supply chain system, after a drug delivery person completes the delivery task, the smart contract immediately revokes their temporary permission to access warehouse inventory details.

[0071] Machine Learning-driven Dynamic Adjustment:

[0072] Conduct behavioral feature modeling, collect user operation logs, such as access time, operation type, and data range. Build a user behavior baseline model through an LSTM neural network to identify normal behavior patterns, such as the time period when doctors view patient medical records daily, and abnormal behaviors, such as accessing sensitive data frequently during non-working hours. Use unsupervised clustering algorithms, such as the DBSCAN algorithm, to group users. Users with the same role share a behavior feature library to improve detection efficiency.

[0073] Risk Dynamic Assessment: Calculate the risk score in real-time, combining user attributes, position and department, operation context, IP address, device fingerprint, and historical behavior deviation. Output a risk value of 0 - 100 through a random forest model.

[0074] When the risk value ≥ 70: Maintain the user's current permissions and continuously monitor behavior data.

[0075] When 90 ≥ the risk value > 70: Automatically downgrade permissions, such as restricting the data export function.

[0076] When the risk value > 90: Freeze the account and trigger an alarm.

[0077] Risk Value: Generated by a random forest model integrating multi-dimensional data such as user attributes, operation behaviors, and device fingerprints. Set thresholds based on the sensitivity inflection point of the ROC curve and the business loss function.

[0078] Collaboration between Attribute Encryption and Zero-Knowledge Proof:

[0079] Attribute Encryption Key Generation: Encode user attributes, such as "Cardiology Attending Physician in a Class-III Grade-A Hospital", into an attribute set, and generate a dynamic access key through elliptic curve encryption. Bind an attribute policy during data encryption, such as "Department = Cardiology AND Title = Attending Physician". In the key lifecycle management, set the validity period of the private key to 24 hours. After timeout, re-authenticate the attributes through an off-chain CA institution to obtain a new key.

[0080] Zero-knowledge proof verification process: The zk-SNARKs protocol is used in the verification phase. Users only need to submit proof of the existence of an attribute, such as proving that they "belong to the role of a doctor," without revealing specific attribute values, such as hospital name or employee number. For example, in the medical insurance data access scenario, the verifier only confirms that the user meets the "medical insurance review qualifications" without knowing the user's institution or review case number.

[0081] For example, a doctor at Hospital A needs to access patient imaging data from Hospital B. The doctor generates a zk certificate to prove that he is "Radiologist A" and that his certificate is valid. The hospital system verifies the validity of the certificate and authorizes access without knowing the name of the other hospital. The operation record is uploaded to the chain: only "an anonymous doctor (ID = 0x9a3b...d7f) accessed the data on 2023-09-20" is recorded, meeting GDPR / HIPAA privacy requirements. When an illegal access occurs, the off-chain arbitration agency can decrypt through multi-party thresholds, and work with the CA agency and the hospital audit department to restore the real identity corresponding to the anonymous ID to achieve responsibility traceability.

[0082] The multi-chain collaboration module encodes smart contracts through permission rules, automatically performs access request verification, and stores encrypted data through private chains. The alliance chain manages indexes and access policies, isolates storage domains from access domains, and requires data requests to pass a cross-chain verification mechanism for process traceability.

[0083] Private chains store encrypted data:

[0084] Responsible for storing the original encrypted data, using symmetric encryption such as AES to protect the data content, and only allowing decryption through keys authorized by smart contracts; for example, in medical scenarios, patient medical records are stored in ciphertext form on private chain nodes, and data access requires cross-chain verification;

[0085] Alliance chain management index and access strategy:

[0086] By managing data indexes, such as Merkle tree root hashes and access policies, metadata such as permission rules and role attribute mapping tables are stored. Through smart contracts, permission rules are encoded into executable logic on the chain, such as the scope of fields allowed to be accessed and the type of operation.

[0087] Isolation advantage: decoupling of "data storage" and "authorization decision-making" is achieved. Even if the consortium chain is attacked, the attacker cannot directly obtain the encrypted data.

[0088] Cross-chain verification process:

[0089] S301: The user initiates a cross-chain data request through a local chain, such as an enterprise private chain, carrying a digital identity certificate and attribute proof;

[0090] S302: The consortium blockchain invokes the smart contract to verify whether the user role attributes match the access policy of the target data;

[0091] S303: After successful verification, the consortium blockchain generates a dynamic access token, triggering the private blockchain smart contract to release the decryption key fragment corresponding to the data;

[0092] S304: Adopt a two-phase commit protocol to ensure that cross-chain operations are "all successful" or "all rolled back", preventing data state inconsistency caused by network interruption;

[0093] Automatically execute access request verification:

[0094] By policy templatization, combine RBAC and ABAC, and define conditional judgment logic through Solidity smart contracts. The code example is as follows:

[0095]

[0096]

[0097] Support dynamic update of policies through the on-chain governance interface, that is, add new compliance requirements, and automatically synchronize to all consortium blockchain nodes after modification; trigger the smart contract rollback automatically when the cross-chain operation maximum waiting time is exceeded; and use Merkle proof to verify the cross-chain operation result. The requesting chain and the processing chain ensure data consistency by comparing the Merkle root hash;

[0098] Key management module, use the hardware security module to generate true random number private keys, and combine with the PKI system to distribute and update keys; after the end of the private key usage period, trigger key rotation, and retrieve the key through an off-chain CA institution; store the data body through symmetric encryption, protect the transmission channel through asymmetric encryption, and the smart contract controls the key decryption permission;

[0099] Hardware security module key generation:

[0100] Adopt physical entropy source technology to generate true random number seeds, and generate private keys through the TRNG true random number generator built in the hardware security module to avoid the predictability risk of pseudo-random number algorithms;

[0101] After the private key is generated, it is directly stored in the secure storage area of the HSM. Adopt physical anti-disassembly packaging technology to prevent side-channel attacks, and the private key plaintext is not exposed outside the hardware; split the private key into multiple fragments, and store them distributively in multiple HSM nodes through the Shamir secret sharing scheme. At least t fragments need to be combined to restore the complete private key;

[0102] PKI system-driven key distribution and update:

[0103] The root CA is entrusted by off-chain authorities, and the sub-CAs are dynamically authorized through smart contracts, supporting multi-level organizational structures, such as key issuance for general hospital headquarters - sub-hospitals; user certificates in the consortium chain are bound to private chain identities through cross-chain relay protocols to achieve key mutual recognition between heterogeneous systems;

[0104] Key rotation:

[0105] The smart contract monitors the key usage duration, and when it expires, it automatically triggers the key update process. Code example:

[0106]

[0107]

[0108] During the transition period when the old and new keys are used in parallel, such as 7 days to ensure business continuity, historical data dynamically selects the decryption key through the smart contract;

[0109] The off-chain CA institution retrieves the key:

[0110] Users need to provide triple verification of biometric fingerprint + hardware token + manual review by the off-chain CA institution, and verify their identities through zero-knowledge proof without disclosing sensitive information; fragments of the private key are entrusted by multiple CA institutions, and a joint signature by more than the threshold number of institutions is required to complete the retrieval operation; when an abnormal retrieval request is detected, the account is automatically frozen and the consortium chain node consensus audit is triggered to prevent malicious attackers from brute-forcing;

[0111] The smart contract controls the key decryption permission:

[0112] The original data is stored using AES-256 symmetric encryption, and the key is protected by HSM and dynamically authorized for access through the smart contract; RSA-4096 or ECC-521 asymmetric encryption is used to establish a secure communication link to prevent man-in-the-middle attacks;

[0113] Encode the access policy into smart contract logic. For example, release the decryption key fragment only when the user attributes meet "department = internal medicine & professional title ≥ attending physician". The code formula is:

[0114]

[0115] Automatically optimize the encryption policy (such as upgrading sensitive data fields to homomorphic encryption) by analyzing access logs through machine learning.

[0116] Example 2

[0117] Please refer to Figure 2 , based on Example 1, this example also provides a blockchain-based data access permission control method, including the following specific steps:

[0118] Step 1: Adopt a role stratification strategy and define the access granularity of roles through smart contracts;

[0119] Step 2: During the permission allocation process, follow the principle of least privilege, and dynamically adjust the permission scope by analyzing user behavior in real time through machine learning; introduce attribute encryption and zero-knowledge proof, dynamically generate access keys according to user attributes, and hide sensitive information during the verification process;

[0120] Step 3: Encode the smart contract through permission rules, automatically execute access request verification, store encrypted data through a private chain, manage indexes and access policies through a consortium chain, isolate the storage domain and the access domain, and data requests need to pass through a cross-chain verification mechanism for process traceability;

[0121] Step 4: Use a hardware security module to generate a true random number private key, distribute and update the key in combination with the PKI system; after the end of the private key usage period, trigger key rotation, and retrieve the key through an off-chain CA institution; store the data body through symmetric encryption, protect the transmission channel through asymmetric encryption, and the smart contract controls the key decryption permission.

[0122] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented using software, the above embodiments can be implemented in whole or in part in the form of a computer program product. Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are executed in hardware or software depends on the specific application and design constraints of the technical solution.

[0123] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units. They may be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0124] The above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed by the present application, and all should be covered by the protection scope of the present application.

Claims

1. A blockchain-based data access permission control system, characterized in that The system includes: A hierarchical permission module that adopts a role - hierarchical strategy and defines the access granularity of roles through smart contracts; A dynamic permission adjustment module that follows the principle of least privilege during the permission allocation process, and dynamically adjusts the permission scope by analyzing user behavior in real - time through machine learning; introducing attribute - based encryption and zero - knowledge proof, dynamically generating access keys according to user attributes, and hiding sensitive information during the verification process; A multi - chain collaboration module that encodes smart contracts through permission rules, automatically executes access request verification, stores encrypted data through a private chain, manages indexes and access policies through a consortium chain, isolates the storage domain and the access domain, and data requests need to pass through a cross - chain verification mechanism for process traceability; A key management module that uses a hardware security module to generate true random number private keys, distributes and updates keys in combination with the PKI system; after the end of the private key usage period, triggers key rotation, and retrieves keys through an off - chain CA institution; stores the data ontology through symmetric encryption, protects the transmission channel through asymmetric encryption, and smart contracts control the key decryption permissions.

2. The data access permission control system based on blockchain according to claim 1, characterized in that, The process of defining the access granularity of roles through smart contracts is as follows: Role - level division: Divide system participants into super - administrators, organizational administrators, departmental administrators, and ordinary user levels; Write the role - permission mapping relationship into the on - chain smart contract through Solidity language, and the smart contract forcibly restricts the scope of role - permission allocation; access control driven by smart contracts, through on - chain deposition of permission rules, automates the permission verification process, and isolates permissions between organizations.

3. The data access permission control system based on blockchain according to claim 1, characterized in that The process of dynamically adjusting the permission scope is as follows: The principle of least privilege includes initial permission allocation and real - time permission revocation; Initial permission allocation: Users initially only obtain the basic permissions necessary to complete the current task, and the permission granularity is refined to the API interface level or data field level. The smart contract has a built - in permission whitelist to automatically intercept permission requests that exceed the role scope; Real - time permission revocation: Monitor user operations through blockchain event triggers, and when permission idleness is detected, automatically trigger the smart contract to revoke redundant permissions.

4. A data access permission control system based on blockchain according to claim 3, characterized in that, The process of analyzing user behavior in real - time through machine learning is as follows: Collect user operation logs, construct a user behavior baseline model through an LSTM neural network to identify normal behavior patterns, adopt an unsupervised clustering algorithm to group users, and users of the same role share a behavior feature library.

5. A blockchain-based data access permission control system according to claim 4, characterized in that, The process of dynamically generating access keys according to user attributes is as follows: Obtain user attributes and encode them into an attribute set; generate a dynamic access key through elliptic curve encryption; bind an attribute policy during data encryption. In the key life - cycle management, the validity period of the private key is set to N hours, and after timeout, it is necessary to re - authenticate the attributes through an off - chain CA institution to obtain a new key; in the verification stage, adopt the zk - SNARKs protocol, and the user only needs to submit a proof of the existence of attributes without revealing the specific attribute values.

6. The data access permission control system based on blockchain according to claim 5, wherein, The process of automatically executing access request verification is as follows: The private chain stores encrypted data: Responsible for storing the original encrypted data ontology, using symmetric encryption, and only allowing decryption with keys authorized by smart contracts; Consortium chain management index and access policy: by managing data index, storing permission rules and role attribute mapping table metadata; encoding permission rules into on-chain executable logic through smart contracts.

7. The data access permission control system based on blockchain according to claim 6, wherein The process of the cross-chain verification mechanism is as follows: S301: The user initiates a cross-chain data request through the local chain, carrying a digital identity certificate and attribute proof; S302: The consortium chain calls the smart contract to verify whether the user role attributes match the access policy of the target data; S303: After verification, the alliance chain generates a dynamic access token, triggering the private chain smart contract to release the decryption key fragment of the corresponding data S304: Use a two-phase commit protocol to ensure that cross-chain operations are "completely successful" or "completely rolled back"; Through policy templating, RBAC and ABAC are combined, and the conditional judgment logic is defined through the Solidity smart contract. After modification, it is automatically synchronized to all alliance chain nodes; by setting the maximum waiting time for cross-chain operations, timeout automatically triggers the smart contract rollback; and Merkle proof is used to verify the results of cross-chain operations. The request chain and the processing chain ensure data consistency by comparing the Merkle root hash.

8. A data access permission control system based on blockchain according to claim 7, characterized in that, The process of using a hardware security unit to generate a true random number private key and distributing and updating the key in combination with the PKI system is as follows: Physical entropy source technology is used to generate true random number seeds, and the private key is generated through the TRNG true random number generator built into the hardware security unit. After the private key is generated, it is directly stored in the secure storage area of the HSM, and physical anti-tampering packaging technology is used to deal with side-channel attacks; the private key is divided into multiple fragments and distributedly stored in multiple HSM nodes through the Shamir secret sharing scheme. At least t fragments can be combined to restore the complete private key.

9. A data access permission control system based on blockchain according to claim 1, characterized in that, The process of retrieving the key through the off-chain CA organization and controlling the key decryption authority through the smart contract is as follows: The root CA in the off-chain CA organization is hosted by an off-chain authority, and the sub-CA is dynamically authorized through smart contracts to support a multi-level organizational structure. The user certificate in the alliance chain is bound to the private chain identity through the cross-chain relay protocol to achieve key mutual recognition between heterogeneous systems. AES-256 symmetric encryption is used to store original data, the key is protected by HSM and access is dynamically authorized through smart contracts; RSA-4096 or ECC-521 asymmetric encryption is used to establish a secure communication link, and the access policy is encoded into the smart contract logic.

10. A data access permission control method based on blockchain, characterized in that: The steps include: Step 1: Adopt a role-based hierarchical strategy and define the access granularity of roles through smart contracts; Step 2: Follow the principle of least privilege during permission allocation, analyze user behavior in real time through machine learning, and dynamically adjust permission scopes. Introduce attribute encryption and zero-knowledge proofs to dynamically generate access keys based on user attributes, and hide sensitive information during the verification process. Step 3: Encode the smart contract with permission rules, automatically perform access request verification, and store encrypted data through the private chain. The consortium chain manages indexes and access policies, isolates storage domains from access domains, and requires data requests to pass a cross-chain verification mechanism for process traceability. Step 4: Use a hardware security module to generate a true random number private key, and distribute and update the key in combination with the PKI system; after the end of the private key usage period, trigger key rotation, and retrieve the key through an off-chain CA institution; store the data body using symmetric encryption, protect the transmission channel using asymmetric encryption, and use a smart contract to control the key decryption permission.

Images