blockchain technology: is it a good candidate for...

12
Research Article Blockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical Data? Nabil Rifi, 1,2 Nazim Agoulmine , 1 Nada Chendeb Taher , 2 and Elie Rachkidi 1 1 COSMO, IBISC Laboratory, University of Evry, Paris Saclay University, France 2 Lebanese University, Faculty of Engineering and Azm Center for Researches, Tripoli, Lebanon Correspondence should be addressed to Nazim Agoulmine; [email protected] Received 15 August 2017; Revised 19 December 2017; Accepted 25 June 2018; Published 5 December 2018 Academic Editor: Fernando De la Prieta Copyright © 2018 Nabil Rifi et al. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. In the past few years, the number of wireless devices connected to the Internet has increased to a number that could reach billions in the next few years. While cloud computing is being seen as the solution to process this data, security challenges could not be addressed solely with this technology. Security problems will continue to increase with such a model, especially for private and sensitive data such as personal data and medical data collected with more and more smarter connected devices constituting the so called Internet of ings. As a consequence, there is an urgent need for a fully decentralized peer-to-peer and secure technology solution to overcome these problems. e blockchain technology is a promising just-in-time solution that brings the required properties to the field. However, there are still challenges to address before using it in the context of IoT. is paper discusses these challenges and proposes a secure IoT architecture for medical data based on blockchain technology. e solution introduces a protocol for data access, smart contracts and a publisher-subscriber mechanism for notification. A simple analytical model is also presented to highlight the performance of the system. An implementation of the solution as a proof of concept is also presented. 1. Introduction IoT is taking over the world; it is estimated that the number of devices connected to the Internet forming the Internet of ings will reach 50 billion by 2020 [1]. One critical application is the eHealth smart homes. In fact, this technol- ogy allows monitoring elderly or individuals with diseases and automatically sending the data to a remote server for processing by doctors. is data is recorded in the so-called EMR (Electronic Medical Record). Secure access to this EMR is problematic considering privacy issues, transparency, etc. is is why in order to develop secure and reliable solutions for eHealth smart homes, it requires unprecedented coordination and collab- oration between all pieces of the system. All devices must work together and be integrated with all other devices, and all devices must communicate and interact seamlessly with remote systems and infrastructures in a secure way. Such a solution is possible, however it can be expensive and time consuming. us, there is a need for new ideas and new technologies that will drive IoT security towards a more decentralized model. Having this huge amount of data, being centralized and sometimes monitored by one single provider, may create many problems. e cloud as a computing/storing technol- ogy cannot only by itself protect the security and privacy of its users. Using a decentralized approach for IoT network security is eventually an interesting way to solve many of the challenges IoT technology is facing today. Adopting a peer- to-peer model to handle billions of transactions between the billions of interconnected devices will decrease dramatically the costs of installation and maintenance of data centers and servers. It will also allow the distribution of storage and processing power on different devices and components of the network increasing the reliability of the system; e.g., the failure of one node will not cause the entire network to halt or collapse. However, in order to establish well-defined peer-to-peer communication protocols, a whole other set of challenges will need to be addressed, mainly security and privacy. Some level Hindawi Wireless Communications and Mobile Computing Volume 2018, Article ID 9763937, 11 pages https://doi.org/10.1155/2018/9763937

Upload: others

Post on 19-Aug-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Research ArticleBlockchain Technology Is It a Good Candidate forSecuring IoT Sensitive Medical Data

Nabil Rifi12 Nazim Agoulmine 1 Nada Chendeb Taher 2 and Elie Rachkidi 1

1COSMO IBISC Laboratory University of Evry Paris Saclay University France2Lebanese University Faculty of Engineering and Azm Center for Researches Tripoli Lebanon

Correspondence should be addressed to Nazim Agoulmine nazimagoulmineufrstuniv-evryfr

Received 15 August 2017 Revised 19 December 2017 Accepted 25 June 2018 Published 5 December 2018

Academic Editor Fernando De la Prieta

Copyright copy 2018 Nabil Rifi et alThis is an open access article distributed under theCreative Commons Attribution License whichpermits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

In the past few years the number of wireless devices connected to the Internet has increased to a number that could reach billionsin the next few years While cloud computing is being seen as the solution to process this data security challenges could not beaddressed solely with this technology Security problems will continue to increase with such a model especially for private andsensitive data such as personal data and medical data collected with more and more smarter connected devices constituting the socalled Internet of Things As a consequence there is an urgent need for a fully decentralized peer-to-peer and secure technologysolution to overcome these problems The blockchain technology is a promising just-in-time solution that brings the requiredproperties to the field However there are still challenges to address before using it in the context of IoTThis paper discusses thesechallenges and proposes a secure IoT architecture for medical data based on blockchain technology The solution introduces aprotocol for data access smart contracts and a publisher-subscriber mechanism for notification A simple analytical model is alsopresented to highlight the performance of the system An implementation of the solution as a proof of concept is also presented

1 Introduction

IoT is taking over the world it is estimated that the numberof devices connected to the Internet forming the Internetof Things will reach 50 billion by 2020 [1] One criticalapplication is the eHealth smart homes In fact this technol-ogy allows monitoring elderly or individuals with diseasesand automatically sending the data to a remote server forprocessing by doctors This data is recorded in the so-calledEMR (Electronic Medical Record)

Secure access to this EMR is problematic consideringprivacy issues transparency etc This is why in order todevelop secure and reliable solutions for eHealth smarthomes it requires unprecedented coordination and collab-oration between all pieces of the system All devices mustwork together and be integrated with all other devices andall devices must communicate and interact seamlessly withremote systems and infrastructures in a secure way Such asolution is possible however it can be expensive and timeconsuming Thus there is a need for new ideas and new

technologies that will drive IoT security towards a moredecentralized model

Having this huge amount of data being centralized andsometimes monitored by one single provider may createmany problems The cloud as a computingstoring technol-ogy cannot only by itself protect the security and privacy ofits users Using a decentralized approach for IoT networksecurity is eventually an interesting way to solve many of thechallenges IoT technology is facing today Adopting a peer-to-peer model to handle billions of transactions between thebillions of interconnected devices will decrease dramaticallythe costs of installation and maintenance of data centersand servers It will also allow the distribution of storage andprocessing power on different devices and components ofthe network increasing the reliability of the system eg thefailure of one node will not cause the entire network to haltor collapse

However in order to establish well-defined peer-to-peercommunication protocols a whole other set of challenges willneed to be addressed mainly security and privacy Some level

HindawiWireless Communications and Mobile ComputingVolume 2018 Article ID 9763937 11 pageshttpsdoiorg10115520189763937

2 Wireless Communications and Mobile Computing

of peers validation and consensus must be reached in order toprevent spoofing and theft an important characteristic thatany peer-to-peer distributed solution must have especiallylarge scale IoT networks A successful approach to decentral-ized control of IoT must not only be a peer-to-peer approachbut also a trust environment in which no participant needsto be trusted and no single point of trust failure existsBlockchain technology offers these features and proved itsefficiency in financial applications such as Bitcoin [2 3] and itcan be of great value and importance in this domain In thispaper we discuss first important background to understandblockchain technology value as well as related works Thenwe present the specific problem we want to address in thecontext of IoT and finally propose a solution architecture andmodelThe proposed solution is based on smart contracts [4]and Publisher-Subscriber mechanism In the following wepresent a mathematical model to evaluate the performanceof the system and its implementation Finally we end up witha conclusion and some future works

2 Related Works

21 Background

211 Blockchain In 2008 Satoshi Nakamoto introduced Bit-coin [5] a fully digital and decentralized cryptocurrencyIn order to solve the double spending problem in Bitcoinblockchain technology was introduced It is a peer-to-peerdecentralized distributed ledger that is replicated on all nodesparticipating in the system It is a complete transparenttechnology that can show all the transactions that have beenmade since its creation without tampering or fraud [6]Blockchain is a group of blocks that are connected each blockto the one before The first block is called the rdquoGenesisrdquo blockand it is hard coded into the softwareThink of the blockchainas a log whose records are batched into timestamped blockseach block being identified by its cryptographic hash Eachblock references the hash of the block that came before itThisestablishes a link between the blocks thus creating a chain ofblocks or blockchain Any node with access to this orderedback-linked list of blocks can read it and figure out what is theworld state of the data that is being exchanged on the network

Tounderstand howblockchainworks wewill first explainhow a blockchain network works This is a set of nodes thatoperate and interact on the same network using the replicatedblockchain copy each node holds One node might be usedas an entry point for multiple users or devices but let firstassume that each node transacts on the network by itselfonly First of all the interaction between users nodes and theblockchain is done via a pair of private and public keys

The transactions are signed using the private keys andthen addressed by other nodes using the correspondingpublic keys [7] The use of asymmetric cryptography isvery important in terms of providing integrity nonrepudi-ation and authentication to the blockchain network Aftera transaction is signed it is broadcasted by the node to allother nodes it is connected to The nodes or peers needto ensure that the transaction is valid thus they need totrigger a validation process called ldquominingrdquo A transaction

in the blockchain can be defined as any transfer of data thathas a value (Bitcoin IoT data etc) After a transaction isvalidated via the mining process it is then added to theblockchain as a new block of transaction and data Sincethe blockchain is transparent these transactions are availablefor all nodes connected to the network These blocks areorganized in a linear sequence that grows overtime whereeach block contains a timestamp and the hash of the previousblockThis organization of the blocks constitutes the so calledblockchain

When presenting blockchain technology there are twomain platforms to mention Bitcoin blockchain whichis the famous cryptocurrency blockchain and Ethereumblockchain [8] Ethereum is another public blockchain thatallows users to implement smart contracts create privateblockchain and test transactions In our proof of conceptimplementation we have used the Ethereum blockchain

212 Proof ofWork It is used in the blockchain in such a waythat each node participates to solve difficult mathematicalpuzzles that their solution validates blocks This puzzle isusually a function of the previous blocks hash in order tomaintain the chronological order and solving the doublespending problem Once this puzzle is solved there is aldquowinnerrdquo that publishes the solution Once the solution ispublished it is easy for other nodes to verify the solutionHowever solving the puzzle is expensive when it comes tocomputational power Once a majority of the peers acceptthe solution all the nodes in the network begin workingon the next block and a repeating process takes placeProof of work is one approach to reach consensus It is veryefficient in terms of securing the transactions and makingthe blockchain immutable because it requires a great amountof resources from computational resources to electrical andCPUpowersHowever this approachhas itsweaknesses sinceit is inefficient for typical devices that are not very powerfulThemotivation behind proof of work is that the nodes whichinvest significant resources into the network are less likely toattack or cheat

213 Proof of Stake Proof of stake is another approach thataims to solve the computational power problem In orderto validate a certain block or transaction the amount ofcryptocurrency is what matters 51 of the digital currencyowners need to agree on the current state The reason behindproof of stake approach is quite simpleThe higher is the stakein the system the more expensive it is for nodes to maintaina secure network Proof of stake is less secure than proof ofwork however it provides a more efficient approach to thelack of computational power issue

