Sage Journals: Discover world-class research

Abstract

With the in-depth integration of traditional industries and information technology in Internet of things, wireless sensor networks are used more frequently to transmit the data generated from various application scenarios. Structural health monitoring is a scene that requires recurrent data transmission in Internet of things, and the wireless sensor networks in Internet of things not only have storage and communication capabilities, but also have computing capabilities. Therefore, the demand for intelligent and decentralized data exchange between them has increased significantly which brings challenges with respect to low data reliability, chaotic data circulation, provenance tracking, and data accountability investigating, threatening the data security of structural health monitoring in Internet of things utilization. In this article, we propose a controllable data transmission mechanism based on the consortium blockchain to content the requirements of the Internet of things scenario. We identify a version-based, fine-grained, and privacy-protected data structure and propose the corresponding smart contracts for our mechanism to ensure the trusted data transmission. To prove the feasibility of our mechanism, a prototype system is implemented based on the Hyperledger Fabric, an open-source consortium blockchain framework. Our experimental results show in practice the usability and scalability of the approach in this article.

Keywords

Controllable data transmission Internet of things privacy data protection consortium blockchain data traceability

Introduction

With the advent of the wireless sensors Internet era, all of its advantages such as high reliability and low installation and maintenance costs are beneficial to structural health monitoring (SHM).¹ On account of the massive breakthrough in the AI (artificial intelligence) in recent years, such as deep learning,^2,3 convolutional neural network,^4,5 and recurrent neural learning,⁶ the technology of large-scale data processing and mining has been mastered. But the data mining process is the only one step in the whole life cycle management of data,⁷ which includes data generation, collection, storage, conversion, integration, mining, analysis, calculation, display, application and maintenance, meaning latency,⁸ and safety, which is important. Hence it is impractical for a unilateral organization to own all the technologies for the whole life cycle management of data, the whole process may involve multiple parties such as from wireless sensors in factories to relay stations for data collecting, then to servers with powerful computing and storage capabilities. Hence, the data will be transmitted by multiple organizations which may put forward higher data responsibility requirements for the relevant multilateral organizations in the process of using, copying, modifying, and mining these data. The willingness of data transmission could be reduced substantially owing to the accountability for subsequent issues such as data leakage, loss, and infringement, which lead to the ever-increasing data island issues. Therefore, privacy data in Internet of things (IoT) need to be protected and transmitted controllable.⁹ In summary, the main challenges of data transmission are multifaceted and could be elaborated as the following three points which will be discussed carefully in section “Problem and solution analysis.” First, the data reliability is low which means that enterprises cannot confirm the authenticity and consistency of the data shared with each other. Second, the data traceability is poor which means that enterprises cannot obtain a complete and accurate flow path of data. Third, the data rights are easy to lose¹⁰ which means the data providers often face continuous loss of data interests after data transmission.

To solve the problem mentioned above and to break the data barriers between multilateral organizations, we propose a blockchain-based and controllable data transmission mechanism, which is a framework with fine-grained, version-evolutional, and privacy-protected data modelization. By establishing smart contracts¹¹ and encrypted interactions with distributed file systems (DFS),¹² we establish connections between on-chain part and off-chain part, which could effectively reduce the data load pressure of the blockchain. Through implementing on the open-source platforms Hyperledger Fabric¹³ and Go-fastdfs, we prove the usability and scalability of the mechanism in this article. The key contributions of this article can be summarized as follows:

The article proposes a secure controllable data transmission scheme suitable for the IoT utilizing smart contract and cryptography, which involves decentralized data exchange between different organizations and different devices adopting the concept of channels to divide the IoT into several small networks making the scheme to have scalability;

The article proposes an on-chain data structure which is fine-grained with metadata, recorded data version evolution path and data propagation path utilizing cryptographic signatures to establish correspondence pointers between blocks and transactions and privacy protected by symmetric encryption combined with asymmetric encryption. The data structure ensures the traceability, privacy, and integrity of data;

The article demonstrates the feasibility of the proposed protocols and framework by implementing a proof-of-concept demonstrator on a consortium blockchain system and a DFS.

The rest of this article is organized as follows. The technical background is outlined and the relevant research trends are introduced in section “Background and related work.” The problems and solution analysis are discussed in detail in section “Problem and solution analysis.” In sections “Architecture” and “Implementation,” the architecture of the mechanism, on-chain data structure, workflow, and smart contracts are elaborated. The experimental results analysis and discussions are presented in section “Experimental results analysis and evaluation.” Finally, we make a conclusion for our contribution and put forward the idea of future work in section “Conclusion and future work.”

Background and related work

In this section, detailed technical background and the recent research trends are outlined.

Background on blockchain

Blockchain is a decentralized distributed storage database proposed by S Nakamoto¹⁴ in the whitepaper of Bitcoin released in 2009. In a nutshell, blockchain technology is not an unprecedented technical concept, but a product of an ingenious combination of multiple traditional technologies. And each one of these traditional technologies contributes to solving certain problems^15–17 encountered in such a decentralized distributed system.

