A government department knowledge base access permission control method based on a blockchain

Abstract

The application discloses a government department knowledge base access permission control method based on a block chain, relates to the technical field of block chains and information security, and effectively eliminates the performance bottleneck of a single control point and single-point failure risk through common participation in decision-making of distributed nodes, significantly improves the reliability and stability of the system; when multiple departments need to cooperatively update strategies, an intelligent contract based on a threshold multi-signature mechanism can automatically execute a voting aggregation and strategy taking effect process, does not need to rely on manual operation of a central administrator, greatly improves the efficiency and automation level of cross-department cooperation, and ensures the immediacy and consistency of strategy changes; the inherent tamper-proof and traceable characteristics of the block chain provide strong audit protection for the entire permission management process; each time of strategy update request, voting process, final decision and strategy version switching is completely recorded on the chain, forming an undeniable audit clue.

Description

Technical Field

[0001] This invention relates to the fields of blockchain and information security technology, and in particular to a blockchain-based method for controlling access permissions to a government department's knowledge base. Background Technology

[0002] Government department knowledge bases have become a core infrastructure for cross-departmental collaborative work and data sharing. Their access control is directly related to data security and administrative efficiency. With the deepening of the digital transformation of government, the access control policy of the knowledge base needs to be jointly formulated and maintained by multiple departments at the same level or above and below. For example, an important policy knowledge involving people's livelihood services needs to be defined by multiple business departments such as finance, civil affairs, and human resources and social security in collaboration to define its access scope and operation permissions.

[0003] To address these needs, existing technologies often employ attribute-based access control ABAC models or policy management platforms. These systems allow permission policies to be associated with dynamic factors such as organizational attributes and resource sensitivity levels, and are configured uniformly through a centralized policy management point. Some systems introduce workflow engines to drive the approval process for policy changes, or establish policy synchronization interfaces between departments to achieve consistent updates of cross-domain permission policies.

[0004] However, in practical applications, when dealing with policy changes proposed concurrently by multiple departments, the centralized policy management node experiences delays in the policy synchronization process, which can lead to inconsistencies in the policy status observed by different departments within a short period of time. Furthermore, the final policy change still depends on the operation of the central administrator, making it difficult to achieve truly decentralized collaborative decision-making and automatic implementation. Summary of the Invention

[0005] In view of the aforementioned existing problems, the present invention is proposed.

[0006] This invention provides a blockchain-based access control method for government department knowledge bases to address the problems of low collaborative update efficiency, synchronization delay, reliance on manual operation, and lack of a reliable auditing mechanism in existing centralized permission policy management systems.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] This invention provides a blockchain-based method for access control of government department knowledge bases, comprising:

[0009] Step S1: Construct a government consortium blockchain. The consortium blockchain consists of multiple departmental nodes, each of which corresponds to a government department and holds a verifiable digital identity.

[0010] Step S2: The access permission policy is written into a policy management smart contract and deployed to the government consortium blockchain. The contract is used to receive, verify and govern policy updates.

[0011] Step S3: When a policy update request is detected, the policy management smart contract verifies the requester's digital signature and permissions.

[0012] Step S4: After at least N department nodes among the M department nodes with voting rights complete the signature confirmation, the strategy management smart contract automatically executes the strategy update and generates the corresponding strategy digest hash and strategy version number.

[0013] Step S5: Write the strategy digest hash and location information into the on-chain transaction as evidence, and store the strategy text in a controlled distributed object storage.

[0014] Step S6: Deploy the Policy Execution Point (PEP) at the front end of the knowledge base. When an access request is received, the PEP obtains or verifies the locally cached policy text based on the current valid policy version number and location information recorded on the chain, generates an access decision, and outputs it.

[0015] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the department nodes complete node registration and certificate management through a trusted government CA or an equivalent consortium blockchain identity mechanism. The voting rights of the nodes are recorded in a whitelist manner in the strategy management smart contract and can be changed according to the version.

[0016] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the conditions for policy updates include:

[0017] A threshold multi-signature mechanism is used to approve update requests, requiring at least N-of-M confirmation.

[0018] It supports configuring voting weights and veto rules for different department nodes, and the contract aggregates and determines the voting results;

[0019] If the vote does not reach the threshold or there is a veto, the update request will automatically expire or enter the revision process;

[0020] The specific rules for the aggregation of voting weights and the priority determination of rejection in the threshold multi-signature voting are as follows:

[0021] In the whitelist of the strategy management smart contract, each department node is registered with voting weight and veto permission flags. The weights are stored in a versioned manner and are updated as the organizational structure changes. Veto permissions are only granted to the minimum set determined by governance.

