Ben-Gurion University of the Negev
Masters’s Thesis
Incentivized Delivery Network of IoT Software Updates using gradual release
Submitted By: Supervisor:
Yechiav Yitzchak Prof. Asaf Shabtai
A thesis submitted in fulfillment of the requirements for
the degree of Master of Science
in the
DEPARTMENT OF SOFTWARE AND INFORMATION SYSTEMS
ENGINEERING
FACULTY OF ENGINEERING SCIENCES
February 27, 2019
Ben-Gurion University of the Negev
Masters’s Thesis
Incentivized Delivery Network of IoT Software Updates using gradual release
Submitted By: Supervisor:
Yechiav Yitzchak Prof. Asaf Shabtai
A thesis submitted in fulfillment of the requirements for
the degree of Master of Science
in the
DEPARTMENT OF SOFTWARE AND INFORMATION SYSTEMS
ENGINEERING FACULTY OF ENGINEERING SCIENCES
Author: ...... Date ...... 27.2.2019 Suprvisor: ...... Date ...... 06/05/2020 Chairman of Graduate Studies Committee: ……………………..Date…… Abstract this work introduces IoTPatchPool Pay Per Piece -aschemethatenablesanincen- tivized distributed delivery network of IoT software updates. the scheme uses a decentralized storage network for reducing the load on the vendor when distributing patches towards IoT devices and eliminating central points of failure. Unlike existing peer-to-peer file-sharing networks that have a fundamental availability problem for unpopular files, our protocol utilizes blockchain-based smart contracts to incentivize independent peers, termed distributors, by means of cryptocurrency payments. A vendor of IoT devices deploys a smart contract with a deposit, which acts as a publicly verifiable binding bid for delivery of patches by pieces to a specific set of IoT endpoints. Distributors will compete for delivering updates to the desired IoT devices in exchange for cryptocurrency payments. We address the fair exchange problem between distributors and the consuming IoT devices by utilizing aa Pay Per Piece Payments protocol, the pay per piece is a form of a gradual release of a commodity where the commodity can be divided into small piece the sender and the receiver build trust as the transactions progress in rounds the permission-less nature of the framework can encourage the participation of a large number of dis- tributors, and thus facilitate a rapid scale-out of the system. Finally, we present and evaluate a prototype implementation combining the BitTorrent network with the cryptocurrency Ethereum. Keywords
IoT
Blockchain
Patch Update
Distributed ledger
Ethereum
Incentivized system
2 Acknowledgments
would like to thank several people for supporting me in the work on this thesis. First, I would like to express my appreciation to my supervisor Prof. Asaf Shabtai, for the guidance, support, and brainstorming, he has given me all along this thesis. IwouldliketothankRonBitonforhissupportthroughoutthisprocessin consulting, examining new paths, and pushing the boundaries. Second, I would like to thank all my colleagues who I worked the framework leading to this thesis, Oded Leiba, Ron Biton, Asaf Nadler, Davidoz Kashi, and Ishai Wiesner. Third, I would like to thank Zur Ronen for his help and support in implementation. lastly many thanks to Telekom Innovation Laboratories at Ben-Gurion University for providing the supporting environment. 2 Contents
Abbreviations 8
1Introduction 9
1.1 Background ...... 13
1.1.1 Blockchain ...... 13
1.1.2 Smart Contracts ...... 14
1.1.3 zk-SNARKs ...... 15
1.1.4 Zero-Knowledge Contingent Payments (ZKCP) ...... 16
1.1.5 Gradual release ...... 16
2ResearchObjectives 18
2.1 Research Goal ...... 18
2.2 Research Questions ...... 19
2.2.1 RQ1: Defining a incentivized IoT patching protocol ...... 19
2.2.2 RQ2: Examining The economic model of the system ..... 19
3RelatedWork 20
3.1 General Architectures for IoT Patching ...... 20
3.2 Decentralized Storage Networks ...... 22
4SecurityModel 25
4.1 Trust Model ...... 25
4.2 Adversarial Model ...... 26
4.3 Goals ...... 26
3 5TheMainComponents 27
5.1 Decentralized storage network (DSN) ...... 27
5.2 Blockchain network ...... 28
5.2.1 Vendor nodes ...... 28
5.2.2 IoT nodes ...... 29
5.2.3 Distributor nodes ...... 30
6IoTPatchPool 32
6.1 Protocol ...... 33
6.1.1 Setup ...... 34
6.1.2 Contract publication ...... 34
6.1.3 Update file initial seeding ...... 36
6.1.4 Update file exchange for a proof-of-distribution ...... 37
6.1.5 Reward claim for a proof-of-distribution ...... 39
6.2 Properties ...... 40
6.3 Implementation ...... 43
7Proposedframework:IoTPatchPoolPayperpiece 47
7.1 Alternative selection ...... 49
7.2 Protocol ...... 51
7.2.1 Setup ...... 51
7.2.2 Contract publication ...... 51
7.2.3 Update file initial seeding ...... 52
7.2.4 Update file Pay Per Piece exchange ...... 54
7.2.5 Reward claiming ...... 55
7.3 Implementation ...... 57
7.4 Evaluation ...... 58
7.4.1 Properties ...... 60
8Discussion 62
8.1 Common Requirements ...... 62
4 8.2 Comparison ...... 63 8.3 Economic Feasibility Analysis ...... 69
9ConclusionsandFutureWork 73
5 List of Figures
6.1 IOTPatchpool High level architecture overview ...... 33 6.2 IOTPatchpool High level overview of the update protocol .. 40 6.3 IOTPatchpool: Outline of the IoT software update protocol 41 6.4 IOTPatchpool: The board used for our demonstration environment, consisting of 48 Raspberry Pi devices...... 45 6.5 IOTPatchpool: A screenshot capturing the user interface of the ven- dor’s server during the update process...... 45
7.1 IoTPatchPool Pay Per Piece High level architecture overview 49 7.2 IoTPatchPool Pay Per Piece sequence diagram ...... 56
8.1 Gas consumption comparison ...... 65 8.2 Time (sec) to execute a Redeem transaction the Rinkeby Test net ...... 67 8.3 time to execute first device update.timeinsecondsforupdating first device on both frameworks, IoTPatchPool on top part and IoTPatchPool Pay Per Piece on bottom part ...... 68 8.4 time to complete 100 IoT devices update.timeinsecondsfor completing 100 devices update, IoTPatchPool on top part and IoTPatchPool Pay Per Piece on bottom part ...... 68 8.5 Frameworks economic feasibility compared to alternatives ...... 72
6 List of Tables
8.1 Comparison between the IoTPatchPool and IoTPatchPool PPP frame- works ...... 64 8.2 Summary of the main items and their size in both frameworks .... 68 8.3 A breakdown of the transactions costs ...... 71
7 Abbreviations
DHT Distributed hash table DOS Denial of service DSN Decentralized storage network
ECDSA Elliptic Curve Digital Signature Algorithm EVM Ethereum Virtual Machine
IOT Internet Of Things IPFS InterPlanetary File System
P2P Peer to Peer PPP Pay Per Piece
ZCKP Zero-Knowledge Contingent Payment
8 Chapter 1
Introduction
The Internet of Things (IoT) is a disruptive paradigm that continues to evolve. It is predicted that there will be a total of 26 billion connected IoT units by 2020.1 The prevalence of these devices makes them an ideal target for attackers, recently many high impact exploits have been demonstrated in practice [1, 2]. In order to de- fend devices from such vulnerabilities or recover from attacks, they must be patched with security updates. Concerns have been raised by users and manufacture alike that this need is often overlooked, and in practice, devices are patched much more rarely than they should [3]. This is in large part due to the slim profit margins of IoT manufacturers, and operational difficulties associated with the large-scale patching of devices. Another concern around the traditional way to distribute con- tent and in particular IoT software updates is the centralized nature of client-server architectures which typically rely on a large geographically and/or organizationally centralized cloud service. The increased amount of IoT devices and sensors, with their respective large amounts of data they broadcast and consume, can put a signif- icant burden on ISPs, inter-ISP business relationships, and the Internet backbone. Therefore, recent researches focused on shifting computation and data throughput to the edge, so that a large part of the data exchange can be performed within the boundaries of single ISPs [4, 5]. Moreover, such architectures impose large central points of failure and are subject to vulnerabilities such as natural disasters or local
1https://www.gartner.com/newsroom/id/3598917
9 outages. For instance, Amazon Web Services (AWS) control around 40% of the cloud-server market, and a recent outage in its US-East-1 region (Ashburn) caused asignificantportionofthewebtobeoffline[6]. Nonetheless, cloud servers dis- persed over multiple regions do not completely solve the problem, as these are still vulnerable to organizational faults and human errors.
Given these difficulties, peer-to-peer file sharing methodologies can be used to optimize content delivery in general and patch delivery in particular. Examples of such networks include Gnutella [7], BitTorrent [8], and IPFS [9], which have gained significant traction in recent years. There have been several recent cases of enter- prises and organizations using peer-to-peer file-sharing networks to achieve improved scalability and reduce costs. Microsoft utilized such architecture for Windows 10 updates [10], Spotify reduced its hosting costs by 88% by using peer-to-peer sharing in its early days [11], Twitter used BitTorrent to speed up servers deployment [12] and Amazon S3 service offers developers to upload hosted files via the BitTorrent network (i.e., seed)asapotentiallycheaperalternativetoclient-serverdistribution [13]. However, such attempts may suffer from a lack of cooperation among indepen- dent Internet peers. In addition, the use of such networks may harm a company’s reputation damage due to the abusive nature of having clients’ software wasting resources by default. Moreover, in the context of IoT devices, such resources are typically limited.
In this work, we propose a decentralized and incentivized IoT updates delivery network based on trustless and permissionless protocol first we will describe in-depth the preceding work IOTpatchpool [14], and later present the IOTpatchpool Pay Per Piece.bothframeworksharemanycomponentsincommonbytheaddressingthefair exchange, while the first addressed this by providing a "Proof-of-distribution" the later make use of the concept of gradual release, An ability to divide the commodity and exchange between sender and receiver is done in rounds wherein each the trust between participants grows.
Within this framework, participating nodes (i.e., distributors) are compensated
10 with cryptocurrency payments for delivering software updates to IoT devices. More specifically, when a new security update is released, a vendor will issue a bid, offering to compensate (with cryptocurrency) distributors who deliver the update or part of it. The agreement is bound by a smart contract, making it publicly verifiable and irreversible. This guarantees compensation to the first distributor that provides a signature by IoT device ensuring the delivery of the patch Eliminating the need for trust between the software update distributor and the consumer (the IoT device or the vendor) by providing fair exchange, can encour- age competition and significantly increase the number of distributors and overall efficiency, thus allowing rapid scale-out. In summary, the main contributions of the proposed framework are as follows.
Essential security features. IoTPatchPool Pay Per Piece utilizes blockchain • as a publicly verifiable incentives layer that encourages competition among in- dependent non-trusted distributors. Therefore, the proposed framework elim- inates single points of failure and increases overall network availability com- pared to current client-server architectures. The proposed framework achieves a fair exchange scheme between consum- ing IoT devices and distributors. In contrast to other attempts utilizing blockchain, our framework does not require that IoT devices continuously hold and manage cryptocurrency hot wallets with sufficient funds. Finally, the pro- tocol ensures the integrity of the transferred content, so it can be verified by the receiving IoT nodes.
Common economic benefits. By using digital currency, the proposed • framework encourages public users to contribute their unused/idle comput- ing resources (e.g., storage, network bandwidth and CPU) for delivering secu- rity updates to IoT devices. Usually these resources can be utilized at a lower price than dedicated cloud-based services and content delivery networks. Con- sequently, the proposed framework contributes to the overall social welfare.
11 Programmable incentivization. The proposed framework supports differ- • ent distribution policies of software updates; i.e., it can be adapted to prioritize software updates differently through minor adjustments to the smart contract. For example, vendors can decide to push forward specific critical security up- dates or prioritize specific IoT clients.
12 1.1 Background
In this section, we introduce the technologies utilized in IoTPatchPool Pay Per Piece, providing the necessary background to understand the protocol and its analysis.
1.1.1 Blockchain
Blockchain was introduced along with Bitcoin in Satoshi Nakamoto’s white pa- per [15]. A blockchain is essentially a distributed data structure that can be regarded as a public ledger where groups of messages are stacked one on top of the other. These groups of messages are named "blocks" and with the use of digital signatures and a distributed consensus algorithm, users in a non-synchronous configuration (i.e., do not necessarily agree on the time and order of messages) can irreversibly agree, with high probability, on a specific block order.
Agreement on the order of blocks is useful for the prevention of currency "double- spend" (where messages within the blocks correspond to value transfer transactions), as the later spending can be mutually eliminated by the users, and is therefore the foundation for Bitcoin and various other cryptocurrencies [16].
Concretely, each transaction message within a block contains the coin transfer value, the redeem terms, an input transaction and the signature of the transaction’s author for authenticity. The redeem terms can be referred to as a Boolean predicate such that only a true evaluation can make use of the transaction. Because published transactions are part of a block, they are irreversible, and thus redeem terms can serve to vouch for coin in exchange for a truth assignment, which is the foundation of "smart contracts".
Light clients. In general, blockchain nodes may fulfill different roles (which are not mutually exclusive): serving as a wallet, a full-node which keeps a full copy of the blockchain, a network routing node (i.e., can send, receive and verify trans- actions) or a miner. A light client is a specific class of blockchain nodes, which typically functions as both a wallet and a network routing node. Such lightweight
13 clients connect to random nodes in the network with a purpose of allowing users to download only block headers as they appear, while fetching other parts of the blockchain on-demand. This relaxes resource requirements significantly, and enables them to be confident that the data is correct, provided that the majority of miners are following the protocol correctly and at least one honest verifying full node exists and serves the accurate blockchain state. In Ethereum, this type of protocol is un- der development and currently available in a less trustless setting 2.Recentresearch suggested a super-efficient light client [17]bybuildingonNon-Interactive Proofs of Proof-of-Work [18] which could require just a soft-fork to existing blockchain protocols, and enable verification of a specific blockchain property requiring only resources logarithmic in the length of the blockchain. The study experimented that such implementation on top of the Ethereum blockchain, will consume only a small number of Megabytes of storage.
1.1.2 Smart Contracts
Asmartcontract[19]isanautonomouscodethatcanenforcetheexecutionof specific terms without the need for intermediaries. In the context of blockchain- based cryptocurrencies, a smart contract is realized with a persistent script and replicated on the system of all nodes holding and running the distributed ledger, supervised and checked by them. Smart contracts don’t differ from any other kind of transaction and are primarily named likewise when used with redeem or execution terms that are more complex than verifying the receiver’s identity. However, the contextual notion of being addressed to anyone who qualifies to specific terms instead of a specific address, makes smart contracts valuable to nodes who wish to satisfy these terms and collect the value.
The features of blockchain-based smart contracts evolved from the Bitcoin script- ing language that is a simple, stack-based, and purposefully non-Turing complete,
2https://github.com/ethereum/wiki/wiki/Light-client-protocol
14 to a new blockchain paradigm initiated with Ethereum [20] which offers Turing- complete stateful languages for writing smart contracts. The most widely adopted example of such a language used for developing smart contracts in Ethereum is So- lidity which is a statically typed JavaScript-like language. Ethereum Classic and Rootstock [21] are other examples of blockchain platforms offering equivalent smart contract capabilities. Hereafter, the use of the term smart contracts in this thesis refers to the Ethereum implementation.
1.1.3 zk-SNARKs
Zero-Knowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs) [22, 23, 24, 25, 26] is an efficient proof system for proving and verifying zero-knowledge proofs. Informally, it allows a prover to convince a verifier that he/she possesses knowledge of a secret parameter, called a witness, satisfying certain properties, with- out revealing anything other than the correctness of the statement to the verifier or anyone else. For example, a prover can convince a verifier that the prover has knowledge of a secret w which is the hash preimage of some value x, without leaking any information about w. Because zk-SNARKs are succinct,proofsareveryshort and easy to verify.
More formally, let L be an NP language and C be a decision circuit for L.Atrusted party conducts a one-time setup phase that results in two public keys: a proving key pk and a verification key vk. The proving key pk allows any (untrusted) prover to generate a proof ⇡ attesting that x L for an instance x of her choice. The 2 non-interactive proof ⇡ is both zero-knowledge and proof-of-knowledge. The proof ⇡ has a constant size and can be verified in time that is linear in x . | | A zk-SNARK for circuit satisfiability consists of the following three polynomial- time algorithms
(Gen, Prove, Verify)
Gen(1 ,C) (pk, vk).Onsecurityparameter and a decision circuit C,the • ! Gen algorithm probabilistically samples pk and vk.Bothkeysarepublished
15 as public parameters and can be used to prove/verify membership in LC .
Prove(pk, x, w) ⇡.Oninputprovingkeypk,instancex, and witness for the • ! NP statement w,theprover Prove outputs a non-interactive proof ⇡ for the
statement x LC . 2
Verify(vk, x, ⇡) 0, 1 .Oninputverifyingkeyvk,aninstancex,andaproof • !{ }
⇡,theverifier Verify outputs 1 if x LC . 2
1.1.4 Zero-Knowledge Contingent Payments (ZKCP)
ZKCP [27] consists of a two-party protocol that allows the fair exchange of a digital commodity for a cryptocurrency payment in a setting where the two parties do not trust each other to deliver, and a distributed ledger replaces a trusted third party. ZKCP are powerful also because they are very flexible: they typically keep proving and verifying complexity off-chain (external to the distributed ledger), and eventually result in a relatively simple transaction sent to the blockchain. This allows a flexible class of conditional payments while the burden on the blockchain is independent of the complexity of the proof scheme conducted between the two parties, without requiring changes in the scripting capabilities of even a limited language such as Bitcoin Script [28]. Their first implementation (for exchanging bitcoins for a Sudoku solution) was presented in [29].
1.1.5 Gradual release
The subject of fair exchange aims to reach fairness between two or more partici- pates involved in a transfer of a certain commodity. the most common solution is the trusted third party protocol (TTP), where two parties participate in the ex- change and a third party oversees every exchange. TTP is a secure way to offer fairness to both parties but the use third party is costly. Pagnia et el [30]proved that any exchange between two parties is impossible without a trusted third party and as mentioned above, the ZCKP is a form of third party mediator between the
16 participating parties. [31] offered another approach to this problem by using an optimistic approach where the assumption is that most participants are honest and in order to reduce costs the TTP will be initiated only in the case of a dispute. the gradual release protocol is another direction and was first coined by [32]and offered a way to exchange goods where the commodities can be partitioned. the idea is that exchange will be completed in rounds where in each round the sender provide a portion of the good and the receiver validates the payment for the part. this method requires both participates to have the same computational powers, to pervert one party to abort the transfer between rounds and brute force the remain- ing information. the ability to split the commodity into pieces reduces the risk for each participates for only a fraction of the value at stake allows for building more trust as the transfer progresses.
17 Chapter 2
Research Objectives
2.1 Research Goal
Distributed computing is a science where computing resources, including the pro- cessing power, storage, and network of individuals or organization can be harnessed in addition to the processing unit’s primary use. one can choose to utilize the unit’s storage and network for seeding torrent files for the beneficial use of other individ- uals. other can choose the utilizing processing power in mining cryptocurrencies in the chance to gain cryptocurrency wealth, users can donate their computing powers to promote science (e.g IBM GRID project 1)oraidinsearchforextraterrestrial intelligence through Berkeley’s SETI@home 2. the goal of this work is to advise a framework of preforming an IoT patch update by permission-less individuals. validate the framework and prove the proprieties of such framework
1https://www.worldcommunitygrid.org 2https://setiathome.berkeley.edu
18 2.2 Research Questions
2.2.1 RQ1: Defining a incentivized IoT patching protocol
The rise of cryptocurrencies enables the incentivizing of any computational resource the main research question will be defining a protocol for IoT patching where a de- centralized network of permission-less individuals will participate in software update delivery. the proposed framework should keep to the standards of existing software update delivery systems where availability, scalability confidentiality is kept. as a decentralized system, the system should be trust-less, where trust-less entities can use their available resources to participate in the network.
2.2.2 RQ2: Examining The economic model of the system
The proposed system falls under two topics in the research, the first, software up- date delivery system. as a patch delivery system, it should be examined in light of the industry standards, the main principals, among others, are CIA; confidential- ity, integrity, and availability, the second is under the distributed computing and incentivized distributed computing. the economic model of the system should pro- vide proof that the proposed system is, in fact, attractive for the distributors and cost-saving for the vendor’s nodes, in the case, it is not attractive for participates, what are the improvements needed to become economically feasible. we would like to evaluate and asses the estimated profit of such protocol compared to a known set of incentivized distributed computing systems.
19 Chapter 3
Related Work
This work falls within the following domains: IoT devices patching and decentralized storage networks (also known as peer-to-peer file sharing networks) and is a progress of the the work described in [14]andpresentedhereaswell.wementionthenovelty of the work for each of the two categories below.
3.1 General Architectures for IoT Patching
Prior to the Internet of Things (IoT) era, traditional host-centric IT solutions fo- cused on delivering security updates (i.e., patches) by self-hosting the binary updates to make them retrievable and available to clients. As the number of clients increases, the availability and reliability of such solutions may require complex server infras- tructure and experienced IT personnel, thus making it very expensive for software providers. Several studies targeted the availability and reliability challenges, in- cluding Liu et al. [33] who suggested an IaaS solution to outsource infrastructure maintenance, and Zhen-hai and Yong-zhi [34] who suggested a Maven-based solution to increase effectiveness in cases of updates’ independence. These solutions were not designed for large numbers of deployed devices as in an IoT network. Following the rapid growth of IoT networks, the work of Yu et al. [35]addressesthechallenges of securing IoT devices with traditional security, host-centric IT solutions such as anti-virus and software patches. The diversity, cyber-physical coupling, and scale of
20 IoT devices, forces these security solutions toward a paradigm shift. Several works focused on the diversity by suggesting solutions for specific scenarios [36], and the issue of updating in a not-trustworthy setting where a device may already be in- fected [37, 38]. However, the above mentioned works do not address the scalability challenge.
Lee and Lee [39]proposedafirmwareupdateschemeinanIoTenvironment based on custom blockchain with a single-purpose block structure, combined with apeer-to-peerfilesharingnetworkasBitTorrentforthedistributionofupdates, to enhance availability, integrity and versions traceability of updates. This idea was improved by Boudguiga et al. [40] with the addition of trusted innocuousness checking nodes that are in charge of verifying the patch before it becomes available to deployed IoT devices.
Notably, both of the latter solutions acknowledged the challenges in uploading an entire software update file to the blockchain, hence delegated the distribution effort to off-chain approaches. Nonetheless, they provide no incentive for non-vendor nodes to join the network and contribute to the effort of distributing the software updates, and thus, may struggle with similar limitations as a centralized vendor network.
Lee [41]addressedthischallengeandproposedanincentive-basedframeworkon top of a blockchain ledger for IoT devices patch delivery. The author addressed the fair exchange problem by issuing a unique receipt per software delivery to ensure payment is done only to the distributor who performed the binaries transfer. This is achieved by a preceding key registration phase where distributors register their encrypting keys to the vendor, which is then trusted to follow the protocol and encrypt each update package with a different registered key. However, according to the proposed solution, the unique package property requires that the vendor will distribute different patches in the order of the number of IoT devices multiplied by the number of distributors. Consequently, the solution that the author proposed requires the same data transfer volumes (bandwidth consumption) by the vendors, compared to a centralized solution, and therefore does not benefit from the use of
21 distributed software delivery network. The contract creation per delivery results in costly blockchain transaction fees. In addition, the author’s solution relies on the ability of IoT devices to pay for their own software updates by using personal digital wallets. The use of digital wallets on IoT devices introduces new attack vectors and potential vulnerabilities to the software update solution. In addition, these digital wallets must be provided with sufficient balance (either by the vendors or device owners), which eventually results in additional, large number of preceding transactions that puts additional load on the blockchain.
Another approach worth mentioning is IOTA [42], a distributed micro-transactions ledger for IoT devices. IOTA is designed for the exchange of services among IoT devices (e.g., electricity for cooling), as opposed to IoT devices patching. Moreover, IOTA’s incentive mechanism is based on the need of a device to issue a service request and is therefore unfit for patch delivery.
In our proposed solution we extend the use of a blockchain-based network for IoT update delivery, and specifically address the issue of an incentive for providing the updates (by non-vendor nodes). In addition, the proposed solution eliminates the need for trust between the security update distributor and the consumer (IoT device), thus allowing rapid scale out.
3.2 Decentralized Storage Networks
Often referred to as peer-to-peer file sharing systems, decentralized storage networks are technologies for the sharing of digital media where distribution made using peer-to-peer networking. Imbalanced use (e.g., peers that avoid uploading) can dramatically reduce the availability of the network and its overall performance [43, 44]. Therefore, sharing incentivization is necessary. The first robust example of P2P file sharing incentivization mechanism is BitTorrent’s choking algorithm (a "tit for tat" exchange scheme) [8], in which a saturated uploader can decide to "choke" a peer which does not contribute any data to him.Although such mechanisms have been proven useful for popular content, they are much less useful for unpopular files
22 or niche markets. In the absence of enough seeders, this impacts the long term availability of a file [45].
Specifically, in the IoT patching use-case, we have a specific set of the relevant IoT devices which are interested in consuming the software updates, but it is not realistic to expect external independent peers to download this file and share it. Since IoT devices are typically resources constrained, we also reject the option of the IoT devices to share the content themselves. Proper incentivization in such setting may become more challenging. However, with the emergence of the blockchain technology that allows data and currency exchange in the absence of trust among its users, new forms of incentivization are unveiled. The most common incentive is digital currency compensation for either providing storage or bandwidth, which is the case for blockchain-based decentralized storage solutions such as Storj [46], Siacoin [47], Filecoin [48]andSwarm.1 2
All of the frameworks mentioned above rely on payment channels to fully support the trustless nature of the exchange of digital goods between the host and client. Such payment channel techniques (e.g., as been suggested in [49]and[50]) provide a protocol to perform micropayments on large scale with low transaction fees, but also introduce new requirements from the participants. These requirements may be challenging to meet/implement when considering a large number of IoT clients as the content consumers:
1. Preceding amount of on-chain transactions - each paying IoT device would first need to get funding, and open a payment channel with a separate preceding on-chain transaction. If a channel needs to be closed that will require another on-chain transaction. This amount of on-chain transactions will typically re- quire a large amount of data transfers (i.e., patches) in order to be eventually economically beneficial.
2. Devices would be required to hold hot wallets and lock funds.
1https://github.com/ethersphere/swarm 2Filecoin and Swarm are not yet operational, true to the time of this writing.
23 3. Participants are required to continuously watch the ledger or outsource this task to a trusted party for detecting disputes.
4. No atomicity - exchange schemes consider an asynchronous communication usually on the basis of a single file’s chunk, where one party first gives its own part in the trade (data or payment). This gives the second party an unfair advantage: it can cheat and abort the communication after receiving the first party’s part but without giving its own. Consequently, a malicious player can repeat this process multiple times (at least with different peers), by that exploiting the protocol for earning free goods without giving its own part.
In addition to these, price discovery and negotiation are usually delegated to the consumers themselves. When considering the option of a single smart contract deployed by a single party paying for the consumers, the vendor in our case, it can be easier to manage distribution pricing.
24 Chapter 4
Security Model
In this section we briefly go over the trust model we assume in relation to the participating players and the adversarial model. Then, with respect to these models, we lay down the security goals of our designed system.
4.1 Trust Model
Our scheme includes three types of participating actors: vendors, distributors and IoT objects. We assume that the IoT devices know their relevant vendor by its public key, and the distributors also have a list of public keys of relevant vendors. For the IoT devices, it can be realized by having the vendor embed its own public key onto the device before it is shipped. The way in which the distributors discover public keys of relevant vendors is out of scope of this thesis (it can be maintained by an external website publishing participating vendors, for instance). Similarly, we say that a vendor is aware of the list of its manufactured IoT devices’ public keys. The distributors are assumed to trust the vendor not to commit to a hash of a malicious file which may impact his machine, and the IoT devices are assumed to trust the vendor to commit to a valid software update. The distributors and the IoT devices can be mutually distrusting, and they may try to take advantage of the protocol and deviate from it as they may see beneficial.
25 4.2 Adversarial Model
In this work we consider the Dolev and Yao attacker model [51]. In this case an attacker can read, send and drop any transaction sent to the blockchain or any other network packet. In addition, the attacker can be a passive party eavesdropping on the network packets, or it can be active by injecting, replaying, or filtering any mes- sage to anyone of the parties involved.
4.3 Goals
Given the trust model and the adversarial model, the security goals of the system are:
1. Fair exchange -adistributorispaidonlyifhedeliversapatchtoanIoT device, and vice versa - an IoT device receives a patch only if the distributor is paid for it.
2. Patch integrity -thedeliveredupdatemustbevalid:passedasoriginally sent by the vendor without a distributor or any other party being able to alter it, and the consuming IoT device will be able to verify it.
3. Patch availability - an IoT will be able to consume a patch at any given time within the relevance time window determined by the vendor.
26 Chapter 5
The Main Components
In this section we outline the main components of the system and the requirements or assumptions regarding them.
5.1 Decentralized storage network (DSN)
We assume a decentralized storage network (DSN, or peer-to-peer file sharing net- work) in which routing data is accessible by all nodes (peers) in the network. Acces- sibility can be achieved with a trackerless peer discovery scheme, using a distributed hash table (DHT). We stress that such scheme does not impose significant resources requirements on each peer. This is because the necessary routing data, such as IP addresses of peers which announced themselves as holders of certain content, is dis- tributed between all network peers so each peer only holds a small fraction of the data. Possible instantiations of such a decentralize storage network are BitTorrent and IPFS. As a routing mechanism, both use Kademlia DHT [52]. Kademlia enables an efficient lookup queries which require a number of communication messages only logarithmic in the number of nodes in the network, while requiring low storage over- head for the participating peers. In addition, it is resistant to various attacks by preferring long-lived nodes. The connected DSN nodes can both consume and serve files. The set of DSN nodes
27 is denoted as follows: S = s ,...,s { 1 nS }
5.2 Blockchain network
The blockchain network must meet the following properties:
1. Permissionless - any interested party (e.g., an anonymous person, organization or company) can read and post messages on the blockchain network.
2. Support an intrinsic digital currency – i.e., the blockchain can be interpreted as a public ledger in which each party has a currency balance.
3. Support smart contracts (as described in Section 1.1.2).
At the time of this writing, Ethereum [20] is the most widely adopted example of such an open permissionless blockchain which also supports stateful smart contracts. We assume the underlying blockchain platform has double-spend prevention, i.e., no two contradicting transactions are accepted within the system’s eventual consensus, and has liveness - that is, all valid transactions propagated throughout the peer-to- peer network will eventually be processed within a period of time. We here refer to the blockchain nodes as the collection of nodes of any of the roles described in Section 1.1.1. The set of blockchain network nodes is denoted as:
B = b ,...,b { 1 nB }
5.2.1 Vendor nodes
Vendor nodes are host machines that are owned by manufacturers of IoT devices. All vendor nodes must participate in both the DSN and the blockchain network. For accessing the blockchain network, it is sufficient that the vendor node will be a light client as detailed in Section 1.1.1. The set of vendor nodes is denoted as:
V = v ,...,v { 1 m} 28 where V (S B) ⇢ \
Every vendor node, vi, must maintain the following:
1. asecret/publickeyspair(skvi ,pkvi ).
2. a list of its self-manufactured IoT devices public keys. Each device must have a unique pair of keys. This can be realized by having the vendor "burning" a new secret key into each new manufactured IoT device and adding the key to its list.
5.2.2 IoT nodes
IoT nodes are machines that require updates by their manufacturing vendor. All IoT nodes participate in both the DSN and the blockchain network. Within the blockchain network, IoT nodes must be able to function as a network routing node. To emphasize, this means the IoT devices are assumed to have connectivity with other nodes in the blockchain network, and are able or receive selected transactions propagated through it. We stress that the requirements of IoT nodes can be realized efficiently in disk space and memory. Such nodes are not required to store a complete copy of the blockchain. Instead, they can rely on a trusted available blockchain node (e.g., a gateway), or reduce the trust needed by consisting of a light client such as described in Section 1.1.1. In addition, having the IoT function as a DSN node also does not impose significant space constraints. The IoT node is not required to share files in the network, and in the cases in which a distributed hash table is used as the peer discovery scheme for the DSN, only a small constant amount of memory is required for maintaining internal routing tables.
29 For every vendor vi V ,thesetofitsIoTnodesisdenoted: 2
O = o ,...,o i { i1 in} where i [1,m]:O (S B) 8 2 i ⇢ \
Each IoT object, oik Oi, maintains the following: 2
1. asecret/publickeyspair(skoik ,pkoik ).
2. public key of its manufacturing vendor, pkvi .
The last prerequisite can also be met by having the vendor "burn" its own pub- lic key pkvi into the IoT device (thereby adding to the suggestion made in previous section, we can have the vendor burn the pair (pkvi ,skoik ) into the deployed device). As our protocol does not require IoT devices to sign transactions which should be verified by the participating blockchain nodes, we do not assume a key pair of a spe- cific signature algorithm; the underlying blockchain’s smart contract language can support an arbitrary digital signature algorithm. However, blockchain platforms typically use Elliptic Curve Cryptography and have built-in functions to verify such signatures. For instance, Ethereum has a built-in ecrecover function in its smart contract language Solidity. Hence, devices may support any public-key cryptogra- phy signature algorithm, such as utilizing hardware security modules (HSMs) which can process RSA signatures, but it would be advised to use ECC.
5.2.3 Distributor nodes
Distributor nodes are host machines that participate in an open bid for proofs- of-distribution. They must participate in both the DSN and the blockchain-based
30 network. Within the blockchain network, distributor nodes must be able to function as both a wallet and a network routing node. Distributor nodes are denoted as:
D = d ,...,d { 1 nD } where D (S B) ⇢ \
31 Chapter 6
IoTPatchPool
We describe the IoTPatchPool framework, its main components and the suggested protocol which enable it to achieve an open incentivized system with fair exchange. It is referred to as a framework because of its general requirements which allow a variety of concrete implementations. The framework is comprised of two networks, a decentralized storage network (DSN), in which software updates are transferred between network nodes; and a blockchain network, in which vendors commit to payment in exchange for delivery in the form of smart contracts, thus incentivizing delivery within the DSN. These two networks are facilitated by the three types of actors participating in the IoT updates delivery network: vendors, IoT devices and distributors. High-level sketch of the architecture and participating parties in Figure 6.1.
The delivery process (high-level overview in Figure 6.2) is triggered when a ven- dor releases a new security update that should be delivered to its deployed devices. The vendor delegates this task to distributors by publishing a smart contract in the blockchain network in which he commits to providing cryptocurrency payments in exchange for a proof-of-distribution,i.e.,providingaproofofdeliveringtheupdate to a deployed IoT device (see Section 6.1.2). In addition, the vendor hosts the new security update, enabling other nodes to consume it via the DSN, for a limited and short period of time.
Upon publication of the smart contract, distributors can participate by down-
32 loading the update from the DSN, thus making it available for the IoT devices. The IoT devices become aware of an update release with the publication of the smart contract and can now consume the update from distributors over the DSN (see Section 7.2.3). The update exchange between a consuming IoT device and a distributor relies on a trustless swap in which the deployed device is updated and the distributor acquires a proof-of-distribution (see Section 6.1.4), therefore is paid by the smart contract (see Section 6.1.5).
Figure 6.1: IOTPatchpool High level architecture overview [ The framework is comprised of two networks, a decentralized storage network (DSN), in which software updates are transferred between network nodes; and a blockchain network, in which vendors commit to payment in exchange for delivery in the form of smart contracts. These two networks are facilitated by the three types of stakeholders participating in the IoT updates delivery network - vendors, IoT devices and distributors.]
6.1 Protocol
In this section, we describe the protocol used for a vendor vi V to send an 2 update file U destined to a group of IoT objects manufactured by the vendor,
Oi = oi1,...,oin . The protocol essentially consists of 5 phases: setup (performed { } 33 only once overall, see Section 6.1.1), contract publication (Section 6.1.2), update file initial seeding (Section 6.1.3), update file exchange for a proof-of-distribution (Sec- tion 6.1.4)andarewardclaimforaproof-of-distribution(Section6.1.5). High-level flow scheme is in Figure 6.2 and a detailed sequence diagram presented in Figure 6.3.
6.1.1 Setup
A third party or one of the vendors first deploys a factory smart contract. This fac- tory contract will function as the generator of new instances of "patching contracts" where a vendor bids digital currency payments for receiving proofs-of-distribution from his destination IoT devices. The involved parties, namely the distributors and the IoT devices, can independently verify this factory contract, be assured that con- tracts created by it are of a specific expected form, and subscribe to events emitted by it.
6.1.2 Contract publication
Upon releasing a new update U,vendorvi performs the following phases:
1. Hashes the update file Uid := H(U).
2. Generates the zk-SNARKs public proving/verification keys: (pkPoD,vkPoD):=
Gen(1 ,C). Here is a security parameter, and C is a decision circuit.
The keys will be used to prove/verify membership in the NP language LC , which for clarity is defined later in Section 6.1.4.
PoD PoD vi 3. Computes update file wrapping package: P := (U, pk ,vk , sign Uid,vk ,Oi), { }
where Oi is represented as an ordered list of the IoT devices public keys.
4. Hashes Pid := H(P ).
5. Sets REF UND to an acceptable time duration for a patch to be effective.
34 6. Sets REV EAL to an acceptable time duration between commit and reveal transactions (as detailed in Algorithm 6.1.2). These two transactions consist the 2-phase redemption of the digital payment made by a distributor in exchange for a key which decrypts the encrypted file served to the IoT. This can be considered as the required time for having a sufficient number of confirmations in the underlying blockchain to have the risk of having the
commit transaction practically negligible in comparison to the transaction’s value (in practice a single block time will do for a low value transaction),
plus some safety margin time for having the subsequent reveal transaction confirmed since its transmission.
7. Sets rt to be the root of the Merkle tree [53]generatedfromtheorderedlist
of IoT devices public keys Oi.
8. Posts a transaction to the factory smart contract deployed in Section 6.1.1 which triggers the creation of a new smart contract (Algorithm 6.1.2 presents
the pseudocode for the new contract), with a deposit fvi of money, the hash of
the update file wrapping package Pid,themerkletreehashrt,theconfigured
time durations REF UND and REV EAL,thedestinationIoTmodelidentifier
Mid and a program which essentially says:
For each ob ject oik Oi: 2
Transfer (fv n) coins to the first party who provides proof that i \
oik have committed to receive the hash preimage of Uid, within time