Cross-domain access control method for heterogeneous multi-chain data based on threshold homomorphic encryption

Abstract

The present invention discloses a heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption. The scheme uses threshold homomorphic encryption to encrypt access policies and attributes, and the access policies and attributes are stored in the form of ciphertext, thereby preventing privacy leakage; the ciphertext of the access policy and user attributes of the data is homomorphically calculated through a smart contract, and then the calculated difference result is sent in the form of ciphertext to the relay nodes within the threshold range in the cross-chain network for joint decryption. When the relay nodes participating in the decryption reach a certain threshold, the plaintext result of the difference can be obtained, and the final authorization decision is made by the smart contract; in addition, the encryption and single-node decryption of the policy and attributes are performed off-chain, and the multi-party joint calculation of the ciphertext result is performed on the relay chain of the cross-chain network environment, which ensures the privacy of the data and the computing efficiency of the system, and the on-chain multi-party calculation of the ciphertext result also ensures the traceability of the access control result.

Description

Technical Field

[0001] The present invention relates to the field of cross-chain interaction technology, and in particular to a heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption. Background Art

[0002] Today, blockchain has been applied to the Internet of Things, healthcare, agriculture, smart cities, and smart transportation. However, with the development of blockchain technology, many independent blockchain networks have emerged, each with its own rules, protocols, and access control mechanisms. There are challenges in interoperability between these independent blockchain networks, which hinder the free flow of data and the cooperation and innovation of blockchain scenarios across organizations and industries.

[0003] Imagine a scenario where, in the daily management process, whether it is a government department or an enterprise, due to business needs, it is usually necessary to exchange and share data with one or more internal and external organizations. If these organizations use different blockchain networks at the bottom, it will cause data isolation and interoperability barriers between different organizations. Cross-chain technology aims to solve the exchange and interoperability of digital assets between blockchains and improve the scalability of blockchain systems. Cross-chain technology allows connections and communications to be established between different blockchain networks, enabling seamless transmission and exchange of data. However, cross-chain network organizations do not fully trust each other, and not all data in the network is open and transparent. In addition, inter-chain data needs to be obtained from each organization chain. This data usually covers some sensitive information, such as commercial information, user privacy information and other sensitive content, and the authority and scope of data sharing between different organizations are limited;

[0004] However, implementing cross-chain access control is not easy. Different blockchain networks have unique data formats, encryption algorithms, and access control policies, which increases the complexity of cross-chain access control. In addition, the transparency of the blockchain also brings some privacy and security considerations. Directly storing access policies or attributes on the blockchain may pose a major threat to sensitive information such as user privacy. These attributes and policies usually contain sensitive information about users and resources, such as the user's identity information, basic conditions, and the sensitivity level and type of data resources. If the attribute information is directly stored on a public cross-chain network without processing, then any organization and user node in the network that can access the data resource can obtain the user's privacy-sensitive information from the attribute information;

[0005] In view of the above, the present application provides a heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption to solve the above problems. Summary of the invention

[0006] In view of the above situation, in order to overcome the defects of the prior art, the present invention provides a cross-domain access control method for heterogeneous multi-chain data based on threshold homomorphic encryption. This scheme completely hides attributes and policies, while ensuring fine-grained access control, and securely protects cross-chain data and its privacy information. By using the threshold homomorphic encryption system (threshold Paillier cryptosystem), the ciphertext is differentially calculated without decrypting user attributes and access policies, and the results are jointly decrypted by multiple parties across the chain, ensuring the security of private data; at the same time, the user access history is tracked and recorded using smart contracts, and dynamic updates of user access rights are guaranteed; experimental analysis and results show that the mechanism is more comprehensive in access control functions, can effectively meet the access control requirements in multi-chain collaborative scenarios, and provides effective technical support for cross-chain data sharing and collaboration.

[0007] The heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption is characterized by including the following parts: data owner, data user, relay node cross-chain protocol, relay node, trusted authority, threshold key generation center;

[0008] The access method specifically comprises the following steps:

[0009] S1: Data owners and data users obtain identity certificates and corresponding encrypted attributes or policies from the relay nodes of their blockchains;

[0010] S2: The data owner uploads the encrypted access policy and its data summary information to the blockchain and provides it to nodes inside and outside the chain to apply for access;

[0011] S3: When a data user applies to access the data of a data owner on a certain chain, he needs to submit a cross-chain access request to the relay node corresponding to the blockchain where he is located;

[0012] S4: The relay node passes the request to the relay node of the blockchain where the data owner is located. The relay node of the blockchain where the data owner is located calls the access control contract to perform the difference calculation of the policy and attributes, and sends the difference ciphertext to all relay nodes within the threshold range for partial decryption calculation;

[0013] S5: The master node collects and merges all partial decryption results to obtain the final joint decryption result, and sends it to the relay node of the blockchain where the data owner is located;

[0014] S6: The relay node of the blockchain where the data owner is located calls the access control contract to determine whether cross-chain operation access can be authorized.

[0015] The above technical solution has the following beneficial effects:

[0016] (1) In the cross-chain scenario, this application proposes a strategy and attribute hiding access control scheme that combines ABAC and threshold homomorphic encryption technology. This scheme can achieve dynamic data access control that is traceable between organizational chains, has privacy protection, and supports attribute revocation in the cross-chain network;

[0017] (2) This application proposes a threshold homomorphic decryption method for joint calculation by multiple relay nodes, in which a multi-party joint decryption group is formed by relay nodes in a cross-chain network to jointly decrypt the ciphertext after homomorphic comparison calculation;

[0018] (3) A simulation experiment was conducted using Hyperledger Fabric and FISCO BCOS as the underlying platforms. After security analysis and experimental testing, the results showed the feasibility and superiority of the solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic diagram of the system model of the present invention;

[0020] Figure 2 This is a schematic diagram of the cross-chain data access control sharing process of the present invention;

[0021] Figure 3 The encryption time of the algorithm of the present invention is relatively slow;

[0022] Figure 4 This is a schematic diagram of the time consumption for key generation of the present invention;

[0023] Figure 5 This is a schematic diagram of the time consumption for decryption by the algorithm of the present invention;

[0024] Figure 6 This is a schematic diagram of the decryption time comparison of the algorithm of the present invention;

[0025] Figure 7 This is a schematic diagram of the time consumption for calculating the ciphertext difference of the present invention. DETAILED DESCRIPTION

