CDAS: A Secure Cross-Domain Data Sharing Scheme Based on Blockchain

Abstract

In the current context of the wide application of Internet of Things (IoT) technology, cross-domain data sharing based on industrial IoT (IIoT) has become the key to maximizing data value, but it also faces many challenges. In response to the security and privacy issues in cross-domain data sharing, we proposed a cross-domain secure data sharing scheme (CDAS) based on multiple blockchains. The scheme first designs the cross-domain blockchain in layers and assists the device in completing the data sharing on the chain through the blockchain layer close to the edge device. In addition, we combine smart contract design to implement attribute-based access control (ABAC) and anonymous identity registration. This method simplifies device resource access by minimizing middleware confirmation, double-checking device access rights, and preventing redundant requests caused by illegal access attempts. Finally, in terms of data privacy and security, IPFS is used to store confidential data. In terms of ensuring data sharing security, searchable encryption (SE) is applied to the overall data sharing and improved. Users can find the required data by searching the ciphertext links in the blockchain system to ensure the secure transmission of private data. Compared with the traditional ABAC scheme, we have added modules for data privacy protection and anonymous authentication to further protect user data privacy. At the same time, compared with the access control scheme based on attribute encryption, our scheme has certain advantages in the time complexity calculation of key algorithms such as policy matching and encryption algorithm. At the same time, with the assistance of the edge blockchain layer, it can reduce the burden of limited computing resources of the device. This scheme can solve the security and efficiency problems of cross-domain data sharing in the industrial Internet of Things through security and experimental analysis.

1. Introduction

As the scale of industrial networks continues to expand and the amount of data grows rapidly, effectively sharing data and mining the potential value are essential for industrial automation transformation [1,2,3]. It has become a trend to connect factory equipment using Industrial Internet of Things (IIoT) technology to automate production tasks. This approach not only improves productivity and reduces management costs, but also addresses the extremely complex challenges of the manufacturing industry. As production processes become more integrated and cross-domain, equipment in different fields needs to communicate and collaborate to achieve smooth overall production [4]. In order to share data safely, there are currently two challenges that should be addressed.

To achieve data sharing between devices in different domains, the issue of inter-domain trust must be resolved [5]. In addition, there are also security and privacy issues when using third-party cloud service platforms for data storage and sharing [6,7,8]. In short, all of these challenges are related to identity authentication.

Traditional authentication schemes usually rely on centralized servers, which pose security risks of single point of failure and centralized management. Due to the ability to provide a unified, interoperable, and tamper-proof infrastructure to solve the problem of large-scale IoT device authentication, blockchain technology has a promising application in identity management for IIoT [9]. Blockchain uses a decentralized approach to record and verify each identity with a distributed ledger, eliminating the risk of single–point failure and improving the robustness and security of the system [10]. Searchable encryption, as a key technique in the field of cryptography [11], realizes efficient search operations on encrypted data while guaranteeing data security. The technique allows data to be stored in encrypted form in the cloud or other untrustworthy storage media, and the data owner (or authorized user) can retrieve encrypted data segments containing relevant information based on specific keywords or query conditions without decrypting the entire data set. Attribute-based encryption searchable encryption schemes can solve the data sharing security and privacy issues, and have been studied by several people [12,13,14], but most of the schemes require complex matching of policies and attribute encryption computation, etc., and some of them even change exponentially with the increase of the number of attributes, which will consume a large amount of time and computational resources, and there are some challenges for resource-constrained industrial IoT devices, which may not be suitable in the industrial IoT. A federation chain is a distributed ledger maintained by multiple collaborating peer-to-peer nodes. It is a permissioned blockchain [15], whose network nodes must be authenticated before joining the network. However, they are regulated by certain contracts and work collaboratively. Blockchain has been used as a supporting technology in multiparty schemes [4,16]. This scheme combines attribute-based access control (ABAC) with cryptographic search to achieve policy matching and data sharing for access control through a multi-layer blockchain, reducing the overhead of attribute computation for the whole process. Our approach is summarized as follows:

• We propose a blockchain-based secure cross-domain data sharing scheme (CDAS) that combines an ABAC and searchable encryption with blockchain to achieve secure and fine-grained access to data for users. While ensuring access control efficiency, it also solves the problems of single point of failure and data privacy protection in traditional data sharing schemes.
• Considering the transmission distance delay between the edge devices and the central organization as well as the limited device resources, we adopt a multi-layer blockchain architecture to assist industrial IoT devices in completing data sharing and other computing authentication operations through edge servers.
• This paper analyzes the security schemes for data privacy in cross-domain data sharing. In order to ensure data security, we transform the traditional cloud-based processing scheme into using IPFS for ciphertext storage, and use anonymous authentication and searchable encryption to achieve the transmission of private data.

The remainder of this paper is organized as follows: Section 2 and Section 3 present related work and relevant background knowledge, respectively. Section 4 presents the system model and its specific details. In Section 5, we details the key algorithms of our proposed scheme. A security analysis is performed in Section 6, followed by a comprehensive performance evaluation in Section 7. Finally, we conclude our work in Section 8.

2. Related Work

With the advantages of immutability and decentralization, blockchain makes it not only applicable to cryptocurrencies but also effective in solving a single point of failure and enhancing security in IIoT applications [17]. In addition, it can provide trusted data and policy management for data sharing and access control models, thereby achieving reliable and traceable cross-domain identity authentication. For example, Yu et al. [18] ensured the privacy of each device by using group signatures for anonymous authentication. Furthermore, they stored the collected data in encrypted form and adopted smart contracts and proxy re-encryption technology to achieve secure cross-domain data sharing. Meneghello et al. [19] used smart contracts to manage device public keys, and designed a cross-domain key protocol to achieve anonymous, temporary, and complete cross-domain authentication. Singh et al. [20] proposed a cloud-based centralized cross-domain data sharing platform utilizing multiple secure gateways that store information in a centralized cloud based on blockchain. Once an application reports malicious activity, the centralized cloud will verify the issue from the blockchain.