214 Smart Contracts It is possible to include code to beexecuted in the blockchain allowing general purpose compu-tation Similar to a contract between any two individuals thesmart contract is a piece of code that can have conditions to betrigerred and actions to execute if conditions are verified Theimportance of smart contracts comes with their capabilitiesto manage the interactions between nodes and participantsof the system based on the data Smart contracts like any

Wireless Communications and Mobile Computing 3

other node have addresses in the blockchain Triggering asmart contract is done by addressing a transaction to it Thesecurity of these contracts is however very important in theblockchain [9]

215 Mining Mining is one of the most important processesin blockchain technology Mining is the act of validatingnew blocks so that they could be added to the blockchainMining is done by providing ldquoproof of workrdquo to validate ablock ie each block contains a mathematical puzzle thatneeds to be solved by the miner in order to provide proof ofworkThis process can be very expensive regarding computa-tional power Miners are individuals or organizations havingdedicated considerable computational power for mining andmaintaining the blockchain

22 Related Works in the Integration of IoT Blockchain andeHealth After an exhaustive investigation of this field wefound out that blockchain is a great candidate for futuredecentralized IoT architectures and models For exampleauthors in [1] have defined a complete IoT architecture com-posed of three layers where blockchain is used as the storagelayerThe authors also defined a data management and a datasharing protocol along with a study on different mechanismsand their impacts on the system ie direct blockchain accessserver client access and publishersubscriber access Basedon this study we found that the publishersubscriber mech-anism is very important and the most flexible mechanismTherefore we decided to adopt it in our solution Blockchaintechnology is also considered in several ehealthcare solutionAs example authors of paper [10] have highlighted thegeneral role and future impact of blockchain technologyin healthcare In the paper [11] a smart contracts basedsolution has been defined by the authors tomanage the accessto electronic medical records Contribution in [11] is alsoimportant since it has defined the basic use of smart contractsin managing relationships between different parties of ablockchain Another study that focused on the use of smartcontracts in the context of IoT [12] and presents importantaspects and different points of view regarding the benefit ofusing smart contracts A use case of Internet of Things inthe context of eHealth is to have medical sensors composinga Wireless Body Area Network (WBAN) and generatingdata This approach is discussed in [13] Authors have useda cryptographic approach applied to the blockchain and anintermediate device to manage data flow and connectionto the blockchain Authors of papers [14 15] have alsodescribed a cryptographic approach where blockchain isimplemented as a solution to protect personal data Authorsin [16] has discussed the design issues of integrated IoT andblockchain The discussion is very helpful to understand thedifferent possible implementation options (fully centralizedpseudocentralized distributed and fully distributed) Paper[17] discusses the data privacy and integrity issues in thearea of eHealth and more particularly clinical trials Authorshave proposed in this contribution a solution that integratesIoT and blockchain to achieve their objective This workis highly related to our research but focuses more on therelation between parties in the context of clinical trials The

paper [18] is not fullyin the area of eHealth but it presents acomprehensive solution to secure data in the context of smarthomes Authors of the paper have proposed a solution basedon the integration of IoT and blockchain to prevent securityattacks against external attacks bymonitoring the IoT devicestransactions Our research aims to take benefits fromall thesestate of art contributions to derive a well-defined solution touse blockchain technology for IoT data access protection Inthe next section we will highlight the exact challenges to facewhen applying blockchain to IoT

We would like also to mention that this paper is anextended version of our previous work presented in [19]

23 Challenges in Using Blockchain Technology with IoT Aspreviously mentioned blockchain is a peer-to-peer decen-tralized technology that provides transparent and powerfulcertification mechanisms while removing the need to trustexternal third parties While this is a very important advan-tage it comes also with some important challenges Firstof all with the intrinsic architecture of the blockchain theledger is replicated on all nodes connected to the blockchainTherefore the storage of large amount of data is inefficientif it is in the blockchain itself This is indeed a big problemfor IoT devices such as typical sensors that do have limitedcomputing and storage resources In addition since there isno third parties involved in the system every block addedto the blockchain needs to be validated by each of its nodesThis is called the rdquolsquoMiningrdquorsquo process as previousely explainedand it requires high computational power demand [20] torunencryption algorithms As the IoT ecosystem is verydiverse and could consist of heterogeneous devices with verydifferent computing capabilities all these devices will notbe able to execute the same encryption algorithms at thedesired speed and this should be taken into account in theproposed architectural solution Another characteristic ofIoT that renders the problem even more complicated is thescalability problem Indeed when the number of IoT nodesincreases the number of generated data will also increase andtherefore the the number of transactions to the blockchainwill also increase The mining and validation process ofthe blockchain will then take more time to complete andthis should be mitigated as much as possible to acheive thescalability property of IoT systems In this paper we aimto address specifically this mining problem and the timetaken by the system to complete the transactions We havetherefore focused our research on the factors and parametersthat might have the higher impact on the complexity of themining process such as the block size and the block time Inthe next section we will discuss the proposed architecture ofthe distributed IoT system followed by the proposed solutionmechanisms

3 Proposed Architecture

The main idea of our approach to solve the problem ofthe high computational power needed in order to com-municate with the blockchain is to introduce a central-izeddecentralized combined architecture ie to introduceintermediate servers between IoT devices and the blockchain

4 Wireless Communications and Mobile Computing

A very good candidate for such an intermediate systemis a cloud edge server easily accessible by clients andwith high computational power The other proposition isto use of a publish-subscribe notification mechanism Inparticular we have taken into account the results obtainedfrom the authors of paper [1] who have shown that thepublish-subscribe mechanism is very efficient in terms offiltering data and introducing intermediates to address thehigh demand of electrical and computational powers fromblockchainmechanisms In addition we propose to use in oursolution smart contracts to maintain rules authenticationand communication between the different nodes and partiesof our system Finally since the transaction of messageswith large amount of data highly negatively impact theperformance of the blockchain we propose to use an off-chain database to store the data in our case we have usedIPFS [21] as peer to peer storage systemThe Figure 1 presentsa high level diagram of the proposed architecture identifyingthe different actors the blockchain and the IoT devices

In the next sections we will first present the consideredscenario then the details of the proposed architecture in termsof components and their interactions

4 Proposed Solution

41 Defining the Scenario To design our solution we havefirst specified a potential real life scenario to help identifyingthe required components and functionalities This scenario isrelated to the eHealth smart home and the remotemonitoringof patients We considered a home equipped with numerousconnected sensors (ie connected things) that collect envi-ronmental data from the home (eg temperature humidityetc) as well as medical sensors that collect health data frominhabitant (eg heart beats ECG etc)

The problem we aimed to address is the following howcan the monitored persons can ensure that the data that iscollected from their private environment and their own bodyand sent outside their home is only accessed by authorizedpersons (eg authorized doctors) and that it is not altered forany malicious reason by a third party

The direction that has been followed to solve this prob-lem is actually to protect the location where the collecteddata is stored To acheive this objective we will highlighthow the components of our blockchain IoT architecture(blockchain smart contracts intermediate servers and off-chain database) could be efficiently glued together for thispurpose The main actors of this scenario are the publishersof data and the subscribers to these data while the end-providers and consumers are the IoT devices and the end-users (data generators and data consumers) Figure 2 presentsour solution to be deployed in the smart home that is derivedfrom the more general architecture presented in Figure 1

The main idea of the solution is highlighted in Figure 2that is to overcome the limitation of connected objects in asmart home not able to directly connect to the blockchain dueto their limited processing capacity and energy powerThis isachieved using intermediary edge system that connects thesmart home to the blockchain and called the gateway Thisgateway is expected to bemore powerful than normal sensors

and will play the role of the publisher to the blockchainEventually it will publish the data received from the setof connected sensors in the smart home to the blockchainThe owners of this data are the monitored persons (egelderly) who live in their homes and have access to this dataThese persons can specify a set of authorized individuals ororganisation that are authorized to access this data

42 Defining the Smart Contracts In order to specify theformal relation between data owners consumers and clientssmart contracts are the corner stone of our blockchain IoTsystem

We have defined 3 types of contracts The proposed smartcontracts are presented in Figure 3

421 The Publisher Contract The first contract is the pub-lisher contract that is deployed by the publisher One canthink about contracts as functions that take input checkit and sendback results When an individual subscribes tothe system and connects his smart home gateway to theblockchain he must first specify his gateway or publishercontract Once accepted he receives an unique ID mappedto his blockchain address (Ethereum [22] address in thecase of Ethereum blockchain) He must also specify the listof IoT devices to connect to the blockchain This can bedone by names to ease access and comprehension of thegenerated data In addition he must specify a type of sharingmechanism to manage the publishersubscriber relationshipand finally he mustspecify the list of addresses that havepermission to access the data (usually these are the addressesof subscribers who are authorized to access the data)

422 The Subscriber Contract The second contract is thesubscriber contract It must contain the address of the sub-scriber in the blockchain and the list of publishers to whichit subscribes It must also specify the specific list of sensors tosubscribe to The sensors can be chosen by type by name orusing a wildcard to select all the available sensors connectedto a particular publisher This is the critical componentof the publisher-subscriber algorithm since based on theinformation stored in that contract the generated data canbe filtered before sending it to a subscriber

423 The Client Contract The third contract is the clientcontract It serves as a mapping contract between normalnodes or clients connected to the blockchain and theirrespective subscriber contracts It contains the client name sothat it would be simpler for clients to communicate betweeneach other using a frontend application This name is mappedto the corresponding address in the blockchain

43The Protocol Description Before describing our protocolwe first define some notations that will be later used in thepaper

(i) 119875119896 publisher number k(ii) 119889119896119894 device i connected to publisher k(iii) 119878119895 subscriber number j(iv) 119862119895 client number j

Wireless Communications and Mobile Computing 5

IoT Device

IoT Device

IoT Device Publisher Node

IoT Blockchain

Client Node

IPFS Database

Subscriber Node

Client Node

Client Node

Client Node

Client Node

Figure 1 Proposed architecture presenting IoT devices connected to the Publisher node itself connected to the blockchain On the otherside clients are either connected to subscriber nodes or directly to the blockchain

Smart home

Blockchain

Home Ownver

Authorized person

Gateway (Publisher)

Figure 2 An architecture for the smart home blockchain IoTthat identifies the gateway to the blockchain the owners and theauthorized persons to access the private data

(v) 119877119890119886119889119871119900119888119886119897119863119886119905119886() function to retrieve data from thelocal buffer

(vi) 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863() function to retrieve the ID ofthe sending IoT device

(vii) 119878119905119900119903119890119863119886119905119886() function to store data in the off-chaindatabase

(viii) 119866119890119899119875119900119894119899119905119890119903() function to generate pointer to locationin the database

(ix) 119867 the Hash pointing to the location in the database(x) 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875) function to return the list of sub-

