Enterprise Data Sharing with Privacy-Preserved Based on Hyperledger Fabric Blockchain in IIOT’s Application

Internet of Things (IoT) technology is now widely used in energy, healthcare, services, transportation, and other fields. With the increase in industrial equipment (e.g., smart mobile terminals, sensors, and other embedded devices) in the Internet of Things and the advent of Industry 4.0, there has been an explosion of data generated that is characterized by a high volume but small size. How to manage and protect sensitive private data in data sharing has become an urgent issue for enterprises. Traditional data sharing and storage relies on trusted third-party platforms or distributed cloud storage, but these approaches run the risk of single-node failure, and third parties and cloud storage providers can be vulnerable to attacks that can lead to data theft. To solve these problems, this paper proposes a Hyperledger Fabric blockchain-based secure data transfer scheme for enterprises in the Industrial Internet of Things (IIOT). We store raw data in the IIoT in the InterPlanetary File System (IPFS) network after encryption and store the Keyword-index table we designed in Hyperledger Fabric blockchain, and enterprises share the data by querying the Keyword-index table. We use Fabric’s channel mechanism combined with our designed Chaincode to achieve privacy protection and efficient data transmission while using the Elliptic Curve Digital Signature Algorithm (ECDSA) to ensure data integrity. Finally, we performed security analysis and experiments on the proposed scheme, and the results show that overall the data transfer performance in the IPFS network is generally better than the traditional network, In the case of transferring 5 MB file size data, the transmission speed and latency of IPFS are 19.23 mb/s and 0.26 s, respectively, and the IPFS network is almost 4 times faster than the TCP/IP network while taking only a quarter of the time, which is more advantageous when transferring small files, such as data in the IIOT. In addition, our scheme outperforms the blockchain systems mainly used today in terms of both throughput, latency, and system overhead. The average throughput of our solution can reach 110 tps (transactions are executed per second), and the minimum throughput in experimental tests can reach 101 tps.