In traditional IIoT ecosystems, sensitive data storage relies on Trusted Third Parties (TTP), which act as middleware for device authentication. However, these ecosystems often face a single point of failure and lack of trust, especially in cross-domain collaboration. To address these challenges, Dwivedi et al. [21] proposed an identity verification mechanism using smart contracts and IPFS for data storage. They also designed an access control scheme to restrict unauthorized nodes from accessing data. Zeng et al. [22] developed a blockchain-assisted cross-domain data sharing scheme (BCDS). In this scheme, resource-constrained IoT devices act as client nodes and cannot participate in consensus. Additionally, they designed a key agreement protocol to ensure the security of data transmission. Kamboj et al. [23] combined role-based access control (RBAC) with smart contracts to manage user roles within organizations, addressing issues of identity authentication and permission assignments.

Traditional access control schemes require complex identity authentication and management communication with domain management servers, resulting in significant communication overhead and centralized dependency. Han et al. [24] leveraged the decentralized nature of blockchain and its ability to ensure data integrity by integrating ABAC with blockchain. This approach enables fine-grained, secure, and auditable access control for private data, overcoming the limitations of traditional methods in the IoT environment. Furthermore, traditional access control methods also struggle to support the security of private data schemes in the current IoT landscape. To protect data privacy, some studies have been conducted by using searchable encryption. Wu et al. [25] proposed a hidden policy attribute data sharing scheme with direct revocation and keyword search, where the search time does not increase with the increase of attributes. Liu et al. [26] proposed a blockchain-assisted searchable attribute-based encryption (BC-SABE) scheme with revocation and decryption functions, which can decentralize key management and revoke keys. However, in the above scheme, the user’s encryption and decryption as well as the search are bound to the user’s attributes. Changing the user’s attribute permissions in subsequent permission changes will become more complicated, and at the same time will bring greater computing and communication overhead.

Although blockchain has many advantages, it will increase computing work and time latency, while the storage and throughput also need to be considered. Zhang et al. [27] designed a policy-hiding attribute-based searchable encryption scheme and use IPFS to store ciphertext data. Shen et al. [4] designed off-chain storage to eliminate throughput bottlenecks by reducing the amount of data written to the blockchain. In addition, access control may become an additional burden due to the limited computing and storage resources of IoT devices. Therefore, Guo et al. [28] established the management of regional devices by using smart gateways and used smart contracts to achieve automatic access policies. Furthermore, they considered the temporal and spatial attributes of the devices to achieve unified access control management for IoT devices in different regions. To address the challenges of security and heterogeneity of cross-domain collaboration in IIOT, Zeng et al. [22] designed a blockchain-assisted cross-domain data sharing scheme (BCDS), in which resource-constrained IoT devices act as client nodes and do not participate in consensus, and designed a key agreement protocol to ensure the security of subsequent data transmission.

3. Preliminaries

3.1. Blockchain

On the blockchain, data is stored in a distributed ledger, which is characterized by decentralization and immutability. Blockchain ensures data integrity and availability, allowing network participants to write, read and verify transaction records [29]. It not only provides a distributed and unchangeable record of all events that have occurred, but also enables many practical applications through smart contracts, such as traceability assistance, record management, supply chain automation and payment applications, thus providing a wide range of opportunities for commercial transactions [30]. Furthermore, it collectively maintains and updates data through multiple nodes in a distributed network, and uses cryptographic hash functions to connect each block to form an unalterable chain. Any modification to a single block will compromise the integrity of the entire chain, ensuring the reliability of the data. For all participants in the blockchain network, they jointly maintain a distributed ledger and update the ledger through a consensus mechanism. Common consensus mechanisms include Proof of Work (PoW), Proof of Stake (PoS), and Practical Byzantine Fault Tolerance (PBFT).

In addition, smart contracts are an important application of blockchain and are automatic programs running on the blockchain. Once a smart contract is deployed, it is replicated to every consensus node in the blockchain network, and its execution is not affected by human intervention. When the conditions are met, the contract will automatically execute, avoiding disputes caused by improper human operation or different interpretations [31].

3.2. Bilinear Map

Let both G and $GT$ be multiplicative cyclic groups of order p, and g be the generator of G, and $Z_p$ be a finite field. Then the bilinear map $e:G\times G\to GT$ satisfies the following three properties [32]:

• Bilinearity: For any $u,v\in G$ and $a,b\in Zp$, it holds that $e(u^a,v^b)=e{(u,v)}^{ab}$.
• Non-degeneracy: There exists at least one element $g\in G$ such that $e(g,g)\ne 1$.
• Efficiency: For any $u,v\in G$, $e(u,v)$ can be computed efficiently.

3.3. Access Control Model

IoT systems can be compromised during data sharing, resulting in the legitimate interests of related resources (e.g., data, services, storage units, computational units, etc.) being accessed by malicious parties. Access control is the main way to prevent unauthorized entities from illegally accessing resources [33]. Currently, most IoT access control mechanisms include three main types: RBAC, CapBAC, and ABAC [9]. RBAC models require assigning permissions to different roles, and managing these permissions becomes difficult when multi-party relationships become complex. Most CapBAC systems concentrate on policy storage and its management, and in complex IoT environments, this centralization can become a bottleneck [9,34]. In contrast, the ABAC model combines the current roles and characteristics of entities to enable fine-grained access control and is therefore more flexible and secure. It implements flexible access policies by defining a set of attributes (e.g., user identity, device type, time, geographic location, etc.) that can be adapted to complex IoT environments. Therefore, in this paper, we combine ABAC with blockchain to enhance the security of cross-domain IoT systems. We store access control policies and access records in the blockchain, which not only ensures the security and reliability of data, but also reduces the potential risk of identity theft.

3.4. Interplanetary File System