scribers that subscribed to publisher P(xi) 119864119905ℎ reference to the blockchain client(xii) 119862119895 set of j clients having the same subscriber(xiii) 119903119890119888(119878) function that allows the client to retrieve the

message sent by a subscriber S(xiv) 119862119900119899119899119890119888119905(119863119861119875) function to connect to database 119863119861119875

1 function Publisher ⊳2 119894119899119894119905119894119886119897119894119911119890119875119906119887119897119894119904ℎ1198901199033 while (119890V119890119899119905119891119903119900119898119886119899119868119900119879119889119890V119894119888119890 = 119879119903119906119890) do4 119863119886 larr997888 119877119890119886119889119871119900119888119886119897119863119886119905119886(119889119896119894 )5 119886 larr997888 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863(119863119886)6 if (119886 = True) then7 119888 larr997888 119878119905119900119903119890119863119886119905119886119861119862(119863119886)8 119867119875 larr997888 119866119890119899119875119900119894119899119905119890119903(119867119886119904ℎ119863119886)9 for (119878119895 isin 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875119896)) do10 119864119905ℎ119904119890119899119889(119867119875 119878119895)11 end for12 end if13 end while14 end function

Algorithm 1

(xv) 119891119890119905119888ℎ(119867119904) function to retrieve data corresponding tohash119867119904

After describing the contracts we specify in this sectionthe behavior of the publisher node after receiving new datagenerated from the connected IoT devices The steps thatshould occur are the following (1) store the data in the off-chain database (IPFS in our case) (2) generate the hashpointing to the location in the database then (3) send thathash to every node on the blockchain that is subscribed to thispublisher All the transactions are sent using the blockchainclient which is an Ethereum client in our implementationThe publisher behavior algorithm is specified in Algorithm 1

In the following we will describe the behavior of asubscriber upon receiving a transaction sent by a publisherthat it is subscribed to Once a transaction is sent by apublisher the blockchain client of the subscriber receives itand extracts the included hash The subscriber first verifiesthe address of the publisher to make sure that it is not an

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 2: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

2 Wireless Communications and Mobile Computing

of peers validation and consensus must be reached in order toprevent spoofing and theft an important characteristic thatany peer-to-peer distributed solution must have especiallylarge scale IoT networks A successful approach to decentral-ized control of IoT must not only be a peer-to-peer approachbut also a trust environment in which no participant needsto be trusted and no single point of trust failure existsBlockchain technology offers these features and proved itsefficiency in financial applications such as Bitcoin [2 3] and itcan be of great value and importance in this domain In thispaper we discuss first important background to understandblockchain technology value as well as related works Thenwe present the specific problem we want to address in thecontext of IoT and finally propose a solution architecture andmodelThe proposed solution is based on smart contracts [4]and Publisher-Subscriber mechanism In the following wepresent a mathematical model to evaluate the performanceof the system and its implementation Finally we end up witha conclusion and some future works

2 Related Works

21 Background

211 Blockchain In 2008 Satoshi Nakamoto introduced Bit-coin [5] a fully digital and decentralized cryptocurrencyIn order to solve the double spending problem in Bitcoinblockchain technology was introduced It is a peer-to-peerdecentralized distributed ledger that is replicated on all nodesparticipating in the system It is a complete transparenttechnology that can show all the transactions that have beenmade since its creation without tampering or fraud [6]Blockchain is a group of blocks that are connected each blockto the one before The first block is called the rdquoGenesisrdquo blockand it is hard coded into the softwareThink of the blockchainas a log whose records are batched into timestamped blockseach block being identified by its cryptographic hash Eachblock references the hash of the block that came before itThisestablishes a link between the blocks thus creating a chain ofblocks or blockchain Any node with access to this orderedback-linked list of blocks can read it and figure out what is theworld state of the data that is being exchanged on the network

Tounderstand howblockchainworks wewill first explainhow a blockchain network works This is a set of nodes thatoperate and interact on the same network using the replicatedblockchain copy each node holds One node might be usedas an entry point for multiple users or devices but let firstassume that each node transacts on the network by itselfonly First of all the interaction between users nodes and theblockchain is done via a pair of private and public keys

The transactions are signed using the private keys andthen addressed by other nodes using the correspondingpublic keys [7] The use of asymmetric cryptography isvery important in terms of providing integrity nonrepudi-ation and authentication to the blockchain network Aftera transaction is signed it is broadcasted by the node to allother nodes it is connected to The nodes or peers needto ensure that the transaction is valid thus they need totrigger a validation process called ldquominingrdquo A transaction

in the blockchain can be defined as any transfer of data thathas a value (Bitcoin IoT data etc) After a transaction isvalidated via the mining process it is then added to theblockchain as a new block of transaction and data Sincethe blockchain is transparent these transactions are availablefor all nodes connected to the network These blocks areorganized in a linear sequence that grows overtime whereeach block contains a timestamp and the hash of the previousblockThis organization of the blocks constitutes the so calledblockchain

When presenting blockchain technology there are twomain platforms to mention Bitcoin blockchain whichis the famous cryptocurrency blockchain and Ethereumblockchain [8] Ethereum is another public blockchain thatallows users to implement smart contracts create privateblockchain and test transactions In our proof of conceptimplementation we have used the Ethereum blockchain

212 Proof ofWork It is used in the blockchain in such a waythat each node participates to solve difficult mathematicalpuzzles that their solution validates blocks This puzzle isusually a function of the previous blocks hash in order tomaintain the chronological order and solving the doublespending problem Once this puzzle is solved there is aldquowinnerrdquo that publishes the solution Once the solution ispublished it is easy for other nodes to verify the solutionHowever solving the puzzle is expensive when it comes tocomputational power Once a majority of the peers acceptthe solution all the nodes in the network begin workingon the next block and a repeating process takes placeProof of work is one approach to reach consensus It is veryefficient in terms of securing the transactions and makingthe blockchain immutable because it requires a great amountof resources from computational resources to electrical andCPUpowersHowever this approachhas itsweaknesses sinceit is inefficient for typical devices that are not very powerfulThemotivation behind proof of work is that the nodes whichinvest significant resources into the network are less likely toattack or cheat

213 Proof of Stake Proof of stake is another approach thataims to solve the computational power problem In orderto validate a certain block or transaction the amount ofcryptocurrency is what matters 51 of the digital currencyowners need to agree on the current state The reason behindproof of stake approach is quite simpleThe higher is the stakein the system the more expensive it is for nodes to maintaina secure network Proof of stake is less secure than proof ofwork however it provides a more efficient approach to thelack of computational power issue

214 Smart Contracts It is possible to include code to beexecuted in the blockchain allowing general purpose compu-tation Similar to a contract between any two individuals thesmart contract is a piece of code that can have conditions to betrigerred and actions to execute if conditions are verified Theimportance of smart contracts comes with their capabilitiesto manage the interactions between nodes and participantsof the system based on the data Smart contracts like any

Wireless Communications and Mobile Computing 3

other node have addresses in the blockchain Triggering asmart contract is done by addressing a transaction to it Thesecurity of these contracts is however very important in theblockchain [9]

215 Mining Mining is one of the most important processesin blockchain technology Mining is the act of validatingnew blocks so that they could be added to the blockchainMining is done by providing ldquoproof of workrdquo to validate ablock ie each block contains a mathematical puzzle thatneeds to be solved by the miner in order to provide proof ofworkThis process can be very expensive regarding computa-tional power Miners are individuals or organizations havingdedicated considerable computational power for mining andmaintaining the blockchain

22 Related Works in the Integration of IoT Blockchain andeHealth After an exhaustive investigation of this field wefound out that blockchain is a great candidate for futuredecentralized IoT architectures and models For exampleauthors in [1] have defined a complete IoT architecture com-posed of three layers where blockchain is used as the storagelayerThe authors also defined a data management and a datasharing protocol along with a study on different mechanismsand their impacts on the system ie direct blockchain accessserver client access and publishersubscriber access Basedon this study we found that the publishersubscriber mech-anism is very important and the most flexible mechanismTherefore we decided to adopt it in our solution Blockchaintechnology is also considered in several ehealthcare solutionAs example authors of paper [10] have highlighted thegeneral role and future impact of blockchain technologyin healthcare In the paper [11] a smart contracts basedsolution has been defined by the authors tomanage the accessto electronic medical records Contribution in [11] is alsoimportant since it has defined the basic use of smart contractsin managing relationships between different parties of ablockchain Another study that focused on the use of smartcontracts in the context of IoT [12] and presents importantaspects and different points of view regarding the benefit ofusing smart contracts A use case of Internet of Things inthe context of eHealth is to have medical sensors composinga Wireless Body Area Network (WBAN) and generatingdata This approach is discussed in [13] Authors have useda cryptographic approach applied to the blockchain and anintermediate device to manage data flow and connectionto the blockchain Authors of papers [14 15] have alsodescribed a cryptographic approach where blockchain isimplemented as a solution to protect personal data Authorsin [16] has discussed the design issues of integrated IoT andblockchain The discussion is very helpful to understand thedifferent possible implementation options (fully centralizedpseudocentralized distributed and fully distributed) Paper[17] discusses the data privacy and integrity issues in thearea of eHealth and more particularly clinical trials Authorshave proposed in this contribution a solution that integratesIoT and blockchain to achieve their objective This workis highly related to our research but focuses more on therelation between parties in the context of clinical trials The

paper [18] is not fullyin the area of eHealth but it presents acomprehensive solution to secure data in the context of smarthomes Authors of the paper have proposed a solution basedon the integration of IoT and blockchain to prevent securityattacks against external attacks bymonitoring the IoT devicestransactions Our research aims to take benefits fromall thesestate of art contributions to derive a well-defined solution touse blockchain technology for IoT data access protection Inthe next section we will highlight the exact challenges to facewhen applying blockchain to IoT

We would like also to mention that this paper is anextended version of our previous work presented in [19]

23 Challenges in Using Blockchain Technology with IoT Aspreviously mentioned blockchain is a peer-to-peer decen-tralized technology that provides transparent and powerfulcertification mechanisms while removing the need to trustexternal third parties While this is a very important advan-tage it comes also with some important challenges Firstof all with the intrinsic architecture of the blockchain theledger is replicated on all nodes connected to the blockchainTherefore the storage of large amount of data is inefficientif it is in the blockchain itself This is indeed a big problemfor IoT devices such as typical sensors that do have limitedcomputing and storage resources In addition since there isno third parties involved in the system every block addedto the blockchain needs to be validated by each of its nodesThis is called the rdquolsquoMiningrdquorsquo process as previousely explainedand it requires high computational power demand [20] torunencryption algorithms As the IoT ecosystem is verydiverse and could consist of heterogeneous devices with verydifferent computing capabilities all these devices will notbe able to execute the same encryption algorithms at thedesired speed and this should be taken into account in theproposed architectural solution Another characteristic ofIoT that renders the problem even more complicated is thescalability problem Indeed when the number of IoT nodesincreases the number of generated data will also increase andtherefore the the number of transactions to the blockchainwill also increase The mining and validation process ofthe blockchain will then take more time to complete andthis should be mitigated as much as possible to acheive thescalability property of IoT systems In this paper we aimto address specifically this mining problem and the timetaken by the system to complete the transactions We havetherefore focused our research on the factors and parametersthat might have the higher impact on the complexity of themining process such as the block size and the block time Inthe next section we will discuss the proposed architecture ofthe distributed IoT system followed by the proposed solutionmechanisms