The unique chain-based storage structure ensures the sequential storage of data, providing a basis for traceability and verification. The cryptographic hash functions¹⁸ enable each node which maintains the network to confirm the legitimacy and correctness of the transaction and connect the timing of the data with hash pointers that makes the tampering behavior of a malicious node to a single block in the entire chain which is meaningless. The various consensus protocols¹⁹ are the rules for each node in the distributed network to reach the consistency of the latest transcript of the ledger under the premise of mutual trustlessness. The smart contracts²⁰ connect the code on the chain with the real-world activities off the chain, allowing blockchain technology to be implemented in applications other than cryptocurrency, such as medical, IoT, government affairs, and energy. The point-to-point network²¹ is to ensure fast and accurate communication between nodes in a decentralized and distributed network.

The architecture of blockchain is particularly robust on account of the complementary advantages among a variety of mature technologies. Data on the chain are extremely difficult to be forged during recording or to be tampered with after recording, and all nodes can trace the trajectory of all data by themselves. The birth of blockchain is therefore of revolutionary significance which considered to be the fifth subversive innovation of the computing paradigm after mainframes, personal computers, the Internet, and mobile social networks by the McKinsey report. What is more significant to the blockchain application domain is the classification of categories, which composed of public blockchain, private blockchain, and consortium blockchain.

Most public blockchains are digital currency systems²² represented by Bitcoin and Ethereum,²³ and there are no restrictions on the identity and access control of nodes participating in network activities. Thus, the nodes only need to generate a private key and address locally to participate in the network operation. The advantage of this type of blockchain is exceedingly open, so the participating nodes are the largest, the activities are the most frequent, and the community is the most active.²⁴ On the other hand, the disadvantage is that the activities on the public blockchain cannot be controlled, and the account can only be anonymous but not encrypted which could cause security breaches²⁵ or privacy issues. (Hence, the transaction content is open to all users. If there is a way to find the corresponding relationship between the corresponding transaction and the role in the real world, the anonymization will lose its significance).

The private blockchain is a blockchain technology designed to serve a certain enterprise or organization. It is often used for log recording of related activities or data within the enterprise. The owner of the private blockchain has complete control but meanwhile brings the shortcoming which there is no interaction with other enterprises or organizations, lack of application scenarios, and low functionality, failing to meet the flexibility and scalability demands in a heterogeneous deterministic network.²⁶

Public blockchain and private chain resemble two poles of blockchain technology, and neither can content the conventional needs in the business environment. In order to achieve compromises in terms of availability, scalability, supervisability, privacy, and and so on, the consortium chain technology emerged. Consortium blockchain is a blockchain technology designed for inter-enterprise commercial activities which is also participated and maintained by multiple organizations or enterprises. It is mainly faced with a weak trust environment between enterprises rather than a trustless environment of a public chain. Hence, what is mainly focused by consortium chain significantly differs from the public chain. Its technical characteristics compared to public chain can be summarized as follows:

Adding certificate authority and identity management;

Adopting multi-centralized architecture design;

Fast transaction speed meanwhile low cost;

High data confidentiality;

Strong controllability and supervisability.

Consortium chain has a variety of advantages that can be used in business environments. The most representative platform is Hyperledger Fabric, founded by the Linux Foundation which has been widely used in many industries.

Related work on data transmission with blockchain

In view of the advantages of blockchain in decentralization, distributed structure, non-tampering, traceability, privacy protection, programmability, many scholars have applied it to data transmission scenarios in various industries including medical care, IoT,²⁷ cloud computing, distributed storage, and so on.

In respect of medical care, Xia et al.²⁸ used blockchain to monitor entities that access data for malicious use from a data custodian system. Fan et al.²⁹ improved the consensus mechanism which achieves consensus of electronic medical records without large energy consumption and network congestion. GG Dagher et al.³⁰ proposed a framework named Ancile which utilizes smart contracts in an Ethereum-based blockchain for heightened access control and obfuscation of medical data. Aileni and Suciu³¹ addressed two main concepts in IoMT (Internet of Medical Devices) applications, e-health and telemedicine, and analyzed the advantages of blockchain application in these two fields. Ray et al.³² proposed a novel privacy-preserving scheme to facilitate seamless and secure transmission of user data based on blockchain and swarm exchange techniques.

In terms of IoT, Nakasumi³³ proposed a blockchain-based solution to address the problems of supply chain management such as double marginalization and information asymmetry. Zhou et al.³⁴ established the BeeKeeper blockchain system, where the IoT servers can process a user’s data by performing homomorphic computations on the data without learning anything from them. Li et al.³⁵ presented a privacy-preserving incentive announcement network based on blockchain to solve the difficulty to forward reliable announcements without revealing users’ identities and the lack the motivation of users to forward announcements in smart vehicles. Lagutin et al.³⁶ proposed a general framework design, which uses interledger technology, federation adapter, and decentralized identifier to seamlessly connect different IoT platforms, and explored its application in four typical scenarios. Yang and Wang³⁷ realized the vertical transaction between smart home and power grid by using smart contract.

