Block chain-based trusted data space cross-domain access control method, system and device, and medium

Abstract

The invention relates to the technical field of data cross-domain access control, in particular to a block chain-based trusted data space cross-domain access control method, system and device and a medium, comprising: receiving a data access request, and analyzing a target data identifier, a target heterogeneous system identifier and access scene information; obtaining the data attribute of the target data according to the target data identifier, generating a dynamic access strategy in combination with the access scene information, and deploying the dynamic access strategy into the block chain; mapping the dynamic access strategy into an equivalent access control rule, and converting the data access request into target compatible request data; verifying zero-knowledge proof provided by the user based on an equivalent access control rule and a user public key; after the verification is passed, routing the target compatible request data to the target heterogeneous system; and the target heterogeneous system generates original response data, converts the original response data into user-side compatible response data and returns the user-side compatible response data to the user. According to the invention, cross-system efficient cooperation is realized, and the real-time adaptability and privacy enhancement security of access control can be improved.

Description

Technical Field

[0001] This application relates to the field of cross-domain data access control technology, specifically to a blockchain-based trusted data space cross-domain access control method, system, device, and medium. Background Technology

[0002] The demand for data sharing in cross-domain scenarios such as healthcare, government affairs, and finance is growing, making data security and privacy protection key challenges. The concept of a trusted data space has emerged to address this need, aiming to ensure secure, controllable, and compliant data access across heterogeneous systems through technological means. Blockchain technology, due to its decentralized and immutable characteristics, is widely used to build trusted data access control frameworks to support seamless collaboration and regulatory compliance across multiple data sources.

[0003] In existing technologies, cross-domain access control of data is mainly implemented through predefined static policy templates, such as Role-Based Access Control (RBAC) or Attribute-Based Encryption (ABE) mechanisms, used to assign permissions based on user identity or data attributes. To address the interoperability issues between heterogeneous systems, existing methods employ centralized gateways or middleware for protocol conversion and data routing, such as converting RESTful API requests into a format compatible with the target system, ensuring compatibility between different communication protocols and data transmission efficiency.

[0004] However, existing technologies have significant shortcomings. Static policies cannot dynamically adjust permission rules based on data attributes (such as sensitivity) and access scenario information (such as user roles and access times), leading to rigid permission management. When accessing across heterogeneous systems, the policy mapping and protocol conversion relying on centralized gateways are inefficient and prone to introducing single points of failure. The permission verification process lacks privacy protection mechanisms and relies on plaintext or high-overhead encryption technologies, which can easily expose sensitive information. Summary of the Invention

[0005] To address the technical problems of existing cross-domain data access control technologies, such as static policies, low interoperability efficiency and single point of failure due to reliance on centralized gateways, and lack of privacy protection mechanisms in the permission verification process, resulting in rigid permission management, fragile data transmission, and the risk of sensitive information leakage, this application provides a blockchain-based trusted data space cross-domain access control method, system, device, and medium. Through the generation and deployment of dynamic access policies, equivalent rule mapping and compatible format conversion of heterogeneous systems, and decentralized permission verification based on zero-knowledge proofs, it achieves efficient cross-system collaboration, improves the real-time adaptability of access control, and enhances privacy and security.

[0006] Firstly, this application provides a blockchain-based method for cross-domain access control of trusted data spaces, comprising the following steps: S1. Receive data access requests sent by users through the source system, and parse the target data identifier, target heterogeneous system identifier, and access scenario information from the data access requests; The target heterogeneous system identifier points to the target heterogeneous system that holds the target data; S2. Query the preset data attribute repository based on the target data identifier to obtain the data attributes of the target data; Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. S3. Read the dynamic access policies stored in the blockchain and map them to the equivalent access control rules supported by the target heterogeneous system; Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; S4. Verify the zero-knowledge proof provided by the user based on the equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result; The user's public key corresponds to the user's distributed digital identity; Zero-knowledge proofs are generated by users using their distributed digital identity and corresponding user private key to declare that they meet policy permission requirements. S5. When the zero-knowledge proof verification result is successful, route the target compatible request data to the target heterogeneous system; S6. After the target heterogeneous system performs an access operation based on the target compatible request data, it generates raw response data, converts the raw response data into client-side compatible response data that conforms to the source system's compatible format, and returns the client-side compatible response data to the user.

[0007] It should be further noted that during the execution of steps S5-S6, the following operations are performed in real time: The strategy execution log is captured by blockchain nodes, including routing operation records of routing target compatible data to target heterogeneous systems, and response generation and conversion records of generating raw response data and converting it into user-end compatible response data. The policy execution log is compared with the dynamic access policy in real time. When the operation recorded in the policy execution log is found to violate the rules in the dynamic access policy, a permission freeze command is output to trigger the freezing of the user's access permissions.