[0026] The aforementioned and other technical contents, features and effects of the present invention will be clearly presented in the following detailed description of the embodiments with reference to the drawings of the present application. The structural contents mentioned in the following embodiments are all based on the drawings of the specification as reference.

[0027] The following content description is mainly divided into six parts:

[0028] 1. Introduction to cross-chain data sharing technology;

[0029] 2. Some research related to this program;

[0030] 3. Introduce the relevant background of the solution, including attribute-based access control (ABAC), threshold homomorphic encryption system, and cross-chain interoperability;

[0031] 4. Introduce the access control model and design goals proposed in this application plan;

[0032] 5. Introduce the specific implementation details of this plan;

[0033] 6. Conduct security analysis and simulation experiments on the method of this application.

[0034] 1. Introduction to cross-chain data sharing technology

[0035] In today's digital age, data sharing has become a key element to promote innovation, promote cooperation and achieve more efficient business processes. However, with the rapid development of information technology, the scale of data is growing and the sources of data are becoming more and more diverse. Since data is distributed in different places, it brings many challenges to data sharing, including data security and privacy protection issues. Blockchain, as a decentralized, tamper-proof and transparent distributed ledger technology, helps to solve the problem of over-reliance on trusted third parties in the process of data sharing, and provides a new solution for data sharing, exchange and collaboration, and realizes the secure transmission of data. Today, blockchain has been applied to the fields of Internet of Things, medical care, agriculture, smart cities, and intelligent transportation. However, with the development of blockchain technology, many independent blockchain networks have emerged, each with its own rules, protocols and access control mechanisms. There are challenges in interoperability between these independent blockchain networks, which hinder the free flow of data and the cooperation and innovation of blockchain scenarios across organizations and industries.

[0036] Imagine a scenario where, in the daily management process, whether it is a government department or an enterprise, due to business needs, it is usually necessary to exchange and share data with one or more internal and external organizations. If these organizations use different blockchain networks at the bottom, it will cause data isolation and interoperability barriers between different organizations. Therefore, cross-chain interoperability has become a research hotspot in recent years. Cross-chain technology aims to solve the exchange and interoperability of digital assets between blockchains and improve the scalability of blockchain systems. Cross-chain technology allows connections and communications to be established between different blockchain networks to achieve seamless transmission and exchange of data. However, cross-chain network organizations do not fully trust each other, and the data in the network is not all open and transparent. In addition, inter-chain data needs to be obtained from each organization chain. This data usually covers some sensitive information, such as commercial information, user privacy information and other sensitive content, and the authority and scope of data sharing between different organizations are limited. Therefore, how to implement data access control in a cross-chain network to ensure data and user privacy security has become a new challenge.

[0037] Traditional access control models, such as mandatory access control (MAC), discretionary access control (DAC), and role-based access control (RBAC), lack flexibility in permission allocation and management. The permissions of the model are static and difficult to adapt to dynamically changing access requirements. Moreover, traditional access control models are designed for access control scenarios within a single system or a single organization. In cross-organizational or cross-domain data interaction scenarios, access control between different blockchain networks requires coordination and integration of permission rules of multiple organizational systems. Traditional model research has great limitations in this scenario. The attribute-based access control (ABAC) model allows more fine-grained control and dynamic access decisions by building access control policies on attributes, based on user, resource, and environmental attributes as decision elements. Moreover, the ABAC model can adapt to the access control requirements between different systems and organizations, and can perform cross-domain and cross-organization access control based on attribute matching. Applying the ABAC model to blockchain cross-chain scenarios for access control not only solves the security and privacy protection issues of data interaction between different blockchain networks, but also brings new development opportunities to traditional centralized access control due to the decentralized and tamper-proof characteristics of blockchain.

[0038] However, it is not easy to implement cross-chain access control. Different blockchain networks have unique data formats, encryption algorithms, and access control policies, which increases the complexity of cross-chain access control. In addition, the transparency of blockchain also brings some privacy and security considerations. Directly storing access policies or attributes on the blockchain may pose a major threat to sensitive information such as user privacy. These attributes and policies usually contain sensitive information about users and resources, such as user identity information, basic conditions, and the sensitivity level and type of data resources. If the attribute information is directly stored on a public cross-chain network without processing, then any organization and user node in the network that can access the data resource can obtain the user's privacy-sensitive information from the attribute information. Therefore, from the perspective of privacy protection, it is not advisable to directly store access policies and attribute information on the blockchain ledger.

[0039] II. Some Research Related to This Scheme

[0040] Some research works have explored how to combine access control models with blockchain technology to meet access control requirements in different scenarios. Some scholars have proposed an ABAC-based smart city access control framework, which manages the addition, deletion, and update of ABAC policies and entity attributes through smart contracts, and supports many-to-many access control. However, although the prototype proves the feasibility of the proposed framework, the author only tested the performance of the framework on the Ethereum platform, which is difficult to reflect the performance of the framework in large-scale IoT blockchain applications such as smart manufacturing or healthcare. Some scholars have combined ABAC with blockchain and proposed an attribute-based distributed access control framework, which uses devices in the IoT as nodes of Ethereum clients for secure access control. However, this scheme stores the plaintext information of device attributes and policies in smart contracts without considering privacy issues. Due to the limited resources of IoT devices, in order to reduce their computing overhead, some scholars have proposed a lightweight decryption access control scheme based on ABE and blockchain, which uses outsourced services for decryption and guarantees the correctness of outsourced decryption based on blockchain. However, in actual applications, attributes may be revoked due to factors such as changes in permissions, and this scheme does not support dynamic management of attributes. In the access control scheme combining attribute-based encryption (ABE) and blockchain, the explicit storage of access policies may expose the privacy of users. Secondly, there are problems such as computational cost and efficiency. To this end, some scholars have proposed a scheme that partially hides access policies to protect user privacy, generates and encrypts keys through an offline mechanism, and uses an outsourcing mechanism for decryption, thereby improving the execution efficiency of the authentication scheme.

[0041] Based on the CP-ABE model, some scholars have proposed a cloud storage framework with access control, which stores the ciphertext of data through smart contracts in the blockchain and sets up an effective access period for access control. However, since the cloud storage platform is semi-honest, it cannot guarantee that the data documents will not be tampered with. Some scholars have combined blockchain and CP-ABE to provide distributed and fine-grained data sharing services in vehicle-mounted self-organizing networks. However, after the file size exceeds 1MB, the transmission rate of this scheme increases exponentially and the time cost is high. In order to cope with the heavy computing cost and storage overhead of the existing CP-ABE scheme, some scholars have proposed an efficient, traceable, and revocable access control scheme: TRAC, which is used for the secure sharing of personal health records in mobile medical care. The ciphertext size and decryption time of this scheme are constant, it has good performance, and supports identity revocation.