In other fields like cloud computing and distributed storage, Park and Park³⁸ adapted blockchain security to cloud computing and its secure solutions. Zhu et al.³⁹ proposed a controllable blockchain data management model that can be deployed in a cloud environment. Wang et al.⁴⁰ presented a framework that combines the decentralized storage system InterPlanetary File System (IPFS), the Ethereum blockchain, and attribute-based encryption technology to solve the problem of single point of failure in traditional cloud storage systems.

The above articles have carried out meaningful explorations on the realization of data sharing by blockchain technology in their respective fields from the perspectives of improving the consensus mechanism, data privacy protection, and storage space efficiency. However, the above articles are still lacking some aspects, which makes them different from this article, and could be summarized as follows:

The data transmission details with blockchain are not explicit enough. For example, how to define the transaction data structure related to a data transmission behavior so that it can be used to provide accountability, immutability, traceability, and auditability later;

There is no mention of the relationship among data which could flow between entities. For example, how to define the data ownership and changes in a process which after certain data are transferred from entity A to another entity B, then entity B transfers the data to entity C? Data will change (or evolve) in the process of transmission, and the evolution path needs to be consciously recorded;

Most of the articles metioned above use blockchain to share data stopped at the stage of sharing bahavior, which does not research the behavior before and after the sharing behavior causing research on behavior at other stages scarce and the narrative is vague. Because data transmission is the only one step in the full life cycle of data management, issues such as credible data storage before data sharing, traceability of data circulation after data sharing, and accountability for data rights violations all require further details.

In view of these points mentioned above, this article discusses the credible evidence, circulation traceability, and rights identification of blockchain technology in the data transmitting process and combines it with the technical characteristics of the consortium chain to propose an data transmission mechanism based on consortium chain design, and strived to realize the efficient, open, and credible flow of data between IoT devices.

Problem and solution analysis

Problem analysis

Low data reliability. The dependability of various network components is facing unprecedented challenges and threats.⁴¹ Meaning as a digital product, data are virtualized and cannot be confirmed by means of taking photos, unpacking and inspecting goods like the real products. To ensure the consistency of data before and after transmitting, such as preventing the phenomenon of denial by the data provider after the data are transmitted, is one of the challenges facing the implementation of data sharing at this stage.

Poor data traceability. Due to its digital nature, the cost of duplicating data is close to zero, which causes the phenomenon of data flooding once it is leaked. To ensure that data are not divulged, the party responsible for the data must be accurately held accountable, but the chaotic leakage of massive data transcripts makes it infeasible to hold accountable for data breaches. Hence, to make the accountability accurate, it is necessary to realize the traceability of the data flow between the sharing parties (refers to all hardware entities that pass through in the data transmitting), which means the direction of the data flow can be recorded clearly, and thus there is evidence to rely on for the subsequent investigation of data leakage.

Vulnerable data rights. Unlike the ordinary resources such as oil and natural gas, data have secondary exploitation or even multiple exploitation capabilities due to its digital characteristics. Therefore, data providers often face continuous loss of data rights after data transmission because they cannot provide the corresponding algorithms. All in all, the value of data cannot be fully determined before sharing, and it is necessary for the data provider and data user to manage data rights.

Solutions analysis

We use a series of technologies including consortium chain, cryptography, DFS, and so on to solve the problem of trusted and controllable data transmission in this dynamic IoT scenario.⁴² The core feature of consortium chain technology is the multi-centralized structure organization to ensure the authenticity of data and break the trust barriers, and solve the dilemma of high trust costs required for cooperation between enterprises and organization today, so that business can be carried out efficiently. The above characteristics are highly consistent with the concept of data transmission services in the IoT and the specific elaboration is as follows:

Multi-centralization: In the consortium chain system, there is no fully centralized database. Each participant maintains organizational nodes representing their own interests, and these organizational nodes store block information related to their own business participation. There is no high or low status among the participants in the data transmission of the IoT, and there is no single centralized node to control the overall situation. Even the government agency only has the authority to maintain and supervise, so that it can be held accountable in the future, and cannot affect the ongoing data transmission behavior. Each participant in the IoT scenario is not only a producer of data, but also a consumer of data, and they are all a small center in the entire data transmission network. For nodes with insufficient storage capacity, DFS can be used for data storage.

Autonomy: The consortium chain is operated and maintained by all the participants that make up the network. The withdrawal of the original participants and the addition of new participants require all organizations in the entire network to vote, which reflects a high degree of autonomy—all parties in the IoT scenario. The data transmission is matched on demand, emphasizing ecologicalization and self-scheduling.

Contractualization: For the business logic running between the participants of the consortium chain, they need to negotiate and jointly develop smart contracts. After the business data call the smart contract, it runs according to the rules without human intervention. The IoT data transmission needs to reduce the intervention of human factors and proceeds according to the pre-established rules, replacing the human factors of cooperation between enterprises with contract code, which can reduce the trust cost and improve the efficiency of cooperation between enterprises.

Data privacy: The consortium chain has a multi-channel mechanism to isolate organizations that do not have business interactions, which make the data between each other invisible, and only the data related to their own business can be seen. The data transmission of the IoT requires extremely high confidentiality, and the data cannot disclosure unrelated companies, but can only be opened to companies that have reached a shared transaction. Cryptography is used to protect data privacy off-chain.