Interplanetary File System (IPFS) (https://docs.ipfs.tech/, accessed on 5 May 2025) is a distributed data storage protocol that stores data based on content addressing and uses a decentralized P2P transmission model. It does not rely on a separate storage server, which solves the security problem of centralized storage, and has a deduplication mechanism to make the system more efficient [35]. After the data is uploaded to the IPFS system, the content is segmented, and the hash value of each segment is calculated using the Merkle tree to obtain the root hash value. Data users can use the root hash value to query the uploaded data, and the hash value calculation ensures that the uploaded files will not be tampered with. IPFS data storage is the main storage medium of the entire distributed data management system. After hash processing, the information is submitted to the blockchain as an index for data query and saved and shared [36,37]. The blockchain only stores the hash value of the data, which can solve the efficiency and scalability problems of consensus synchronization in the blockchain.

4. Cross-Domain Multi-Layer Blockchain Model

In this section, we will introduce the system architecture and process of our scheme.

4.1. System Model

As shown in Figure 1, the architecture of our scheme consists of three types of entities.

• DS (Internet of Things Devices): This represents resource-constrained industrial IoT devices with limited computing power and storage resources.
• ES (Edge Servers): This refers to servers close to edge devices with certain computing and storage capabilities. Each factory may be distributed in different regions and may consist of multiple ES, but the number of ES needs to meet Byzantine or other constraints. The ES of each domain jointly form the edge blockchain layer, which is responsible for assisting DS devices in completing operations such as data sharing.
• AS (Domain Master Device Servers): This consists of master devices in the domain, and each domain has a master device. It is used for cross-domain collaboration, cross-domain authentication, and access control operations. It also supports the management of devices within the domain, the generation of on-chain keys of devices, etc. Additionally, it provides decentralized sharing services and stores the public parameters of on-chain nodes.

In our scheme, the full node consists of all domains AS and DS. To ensure fairness, we set a threshold, denoted as P, to define the range of the number of institutions allowed to join the full node network. Specifically, assuming there are m institutions and n full nodes, the number of full nodes in each domain needs to satisfy $m<P<(n-1)/3$.

4.2. Scheme Process

The scheme is divided into multiple steps to achieve secure data sharing. DS devices play two roles: data requester $D{S}_R$ and data owner $D{S}_O$. The process is as follows:

• User Registration: Users perform anonymous registration before joining the blockchain.
• Data Storage:
  • Off-Chain Shared Information Storage: $D{S}_O$ encrypts the original data with a symmetric key and stores it in IPFS, and generates an encrypted file index.
  • On-Chain Data Storage: Devices and users upload key data to the blockchain.
• File Keyword Encryption: Devices can encrypt keywords of shareable file in advance and store them on the blockchain for subsequent retrieval of file information.
• Data Request: The data request process is divided into multiple parts.

  (a)

  $D{S}_R$ initiates a cross-domain data request to the edge blockchain layer.

  (b)

  When $E{S}_R$ of $D{S}_R$ receives the request, if the request is authenticated, $E{S}_R$ will synchronize the request with other edge devices on the blockchain.

  (c)

  After $E{S}_O$ of $D{S}_O$ receives the request, it will execute the on-chain access control contract to verify whether the attributes of the requester and the requested object meet the access control policy.

  (d)

  After passing the access control check, $D{S}_R$ invokes the trapdoor generation algorithm to output the trapdoor, and uploads it to the edge blockchain layer.

  (e)

  $E{S}_O$ of the edge blockchain layer invokes the search algorithm and compares $m^{\prime }$ in the trapdoor value with m in the keyword ciphertext. If the corresponding ciphertext file is retrieved, the result will be transmitted to the $A{S}_O$ device in the domain. Subsequently, $A{S}_O$ encrypts the encrypted file index and the symmetric key and uploads them to the blockchain, and synchronizes them to the edge blockchain layer.

• Data Decryption: $D{S}_R$ receives the ciphertext information sent by the edge layer, decrypts the encrypted result with the private key to obtain the symmetric key and the link $URL\left(K\right(F\left)\right)$ of the original file ciphertext. Then, it sends a link data request to IPFS, obtains the ciphertext of the original file, and decrypts it to obtain the original data file M.

4.3. Threat Model

In this section, we will describe the security of this scheme under the IND-CKA and IND-CPA models.

• IND-CKA security: The IND-CPA security of our scheme uses the game between the adversary A and the challenger C as follows:

• Init: A selects the access structure and sends it to C.
• Setup: C calculates the system parameters and sends them to A.
• Query phase 1: A sends a query to the oracle, and C responds as follows:

  (a)

  Key generation: C executes the key generation algorithm to generate the user’s key and sends it to A.

  (b)

  Threshold phase: A selects any keyword $W^{\prime }$, C executes the $Trapdoor$ algorithm to generate the trapdoor $T{W}^{\prime }$ and sends it to A.

• Challenge: A submits two keywords $W_0$ and $W_1$ of equal length, and C randomly selects a bit $b\in \{0,1\}$ to calculate the ciphertext $C{W}_b$ and sends it to A.
• Query phase 2: It is similar to phase 1.
• Guess: A outputs the guess value $b^{\prime }$, and wins the game if $b^{\prime }=b$. The probability of A winning the game is $Ad{v}_A^{CKA}=|Pr[b^{\prime }=b]-1/2|$.

• IND-CPA security: The IND-CPA security of our scheme uses the game between adversaries A and C.

• Init: C executes the setup algorithm and then sends $GP$ to A.
• Query phase 1: A executes the key generation algorithm on the challenger, generates the user’s key, and sends it to A.
• Challenge: A sends two identical messages $M_0$ and $M_1$ to C. C randomly selects a bit $\chi \in \{0,1\}$, calculates the ciphertext $C_0$ and $C_K$ according to a specific rule, and sends $<C_0,C_K>$ to A.
• Query phase 2: A continues to request operations to C, but the request content cannot contain $M_0$ and $M_1$.
• Guess: A guesses the bit $\chi$ previously selected by C. The advantage of A in this attack is measured according to the result of his guess, and then the security of the encryption scheme under the IND-CPA security model is evaluated. A outputs the guess value ${\chi }^{\prime }$, and if ${\chi }^{\prime }=\chi$, A will win. The probability of A winning the game is $Ad{v}_A^{CPA}=|Pr[{\chi }^{\prime }=\chi ]-1/2|$.

5. Specific Algorithm Analysis of the Scheme

5.1. System Initialization

$Setup\left(\lambda \right)\to (GP,PK,MSK)$: The AS takes the security parameter $\lambda$ as input and outputs the public global parameter $GP$, the initial public key $Pk$, the system master key $MSK$, and the user identity information pair. Then, it selects two cyclic multiplication groups $G0$ and $GT$ with the prime number q as order, g is the generator of $G0$, and e is the bilinear map of $G0\times G0=GT$.

• Select random numbers $\alpha ,\beta ,\gamma \in Z_q$.
• Calculate $Y=e{(g,g)}^{\alpha }$, $g_a=g^{\alpha },g_b=g^{\beta },g_c=g^{\gamma }$.
• $GP=<G0,Y,g,e,g_a,g_b,g_c>$, and $MSK=<\alpha ,\beta ,\gamma >$.

5.2. Key Generation Algorithm

$KeyGen(GP,MSK,DID)\to (SK,PK)$: This key generation algorithm takes as input the relevant parameters $GP=<G0,Y,g,e,g_a,g_b,g_c>$, $MSK=<\alpha ,\beta ,\gamma >$ and the user’s anonymous identity DID, and is used to generate the user’s public–private key pair. The specific steps of the algorithm are as follows:

• Select a random number $t\in Zq$.
• Calculate the identity-based hash value: $I=H\left(DID\right)$.
• Calculate $D_0=g^{\alpha \gamma It}$, $D_1=g^t$, and $D_2=g^I{g}^t$. Generate the identity-based public-private key pair $(SK,PK)$ for ES and DS. Generate the user’s private key $SK=⟨D_0,I,t⟩$ for later decryption, and the user’s public key $PK=⟨D_1,D_2⟩.$

5.3. User Registration

For devices, they can only join the blockchain network after being authorized by the domain manager, and must be authenticated when registering on the blockchain to ensure cross-domain anonymity. We have set up anonymous credential issuance and management for anonymous device authentication on the blockchain. Figure 2 shows the on-chain process of device registration within the domain, including the issuance and verification of identity credentials. The steps are as follows:

• DS selects a secure random number $u(u\in Z_P)$ and combines it with its own real identity UID to generate its anonymous identity.

  $$DI{D}_i={UID}_i·{{(PK}_i^{ES})}^u,m=g^u$$
• Application for identity certificate DS initiates an identity certificate request and uses the private key ${sk}_i^{DS}$ of DS to sign the anonymous identity message of DS.

  $$M=message\left(DID\right|\left|m\right|\left|Sign\right({sk}_i^{DS}\left|\right|DID\left|\right|m\left)\right)$$
• AS verifies the identity of the DS and signs the message.

  $$Verify({pk}_i^{DS}\left|\right|DID\left|\right|m\left|\right|Sign({sk}_i^{DS}\left|\right|DID\left|\right|m\left)\right)$$
• AS issues in-domain identity credentials, while AS signs the identity using the private key on the blockchain.

  $$TokenN=DID\left|\right|m\left|\right|Domain\left|\right|Sign\left({sk}_i^{AS}\right|\left|DID\right|\left|m\right|\left|Domain\right)$$
• DS initiates a registration request to the blockchain network.
• The blockchain (BC) uses the corresponding AS’s on-chain public key from the respective domain to verify its identity credentials.

  $$Verify\left(TokenN\right|\left|{pk}_i^{AS}\right)$$
• The aforementioned steps lead to the successful registration of DS, and BC returns the node certificate.

5.4. Data Storage

Data storage mainly consists of two parts: off-chain and on-chain storage.

• Off-chain Shared Data Storage
  $Upload(K,F,SK)\to URL\left(K\right(F\left)\right)$: $D{S}_O$ encrypts the original data with a symmetric key and stores it in IPFS, then returns the link $URL\left(K\right(F\left)\right)$. The data owner $D{S}_O$ encrypts the data of the industrial IoT device. Specifically, it uses the AES-based symmetric key K to encrypt the original file $CM$. Then it uploads the encrypted file to IPFS and obtains the IPFS file link $URL\left(K\right(F\left)\right)$. The data owner $D{S}_O$ saves $URL\left(K\right(F\left)\right)$ and the symmetric key K of the encrypted file to the domain master device (AS) within the domain through in-domain transmission for subsequent data sharing.
• On-Chain Data Storage
  Devices and users upload key data to the blockchain. The master device uploads the data of all nodes to the blockchain according to requirements and synchronizes with other consensus nodes to complete the data storage of the blockchain.
  $Upload\_BC(DATA,Addr,Attr,Policy)$: The master device (AS) of each domain combines the key data of all devices within the domain, device attributes, device resource attributes, resource access policies, and other information with the address, and then invokes the corresponding smart contract to upload them to the blockchain. The nodes of the on-chain device can obtain the public key data of other on-chain devices through the address $Addr$ of the target device. The key data of the device includes the following:

  $$DATA\left(DID\right|\left|Domn\right|\left|PK\right|\left|Type\right|\left|TS\right)$$
  It includes the user’s anonymous identity $DID$ and affiliated domain $Domn$, the device’s public key $PK$, the device type $Type$, the timestamp $TS$, the encrypted file link, etc.

5.5. Data Keyword Encryption

$Enc(GP,W)\to \left(C_W\right)$: The inputs are the keyword dataset W extracted from the original data and the system parameters $GP=<G0,Y,g,e,g_a,g_b,g_c>$. The data owner executes this algorithm as follows:

• Randomly select $t_1,t_2\in Z_q$.
• Calculate: $m=H\left(W\right)$, $w_0=g_a^{(t_1+t_2)}$, $w_1=g_b^{t_1}$.
• Calculate: $c_1=g_c^{t_1}$, $c=w_0·w_1^m$, $c_2=g^{t_2}$.
• $C_W=<c_1,c,c_2>$.

5.6. Data Request

The data request stage is mainly divided into four phases: access control, trapdoor generation, encrypted search, and decryption.

5.6.1. Access Control

Our scheme integrates ABAC with blockchain to create a blockchain-based access control framework. It enables on-chain autonomy through smart contracts, without the need for the third-party in the access control process. We upload access control policies and device attributes to the blockchain through smart contracts, which include DC, RC, PGC, JC, and ACC contracts. Based on them, we can implement cross-domain access control securely and flexibly.

• DC: It can manage and query the attributes of device entities (DS), and store multiple DS attributes: $D{S}_n=\{D{S}_1,D{S}_2,D{S}_3,...\}$, where each address can store only one set of DS attributes: $D{S}_i=\{D_1,D_2,D_3,...\}$. As shown in

  Table 1. Interfaces and functions of DC contract.

  Contract	Interface	Function
  DC.sol	Authorities_only()	Only the permission owner can invoke the functions
  	DSAdd()	AS Adds the attributes of the device in the domain
  	DSDelete()	Delete the attributes of the device
  	DSUpdate()	Update the attributes of the device
  	CheckDS()	Check the device’s attributes in the BC

  , DC can perform operations such as adding, modifying, and querying attributes.
• RC: It can manage and query the attributes of resource entities (RS), and store multiple RS attributes: $R{S}_n=\{R{S}_1,R{S}_2,R{S}_3,...\}$, where each device address can store only one set of RS attributes: $R{S}_i=\{R_1,R_2,R_3,...\}$. As shown in

  Table 2. Interfaces and functions of RC contract.

  Contract	Interface	Function
  RC.sol	Authorities_only()	Only the permission owner can invoke the functions
  	RSAdd()	AS adds the attributes of the resource in the domain
  	RSDelete()	Delete the attributes of the resource
  	RSUpdate()	Update the attributes of the resource
  	CheckRS()	Check the resource’s attributes in the BC

  , it can perform operations such as adding, modifying, and querying attributes.
• PGC: As shown in

  Table 3. Interfaces and functions of PG contract.

  Contract	Interface	Function
  PG.sol	AddPolicy()	Add policy
  	DeletePolicy()	Deletion policy
  	Match()	Policy matching

  , it mainly implements the management function of access control policy, including adding and modifying policies, etc. The data applicant must verify that its access request complies with the policy by invoking this contract. An access request will be approved only if the attributes of the requester and the resource being accessed meet all the management policy criteria.
  For example, assume that a resource $R{S}_i$ has the following attributes: $R{S}_i=\{DomainA,Assembly\_Process,Secret,Assembly\_Machine,2025-01-01\}$, and the access policy of $R{S}_i$ is $Polic{y}_i=\{Domain\in \{DomainA,DomainB,DomainC\}$, $Position=Assembly,Level=high,Type\_Access\in \{Machine,Testing\_Equipment\}$, $Operation=Read,R{S}_i\}$. Among them, $Assembly\_Process$ means that the resource type is assembly process, $Secret$ means that the resource level is confidential, and $Assembly\_Machine$ means that the applicable equipment is machine operation. If a device $D{S}_j$ has the attributes $D{S}_j=\{Assembly,High,DomainB,Testing\_Equipment,Read\}$, then it can access $R{S}_i$.
• JC: As shown in

  Table 4. Interfaces and functions of JC contract.

  Contract	Interface	Function
  JC.sol	AddBlackList()	Add to the permanent blacklist
  	CheckBlackList()	Check if the user is in the blacklist
  	AddBlocked()	Add to the temporary blacklist
  	CheckBlocked()	Check if the user is blocked

  , it mainly determines whether the current data accessor meets the normal access status and detects whether its attributes are in the temporary blacklist. If a node is monitored, any malicious behaviors it performs will be added to the temporary blacklist. When ACC determines that the current data request is malicious, the JC will be triggered. At the same time, JC records the current access record to audit the access behavior on the chain. When the number of malicious behaviors monitored on the current node exceeds a certain number, it will be added to the permanent blacklist, and access control will not be possible.
• ACC: It controls the access between the current account and the access object, and only allows accounts that meet all conditions to pass. It compares the received access control attributes with the attributes specified in the access control policy and returns the corresponding access result.

  (a)

  RequestListen function: When monitoring for malicious behavior, the AddBlocked() in the JC will be triggered to freeze the account’s transactions until the end of the penalty period. In addition, if the account has committed more than 10 illegal behaviors, the AddBlackList() will be called to add it to the permanent blacklist.

  (b)

  Access function: As shown in Algorithm 1, the visitor and requester are first authenticated by calling Authentic() to verify the account addresses of the visitor and data provider and query whether they exist in the blockchain system. Then, the checkBlackList() in the JC is called to determine if the account is blacklisted. Additionally, the checkBlocked() is called to verify that the account is currently on the temporary blacklist and whether the transaction has been released. If the transaction has been released, the subsequent operations continue. Finally, the DC, RC, and PC contracts are invoked to match the attributes of visitors with the policy of the access object.

Algorithm 1: Access Function

5.6.2. Trapdoor Generation

$Trapdoor(GP,SK,PK,W^{\prime })\to T{W}^{\prime }$: The inputs are the global parameters $GP$, the private key $SK=<D_0,I,t>$, the public key $PK=<D,g_t>$ of the data requester $D{S}_R$, and the input of the keyword $W^{\prime }$ by $D{S}_R$. The specific steps are as follows:

• Randomly select $s\in Z_q$.
• Calculate: $m^{\prime }=H\left(W^{\prime }\right)$.
• Calculate: $T_1={(g_b^{m^{\prime }}·g_a)}^{s·I}$, $T_2=g_a^{s·I}$, $T_3=D_0^s$, and $T{W}^{\prime }=<T_1,T_2,T_3>$.

5.6.3. Encrypted File Retrieval

$Search(GP,CW,T{W}^{\prime })\to (CF,\perp )$: The input includes the global parameters $GP=<G0,Y,g,e,g_a,g_b,g_c>$, the keyword ciphertext $CW=<c1,c,c2>$ and the trapdoor $T_W^{\prime }=<T_1,T_2,T_3>$. The edge blockchain layer calculates and determines whether the final results of $Pm$ and $P{m}^{\prime }$ are equal. The specific calculations are as follows:

• Calculate:

  $$\begin{array}{cc}\hfill P_m& =e(c,T_2)\hfill \\ \hfill & =e(g_c^{t_1},g_a^{s·I})\hfill \\ \hfill & =e(g^{\alpha (t_1+t_2)+\beta t_{1}m)},g^{\gamma s·I})\hfill \\ \hfill & =e{(g,g)}^{\gamma s·I(\alpha (t_1+t_2)+\beta t_{1}m)}\hfill \end{array}$$

  (1)