[0042] However, the above research work does not discuss the cross-domain or cross-chain secure data sharing and access control of different organizations in a multi-blockchain network. In order to solve the privacy and security issues of cross-domain communication, some scholars have built a cloud-based centralized cross-domain data sharing platform, using a secure gateway to provide privacy control, establishing keys through Ephemeral Elliptic CurveDiffie-Hellman, and identity-based signatures for identity authentication, providing cross-domain identity authentication and data sharing between different domains in the industrial Internet of Things. Some scholars have proposed a lightweight alliance chain architecture to improve the scalability of the access control scheme for IoT devices. This scheme also promotes inter-domain access control by setting cross-domain roles and environments. In addition, it stores access control policies in the form of transactions to ensure lightweight requirements. In response to the problems of difficult cross-domain trusted sharing of data and long access cycles, some scholars have designed an encryption and authentication mechanism based on biometric keys and national secret algorithms, deriving keys based on patient biometrics to achieve personalized privacy protection, and improving data processing and computing capabilities through edge computing. In order to protect sensitive data and user privacy in data sharing in multi-chain systems, some scholars have proposed the SynergyChain multi-chain framework, which implements hierarchical access control of multi-chain data through data aggregation and identity authentication, and based on smart contracts. However, this solution only performs coarse-grained permission control based on the data level, which cannot meet the dynamically changing access needs in complex large organizations. Some scholars have proposed a cross-domain access control solution based on blockchain and TrustNet for cross-domain information access control in IoT scenarios. The solution integrates the TrustNet system with the alliance chain, and transmits trust along the trust path between alliance chain nodes through TrustNet. The trust evaluation algorithm Appleseed evaluates the trust value between each domain. The cross-domain access control contract determines the access control authority based on the evaluated trust value and the access control policy of each domain. For the application scenario of edge-cloud collaboration, some scholars have studied the cross-domain access control architecture of this scenario, authorizing access to resources according to the attribute permission level, and supporting dynamic update of access rights. However, the existing cross-domain access control research mainly focuses on the scenario within a single blockchain platform, and has not yet covered the real cross-chain access control between multiple independent blockchain platforms.

[0043] 3. Introduction of relevant background in the proposal

[0044] 3.1 Attribute-based access control

[0045] The attribute-based access control (ABAC) model determines access rights to resources by evaluating the match between the user's attributes and the defined access policy. In the ABAC model, there are four main elements, user (U), resource (R), environment (Condition), and operation permission (P). The attribute set of U and R plays an important role. These attributes may include information such as the user's role, location, time, and other information, as well as the type, classification, sensitivity, and other attributes of the resource. In the ABAC model, access control decisions are usually defined by policy rules. These policy rules can be described using conditional statements, such as "if the user role is administrator and the time is within working hours, then access is allowed." ABAC policies can be expressed as complex Boolean operations on a variety of different attributes. When an access request occurs, the system will match the applicable policy rules based on the user's attributes and the resource's attributes, and then decide whether to grant access rights based on the matching results.

[0046] We extended the ABAC model and implemented a cross-chain ABAC model to dynamically manage access to all devices in the cross-chain network. The model has the following components:

[0047] Subject (S): The access subject of the access control model, that is, the user entity;

[0048] Object (O): The access object of the access control model, that is, the resource entity in the network;

[0049] Attributes (A): A collection of attributes related to accessing subject and object resources;

[0050] Access rights (P): a set of permissions that allow or deny access, where access permission includes specific operation types, such as read, write, etc.

[0051] Policy rules (PR): consist of attributes and conditions and are used to determine access rights;

[0052] Decision function (D): It uses policy rules PR to determine access rights P based on subject attributes and object attributes;

[0053] The ABAC model can be expressed as: D(S,O)=P, and the policy rules can be expressed as: PR=(SPR,OPR,Condition,PPR), where S is the attribute set of the subject user: S={AS1,AS2,...,ASn}, SPR is the policy rule related to the subject attribute,

[0054] O is the attribute set of the object resource: O = {AO1, AO2, ..., AOn}, OPR is the policy rule related to the object attribute,

[0055] P is the access permission set: P = {Allow_read, Allow_write, Deny}, PPR is the access operation permission corresponding to the policy rule PR,

[0056] Condition is a conditional statement that determines access rights based on the conditions of the attribute.

[0057] 3.2 Threshold Homomorphic Encryption System

[0058] The threshold key sharing decryption / signature scheme was first proposed by Desmedt and Frankel in 1989. In this scheme, the key is divided into multiple parts and distributed to l (lowercase letter L) different participants, of which more than t participants have the ability to regenerate the key (but less than t is not allowed), that is, assuming that there are no participants greater than or equal to the threshold t who will be compromised, threshold decryption allows the relevant participants who meet the threshold requirements to decrypt specific messages without leaking any information about other plaintexts or secret keys in the process.

[0059] The Threshold Paillier cryptosystem works as follows, where Δ = l!, l is the number of cross-chain node servers:

[0060] Key generation: Choose an integer modulus n = pq, where p and q are two strong prime numbers such that p = 2p′+1, q = 2q′+1, and gcd Let m = p′q′. Let β be a randomly selected element in Zn*; then, randomly select (a, b)∈Zn * ×Zn * , and set g = (1 + n) a ×b n modn 2 The key SK = β × m is shared using the Shamir scheme (Shamir A. How to share a secret [J]. Communications of the ACM, 1979, 22 (11): 612-613.), let a0 = mβ, randomly select t values ​​a in {0, ..., n × m-1} i , and set The secret share of the i-th cross-chain node server (share)s i =f(i)modnm; public key PK = (n, g, θ), where θ = L(g mβ)=amβmod n. LetVK=v be a square that generates of the cyclic group of squaresin Verification Key

[0061] Encryption algorithm: Randomly select x∈Z n * , and calculate the ciphertext c = g M x n modn 2 To encrypt information M.

[0062] Shared decryption: The i-th cross-chain node server uses its secret share s i To calculate the decryption share And compute the correct validity proof.

[0063] Merge Algorithm: When fewer than t decrypted shares have proof of validity, the algorithm fails. Otherwise, let S be the set of t+1 valid shares and calculate the plaintext in

[0064] 3.3 Cross-chain interoperability