3 Proposed Architecture

The main idea of our approach to solve the problem ofthe high computational power needed in order to com-municate with the blockchain is to introduce a central-izeddecentralized combined architecture ie to introduceintermediate servers between IoT devices and the blockchain

4 Wireless Communications and Mobile Computing

A very good candidate for such an intermediate systemis a cloud edge server easily accessible by clients andwith high computational power The other proposition isto use of a publish-subscribe notification mechanism Inparticular we have taken into account the results obtainedfrom the authors of paper [1] who have shown that thepublish-subscribe mechanism is very efficient in terms offiltering data and introducing intermediates to address thehigh demand of electrical and computational powers fromblockchainmechanisms In addition we propose to use in oursolution smart contracts to maintain rules authenticationand communication between the different nodes and partiesof our system Finally since the transaction of messageswith large amount of data highly negatively impact theperformance of the blockchain we propose to use an off-chain database to store the data in our case we have usedIPFS [21] as peer to peer storage systemThe Figure 1 presentsa high level diagram of the proposed architecture identifyingthe different actors the blockchain and the IoT devices

In the next sections we will first present the consideredscenario then the details of the proposed architecture in termsof components and their interactions

4 Proposed Solution

41 Defining the Scenario To design our solution we havefirst specified a potential real life scenario to help identifyingthe required components and functionalities This scenario isrelated to the eHealth smart home and the remotemonitoringof patients We considered a home equipped with numerousconnected sensors (ie connected things) that collect envi-ronmental data from the home (eg temperature humidityetc) as well as medical sensors that collect health data frominhabitant (eg heart beats ECG etc)

The problem we aimed to address is the following howcan the monitored persons can ensure that the data that iscollected from their private environment and their own bodyand sent outside their home is only accessed by authorizedpersons (eg authorized doctors) and that it is not altered forany malicious reason by a third party

The direction that has been followed to solve this prob-lem is actually to protect the location where the collecteddata is stored To acheive this objective we will highlighthow the components of our blockchain IoT architecture(blockchain smart contracts intermediate servers and off-chain database) could be efficiently glued together for thispurpose The main actors of this scenario are the publishersof data and the subscribers to these data while the end-providers and consumers are the IoT devices and the end-users (data generators and data consumers) Figure 2 presentsour solution to be deployed in the smart home that is derivedfrom the more general architecture presented in Figure 1

The main idea of the solution is highlighted in Figure 2that is to overcome the limitation of connected objects in asmart home not able to directly connect to the blockchain dueto their limited processing capacity and energy powerThis isachieved using intermediary edge system that connects thesmart home to the blockchain and called the gateway Thisgateway is expected to bemore powerful than normal sensors

and will play the role of the publisher to the blockchainEventually it will publish the data received from the setof connected sensors in the smart home to the blockchainThe owners of this data are the monitored persons (egelderly) who live in their homes and have access to this dataThese persons can specify a set of authorized individuals ororganisation that are authorized to access this data

42 Defining the Smart Contracts In order to specify theformal relation between data owners consumers and clientssmart contracts are the corner stone of our blockchain IoTsystem

We have defined 3 types of contracts The proposed smartcontracts are presented in Figure 3

421 The Publisher Contract The first contract is the pub-lisher contract that is deployed by the publisher One canthink about contracts as functions that take input checkit and sendback results When an individual subscribes tothe system and connects his smart home gateway to theblockchain he must first specify his gateway or publishercontract Once accepted he receives an unique ID mappedto his blockchain address (Ethereum [22] address in thecase of Ethereum blockchain) He must also specify the listof IoT devices to connect to the blockchain This can bedone by names to ease access and comprehension of thegenerated data In addition he must specify a type of sharingmechanism to manage the publishersubscriber relationshipand finally he mustspecify the list of addresses that havepermission to access the data (usually these are the addressesof subscribers who are authorized to access the data)

422 The Subscriber Contract The second contract is thesubscriber contract It must contain the address of the sub-scriber in the blockchain and the list of publishers to whichit subscribes It must also specify the specific list of sensors tosubscribe to The sensors can be chosen by type by name orusing a wildcard to select all the available sensors connectedto a particular publisher This is the critical componentof the publisher-subscriber algorithm since based on theinformation stored in that contract the generated data canbe filtered before sending it to a subscriber

423 The Client Contract The third contract is the clientcontract It serves as a mapping contract between normalnodes or clients connected to the blockchain and theirrespective subscriber contracts It contains the client name sothat it would be simpler for clients to communicate betweeneach other using a frontend application This name is mappedto the corresponding address in the blockchain

43The Protocol Description Before describing our protocolwe first define some notations that will be later used in thepaper

(i) 119875119896 publisher number k(ii) 119889119896119894 device i connected to publisher k(iii) 119878119895 subscriber number j(iv) 119862119895 client number j

Wireless Communications and Mobile Computing 5

IoT Device

IoT Device

IoT Device Publisher Node

IoT Blockchain

Client Node

IPFS Database

Subscriber Node

Client Node

Client Node

Client Node

Client Node

Figure 1 Proposed architecture presenting IoT devices connected to the Publisher node itself connected to the blockchain On the otherside clients are either connected to subscriber nodes or directly to the blockchain

Smart home

Blockchain

Home Ownver

Authorized person

Gateway (Publisher)

Figure 2 An architecture for the smart home blockchain IoTthat identifies the gateway to the blockchain the owners and theauthorized persons to access the private data

(v) 119877119890119886119889119871119900119888119886119897119863119886119905119886() function to retrieve data from thelocal buffer

(vi) 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863() function to retrieve the ID ofthe sending IoT device

(vii) 119878119905119900119903119890119863119886119905119886() function to store data in the off-chaindatabase

(viii) 119866119890119899119875119900119894119899119905119890119903() function to generate pointer to locationin the database

(ix) 119867 the Hash pointing to the location in the database(x) 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875) function to return the list of sub-

scribers that subscribed to publisher P(xi) 119864119905ℎ reference to the blockchain client(xii) 119862119895 set of j clients having the same subscriber(xiii) 119903119890119888(119878) function that allows the client to retrieve the

message sent by a subscriber S(xiv) 119862119900119899119899119890119888119905(119863119861119875) function to connect to database 119863119861119875

1 function Publisher ⊳2 119894119899119894119905119894119886119897119894119911119890119875119906119887119897119894119904ℎ1198901199033 while (119890V119890119899119905119891119903119900119898119886119899119868119900119879119889119890V119894119888119890 = 119879119903119906119890) do4 119863119886 larr997888 119877119890119886119889119871119900119888119886119897119863119886119905119886(119889119896119894 )5 119886 larr997888 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863(119863119886)6 if (119886 = True) then7 119888 larr997888 119878119905119900119903119890119863119886119905119886119861119862(119863119886)8 119867119875 larr997888 119866119890119899119875119900119894119899119905119890119903(119867119886119904ℎ119863119886)9 for (119878119895 isin 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875119896)) do10 119864119905ℎ119904119890119899119889(119867119875 119878119895)11 end for12 end if13 end while14 end function

Algorithm 1

(xv) 119891119890119905119888ℎ(119867119904) function to retrieve data corresponding tohash119867119904

After describing the contracts we specify in this sectionthe behavior of the publisher node after receiving new datagenerated from the connected IoT devices The steps thatshould occur are the following (1) store the data in the off-chain database (IPFS in our case) (2) generate the hashpointing to the location in the database then (3) send thathash to every node on the blockchain that is subscribed to thispublisher All the transactions are sent using the blockchainclient which is an Ethereum client in our implementationThe publisher behavior algorithm is specified in Algorithm 1

In the following we will describe the behavior of asubscriber upon receiving a transaction sent by a publisherthat it is subscribed to Once a transaction is sent by apublisher the blockchain client of the subscriber receives itand extracts the included hash The subscriber first verifiesthe address of the publisher to make sure that it is not an

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 3: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Wireless Communications and Mobile Computing 3

other node have addresses in the blockchain Triggering asmart contract is done by addressing a transaction to it Thesecurity of these contracts is however very important in theblockchain [9]

215 Mining Mining is one of the most important processesin blockchain technology Mining is the act of validatingnew blocks so that they could be added to the blockchainMining is done by providing ldquoproof of workrdquo to validate ablock ie each block contains a mathematical puzzle thatneeds to be solved by the miner in order to provide proof ofworkThis process can be very expensive regarding computa-tional power Miners are individuals or organizations havingdedicated considerable computational power for mining andmaintaining the blockchain

22 Related Works in the Integration of IoT Blockchain andeHealth After an exhaustive investigation of this field wefound out that blockchain is a great candidate for futuredecentralized IoT architectures and models For exampleauthors in [1] have defined a complete IoT architecture com-posed of three layers where blockchain is used as the storagelayerThe authors also defined a data management and a datasharing protocol along with a study on different mechanismsand their impacts on the system ie direct blockchain accessserver client access and publishersubscriber access Basedon this study we found that the publishersubscriber mech-anism is very important and the most flexible mechanismTherefore we decided to adopt it in our solution Blockchaintechnology is also considered in several ehealthcare solutionAs example authors of paper [10] have highlighted thegeneral role and future impact of blockchain technologyin healthcare In the paper [11] a smart contracts basedsolution has been defined by the authors tomanage the accessto electronic medical records Contribution in [11] is alsoimportant since it has defined the basic use of smart contractsin managing relationships between different parties of ablockchain Another study that focused on the use of smartcontracts in the context of IoT [12] and presents importantaspects and different points of view regarding the benefit ofusing smart contracts A use case of Internet of Things inthe context of eHealth is to have medical sensors composinga Wireless Body Area Network (WBAN) and generatingdata This approach is discussed in [13] Authors have useda cryptographic approach applied to the blockchain and anintermediate device to manage data flow and connectionto the blockchain Authors of papers [14 15] have alsodescribed a cryptographic approach where blockchain isimplemented as a solution to protect personal data Authorsin [16] has discussed the design issues of integrated IoT andblockchain The discussion is very helpful to understand thedifferent possible implementation options (fully centralizedpseudocentralized distributed and fully distributed) Paper[17] discusses the data privacy and integrity issues in thearea of eHealth and more particularly clinical trials Authorshave proposed in this contribution a solution that integratesIoT and blockchain to achieve their objective This workis highly related to our research but focuses more on therelation between parties in the context of clinical trials The