• Calculate:

  $$\begin{array}{cc}\hfill P_m^{\prime }& =e(c_1,T_1)·e(c_2,T_3)\hfill \\ \hfill & =e(g^{\gamma t_1},g^{s·I(\beta m^{\prime }+\alpha )})·e(g^{t_2},g^{\alpha \gamma s·I})\hfill \\ \hfill & =e{(g,g)}^{\gamma t_{1}s·I(\beta m^{\prime }+\alpha )}·e{(g,g)}^{\alpha \gamma s·I{t}_2}\hfill \\ \hfill & =e(g^{\alpha (t_1+t_2)+\beta t_{1}m)},g^{\gamma s·I})\hfill \\ \hfill & =e{(g,g)}^{\gamma s·I(\alpha (t_1+t_2)+\beta t_{1}m)}\hfill \end{array}$$

  (2)
  If the keyword input by the user is equal to the encrypted keyword, i.e., $m^{\prime }=m$ and $P{m}^{\prime }=Pm$, then the edge blockchain layer returns the link for the encrypted file $CM$; otherwise, it returns ⊥.
• $Enc(K,URL(K\left(F\right)),PK)\to CM$: The AS located in the data owner encrypts both the $URL\left(K\right(F\left)\right)$ and the symmetric key K of the encrypted file. Subsequently, it uploads these encrypted elements to the edge blockchain, where $PK=<D1,D2>$.

  (a)

  Select a random $z\in Z_q$.

  (b)

  Calculate $C_0=g^z$.

  (c)

  Calculate $C_K=K·e(D_2,C_0)$.

  (d)

  Calculate $C_F=URL\left(K\left(M\right)\right)·e(D_2,C_0)$, $CM=<C_0,C_K,C_F>$.