[0065] Due to the diversity of blockchain infrastructure and the lack of unified architecture standards in the industry, research on blockchain and its interoperability solutions has become challenging. In recent years, with the in-depth study of blockchain interoperability issues, the concept of cross-blockchain communication has been considered by scholars to be a necessary condition for solving blockchain interoperability. Cross-chain communication allows value to cross the barriers between chains, thereby transmitting information between one or more chains. Cross-chain communication involves two blockchains: the source chain and the target chain. Transactions are initiated through the source chain, and the target chain performs transaction execution operations.

[0066] There are many articles analyzing and classifying cross-chain interoperability technology. In short, the research and implementation of cross-chain communication technology between heterogeneous blockchains is of great significance to the development of the cross-chain field. However, the differences in the underlying standards of blockchains bring opportunities to blockchains, but also bring severe challenges to cross-chain operations.

[0067] 3.4LibP2P

[0068] LibP2P is a modular network stack and library for building P2P networks. It is derived from the open source project IPFS, and its modular design enables it to be used to build the P2P network layer of various decentralized applications. At present, many blockchain projects, such as Ethereum 2.0, Polkadot, Filecoin, BitXHub, etc., choose to use the libP2P library to build the network layer of their systems. LibP2P has many excellent features, such as peer node discovery (able to discover other nodes in the P2P network), routing, support for multiple data transmission protocols, protection of transmission data privacy, etc., and provides a variety of encryption and authentication mechanisms. It uses an encoding scheme called "multiaddr" to unify different protocol address formats and assigns nodes in the network a unique ID for the entire network. By using node IDs, the problem of man-in-the-middle attacks can be effectively solved. Due to its flexibility and scalability, libP2P has been widely used in distributed file systems or building decentralized applications.

[0069] IV. Access Control Model and Design Goals Proposed in This Solution

[0070] 4.1 System Architecture

[0071] In this application, a strategy and attribute-hiding access control scheme for secure data sharing in cross-chain networks is proposed using ABAC and threshold homomorphic encryption technology;

[0072] Figure 1 The system model of the proposed solution is depicted, involving seven different entities, including:

[0073] Data owner: data owner (DO)

[0074] Data user: datauser(DU)

[0075] Relay node cross-chain protocol: relay node cross-chain protocol (RNCCP)

[0076] Relay node: relay node (RN)

[0077] Trusted authority: trusted authority (TA)

[0078] Threshold Key Generation Center (TKGC), their definitions are as follows:

[0079] DO: DO is the entity that owns the data and wants to share it across chains; DO specifies its attribute-based access control policy PR = (SPR, OPR, Condition, P PR ), and TA uses its public key PK to encrypt the policy; then, DO uploads the generated policy ciphertext to the blockchain through the access control contract (ACC).

[0080] DU: DU is an entity in the network that wants to obtain data in the network through cross-chain interoperation; DU has a set of attributes O={A O1 ,A O2 ,...,A On}, the RNs of both parties participating in the cross-chain operation in the network jointly calculate the ciphertext difference between the strategy and the attribute. If the difference is 0, it proves that the attribute of DO meets the strategy set by DU, and DU is allowed to obtain DO data through cross-chain operations.

[0081] RNCCP: RNCCP is a universal cross-chain data transmission protocol for relay nodes. It allows heterogeneous blockchains to access the cross-chain platform without changing the underlying structure, perform unified cross-chain operations, and achieve trusted cross-chain contract interoperability and data transmission. The protocol stipulates the consistency of the data structure and operation objects of cross-chain transactions, defines the life cycle of cross-chain transactions between heterogeneous blockchains, and provides a consistent calling interface to the upper-level cross-chain platform. In our previous research on cross-chain mechanisms,

[47] There is a specific definition of its implementation principle.

[0082] RN: RN is a node that forwards and verifies cross-chain transaction requests in the cross-chain network. As an entity that performs threshold homomorphic joint calculations on the DO strategy and DU attributes in the access control process, RN calculates the gap in the ciphertext by calling the joint matching algorithm of ACC and uses its own secret share s i That is, the private key decrypts the gap to obtain the decrypted share; finally, the decrypted shares of both parties are merged through the merging algorithm to obtain the original text of the gap, thereby realizing fine-grained access control of the data.

[0083] TA: TA is a trusted authority on the blockchain. Each blockchain has a corresponding TA. TA uses the public key to encrypt the policy and attributes. The encrypted policy ciphertext is stored in ACC, and the attributes are distributed to DU.

[0084] TKGC: TKGC is the trusted threshold key generation center on the relay node chain of the cross-chain network; it is responsible for generating threshold keys and authentication keys for the relay nodes of the blockchain participating in the cross-chain network according to the key generation protocol, and passing the public key PK to the TA of each blockchain in the network in a secure manner.

[0085] 4.2 Safety requirements and design goals

[0086] In the scheme proposed in this application, it is assumed that TKGC and the RN recommended by the blockchain are credible. DUs are considered dishonest, and they try to collude to obtain as much private data of DO as possible while expecting to obtain DO data. In addition, DUs may try to play a malicious role in cross-chain interactions and obtain data without authorized access.

[0087] In this article, it is assumed that attackers cannot compromise most of the nodes in the network, and they cannot tamper with the plaintext data or ciphertext information on the blockchain ledger. However, attackers can access the public information stored in the ledger, and can infer and calculate the relevant information of the publisher based on the data. Therefore, in a cross-chain network environment, if DU directly stores its corresponding attributes publicly on the blockchain, then the attacker may learn the attribute set that satisfies the access policy from the DU that has been authorized to access, thereby inferring the access control policy of DO. The attacker simulates and forges his own attributes based on the inferred policy, and then maliciously obtains cross-chain access rights to DO data. Similarly, if the access policy of DO can be obtained directly from the blockchain, the attacker may also obtain some privacy-sensitive information about DO and DU data through the policy.

[0088] Based on the above analysis, the security requirements that the model needs to have are as follows:

[0089] (1) Support fine-grained access control, allowing the definition of flexible multi-level access control policies, while supporting dynamic updates of access policies to adapt to different cross-chain interaction requirements and scenarios, and supporting traceable auditing of access records.

[0090] (2) In addition, by encrypting and hiding the access policies and attributes, the sensitive privacy information of users in the blockchain is protected while resisting the malicious damage of the above attacks.

[0091] (3) Most importantly, our model should also be capable of multi-party secure joint computing in a cross-chain network.