Therefore, the application of consortium chain, cryptography, DFS, and so on in the data transmission scene of the IoT meets its various requirements.

Architecture

In this section, we propose a prototype system that takes full account of the demand of a controllable privacy data transmission mechanism in IoT scenario, including the components of the IoT and the data structure on chain.

Prototype system components overview

The IoT organization alliance can be composed of multiple IoT enterprises with privacy data transmission interactions. As shown in Figure 1, each organization has its own IoT equipments, and these equipments could have the demand to use privacy data from other equipments from the same organization or different organization. Depending on how they process the data, organizations can have the identity of both a data transmitter and a data receiver on the chain. The number of organizations participating in network maintenance needs to be voted by all pre-organizations on chain. The IoT device nodes within each organization are designed with multi-role division of labor, such as data processing, transaction endorsement, transaction sorting, block packaging, block broadcasting, and block verification. The colored dashed box indicates the channels used for data transmission which can be created freely by organizations dedicated to certain business services according to the needs among IoT devices of different organizations, so that can isolate the data between channels to ensure data privacy.

Figure 1.

System design.

The main chain and data chains. Designed based on the Hyperledger Fabric platform, the main chain is used to store the certification and organization information and channel information to build business channel. And the data chains store metadata information, description information, unique hash certificates, and inheritance version relationships between data, and so on; each of the data chains corresponds to a channel which is mainly responsible for isolating the data of the irrelevant organization, providing reliable hash evidence comparison for the data sharing business between the subsequent organizations on the chain, and ensuring the consistency of the data and the traceability of the evolution trajectory and circulation trajectory of the data version. Records on data chain can support relevant nodes to conduct data audits, rights prosecutions, and so on.

The DFS. Devices in IoT have diversified storage capability and blockchain also cannot process large-scale data. So DFS is used to share the pressure for data storage if the amount of private data exceeds the storage capacity of IoT devices. As long as the unique hash digest calculated by the file is consistent with the record on the data chain, the consistency of the data can be guaranteed. To ensure that the privacy data stored in DFS need to be encrypted, a detailed explanation of data encryption will be given later.

Third-party participant. The third-party participant such as the MSP (membership service provider) responsible for providing the identity certificates needed to participate in the activities of the consortium chain. Meanwhile, third party can also act as a supervisor participating in the maintenance and operation of the entire network, but does not have the authority to initiate data transmitting transactions. When data rights disputes occur between organizations, the records of the third party can also be used as a reference for determining responsibility.

Data structure on chain

We propose a version-based, fine-grained, and privacy-protected data structure which consists of five sections including KeyID, Subject data, Attachments, Data trajectory, and Privacy and authentication as shown in Figures 2 and 3. The KeyID part represents the unique identification code on the blockchain for each data transmission operation. The Subject data part contains the metadata of the data transmitted. The Attachments part is used to record the information of attachment files with the main data. The Data trajectory part is mainly designed to record the process of data flow. The Privacy and authentication part mainly records the data rights information. In general, this feature of the data structure on chain can be described as three points: fine-grained defined, version-based evolution, privacy and authentication.

Figure 2.

Data structure.

Figure 3.

Data propagation path.

Fine-grained defined. The subject data section and attachments section include fine-grained information about all data files in a data transmission process. The subject data section consists of the data type of the transferred data file, the URL address of the encrypted data file stored in DFS, the hash of the original data file, the data size and the attachments numbers (a subject file can has several attachents). Attachments section refers to some documents that prove the legitimacy of the subject data, including invoices, photos, PDF files, and so on. And, the attachments section includes the number and type of attachments, and the total hash of the attachments (total hash is calculated by all the hash of attachments file in a certain order). The fine-grained data structure can help to record the information on chain more accurately.

Version-based evolution. In the data trajectory section, the version information of the data is defined. It is defined as version 1.0 once the data are uploaded on chain, and modifications to attachments will cause minor version changes, such as version 1.0 to version 1.1. Modifications to the subject data will cause major version changes, such as version 1.0 to version 2.0. The version information includes the version number and operator information to prevent the overlap of versions caused by different subjects in a distributed system. If the data transmitter does not modify the data but only share the data receiving from the previous data transmitter, the version number will not change while the operation object will change. More significantly, this section contains the source and destination information of the data, which means where the data come from and whom the data will be transmitted. The data source information is specified by the KeyID that is unique on the chain for each data transmission transaction (will be elaborated in detail later). The data destination information includes the public key information of the data recipient. This version-based evolution structure is conducive to the trajectory of data moving on the chain. Figure 3 could be regarded as an explanation of the process described in this paragraph. Through the unique KeyID recorded in each transaction of the block, the flow and evolution process of data can be recorded.

Privacy protection and authentication. In this section, the data transmitter should claim the data rights statements first, which means whether the rights belong to itself or to the pre-owner of the data. In order to protect privacy at a higher level than the channel, we use a combination of symmetric encryption and asymmetric encryption. The original data are stored in IoT devices or DFS after symmetric encryption, and the key of symmetric encryption is then stored in the privacy section off the data structure by asymmetric encryption, which is the public key of the data recipient, which means that only the organization that holds the private key corresponding to the public key can decrypt the encrypted information. Authentication information is related to the identity information of the data transmitter, including its public key and the signature by the public key to the transaction information, so as to verify the transaction with other nodes or organizations. Signature of the data receiver should also be recorded in the part which implies that both the transmitter and the receiver agree with the data rights statement.