[0008] It should be further noted that in step S1, the access scenario information includes user role, access time, and compliance requirements.

[0009] It should be further noted that in step S2, the data attributes include data sensitivity attributes and data source attributes.

[0010] It should be further noted that in step S2, the dynamic access policy includes permission requirement declaration predicates, enforcement constraint rules, cross-domain compatibility instructions, and audit metadata; Cross-domain compatibility instructions include protocol conversion parameters and policy mapping rules; Audit metadata includes policy version number, generation timestamp, and user distributed digital identity identifier; When a dynamic access policy is deployed to the blockchain, a current policy state identifier is generated and stored in the blockchain.

[0011] It should be further explained that in step S2, generating a dynamic access strategy by combining data attributes and access scenario information includes: S201. Generate an initial access policy through logical matching operations. The initial access policy includes an initial permission requirement declaration predicate and initial execution constraint rules, wherein: Initial permission requirements include the following for declaring the generation of predicates: Generate comparison condition expressions based on the data sensitivity attributes of the target data; Generate an attribution condition expression based on the user role in the access scenario information; The comparison condition expression and the attribution condition expression are combined into a machine-readable predicate logic to form the initial permission requirement declaration predicate; The generation of initial execution constraint rules includes: Data processing constraints are generated based on compliance requirements in the access scenario information. Data classification and processing instructions are generated based on the data type labels of the target data. Dynamic permission validity parameters are generated based on operation context features; Data processing constraints, data classification and processing instructions, and dynamic permission validity parameters together constitute the initial execution constraint rules; S202. Based on the historical policy execution logs stored on the blockchain, optimize the permission thresholds and condition constraints in the initial access policy to obtain an optimized access policy; S203. Embed cross-domain compatibility instructions and audit metadata into the optimized access policy to obtain a dynamic access policy.

[0012] It should be further explained that in step S202, the method for optimizing the permission thresholds and condition constraints in the initial access policy is as follows: The initial access strategy is input into the trained access strategy optimization model, which is then used to output a dynamic access strategy. The access policy optimization model is constructed using a supervised learning algorithm and trained using historical policy execution logs stored in the blockchain as a sample set.

[0013] It should be further noted that the access strategy optimization model is constructed using the random forest algorithm.

[0014] It should be further noted that in step S3, the communication protocol types of the source system and the target heterogeneous system are obtained using the following method: The type of communication protocol used by the target heterogeneous system is obtained based on the target heterogeneous system identifier; Based on the communication protocol header of the data access request, identify the type of communication protocol used by the source system.

[0015] It should be further explained that the specific steps for generating zero-knowledge proofs in step S4 include: S401. Generate the user's distributed digital identity identifier and the corresponding public-private key pair, the public-private key pair including the user's public key and the user's private key; S402. Extract permission requirement declaration predicates from dynamic access policies; S403. Obtain the tree hash value of the dynamic access policy as a policy integrity identifier; Get the current timestamp; A random number seed is generated using a cryptographic hash function based on the user's private key and the current timestamp; S404. Create a non-interactive proof based on the user's private key, permission requirement declaration predicate, and random number seed. S405. Encapsulate non-interactive proofs, public input parameters, and user distributed digital identity identifiers to generate verifiable zero-knowledge proof data packets.

[0016] It should be further explained that, in step S4, the specific steps for verifying the zero-knowledge proof based on the equivalent access control rules include: S411. Obtain the equivalent access control rules and zero-knowledge proof data packets; S412. Query the user's public key based on the user's distributed digital identity; Timeliness verification is performed based on the current system time and the timestamp within the data packet; Obtain the current policy status identifier of the blockchain storage; S413. Compare the policy integrity identifier with the current policy status identifier to perform integrity verification; Use the user's public key to verify the signature validity of the zero-knowledge proof bytecode; The equivalent access control rules are converted into verifiable logical conditions, and the arithmetic circuit verification operation of zero-knowledge proof is performed. S414. Output the verification result. The verification result is passed if the integrity check, signature validity check, and arithmetic circuit verification of zero-knowledge proof all pass. Otherwise, it is failed.