[0092] We assume that attackers cannot decrypt and forge access control results by colluding with RNs within the specified threshold. The encryption primitives used in the paper are all secure. We use threshold homomorphic encryption to resist collusion attacks by attackers while performing joint secure calculations through multiple RNs in the network. We use its homomorphism to cleverly calculate the difference between the strategy and the attributes.

[0093] V. Specific implementation details of this plan

[0094] 5.1 Overview

[0095] The cross-chain access control scheme we proposed builds a cross-chain network and corresponding RNs, solving the problem of secure data transmission and cross-chain interoperability between blockchains; on this basis, the scheme proposed in this paper implements an ABAC-based access control model with a dynamic update strategy in the cross-chain network, solving the problem of controllable permission access control of inter-chain data. In addition, in order to ensure data security and privacy during the access process, we built a threshold homomorphic encryption system (threshold Paillier cryptosystem) mechanism in the relay node chain composed of RNs, and the corresponding RNs of both cross-chain parties jointly securely calculate the access policy and attribute ciphertext, realizing reliable calculation and traceable access control.

[0096] For each RN node recommended by each blockchain in the cross-chain network, TKGC generates the key share of the corresponding threshold homomorphic cryptographic system and sends it to each RN in a secure manner together with the public key. In addition, RN also has a certificate issued by the CA of the relay node chain (CA: a fixed term in the blockchain, referring to the certificate authority in the blockchain), which is used to sign cross-chain transactions and verify the validity of cross-chain transactions. For each RN participating in the joint decryption, the partial decryption results obtained after decryption using the key share are finally combined by the master node of the relay node chain to calculate the final joint decryption result.

[0097] Among them, the master node is the master node of the relay node chain. The relay node chain defines three types of relay nodes: master node, cross-chain node and light node.

[0098] There is only one master node in the cross-chain network, which is elected by the RN nominated by the organization chain where the government department in the network is located; in addition, the master node is also required to perform identity security authentication and supervision on other relay nodes joining the cross-chain network.

[0099] If DU and DO want to perform cross-chain data sharing and other operations in the network, the following steps are required:

[0100] First, you need to obtain the identity certificate and the corresponding encrypted attributes or policies from the TA of its blockchain.

[0101] Subsequently, DO uploads the encrypted access policy and summary information of its data to the blockchain, and provides it to nodes inside and outside the chain to apply for access.

[0102] When DU wants to apply for access to DO data on a certain chain, it must submit a cross-chain access request to the RN corresponding to the blockchain where it is located.

[0103] RN passes the request to the RN in the chain where DO is located, which calls ACC to perform the difference calculation of policies and attributes, and hands the difference ciphertext to all RNs within the threshold range for partial decryption calculation.

[0104] Finally, the master node collects and merges all partial decryption results to obtain the final joint decryption result and sends it to the RN of the chain where the DO is located.

[0105] RN calls ACC to determine whether cross-chain operation access can be authorized.

[0106] In the complete process of access control and sharing of cross-chain data throughout its life cycle, smart contracts play an important role in the execution logic of the mechanism; our mechanism involves three types of contracts:

[0107] User contracts, cross-chain contracts, and access control contracts (ACC). User contracts provide interfaces for DU and DO to perform operations such as data sharing and encrypted upload.

[0108] As a bridge connecting users, blockchains and relay node chains, cross-chain contracts mainly implement cross-chain interoperability logic between heterogeneous chains. Cross-chain contracts transfer data with user contracts and receive user cross-chain requests, thereby realizing interactive communication of inter-chain data.

[0109] Figure 2 The access control and sharing process of cross-chain data is shown. Figure 2 The specific process of cross-chain access control is introduced in detail.

[0110] 5.2 System Initialization

[0111] Initially, according to the heterogeneous cross-chain interaction mechanism based on relay nodes, a cross-chain network architecture consisting of multi-organization chains and relay node chains was constructed. Assuming the number of blockchains in the network is M, there are M RNs in the network. The master node of the relay node chain selects t (t≥2) RNs within the threshold range as the node group for joint decryption. This node group must include the RNs corresponding to the source chain and the destination chain participating in this round of cross-chain interaction. The RNs participating in the joint decryption have their corresponding decryption key shares generated by TKGC.

[0112] The specific process is as follows:

[0113] First, all TAs in the cross-chain network specify the key generation protocol of the threshold homomorphic encryption system. TKGC sets two strong prime numbers p and q, and then randomly selects (a, b) ∈ Zn * ×Zn * , let g = (1 + n) a ×b n modn 2 , and calculate n = pq;

[0114] Then use the scheme described in Section 3.2 to generate the public key PK = (n, g, θ) and the private key decryption share SK i=f(i)modnm, where SK i is the i-th RN i The private key decrypts the share and calculates Public key PK and private key decryption share SK i The TKGC sends the data to TA and RN through secure channels. i ;

[0115] When a DU joins a blockchain network, the TA of the blockchain to which it belongs first assigns it a certificate and attributes. The TA sets the attributes of the DU based on its blockchain, organization, security level, user type, etc., and assigns it the allowed cross-chain operation attributes.

[0116] In the network, TKGC uniformly defines the attribute name and quantity assigned to DU by each TA, that is, the user attribute set S of each chain = {A S1 ,A S2 ,...,A Sn} contains the same number of attributes n, each attribute A Si The corresponding names are uniformly defined by TKGC and made public throughout the network.

[0117] A Si The value of is encrypted by TA using PK; specifically, let the attribute in the attribute set S of DU be E PK (A Si )=[“AttName Si ”: “E PK (AttValue Si )”], where E PK (AttValue Si ) is the result of TA encrypting the attribute value using the public key PK of the threshold cryptographic system.

[0118] That is, the corresponding attribute set of DU on the blockchain is E PK (S) = {[“AttName S1 ”: “E PK (AttValue S1 )”],[“AttName S2 ”: “E PK (AttValue S2 )”],...,[“AttName Sn ”: “E PK (AttValue Sn )”]}.

[0119] 5.3 Data Upload

[0120] When any registered user on the blockchain wants to upload shared data, he can call the data upload function defined in the user contract. Before calling the function, the user can choose to encrypt and store the data in a distributed file system such as IPFS, IPNS, Arweave, etc., and obtain the index address 'hashAdd' and set up a unique identifier 'DID' for the data. We use DID (the unique identification field of the data, defined as DID) to uniquely identify the data and reference the off-chain address of the data through hashAdd.