[0022] The contract receives timestamped approval / disapproval / abstention instructions from each node within the voting window, verifies digital signatures and voting eligibility, and records invalid or duplicate instructions in the audit but does not participate in aggregation;

[0023] If any node with veto power submits a veto command within the window, the update request will directly enter the failure or revision branch. This decision is made before weight aggregation.

[0024] Assuming no vetoes exist, the approval instructions are weighted and compared with a threshold. If the participation condition of approval by at least N different nodes is met, the execution branch is initiated.

[0025] ,

[0026] in, This represents the weighted sum of the approval instructions, with dimensions that are dimensionless. Indicates the index of the department node with voting rights. This indicates the number of department nodes with voting rights, expressed in units. Represents a node The voting weight is a non-negative real number. Represents a node The approval indicator variable takes a value of 1 for approval and 0 for dissent or abstention. This indicates the weight threshold, with dimensions consistent with the left side;

[0027] In the formula:

[0028] ,

[0029] in, This represents the threshold coefficient, with a range of values. ;

[0030] If the voting window expires before the threshold is reached or before N-of-M is reached, a request is made to enter the revision branch;

[0031] For each vote, a strategy-level proof of the commitment value and aggregation result is generated, including a summary of the voting window, weight version, approval set, and rejection record. This proof is stored on the blockchain and bidirectionally associated with the update transaction.

[0032] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the PEP uses an attribute-based access control model to match subject attributes, resource attributes, environmental attributes, and operational attributes when performing access control.

[0033] The subject attributes include at least the department and job level, the resource attributes include at least the data security level and subject classification, the environmental attributes include at least the access time and network environment, and the operation attributes include at least reading, editing, and downloading.

[0034] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the PEP maintains a local cache of the policy and records the corresponding policy version number. Incremental synchronization is triggered when a higher version number appears on the chain.

[0035] In the event that object storage is unreachable, PEP continues to perform business operations within the cache validity period and completes verification and re-entry upon recovery.

[0036] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the user attributes in the access request are verified using a zero-knowledge attribute proof protocol.

[0037] Users submit verifiable proofs of policy predicates to the PEP without revealing plaintext attributes;

[0038] PEP calls the verification component to check the validity of the proof and the revocation status, and only determines that the proof is valid and satisfies the policy predicate;

[0039] The mapping and verification relationship between the attributes and policy predicates in the zero-knowledge attribute proof is as follows:

[0040] The set of predicates for the currently valid policy version on the PEP loading chain is used to normalize the subject / resource / environment / operation attribute key-domain-comparison clauses to form policy predicates. An abstract syntax tree that limits operations and unit scope;

[0041] On the user side, the attributes to be used are encoded into vectors and a commitment vector is generated. We promise to only bind the data and not disclose plaintext. The cancellation status and validity period will be submitted as separate evidence along with the proof.

[0042] The governance side is a strategy predicate. Compilation yields the constraint system and verification keys. And record the predicate digest hash. Based on the policy version metadata, PEP selects the matching verification key;

[0043] User made a promise Generating zero-knowledge proofs with local property witnesses and will Submit to PEP if the strategy contains multiple sub-forms;

[0044] Under the premise of being bound to the current policy version and key version, PEP only performs a verification or non-verification judgment on submitted materials, and the relationship is as follows:

[0045] ,

[0046] in, This represents a zero-knowledge verification algorithm. Indicates the verification key. Indicating strategy predicates digest hash, Represents the commitment vector. This represents zero-knowledge proof. Represents a user attribute vector. Indicates the commitment random factor, Represents the commitment function, This indicates that the attribute satisfies the strategy predicate;

[0047] When the verification is successful, PEP synchronously checks whether the policy version number and key version match. For revocation and expiration, it reads the revocation list or accumulator witness. If revocation or expiration occurs, it is judged as a failure and the reason is recorded.

[0048] For invalid signature, key version mismatch, predicate failure, undo hit, and time window out of bounds, provide the failure type respectively. Generate an audit summary, write it to the on-chain event, and associate it with the access log segment.

[0049] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the processing of access logs includes:

[0050] The access logs are segmented according to fixed time windows, and Merkle roots are generated within each segment.

[0051] The Merkle root of each segment will be uploaded to the blockchain for verification according to the set period.

[0052] Detailed logs are stored in the controlled object or a local database and are supported for verifiable evidence collection through on-chain location information and Merkle paths.