Background
In recent years, with the rapid development of the Industrial Internet of Things (IIoT), the increase in productivity has also resulted in a significant challenge-data explosion. Enterprises in the industrial IoT use smart portable mobile terminals (e.g., drones, smartphones, electronic watches), sensors (e.g., infrared sensors, laser scanners, gyroscopes), and other large embedded devices (e.g., magnetic resonance imaging devices, traffic lights, (1) We designed a data security sharing and privacy protection framework to solve the blockchain load problem and achieve enterprise privacy protection of sensitive data while improving the scalability of the system. (2) We designed a Keyword-index table for data sharing between enterprises and designed a Chaincode to realize the automatic call of data. (3) Our scheme realizes mutual authentication of all parties and protection of data integrity.

Related Works
Few studies have focused on the use of the blockchain to share data between companies or organizations. We outlined the trends in related research, focusing on discussions that combine blockchain technology, as shown in Table 1. Leading to a slower rate of information entering the smart space Wang et al. [14] 2018 To use blockchain double-link structure combined with proxy re-encryption for data sharing Blockchain, Proxy re-encryption The two chains store original data and transaction data separately, combined with proxy re-encryption to achieve reliable data sharing There is no detailed experimental process to prove the actual effect of the program, and the safety analysis is not detailed enough Zhang et al. [15] 2018 To realize data sharing in the electronic medical system through alliance chain Teslya et al. [13] proposed a blockchain-based IIOT trust information sharing platform, and such a combination made it possible to use the mechanisms implemented in the blockchain to solve the problems identified in the platforms for IoT. Wang et al. [14] proposed a blockchain dual-chain structure, where one chain stores the original data and the other chain stores the transaction data, combined with proxy re-encryption for reliable data sharing. The scheme proposed by Zhang et al. [15] describes in detail the implementation of data sharing in eHealth systems through federated chains, where multiple hospitals form a federated chain and use bilinear mapping to ensure secure data sharing, with a very detailed evaluation of the efficiency and cost. Ra Lee et al. [16] proposed a healthcare data-sharing framework using blockchain registries and Fast Healthcare Interoperability Resources (FHIR) technology to improve operability by storing registries on the blockchain while storing the raw data in a database. Kumar et al. [17] proposed a method for health data sharing using Hyperledger Fabric by calling chain codes and listing the specific algorithmic steps. However, the above schemes are still not perfect in terms of identity authentication and data traceability, and the communication parties do not have complete trust, and there is still the risk of data leakage.
Our scheme focuses on proposing a secure data sharing and privacy protection scheme based on blockchain and smart contract technology that allows data to be shared between authorized enterprises. We ensure that the entire process from data submission to data transfer is fully recorded in the blockchain and that ECDSA is used for data integrity protection. We use data stored independently of each other to increase the scalability of the blockchain network, reduce latency and energy costs, and improve the transmission effectiveness of the network. The perfect authentication and access control mechanism can ensure that the sensitive data of enterprises will not be leaked out and effectively protect the privacy of enterprises.
The contents of the rest of the paper are as follows: Section 2 presents some related knowledge of our study. Section 3 describes our proposed architecture and the detailed workflow. In Section 4, we analyze the security of the scheme. In Section 5, we evaluate the performance of the scheme. In Section 6, we perform an experimental test of the proposed scheme. Finally, Section 7 concludes the paper. Elliptic Curve Cryptography (ECC) [18] is a public key encryption algorithm based on elliptic curve mathematics. The main advantage of ECC is that it uses a smaller key length and provides a comparable level of security compared to the Rivest-Shamir-Adleman (RSA) encryption algorithm. ECDSA is a combination of ECC and DSA (Digital Signature Algorithm). Compared with RSA, the public key length of ECDSA is shorter and the encrypted message will be smaller, so the computation and processing time will be shorter, and the memory and bandwidth requirements will be smaller. The following is the signature and verification process of ECDSA: Signing process: Suppose Alice wants to sign a message m, the elliptic curve parameter used is D = (p, a, b, G, n, h), Alice needs to choose a random number between [1, N−1], d A as Alice's private key, and generate a public key Q A = d A G. Alice will sign according to the following steps: First, Alice needs to generate a random number k between [1, N−1]; then calculate (x 1 , y 1 ) = kG, z = h(m), r = x 1 mod n, s = (z + d A r)k −1 mod n. Finally, Alice sends the ECDSA signature result (r,s) to Bob.
Verification process: Bob needs to verify after receiving the signature. The verification steps are as follows: First, verify whether (r,s) is between [1, N−1]; then, calculate the following parameters: z = h(m), u = 1z s −1 mod n, u = 2rs −1 mod n, (x 1 , y 1 ) = u 1 G + u 2 Q A . Finally, check whether the equation x 1 mod n = r is Equality: If they are equal, Bob confirms that the signature and message sent by Alice are correct.

Hyperledger Fabric
Hyperledger Fabric [19] is a platform for blockchain-based distributed ledger solutions that control transactions through chain codes, based on a modular architecture that provides a high degree of confidentiality, flexibility, and scalability. The transaction process is divided into the proposal phase, endorsement phase, sorting and packaging phase, and on-chain storage phase.
The Hyperledger Fabric architecture is mainly composed of the following parts: Client: the blockchain network used to connect members, through the SDK to call the proposal for transactions; Certificate Authorities (CA): Certificate and public and private key issuers, mainly responsible for the identity of the member's Management; Peers: can be divided into Leader Peer, Anchor Peer, Endorsing Peer, and Committing Peer, responsible for storing copies of the ledger and executing smart contracts (called Chaincode in Hyperledger Fabric) and approving transactions; Ordering Service (OS): responsible for collecting transaction of each channel and broadcasting to all Peers in the channel for storage on the chain. The specific workflow is shown in Figure 1:

Chaincode
The Chaincode in Hyperledger Fabric encapsulates the business logic used to create and modify business logic in the ledger, which can be written in different programming languages (e.g., Java, Go, and Node.js) [21]. Chaincode is created and executed by Peers to facilitate, authenticate, and enforce rules for reading, and the business logic of chain codes is defined by mutual agreement between members to read, execute, and update the current state of the ledger. When conditions are triggered, the chain code performs specific tasks, and the results of the transaction execution are submitted to the blockchain network and eventually attached to all Peers' copies of the ledger [22].

InterPlanetary File System (IPFS)
The Interplanetary File System (IPFS) is a peer-to-peer distributed file system used as a distributed data storage service where the contents of the resources received by IPFS correspond to unique hashes 31. Any node in the IPFS network is independent and does not depend on other nodes, and the nodes do not need to trust each other, so there is no single point of failure as in traditional HTTP transfers. Data access will select the nearest node, greatly speeding up data transfer and reducing the storage footprint [23]. IPFS peer-to-peer transmission can effectively save network bandwidth, distributed files can effectively avoid potential DDoS attacks, and it has features, e.g., high throughput, content addressing, data anti-tampering, and de-duplication.

BAN Logic
BAN Logic [24] was first proposed by Burrows et al. It is a trust-based modal logic that is usually used to prove the correctness of a protocol or scheme. During the reasoning of BAN Logic, the trust of the subjects participating in the protocol changes and evolves as the message exchange evolves. When applying BAN Logic for analysis, it is divided into the following four steps: (1) Describe the protocol messages that are not formally described in BAN Logic notation.
(2) Identify the initial assumptions from the protocol description and describe them in BAN Logic notation. (3) List the goals to be achieved by the protocol. (4) Using the messages, initial conditions, and inference rules in the communication, prove whether the protocol can achieve the goal.

Threat Model
The threat model is an important consideration for system security issues, and the following security issues are worth analyzing in our scenario.
(1) Mutual authentication of nodes [25]: Mutual authentication refers to two parties who authenticate each other simultaneously in an authentication protocol. To ensure data security, mutual authentication is the ideal solution among authentication schemes for transmitting sensitive data. The receiver/sender must be able to confirm the legitimate identity of the sender/receiver of the message during the transmission of the message, and failure to do so will pose a great threat to data security. (2) Data integrity [26]: Data integrity is the key to ensuring data accuracy and consistency, and to processing or retrieving data. Any accidental changes to data as a result of storage, retrieval, or processing operations can compromise data integrity. For messages transmitted in an unencrypted network environment that may be maliciously modified, data integrity may also be compromised. (3) Data traceability [27]: Data loss due to malicious data theft by attackers, posing a serious threat to corporate assets. (4) Non-repudiation [28]: Non-repudiation means that people cannot deny the act of sending a message and the content of the message due to the existence of some mechanism. The sender denies the message it sent, which can cause damage to the trust relationship between nodes. (5) Resist known attack [29]: Cyber-attacks may cause data corruption or system paralysis, posing challenges to the stability and security of the system. Common attacks on blockchain networks are man-in-the-middle attacks, replay attacks, etc. For enterprises, cyber-attacks can disrupt critical infrastructure and lead to data leakage or corruption.

System Architecture
In this article, we elaborate on the Hyperledger blockchain-based framework for enterprise data sharing and privacy protection, as shown in Figure 2. The framework is divided into three layers.
(1) Hyperledger Network Layer: This includes Peers, Ordering Service Node, Channels, and Certificate Authority (CA). The CA is responsible for issuing public and private keys and digital certificates. Administrators and Peers must be authenticated by the CA to become part of the blockchain network. The Channel is a private blockchain built based on data isolation and confidentiality. The data in the channel (e.g., Ledger information and member information) is known only to the members in the channel, and the data cannot be shared between different channels, and the channel mechanism ensures data sharing between different enterprises while protecting privacy. The Ordering Service Node only sorts and packs the transactions received in the channel and does not verify the legitimacy of the transactions, and then broadcasts the packaged transactions to all Peers in the channel. Peers are a network entity that maintains the ledger and runs the Chaincode to do read and write operations on the ledger. (2) Client Layer: Each enterprise in the industrial IoT has an administrator who is responsible for interacting with the Hyperledger Blockchain Network. The administrator is connected to the blockchain network through the Client, which uses the SDK (Software Development Kit) to interact with the blockchain network and can access the ledger through Peers using the Chaincode, and the administrator needs to register through CA to participate in transactions in the system. (3) Storage Layer: Enterprises that join the same channel will also join the channel's IPFS network, which is a distributed file system for storing and sharing data, and generating a hash address for storing data, which is a key component. The administrator stores the data encrypted using AES in IPFS while constructing a Keyword-index table of the hash addresses returned by IPFS to upload to the blockchain, which greatly increases the scalability of the system. Moreover, each data transaction carries a timestamp and is permanently stored in the blockchain.
The Hyperledger Fabric blockchain can be configured with multiple Channels, and multiple enterprises can join a single Channel or join different Channels for data sharing. Enterprise administrators create their own CA in the blockchain network and then apply for a public-private key and a digital certificate using the X.509 standard from the CA to provide signatures for transactions and to endorse the results of transactions. The

Hyperledger Fabric Detailed Transaction Information Flow
Data sharing among industrial IoT companies is realized through Channel, and different companies' businesses may have crossover, so all parties can join the same Channel for data sharing. For example, Enterprise Administrator A (A) and Enterprise Administrator B (B) can join the same Channel for data sharing, which can be divided into four phases: registration phase, data storage phase, data query phase, and data transfer phase, and the workflow is shown in Figure 3.
Step 1. A and B need to register with the Fabric CA in Hyperledger Fabric Blockchain through the Client, and then the Fabric CA issues the public and private keys and digital certificates to the client of A and B, and the registration phase is completed.
Step 2. B uses the AES encryption algorithm to symmetrically encrypt and sign the sensitive and private data, and the encrypted data is saved to IPFS. Step 3. IPFS returns the hash address of the encrypted data to the B Client.
Step 4. B Client receives the hash address and generates a Keyword-index table for the data keywords, and executes the Chaincode to add the Keyword-index table to the blockchain, and the data storage phase is completed.
Step 5. A sends a data access request containing keywords to the blockchain through the client. Step 6. If the request initiated by A is legitimate and the queried data exists in the blockchain index directory, the blockchain network will return to A the required Keyword-index table containing the data hash address stored in IPFS, and the data query phase is completed. Step 7. A initiates a data request to B, which contains A's ID.
Step 8. B receives a request from A, requests A's public key from the blockchain network, and verifies A's request message, and then uses A's public key to encrypt the AES key to form an encrypted key message and sends the message to A.
Step 9. After receiving the message, A uses its private key to decrypt it to obtain the AES key, obtains the encrypted data through the hash address provided by the Keyword-index table in IPFS, and then uses the AES key to decrypt the encrypted data to obtain the original data. The transfer phase is completed.

Registration Phase (Phase 1)
In this phase, enterprises joining the blockchain network for the first time need the administrator (X) to register with the CA via the client, and the registration phase proceeds as follows.
Step 1. X hashes the registration information to be submitted to obtain h(M SUBMIT ) and sends it to the CA. Step 2. CA generates ECDSA private key d X based on the X and calculates Q X = d X × G.
If the identity of the registered role is verified as legitimate, the CA sends (d X , Q X ) and Cert X to the X Client, where Cert X contains a unique ID X . Step 3. X stores (d X , Q X ) and Cert X .

Data Storage Phase (Phase 2)
In this phase, B will store the original data in IPFS after AES encryption through the client, and at the same time, construct the hash address of the encrypted data returned from IPFS to generate a Keyword-index table (as shown in Figure 4) for uploading to Hyperledger Fabric Blockchain (HFB). The workflow is shown in Algorithm 1 and can be divided into four steps.
The Keyword-index table structure is as follows: (1) "Holder": Name of the enterprise holding the data. "Signature": Signature of the enterprise administrator to ensure the integrity of the data. "ID": The unique identifier of the enterprise administrator, which is included in the certificate. (2) "Hash_Address": The hash address of the data, the only basis for content addressing in an IPFS network. "Summary_Data": a brief description of the data content. "keyword": the search basis for the data requester to query this index table in the blockchain by keyword. "size": the size of the data. "type": the type of the data.  Step 1: Step 2: hash address; Upon receiving; check whether Step 4: Add to ledger; Upon receiving; check whether T NOW − T 2 ≤ τ; call function Veri f y(z B2 , r B2 , s B2 ), return result; if T NOW − T 2 ≤ τ then if result = "valid" then call chaincode "Subfile", add (M 2 , Submit B ) to ledger; end end Step 1. B selects a random number k B1 , selects the data DT B to be stored, and generates the message: The function Sign(M 1 , d B , k B1 ) is called to generate the signature (r B1 , s B1 ) for M 1 (as shown in Algorithm 2) and then uses the AES encryption algorithm to symmetrically encrypt M 1 to get C B1 = E SK B (M 1 ). C B1 and (r B1 , s B1 ) are stored in IPFS.
Step 2. IPFS first checks the validity of the timestamp to prevent replay attacks, then stores the message in the IPFS network and returns the hash address to B.
Step 3. B generates a Keyword-index table for data keywords, and then selects a random number k B2 to generate a message: The function Sign(M 2 , d B , k B2 ) is called to generate the signature (r B2 , s B2 ) for M 2 and then send M 2 , (r B1 , s B1 ) to HFB.
Step 4. HFB checks the validity of the timestamp T NOW − T 2 ≤ τ and then calls the function Veri f y(z B2 , r B2 , s B2 ) (as shown in Algorithm 2) to verify the legitimacy of the signature. If x B2 = r B2 mod n, the signature is legal. Then, the Chaincode "Subfile" (as shown in Figure 5) is executed to be added (M 2 , Submit B ) to the blockchain ledger, Submit B = h(r B2 , s B2 ). The data storage phase is completed.

Data Query Phase (Phase 3)
Enterprises that need to query data, for example, A, need to submit a query request to HFB, and if the submitted request is legitimate, HFB will return the Keyword-index table to A. The workflow is shown in Algorithm 3 and can be divided into two steps. Step 2. HFB checks the timestamp T NOW − T A−HFB ≤ τ and calls the function Veri f y(z A1 , r A1 , s A1 ) to verify the validity of the signature. If x A1 = r A1 mod n, the signature is legal. Then, the Chaincode "Querfile" (as shown in Figure 6) is executed to be added (M A−HFB , Query A ) to the blockchain, Query A = h(r A1 , s A1 ). Moreover, then, the blockchain returns the Keyword-index table to A. The data query phase is completed.

Mutual Authentication
In this article, we use BAN Logic to demonstrate the mutual authentication of the two parties in the data transmission process, mainly to ensure that the data is not tampered with during the transfer phase. Table 2 shows syntax and semantics are associated with BAN Logic.

Symbol Description
P|≡ X P trusts X or P is qualified to trust X P X P received a message containing X P|∼ X P has sent a message containing X P|⇒ X P has jurisdiction over X #(X) X is the latest The shared key K is used for communication by P and Q. K → P P has X as a public key {X} K The message X is encrypted by K < X > Y This indicates that X combined with Y In the data transfer phase, the scheme mainly authenticates the legitimacy of the identity of the communicating parties, and the main objectives of the scheme are: In the data transfer phase, BAN Logic is applied to generate the idealized form as follows: The proposed scheme is analyzed and the following assumptions made: According to the assumptions and rules of BAN Logic, the main proofs of the data transfer phase are as follows: (1) The administrator of Enterprise B (B) authenticates the administrator of Enterprise A (A).
Through M2 and the seeing rule, we derive: Through A2 and the freshness rule, we derive Through Formula (9), A8, and the message meaning rule, we derive: Through Formulas (10) and (11), and the nonce verification rule, we derive: Through Formula (12) and the belief rule, we derive (G2), (G6), and (G10): Through Formula (13), A3, and the jurisdiction rule, we derive (G1): Through Formula (14), A5, and the jurisdiction rule, we derive (G5): Through Formula (15), A7, and the jurisdiction rule, we derive (G9): Through Formulas (6), (8), (16), and (17), it can be proven that, in the proposed scheme, A and B authenticate each other. Moreover, it can also be proven that the proposed scheme can authenticate the private key of A and B.
In the proposed scheme, B authenticates A by verifying: If it passes the verification, B authenticates the legality of A. A authenticates the B by verifying: x B3 = r B3 mod n (20) If it passes the verification, A authenticates the legality of B. The data transfer phase of the proposed scheme, thus, guarantees mutual authentication between A and B.

Data Integrity
In our scheme, the parties' transaction data will be permanently stored in the blockchain network while we use ECDSA and AES to sign and encrypt the transactions to ensure data integrity. For example, in the data storage phase, B will sign and add timestamps to the Keyword-index table, and then upload it to the blockchain network, which will verify the timestamp T NOW − T 2 ≤ τ and signature (r B2 , s B2 ) upon receipt. If the data is tampered with, then x B2 = r B2 mod n, M 2 does not match (r B2 , s B2 ), and the attacker's attack failed. During the data transfer phase, both communicating parties also verify the signature upon receipt of the message to ensure the integrity of the data. The data uploaded to the blockchain is stored in the blocks in a chained data structure, and each block is linked to the previous block through a hash function. If an attacker wants to tamper with the data, he needs to modify the hash value of the whole chain, which is unrealistic in a decentralized network system.

Traceability
Every transaction data stored in the blockchain is signed and stored forever, and the data is transparent and can be publicly verified. For example, the message is uploaded to the blockchain with the signed hash Submit B of B in the data storage phase. In the data query phase, the signature hash Query A of A is uploaded to the blockchain M Query . All members can trace the transaction process and determine whether the data in the blockchain is legitimate by verifying Submit B ? = h(r B2 , s B2 ) and Query A ? = h(r A1 , s A1 ).

Non-Repudiation
In the proposed scheme, ECDSA's private key signature is used to achieve nonrepudiation. The messages sent by all members of the system use their private keys to sign the messages. The receiver will verify the signature after receiving the message. If the verification is successful, the sender cannot deny the content of the message sent. Table 3 shows the non-repudiation of each role in the proposed scheme.

Resist Known Attacks
In this phase, we analyzed possible attacks against the system, including man-in-themiddle attacks and replay attacks.

Man-in-the-Middle Attack
The attacker tries to intercept and tamper with the message content. In our scheme, both communicating parties do not have to send their public keys to each other, and both parties can query each other's public keys in the blockchain network, which can effectively prevent the attacker from intercepting the message and replacing the public key. For example, A uses B's public key to encrypt the message C A−B = E Puk B (M Request ). B uses A's public key to encrypt the message C B−A = E Puk A (M Reply ). The attacker does not know the private keys of the communicating parties, so he cannot decrypt the message.

Replay Attacks
The messages of the two communicating parties may be intercepted by the attacker, who pretends to be a legitimate sender and sends the same message to the recipient. In our scheme, a timestamp mechanism is added between two parties of arbitrary communication to prevent such attacks. For example, during the data transfer phase, B sends a timestamped message M B−A to A, who checks that the timestamped message T NOW − T B−A ≤ τ is valid. Even if the attacker tampers with the timestamp data, because B has added a times- ) to the signature (r B3 , s B3 ), A checks that the timestamp does not match the signature and the replay attack fails. Table 4 shows the communication cost analysis of the proposed scheme. In the Gigabit Ethernet environment, the maximum transmission speed is 1 Gbps, and in the 10 Gigabit Ethernet environment, the maximum transmission speed is 10 Gbps. We assume that the ECDSA signature and key are 160 bits, the asymmetric encryption message is 1024 bits, the hash function operation requires 160 bits, and the length of other messages (such as ID and timestamp, etc.) is 80 bits. Taking the data transmission phase with the highest communication cost as an example, A needs to send two signatures, one hash, one asymmetric encrypted message, and one other message to B. The total size is 2 × 160 bits + 160 bits + 1024 bits + 80 bits = 1584 bits. B needs to send two signatures, one hash, one asymmetric encrypted message, and one other message to A. The total size is 2 × 160 bits + 160 bits + 1024 bits + 80 bits = 1584 bits. The total communication cost for the data transfer phase is 1584 bits + 1584 bits = 3168 bits, which takes 3.168 µs in a Gigabit Ethernet communication environment and 0.3168 µs in a 10 Gigabit Ethernet environment. These communication costs are very low, so the proposed scheme has good communication performance.