Each data are represented by a transaction $T_{i}$ which is composed of $KeyI D_{i}$ , $S_{i}$ , $A_{i}$ , $D_{i}$ , and $P_{i}$

T_{i} = {KeyI D_{i}, S_{i}, A_{i}, D_{i}, P_{i}}

(1)

$S_{i}$ represents Subject data section, $A_{i}$ represents Attachments section, $D_{i}$ represents Data trajectory section and $P_{i}$ represents Privacy and authentication section. $KeyI D_{i}$ is calculated from the Merkle root⁴³ in the above four sections

\begin{matrix} KeyI D_{i} = Hash [Merkleroot (S_{i}) + Merkleroot (A_{i}) \\ + Merkleroot (D_{i}) + Merkleroot (P_{i})] \end{matrix}

(2)

To sum up, this data structure takes into account the data reliability, the data traceability, and the data rights, which lays a strong foundation for subsequent data transmission.

Implementation

In this section, we elaborate the prototype workflow with detailed data transmission procedure and present the pseudocode of smart contracts we use in Figure 4. The interactions between the data transmitter and data recipient are executed by the smart contracts.

Figure 4.

Data transmission workflow.

Data transmission workflow

First, establish organizations for enterprises involved in privacy data transmission, apply for identity root certificates from third-party service providers, and create blockchain channels according to the businesses among related organizations using root certificates;

Second, the data transmitter and recipient request the sub-certificate from their own organization, respectively, and deploy the businesses channel on their local devices. Both sides can choose to serve as multiple functional nodes in the blockchain according to their own capabilities and conditions and participate in the maintenance of the consortium chain;

Third, all organizations establish their own public and private key pairs (multiple pairs can be held for easy replacement at any time) and record the public key on chain. The data recipient initiates a data transmission request and sends its identity to the data transmitter off-chain. After the data transmitter agrees to the request, it queries the chain based on the identity information of data recipient and obtains the public key of data recipient;

Afterward, the data transmitter hashes all relevant information (the subject data section, attachments section, data trajectory section mentioned above) of the transmitted data to obtain the KeyID of the data transmission transaction and signs the hash value with its own private key. Meanwhile, the data transmitter symmetrically encrypts the transmitted data file and stores it in itself or the DFS, and uses the public key of the data recipient to encrypt the symmetric key. Then record these information aggregates on the chain, initiate a blockchain transaction, and send the KeyID to the data recipient off-chain;

After receiving the KeyID, the data recipient searches for the transaction data related to the KeyID on the chain and obtains the data file URL (if the amount of data is small, the data recipient will receive the encrypted data directly), the encrypted symmetric key, the hash value of the original data, and other information stored in the transaction;

Next, the data recipient downloads the encrypted data file from the DFS (if it does not receive the data directly), decrypts the symmetric key with its own private key, and then decrypts the encrypted data file with the symmetric key to obtain the original data. After that, the data recipient calculates the hash value of the original data and compares it with the hash value stored on the chain. If the two are the same, the consistency is confirmed;

Eventually, if it involves future data accountability, the signature information stored in the transaction can be used for identity verification.

Smart contract

We present three smart contracts in pseudocode form to help summarize the execution of the entire data transmission process.

Data preprocessing contract. Assume the devices do not have enough store capability. The original file is encrypted with the Advanced Encryption Standard (AES) symmetric key and uploaded to the DFS in the first contract. The DFS returns the hash value and storage path of the file. Assign the returned result to transmitter’s data structure, which includes data type, file storage path, original file hash value, data size, file name, number of attachments, total hash value and other data description information, file version number, operation object, operation type, data source, data destination, and other data track information.

Contract 1: Data preprocess contract

Function DataPreprocess (originalFile, data)cipherFile = Encrypt(originalFile, secretKey)result = UploadDFS(cipherFile)data.fileHash = result.fileHashdata.url = result.urlreturn

Data transmitting contract. This contract assigns the symmetric key encrypted by the recipient’s public key to the data structure, and then hash the data structure, and the hash value obtained is used as the KeyID of the data structure to identify the entire structure. Use the signature of transmitter’s private key to KeyID as the signature field of data. Finally, the data structure is used to initiate a chain transaction in the form of json.

Contract 2: Data transmit contract

data.cipherKey = Encrypt(secretKey, data.recipientPubKey)data.KeyID = Hash(data.information)data.signature = sign(KeyID, transmitterPrivKey)InvokeChain(data)return

Data receiving contract. In this contract, recipient queries the data on the chain through KeyID. After getting the returned result, recipient downloads the ciphered file from the DFS according to the file storage path, then uses its private key to decrypt the symmetric key. And the decrypted symmetric key will be used to decrypt the ciphered files. After obtaining the original file, it verifies the integrity of the file by the comparison of the hash value first, and then verifies the authenticity of the data source through the signature.