[0017] Secondly, this application provides a blockchain-based trusted data space cross-domain access control system for implementing the aforementioned trusted data space cross-domain access control method, comprising: The request parsing module is used to receive data access requests sent by users through the source system and parse the target data identifier, target heterogeneous system identifier, and access scenario information from the data access requests. The dynamic strategy generation module is used to query a pre-set data attribute repository based on the target data identifier to obtain the data attributes of the target data. Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. The cross-domain conversion module is used to read the dynamic access policies stored in the blockchain and map them to the equivalent access control rules supported by the target heterogeneous system. Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; The zero-knowledge proof verification module is used to verify the zero-knowledge proof provided by the user based on equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result. The routing execution module is used to route the target compatible request data to the target heterogeneous system when the zero-knowledge proof verification result is successful; and to convert the original response data into client-side compatible response data that conforms to the source system's compatible format, and return the client-side compatible response data to the user.

[0018] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the aforementioned trusted data space cross-domain access control method.

[0019] Fourthly, this application provides a storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the aforementioned trusted data space cross-domain access control method.

[0020] As can be seen from the above technical solutions, this application has the following advantages: 1. This application solves the problem of rigid policies by querying a pre-set data attribute repository based on the target data identifier, obtaining data attributes, and generating dynamic access policies in combination with access scenario information. It realizes real-time adjustment of permission rules based on data sensitivity attributes and user roles, thereby improving the flexibility and adaptability of access control.

[0021] 2. This application solves the interoperability problem by reading the dynamic access policies stored in the blockchain, mapping them to equivalent access control rules supported by the target heterogeneous system, and converting data access requests into a compatible format according to the communication protocol types of the source system and the target heterogeneous system. This enables efficient compatibility and seamless collaboration of cross-system data routing.

[0022] 3. This application addresses the risk of privacy leakage by verifying zero-knowledge proofs provided by users based on equivalent access control rules and user public keys. It enables decentralized permission verification without exposing policy details or sensitive user attributes, thereby enhancing data security and verification efficiency. Attached Figure Description

[0023] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a blockchain-based cross-domain access control method for trusted data spaces, as described in one embodiment of this application.

[0025] Figure 2 This is a schematic block diagram of a blockchain-based trusted data space cross-domain access control system in one embodiment of this application.

[0026] Figure 3 This is a schematic diagram of the hardware structure of an electronic device in one embodiment of this application. Detailed Implementation

[0027] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this patent, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this patent.

[0028] The following describes in detail the trusted data space cross-domain access control method involved in this application. Specific details such as particular system architectures and technologies are presented for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details.

[0029] In the trusted data space cross-domain access control method involved in this application, the term "comprising" indicates the presence of the described feature, whole, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or sets thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0030] To facilitate a clear description of the technical solutions of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0031] The terms "one embodiment" or "some embodiments" used in this application mean that one or more embodiments of this application include the specific features, structures, or characteristics described in that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this application do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0032] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0033] The trusted data space cross-domain access control method provided in this application embodiment is executed by a computer device, and correspondingly, the blockchain-based trusted data space cross-domain access control system runs in the computer device.

[0034] Figure 1 This is a flowchart of a blockchain-based trusted data space cross-domain access control method according to an embodiment of this application. Figure 1 The executing entity can be a trusted cross-domain access control system for data spaces. Depending on different requirements, the order of steps in this flowchart can be changed, and some can be omitted.

[0035] like Figure 1 As shown, this blockchain-based trusted data space cross-domain access control method includes: Step S1: Receive the data access request sent by the user through the source system, and parse the target data identifier, target heterogeneous system identifier and access scenario information from the data access request; The target heterogeneous system identifier points to the target heterogeneous system that holds the target data.

[0036] By parsing the target data identifier, target heterogeneous system identifier, and access scenario information from the data access request, the target data location and operation context can be accurately located, providing a complete input basis for dynamic policy generation and eliminating policy deviations caused by missing system or scenario information.

[0037] In some specific embodiments, the access scenario information includes user role, access time, and compliance requirements.

[0038] By clearly defining the core dimensions of access scenario information, we ensure that the generated access policies are strongly correlated with the actual business environment, thereby enhancing the contextual adaptability of access control.

[0039] Step S2: Query the preset data attribute repository based on the target data identifier to obtain the data attributes of the target data; Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain.

[0040] By querying a pre-set data attribute repository based on the target data identifier to obtain the data attributes of the target data, and combining this with access scenario information to generate dynamic access policies and deploy them to the blockchain, the correlation between policies and data attributes and blockchain notarization are realized.

[0041] In some specific embodiments, data attributes include data sensitivity attributes and data source attributes.

[0042] By clearly defining the specific scope of data attributes, an objective basis for hierarchical classification of differentiated permission policies can be provided, enabling refined management of data assets.