Computation Cost
In Table 5, we analyze the computational cost of each phase of the scheme, and we use asymmetric encryption and decryption, hashing operations, and addition, subtraction, multiplication, and division operations as the basis for the computational cost analysis. Taking the data transfer phase (phase 4) with the highest computational cost as an example, A requires three encryption/decryption operations, two comparison operations, five modular operations, two hash operations, eight multiplication operations, and one signature operation. B requires two encryption/decryption operations, two comparison operations, five modular operations, two hash operations, eight multiplication operations, and one signature operation. Thus, in our scheme, the calculation cost is acceptable.

Blockchain Architecture Comparison
There are currently at least four types of blockchain networks: public blockchains, private blockchains, consortium blockchains, and hybrid blockchains [30]. Private blockchains are too centralized and not suitable for data sharing between enterprises but only for resource management within a specific individual or company. We summarize the comparison between two blockchain platforms, Hyperledger Fabric, a typical representative of consortium blockchains, and Ethereum, a typical representative of public blockchains, as shown in Table 6. Table 5. Analysis of the communication cost.  From the above table, we can see that although Ethereum has advantages in fault tolerance and the transaction success rate, Hyperledger Fabric outperforms Ethereum in terms of the average transaction latency, throughput, privacy, and scalability, and the modularity and channel design of Hyperledger Fabric is more suitable for data sharing among enterprises [31]. Table 7 shows the comparison of the previous scheme with our proposed scheme. It can be seen from the table that this scheme overcomes the shortcomings of the previous scheme. We compare with previous studies, which, as mentioned before, have some flaws, we improve on the flaws based on the previous work. Teslya et al. [13] proposed a blockchainbased IIOT trust information sharing platform. Tis paper describes a possible way of integrating IoT and blockchain technology to solve these problems. To this end, an architecture combining the Smart-M3 information sharing platform and the blockchain platform was developed. However, it only proposes an architecture without detailed deployment and experiments. Furthermore, this paper does not discuss the security of the architecture and lacks a theoretical basis. This paper has detailed instructions on system security and experimental testing. Wang et al. [14] proposed a new data-sharing scheme based on blockchain technology, which combines the blockchain with a double-chain structure and proxy re-encryption to achieve safe and reliable data sharing. This scheme only discusses the security and complexity of the system and does not have actual experimental tests. In addition, this scheme cannot detect the source of data leakage, and the segmentation of data blocks lacks theoretical support. We experimentally test the proposed scheme, and we employ signature technology to ensure data traceability. Zhang et al. [15] proposed a blockchain-based security and privacy-preserving PHI sharing (BSPP) scheme for improving diagnosis in e-health systems. However, the scheme uploads all PHI data to the blockchain network, which undoubtedly increases the overhead of the blockchain client, and the scheme does not provide discussion on the authentication between the nodes of the Consortium chain. Our solution uses off-chain storage of data to reduce the overhead of the blockchain network, and we use ban logic proof to prove the identity security among the nodes. Ra Lee et al. [16] proposed a standards-based sharing framework SHAREChain that combines two properties to deal with reliability and interoperability issues and Kumar et al. [17] proposed a healthcare application based on a blockchain network with a Hyperledger fabric structure, but these two schemes do not discuss the security and efficiency of the system. We illustrate the safety of the proposed scheme, and the experimental results show the good efficiency of our scheme.