[0121] Before uploading data, TA needs to encrypt the access control policy of the data, that is, E PK (PR) = E PK [S PR ,O PR ,Condition,P PR ].

[0122] Among them, S PR It is the policy rule that needs to be met when DU allows application to access data. PR is the policy rule related to DO attributes, P PR It is the access operation permission corresponding to the policy rule PR.

[0123] By E PK (PR) replaces the original policy data and stores it in the ACC contract of the blockchain.

[0124] After the user executes the data upload function in the contract, the function generates a data storage transaction TX data , and store the ciphertext of data and access policy on the blockchain ledger.

[0125] At the same time, the data summary "data info "(defined as data in the code info , which is the data summary) is publicly provided to DUs interested in the data to make data requests.

[0126] It is worth noting that data info It does not contain content related to user privacy-sensitive information. The data upload transaction can be expressed as TX data ={DID,data info ,hashAdd,E PK (PR)}.

[0127] 5.4 Data Access Request

[0128] When DU wants to apply for access to DO data, it first calls the user contract, applies for access to the data, and provides encrypted attributes. The user contract determines whether the request requires a cross-chain operation based on the data DID provided by DU. If a cross-chain operation is required, the user contract calls the cross-chain contract, which constructs and sends a cross-chain transaction request (CCTX request ), where CCTX request A code identifier representing a cross-chain transaction request;

[0129] RN signs the cross-chain transaction request, encapsulates the cross-chain transaction according to the defined RNCCP cross-chain protocol, and uses LibP2P to transmit the encapsulated cross-chain transaction data to the RN of the corresponding chain for cross-chain operation processing.

[0130] The cross-chain request after RN encapsulation can be expressed as CCTX request ={CrossTxNo,SrcChainCode,DestChainCode,Proof,CrossChainData,TxResult}, where CrossTxNo=[SrcChainNo:DestChainNo:Number] is a unique cross-chain transaction number created by splicing the source chain number, the destination chain number and the self-increment code. SrcAddress and DestAddress are the numbered addresses of the two parties in the cross-chain respectively. Proof contains the verification information of the cross-chain transaction, including the hash of the cross-chain transaction, the block number of the transaction, the Merkle root hash value and the signature of the cross-chain node on the transaction; RN can perform transaction atomicity verification, signature verification, block header verification, etc. through the Proof field; CrossChainData encapsulates the DID of the DU application for access to data and the encrypted attribute information of the DU E PK (S).

[0131] The details of the access request function are given in Algorithm 1; after the original chain RN signs and confirms the transaction, it finds the address (dest) of the RN node corresponding to the chain in the blockchain database of the relay node chain according to the destination chain number, and uses the communication algorithm between nodes to perform secure communication of cross-chain access requests.

[0132]

[0133] 5.5 Multi-party RN joint decryption authorization

[0134] Based on CCTX request After receiving the cross-chain request, the RN of the chain where DO is located parses the request and extracts the encryption attribute E of DU. PK (S). Then, RN calls the ACC contract to retrieve the encrypted access policy E corresponding to the DID data.PK (PR), and use ACC to calculate E PK (S) and E PK (PR) The difference between the ciphertexts Result;

[0135] Specifically, using the homomorphism of the threshold homomorphic cryptosystem, the difference of the original data is the division of the ciphertext data, and the addition of the original data is the multiplication of the ciphertext data; the master node sets an "addition factor" M X , and use PK to calculate its ciphertext E PK (M X );M X Keep it confidential, ciphertext E PK (M X ) is publicly sent to other RNs in the network for RNs to use to calculate E PK (S) and E PK The difference between (PR).

[0136] Specifically, let the data security level E allowed in policy PR be PK (A PR1 )=[“DataLevel”:“E PK (A)”], the security level attribute of the DU applying for access is E PK (A S1 )=[“DataLevel”:“E PK (B)”]. To prevent attackers from obtaining access policies and user attributes, we transmit and compare the corresponding ciphertexts in the network, namely, ciphertext E PK (A) and E PK (B) According to the homomorphism of the Paillier cryptosystem, M is set by the master node. X >>The maximum value of DataLevel. ACC uses the Paillier cryptographic algorithm to calculate E PK (Result) = E PK (A)*E PK (M X ) / E PK (B), and E PK (Result) is submitted to the RN within the threshold range for joint decryption; finally, the master node combines the joint decryption results to obtain the specific plaintext value "Result", where Result is the plaintext result, marked with the above characters, and the plaintext result of the code is defined as Result;

[0137] According to homomorphism, Result=A+M X -B. If Result>M X, it means A>B, that is, the data security level set by the rule is higher, and the security level of DU does not match it, so the access request is invalid; otherwise, access is allowed.

[0138] To avoid repeated judgments in a short period of time and consumption of computing resources, after the ACC determines the access rights of the DU, the RN dynamically generates an access control permission list and sets the time interval allowed for access control. Within the specified time, the DU can directly control access to the DO through the permission records in the access list. After the specified time, the ACC updates the access control permission list.

[0139] The details of ACC's secure multi-party joint decryption calculation through the threshold Paillier cryptosystem are shown in Algorithm 2; the input of the algorithm is the attribute ciphertext E PK (AttValue Si ), Strategy ciphertext E PK (AttValue SPRi ), Additive factor ciphertext E PK (M X ) and the public key PK. Among them, E PK (AttValue Si ) is a specific encrypted attribute E in the attribute set S PK (A Si )=[“AttName Si ”: “E PK (AttValue Si )”], E PK (AttValue SPRi ) is strategy E PK (PR) = E PK [S PR ,O PR ,Condition,P PR ] The policy rules that need to be met when DU is allowed to apply for access to data S PR The ciphertext value E corresponding to the same AttName PK (AttValue SPRi ), E PK (M X ) is the ciphertext of the addition factor set by the master node, and the public key PK is public among all RNs. The output of the algorithm is the generated ciphertext difference E PK (Result);

[0140] Then, the master node will PK(Result) is shared with RN within the threshold range for decryption, and the partial decryption calculation results of the RN nodes are combined to obtain the final difference result, and the ACC is called to determine the access control authority. At this point, the complete access control process ends; the master node aggregates the partial decryption results of the RN for joint calculation details as shown in Algorithm 3; the algorithm input is the threshold t RN partial decryption E PK (Result) result list "partialDecryptionList", public key PK, M X And the threshold t, the output is calculated as the comparison result "compareResult" between the decrypted value and the addition factor.

[0141]

[0142]

[0143]

[0144] 6. Security and Performance Analysis