[0053] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the policy version management includes:

[0054] Each policy update is assigned a monotonically increasing policy version number; the version history is recorded on-chain; after a department node with voting rights completes multi-signature confirmation again, rollback to a specified historical version is allowed and the local cache of PEP is updated synchronously.

[0055] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, cross-domain collaboration includes:

[0056] Establish a cross-chain verification mechanism to achieve policy mutual recognition with external government consortium blockchains;

[0057] Verify the validity of the other party's on-chain policy digest hash and version number through cross-chain contracts or equivalent light client / relay solutions, and complete the corresponding synchronization and notarization on this chain.

[0058] As a preferred embodiment of the blockchain-based access control method for government department knowledge bases described in this invention, the strategy management smart contract provides an approval workflow and event notification interface: it records events such as update failure, version switching, rollback execution, and cross-chain synchronization completion on the blockchain and pushes notifications to the subscribed department nodes.

[0059] The beneficial effects of this invention are as follows: By enabling distributed nodes to participate in decision-making, this invention effectively eliminates the performance bottlenecks and single-point-of-failure risks of a single control point, significantly improving the reliability and stability of the system. When multiple departments need to collaboratively update policies, smart contracts based on threshold multi-signature mechanisms can automatically execute voting aggregation and policy activation processes without relying on manual operation by a central administrator, greatly improving the efficiency and automation level of cross-departmental collaboration and ensuring the timeliness and consistency of policy changes. The inherent immutability and traceability of blockchain provide strong audit protection for the entire permission management process. Every policy update request, voting process, final decision, and policy version switch is fully recorded on the chain, forming an undeniable audit trail, enabling any violations or abuse of permissions to be accurately traced and held accountable, greatly enhancing the security and credibility of the system.

[0060] This invention improves efficiency and security while also addressing privacy concerns. By introducing zero-knowledge proof technology, users do not need to present their sensitive attribute credentials in plaintext when requesting access; they only need to prove that they meet the policy requirements. This effectively prevents the risk of leakage of user privacy information during the verification process, achieving data usability without visibility, and meeting the stringent requirements for government data security management.

[0061] This invention offers excellent flexibility and scalability. The version management mechanism allows the system to securely roll back to a historical policy state when necessary, ensuring business continuity. Furthermore, the introduction of a cross-chain verification mechanism lays the foundation for future mutual recognition and collaboration of permissions between different government blockchain systems, supporting the construction of a larger-scale, integrated, and trusted digital government infrastructure.

[0062] In summary, this invention not only solves the core pain points of existing technologies, but also achieves comprehensive improvements in multiple dimensions such as security, efficiency, privacy, and scalability. Attached Figure Description

[0063] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0064] Figure 1 This is a flowchart illustrating the access control method for government department knowledge bases in this embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0067] For example, the terms “first” and “second” used in this application are only used to distinguish and describe similar objects, to differentiate the first object from another object, and are not used to describe a specific order or sequence, nor should they be interpreted as indicating or implying relative importance.

[0068] This application proposes a blockchain-based access control method for government department knowledge bases, combining... Figure 1 As shown, the method includes:

[0069] Step S1: Construct a government consortium blockchain. The consortium blockchain consists of multiple departmental nodes, each of which corresponds to a government department and holds a verifiable digital identity.

[0070] In this embodiment, the government consortium blockchain refers to a consortium-type distributed ledger jointly maintained by government departments, possessing access governance and auditability characteristics; departmental nodes refer to accounting and voting entities holding valid institutional certificates and approved by access governance, capable of undertaking proposal, voting, notarization, and synchronization responsibilities. The default consensus finality is measured by block confirmation depth, with K=3 and an adjustable range of [1, 12], set according to the historical block production stability and regulatory compliance requirements; the maximum node clock synchronization deviation Δt defaults to ≤500 ms, adjustable [100, 1000] ms, set according to message delay distribution and voting window; the certificate revocation list refresh cycle defaults to 10 min, adjustable [1, 60] min, determined according to the superior CA strategy. Optionally, node identities can be uniformly issued by the government CA or recorded by the consortium blockchain identity contract using an equivalent certificate fingerprint, with input and output consistent. Necessary exception handling involves temporarily using a snapshot of the last successfully synchronized CRL and downgrading node permissions to read-only when the CRL is unreachable, until the CRL is restored.

[0071] Step S2: The access permission policy is written as a policy management smart contract and deployed to the government consortium blockchain. The contract is used to receive, verify and govern policy updates.