5.6.4. Decryption and Authentication of Integrity

$Decypt(GP,SK,CM)\to F$: The data requester $D{S}_R$ inputs the global parameters $GP$ and the private key $SK=<D_0,I,t>$ to decrypt the encrypted data. Given that $D_2=g^I·g^t$, substitute it into $C_k=K·e(D_2,C_0)$ and $CF=URL\left(K\left(M\right)\right)·e(D_2,C_0)$. The specific steps are as follows:

• Calculate: $C=e(g^z,g^t)·e(g^z,g^I)$
• Calculate:

  $$\begin{array}{cc}\hfill K& ={\displaystyle \frac{C_k}{C}}\hfill \\ \hfill & ={\displaystyle \frac{K·{e(D}_2,C_0)}{e\left(g^z,g^t\right)·e(g^z,g^I)}}\hfill \\ \hfill & ={\displaystyle \frac{K·e{\left(g,g\right)}^{Iz}e{\left(g,g\right)}^{tz}}{e\left(g^z,g^t\right)·e(g^z,g^I)}}\hfill \end{array}$$

  (3)
• Calculate:

  $$\begin{array}{cc}\hfill URL\left(K\left(F\right)\right)& ={\displaystyle \frac{C_F}{C}}\hfill \\ \hfill & ={\displaystyle \frac{URL\left(K\left(F\right)\right)·{e(D}_2,C_0)}{e\left(g^z,g^t\right)e(g^z,g^I)}}\hfill \\ \hfill & ={\displaystyle \frac{URL\left(K\left(F\right)\right)·e{\left(g,g\right)}^{Iz}e{\left(g,g\right)}^{tz}}{e\left(g^z,g^t\right)e(g^z,g^I)}}\hfill \\ \hfill & =URL\left(K\left(F\right)\right)\hfill \end{array}$$

  (4)