[0145] 6.1 Security Analysis

[0146] In our proposed solution, for the user's sensitive data in attributes or policies, whether it is stored on the chain, in the access request of cross-chain interaction, or in the process of smart contract calculation, all the data operated by users, RN nodes, and blockchain nodes are all encrypted data after being encrypted by the threshold Paillier cryptosystem. This means that except for the user himself, no other node can access the original information of sensitive data, thus effectively protecting the privacy of the data in attributes and policies.

[0147] For attackers who try to obtain data by attacking blockchain nodes, our solution adopts the thresholdPaillier cryptosystem algorithm. This algorithm distributes private keys in shards to trusted RNs of different blockchains, making it difficult for attackers to crack RN nodes with high computing and high security performance on different blockchain organizations to obtain t threshold homomorphic decryption private keys to decrypt data. In addition, it is also difficult for attackers to compromise the TKGC that distributes the key. This approach ensures that data remains confidential to unauthorized users, thereby maintaining data privacy and security with access control permissions.

[0148] If an attacker attempts to destroy the DU to obtain indefinite access control rights to DO data, our solution can dynamically generate an access control permission list and set the time interval allowed for access control. Once it is determined that the DU is hijacked, the user's access to the data can be terminated by modifying the access permission list. At the same time, DO dynamically changes the encryption key of the data. Since DU only obtains the storage address of the data, it cannot decrypt the actual original data even after being hijacked.

[0149] In addition, the user's cross-chain request and authorization results are recorded by ACC on the distributed ledger of the relay chain. Since it is difficult for an attacker to control more than 50% of the node computing power of the entire network to tamper with the transaction ledger, the cross-chain request authorization record on the relay chain can provide effective evidence for subsequent audits and access record tracking.

[0150] 6.2 Performance Analysis

[0151] In order to test and evaluate the feasibility and performance of the cross-chain access control scheme based on ABAC and threshold homomorphic encryption technology proposed in this paper, we conducted some experimental simulations. Compared with the existing blockchain access control schemes that store policies and attributes in plain text or encrypt and decrypt data by a single central node, since our scheme is applied in cross-chain scenarios and uses multi-relay node joint decryption technology, this scheme will inevitably generate some additional computational overhead.

[0152] We simulated our solution on a computer with Intel Xeon E5 CPU, 64GB memory, and Ubuntu 18.04 operating system. We used HyperLedger Fabric and FISCO BCOS platforms to build a cross-chain interactive network. In the cross-chain network, the HyperLedger Fabric blockchain network built 11 nodes, including 3 orderer nodes, 4 organizations, and 2 peer nodes in each organization, running the raft consensus algorithm. Three groups with a total of 8 nodes were deployed in the FISCO BCOS network, and raft was selected as the consensus algorithm for the blockchain.

[0153] We used Go and Solidity to develop cross-chain contracts and access control contracts for HyperLedger Fabric and FISCOBCOS platforms, respectively, to enable users to interact with blockchains and perform cross-chain operations through access control. Since the user's attributes and policies need to be encrypted and the RN node segment needs to be jointly decrypted, a JAVA program was also developed to implement the thresholdPaillier cryptosystem algorithm. We set the key size to 128 bits, which is also the number of bits k in p and q, making the security 2k, and control the threshold number of RN nodes through parameters.

[0154] In terms of functionality, our scheme is compared with existing fine-grained access control schemes, as shown in Table 1. We compare them based on five aspects: encryption method, whether policy hiding is supported, whether dynamic update of access rights is supported, traceability, and efficiency. Through comparison, it is found that Yan et al.

[48] adopted the ABE encryption scheme and chose to perform proxy encryption and decryption on the proxy server. Although the encryption and decryption speed is improved, there is a risk of privacy plaintext leakage when the encryption and decryption are handed over to a unified server. Han et al.

[49] adopted blockchain and inner product encryption to achieve access control and policy hiding, but the decryption and encryption time of this scheme is large and the efficiency of the scheme is low. Liang et al.

[50] adopted CP-ABE to encrypt attributes and improved the Paillier homomorphic encryption mechanism to encrypt the original data. Although the encryption and decryption time is reduced, it does not support policy hiding, which may lead to user privacy leakage in the policy. Wu et al.

[51] used an additive homomorphic cryptosystem to encrypt attributes and policies and used multiple blockchain nodes to collectively decrypt data. However, this scheme does not support dynamic changes in access rights, lacks access history tracking, and cannot perform access control in a multi-chain collaborative environment. Compared with the above scheme, our scheme has more comprehensive access control functions and also uses the threshold Paillier cryptosystem and multi-party joint ciphertext calculation to make the solution more secure.

[0155] Table 1 Comparison of access control schemes

[0156]

[0157] In terms of performance, the efficiency of our proposed solution is mainly affected by the threshold Paillier cryptosystem-related algorithm, ciphertext difference calculation, and cross-blockchain operation performance. The performance related to cross-chain operations has been given in previous studies. Therefore, after the smart contract is installed and deployed, we use the SDK provided by the blockchain platform to write the client's cross-chain access control request code to call the smart contract, and evaluate the performance of the other two key steps mentioned above. The experiment was repeated 100 times, and the average value was used as the evaluation standard.

[0158] (1) Time consumption of encryption and decryption based on Paillier threshold cryptosystem

[0159] The time for key generation and encryption / decryption in the Threshold Paillier cryptosystem is related to the number t of RN nodes participating in joint decryption in the cross-chain network and the number n of attributes in the strategy. In order to observe how these factors affect the performance of the threshold Paillier cryptosystem algorithm, we conducted experiments at different scales, testing and analyzing the relationship between the number t of RN nodes and the key generation time and encryption / decryption time, and the relationship between the number n of attributes and encryption time, such as Figure 3-5 shown; from Figure 3 It can be seen that the encryption time of each scheme increases with the number of attributes. In addition, the time consumed by our scheme is less than that of Yan et al. and Huang et al. Figure 4 and Figure 5 The relationship between the number of RN nodes and the key generation time and decryption time is compared respectively. It can be seen from the figure that the time consumption of our scheme increases with the increase of RN nodes. And when the number of RN nodes increases to a certain amount, the key generation time increases exponentially. Since the private key share of each RN node is generated during the system initialization phase, the key generation time does not affect the access control throughput of the system. In addition, the joint decryption time of our scheme increases linearly with the number of RNs, and the average time is about 13.75ms, which can meet the system requirements. Figure 6We compared the decryption time of our scheme when the number of joint decryption nodes is fixed with the time consumption of other single-node decryption schemes and the relationship between the number of attributes. Since our scheme performs differential calculations on ciphertexts and only decrypts the final result, the decryption time consumption of our scheme is independent of the attributes and is stable at around 5ms. The scheme of Yan et al. supports proxy decryption, and the user decryption time is stable at around 1.5ms. The decryption time of Xu et al.'s scheme is stable at 20ms and is always a constant. The decryption time of Huang et al.'s scheme is positively correlated with the attributes, and the time cost is higher than our scheme. This proves that our scheme has advantages in different stages such as data encryption and decryption, joint calculation of ciphertext differences, and also meets the requirements of cross-chain access control in the decryption stage.