Contract 3: DataReceive(KeyID)

data = QueryChain(KeyID)secretKey = Decrypt(data.cipherKey, recipientPrivKey)cipherFile = DownloadDFS(data.url)originalFile = Decrypt(cipherFile,secretKey)if Hash(originalFile) != data.fileHash:returnDATA INTEGRITY ERRORelse:if Verify(data.signature) == True:return SUCCESSelse:return SIGNATURE VERIFICATION ERROR

Experimental results analysis and evaluation

In order to verify the feasibility of the prototype design in this article, a variety of data transmission scenarios under the change of the number of channels, the number of organizations, and the number of nodes are simulated based on the open-source platform Hyperledger Fabric and Go-fastdfs. We use the virtual machine and the container (Dokcer) to simulate the experiment, and each node opens a container. We define each data transmission action as a transaction on the blockchain. The way to test the TPS (transactions per second) is to use a script we wrote in GO which multi-threaded concurrently calls our blockchain’s interface through HTTP protocols to get the time after all threads have finished running, and then divide the number of transactions processed by the time. The detailed set-up needs are shown in Table 1.

Table 1.

The choice of options.

Experiment set-up	Description
Server type	Cloud virtual machine
RAM	2.0 Ghz
Server hard disk	500G
Bandwidth	100M
Server system	Linux Ubuntu 16.04
Sorting mode	Kafka
Local database	Leveldb
DFS	Go-fastdfs
Transaction size	200Bytes

DFS: distributed file system.

By recording the TPS of data transmission transaction and the time-consumption of data evolution trajectory tracing, we discuss and evaluate the performance, usability, scalability, security, privacy, and traceability of the design prototype.

Experimental results

The experiment simulates the scenario design in 1, 2, and 3 data channels with the total number of organization in data channels 2, 3, 4, and the total number of nodes in every data channels is 4, 8, 12, 16, 20, 24, which is more suitable for real distributed IoT scenarios. The allocation strategy of nodes can be summarized as equal distribution (if the total number of nodes can be divided by the number of organizations). For instance, when the total number of nodes is 8 and the number of organizations is 2, each organization owns 4 nodes. If the total number of nodes is 8 and the number of organizations is 3, one organization owns 2 nodes and the others own 3 nodes. Figures 5 and 6 record the TPS of data transmission transaction and time-consumption of provenance tracking in the above hypothetical scenarios.

Figure 5.

Experimental results in channel 1.

Figure 6.

Experimental results in channels 2 and 3.

As shown in Figure 5(a), the abscissa represents the number of all nodes in the network, the ordinate represents the TPS of data transmission transaction in the network, and different types of lines represent the number of organizations. As shown in Figure 5(b), the abscissa represents the length of tracking path (the number of nodes which transmits the certain data) in one tetroactive transaction, the ordinate represents the time consumption of the tetroactive transaction, and different types of lines represent the number of organizations. It can be seen that with the increase of the total number of nodes in one channel of the consortium chain, the TPS gradually decrease under the condition that the total number of organizations remain unchanged. Meanwhile, the time-consumption of provenance tracking increases linearly with the expansion of tracking path length. This is because the more the total number of nodes in the channel, the more databases need to be updated each time, and the longer the time is spent. At the same time, it is worth noting that the difference caused by the increase of the total number of organization can be ignored when the total number of nodes in the whole network of consortium chain is unchanged.

As the number of channels increases to 2 and 3, the total number of nodes in blockchain network doubles and triples. Figure 6 shows that there is no obvious change in the TPS of data transmission transaction and time-consumption of provenance tracking.

Discussion

Usability. The data transmission prototype provided in this article has shown relatively high performance in a variety of organizations and multiple node setting scenarios. Among them, transmission transaction TPS and time-consumption of provenance tracking can be maintained at about 200, 700, and 3 ms, respectively, which is more excellent than the data transmission mechanism designed in single-digit TPS of Bitcoin and 10-digit TPS of Ethereum, enough to meet the data transmission requirements between small-scale IoT scenario including dozens of nodes or devices.

Scalability. The increase in the number of organizations will certainly reduce TPS, but with the increase in the number of organizational nodes in a channel, the decline of network performance will tend to be flat, which indicates that the prototype is highly scalable. In addition, there is no obvious difference between the performance of multiple channels and that of a single channel. If the number of organizations and nodes increase, more channels could be established to meet the demand.

Security. The data transmission mechanism proposed in this article is based on the consortium chain, which means the nodes participating in the chain business need to be examined before they can apply for identity certificates. Whether it is for the admission of new members or the development of new business contracts, it is necessary for the members of the entire network to negotiate and develop together. This avoids malicious nodes from participating in consensus and generating blocks. In addition, all nodes must sign the transmitted data and store it in the transaction to be responsible for their actions. In view of the immutability of the blockchain, this will also prevent malicious actions by nodes with legitimate identities. These properties all contribute to the security of the entire mechanism.