[0072] Specifically, the strategy management smart contract performs integrity verification on the structured fields of the strategy text. These fields include at least the strategy identifier, strategy version number, applicable resource set, strategy predicate set, publisher identifier, public key fingerprint, and validity window. The strategy text defaults to structured text encoding, with a maximum single text size of ≤256 KB by default, adjustable from [64 KB, 1 MB], based on on-chain transaction size and object storage throughput. Strategy proposals are subject to departmental rate limits, defaulting to ≤30 proposals per department per hour, adjustable from [5, 100] proposals per hour, based on governance rules and historical load. The voting window defaults to 10 minutes, adjustable from [1, 60] minutes, based on cross-departmental network latency and working hours. Optionally, field encoding uses JSON or equivalent binary object encoding to maintain consistency between field semantics and the signature verification process. In abnormal situations, if fields are missing or exceed limits, the contract refuses to process the proposal and returns an auditable reason code.

[0073] Step S3: When a policy update request is detected, the policy management smart contract verifies the requester's digital signature and permissions.

[0074] Step S4: After at least N department nodes among the M department nodes with voting rights complete the signature confirmation, the strategy management smart contract automatically executes the strategy update and generates the corresponding strategy digest hash and strategy version number.

[0075] For example, M represents the number of departmental nodes with voting rights, and N represents the minimum number of approval nodes. The default threshold coefficient is 0.67, adjustable [0.5, 1.0], set according to governance red lines and risk assessments. Approval, opposition, and abstention instructions within the voting window are bound with timestamps and digital signatures. Duplicate or invalid instructions are only used for auditing and do not participate in aggregation. Voting weights are obtained from versioned weights recorded in the contract whitelist; approval indicator variables are parsed from signature approval instructions; threshold values ​​are calculated from the threshold coefficient and the sum of current weights; M and N are published together by governance rules before the version switch takes effect. Optionally, the minimum set of veto rights granted is determined through governance proposals and takes precedence over weight aggregation. Necessary boundary handling is that if the threshold or participation condition is not met by the end of the voting window, a request is made to enter the revision branch and the audit trail is preserved.

[0076] Step S5: Write the strategy digest hash and location information into the on-chain transaction as evidence, and store the strategy text in a controlled distributed object storage.

[0077] In this embodiment, the location information refers to the content addressing identifier that can uniquely locate the policy text or the unified resource identifier in the controlled object storage, including integrity verification metadata. The policy digest hash defaults to a hash algorithm that meets collision resistance requirements, selected based on the cryptographic compliance list; the number of object storage replicas is 3 by default, adjustable [2,5], set according to the disaster recovery level; the maximum propagation delay for policy distribution is 30 s by default, adjustable [5,120] s, set according to network bandwidth and the number of nodes. Optionally, on-chain notarization precedes or runs concurrently with object storage, but a version state machine ensures that notarization has been completed and can be retrieved before external release. The necessary exception handling is that when object storage writing fails but on-chain notarization has already occurred, the version is marked as pending re-notarization and prohibited from external use until re-notarization is successful.

[0078] Step S6: Deploy the Policy Execution Point (PEP) at the front end of the knowledge base. When an access request is received, the PEP obtains or verifies the locally cached policy text based on the current valid policy version number and location information recorded on the chain, generates an access decision, and outputs it.

[0079] Furthermore, PEP performs semantic verification and predicate compilation on the policy text before caching it. The cache validity period (TTL) is 10 minutes by default and can be adjusted to [1, 60] minutes, depending on the policy update frequency. The time limit for a single access decision is no more than 200ms by default and can be adjusted to [50, 500] ms, depending on the concurrency and service level. The on-chain query timeout threshold is 2 seconds by default and can be adjusted to [0.5, 10] seconds. Optionally, when a higher version number is detected on the chain, PEP prefetches the new version incrementally in the background and switches after completing the consistency verification. In abnormal situations, such as on-chain query timeout or object storage unreachable, PEP continues to execute according to the most recent valid version within the cache TTL and writes the downgrade reason into the access audit.

[0080] In one embodiment, departmental nodes complete node registration and certificate management through a trusted government CA or an equivalent consortium blockchain identity mechanism. The voting rights of nodes are recorded in a whitelist manner in the strategy management smart contract and can be changed according to the version.

[0081] In one embodiment, the pass conditions for policy updates include:

[0082] A threshold multi-signature mechanism is used to approve update requests, requiring at least N-of-M confirmation.

[0083] It supports configuring voting weights and veto rules for different department nodes, and the contract aggregates and determines the voting results;