paper [18] is not fullyin the area of eHealth but it presents acomprehensive solution to secure data in the context of smarthomes Authors of the paper have proposed a solution basedon the integration of IoT and blockchain to prevent securityattacks against external attacks bymonitoring the IoT devicestransactions Our research aims to take benefits fromall thesestate of art contributions to derive a well-defined solution touse blockchain technology for IoT data access protection Inthe next section we will highlight the exact challenges to facewhen applying blockchain to IoT

We would like also to mention that this paper is anextended version of our previous work presented in [19]

23 Challenges in Using Blockchain Technology with IoT Aspreviously mentioned blockchain is a peer-to-peer decen-tralized technology that provides transparent and powerfulcertification mechanisms while removing the need to trustexternal third parties While this is a very important advan-tage it comes also with some important challenges Firstof all with the intrinsic architecture of the blockchain theledger is replicated on all nodes connected to the blockchainTherefore the storage of large amount of data is inefficientif it is in the blockchain itself This is indeed a big problemfor IoT devices such as typical sensors that do have limitedcomputing and storage resources In addition since there isno third parties involved in the system every block addedto the blockchain needs to be validated by each of its nodesThis is called the rdquolsquoMiningrdquorsquo process as previousely explainedand it requires high computational power demand [20] torunencryption algorithms As the IoT ecosystem is verydiverse and could consist of heterogeneous devices with verydifferent computing capabilities all these devices will notbe able to execute the same encryption algorithms at thedesired speed and this should be taken into account in theproposed architectural solution Another characteristic ofIoT that renders the problem even more complicated is thescalability problem Indeed when the number of IoT nodesincreases the number of generated data will also increase andtherefore the the number of transactions to the blockchainwill also increase The mining and validation process ofthe blockchain will then take more time to complete andthis should be mitigated as much as possible to acheive thescalability property of IoT systems In this paper we aimto address specifically this mining problem and the timetaken by the system to complete the transactions We havetherefore focused our research on the factors and parametersthat might have the higher impact on the complexity of themining process such as the block size and the block time Inthe next section we will discuss the proposed architecture ofthe distributed IoT system followed by the proposed solutionmechanisms

3 Proposed Architecture

The main idea of our approach to solve the problem ofthe high computational power needed in order to com-municate with the blockchain is to introduce a central-izeddecentralized combined architecture ie to introduceintermediate servers between IoT devices and the blockchain

4 Wireless Communications and Mobile Computing

A very good candidate for such an intermediate systemis a cloud edge server easily accessible by clients andwith high computational power The other proposition isto use of a publish-subscribe notification mechanism Inparticular we have taken into account the results obtainedfrom the authors of paper [1] who have shown that thepublish-subscribe mechanism is very efficient in terms offiltering data and introducing intermediates to address thehigh demand of electrical and computational powers fromblockchainmechanisms In addition we propose to use in oursolution smart contracts to maintain rules authenticationand communication between the different nodes and partiesof our system Finally since the transaction of messageswith large amount of data highly negatively impact theperformance of the blockchain we propose to use an off-chain database to store the data in our case we have usedIPFS [21] as peer to peer storage systemThe Figure 1 presentsa high level diagram of the proposed architecture identifyingthe different actors the blockchain and the IoT devices

In the next sections we will first present the consideredscenario then the details of the proposed architecture in termsof components and their interactions

4 Proposed Solution

41 Defining the Scenario To design our solution we havefirst specified a potential real life scenario to help identifyingthe required components and functionalities This scenario isrelated to the eHealth smart home and the remotemonitoringof patients We considered a home equipped with numerousconnected sensors (ie connected things) that collect envi-ronmental data from the home (eg temperature humidityetc) as well as medical sensors that collect health data frominhabitant (eg heart beats ECG etc)

The problem we aimed to address is the following howcan the monitored persons can ensure that the data that iscollected from their private environment and their own bodyand sent outside their home is only accessed by authorizedpersons (eg authorized doctors) and that it is not altered forany malicious reason by a third party

The direction that has been followed to solve this prob-lem is actually to protect the location where the collecteddata is stored To acheive this objective we will highlighthow the components of our blockchain IoT architecture(blockchain smart contracts intermediate servers and off-chain database) could be efficiently glued together for thispurpose The main actors of this scenario are the publishersof data and the subscribers to these data while the end-providers and consumers are the IoT devices and the end-users (data generators and data consumers) Figure 2 presentsour solution to be deployed in the smart home that is derivedfrom the more general architecture presented in Figure 1

The main idea of the solution is highlighted in Figure 2that is to overcome the limitation of connected objects in asmart home not able to directly connect to the blockchain dueto their limited processing capacity and energy powerThis isachieved using intermediary edge system that connects thesmart home to the blockchain and called the gateway Thisgateway is expected to bemore powerful than normal sensors

and will play the role of the publisher to the blockchainEventually it will publish the data received from the setof connected sensors in the smart home to the blockchainThe owners of this data are the monitored persons (egelderly) who live in their homes and have access to this dataThese persons can specify a set of authorized individuals ororganisation that are authorized to access this data

42 Defining the Smart Contracts In order to specify theformal relation between data owners consumers and clientssmart contracts are the corner stone of our blockchain IoTsystem

We have defined 3 types of contracts The proposed smartcontracts are presented in Figure 3

421 The Publisher Contract The first contract is the pub-lisher contract that is deployed by the publisher One canthink about contracts as functions that take input checkit and sendback results When an individual subscribes tothe system and connects his smart home gateway to theblockchain he must first specify his gateway or publishercontract Once accepted he receives an unique ID mappedto his blockchain address (Ethereum [22] address in thecase of Ethereum blockchain) He must also specify the listof IoT devices to connect to the blockchain This can bedone by names to ease access and comprehension of thegenerated data In addition he must specify a type of sharingmechanism to manage the publishersubscriber relationshipand finally he mustspecify the list of addresses that havepermission to access the data (usually these are the addressesof subscribers who are authorized to access the data)

422 The Subscriber Contract The second contract is thesubscriber contract It must contain the address of the sub-scriber in the blockchain and the list of publishers to whichit subscribes It must also specify the specific list of sensors tosubscribe to The sensors can be chosen by type by name orusing a wildcard to select all the available sensors connectedto a particular publisher This is the critical componentof the publisher-subscriber algorithm since based on theinformation stored in that contract the generated data canbe filtered before sending it to a subscriber

423 The Client Contract The third contract is the clientcontract It serves as a mapping contract between normalnodes or clients connected to the blockchain and theirrespective subscriber contracts It contains the client name sothat it would be simpler for clients to communicate betweeneach other using a frontend application This name is mappedto the corresponding address in the blockchain

43The Protocol Description Before describing our protocolwe first define some notations that will be later used in thepaper

(i) 119875119896 publisher number k(ii) 119889119896119894 device i connected to publisher k(iii) 119878119895 subscriber number j(iv) 119862119895 client number j

Wireless Communications and Mobile Computing 5

IoT Device

IoT Device

IoT Device Publisher Node

IoT Blockchain

Client Node

IPFS Database

Subscriber Node

Client Node

Client Node

Client Node

Client Node

Figure 1 Proposed architecture presenting IoT devices connected to the Publisher node itself connected to the blockchain On the otherside clients are either connected to subscriber nodes or directly to the blockchain

Smart home

Blockchain

Home Ownver

Authorized person

Gateway (Publisher)

Figure 2 An architecture for the smart home blockchain IoTthat identifies the gateway to the blockchain the owners and theauthorized persons to access the private data

(v) 119877119890119886119889119871119900119888119886119897119863119886119905119886() function to retrieve data from thelocal buffer

(vi) 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863() function to retrieve the ID ofthe sending IoT device

(vii) 119878119905119900119903119890119863119886119905119886() function to store data in the off-chaindatabase

(viii) 119866119890119899119875119900119894119899119905119890119903() function to generate pointer to locationin the database

(ix) 119867 the Hash pointing to the location in the database(x) 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875) function to return the list of sub-

scribers that subscribed to publisher P(xi) 119864119905ℎ reference to the blockchain client(xii) 119862119895 set of j clients having the same subscriber(xiii) 119903119890119888(119878) function that allows the client to retrieve the

message sent by a subscriber S(xiv) 119862119900119899119899119890119888119905(119863119861119875) function to connect to database 119863119861119875

1 function Publisher ⊳2 119894119899119894119905119894119886119897119894119911119890119875119906119887119897119894119904ℎ1198901199033 while (119890V119890119899119905119891119903119900119898119886119899119868119900119879119889119890V119894119888119890 = 119879119903119906119890) do4 119863119886 larr997888 119877119890119886119889119871119900119888119886119897119863119886119905119886(119889119896119894 )5 119886 larr997888 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863(119863119886)6 if (119886 = True) then7 119888 larr997888 119878119905119900119903119890119863119886119905119886119861119862(119863119886)8 119867119875 larr997888 119866119890119899119875119900119894119899119905119890119903(119867119886119904ℎ119863119886)9 for (119878119895 isin 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875119896)) do10 119864119905ℎ119904119890119899119889(119867119875 119878119895)11 end for12 end if13 end while14 end function

Algorithm 1

(xv) 119891119890119905119888ℎ(119867119904) function to retrieve data corresponding tohash119867119904

After describing the contracts we specify in this sectionthe behavior of the publisher node after receiving new datagenerated from the connected IoT devices The steps thatshould occur are the following (1) store the data in the off-chain database (IPFS in our case) (2) generate the hashpointing to the location in the database then (3) send thathash to every node on the blockchain that is subscribed to thispublisher All the transactions are sent using the blockchainclient which is an Ethereum client in our implementationThe publisher behavior algorithm is specified in Algorithm 1

In the following we will describe the behavior of asubscriber upon receiving a transaction sent by a publisherthat it is subscribed to Once a transaction is sent by apublisher the blockchain client of the subscriber receives itand extracts the included hash The subscriber first verifiesthe address of the publisher to make sure that it is not an

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 4: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

4 Wireless Communications and Mobile Computing

A very good candidate for such an intermediate systemis a cloud edge server easily accessible by clients andwith high computational power The other proposition isto use of a publish-subscribe notification mechanism Inparticular we have taken into account the results obtainedfrom the authors of paper [1] who have shown that thepublish-subscribe mechanism is very efficient in terms offiltering data and introducing intermediates to address thehigh demand of electrical and computational powers fromblockchainmechanisms In addition we propose to use in oursolution smart contracts to maintain rules authenticationand communication between the different nodes and partiesof our system Finally since the transaction of messageswith large amount of data highly negatively impact theperformance of the blockchain we propose to use an off-chain database to store the data in our case we have usedIPFS [21] as peer to peer storage systemThe Figure 1 presentsa high level diagram of the proposed architecture identifyingthe different actors the blockchain and the IoT devices

In the next sections we will first present the consideredscenario then the details of the proposed architecture in termsof components and their interactions

4 Proposed Solution

41 Defining the Scenario To design our solution we havefirst specified a potential real life scenario to help identifyingthe required components and functionalities This scenario isrelated to the eHealth smart home and the remotemonitoringof patients We considered a home equipped with numerousconnected sensors (ie connected things) that collect envi-ronmental data from the home (eg temperature humidityetc) as well as medical sensors that collect health data frominhabitant (eg heart beats ECG etc)