After decryption, $D{S}_R$ sends the $URL\left(K\right(F\left)\right)$ to IPFS to obtain the ciphertext of the file, and then uses the symmetric key K to decrypt the file to get the plaintext F.

6. Security Analysis

This section demonstrates the security of our scheme from the perspectives of IND-CKA, IND-CPA, and system security analysis.

6.1. Security Based on Adversarial Model

Theorem 1.

Assuming that the DBDH assumption holds, the proposed scheme can resist the chosen keyword attack, and the proposed scheme is secure for IND-CKA.

Proof. 

Assume that there is a probabilistic polynomial time adversary A and challenger C, playing a game under the IND-CKA security model. Assume that the advantage of A in recovering a keyword from the index set is non-negligible. We will prove by contradiction that if A can distinguish ciphertexts encrypted with different keywords under the chosen keyword attack with a non-negligible advantage, then C can be constructed to solve the DBDH problem with a non-negligible advantage.

Given a tuple $(G,g,g^a,g^b,g^c,T)(a,b,c\in Z_p$), in polynomial time, T may be $e{(g,g)}^{abc}$ or a random component of the group G. Next, we describe the game process between A and C in detail:

• Init: A selects the access strategy and challenges C.
• Setup: C first selects two cyclic multiplication groups $G0$ and $GT$ with the prime number q as order, then randomly selects $\alpha ,\beta ,\gamma \in Z_q$ and calculates $Y=e{(g,g)}^{\alpha }$, $p_1=g^{\alpha }$, $p_2=g^{\beta }$, $p_3=g^{\gamma }$ to obtain public global parameters $GP=<G,Y,g,e,p_1,p_2,p_3>$, and finally sends them to A.
• Query phase 1: A submits a query to the oracle, and C responds as follows:

  (a)

  Key generation phase: C first selects a random number $t\in Z_q$, then calculates the identity-based hash value: $I=H\left(DID\right),D_0=g^{\alpha ·\gamma ·It},D_1=g^t,D_2=g^I{g}^t$ to generate an identity-based public and private key pair $(SK,PK)$, C sends $<D_0,D_1,D_2>$ to A.

  (b)

  Trapdoor generation phase: A inputs any keyword, then C executes the algorithm $Trapdoor(GP,SK,PK,W^{\prime })$ to generate a trapdoor $T_W^{\prime }$, selects a random number $s\in Z_q$ to calculate $T_1={(g_b^{m^{\prime }}·g_a)}^{s·It},T_2=g_c^{s·It},T_3=D_0^s,T_W^{\prime }=<T_1,T_2,T_3>$, then sends $T_W^{\prime }$ to A.

• Challenge phase: A first submits two keywords of equal length $W_0$ and $W_1$, then C will randomly select a bit $b\in \{0,1\}$ and calculate the following ciphertext $C_{W_b}$, which consists of $m^{\prime }=H\left(W_b\right)$, $c_1=g_c^{t_1}$, $c=w_0·w_1^{m^{\prime }}=g_a^{t_1+t_2}·g_b^{t_1{m}^{\prime }}$, $c_2=g^{t_2}$ and $c^{\prime }=e(g,g)$ (random $t_1,t_2\in Z_q$), and then send $C_{W_b}$ to A.
• Query phase 2: A submits the keyword datasets to C for encrypted query, and the submitted datasets cannot be $W_0$ and $W_1$.
• Guess: If $b^{\prime }=b$, A will win the game, and the probability is as follows. In keyword encryption, for $c=w_0·w_1^{m^{\prime }}=g_a^{(t_1+t_2)}·g_b^{t_1{m}^{\prime }}=g^{a(t_1+t_2)+b{t}_1{m}^{\prime }}$, assuming that $a=\gamma$, $b=t_1$, $T=g^{ab}$, where $\gamma$ and $t_1$ are randomly selected from $Z_p$. It is computationally infeasible to distinguish $g^{ab}$ from Z in polynomial time. At the same time, for $P_m^{\prime }=e(c,T_2)=e{(g,g)}^{\gamma s·I(\alpha (t_1+t_2)+\beta t_1{m}^{\prime })}$, assuming that the advantage of A in winning the game is $ϵ$, if C outputs a valid ciphertext from $e{(g,g)}^{abc}$, the advantage of A in winning the game is ${\displaystyle \frac{1}{2}}+ϵ$. However, if c is a random number, not a valid ciphertext, the advantage of winning the game is ${\displaystyle \frac{1}{2}}$, A will not have an advantage in attacking the CKA game. The advantage of A in breaking the DBDH problem is calculated as follows:

  $$\begin{array}{cc}\hfill Ad{v}_A^{CKA}& ={\displaystyle \frac{1}{2}}·\mid Pr[b^{\prime }=1|bit=1]\mid +{\displaystyle \frac{1}{2}}·\mid Pr[b^{\prime }=0|bit=0]\mid -{\displaystyle \frac{1}{2}}\hfill \\ \hfill & ={\displaystyle \frac{1}{2}}·({\displaystyle \frac{1}{2}}+ϵ)+{\displaystyle \frac{1}{2}}·{\displaystyle \frac{1}{2}}-{\displaystyle \frac{1}{2}}={\displaystyle \frac{ϵ}{2}}\hfill \end{array}$$

  (5)

In short, since the DBDH assumption holds and $ϵ$ is negligible, C and A have almost no advantage in solving the DBDH problem. The advantage of A in the IND-CKA game is negligible, i.e., the encryption scheme is secure under the IND-CKA security model. □

Theorem 2.

Assuming that the DBDH assumption holds, the proposed scheme can resist the chosen plaintext attack and is secure for IND-CPA.

Proof. 

Given a tuple $(G,g,g^a,g^b,g^c,Z)(a,b,c\in Z_p$, where Z may be $e{(g,g)}^{abc}$ or a random element in group G), it is almost impossible to distinguish Z from $e{(g,g)}^{abc}$ in polynomial time.

• Init: A chooses a challenge for C.
• Setup: C selects two cyclic multiplication groups $G0$ and $GT$ with the prime number q as order and random $\alpha ,\beta ,\gamma \in Z_q$, then calculates $Y=e{(g,g)}^{\alpha }$, $p_1=g^{\alpha }$, $p_2=g^{\beta }$, $p_3=g^{\gamma }$ to obtain public global parameters $GP=<G,Y,g,e,p_1,p_2,p_3>$, finally sends them to A.
• Query phase 1: A requests a key, and C selects a random number $t\in Z_q$ and calculates the identity-based values: $I=H\left(DID\right),D_0=g^{\alpha ·\gamma ·It},D_1=g^t,D_2=g^I·g^t$ to generate an identity-based public–private key pair $(SK,PK)$, C sends $<D_0,D_1,D_2>$ to A.
• Challenge phase: Taking decryption K as an example, A sends two identical messages $M_0$, $M_1$ to challenger $C,$ then C selects a bit $\chi \in \{0,1\}$, calculates $C_0=g^z$, $C_K=M_{\chi }·e(D_2,C_0)$, and C sends $<C_0,C_K>$ to A.
• Query phase 2: It is similar to the phase 1, but it does not include $M_0$ and $M_1$.
• Guess: A guesses the value of $\chi$, where the advantage to solve DBDH is $Ad{v}_A^{CPA}={\displaystyle \frac{1}{2}}·({\displaystyle \frac{1}{2}}+ϵ)+{\displaystyle \frac{1}{2}}·{\displaystyle \frac{1}{2}}-{\displaystyle \frac{1}{2}}={\displaystyle \frac{ϵ}{2}}$.

In short, since the DBDH problem cannot be broken, the encryption scheme is secure under the IND-CPA security model. □

6.2. Security Analysis of the System

Collusion attack: Collusion attack refers to a malicious behavior in which multiple stakeholders in a blockchain network jointly control a large number of nodes and obtain illegal benefits or damage the system by manipulating the consensus process, tampering with data, etc. This behavior will undermine system trust, cause economic losses, and even cause the system to paralyze. In the PBFT algorithm, when a node proposes a new transaction block, other nodes will verify the validity of the block through multiple rounds of voting confirmation and finally reach a consensus. In order to ensure the correctness of the consensus, PBFT requires at least two-thirds of the nodes to agree on a proposal before it can be accepted. If the number of nodes in a domain exceeds the threshold P, a single domain may be paralyzed, causing the system to fail to work. Therefore, in order to prevent collusion attacks between institutions and fairness, the full node threshold P is set as the maximum tolerance value of the total number of nodes in the network. In short, even if all full nodes in an institution collude, they cannot affect the consensus of the entire network.

Auditability: Our scheme ensures the suitability of the data by adding a signature during data transmission and by storing the hashed data. The receiver verifies the integrity of the received data by hashing it and comparing it to the hash of the requested data stored on the blockchain. This method ensures that anyone can audit the integrity of the data by comparing it with the data stored on the blockchain.

Immutability: Our scheme stores key data on the blockchain. Only designated accounts have the right to update data attributes, and other accounts have no right to modify them. In addition, each data attribute update is timestamped to ensure data integrity and prevent malicious users from tampering with data.

Anonymity: Our scheme generates an anonymous identity for the device before it joins the blockchain. Devices in other domains cannot access the real device information, thus preventing the leakage of sensitive identity information.

DOS Attack: Our scheme incorporates an event monitoring function in smart contracts to monitor accounts engaged in malicious behaviors such as frequent access. Once the malicious behavior of an account exceeds a certain threshold, it will be blacklisted and permanently banned from participating in data sharing.

7. Experiment

In this section, we conduct a comparative analysis of the functionality and performance between the CDAS scheme and existing schemes. The cryptography part is implemented using the JPBC library, and the FISCO BCOS blockchain platform is used to build a blockchain environment for multiple institutions. In addition, the on-chain contract part is written in Solidity and converted to Java to interact with the off-chain. Experimental setup: We use three Linux virtual machines (Ubuntu 18.04 (LST) 8 GB memory) to simulate three organizational alliances and use Fisco Bcos v3.5.0 to implement the CADS alliance chain system. In addition, we use the Java SDK client in Fisco to deploy and test the scheme. The device (Intel(R) Core(TM) i5-8265U CPU @ 1.60 GHz, and 8 GB memory) is used to implement the interaction between the client and the blockchain. The cryptographic algorithm uses the JPBC 2.0.0 library and is implemented based on the TypeA encryption scheme.