[0084] If the vote does not reach the threshold or there is a veto, the update request will automatically expire or enter the revision process;

[0085] The specific rules for weighting and prioritizing vetoes in multi-signature voting are as follows:

[0086] In the whitelist of the strategy management smart contract, each department node is registered with voting weight and veto permission flags. The weights are stored in a versioned manner and are updated as the organizational structure changes. The veto permission is only granted to the minimum set determined by governance.

[0087] The contract receives timestamped approval / disapproval / abstention instructions from each node within the voting window, verifies digital signatures and voting eligibility, and records invalid or duplicate instructions in the audit but does not participate in aggregation;

[0088] If any node with veto power submits a veto command within the window, the update request will directly enter the failure or revision branch. This decision is made before weight aggregation to reduce unnecessary on-chain computation and external coordination overhead.

[0089] Assuming no vetoes exist, the approval instructions are weighted and compared with a threshold. If the participation condition of approval by at least N different nodes is met, the execution branch is initiated.

[0090] ,

[0091] in, This represents the weighted sum of the approval instructions, with dimensions that are dimensionless. Indicates the index of the department node with voting rights. This indicates the number of department nodes with voting rights, expressed in units. Represents a node The voting weight is a non-negative real number. Represents a node The approval indicator variable takes a value of 1 for approval and 0 for dissent or abstention. This indicates the weight threshold, and its dimensions are the same as those on the left.

[0092] In the formula:

[0093] ,

[0094] in, This represents the threshold coefficient, with a range of values. ;

[0095] When the voting window expires without reaching the threshold or N-of-M, a request is made to enter the revision branch. The revision proposal can reuse the previous version's whitelist or submit a draft of changes to the weights and window parameters to enter a new round of governance.

[0096] The strategy-level proof of the commitment value and aggregation result generated for each vote includes a summary of the voting window, weight version, approval set and rejection record. It is stored on the chain and bidirectionally associated with the update transaction, which facilitates post-event review and cross-domain collaborative reference.

[0097] Similarly, commitment values ​​are used to bind voting materials to time windows to avoid replays; strategy-level proofs are provided to the audit and compliance departments in read-only mode for retrieval. The minimum retention period for audit data is 5 years by default, adjustable to [3, 10] years, determined according to the file management specifications; the maximum confirmation waiting time for on-chain evidence storage is 60 seconds by default, adjustable to [10, 300] seconds, set according to the on-chain block interval and business timeliness. Optionally, the commitment function adopts a general commitment scheme or equivalent implementation that satisfies binding and concealment, keeping the input index consistent with the audit query interface. In abnormal situations, if the audit transaction is not packaged within the confirmation waiting time, the contract triggers a re-submission mechanism, retrying 3 times by default, adjustable to [1, 5] times.

[0098] Specifically, this rule introduces a two-layer judgment of weighted aggregation and veto priority under the original N-of-M threshold multi-signature framework, forming an execution chain of veto first, aggregation later, and parallel participation constraints; veto priority puts risk control of highly sensitive departments forward, reducing unnecessary voting and cross-system synchronization; weighted aggregation adjusts the threshold with governance parameters, which can reflect the distribution of departmental responsibilities and avoid a few high-weight nodes from having too strong an influence when they are not given veto authority;

[0099] The participation requirement requires a minimum number of approved nodes, suppressing the situation where a group of high-weight nodes advance alone; timeouts and revision branches provide a buffer for collaboration, facilitating secondary agenda setting on policy texts, weight schemes, or voting windows; end-to-end auditing and commitment notarization provide a traceable basis for subsequent review and cross-chain mutual recognition, maintaining consistent governance semantics and evidence collection capabilities in the interaction of object storage and policy version switching.

[0100] In one embodiment, PEP uses an attribute-based access control model to match subject attributes, resource attributes, environment attributes, and operation attributes when performing access control.

[0101] The main attributes should at least include the department and job level; the resource attributes should at least include the data security level and subject classification; the environmental attributes should at least include the access time and network environment; and the operation attributes should at least include reading, editing, and downloading.

[0102] In one embodiment, the PEP maintains a local cache of the policy and records the corresponding policy version number. When a higher version number appears on the chain, incremental synchronization is triggered.

[0103] In the event that object storage is unreachable, PEP continues to perform business operations within the cache validity period and completes verification and re-recording after recovery;

[0104] In one embodiment, user attributes in the access request are verified using a zero-knowledge attribute proof protocol:

[0105] Users submit verifiable proofs of policy predicates to the PEP without revealing plaintext attributes;

[0106] PEP calls the verification component to check the validity of the proof and the revocation status, and only determines that the proof is valid and satisfies the policy predicate;

[0107] The mapping and verification relationship between attributes and policy predicates in zero-knowledge attribute proofs is as follows:

[0108] The set of predicates for the currently valid policy version on the PEP loading chain is used to normalize the subject / resource / environment / operation attribute key-domain-comparison clauses to form policy predicates. An abstract syntax tree that limits operations (equality, range, set inclusion, threshold logic) and unit scope;

[0109] On the user side, the attributes to be used are encoded into vectors and a commitment vector is generated. We promise to only bind the data and not disclose plaintext. The cancellation status and validity period will be submitted as separate evidence along with the proof.

[0110] The governance side is a strategy predicate. Compilation yields the constraint system and verification keys. And record the predicate digest hash. Based on the policy version metadata, PEP selects the matching verification key;

[0111] User made a promise Generating zero-knowledge proofs with local property witnesses and will Submit to PEP; if the strategy contains multiple sub-forms, batch proofs using parallel or threshold combinations can be employed.

[0112] Under the premise of being bound to the current policy version and key version, PEP only performs a verification or non-verification judgment on submitted materials, and the relationship is as follows:

[0113] ,

[0114] in, This represents a zero-knowledge verification algorithm. Indicates the verification key. Indicating strategy predicates digest hash, Represents the commitment vector. This represents zero-knowledge proof. Represents a user attribute vector. Indicates the commitment random factor, Represents the commitment function, This indicates that the attribute satisfies the strategy predicate;

[0115] When the verification is successful, PEP synchronously checks whether the policy version number and key version match. For revocation and expiration, it reads the revocation list or accumulator witness. If revocation or expiration occurs, it is judged as a failure and the reason is recorded.

[0116] For invalid signature, key version mismatch, predicate failure, undo hit, and time window out of bounds, provide the failure type respectively. Generate an audit summary, write it to the on-chain event, and associate it with the access log segment;

[0117] Specifically, this mapping transforms predicates in access control from textual rules into a verifiable constraint system. Users bind attributes with commitments and then provide satisfaction proofs in a zero-knowledge manner. PEP only needs to verify the consistency of the verification key, predicate digest, and proof to complete the authorization decision. This path moves the plaintext of attributes to the user side, and only records the summary information related to the policy version on the chain, reducing the data exposure surface. Revocation and validity period are verified in parallel, so that the published proofs become invalid after a governance event, which is in line with the requirements of identity lifecycle management in government scenarios. Failure paths are broken down to specific reasons, which makes it easier to locate gaps in the approval workflow. At the same time, the audit digest links the policy version, predicate digest, and verification results, providing matching anchors for cross-domain collaboration and evidence collection.

[0118] In one embodiment, the processing of access logs includes:

[0119] The access logs are segmented according to fixed time windows, and Merkle roots are generated within each segment.

[0120] The Merkle root of each segment will be uploaded to the blockchain for verification according to the set period.

[0121] Specifically, access logs are segmented according to fixed time windows. The default time window ΔT is 5 minutes, adjustable to [1, 30] minutes, depending on business peaks and audit granularity. The maximum number of leaf entries per segment is 10,000 by default, adjustable to [1,000, 100,000]. If the limit is exceeded, the segment is automatically split into adjacent segments and cross-segment references are established. The on-chain period is consistent with ΔT by default, but can be adjusted to an integer multiple thereof, depending on on-chain transaction fees and regulatory timeliness. Optionally, empty windows are marked with placeholder roots to maintain continuity. In abnormal situations, such as verification failure within a segment, a corresponding error flag is generated, and the on-chain of that segment root is blocked. At the same time, reconstructable details are stored in an isolation area for later reconstruction.

[0122] Detailed logs are stored in controlled object storage or a local database and support verifiable evidence collection through on-chain location information and Merkle paths;

[0123] In one embodiment, policy version management includes:

[0124] Assign a monotonically increasing strategy version number to each strategy update; record version history on the chain; after a department node with voting rights completes multi-signature confirmation again, rollback to a specified historical version is allowed and the local cache of PEP is updated synchronously.

[0125] For example, the rollback target is uniquely indicated by the version number, and the rollback operation is treated as a new version release. The rollback freeze window is 10 minutes by default, adjustable to [1, 60] minutes to avoid conflicts with ongoing updates. Upon receiving a rollback event, a PEP should complete the version replacement within 60 seconds, adjustable to [10, 300] seconds, depending on the node size. Optionally, the contract verifies the object storage retrievability and digest consistency of the target version before rollback; if these conditions are not met, the rollback is rejected. In abnormal situations, such as some PEPs failing to switch within the time limit, the contract continuously broadcasts the version status and provides a catch-up interface until all nodes achieve consistency.