The problem we aimed to address is the following howcan the monitored persons can ensure that the data that iscollected from their private environment and their own bodyand sent outside their home is only accessed by authorizedpersons (eg authorized doctors) and that it is not altered forany malicious reason by a third party

The direction that has been followed to solve this prob-lem is actually to protect the location where the collecteddata is stored To acheive this objective we will highlighthow the components of our blockchain IoT architecture(blockchain smart contracts intermediate servers and off-chain database) could be efficiently glued together for thispurpose The main actors of this scenario are the publishersof data and the subscribers to these data while the end-providers and consumers are the IoT devices and the end-users (data generators and data consumers) Figure 2 presentsour solution to be deployed in the smart home that is derivedfrom the more general architecture presented in Figure 1

The main idea of the solution is highlighted in Figure 2that is to overcome the limitation of connected objects in asmart home not able to directly connect to the blockchain dueto their limited processing capacity and energy powerThis isachieved using intermediary edge system that connects thesmart home to the blockchain and called the gateway Thisgateway is expected to bemore powerful than normal sensors

and will play the role of the publisher to the blockchainEventually it will publish the data received from the setof connected sensors in the smart home to the blockchainThe owners of this data are the monitored persons (egelderly) who live in their homes and have access to this dataThese persons can specify a set of authorized individuals ororganisation that are authorized to access this data

42 Defining the Smart Contracts In order to specify theformal relation between data owners consumers and clientssmart contracts are the corner stone of our blockchain IoTsystem

We have defined 3 types of contracts The proposed smartcontracts are presented in Figure 3

421 The Publisher Contract The first contract is the pub-lisher contract that is deployed by the publisher One canthink about contracts as functions that take input checkit and sendback results When an individual subscribes tothe system and connects his smart home gateway to theblockchain he must first specify his gateway or publishercontract Once accepted he receives an unique ID mappedto his blockchain address (Ethereum [22] address in thecase of Ethereum blockchain) He must also specify the listof IoT devices to connect to the blockchain This can bedone by names to ease access and comprehension of thegenerated data In addition he must specify a type of sharingmechanism to manage the publishersubscriber relationshipand finally he mustspecify the list of addresses that havepermission to access the data (usually these are the addressesof subscribers who are authorized to access the data)

422 The Subscriber Contract The second contract is thesubscriber contract It must contain the address of the sub-scriber in the blockchain and the list of publishers to whichit subscribes It must also specify the specific list of sensors tosubscribe to The sensors can be chosen by type by name orusing a wildcard to select all the available sensors connectedto a particular publisher This is the critical componentof the publisher-subscriber algorithm since based on theinformation stored in that contract the generated data canbe filtered before sending it to a subscriber

423 The Client Contract The third contract is the clientcontract It serves as a mapping contract between normalnodes or clients connected to the blockchain and theirrespective subscriber contracts It contains the client name sothat it would be simpler for clients to communicate betweeneach other using a frontend application This name is mappedto the corresponding address in the blockchain

43The Protocol Description Before describing our protocolwe first define some notations that will be later used in thepaper

(i) 119875119896 publisher number k(ii) 119889119896119894 device i connected to publisher k(iii) 119878119895 subscriber number j(iv) 119862119895 client number j

Wireless Communications and Mobile Computing 5

IoT Device

IoT Device

IoT Device Publisher Node

IoT Blockchain

Client Node

IPFS Database

Subscriber Node

Client Node

Client Node

Client Node

Client Node

Figure 1 Proposed architecture presenting IoT devices connected to the Publisher node itself connected to the blockchain On the otherside clients are either connected to subscriber nodes or directly to the blockchain

Smart home

Blockchain

Home Ownver

Authorized person

Gateway (Publisher)

Figure 2 An architecture for the smart home blockchain IoTthat identifies the gateway to the blockchain the owners and theauthorized persons to access the private data

(v) 119877119890119886119889119871119900119888119886119897119863119886119905119886() function to retrieve data from thelocal buffer

(vi) 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863() function to retrieve the ID ofthe sending IoT device

(vii) 119878119905119900119903119890119863119886119905119886() function to store data in the off-chaindatabase

(viii) 119866119890119899119875119900119894119899119905119890119903() function to generate pointer to locationin the database

(ix) 119867 the Hash pointing to the location in the database(x) 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875) function to return the list of sub-

scribers that subscribed to publisher P(xi) 119864119905ℎ reference to the blockchain client(xii) 119862119895 set of j clients having the same subscriber(xiii) 119903119890119888(119878) function that allows the client to retrieve the

message sent by a subscriber S(xiv) 119862119900119899119899119890119888119905(119863119861119875) function to connect to database 119863119861119875

1 function Publisher ⊳2 119894119899119894119905119894119886119897119894119911119890119875119906119887119897119894119904ℎ1198901199033 while (119890V119890119899119905119891119903119900119898119886119899119868119900119879119889119890V119894119888119890 = 119879119903119906119890) do4 119863119886 larr997888 119877119890119886119889119871119900119888119886119897119863119886119905119886(119889119896119894 )5 119886 larr997888 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863(119863119886)6 if (119886 = True) then7 119888 larr997888 119878119905119900119903119890119863119886119905119886119861119862(119863119886)8 119867119875 larr997888 119866119890119899119875119900119894119899119905119890119903(119867119886119904ℎ119863119886)9 for (119878119895 isin 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875119896)) do10 119864119905ℎ119904119890119899119889(119867119875 119878119895)11 end for12 end if13 end while14 end function

Algorithm 1

(xv) 119891119890119905119888ℎ(119867119904) function to retrieve data corresponding tohash119867119904

After describing the contracts we specify in this sectionthe behavior of the publisher node after receiving new datagenerated from the connected IoT devices The steps thatshould occur are the following (1) store the data in the off-chain database (IPFS in our case) (2) generate the hashpointing to the location in the database then (3) send thathash to every node on the blockchain that is subscribed to thispublisher All the transactions are sent using the blockchainclient which is an Ethereum client in our implementationThe publisher behavior algorithm is specified in Algorithm 1

In the following we will describe the behavior of asubscriber upon receiving a transaction sent by a publisherthat it is subscribed to Once a transaction is sent by apublisher the blockchain client of the subscriber receives itand extracts the included hash The subscriber first verifiesthe address of the publisher to make sure that it is not an

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 5: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Wireless Communications and Mobile Computing 5

IoT Device

IoT Device

IoT Device Publisher Node

IoT Blockchain

Client Node

IPFS Database

Subscriber Node

Client Node

Client Node

Client Node

Client Node

Figure 1 Proposed architecture presenting IoT devices connected to the Publisher node itself connected to the blockchain On the otherside clients are either connected to subscriber nodes or directly to the blockchain

Smart home

Blockchain

Home Ownver

Authorized person

Gateway (Publisher)

Figure 2 An architecture for the smart home blockchain IoTthat identifies the gateway to the blockchain the owners and theauthorized persons to access the private data

(v) 119877119890119886119889119871119900119888119886119897119863119886119905119886() function to retrieve data from thelocal buffer

(vi) 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863() function to retrieve the ID ofthe sending IoT device

(vii) 119878119905119900119903119890119863119886119905119886() function to store data in the off-chaindatabase

(viii) 119866119890119899119875119900119894119899119905119890119903() function to generate pointer to locationin the database

(ix) 119867 the Hash pointing to the location in the database(x) 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875) function to return the list of sub-

scribers that subscribed to publisher P(xi) 119864119905ℎ reference to the blockchain client(xii) 119862119895 set of j clients having the same subscriber(xiii) 119903119890119888(119878) function that allows the client to retrieve the

message sent by a subscriber S(xiv) 119862119900119899119899119890119888119905(119863119861119875) function to connect to database 119863119861119875

1 function Publisher ⊳2 119894119899119894119905119894119886119897119894119911119890119875119906119887119897119894119904ℎ1198901199033 while (119890V119890119899119905119891119903119900119898119886119899119868119900119879119889119890V119894119888119890 = 119879119903119906119890) do4 119863119886 larr997888 119877119890119886119889119871119900119888119886119897119863119886119905119886(119889119896119894 )5 119886 larr997888 119878119890119899119889119894119899119892119868119900119879119863119890V119894119888119890119868119863(119863119886)6 if (119886 = True) then7 119888 larr997888 119878119905119900119903119890119863119886119905119886119861119862(119863119886)8 119867119875 larr997888 119866119890119899119875119900119894119899119905119890119903(119867119886119904ℎ119863119886)9 for (119878119895 isin 119878119906119887119904119888119903119894119887119890119889119871119894119904119905(119875119896)) do10 119864119905ℎ119904119890119899119889(119867119875 119878119895)11 end for12 end if13 end while14 end function

Algorithm 1

(xv) 119891119890119905119888ℎ(119867119904) function to retrieve data corresponding tohash119867119904

After describing the contracts we specify in this sectionthe behavior of the publisher node after receiving new datagenerated from the connected IoT devices The steps thatshould occur are the following (1) store the data in the off-chain database (IPFS in our case) (2) generate the hashpointing to the location in the database then (3) send thathash to every node on the blockchain that is subscribed to thispublisher All the transactions are sent using the blockchainclient which is an Ethereum client in our implementationThe publisher behavior algorithm is specified in Algorithm 1

In the following we will describe the behavior of asubscriber upon receiving a transaction sent by a publisherthat it is subscribed to Once a transaction is sent by apublisher the blockchain client of the subscriber receives itand extracts the included hash The subscriber first verifiesthe address of the publisher to make sure that it is not an

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 6: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

6 Wireless Communications and Mobile Computing

1 function Subscriber ⊳2 1198941198991198941199051198941198861198971198941199111198901198781199061198871199041198881199031198941198871198901199033 119862119895 larr997888 1199031198901198921198941199041199051198901199031198901198891198881198971198941198901198991199051199044 while 119890V119890119899119905119891119903119900119898119875119906119887119897119894119904ℎ119890119903 = 119879119903119906119890 do5 119867119904 larr997888 119864119905ℎ119903119890119888119890119894V119890()6 if ((119867119904 = 0) 119886119899119889 (119864119905ℎ119886119889119889119903119890119904119904(119904119890119899119889119890119903) == 119864119905ℎ119886119889119889119903119890119904119904(119875119896))) then7 for 119888119895 isin 119862119895 do8 119904119890119899119889(119867119904 119888119895)9 end for10 end if11 end while12 end function

Algorithm 2

IoTDevice Names (List)

IoTDevice Types (List)

PublisherNode ID (or Eth Adress)

List of Addresses that have permission

ClientName Eth Address SubscriberContract

Owner Eth Address

PublisherName Sensor TypeNameAll

Figure 3 Proposed smart contracts publisher contract subscribercontract and client contract

error or a spam If not the action of the subscriber is differentdepending on whether the client is directly connected to theblockchain or not If it is directly connected this means thatthe client has deployed its own subscriber node therefore itreceives the transaction directly through the blockchain client