[0043] In some specific embodiments, dynamic access policies include permission requirement declaration predicates, enforcement constraint rules, cross-domain compatibility instructions, and audit metadata; Cross-domain compatibility instructions include protocol conversion parameters and policy mapping rules; Audit metadata includes policy version number, generation timestamp, and user distributed digital identity identifier; When a dynamic access policy is deployed to the blockchain, a current policy state identifier is generated and stored in the blockchain.

[0044] By clearly defining a four-layer structure for dynamic access policies—permission requirement declaration predicates expressing permission logic, execution constraint rules limiting operation conditions, cross-domain compatibility instructions solving system compatibility issues, and audit metadata enabling operation tracing—a single policy file can simultaneously carry out three functions: permission control, protocol conversion, and audit tracing, significantly reducing the deployment complexity of cross-domain collaboration.

[0045] In some specific embodiments, generating dynamic access policies by combining data attributes and access scenario information includes: S201. Generate an initial access policy through logical matching operations. The initial access policy includes an initial permission requirement declaration predicate and initial execution constraint rules, wherein: Initial permission requirements include the following for declaring the generation of predicates: Generate comparison condition expressions based on the data sensitivity attributes of the target data; Generate an attribution condition expression based on the user role in the access scenario information; The comparison condition expression and the attribution condition expression are combined into a machine-readable predicate logic to form the initial permission requirement declaration predicate; The generation of initial execution constraint rules includes: Data processing constraints are generated based on compliance requirements in the access scenario information. Data classification and processing instructions are generated based on the data type labels of the target data. Dynamic permission validity parameters are generated based on operation context features; Data processing constraints, data classification and processing instructions, and dynamic permission validity parameters together constitute the initial execution constraint rules; S202. Based on the historical policy execution logs stored on the blockchain, optimize the permission thresholds and condition constraints in the initial access policy to obtain an optimized access policy; S203. Embed cross-domain compatibility instructions and audit metadata into the optimized access policy to obtain a dynamic access policy.

[0046] By generating core policy components step by step: automatically generating comparison conditions based on data sensitivity, generating attribution conditions based on user roles to form permission predicates; generating data processing constraints based on compliance requirements, generating classification instructions based on data type tags, generating timeliness parameters based on operation context to form execution rules, and finally optimizing threshold parameters using historical logs, the entire process of policy automation from basic construction to continuous optimization is achieved.

[0047] In some specific embodiments, in step S202, the method for optimizing the permission threshold and condition constraints in the initial access policy is as follows: The initial access strategy is input into the trained access strategy optimization model, which is then used to output a dynamic access strategy. The access policy optimization model is constructed using a supervised learning algorithm and trained using historical policy execution logs stored in the blockchain as a sample set.

[0048] An access policy optimization model built using supervised learning algorithms automatically optimizes the permission thresholds and constraints in the initial policy. For example, it tightens the access threshold for sensitive data based on historical violation records, significantly improving the alignment of the policy with real-time security requirements. In some specific embodiments, the access strategy optimization model is constructed using the random forest algorithm.

[0049] By constructing a policy optimization model using the random forest algorithm and utilizing a multi-decision tree voting mechanism to handle complex policy logs (such as scenarios with multiple constraints such as time, role, and data type), the robustness of policy optimization can be improved by preventing overfitting of a single decision tree.

[0050] Step S3: Read the dynamic access policy stored in the blockchain and map it to the equivalent access control rules supported by the target heterogeneous system; Based on the communication protocol types of the source system and the target heterogeneous system and the equivalent access control rules, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format.

[0051] By converting dynamic access policies into equivalent access control rules natively supported by the target heterogeneous system and automatically adapting to heterogeneous communication protocol specifications, it eliminates cross-domain collaboration barriers caused by differences in policy expression and incompatibility of transmission protocols.

[0052] In some specific embodiments, the communication protocol types of the source system and the target heterogeneous system are obtained using the following methods: The type of communication protocol used by the target heterogeneous system is obtained based on the target heterogeneous system identifier; Based on the communication protocol header of the data access request, identify the type of communication protocol used by the source system.

[0053] The system employs a dual protocol identification mechanism: it obtains the communication protocol type (such as HTTP / CoAP) based on the target system identifier, and simultaneously parses the request protocol header to identify the source system protocol type (such as MQTT), providing an accurate protocol dictionary for subsequent request format conversion.

[0054] Step S4: Verify the zero-knowledge proof provided by the user based on the equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result; The user's public key corresponds to the user's distributed digital identity; Zero-knowledge proofs are generated by users using their distributed digital identity and corresponding user private key to declare that they meet policy permission requirements.