Function Comparison
We propose a complete system framework focusing on the security issues of enterprise data transmission among blockchain networks. Therefore, we focus on the security issues of the system in the analysis phase. Compared to previous studies, our solution has advantages in data privacy, data protection, and data traceability, which are lacking in previous solutions, while we adopt off-chain storage of data to increase the scalability of the blockchain network and use digital signature technology to ensure the authenticity of data. Finally, the experimental results show that our scheme has good efficiency and practical prospects.

Deployment and Testing
In this section, we experimentally evaluate the proposed scheme. The HyperLedger Fabric uses Docker container technology to run the Chaincode containing the system application logic. The Fabric framework includes a certificate authority (CA), order nodes, and peer nodes. Each peer node maintains a full copy of the blockchain data, and in our scenario, the Enterprise Administrator is the peer node. Each peer node uses CouchDB to maintain the state of its ledger. All nodes are run in their own Docker containers. We deployed 6 peer nodes, 1 order node and 2 CA on a server with Intel Core i7-8700 @3.2GHz CPU and 8 GB RAM. The operating system of the physical machine is Ubuntu 18.04.2 LTS. The version of Fabric we used is v1.4.

Performance of File Transmission in Traditional and IPFS Network
In this experiment, we compared the file upload performance of different file sizes in traditional TCP/IP networks and IPFS networks. Because the number of IoT devices is huge in industrial IoT networks and each device can only generate a small amount of data, we chose files of sizes 1, 5, 10, 50, and 100 MB, respectively. As can be seen from Figure 7  From the experimental results, almost all the transfer rates in the IPFS network are faster than in the TCP/IP network, and the IPFS networks are almost 4 times larger than TCP/IP networks when transferring data of 5 MB file size. Moreover, IPFS networks take less time than TCP/IP networks, which is more evident when transferring small files (File Size ≤ 10 MB), IPFS networks take one-half the time of TCP/IP networks when transferring 1 MB files, and one-quarter the time of TCP/IP networks when transferring 5 MB files. The data transfer performance in IPFS networks is generally better than that in traditional networks.