[0160] (2) Calculation and judgment of ciphertext differences

[0161] Since our solution involves multiple cross-chain participants, for the sake of system security, we use the homomorphism of the homomorphic cryptographic system for ciphertexts. By calculating the difference of ciphertexts and jointly decrypting them, we can more safely avoid the risk of plaintext leakage in the access policy. Figure 7 It can be seen that the ciphertext difference calculation time is positively correlated with the number of attributes. We measured that the average time for off-chain ciphertext difference calculation is 7ms. Since the ciphertext difference calculation needs to be called by the ACC contract and judged after calculation, the average time consumption for calculation and judgment is about 2.3s, and the overall time meets our cross-chain system requirements.

[0162] In view of the problem of secure access control of inter-chain data in the process of cross-chain network interoperation, as well as the problems of easy leakage of plaintext storage of access policies, untraceable access records, and threats to data privacy security in the current access control system, we proposed a heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption. This scheme completely hides attributes and policies, and securely protects cross-chain data and its privacy information while ensuring fine-grained access control. By using the threshold Paillier cryptosystem, the ciphertext is calculated without decrypting user attributes and access policies, and the results are jointly decrypted by multiple parties across the chain, ensuring the security of private data. At the same time, smart contracts are used to track and record user access history, and dynamic updates of user access rights are guaranteed. Experimental analysis and results show that the mechanism is more comprehensive in access control functions, can effectively meet the access control requirements in multi-chain collaborative scenarios, and provide effective technical support for cross-chain data sharing and collaboration. Through experiments, our scheme has been tested on platforms such as Hyperledger Fabric and FISCO BCOS to verify its stability and adaptability, providing strong support for practical applications.

[0163] The above description is only for illustrating the present invention. It should be understood that the present invention is not limited to the above embodiments, and various variations that conform to the concept of the present invention are within the protection scope of the present invention.

Claims

1. A heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption, characterized in that: It includes the following parts: data owner, data user, relay node cross-chain protocol, relay node, trusted authority, threshold key generation center; The access control method specifically comprises the following steps: S1: Data owners and data users obtain identity certificates and corresponding encrypted attributes or policies from the relay nodes of their blockchains; S2: The data owner uploads the encrypted access policy and its data summary information to the blockchain and provides it to nodes inside and outside the chain to apply for access; S3: When a data user applies to access the data of a data owner on a certain chain, he needs to submit a cross-chain access request to the relay node corresponding to the blockchain where he is located; S4: The relay node passes the request to the relay node of the blockchain where the data owner is located. The relay node of the blockchain where the data owner is located calls the access control contract to perform the difference calculation of the policy and attributes, and sends the difference ciphertext to all relay nodes within the threshold range for partial decryption calculation; S5: The master node collects and merges all partial decryption results to obtain the final joint decryption result, and sends it to the relay node of the blockchain where the data owner is located; S6: The relay node of the blockchain where the data owner is located calls the access control contract to determine whether cross-chain operation access can be authorized.

2. According to the threshold homomorphic encryption-based heterogeneous multi-chain data cross-domain access control method of claim 1, it is characterized in that: Several of the relay nodes constitute a relay node chain and the relay node chain includes three types of relay nodes: a master node, a cross-chain node, and a light node. There is only one master node in the cross-chain network.

3. According to the threshold homomorphic encryption-based heterogeneous multi-chain data cross-domain access control method of claim 1, it is characterized in that: The data owner and data user perform data sharing and encrypted upload operations through the user contract providing an interface; The cross-chain interoperability between the user, blockchain and relay node chain is realized by the cross-chain contract, which transfers data with the user contract and receives the user's cross-chain request.

4. According to the threshold homomorphic encryption-based heterogeneous multi-chain data cross-domain access control method of claim 1, it is characterized in that: The relay node recommended by each blockchain in the cross-chain network generates the key share of the corresponding threshold homomorphic cryptographic system by the threshold key generation center, and sends it to each relay node together with the public key in a secure manner.

5. According to the threshold homomorphic encryption-based heterogeneous multi-chain data cross-domain access control method of claim 1, it is characterized in that: The access control contract includes the following steps: S1: When a data user wants to join a blockchain network, the trusted authority of the blockchain to which he belongs assigns him a certificate and attributes; S2: Before uploading data, the data owner needs to encrypt the access control policy of the data by the corresponding trusted authority; S3: When a data user applies to access the data owner's data, the user contract is called to apply for access to the data and provide encrypted attributes. The user contract determines whether the request requires a cross-chain operation based on the data provided by the data user. S4: If cross-chain operation is required, the user contract calls the cross-chain contract and the cross-chain contract constructs and sends a cross-chain transaction request. The relay node signs the cross-chain transaction request and encapsulates the cross-chain transaction according to the relay node cross-chain protocol. S5: Use LibP2P to transmit the encapsulated cross-chain transaction data to the relay node of the corresponding chain for cross-chain operation processing; S6: After receiving the cross-chain request, the relay node of the blockchain where the data owner is located parses the request and extracts the encrypted attributes of the data user. Then, the relay node calls the access control contract to retrieve the encrypted access policy of the data corresponding to the DID, and uses the access control contract to calculate the difference between the encrypted attributes and the encrypted access policy. S7: The master node shares the difference in S6 with the relay nodes within the threshold range for joint decryption, and combines the partial decryption calculation results of the relay nodes to obtain the final difference result; S8: The difference in S7 is determined through the access control contract to determine whether the access request is valid.

6. The heterogeneous multi-chain data cross-domain access control method based on threshold homomorphic encryption according to claim 5 is characterized in that: After the access control contract determines the access rights of the data user, the relay node dynamically generates an access control permission list and sets the access control permission time interval. After the specified time, the access control contract updates the access control permission list.

Images