[0055] By using cryptographic methods to verify the compliance of encrypted claims with dynamic policies, permission compliance verification can be completed without transmitting sensitive information, thus solving the privacy leakage risk in traditional access control.

[0056] In some specific embodiments, the specific steps for generating zero-knowledge proofs include: S401. Generate the user's distributed digital identity identifier and the corresponding public-private key pair, the public-private key pair including the user's public key and the user's private key; S402. Extract permission requirement declaration predicates from dynamic access policies; S403. Obtain the tree hash value of the dynamic access policy as a policy integrity identifier; Get the current timestamp; A random number seed is generated using a cryptographic hash function based on the user's private key and the current timestamp; S404. Create a non-interactive proof based on the user's private key, permission requirement declaration predicate, and random number seed. S405. Encapsulate non-interactive proofs, public input parameters, and user distributed digital identity identifiers to generate verifiable zero-knowledge proof data packets.

[0057] Zero-knowledge proofs are generated through triple binding: policy integrity is bound by policy tree hash value, timeliness of proof is bound by timestamp, and authenticity of identity is bound by user private key. This generates tamper-proof proof data packets, solving the problem that traditional proofs are vulnerable to replay attacks.

[0058] In some specific embodiments, the specific steps for verifying zero-knowledge proofs based on equivalent access control rules include: S411. Obtain the equivalent access control rules and zero-knowledge proof data packets; S412. Query the user's public key based on the user's distributed digital identity; Timeliness verification is performed based on the current system time and the timestamp within the data packet; Obtain the current policy status identifier of the blockchain storage; S413. Compare the policy integrity identifier with the current policy status identifier to perform integrity verification; Use the user's public key to verify the signature validity of the zero-knowledge proof bytecode; The equivalent access control rules are converted into verifiable logical conditions, and the arithmetic circuit verification operation of zero-knowledge proof is performed. S414. Output the verification result. The verification result is passed if the integrity check, signature validity check, and arithmetic circuit verification of zero-knowledge proof all pass. Otherwise, it is failed.

[0059] A zero-knowledge proof verification pipeline is constructed to prevent fraud through a four-step verification mechanism: timeliness verification to intercept expired proofs, blockchain policy identifier verification to prevent policy tampering, signature verification to confirm identity authenticity, and arithmetic circuit operation to verify permission logic.

[0060] Step S5: If the zero-knowledge proof verification result is successful, the target compatible request data is routed to the target heterogeneous system.

[0061] By establishing a strict logical connection between verification results and data routing, it is ensured that only authorized requests can enter the cross-domain transmission channel, forming a real-time linkage mechanism between policy constraints and data flow.

[0062] Step S6: After the target heterogeneous system performs an access operation based on the target compatible request data, it generates raw response data, converts the raw response data into client-compatible response data that conforms to the source system's compatible format, and returns the client-compatible response data to the user. By using an automatic format conversion mechanism for response data, the consistency of the original data semantics during cross-system transmission is maintained, eliminating parsing errors or information distortion caused by protocol differences.

[0063] In some specific embodiments, during the execution of steps S5-S6, the following operations are performed in real time: The strategy execution log is captured by blockchain nodes, including routing operation records of routing target compatible data to target heterogeneous systems, and response generation and conversion records of generating raw response data and converting it into user-end compatible response data. The policy execution log is compared with the dynamic access policy in real time. When the operation recorded in the policy execution log is found to violate the rules in the dynamic access policy, a permission freeze command is output to trigger the freezing of the user's access permissions.

[0064] By monitoring the deviation between the strategy execution trajectory and the blockchain evidence storage rules in real time, a permission circuit breaker mechanism can be triggered within a millisecond response time, forming a dynamic security protection network for cross-domain operations across the entire chain.

[0065] In one specific embodiment, the steps of the blockchain-based trusted data space cross-domain access control method include: Step S1: Receive the data access request sent by the user through the source system, and parse the target data identifier, target heterogeneous system identifier and access scenario information from the data access request; The target heterogeneous system identifier points to the target heterogeneous system that holds the target data; Access scenario information includes user role, access time, and compliance requirements.

[0066] Step S2: Query the preset data attribute repository based on the target data identifier to obtain the data attributes of the target data; Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. During the process, a current policy status identifier is generated and stored in the blockchain. Data attributes include data sensitivity attributes and data source attributes; Dynamic access policies include permission requirement declaration predicates, enforcement constraint rules, cross-domain compatibility instructions, and audit metadata; Cross-domain compatibility instructions include protocol conversion parameters and policy mapping rules; Audit metadata includes policy version number, generation timestamp, and user distributed digital identity identifier; The generation of dynamic access strategies by combining data attributes and access scenario information includes: S201. Generate an initial access policy through logical matching operations. The initial access policy includes an initial permission requirement declaration predicate and initial execution constraint rules, wherein: Initial permission requirements include the following for declaring the generation of predicates: Generate comparison condition expressions based on the data sensitivity attributes of the target data; Generate an attribution condition expression based on the user role in the access scenario information; The comparison condition expression and the attribution condition expression are combined into a machine-readable predicate logic to form the initial permission requirement declaration predicate; The generation of initial execution constraint rules includes: Data processing constraints are generated based on compliance requirements in the access scenario information. Data classification and processing instructions are generated based on the data type labels of the target data. Dynamic permission validity parameters are generated based on operation context features; Data processing constraints, data classification and processing instructions, and dynamic permission validity parameters together constitute the initial execution constraint rules; S202. Based on the historical policy execution logs stored on the blockchain, optimize the permission thresholds and condition constraints in the initial access policy to obtain an optimized access policy; The method to optimize the permission thresholds and condition constraints in the initial access policy is as follows: The initial access strategy is input into the trained access strategy optimization model, which is then used to output a dynamic access strategy. The access strategy optimization model is constructed using the random forest algorithm and trained using historical policy execution logs stored in the blockchain as a sample set. S203. Embed cross-domain compatibility instructions and audit metadata into the optimized access policy to obtain a dynamic access policy.

[0067] Step S3: Read the dynamic access policy stored in the blockchain and map it to the equivalent access control rules supported by the target heterogeneous system; Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; The communication protocol types of the source system and the target heterogeneous system are obtained using the following method: The type of communication protocol used by the target heterogeneous system is obtained based on the target heterogeneous system identifier; Based on the communication protocol header of the data access request, identify the type of communication protocol used by the source system.

[0068] Step S4: Verify the zero-knowledge proof provided by the user based on the equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result; The user's public key corresponds to the user's distributed digital identity; Zero-knowledge proofs are generated by users using their distributed digital identity and corresponding user private key to declare that they meet policy permission requirements. The specific steps for generating zero-knowledge proofs include: S401. Generate the user's distributed digital identity identifier and the corresponding public-private key pair, the public-private key pair including the user's public key and the user's private key; S402. Extract permission requirement declaration predicates from dynamic access policies; S403. Obtain the tree hash value of the dynamic access policy as a policy integrity identifier; Get the current timestamp; A random number seed is generated using a cryptographic hash function based on the user's private key and the current timestamp; S404. Create a non-interactive proof based on the user's private key, permission requirement declaration predicate, and random number seed. S405. Encapsulate non-interactive proofs, public input parameters, and user distributed digital identity identifiers to generate verifiable zero-knowledge proof data packets; The specific steps for verifying zero-knowledge proofs based on equivalent access control rules include: S411. Obtain the equivalent access control rules and zero-knowledge proof data packets; S412. Query the user's public key based on the user's distributed digital identity; Timeliness verification is performed based on the current system time and the timestamp within the data packet; Obtain the current policy status identifier of the blockchain storage; S413. Compare the policy integrity identifier with the current policy status identifier to perform integrity verification; Use the user's public key to verify the signature validity of the zero-knowledge proof bytecode; The equivalent access control rules are converted into verifiable logical conditions, and the arithmetic circuit verification operation of zero-knowledge proof is performed. S414. Output the verification result. The verification result is passed if the integrity check, signature validity check, and arithmetic circuit verification of zero-knowledge proof all pass. Otherwise, it is failed.

[0069] Step S5: If the zero-knowledge proof verification result is successful, the target compatible request data is routed to the target heterogeneous system.

[0070] Step S6: After the target heterogeneous system performs an access operation based on the target compatible request data, it generates raw response data, converts the raw response data into client-side compatible response data that conforms to the source system's compatible format, and returns the client-side compatible response data to the user.

[0071] During the execution of steps S5-S6, the following operations are performed in real time: The strategy execution log is captured by blockchain nodes, including routing operation records of routing target compatible data to target heterogeneous systems, and response generation and conversion records of generating raw response data and converting it into user-end compatible response data. The policy execution log is compared with the dynamic access policy in real time. When the operation recorded in the policy execution log is found to violate the rules in the dynamic access policy, a permission freeze command is output to trigger the freezing of the user's access permissions.

[0072] The following are embodiments of a blockchain-based trusted data space cross-domain access control system provided in this application. This blockchain-based trusted data space cross-domain access control system and the trusted data space cross-domain access control methods in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the trusted data space cross-domain access control system, please refer to the embodiments of the blockchain-based trusted data space cross-domain access control methods described above.