Throughput and Latency of Smart Contract Calling
We designed two smart contracts for the blockchain network and used throughput and transaction latency as the main performance metrics in our benchmarking. Throughput is the rate at which transactions are committed to the ledger, measured in terms of how many transactions are executed per second (tps). Latency is the time it takes from the time the application sends a transaction proposal to the time the transaction is committed to the ledger. As can be seen from Figure 8, when the block size and send rate is fixed, the TPS remains essentially constant as the number of transactions increases. "Querfile" fluctuates around 110 tps, with a minimum of 101.3 tps and a maximum of 115.6 tps; and "Subfile" fluctuates around 50 tps, with a minimum of 44. 3 tps and a maximum of 53.2 tps. In addition, as shown in Figure 9, the latency increases with the increase in the number of transactions. TPS remains essentially constant as the number of transactions increases. "Querfile" fluc tuates around 110 tps, with a minimum of 101.3 tps and a maximum of 115.6 tps; and "Subfile" fluctuates around 50 tps, with a minimum of 44. 3 tps and a maximum of 53. tps. In addition, as shown in Figure 9, the latency increases with the increase in the num ber of transactions.

Performance Comparison of Different Systems
To demonstrate the good performance of our proposed scheme, we compare it with other blockchain systems mainly used today: Bitcoin, Ethereum, Litecoin, BitcoinCash, and Primecoin in terms of the system transaction average latency and average throughput [32]. The sending rate, block size, and some transactions are set to 200 tps, 2 MB, and 400. Figure 10 gives the comparison results. From the comparison, it is clear that our scheme has better performance than existing blockchain systems in terms of the average transaction latency and average throughput. In terms of throughput, the block size limits the throughput of Bitcoin to only seven transactions per second. In total, 70, 60, and 56 transactions per second are achieved for Primecoin, Litecoin, and Bitcoin Cash, respectively, while Ethereum processes about 30 transactions per second. The average throughput of our solution can reach 110 tps, and the minimum throughput in experimental tests can reach 101 tps. In terms of system overhead, since the blockchain platform used in this system is Hyperledger Fabric, it does not need to consume a lot of computational resources for mining; therefore, the overhead of our solution is extremely low.