1 function Client ⊳2 1198941198991198941199051198941198861198971198941199111198901198621198971198941198901198991199053 while (119890V119890119899119905119891119903119900119898119890119899119889 minus 119906119904119890119903 = 119879119903119906119890) do4 119867119904 larr997888 119903119890119888(119878)5 if (119867119904 = 0) then6 119862 larr997888 119862119900119899119899119890119888119905(119863119861119875)7 119863119886119905119886 larr997888 119862119891119890119905119888ℎ(119867119904)8 end if9 end while10 end function

Algorithm 3

part of its subscriber node Alternatively the client may nothave its own subscriber node and is therefore using anothersubscriber node to the blockchain along with other clientsThis part implements the possibility of having several clientsbehind only one subscriber node handling the data on theirbehalf in the blockchain and forwarding it to all of them Theclients registered with the subscriber are part of the set 119878119895

The algorithm that shows this behavior is specified inAlgorithm 2

The third part describes the fetching of the data using thereceived hash in the second part The client connects to theIPFS node whenever the end-user requests it and uses thehash code to fetch the data generated by the IoT devices Thisbehavior is specified in Algorithm 3

Figure 4 highlights the specific modules of the subscribernode and the publisher node In the subscriber node theGraphical User Interface (GUI) is the entry point for theend-user The Ethereum client connects the node to theblockchain and the local database stores the received data (itworks as a cache to reduce response time of future accesses)

It is also worthy to mention that one important step ofthe process is not actually visible in the Figure 4 that is themining Indeed for each transaction taking place the nodeson the blockchain (miners) shall validate the transaction aspreviousely explained This increases the time to deliver amessage from a publisher to a subscriber and it has also animportant impact on the performance of the overall systemin terms of response time

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 7: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Wireless Communications and Mobile Computing 7

GUI

Local Client Database

Eth Client

Subscriber Code

Blockchain

Client Node (Subscriber)

Eth Client

Subscriber Code

DB Access Control

IoTDevice

Offchain Publisher Database

Publisher Node

Figure 4 Internal structure of the client and subscriber nodes andpublisher

Figure 5 shows the sequence diagram of the proposedprotocol that depicts the exchanged messages between thedifferent components of the architecture The previouslypresented algorithms specify the internal behaviors of thepublisher and the subscriber nodes as well as the informationthat transit between them The miner behavior correspondsto the mining process that happens each time a transaction istransmitted to the blockchain

Table 1 describes the main functions used in the imple-mentation of the proposed protocol Each function is alsodescribed in this table InTable 2 themain used variables thatallow the protocol to function correctly are described Thevariables presented in Table 2 constitute the input or outputparameters to the functions described in Table 1

5 Performance Analysis of the System

As previously mentioned the mining process is an importantpart of the system and should be explicitly considered inthe performance evaluation of the system mainly in termsof response time Eventually to optimize the performance ofsuch a system many factors should be taken into accountThe main performance parameter is the delay of processinga transaction and therefore it is important to identify theparametersfactors that could have an important impact onthis delay

In this system the transaction time obviousely dependson the rate and size of the data 119905 = 119891(119903 119904) This rate isimportant because it impacts the mining process If the rateof data generated by IoT devices increases the transactiontime will also increase The mining process depends also onthe capability of a device processor to validate a transactionso does the delay time [23] The best approach to reducethe transaction time is to lower the rate and the size of the

Table 1 Protocol functions and description

Function Description

RegisterPublisherThis functionrsquos role is to identify thepublisher to the blockchain Apublisher registration consists of anID and its address in the blockchain

RegisterSubscriberSimilar to RegisterPublisherfunction but for the subscribernodes

AddSensorThis function is available for thepublisher nodes In order to addsensors a publisher should providea type and an ID for the sensor

RegisterToSensorThe Subscriber can check apublisherrsquos added sensor andregister to one or all sensorsdepending on ID or Type

NotifyThe notify function is critical sinceit advertises new data newpublishers and new sensors

StoreData When new data is generated it isstored in the decentralized storage

GenerateHash

After storage a hash of the pointerto the location of the data in thestorage is generated and thenbroadcasted to interestedsubscribers using the Notifyfunction

Table 2 Protocol data types and description

Data Type Description

PubIDThe publisher ID needed forregistration and used by subscriberto subscribe to of type String

PubAddressThe publisher address in theblockchain needed for registrationand used by subscriber to subscribeto of type address

SubID The subscriber ID needed forregistration of type String

SubAddressThe subscriber address in theblockchain needed for registrationof type address

SensorInfo The sensor type and ID of typeString

HashPointerThe main data type transferredbetween publishers and subscribersusing the Notify function can be oftype base58

data Unfortunately this is not always possible First it isnot always possible to control the CPU computing capacitysince it comes with the device hardware and moreover it isnot always possible to control the rate and the size of datatransmitted by sensors (this also depends on the applicationlogic) For example monitoring in real time the ECG ofan individual can be critical For that doctors must be

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 8: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

8 Wireless Communications and Mobile Computing

IoT Device Publisher Subscriber Blockchain Miner

RegisterPublisher (PubID PubAddress)Mine Transaction

AddSensor (SensorInfo)

Mine Transaction