[0073] like Figure 2 As shown, the blockchain-based trusted data space cross-domain access control system includes: The request parsing module is used to receive data access requests sent by users through the source system and parse the target data identifier, target heterogeneous system identifier, and access scenario information from the data access requests. The dynamic strategy generation module is used to query a pre-set data attribute repository based on the target data identifier to obtain the data attributes of the target data. Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. The cross-domain conversion module is used to read the dynamic access policies stored in the blockchain and map them to the equivalent access control rules supported by the target heterogeneous system. Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; The zero-knowledge proof verification module is used to verify the zero-knowledge proof provided by the user based on equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result. The routing execution module is used to route the target compatible request data to the target heterogeneous system when the zero-knowledge proof verification result is successful; and to convert the original response data into client-side compatible response data that conforms to the source system's compatible format, and return the client-side compatible response data to the user.

[0074] The trusted data space cross-domain access control system in this embodiment is used to implement a blockchain-based trusted data space cross-domain access control method.

[0075] This application also provides an electronic device for implementing the various embodiments of this application. Figure 3 To illustrate the hardware structure of an electronic device according to various embodiments of this application, as shown in the following diagram... Figure 3 As shown, the electronic device includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor.

[0076] Those skilled in the art will understand that the electronic device structure involved in the embodiments of this application does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0077] In embodiments of this application, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0078] In this application embodiment, the processor can be implemented using at least one of an Application-Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such implementations can be implemented within a controller. For software implementations, implementations such as processes or functions can be implemented with separate software modules that allow the performance of at least one function or operation. The software code can be implemented by a software application (or program) written in any suitable programming language, and the software code can be stored in memory and executed by the controller.

[0079] In addition, the electronic device includes some functional modules not shown, which will not be described in detail here.

[0080] Those skilled in the art will understand that the various aspects of the electronic device provided in this application can be implemented as a system, method, or program product. Therefore, the various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software aspects, collectively referred to herein as a "circuit," "module," or "system."

[0081] This application also provides a storage medium storing a program product capable of implementing a blockchain-based trusted data space cross-domain access control method. In some possible implementations, various aspects of this application can also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this application.

[0082] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0083] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain-based method for cross-domain access control of trusted data spaces, characterized in that, include: S1. Receive data access requests sent by users through the source system, and parse the target data identifier, target heterogeneous system identifier, and access scenario information from the data access requests; The target heterogeneous system identifier points to the target heterogeneous system that holds the target data; S2. Query the preset data attribute repository based on the target data identifier to obtain the data attributes of the target data; Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. S3. Read the dynamic access policies stored in the blockchain and map them to the equivalent access control rules supported by the target heterogeneous system; Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; S4. Verify the zero-knowledge proof provided by the user based on the equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result; The user's public key corresponds to the user's distributed digital identity; Zero-knowledge proofs are generated by users using their distributed digital identity and corresponding user private key to declare that they meet policy permission requirements. S5. When the zero-knowledge proof verification result is successful, route the target compatible request data to the target heterogeneous system; S6. After the target heterogeneous system performs an access operation based on the target compatible request data, it generates raw response data, converts the raw response data into client-side compatible response data that conforms to the source system's compatible format, and returns the client-side compatible response data to the user.

2. The trusted data space cross-domain access control method as described in claim 1, characterized in that, During the execution of steps S5-S6, the following operations are performed in real time: The strategy execution log is captured by blockchain nodes, including routing operation records of routing target compatible data to target heterogeneous systems, and response generation and conversion records of generating raw response data and converting it into user-end compatible response data. The policy execution log is compared with the dynamic access policy in real time. When the operation recorded in the policy execution log is found to violate the rules in the dynamic access policy, a permission freeze command is output to trigger the freezing of the user's access permissions.

3. The trusted data space cross-domain access control method as described in claim 1, characterized in that, In step S1, the access scenario information includes user role, access time, and compliance requirements; In step S2, the data attributes include data sensitivity attributes and data source attributes; Dynamic access policies include permission requirement declaration predicates, enforcement constraint rules, cross-domain compatibility instructions, and audit metadata; Cross-domain compatibility instructions include protocol conversion parameters and policy mapping rules; Audit metadata includes policy version number, generation timestamp, and user distributed digital identity identifier; When a dynamic access policy is deployed to the blockchain, a current policy state identifier is generated and stored in the blockchain.

4. The trusted data space cross-domain access control method as described in claim 3, characterized in that, In step S2, generating a dynamic access strategy by combining data attributes and access scenario information includes: S201. Generate an initial access policy through logical matching operations. The initial access policy includes an initial permission requirement declaration predicate and initial execution constraint rules, wherein: Initial permission requirements include declaring the generation of predicates, including: Generate comparison condition expressions based on the data sensitivity attributes of the target data; Generate an attribution condition expression based on the user role in the access scenario information; The comparison condition expression and the attribution condition expression are combined into a machine-readable predicate logic to form the initial permission requirement declaration predicate; The generation of initial execution constraint rules includes: Data processing constraints are generated based on compliance requirements in the access scenario information. Data classification and processing instructions are generated based on the data type labels of the target data. Dynamic permission validity parameters are generated based on operation context features; Data processing constraints, data classification and processing instructions, and dynamic permission validity parameters together constitute the initial execution constraint rules; S202. Based on the historical policy execution logs stored on the blockchain, optimize the permission thresholds and condition constraints in the initial access policy to obtain an optimized access policy; S203. Embed cross-domain compatibility instructions and audit metadata into the optimized access policy to obtain a dynamic access policy.

5. The trusted data space cross-domain access control method as described in claim 4, characterized in that, In step S202, the method for optimizing the permission thresholds and condition constraints in the initial access policy is as follows: The initial access strategy is input into the trained access strategy optimization model, which is then used to output a dynamic access strategy. The access policy optimization model is constructed using a supervised learning algorithm and trained using historical policy execution logs stored in the blockchain as a sample set.

6. The trusted data space cross-domain access control method as described in claim 3, characterized in that, In step S4, the specific steps for generating a zero-knowledge proof include: S401. Generate the user's distributed digital identity identifier and the corresponding public-private key pair, the public-private key pair including the user's public key and the user's private key; S402. Extract permission requirement declaration predicates from dynamic access policies; S403. Obtain the tree hash value of the dynamic access policy as a policy integrity identifier; Get the current timestamp; A random number seed is generated using a cryptographic hash function based on the user's private key and the current timestamp; S404. Create non-interactive proof bytecode based on the user's private key, permission requirement declaration predicate, and random number seed; S405. Encapsulate non-interactive proof bytecode, public input parameters, and user distributed digital identity identifiers to generate a verifiable zero-knowledge proof data package.

7. The trusted data space cross-domain access control method as described in claim 6, characterized in that, In step S4, the specific steps for verifying zero-knowledge proofs based on equivalent access control rules include: S411. Obtain the equivalent access control rules and zero-knowledge proof data packets; S412. Query the user's public key based on the user's distributed digital identity; Timeliness verification is performed based on the current system time and the timestamp within the data packet; Obtain the current policy status identifier of the blockchain storage; S413. Compare the policy integrity identifier with the current policy status identifier to perform integrity verification; Use the user's public key to verify the signature validity of the zero-knowledge proof bytecode; The equivalent access control rules are converted into verifiable logical conditions, and the arithmetic circuit verification operation of zero-knowledge proof is performed. S414. Output the verification result. The verification result is passed if the integrity check, signature validity check, and arithmetic circuit verification of zero-knowledge proof all pass. Otherwise, it is failed.

8. A blockchain-based trusted data space cross-domain access control system, characterized in that, A method for implementing cross-domain access control of trusted data space as described in any one of claims 1-7 includes: The request parsing module is used to receive data access requests sent by users through the source system and parse the target data identifier, target heterogeneous system identifier, and access scenario information from the data access requests. The dynamic strategy generation module is used to query a pre-set data attribute repository based on the target data identifier to obtain the data attributes of the target data. Dynamic access policies are generated by combining data attributes and access scenario information, and then deployed to the blockchain. The cross-domain conversion module is used to read the dynamic access policies stored in the blockchain and map them to the equivalent access control rules supported by the target heterogeneous system. Based on the communication protocol types and equivalent access control rules of the source system and the target heterogeneous system, the data access request is converted into target compatible request data that conforms to the target heterogeneous system's compatible format; The zero-knowledge proof verification module is used to verify the zero-knowledge proof provided by the user based on equivalent access control rules and the user's public key, and output the zero-knowledge proof verification result. The routing execution module is used to route the target compatible request data to the target heterogeneous system when the zero-knowledge proof verification result is successful; and to convert the original response data into client-side compatible response data that conforms to the source system's compatible format, and return the client-side compatible response data to the user.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the trusted data space cross-domain access control method as described in any one of claims 1-7.

10. A storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the trusted data space cross-domain access control method as described in any one of claims 1-7.

Images