Conclusions
To solve the data sharing and privacy protection problems brought by the rapid growth of data in industrial IoT, we proposed an enterprise privacy protection and data sharing scheme based on the Hyperledger Fabric blockchain. We focused on the security and privacy of data transmitted by all parties in industrial systems. We utilized the Hyperldeger Fabric channel mechanism to enable enterprises to share data while keeping sensitive data private, isolating data between different channels, and all transaction data will carry time stamps and be permanently stored in the blockchain ledger, and be open, transparent, and traceable. Moreover, we achieved a high degree of automation in data recall through the designed Chaincode. The under-chain storage approach can effectively increase the scalability of the system. In addition, our scheme achieves mutual authentication of all parties in the system and data integrity protection. Finally, the analysis results show that our scheme has good traceability, non-repudiation, and resistance against known cyber attacks, and good performances.
In the future, a potential research direction is how to optimize the consensus algorithm of Hyperldeger Fabric, in which the backing nodes are responsible for endorsing the legitimacy of all transaction contents and carry a large amount of sensitive transaction data. How to protect the backing nodes from attacks and enhance the processing power of

Institutional Review Board Statement:
This study is based entirely on theoretical basic research. It does not involve humans.

Informed Consent Statement:
This study is based entirely on theoretical basic research. It does not involve humans.

Data Availability Statement:
The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest:
The authors declare no conflict of interest.

Cert X
Certificate of X issued by CA ID X X's identity (r X , s X ) Elliptic curve signature value of X T X Timestamp message of X C X Ciphertext sent by X DT X Data sent by X SK X The AES key of party X E SK X (M) Use X's AES key to encrypt M D SK X (M) Use X's AES key to decrypt M Puk X The public key of party X Prk X The private key of party X E Puk X (M) Use X's public key to encrypt M E Prk X (M) Use X's private key to decrypt M h(.) The one-way hash function τ Valid timestamp interval M SUBMIT The submitted registration information Verify whether A is equal to B