Privacy. In light of privacy, the channels isolate organizations that are not within the same business logic from the business level, preventing them from seeing each other’s behavior on the chain. The combination of asymmetric and symmetric encryption ensures privacy from the data level when organizations are in one channel. The public–private pair of multi-group backup which can be replaced at any time ensures the robustness of data encryption.

Traceability. We consider the problem of tracing the data propagation path and version evolution when the structure of data on blockchain is defined. Each transaction represents a version of data and connects with the pre-version data and next-version data (if existed) with endorsement by the uploader’s signature, which facilitates the complete traceability of the whole life cycle of data. When tracing data, user only need to know a transaction to quickly form data propagation records and evolution tracks, rather than traversing each block.

Data rights protecting. When data are transmitted between different organizations, each operation will be faithfully recorded. The statement of data rights will be declared in the Privacy and authentication part to record the provisions of the data transmitter to the data receiver. The data transmitter can declare in this section that “the data can only be transmitted to three households, and the income needs to be returned in proportion.” Due to the existence of signatures of both parties, this statement is undeniable so as to protect the rights and interests of data.

Conclusion and future work

In this article, we propose a controllable data transmission mechanism to solve the demand of reliable privacy data transmission between IoT devices of enterprises. By defining a fine-grained, version-based, privacy-protected data structure, the data files stored in different blocks can be linked, the data rights statements can be recorded in block and the evolution and propagation path of data can be clearly displayed which could contribute to provenance tracking and data accountability investigating. We present the architecture prototype of this mechanism and implement it based on Hyperledger Fabric, then simulate a variety of scenarios and conduct experiments to prove the usability and scalability of this mechanism.

However, the scenario considered in this article is more inclined to achieve controllable data transmission in technology, and there is no corresponding incentive or punishment rules for participating enterprises in the actual business environment. Therefore, in the future work, the token should be added to the data transmission mechanism in this article, which is beneficial to improve the enthusiasm of each organization to participate in business and cultivate positive behavior.

Footnotes

Acknowledgements

Thanks to WenQing Li for her technical support and Professor Zhang Xu for the general support she provided.

Handling Editor: Francesc Pozo

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This article is funded by the National Key Technologies R&D Program of China under Grant 2018YFB1402700

ORCID iD

ZiXiang Nie

References

Farrar

Worden

. An introduction to structural health monitoring. Philos T Roy Soc A 2007; 365(1851): 303–315.

LeCun

Bengio

Hinton

. Deep learning. Nature 2015; 521(7553): 436–444.

Schmidhuber

. Deep learning in neural networks: an overview. Neur Netw 2015; 61: 85–117.

Szegedy

Liu

Jia

, et al. Going deeper with convolutions. In Proceedings of the IEEE conference on computer vision and pattern recognition, Boston, MA, 7–12 June 2015, pp.1–9. New York: IEEE.

Krizhevsky

Sutskever

Hinton

. Imagenet classification with deep convolutional neural networks. Adv Neur Inf Proc Syst 2012; 25: 1097–1105.

Graves

Mohamed

Hinton

. Speech recognition with deep recurrent neural networks. In: 2013 IEEE international conference on acoustics, speech and signal processing, Vancouver, BC, Canada, 26–31 May 2013, pp.6645–6649. New York: IEEE.

Allcock

Bester

Bresnahan

, et al. Data management and transfer in high-performance computational grid environments. Paral Comput 2002; 28(5): 749–771.

Song

Zhou

, et al. Smart collaborative automation for receive buffer control in multipath industrial networks. IEEE Trans Indus Inf 2019; 16(2): 1385–1394.

Song

Zhu

Zhou

, et al. Smart collaborative tracking for ubiquitous power IoT in edge-cloud interplay domain. IEEE Int Things J 2019; 7(7): 6046–6055.

10.

Reichman

Samuelson

. Intellectual property rights in data. Vand L Rev 1997; 50: 49.

11.

Wang

Ouyang

Yuan

, et al. Blockchain-enabled smart contracts: architecture, applications, and future trends. IEEE T Syst Man Cyber Syst 2019; 49(11): 2266–2277.

12.

Levy

Silberschatz

. Distributed file systems: concepts and examples. ACM Comput Surv 1990; 22(4): 321–374.

13.

Androulaki

Barger

Bortnikov

, et al. Hyperledger Fabric: a distributed operating system for permissioned blockchains. In: Proceedings of the thirteenth EuroSys conference, Porto, 23–26 April, pp.1–15. New York: ACM.

14.

Nakamoto

. Bitcoin: a peer-to-peer electronic cash system. Decent Bus Rev 2008; 2008: 21260.

15.

Ren

Beard

Atkins

. A survey of consensus problems in multi-agent coordination. In: Proceedings of the 2005, American control conference, Portland, OR, 8–10 June 2005, pp.1859–1864. New York: IEEE.

16.

Jiang

. A survey of task allocation and load balancing in distributed systems. IEEE T Parall Distr 2015; 27(2): 585–599.

17.

Hasan

Anwar

Yurcik

, et al. A survey of peer-to-peer storage techniques for distributed file systems. In: International conference on information technology: coding and computing (ITCC’05)-Volume II, Las Vegas, NV, 4–6 April 2005, pp.205–213. New York: IEEE.