[0126] In one embodiment, cross-domain collaboration includes:

[0127] Establish a cross-chain verification mechanism to achieve policy mutual recognition with external government consortium blockchains;

[0128] Verify the validity of the other party's on-chain policy digest hash and version number through cross-chain contracts or equivalent light client / relay solutions, and complete the corresponding synchronization and notarization on this chain.

[0129] Similarly, the minimum confirmation depth for cross-chain verification defaults to Kremote=2 on the other chain, adjustable [1, 12], based on the finality setting of the other chain's consensus; the cross-chain message timeout defaults to 30 s, adjustable [5, 300] s, based on cross-domain network latency; replay protection is implemented through a unique session identifier and sequence window, with a default sequence window size of 1024, adjustable [128, 4096]. Optionally, when the other chain is unavailable, a manual review channel is entered to prevent the local chain's policy from being automatically overridden. In abnormal situations, if cross-chain verification fails or times out, the reason for the failure is recorded and the status is set to pending review, without triggering synchronization.

[0130] In one embodiment, the strategy management smart contract provides an approval workflow and event notification interface: it records events such as update failure, version switching, rollback execution, and cross-chain synchronization completion on the chain and pushes notifications to the subscribed department nodes for manual review and auditing.

[0131] Optionally, the event notification interface supports both polling and callback delivery modes. The default number of callback retries is 3, adjustable from [1,5] times; the default minimum retry interval is 30 seconds, adjustable from [5,120] seconds, depending on the availability of the receiver; the default minimum retention period for event archiving is 5 years, adjustable from [3,10] years, depending on the archive management specifications. Necessary exception handling is as follows: when a subscribed node is unreachable, the event is placed in a delayed queue and retained for 24 hours, adjustable from [1,72] hours. If the node remains unreachable after the retention period, only the on-chain record is retained as the final basis.

[0132] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0133] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A blockchain-based access control method for government department knowledge bases, characterized in that, include, Step S1: Construct a government consortium blockchain. The consortium blockchain consists of multiple departmental nodes, each of which corresponds to a government department and holds a verifiable digital identity. Step S2: The access permission policy is written into a policy management smart contract and deployed to the government consortium blockchain. The contract is used to receive, verify and govern policy updates. Step S3: When a policy update request is detected, the policy management smart contract verifies the requester's digital signature and permissions. Step S4: After at least N department nodes among the M department nodes with voting rights complete the signature confirmation, the strategy management smart contract automatically executes the strategy update and generates the corresponding strategy digest hash and strategy version number. Step S5: Write the strategy digest hash and location information into the on-chain transaction as evidence, and store the strategy text in a controlled distributed object storage. Step S6: Deploy the Policy Execution Point (PEP) at the front end of the knowledge base. When an access request is received, the PEP obtains or verifies the locally cached policy text based on the current valid policy version number and location information recorded on the chain, generates an access decision, and outputs it.

2. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, The departmental nodes complete node registration and certificate management through a trusted government CA or an equivalent consortium blockchain identity mechanism. The voting rights of the nodes are recorded in a whitelist in the strategy management smart contract and can be changed according to the version.

3. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, The conditions for passing a policy update include: A threshold multi-signature mechanism is used to approve update requests, requiring at least N-of-M confirmation. It supports configuring voting weights and veto rules for different department nodes, and the contract aggregates and determines the voting results; If the vote does not reach the threshold or there is a veto, the update request will automatically expire or enter the revision process; The specific rules for the aggregation of voting weights and the priority determination of rejection in the threshold multi-signature voting are as follows: In the whitelist of the strategy management smart contract, each department node is registered with voting weight and veto permission flags. The weights are stored in a versioned manner and are updated as the organizational structure changes. Veto permissions are only granted to the minimum set determined by governance. The contract receives timestamped approval / disapproval / abstention instructions from each node within the voting window, verifies digital signatures and voting eligibility, and records invalid or duplicate instructions in the audit but does not participate in aggregation; If any node with veto power submits a veto command within the window, the update request will directly enter the failure or revision branch. This decision is made before weight aggregation. Assuming no vetoes exist, the approval instructions are weighted and compared with a threshold. If the participation condition of approval by at least N different nodes is met, the execution branch is initiated. ， in, This represents the weighted sum of the approval instructions, with dimensions that are dimensionless. Indicates the index of the department node with voting rights. This indicates the number of department nodes with voting rights, expressed in units. Represents a node The voting weight is a non-negative real number. Represents a node The approval indicator variable takes a value of 1 for approval and 0 for dissent or abstention. This indicates the weight threshold, and its dimensions are the same as those on the left. In the formula: ， in, This represents the threshold coefficient, with a range of values. ; If the voting window expires before the threshold is reached or before N-of-M is reached, a request is made to enter the revision branch; For each vote, a strategy-level proof of the commitment value and aggregation result is generated, including a summary of the voting window, weight version, approval set, and rejection record. This proof is stored on the blockchain and bidirectionally associated with the update transaction.

4. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, The PEP uses an attribute-based access control model to match subject attributes, resource attributes, environment attributes, and operation attributes when performing access control. The subject attributes include at least the department and job level, the resource attributes include at least the data security level and subject classification, the environmental attributes include at least the access time and network environment, and the operation attributes include at least reading, editing, and downloading.

5. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, PEP maintains a local cache of the policy and records the corresponding policy version number. When a higher version number appears on the chain, incremental synchronization is triggered. In the event that object storage is unreachable, PEP continues to perform business operations within the cache validity period and completes verification and re-entry upon recovery.

6. The blockchain-based access control method for government department knowledge bases as described in claim 4, characterized in that, User attributes in the access request are validated using a zero-knowledge attribute proof protocol: Users submit verifiable proofs of policy predicates to the PEP without revealing plaintext attributes; PEP calls the verification component to check the validity of the proof and the revocation status, and only determines that the proof is valid and satisfies the policy predicate; The mapping and verification relationship between the attributes and policy predicates in the zero-knowledge attribute proof is as follows: The set of predicates for the currently valid policy version on the PEP loading chain is used to normalize the subject / resource / environment / operation attribute key-domain-comparison clauses to form policy predicates. An abstract syntax tree that limits operations and unit scope; On the user side, the attributes to be used are encoded into vectors and a commitment vector is generated. We promise to only bind the data and not disclose plaintext. The cancellation status and validity period will be submitted as separate evidence along with the proof. The governance side is a strategy predicate. Compilation yields the constraint system and verification keys. And record the predicate digest hash. Based on the policy version metadata, PEP selects the matching verification key; User based on commitment vector Zero-knowledge proofs generated with local property witnesses and will Submit to PEP if the strategy contains multiple sub-forms; Under the premise of being bound to the current policy version and key version, PEP only performs a verification or non-verification judgment on submitted materials, and the relationship is as follows: ， in, This represents a zero-knowledge verification algorithm. Indicates the verification key. Indicating strategy predicates digest hash, Represents the commitment vector. This represents zero-knowledge proof. Represents a user attribute vector. Indicates the commitment random factor, Represents the commitment function, This indicates that the attribute satisfies the policy predicate. Indicates a strategy predicate; When the verification is successful, PEP synchronously checks whether the policy version number and key version match. For the revocation status and validity period, it reads the revocation list or accumulator witness. If revocation or expiration occurs, it is judged as a failure and the reason is recorded. For invalid signature, key version mismatch, predicate failure, undo hit, and time window out of bounds, provide the failure type respectively. Generate an audit summary, write it to the on-chain event, and associate it with the access log segment.

7. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, Access log processing includes: The access logs are segmented according to fixed time windows, and Merkle roots are generated within each segment. The Merkle root of each segment will be uploaded to the blockchain for verification according to the set period. Detailed logs are stored in the controlled object or a local database and are supported for verifiable evidence collection through on-chain location information and Merkle paths.

8. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, Policy version management includes: Each policy update is assigned a monotonically increasing policy version number; the version history is recorded on-chain; after a department node with voting rights completes multi-signature confirmation again, rollback to a specified historical version is allowed and the local cache of PEP is updated synchronously.

9. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, Cross-domain collaboration includes: Establish a cross-chain verification mechanism to achieve policy mutual recognition with external government consortium blockchains; Verify the validity of the other party's on-chain policy digest hash and version number through cross-chain contracts or equivalent light client / relay solutions, and complete the corresponding synchronization and notarization on this chain.

10. The blockchain-based access control method for government department knowledge bases as described in claim 1, characterized in that, The strategy management smart contract provides an approval workflow and event notification interface: it records events such as update failure, version switching, rollback execution, and cross-chain synchronization completion on the blockchain and pushes notifications to subscribed department nodes.

Images