7.1. Time Cost Analysis

When the data size of the policy attributes in this test is 60 bits, the time consumption of the functions is shown in

Table 5. The time cost of different functions.

Function	Time Consuming
Access	1476 ms
match	709 ms
RequestListen	285 ms
VerifyToken	833 ms
Check_Black	63 ms
Check_Data	108 ms

. Among them, the Access includes authentication, policy matching, blacklist query, and event monitoring functions. Further, the match, i.e., policy matching, consumes a more significant percentage of time because it is more complex than the other functions. At the same time, we record the time consumed in querying data in storage consistency. The average time consumed for access control and token authentication is 1476 ms and 833 ms, respectively.

7.2. Transactions Throughput Analysis

As shown in Figure 3, we tested the changes in TPS (transactions per second) under ACC (access control contract) and anonymous TVC (token verification contract) on a single-chain and a two-layer blockchain. Before reaching the optimal value, the throughput increases with the increase in the number of requests. When the number of requests increases to a certain extent, the growth trend of the throughput will gradually slow down and eventually stabilize. This phenomenon is mainly due to the performance bottleneck of the system. As the number of requests continues to rise, system resources such as CPU, memory, and network bandwidth gradually become saturated, and more requests can no longer be processed with the same efficiency, thus limiting the further improvement of throughput. In the single chain, the TVC and ACC reach the optimal value earlier because the single chain requires more nodes to participate in the consensus and consumes more resources. The change trend is stable at around 450 and 400, respectively. In the dual chain, the optimal values of the throughput of the two contracts with the same number of nodes is significantly improved, especially the TVC contract, which finally tends to around 2000. The TVC is executed by the domain master blockchain node, which has fewer nodes and a shorter consensus time. The ACC is executed by the ES node, which has fewer nodes than the single-layer chain, and the TPS tends to 750, which has an advantage over the single chain. In addition, the change in throughput is related to the complexity of the contract. Since the complexity of the ACC is higher than that of the TVC, its TPS is lower. Furthermore, since the AS and ES devices in our scheme are both high-performance devices that can handle a large number of requests and calculations, the TPS test results will be better in actual applications (

Table 6. The results of 1000 transactions executed.

Time Period	ACC Times	VT Times
100 ms–200 ms	4	0
200 ms–400 ms	83	45
400 ms–1000 ms	375	702
1000 ms–2000 ms	295	253
>2000 ms	243	0

).

7.3. Gas Cost Analysis

Gas is the pricing unit in the blockchain network, which measures the resource consumption required to execute smart contracts or other on-chain operations, including computing, storage, network, etc. As shown in

Table 7. The gas cost of different functions.

Function	Gas Cost
Access	126,870 gwei
AddPolicy	96,722 gwei
VerifyToken	13,717 gwei
match	66,192 gwei
StorageData	52,707 gwei
setBlackList	4954 gwei

, there is the gas cost of different functions. Among them, the Access in the ACC contract consumes the most gas, because it calls the functions of multiple other contracts and the size of gas is related to the complexity of the contract. In the blockchain, gas is only consumed when the transaction status is changed, while data query operations will not consume gas.

7.4. Cryptographic Algorithms Analysis

We consider encryption, trapdoor generation, and search as three main algorithms, and analyze their time complexity for our scheme and other related schemes [25,26,27]. The main considerations include the exponentiation operation E, the pairing operation P, and the hash operation H. The specific time consumption is shown in

Table 8. The main computation time consumption.

Operater	E	P	H
Time (ms)	8.06	6.99	0.021

E stands for power exponentiation, H stands for hash operation, and P stands for bilinear operation.

, and the time complexity of the key algorithms of the compared schemes is shown in

Table 9. The time complexity of main algorithms.

Scheme	Encrypt	Trapdoor	Search	Decrypt
1. Zhang et al. [27]	$(n+3)E+3P$	$5E+2H$	$6P$	$P+E$
2. Wu et al. [25]	$(n+2)E+P+nH$	$E+H+P$	$2P$	$(n+3)P$
3. Liu et al. [26]	$(4n+3)E+H$	$(2n+2)E+H$	$(2n+1)P+nE$	$(3n+2)P+nE$
4. Ours	$5E+H$	$4E+H$	$3P$	$2P+2E$

.

As shown in Table 9, the time consumption of the above three schemes increases linearly with the value of attribute n. In addition, the efficiency of access control is also related to the complexity of policy matching. Since the encryption algorithm of this scheme is not affected by n, it has an advantage. Considering that the difference in time cost is obvious when $n=10$, we compare the time consumption of each scheme when the number of attributes is 10. When the number of keywords is set to 1, the time consumption comparison is shown in Figure 4. In addition, since the time consumption of trapdoor generation is mainly related to power operation, the trapdoor time consumption of this scheme is relatively low. In the search phase, this scheme requires the edge server to perform three bilinear pairing operations. Although the computational cost is not as low as that of Scheme 2, it is more secure and better than other schemes. In the decryption phase, this scheme uses two bilinear pairing operations and two power operations. The time consumption of the decryption phase is significantly lower than that of Schemes 2 and 3. In summary, the change in the number of attributes in this scheme will not affect the time consumption of key steps in the overall encryption search. At the same time, this scheme implements access control that does not rely on a third party through smart contracts, and policy matching does not require complex cryptographic operations.

8. Conclusions

In this paper, we design a cross-domain data sharing scheme for federated systems based on multiple blockchains. Based on the decentralized nature of blockchain, we solve the problem of over-reliance on central entities. In addition, we integrate smart contracts to implement ABAC and anonymous identity registration. This approach simplifies device resource access by minimizing middleware confirmation, double-checking device access rights, and preventing redundant requests caused by illegal access attempts. Furthermore, we improve and apply the searchable encryption scheme to data sharing to protect data privacy, and compare it with other data sharing schemes combined with ABE in terms of time complexity and other aspects. Finally, we validate the effectiveness of our cross-domain sharing scheme by simulating multiple organizations and devices using the FISCO BCOS blockchain platform.

In the future, we will focus on practical applications in real-world scenarios. In addition, we will also consider optimizing the computational efficiency and communication overload of the proposed scheme.