18.

Preneel

. Analysis and design of cryptographic hash functions. PhD Thesis, Katholieke Universiteit te Leuven, Leuven, 1993.

19.

Sankar

Sindhu

Sethumadhavan

. Survey of consensus protocols on blockchain applications. In: 2017 4th international conference on advanced computing and communication systems (ICACCS), Coimbatore, India, 6–7 January 2017, pp.1–5. New York: IEEE.

20.

Alharby

Van Moorsel

. Blockchain-based smart contracts: a systematic mapping study. arXiv preprint arXiv:1710063722017.

21.

Pourebrahimi

Bertels

Vassiliadis

. A survey of peer-to-peer networks. Citeseer, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.64.1218

22.

Tschorsch

Scheuermann

. Bitcoin and beyond: a technical survey on decentralized digital currencies. IEEE Commun Surv Tutor 2016; 18(3): 2084–2123.

23.

Wood

. Ethereum: a secure decentralised generalised transaction ledger. Ethereum Proj Yellow Paper 2014; 151(2014): 1–32.

24.

Tang

Shi

Dong

. Public blockchain evaluation using entropy and topsis. Exp Syst Appl 2019; 117: 204–210.

25.

Mehar

Shier

Giambattista

, et al. Understanding a revolutionary and flawed grand experiment in blockchain: the DAO attack. J Cases Inf Tech 2019; 21(1): 19–32.

26.

Song

You

, et al. Enabling heterogeneous deterministic networks with smart collaborative theory. IEEE Netw 2021; 35(3): 64–71.

27.

Atzori

Iera

Morabito

. The internet of things: a survey. Comp Netw 2010; 54(15): 2787–2805.

28.

Xia

Sifah

Asamoah

, et al. Medshare: trust-less medical data sharing among cloud service providers via blockchain. IEEE Access 2017; 5: 14757–14767.

29.

Fan

Wang

Ren

, et al. Medblock: efficient and secure medical data sharing via blockchain. J Med Syst 2018; 42(8): 1–11.

30.

Dagher

Mohler

Milojkovic

, et al. Ancile: privacy-preserving framework for access control and interoperability of electronic health records using blockchain technology. Sust Cities Soc 2018; 39: 283–297.

31.

Aileni

Suciu

. Iomt: a blockchain perspective. In: Khan

Quasim

Algarni

(eds) Decentralised internet of things. Cham: Springer, 2020, pp.199–215.

32.

Ray

Chowhan

Kumar

, et al. Biothr: electronic health record servicing scheme in iot-blockchain ecosystem. IEEE Int Things J 2021; 8: 10857–10872.

33.

Nakasumi

. Information sharing for supply chain management based on block chain technology. In: 2017 IEEE 19th conference on business informatics (CBI), volume 1, Thessaloniki, 24–27 July 2017, pp.140–149. New York: IEEE.

34.

Zhou

Wang

Sun

, et al. Beekeeper: a blockchain-based iot system with secure storage and homomorphic computation. IEEE Access 2018; 6: 43472–43488.

35.

Liu

Cheng

, et al. Creditcoin: a privacy-preserving blockchain-based incentive announcement network for communications of smart vehicles. IEEE T Intell Transp Syst 2018; 19(7): 2204–2220.

36.

Lagutin

Anton

Bellesini

, et al. The SOFIE approach to address the security and privacy of the IoT using interledger technologies. Secur Priv Int Things Chall Sol 2020; 27: 76.

37.

Yang

Wang

. Privacy-preserving transactive energy management for IOT-aided smart homes via blockchain. IEEE Int Things J 2021; 8: 11463–11475.

38.

Park

. Blockchain security in cloud computing: use cases, challenges, and solutions. Symmetry 2017; 9(8): 164.

39.

Zhu

Gai

, et al. Controllable and trustworthy blockchain-based cloud data management. Fut Gen Comp Syst 2019; 91: 527–535.

40.

Wang

Zhang

. A blockchain-based framework for data sharing with fine-grained access control in decentralized storage systems. IEEE Access 2018; 6: 38437–38450.

41.

Song

Zhang

, et al. Smart collaborative balancing for dependable network components in cyber-physical systems. IEEE T Indus Inf 2020; 17: 6916–6924.

42.

Song

Zhou

Wang

, et al. Smart collaborative distribution for privacy enhancement in moving target defense. Inf Sci 2019; 479: 593–606.

43.

Merkle

. A digital signature based on a conventional encryption function. In: Pomerance

(ed.) Conference on the theory and application of cryptographic techniques. Berlin: Springer, 1988, pp.369–378.

A controllable privacy data transmission mechanism for Internet of things system based on blockchain

Abstract

Keywords

Introduction

Background and related work

Background on blockchain

Related work on data transmission with blockchain

Problem and solution analysis

Problem analysis

Solutions analysis

Architecture

Prototype system components overview

Data structure on chain

Implementation

Data transmission workflow

Smart contract

Experimental results analysis and evaluation

Experimental results

Discussion

Conclusion and future work

Footnotes

Acknowledgements

Declaration of conflicting interests

Funding

ORCID iD

References