RegisterSubscriber (SibId SubAddressMine Transaction

RegisterToSensor (PubID PubAddress SensorInfo)

Mine Transaction

Notify(PubID SubAddress)Generate NewData

StoreData(NewData) ampamp GenerateHash()

Mine Transaction

Notify(PubID SubAddress HashPointer)

Figure 5 Sequence diagram of the Publisher-Subscriber protocol implemented on the blockchain

able to interpret the received ECG data In this case heartmeasurements should be sampled and sent at high rate Thisis not true for all types of physiological signals For instance itis not critical tomeasure body temperature at high frequencyThus changing the sampling rate of the ECG signal withouta careful validation from doctors may not be good for anaccurate interpretation of the data Therefore we consider inthis work the mining time as the main performance metric toevaluate the performance of our proposed system

Let119873119889 be the number of devices connected to a publisherLet 119903119889 be the rate of IoT device data generation and

consequently the associated rate of generation of new blocksin the blockchain

The total data rate generated by one publisher that has119873119889associated IoT devices assuming that all the devices have thesame data rate 119903119889 is equal to119873119889times119903119889 sample of data per second

Each new data will generate a new transaction which inturn will trigger the mining of a new block in the blockchainIn this case the mining rate will depend on the block size119873119905and the time to mine the generated block 119879119887 The block sizedepends itself on the number of transactions one block canfit it varies indeed from one blockchain platform to anotherAs previously indicated Bitcoin uses a fixed size for its blockwhile Ethereum uses a variable size

In this context the mining rate will correspond to thefraction119873119905119879119887 bps There are two possible cases the first oneis when the generated data rate from the publisher is lowerthan the mining rate and the second case is when it is higherThe maximum delay time for each case is formulated is thefollowing

Case 1 Max Delay = 119879119887 if 119873119889 times 119903119889 le 119873119905119879119887 Case 2 MaxDelay =119873119887 times 119879119887 where119873119887 is the number of necessary blocksto accommodate all transactions if119873119889 times 119903119889 ge 119873119905119879119887

119873119887 can be calculated supposing t=1s119873119887 = (119873119889 times 119903119889)119873119905

In the same way this can be generalized to all thegenerated data from all publishers We obtain the followingformulation

119873119875

sum119899=1

119873119875119889 119894 times 119903119875119889 119894 ge

119873119905119879119887

(1)

In this formulation we did not take into account thework andtime taken by the subscriber and the publisher for their ownoperationsWe consider indeed that these times are negligiblecomparing to the mining time which constitutes the mostimportant part of the delay

6 Implementation of the Solution

To implement our solution we have chosen to use aframework called Embark [24] This framework is basedon the concept of decentralized applications (DApps) andwas fitting our technical requirements Embark frameworkimplements the Ethereum blockchain IPFS database andWhisper protocol used to send messages between multipleDApps We have chosen to use the GoEthereum (geth)client along with SolidityC [25] language for smart contractsprogramming HTML Javascript and JQuery langages havebeen used to program the frontend and the GUI We havesuccessfully implemented our private blockchain as well asthe notification smart contracts We have considered twotypes of nodes a laptop and a Raspberry Pi We havesuccessfully connected both of gateways to the blockchainThe Raspberry Pi permits to generate real data from itsembedded sensors

Technical Details In this section we discuss the settings ofthe system and the implementation details of the testbed

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 9: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Wireless Communications and Mobile Computing 9

Subscriber

Rasberry Pi3 (Thing)

IoT Blockchain

Subscriber

Blockchain Publisher

Figure 6 Testbed composed of a Raspberry Pi 3 as the publisher to the blockchain and a laptop as a subscriber to the blockchain

Figure 6 shows our testbed that is composed of two nodesa Raspberry Pi acting as a passive publisher (ie it is not aminer node) and the laptop acting as a subscriber as well as aminer for the blockchain To validate the system architecturewe have implemented the scenario presented in Figure 5Thescenario involves first a publisher that registers to the systemThe registration of the publisher suffices providing its namesince the Ethereum address is automatically fetched using theldquomsgsenderrdquo function Once the publisher is registered Thesystem identify the list of sensors provided by this particularpublisher For that an advertising protocol is used (it is acore function in the proposed pub-submodel) The sensor ismodeled in the publisher contract as a record of two variablesthe sensor ID and the sensor type Once the publisher andits sensors are registered to the blockchain any subscriberconnecting to the blockchain can discover the publisher andit sensors In the general case when a particular subscriberregisters to the system it is possible for it to discover allthe available publishers via this particular subscriber as wellas their provided sensing capabilities It is then possible fora subscriber to subscribe to any of these publishers if it isauthorized If successfull the address of the subscriber isadded to the publisherrsquos contract

Once new data is generated from any of the sensorsassociated with a publisher the gateway stores it in the IPFSstorage and sends a broadcast message to the blockchaincontaining a hash pointing to the location where the datais stored When the notification is received by a particularsubscriber (in our testbed the laptop) its frontend modulechecks its contract that contains all the publishersrsquo addressesto verify whether this publisher is among its associatedpublishers list If the notification source address does exist inthe list then the notification is accepted otherwise it is filtered

The implementation of the system behavior was challeng-ing since SolidityC was not completely mature many featureswere not yet implemented at the implementation time Toverify that the GUI was working properly we have performedseveral tests using the Embark dashboard

The different steps of the system implementation anddeployment are the following

(i) Setting up the private blockchain using Geth

(ii) Configuring the laptop and the Raspberry Pi andconnecting them to the blockchain

(iii) Programming the proposed smart contracts modelusing SolidityC

(iv) Deploying the contracts on the blockchain(v) Programming the subscriberrsquos frontend (the HTML

webpage)(vi) Programming the backend (Javascript to link the

smart contracts and the frontend)(vii) Configuring IPFS off-chain database(viii) Connecting all the elements using Embark frame-

work

The implementation details of the different steps aredescribed as follows the first step to implement the systemwas to create a private blockchain to ease testing and exper-imentation For that we have used Geth (the command lineinterface for running a full Ethereum node implemented inGo) to create the Genesis file (the Genesis block is the firstblock in the blockchain) which is a Json file After creatingthe Genesis file we have specified some properties of theblockchain such as identity rpcport port data directoryand network Id The next step was to test the blockchainby adding peers connecting them to the blockchain andsending Ethereummessages tomake sure that the blockchainwas working properly Thanks are due to the Geth Javascriptconsole and the Geth functions which allowed us to testthe blockchain Once the blockchain created the followingstep was to create and deploy smart contracts As previouslystated we have specified the contracts described in Section 5and then used the SolidityC compiler to generate them Aftersuccessfully setting up the private blockchain and deployingthe smart contracts the backend was eventually completeThe next step was the deployment of GUI ie the frontendof the DApp The implemented frontend is composed ofdifferent files html Javascript and css files for the portalwebpage and its interactions along with several Embarkconfiguration files The visible part of the GUI is the portalwebpage running on a webserver executed in the laptop Awebserver configuration file was also available in Embark

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 10: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

10 Wireless Communications and Mobile Computing

01234567

0 100 200 300 400 500

diffi

culty

val

ue

x 10

0000

00

number of blocks

Difficulty vs Nbr of Blocks

(a)

0 2 4 6 8 10 12Transaction par seconde (tps)

Mining Time Variation

Mining Time at low difficultyMining time at high difficulty

minus20000

2000400060008000

100001200014000

Min

ing

Tim

e (m

s)

(b)

Figure 7 Difficulty variation versus number of blocks and time variation versus transactions rate for different difficulty values

This environment was then used to deploy a blockchainstorage GUI the frontend and backend Finally we deployedthe IPFS database and connected it to the private blockchainAll peers could then connect to the blockchain and storedata in the IPFS off-chain database This has completed theimplementation and the deployment of the testbed

Tests and Results Before presenting the results of the testswe will first present the key parameters of a blockchain

(i) Number of transactions per block It is calculated asthe block size divided by the average transaction sizeIn fact the number of transactions in a block in theEthereum blockchain can reach 2200 transactions perblock as a maximum value and 1050 transactions perblock as a minimum value [26]

(ii) Transaction throughput which depends on two mainvalues the block size and the expected time intervalbetween blocks

(iii) Block time mining time or the time needed tovalidate a block

(iv) Number of transactions per second (tps)

We have evaluated the variation of the mining timeagainst the blockchain scaleThis was achieved by varying thenumber of transactions per second (tps)

The difficulty level parameter of the Ethereum blockchain(ie level of difficulty to mine blocks) [26] is directly relatedto the mining time In fact the difficulty is a scalar valuecorresponding to the difficulty level applied during the noncediscovery of the processed block It defines the mining targetwhich can be calculated from the previous blocks difficultylevel and the timestamp The higher the difficulty is thestatistically the more calculations a miner must perform todiscover a valid block This value is used to control the blockgeneration time of a blockchain keeping the block generationfrequency within a target range In our testbed we havekept this value intentionally low to avoid waiting too longduring tests Indeed since the discovery of a valid blockis required to execute a transaction on the blockchain the

overall operation can take a lot of time We have made ourtests when the difficulty value was low and after a certaintime we have conducted other tests when the difficulty valuehas increased to high values In Bitcoin the average expectedsystem throughput value is 175 tps It is worth noting thatthe miner actually the laptop has the following technicalconfiguration in this testbed Intel(R) Core(TM) i7-2670QMCPU 220GHz 800GB RAM 64 bit OS

Figure 7(a) shows the variation of the difficulty valueversus the number of blocks Actually the difficulty increaseslinearly with the number of blocks which is a propertyknown for the blockchain however Figure 7(b) shows that themining time increaseing exponentially with the rate of thetransaction (ie number of transactions per second) whichis also inherent to the blockchain behavior since more trans-actions the blockchain needs to process per second higherthe processing capacity is required from the blockchainMiners The following Figure highlights also the difficultyvalue increases the mining time increases significantly whichis also a characteristic of the blockchain that impacts oursolution Therefore there is need to find the right tradeoffbetween the difficulty level and the target response time ofthe system which will be perceived by the end-users

7 Conclusion and Future Works

The objective of this work was to consider the possibilityof using blockchain technology in the area of IoT dataaccess protection with a possible application in the eHealtharea with the protection of personal medical informationcollected from medical sensors and environmental sensorsin smart homes We have proposed an architecture of asolution designed for that purpose that is based on contractsbetween providers and consumers of data To cope with thesize of the data to store we have proposed to associate theblockchain with an off-chain database The block contains themain contract information as well as reference to where thecomplete data is storedWehave also discussed and presentedthe performance of such a system and the parameters thatmay have an impact on the time to process the transactions

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 11: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

Wireless Communications and Mobile Computing 11

We have implemented the system in a testbed and conductedsome tests to validate the behavior of the system componentsWe have shown that existing technologies have permittedto implement the proposed architecture Finally we haveperformed some performance measurement of the system tohighlight how the system response time (mining time) variesagainst the rate of the transactions that is an important factorto consider when deploying such a system in eHealth realmIn our future work we aim to extend the system to work on apublic blockchain and conduct large scale evaluations

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This research was supported by the University of EvryVal dEssonne and by the Lebanese University and CNRSLebanon Part of this work was also conducted in the frame ofthe PHC CEDRE Project N37319SK The authors also thanktheir colleague Dr Massum Hasan for the early discussionson the topic

References

[1] S H Hashemi F Faghri P Rausch and R H CampbellldquoWorld of empowered IoT usersrdquo in Proceedings of the 1stIEEE International Conference on Internet-of-Things Design andImplementation IoTDI 2016 pp 13ndash24 Berlin Germany April2016

[2] N Nakamoto ldquoA Peer-to-Peer Electronic Cash Systemrdquo 2008httpsbitcoinorgbitcoinpdf

[3] F Tschorsch and B Scheuermann ldquoBitcoin and beyond Atechnical survey on decentralized digital currenciesrdquo IEEECommunications Surveys amp Tutorials vol 18 no 3 pp 2084ndash2123 2016

[4] Nick Szabo The Idea of Smart Contracts httpwwwfonhumuvanlrobCoursesInformationInSpeechCDROMLiteratureLOTwinterschool2006szabobestvwhnetideahtml

[5] N Nakamoto ldquoBitcoin A peer-to-peer electronic cash systemrdquo2008 httpbitcoinorgbitcoinpdf

[6] M E Peck ldquoBlockchains How they work and why theyrsquollchange the worldrdquo IEEE Spectrum vol 54 no 10 pp 26ndash352017

[7] A Judmayer N Stifter K Krombholz and E Weippl ldquoBlocksand Chains Introduction to Bitcoin Cryptocurrencies andTheir Consensus Mechanismsrdquo Synthesis Lectures on Informa-tion Security Privacy and Trust vol 9 no 1 pp 1ndash123 2017

[8] ldquoEthereum homestead documentationrdquo httpwwwethdocsorgenlatest

[9] N Atzei M Bartoletti and T Cimoli ldquoA Survey of Attacks onEthereum Smart Contracts (SoK)rdquo in Principles of Security andTrust vol 10204 of Lecture Notes in Computer Science pp 164ndash186 Springer Berlin Germany 2017

[10] M Mettler ldquoBlockchain technology in healthcare The revolu-tion starts hererdquo in Proceedings of the 18th IEEE InternationalConference on e-Health Networking Applications and ServicesHealthcom 2016 Munich Germany September 2016

[11] A Azaria A Ekblaw T Vieira and A Lippman ldquoMedRecUsing blockchain for medical data access and permission man-agementrdquo in Proceedings of the 2nd International Conference onOpen and Big Data OBD rsquo16 pp 25ndash30Vienna Austria August2016

[12] K Christidis and M Devetsikiotis ldquoBlockchains and SmartContracts for the Internet of Thingsrdquo IEEE Access vol 4 pp2292ndash2303 2016

[13] J Zhang N Xue and X Huang ldquoA Secure System for PervasiveSocial Network-Based Healthcarerdquo IEEE Access vol 4 pp9239ndash9250 2016

[14] G Zyskind O Nathan and A S Pentland ldquoDecentralizing pri-vacy Using blockchain to protect personal datardquo in Proceedingsof the IEEE Security and PrivacyWorkshops SPW 2015 pp 180ndash184 San Jose Calif USA May 2015

[15] M Y Jung and J W Jang ldquoData management and searchingsystem and method to provide increased security for IoTplatformrdquo in Proceedings of the 2017 International Conferenceon Information and Communication Technology Convergence(ICTC) pp 873ndash878 Jeju South Korea October 2017

[16] C-F Liao S-W Bao C-J Cheng and K Chen ldquoOn designissues and architectural styles for blockchain-driven IoT ser-vicesrdquo in Proceedings of the 4th IEEE International Conferenceon Consumer Electronics - Taiwan ICCE-TW 2017 pp 351-352Taipei Taiwan June 2017

[17] F Angeletti I Chatzigiannakis and A Vitaletti ldquoThe role ofblockchain and IoT in recruiting participants for digital clinicaltrialsrdquo in Proceedings of the 25th International Conference onSoftware Telecommunications and Computer Networks Soft-COM 2017 Split Croatia September 2017

[18] A Dorri S S Kanhere R Jurdak and P GauravaramldquoBlockchain for IoT security and privacy The case study ofa smart homerdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 618ndash623 Kona HawaiiUSA March 2017

[19] N Rifi N Agoulmine N Chendeb Taher and E RachkidildquoTowards using blockchain technology for data access manage-mentrdquo in Proceedings of the IEEE 17th International Conferenceon Ubiquitous Wireless Broadband (ICUWB Conference) 2017

[20] ldquoMining in Bitcoinrdquo httpsenbitcoinitwikiMining[21] IPFS ldquoContentAddressed Versioned P2P File Systemrdquo https

ipfsiodocs[22] ldquoEthereumwhitepaperrdquo httpsgithubcomethereumwikiwiki

White-Paper[23] J A Dev ldquoBitcoin mining acceleration and performance

quantificationrdquo in Proceedings of the 2014 IEEE 27th CanadianConference on Electrical and Computer Engineering CCECE2014 Toronto Canada May 2014

[24] ldquoEmbark frameworkrdquo httpsgithubcomiurimatiasembark-framework

[25] Solidity Introduction to Smart Contracts httpsolidityread-thedocsioendevelopintroduction-to-smartcontractshtml

[26] ldquoEthereum charts and statisticsrdquo httpsetherscaniocharts

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 12: Blockchain Technology: Is It a Good Candidate for …downloads.hindawi.com/journals/wcmc/2018/9763937.pdfBlockchain Technology: Is It a Good Candidate for Securing IoT Sensitive Medical

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom