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- networks that have a fundamental availability problem for unpopular files, our protocol utilizes -based smart contracts to incentivize independent peers, termed distributors, by means of payments. A vendor of IoT devices deploys a 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 . Keywords

IoT

Blockchain

Patch Update

Distributed

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 ...... 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 DOS Denial of service DSN Decentralized storage network

ECDSA Elliptic Curve Digital Signature Algorithm EVM Ethereum Virtual Machine

IOT Internet Of Things IPFS InterPlanetary

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 -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, 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 [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. 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 , 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 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 [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- 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 , 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. 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 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 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 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 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 compensation for either providing storage or bandwidth, which is the case for blockchain-based decentralized storage solutions such as Storj [46], Siacoin [47], [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 . 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 [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

REF UND.

Assigning a time limit REF UND for publishing proofs is important so that the vendor can collect its refund if some of the IoT objects were not served after some set time (e.g., because sufficient time has passed such that a newer update file must be distributed, or because some remote objects are no longer active). Note that addressing specific IoT devices with a security update

35 becomes possible as the vendor maintains the list of their public keys. Instead of listing the entire IoT devices public keys, the contract expects to receive proofs-of-membership in the form of a Merkle path from a given IoT public key to the Merkle root rt.

Algorithm 1: Proofs-of-distribution bid contract Initialize IoTsMerkleRoot := rt Initialize fileHash := Uid Initialize duration := REF UND Initialize commitDuration := REV EAL Initialize contractStartTime := now Initialize := I ; Initialize N := number of IoT devices

on contract input commit (pko,mp,s,) at time T : pkd := message sender discard if T>contractStartTime + duration discard if mp is not a valid Merkle path from pko to IoTsMerkleRoot discard if [pko].pkd = NULL and now < [pko].commitTime + I 6 I commitDuration discard if [pko].redeemed == TRUE I verify the signature on the message (fileHash s pkd) against public || || key pko := pko I I[{ } [pko].commitTime := now I[pko].pkd := pkd I[pko].s := s I emit Committed(pkd,pko,s)

on contract input reveal (r, pko) at time T : discard if T>contractStartTime+duration discard if T> [pko].commitTime + commitDuration I discard if [pko].redeemed == TRUE I discard if Hash(r) = s 6 [pko].redeemed := TRUE I transfer (N balance) to pkd ÷ emit KeyRevealed(pko,r)

6.1.3 Update file initial seeding

Distributor nodes and the manufactured IoT objects are subscribed to events emit- ted from the factory smart contract deployed in Section 6.1.1,andexpectanevent

36 of the creation of a new contract by a vendor known by his public key pkvi .Once one has been created as in Section 6.1.2,theinvolvedpartiesparsetherelevant parameters from the creation event and the following process starts:

1. Distributors start to request downloading the update file wrapper package

corresponding to the hash Pid which was published in the smart contract, using the underlying DSN.

2. The vendor vi transfers (i.e., seeds) the package P via the DSN (offthe blockchain). The file is then propagated until it eventually reaches some dis- tributor d D that wishes to participate in the open bid for the proofs-of- 2 distribution. It should be made clear that this initial seeding by the vendor is meant to last a limited amount of time until a sufficient mass of distributors has downloaded the file, and from that point the distribution is performed completely by the competing distributors.

3. After completely downloading the package P , d verifies that:

vi vi PoD PoD - VerifySig(pk , sign Uid,vk ,Uid vk )=1. { } ||

- The number of elements in Oi matches N as was committed in the contract.

- The Merkle root of the generated Merkle tree in Oi matches rt that was committed in the contract.

4. d announces itself in the underlying DSN peer discovery scheme, such as a

distributed hash table (DHT), as a holder of the file using its file hash Uid.

6.1.4 Update file exchange for a proof-of-distribution

In this procedure, a distributor and an IoT object are interacting in order to even- tually perform an update file transfer. They first conduct a hand-shake to let both know that the requesting IoT is indeed a member of the group to update, Oi.After- wards, they follow a two-party protocol where they perform a fair exchange of the

37 update file for a proof-of-distribution, a digital signature given by the IoT object which can reward the distributor with a payment when sent to the smart-contract. The fair exchange is achieved in a trustless manner by applying a zero-knowledge contingent payment (ZKCP [27]) which makes use of a zero-knowledge proof gen- erated by the distributor and verified by the IoT object. This part is done in a protocol which is external to the blockchain and therefore does not require any spe- cific modifications to the of the underlying blockchain nor does it add any burden to the blockchain nodes (so it does not cost any digital currency fees or gas in the Ethereum jargon). In details, this process consists of the following steps:

1. IoT object oik Oi receives a creation event from the factory smart contract, 2 vi checks it was sent by a its own vendor vi identified by the public key pk ,and

verifies that the model identifier Mid is indeed of its own and thus the update potentially concerns to him.

2. oik performs a lookup for the file U using the publicly available file hash Uid

from the smart contract deployed by vi,anditreachesthedistributord by using the underlying DSN peer-discovery scheme (e.g., DHT). It then sends d a request to download the update file which is the hash preimage

of Uid.

3. d sends a random nonce c,achallenge,tooik to sign on.

4. oik:

- Computes signoik c := Sign(skoik ,c). { } -Sendsthetuple(pkoik , signoik c ) to d. { }

5. d:

oik -Verifiesthatpk Oi. 2 -VerifiesthatVerifySig(pkoik , signoik c ,c)=1. { } - Computes the Merkle proof mpoik which is the Merkle path of the public key

pkoik to rt.

38 - Computes r := Gen(1), where Gen is some secure random key generator for the security parameter .

- Computes s := H(r). - Computes Uˆ := Enc(U, r) where Enc is some symmetric encryption algorithm (e.g., AES). - Computes x := (U,sˆ ). - Computes w := (U, r).

- Computes the zero-knowledge proof: ⇡ := Prove(pkPoD,x,w) where x is the

public instance, w is the secret witness and the NP statement is x Lc where 2

LC = (U,sˆ ): w =(U, r), H(U)=Uid H(r)=s Enc(U, r)=Uˆ . { 9 ^ ^ } oik VoD vi PoD d -Sendsthetuple(mp ,x,⇡,vk , sign Uid,vk ,pk ) to oik. { }

6. oik:

vi vi PoD PoD -VerifiesVerifySig(pk , sign Uid,vk ,Uid vk )=1. { } || -Verifiesmpoik is a valid Merkle-path from pkoik to rt.

-VerifiesVerify(vkPoD,x,⇡)=1.

oik d -Sendssign Uid,s,pk to d. { }

6.1.5 Reward claim for a proof-of-distribution

As a distributor d acquires the proof-of-distribution, he collects his reward as follows:

1. d:

oik oik d d -VerifiesVerifySig(pk , sign Uid,s,pk ,Uid s pk )=1. { } || || oik oik d oik -Postsacommit transaction to the smart contract containing: (pk , s, sign Uid,s,pk ,mp ). { }

-WaitsforasufficientnumberofconfirmationsbeforeREV EAL expires.

oik -Postsareveal transaction containing (r, pk ) which would release (fvi /n) coins to the address of d in return, according to the contract description.

2. oik:

-ReceivestherelevantKeyRevealed event which is associated with the device’s

public key, pkoik , with the decrypting key r.

39 - Computes Dec(U,rˆ ) to get the update file U.

Phase 1: Contract Publication Phase 2: Initial Seeding Phase 3: File Exchange for PoD Phase 4: Reward for PoD

Blockchain Distributor Distributor Blockchain

Commit Reward Encrypted Key Smart Contract PoD and File File for PoD Reveald Reveal

Zero-knowledge proof

Vendor Vendor IoT Device Distributor IoT Device

Figure 6.2: IOTPatchpool High level overview of the update protocol [ The protocol consists of four phases. In the first phase the vendor publishes a smart contract for the delivery of the new software update. Then, in the second phase the vendor uploads the software update file to the DSN. In the third phase the Distributor node and the IoT device exchange the (encrypted) software update file and the proof-of-distribution (PoD). Finally, the Distributor node claims the reward for distributing the software update file to the IoT device.]

6.2 Properties in this section we will prove the properties of the protocol with respect to the security goals in Section 4:

1. Fair exchange -weproveachievingfairexchangeofapatchforpaymentin our proposed system.

Let Uij be the jth update of the vendor vi,andletC(Uij,oik) be a compensa-

tion of the smart contract to the update given to a the IoT object oik.

Theorem 1 Except a negligible probability in the security parameter ,adis-

tributor node dq can receive the payment compensation C(Uij,oik) if and only if:

(a) dq delivered the security update Uij to the IoT device oik,and

(b) No other distributor dp (p = q) received C(Uij,oik) 6 40 Figure 6.3: IOTPatchpool: Outline of the IoT software update protocol [HereC is a decision circuit, x is the public instance, w is the secret witness and the NP statement is x LC where LC = (U,sˆ ): w =(U, r), H(U)=Uid H(r)=s 2 { 9 ^ ^ Enc(U, r)=Uˆ .] }

Proof. Let SCij be the smart contract published by the vendor vi towards the

delivery and compensation of the update Uij. The state of the contract SCij contains the root rt of the Merkle tree generated from the set of the public

keys of the destination IoT devices, Oi,andtheredemptionstateofeachIoT (i.e., whether the reward for it was already redeemed or not).

Let rx denote a valid secret revealed in a reveal message for an update Uij

41 towards a device oix,i.e.,itisahashpre-imageofans value which was signed

oix in a valid signature checked against pk ,thepublickeyofoix.

By the contract construction, the object oix is assigned with rx only if it was not previously assigned with such a valid pre-image.

For any distributor dp (p = q)toreceiveC(Uij,oik) prior to dq,apublished 6 transaction reporting the secret for dp is required for Uij,oik.

If this transaction is indeed published, SCij already has an r assignment for oik

(and a true redeemed flag), thus a distributor node dq cannot receive C(Uij,oik) as required.

We therefore, continue by assuming C(Uij,oik) was not yet received by any distributor.

Assuming C(Uij,oik) is still available, in order for dq to receive it - the smart contract SCij must induce verify( )=1. Therefore, if dq did not deliver · the security update Uij to the IoT device oik he is required to provide the contract with a forged published proof in commit and reveal and yet suffice verify( )=1. ·

Based on the security parameter of the system ,adistributordq can forge this proof only if one of the follows applies:

oik d (a) The distributor forges digital signature instead of oik,i.e.,dq forges sign Uid,s,pk . { } (b) The distributor forges the entire zk-SNARKs proof-of-knowledge.

(c) The distributor finds a second hash preimage r0 s.t H(r0)=H(r)=s.

Now, based on having (1) a digital signature scheme which is secure in the sense of existential unforgability against chosen message attacks (EU-CMA secure), (2) soundness of zk-SNARKs and (3) second preimage resistance for acryptographichashfunction,anattackerwouldbeabletoachieveoneof the above only with negligible probability in the chosen security parameter .

Therefore, dq cannot receive C(Uij,oik) without a valid proof-of-distribution except with a negligible probability in .

42 In the other direction, by the completeness of zk-SNARKs, a distributor dq that

delivers Uij to the IoT device oik will be able to acquire a proof-of-distribution

and can publish it to collect C(Uij,oik), assuming that the IoT object will not disconnect in the middle of their two-party protocol and that the distributor’s

commit and reveal transactions will be relayed and confirmed within their

respective time windows. If no other distributor collected C(Uij,oik),based

on the irreversibility of the blockchain, the smart contract is binding, thus dq

will be able to receive the C(Uij,oik) payment as required.

It should be noted that the vendor vi, which has performed the zk-SNARKs trusted setup to generate the proving and verification keys, is able to forge proofs to falsely convince IoT devices that he has delivered them the update file. However, since this will serve him only in getting his own vested funds from the smart contract, and beat his own original purpose to update his manufactured devices, we argue that this is not a real limitation of the protocol.

2. Patch integrity -followedfromthepreviousproof,adistributoriscompen- sated only if it indeed delivered an IoT a file in which its cryptographic hash

digest is Uid,theexacthashthevendorcommittedto.Fromthecollisionre- sistance of the cryptographic hash function, it is indeed the original update

file Uid except a negligible probability.

3. Patch availability -aswepresentedtheanalysisoftheDenial-of-Service potential attacks, the of both the decentralized storage and blockchain networks, together with incentives guaranteed by the binding con-

tract for the time period of the bid (REFUND), ensure the file will be available for consumption by relevant IoT devices.

6.3 Implementation

In order to demonstrate and further evaluate our proposed framework we developed a dedicated prototype environment, which consisted of the following components:

43 Ethereum Blockchain: In order to allow new distributors to join the system • and increase competition between service providers, participation should be open and all participating clients should be able to write new transactions onto the blockchain. Henceforth, we require our blockchain platform to be open and permissionless. In addition, our blockchain platform should also support rich scripting language smart contracts. For these reasons we opt to use Ethereum, which at the time of this writing, is the most widely blockchain network with these properties. One expression of Ethereum’s adoption is the overwhelming 2.4 1014 hash computations per second securing the blockchain, contributing ⇡ ⇤ to its immutability. This is second only to Bitcoin, with 4.8 1019 SHA256 ⇡ ⇤ computations per second, true to the time of this writing.

We implemented in Solidity the pseudocode described in Algorithm 6.1.2. For development and evaluation purposes, we used a local private network of Ethereum, with a modified consensus algorithm using a Proof-of-Authority.

WebTorrent: We opt to use WebTorrent, a well-adopted BitTor- • rent client for the web, with support for connecting to BitTorrent’s distributed hash table based on Kademlia [54].

libsnark: For the implementation of the proof-of-distribution, we use the • libsnark1 library for our zk-SNARKs system, which is also the core library used for the privacy-focused cryptocurrency .

Using these three components we created three types of clients: (1) a vendor client, (2) a distributor client and (3) an IoT client. The vendor and distributor clients are running on Hyper-V Virtual Machines (VMs) running Ubuntu 18.04 on an i5 2-core 4GB RAM located in our labs. The IoT clients were running on Raspberry Pi 3 physical devices. Also, we deployed a dedicated (private) Ethereum geth2 client full-node. This node is functioning as a miner with a modified mining

1https://github.com/scipr-lab/libsnark 2https://github.com/ethereum/go-ethereum

44 Figure 6.4: IOTPatchpool: The Figure 6.5: IOTPatchpool: A board used for our demonstration en- screenshot capturing the user inter- vironment, consisting of 48 Raspberry face of the vendor’s server during the Pi devices. update process. algorithm in the form of Proof-of-Authority, on a server with a pre-known IP address to which the clients were able to connect and interact with, using the Web3 JS API.3

The prototype environment consisted of a single vendor, 20 distributors and 48 physical Raspberry Pi 3 devices functioning as the IoT clients. Figure 6.4 shows the board we used in our labs for the demonstration environment, which held the Raspberry Pi devices with a TV monitor in its center.

Each of the Distributors and IoT clients were pre-configured with the single verified factory contract address, and a corresponding ECDSA secp256k1 key pair as used in Ethereum. Distributors started offwith some Ether balance where the IoT devices did not as they are not required to. Also, distributors start with a list of relevant vendors public keys, and each IoT with its single vendor public key (the method for discovering the verified public keys can be done by some other service or CA and was out of scope for our tests).

The update process: First, distributors and IoT clients subscribe to ContractPublished events from the commonly known factory contract address. We used a single user interface representing the vendor’s interaction with its server. It first goes through a screen to select a file to upload. When it selects a single file to upload, it creates a new contract instance by sending a createContract transaction to the factory contract with the relevant selected parameters including the relevant file hash and model identifier to update.

3https://github.com/ethereum/web3.js/

45 Involved parties are notified about this event. IoT devices are able to filter events only for their specific model identifier and trusted vendor public address, and also get past update events in case they were disconnected at the moment the contract was created. At this point, the vendor seeds the software update file through the WebTorrent network. Distributors and IoT clients which received the relevant event, start re- questing to download the file via WebTorrent. Consequently, IoT devices find dis- tributor peers via the DHT. The distributors initiate a side communication channel with the IoT devices to perform the 2-party ZKCP protocol, which ends with fair exchange performed on the blockchain: a distributor receives its payment and an

IoT device receives its corresponding decryption key by the KeyRevealed event. Finally, Figure 6.5 shows a screenshot of the TV monitor, which displays the user interface for the vendor’s server, as it gets notified with KeyRevealed events emit- ted by the geth node, to audit the update process of the IoT devices. Each point on the web page map is associated with a device public key, which is part of the emitted event, hence it marks a point on the map with every new update of an IoT object. A click on each point takes the viewer to a block-explorer showing the exact transaction which caused the KeyRevealed event to the specific IoT, showcasing a transaction was indeed made and a compensation was transferred from the contract to the delivering distributor.

46 Chapter 7

Proposed framework: IoTPatchPool Pay per piece

this part describes the IoTPatchPool Pay per piece framework, its main components, and the suggested protocol which enables it to achieve an open incentivized system with pay per piece of digital exchange. pay per piece is a general exchange protocol which includes two or more parties which are interacting in trust-less exchange of goods, the core concept is the fact that each party will reduce its exposure for risk by dividing the stack in hand by a certain factor, once the fulfillment of the divided goods the trust can be built and trust and the transaction is building as time progress.

the IoTPatchPool Pay per piece will try to address a few of the shortcomings of the former framework which are as follows:

1. Patch size limitations:theIoTPatchPool framework relies on the ZKCP protocol which is limited in its current implementation for 55 kB

2. Network overhead:inadditiontothepatchupdateitself,theformerframework requires the sending of additional data in the form of ZKsnarks proving and verification keys, in some cases it is hundreds time folds bigger than the patch file itself.

3. Demands for IoT devices: in ZCKP protocol the IoT devices need to verify

47 the ZKsnarks statement and in addition, there is a need to decrypt the patch binaries once the decryption key is revealed. these two operations are having additional demands on the device storage memory and processing power.

4. Costs:theformernetworkisafirstlayersolutionontheblockchainnetwork, to reduce costs new methods of offering payment to the distributors should be used.

as the IoTPatchPool this 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 7.1. The delivery process is triggered when a vendor releases a new security up- date 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.,providingproofofdeliveringtheupdatetoadeployedIoTdevice (see Section 7.2.2). In addition, the vendor hosts the new security update, enabling other nodes to consume it via the DSN, for a limited and short time periods. Upon publication of the smart contract, distributors can participate by down- 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).

48 Figure 7.1: IoTPatchPool Pay Per Piece 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.]

7.1 Alternative selection leading from the former work on the IoTPatchPool we researched for additional methods to achieve a trust-less protocol for IoT patch distribution. the desired framework should accompany all the former framework properties and in addition address few of the shortcomings listed in 7.thepayperpieceprotocolrequiresan exchange for signature between the distributor and the IoT during the file exchange. as a security parameter for the system, the smaller pieces and hence larger count of pieces is preferable, since it minimizes the in initial risk in the good exchange, on the other side of the stick is the fact that larger amount of signature means higher

49 fees paid in the form of transaction gas. one method to achieve a lower amount of signature sent to the smart contract is signature aggregation. the ability to compact multiple signatures into one signature will lead for smaller fees paid to the miners.

1. BGLS multi signature in 2003 a variation on the BLS signature aggregation scheme was introduced [55], Given n signatures on n distinct messages from ndistinctusers,itispossibletoaggregateallthesesignaturesintoasingle short signature. in late 2017 the ethereum main net was forked and introduces anewsetofcommandsenablingtheimplementationoftheBGLSsignature verification in a smart contract, namely the function for pairing check. preliminaries testing done on these methods showed that paring check is a costly function and depends on the number of signatures aggregated. tests showed that in BGLS signature is 100 K Gas unites to verify where the ⇠ already implemented ECDSA verification costs 27 K gas units. ⇠

2. ASM - accountable-subgroup multi-signature in 2018 a new signature aggregate scheme was introduced [56], this scheme allows for verification of asignatureofthesamemessagegivenbyanarbitrarysubsetofapredefined group of signers. as the mentioned BGLS scheme this also relies on the pairing check function introduced in the 2017 fork. in addition, it requires for a setup phase of 3 round communication between all the singers - forcing that all IoTs devices will be online and communicating in every patch release making this scheme unsuitable for this framework.

3. ECDSA Elliptic Curve Digital Signature Algorithm is one of the main build- ing blocks of the ethereum network and it is used for verifying all the trans- actions. since its inherent to the system the costs of verifying signatures is relatively low 7K gas units but does not support any kind of aggregation. ⇠ reviewing all the possibilities the ECDSA alternative was chosen for its simplicity low costs and lack of demand for online preliminary setup between signers. it’s important to notice that choosing ECDSA will allow this framework to be scalable

50 as the blockchain ledger itself making any new additional improvements in scalability to applied on this framework.

7.2 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 (see Section { } 7.2.1), contract publication (Section 7.2.2), update file initial seeding (Section 7.2.3), update file exchange for a pay per piece confirmation (Section 7.2.4)andareward claim (Section 7.2.5). detailed sequence diagram presented in Figure 7.2.

7.2.1 Setup

Same as the IoTpatchpool framework, this framework uses a Factory contract as an initial step for any patch update procedure. the factory contract will be used to link all the future vendor contracts to the community of distributors who would like to participate in future IoT patch update procedure. the distributor would listen to an event emitted by the factory contract to receive the newly published contract and initiate a process of patch update.

7.2.2 Contract publication

Upon releasing a new update U,vendorvi performs the following phases:

1. Hashes the update file Uid := H(U)

2. sets N as the total count of IoTS Oi

3. sets P as the total count of pieces

vi 4. Computes update file wrapping package: P := (U, sign Uid ,Oi), where Oi { } is represented as an ordered list of the IoT devices public keys.

51 5. Hashes Pid := H(P ).

6. Sets ContractLifeTime to an acceptable time duration for a patch to be effective.

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 7.2.1 which triggers the creation of a new smart contract (Algorithm 7.2.2 presents

the pseudo-code for the new contract), with a deposit fvi of money, the hash of

the update file wrapping package Pid,themerkletreehashrt,theconfigured

time duration ContractLifeTime,thedestinationIoTmodelidentifierMid and a program which essentially says:

For each ob ject oik Oi and every piece index in range of Pieces : 2

Transfer fvi/(n p) coins to the first party who provides proof that oik ⇤ di have signed on a message (Uid,pk ,j), within time ContractLifeTime.

Note that addressing specific IoT devices with a security update becomes pos- sible as the vendor maintains the list of their public keys. Instead of listing the entire IoT devices public keys, the contract expects to receive proofs-of- membership in the form of a Merkle path from a given IoT public key to the Merkle root rt.

7.2.3 Update file initial seeding

Distributor nodes and the manufactured IoT objects are subscribed to events emit- ted from the factory smart contract deployed in Section 7.2.1,andexpectanevent of the creation of a new contract by a vendor known by his public key pkvi .Once one has been created as in Section 7.2.2,theinvolvedpartiesparsetherelevant parameters from the creation event and the following process starts:

52 Algorithm 2: IoTPatchpool Pay Per Piece smart contract Initialize IoTsMerkleRoot := rt Initialize fileHash := Uid Initialize ContractLifeTime := ContractLifeTime Initialize contractStartTime := now Initialize UpdatedPieces = ; Initialize n := Number of IoT devices Initialize p := Number of Pieces

on contract input RedeemPayment (pko,mp,s,, msg, piece, ) at time T : pkd := message sender discard if T>contractStartTime + ContractLifeTime discard if mp is not a valid Merkle path from pko to IoTsMerkleRoot discard if UpdatedPieces [pko][piece]==TRUE verify the signature on the message (fileHash pkd piece) against || || public key pko

UpdatedPieces [pko][piece]==TRUE d TransferCoins (pk ,fvi/(n p)) ⇤ emit iotPartUpdated(pkd,pko, piece)

1. Distributors start to request downloading the update file wrapper package

corresponding to the hash Pid which was published in the smart contract, using the underlying DSN.

2. The vendor vi transfers (i.e., seeds) the package P via the DSN (offthe blockchain). The file is then propagated until it eventually reaches some dis- tributor d D that wishes to participate in the open bid in the contract. 2 It should be made clear that this initial seeding by the vendor is meant to last a limited amount of time until a sufficient mass of distributors has downloaded the file, and from that point the distribution is performed completely by the competing distributors.

3. After completely downloading the package P , d verifies that:

vi vi - VerifySig(pk , sign (Uid)) = 1.

-verifythatPid which was publish in the contract, Pid = H(P ).

- The number of elements in Oi matches N as was committed in the contract.

53 - The Merkle root of the generated Merkle tree in Oi matches rt that was committed in the contract.

4. d announces itself in the underlying DSN peer discovery scheme, such as a

distributed hash table (DHT), as a holder of the file using its file hash Uid.

7.2.4 Update file Pay Per Piece exchange

In this procedure, a distributor and an IoT object are interacting in order to even- tually perform an update file transfer. They first conduct a hand-shake to let both know that the requesting IoT is indeed a member of the group to update, Oi. In details, this process consists of the following steps:

1. IoT object oik Oi receives a creation event from the factory smart contract, 2 vi checks it was sent by a its own vendor vi identified by the public key pk ,and

verifies that the model identifier Mid is indeed of its own and thus the update potentially concerns to him.

2. oik performs a lookup for the file U using the publicly available file hash Uid

from the smart contract deployed by vi,anditreachesthedistributord by using the underlying DSN peer-discovery scheme (e.g., DHT). It then sends d a request to download the update file which is the hash preimage

of Uid.

3. d sends a random nonce c,achallenge,tooik to sign on.

4. oik:

- Computes signoik c := Sign(skoik ,c). { } -Sendsthetuple(pkoik , signoik c ) to d. { }

5. in this stage the IoT device can start downloading pieces from any free pro- viding distributors (i.e the vendor node)

6. d:

oik -Verifiesthatpk Oi. 2 54 -VerifiesthatVerifySig(pkoik , signoik c ,c)=1. { }

7. piece by piece exchange:

-oik sends the requested j part of the patch file

di -d concats Mj = concact(Uid,pk ,j) ans sends to oik

-d sends part to oik

-oik signs Mj and sends to d

7.2.5 Reward claiming

As a distributor d acquires the signed messaged from oik,hecollectshisrewardas follows:

1. d:

-for each acquired Mj signature:

-builds a merkle tree proof for oik

oik -sends (Mj, sign Mj ,Merkle proof) to contract { }

55 Figure 7.2: IoTPatchPool Pay Per Piece sequence diagram

56 7.3 Implementation

the IoTPatchPool implementation proved the capability of such framework to func- tion on multi participate platform, Raspberry pies used as a fleet of IoT devices requesting patch from the distributors which in return replied to the Ethereum smart contract to reclaim their reward. the implementation of the IoTPAtchPool Pay Per Piece was needed to examine the various questions concerning the new fields in which modified in the framework, one key question was the latency of the blockchain. even though the two critical phase of "delivering the patch to the IoT" and the "Redeem" phase are not bind one into the other, is it up to the distributors to control when to initiate each one and making they complete in one round, meaning to send a piece and in return to redeem the reward, does increase the certainty of the distributes concerning the reward claim. another key question is the costs, we do expect higher costs in gas in IoTPAtchPool Pay Per Piece framework and although it is possible to calculate theoretical one - the blockchain is a living distributed grid of computing power which is subject to fluctuation. to answer these question the implementation was based on the smart contract and deployment on the Ethereum main test net, Rinkeby is one of the 3 Ethereum test net it is the biggest one and is close to the main net as possible, the gas prices aligned with the main net and the block-time is similar although it does not use PoW as the consensus algorithm. the smart contract was written in Solidity version 0.4.17 and was deployed and tested using the Truffle framework. Mocha was used as a testing framework and for gas consumption reporter. before contact deployment all attacker scenarios were tests, among others, reclaiming of reward twice, false signa- ture by IoT, false merkle proof, reclaim of a none member IoT device in the contact and false contract Id.

57 7.4 Evaluation

Based on the trust model and adversarial model we detailed in Section 4,weanalyze the different threats to the proposed framework and evaluate the system properties with respect to the security goals.

Reward interception. An attacker can eavesdrop on transactions sent over the blockchain network and try to catch the Redeem transaction, and try to withdraw

d the reward to himself. in order to prevent this Mj contains PK and is signed by

d Oik.thePK should match messenger address to of the transaction sent to the smart contract and for any new public address to claim the reward the attacker should achieve a new signature.

Malformed contract. An attacker can attempt to change the smart contract after it was deployed, in order to discard the vendor’s commitment to compensat- ing delivering distributors. Specifically, an attacker can change the smart contract balance, the number or the actual set of IoT devices to serve for a given deposit, or modify its state in such way that will change the contract’s behavior for a given function which handles the payment’s logic (for example, by having the contract to rely on an externally modifiable account address). Also, in Solidity, in general, it is possible to have contracts to self-destruct and be removed from the blockchain, given an external triggering message. Moreover, an attacker can try and change the contract owner if it gives any special permissions throughout the lifetime of the contract. We designed the contract so that the payment properties and logics are immutable and there is no option to withdraw money before the initially set expiration time, hence a dishonest vendor or any other attacker is unable to modify the payment terms. In particular, the number of the IoT devices or the set of the legitimate de- vices public keys (Oi)arenotmodifiableaftertheywerecommittedinthebinding smart contract (by N and Merkle root rt,seeAlgorithm7.2.2), and they are also verified against the actual values that were transferred with the wrapping package P by each distributor. lastly, the contract is not prone to an ownership change or

58 to self-destruction.

Denial-of-service (DoS): Redeem with false Message. Amaliciousdis- tributor can choose to only send a Redeem transaction with a prior knowledge that this transaction will not be fulfilled only to deny other distributors to redeem funds. this attack will be costly to perform due to the transaction fees upon sending the transaction.

Denial-of-service (DoS): Exhausting Resources. On top of the previous attack, an attacker can impersonate to be an honest distributor which holds the relevant file by announcing itself in the distributed hash table (DHT) of the DSN as a holder of the relevant file identifier. Then, when a connection is initiated, the attacker can cheat an IoT and waste its resources by going through the handshake process with him and not eventually delivering the file. A different attack may be that an attacker compromises an IoT device of the relevant IoT set, causing it to waste distributor’s resources, and then similarly stop the interaction by going offline or terminate the connection. this framework doesn’t require high demanding tasks to be preform, the only attack can be subjected only to hash a message and produce a signature, which is not difficult to compute.

Denial-of-service (DoS): Blockchain related attacks. Another way to prevent patching from being performed is to censor transactions that reach the blockchain network. Aside from the eclipse attack which has been explained above, such an attack is typically referred to as a censorship attack. By construction, the attacker will essentially need to control the majority of the mining power of the net- work (or more than 25% given connectivity assumptions [57]) which is presumably difficult.

Compromising a firmware integrity. An attacker can impersonate to a ven- dor and try to publish a malicious software update to the IoT devices. The integrity of the file is ensured by first having the vendor committing to a specific file hash,

59 Uid,inthecontractdeploymenttransactionsignedbythetrustedvendor,andthen having the IoT device verifying a proof given by the distributor, attesting that he has sent an encrypted version of a file which is the hash preimage of Uid.

Software downgrade attack. An attacker may cause an IoT device to down- grade its software to an outdated version (which may include known vulnerabilities). This threat is mitigated using the consensus regarding the order of the blockchain’s transactions, which implies ordering of the updates versions.

7.4.1 Properties in this section we will prove the properties of the protocol with respect to the security goals in Section 4:

1. Fair exchange -theprotocolconstructionisbasedonfirstdeliverythepiece from the distributor to IoT device and in return receives the signature assuring the reward claiming in the smart contract. in the protocol, the distributor can be listed on the DSN by first downloading the patch and hashing the file into an address, meaning that the distributor holds the patch binaries ready to deliver, each piece in the torrent protocol is hashed and can be verified by the receiver. in the case of delivering false pieces from the distributor to the IoT device, the IoT will validate the piece against the hash and confirm its validity.

the second phase is IoT signing the requested message. in this construction, the distributor can only validate the signature only after receiving the sig- nature - putting himself in risk and will be compromising a fraction of the reward once per IoT lifetime. since this phase starts only after validating the IoT public address in the handshake phase, the distributor can hold a black- list of IoT making it protected the next time the IoT requests a piece. in the transitional construction of the gradual release, both parties should have the same computational power in order to eliminate the ability of one party to

60 abort between rounds and brute force the remaining information, in this pro- tocol the availability of the piece is given from multiple sources, eliminating the incentive of one party to redraw from the transfer

in any given time the distributor can call a free of (ethereum) gas method in the smart contract and check if the IoT and piece were already rewarded before providing the piece.

2. Patch integrity -thepatchupdatefilehashislistedtothecontract.aslong as the attacker hasn’t gained enough resources to modify the ledger, which is presumably very hard). this along with the use of a collision-free hash function patch will lose its integrity with a negligible probability.

3. Patch availability -aspresentedintheanalysisoftheDenial-of-Service potential attacks, the decentralization of both the decentralized storage and blockchain networks, together with incentives guaranteed by the binding con-

tract for the time period of the bid ContractLifeTime, ensure the file will be

available for consumption by relevant IoT devices. moreover in the IoTPatch- Pool Pay Per Piece the initial seed of the vendor is the same seed who is used throughout the process.

61 Chapter 8

Discussion

The two frameworks are operating in a field of trust-less permission-less IoT Patch delivery, they share many of the same components and requirements and in this section, I will discuss the similarities, differences, and present comparison between the two frameworks.

8.1 Common Requirements

as described in depth in the protocol section in each framework the Iot oik requires to hold the following:

pkik , vkik -Iot’spublicandprivatekey •

pkd -theiot’svendor’spublickey • this is the same demand for both methods. for communicating with blockchain ledger and to hold funds each vendor’s node and distributor node required to hold a wallet as well as full node communicating with the ledger. to support low power devices and reduce network and bandwidth demands there is no requirement for the IoT to hold any wallet but there is a need for a light client to validate contract information from the contract. as respect to the operating, both systems operate on node JS and can operate on various operating systems

62 8.2 Comparison

The common supporting components and the requirements between the two methods are vast, none the less the cornerstone of the methods described differ mainly in the use of the smart contract on the distributed ledger as well as the manner the patch is delivered to the IoT device. this contributes mainly to the economic feasibility differences between the methods, this will be described in-depth in the Economic Feasibility section 8.3 for comparing the two frameworks for must cases 1 vendor 1 distributor and 100 IoTs devices were used. where specified a more general case of 1 vendor 5 distributors and 100 devices were used. in general transaction, gas price was 2 GWEI with Ethereum priced as 180 $ the comparison in this section will include the following items

Costs -theamountofoverallgasconsumptioninordertocompleteupdate • delivery

Patch size limitations -constraintsonthepatchfileupdatesize •

Time to complete patch distribution -theoveralltimerequiredinorder • to complete a full patch update on a single Iot device

Network overhead -theadditionaldatatothepatchfileupdaterequiredin • order to complete a patch distribution

P2P integration - integration to an P2P service as IPFS or Torrent •

63 Criteria IoTPatchPool IoTPatchPool Pay Per piece Costs ~0.29$ per contract publish ~0.29$ per contract publish ~0.1 $ per file ~0.27 $ per file,

Patch size limi- 55 kB for current ZKCP im- Patch size not limited tations plementation

Time to com- setup and seeding phase short setup and seeding, plete distribute longer, enables faster overall longer for overall update update update distribution distribution

Network Over- thousands fold larger than the negligible additional data to head Patch size binaries transfer between participates and the smart contract

P2P integration utilize torrent to transfer data integrated with P2P net- but limited to 1 to 1 file ex- works, supported paralleliza- change due to file encryption tion of download from multi- ple sources

Table 8.1: Comparison between the IoTPatchPool and IoTPatchPool PPP frame- works

64 Gas consumption to complete distribute update phase

IoTPatchPool Pay Per Piece 7.52 105 ·

IoTPatchPool 3.02 105 ·

Figure 8.1: Gas consumption comparison

Costs • The gas costs required to complete patch update on a certain Iot device vary between the 2 methods, the IoTPatchpool requires 2 set of sepa- rate transactions to the ledger, the Commit and the Reveal transition. the IoTPatchpool-pay per piece method requires P time Redeem transaction per update where P is a configurable number of pieces set by the initial seeding of the Vendor. GAS estimations where done on the Rinkeby Test network in different time steps to reduce variance in measurements. the IoTPatchpool reacquires average of 237,636 gas unites and 64,117 gas unites for the Commit and the Revel transitions respectfully. the IoTPatchpool- pay per piece methods required Redeem transaction resulted on average of 75195 gas united per transaction. in the case of P=10 (system default) the total per IoT update summed at 751,950 gas united compared to 301,753 point in IoTPatchpool method. see Figure 8.1

Patch size limitations • The ZCKP component in IoTPatchpool method requires the construction of a zkSNARKs since this technology is relatively new it’s currently constrained to 55 kB.thelattermethoddoesn’tholdanyconstraintsandcansupportany patch file size.

Time to complete distribute update • The time required to complete the patch update determined by the shortest critical path of total actions. in both methods the communication to and

65 from the ledger are separate from the actual file transfer and are not in the critical path, a distributor can accumulate the proof of distribution from the IoT nodes and send transactions to redeem payment from the ledger on a separate schedule. it’s important to note that while a distributor can send redeem transactions on a different time - it has to be within the expiration time in the contract as well as being the first party among all other distributors to claim the payment for evaluation of the critical path time to execute on transactions on the Ethereum BlockChain a test was run on the Rinkeby network. The network data transfer rate was calculated as 10 Mbit per second and for the number of pieces set to 10 wherein which the distributors allow for 3 pieces of risk, meaning initiate Redeem every 3 pieces sent. as seen in 8.2 block time remains steady and as the main network is average is around the 15 seconds mark. both framework as any other blockchain project, an important security parameter is the block confirmation time, for testing purposes the confirmation block was set to 1. it is highly recommended to use ahighervalueforblockconfirmationinarealpredictionenvironment. as can be seen in Figure 8.3 publishing the contract is the same in both frame- works, initial seeding from Vendor to the Distributors is substantially longer in the IoTPatchPool due to the ZKCP generation and sending to the dis- tributors. the update distribution is slightly shorter in the former framework compare to the proposed IoTPatchPool Pay Per Piece for comparison of a more complete scenario a case of updating 100 IoT devices by a single distributor can be seen in Figure 8.4 and as expected it is shorter on the IoTPatchPool framework. this gap will grow further when the num- ber of devices increases and the number of pieces parameter increases. it is important to note that while in IoTPatchPool framework the main bottle- necks are the ZKCP key generation, the IoTPatchPool Pay Per Piece bottleneck is the ledger block time and latency, implementation on a more

66 Figure 8.2: Time (sec) to execute a Redeem transaction the Rinkeby Test net

scalable ledger or a second layer solution which does not depend on the block time will improve timing substantially.

Network Overhead • to estimate the network overhead we used a scenario of 1 vendor 5 distributors and 100 IoT devices, the patch size was 55 kB.theIoTPatchPool Pay Per Piece framework used default configuration of P=10. the IoTPatchPool protocol require the construction and the transfer of the proving, verification key and the proof, in comparison the IoTPatchPool Pay Per Piece re- quires mainly the signature exchange between IoT and distributor and the transaction data sent to the blockchain. see table 8.2

computing the overhaul required data to be transfer in the mentioned scenario the IoTPatchpool framework sums to 680 MB while the IoTPatchpool Pay Per piece sums to less than 1MB. when comparing to the actual patch size the overhead in the first framework is thousands fold larger than the actual patch size while in the later is negligible.

67 Figure 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

Figure 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

Framework Item Usage frequency Size in Bytes Both Patch update per IoT 55 IoTPATCHPool Proving Key Per distributor 135924430 IoTPATCHPool Verification Key per IoT 2675 IoTPATCHPool Proof per IoT 1411 IoTPATCHPool Commit per IoT 480 IoTPATCHPool Reveal per IoT 120 IoTPATCHPool PPP signature exchange per piece 320 IoTPATCHPool PPP Redeem per piece 540

Table 8.2: Summary of the main items and their size in both frameworks

68 P2P integration -oneofthedifferencesbetweenthetwoframeworksisthe • use of the Torrent network, in both torrent is used as a data-sharing tool. the IoTPatchpool framework uses this to distribute the file as a whole since the file is encrypted, it can not use the ability to download the Patch from different sources making it one to one transfer. as for the IoTPatchpool Pay Per piece framework, the original seed of the vendors is the actual seed which used to distribute the data, IoT can download the patch from the multi-sources and conduct a signature exchange with multi distributors willing to send the piece. this is an advantage in file availability, transfer rate, and parallelism.

8.3 Economic Feasibility Analysis

Permission-less blockchain such as Ethereum and Bitcoin face scalability issues that are translated into high latency and relatively high transactions fees. Hence, scal- ability is in the heart of discussions of transforming any blockchain-based solution to a profitable product. In this section, we analyze the economic feasibility of our proposed framework. Specifically, we attempt to understand what is the scalabil- ity improvement required by Ethereum for the framework to be profitable for both vendors and distributors.

Ethereum uses the concept of gas to discourage over-consumption of valuable resources by the miners. Every instruction on the Ethereum Virtual Machine (EVM) is valued in gas units (a table is given in the Ethereum yellow page [58]) and every block has a gas limit (which is derived by a dedicated algorithm). Although the gas value of each instruction is fixed, the gas price (set by the initiator of a transaction) is highly fluctuating, and mostly depends on both the load of the network and the current exchange price of Ether, the native token of Ethereum. Setting a low gas price to a transaction increases its confirmation time (i.e., decreases its chances of being mined in a near block). Hence, in our analysis, we set the initial gas price

9 to 2 gwei (2 10 Ether), which at the time of this writing provides an average ⇤ confirmation time of five minutes. ETH, the coin used in the ethereum network was

69 valued at 180$ per ETH.

The gas consumption of each transaction in the contract was calculated by using the prototype system. The results are presented in Table 8.3. A different cryp- tocurrency with a similar notion of smart contracts, such as Ethereum Classic, is typically traded at a fraction of that rate. For example, true to the time of this writing, Ethereum Classic is exchanged with 7.76 $ per "Ether Classic." Such a choice of a platform can significantly decrease the costs of execution of our proposed framework.

For IoTPatchpool the Create Factory transaction has the highest cost with 998,545 gas units and similiar costs in the IoTPatchpool-pay per piece frame- work, but it is performed only once for the entire framework. The second-highest transaction is Create Contract, which costs 814,526 gas units per every new up- date. as for IoTPatchpool-pay per piece Redeem transaction is was averaging at 75,195 gas unites and it is repeated per piece update. The Commit and Reveal transactions have relatively low gas costs, however, they are performed for each de- livery. Commit and Redeem are the only transaction types which are affected by the number of devices in the system because it needs to carry a Merkle proof of membership in the set of public keys of the relevant IoT devices. The measurement considered a Commit transaction with 21 hash values, which are enough to prove membership in a set of 221 devices. The costs in (ethereum) gas of the other types of transactions are roughly constant.

We also explored pricing policies of existing alternatives such as cloud computing services. Specifically, we focused on Amazon Web Services (AWS) that provide a dedicated service for both hosting and delivering data without initial setup payment, in a "pay-as-you-go" policy. At the time of writing the price for delivering 1TB of date is about 85$. It is reasonable to assume that, although the framework provides additional security attributes, vendors will not pay much more than this amount for the delivery of 1TB.

For the analysis, we considered real-life scenarios of updating 100k units of 3

70 Framework Transaction Type Usage Frequency Cost in $ IoTPatchPool Create Factory per framework setup 0.36 IoTPatchPool Create Contract per update file 0.29 IoTPatchPool Commit per delivery 0.08 IoTPatchPool Reveal per delivery 0.02 IoTPatchPool PPP Create Contract per update file 0.28 IoTPatchPool PPP Redeem per Piece 0.02

Table 8.3: A breakdown of the transactions costs [ A breakdown of the gas costs in $ for the different transactions of the proposed framework computed for the Ethereum network. Commit transaction is the only one that is affected by the number of overall devices in the system. Measurement considered a Merkle path of 21 hash values. USD costs were calculated with an 9 average gas price of 2 Gwei (2 10 Ether) and the conversion rate of 180$ per ⇤ Ether, which are real-world rates on November 15th, 2018.] smart televisions with firmware update file size of 170 MB, 800 MB and 1.6GB.1 2 3 the main reason to present different size patches is because the main differences between the traditional patch delivery costs are roughly a factor of the size - as can be seen AWS bill their customer by the mega, both frameworks rely on unutilized resources of the distributors.

The results of the assessment are presented in Figure 8.5.Ascanbeseen,IoTPatchpool is the more financially feasible one between the two and in the current Ethereum implementation will cost in a total of 10,863$ and the IoTPatchpool-pay per piece framework will sum to a total of 27,070$ with current implementation on top of the ethereum ledger is costly over AWS alternative, the first method is feasible only for a very large patch size and the second is costly over the alternative. given the ledger is subject to improvement, we wanted to look for the improvement needed to make the frameworks attractive, the point in which the Gas price is reduced by 24 the proposed frameworks becomes profitable for distributors to join for all the firmware update size. For example, a distributor with an Internet upload band- width of 30 Mbit per second that contribute his during night hours (from 22PM to 08AM) can deliver about 4TB per month. for theIoTPatchpool-pay

1http://www.dl.toshiba.com/tsb-dtv/NA/GB/EN/65L9363DF.html 2https://www.lg.com/us/support-product/lg-75SK8070PUA 3https://www.sony.co.uk/electronics/support/televisions-projectors-oled-tvs-android-/ kd-55af8#downloads

71 Frameworks costs compare to alternatives 30,000 IoTPatchPool PPP IoTPatchPool 25,000 AWS 170MB file AWS 800MB file AWS 1.6GB file 20,000

15,000

Total Cost in10 $ ,000

5,000

0 0 1 2 3 4 Factor of ledger scalability factor 2

Figure 8.5: Frameworks economic feasibility compared to alternatives [The cost of the proposed solutions, depends on the ledger scalability (factor 2). The costs were calculated based on Amazon S3 website and Ether value on November 15th, 2018] per piece framework, Considering a patch size of 1.6GBand a ledger improvement of 24, the Gas consumption for all transactions sums up to 42$. Thus, given the upper bound of AWS (85$ for delivering 1TB)adistributorcanearnupto297$a month for the patch deliveries. It should be mentioned that we consider such an improvement requirement very reasonable and feasible in the near future. Active research is currently examining alternatives to scale up the network (e.g., increasing the number of transactions per second, which is expected to reduce the gas price). Such alternatives vary from on- chain solutions such as Plasma and Sharding to off-chain solutions such as Truebit and payment channels, which are expected to improve the scalability in a factor of 10 to 100.4

4https://medium.com/@FEhrsam/scaling-ethereum%2Dtobillions-of-users-f37d9f487db1

72 Chapter 9

Conclusions and Future Work

this thesis has presented and explored two architectures for an incentivized dis- tributed delivery network of software updates to IoT devices, using smart contracts and a decentralized storage network.

the motivation for this work is to find a better use of resources and by maintaining the core principle of permissionless the system invites potentially a large audience of users, without dedicated hardware to contribute their idle machine and unused bandwidth to participate in this tasks of a patch update.

both frameworks are based on an economic model that allows compensation for work, the first, present fair exchange protocol for a trustless swap of digital payments for patch delivery, utilizing zero-knowledge contingent payments, where a smart contract functions as a distributed mediator. the second offer a gradual release in the form of Pay Per Piece where parities exchange commodity in rounds swapping part of the digital good in return of a partial payment.

this work has presented a prototype implementation and evaluated the economic feasibility of both frameworks.

both frameworks are lacking in different areas, the first limited by the constraints of the ZKsnarks protocol, making it worthy for distribution of small patch files and the second limited by economic feasibility making currently available solutions of storage and distribution more appealing

With regard to future research and improvement both frameworks are based

73 on a first layer application of the blockchain, meaning that they are based on the scalability of the network itself, an interesting direction will be implementing either of the frameworks on a second layer solution (i.e ) that will allow for low latency and reduce costs making this solution worthy for production.

74 Bibliography

[1] M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. Bursztein, J. Cochran, Z. Durumeric, J. A. Halderman, L. Invernizzi, M. Kallitsis, et al., Understand- ing the Mirai botnet, in: USENIX Security Symposium, 2017, pp. 1092–1110.

[2] E. Ronen, A. Shamir, A.-O. Weingarten, C. O’Flynn, Iot goes nuclear: Creating a zigbee chain reaction, in: Security and Privacy (SP), 2017 IEEE Symposium on, IEEE, 2017, pp. 195–212.

[3] B. Schneier, E-mail vulnerabilities and disclosure, ://www.schneier. com/blog/archives/2018/06/e-mail_vulnerab.html (June 2018).

[4] E. M. Schooler, D. Zage, J. Sedayao, H. Moustafa, A. Brown, M. Ambrosin, An architectural vision for a data-centric IoT: Rethinking things, trust and clouds, in: Distributed Computing Systems (ICDCS), 2017 IEEE 37th International Conference on, IEEE, 2017, pp. 1717–1728.

[5] N. Abbas, Y. Zhang, A. Taherkordi, T. Skeie, Mobile edge computing: A survey, IEEE Internet of Things Journal 5 (1) (2018) 450–465.

[6] D. Ramel, Hundreds of enterprise services reportedly hit by AWS outage,

https://virtualizationreview.com/articles/2018/03/05/aws-outage. aspx (Mar. 2018).

[7] Gnutella protocol specification 0.4, http://rfc-gnutella.sourceforge.net/ developer/stable/.

75 [8] B. Cohen, Incentives build robustness in BitTorrent, in: Workshop on Eco- nomics of Peer-to-Peer systems, Vol. 6, 2003, pp. 68–72.

[9] J. Benet, IPFS-content addressed, versioned, p2p file system, arXiv preprint arXiv:1407.3561.

[10] T. Warren, Microsoft to deliver Windows 10 updates using peer-

to-peer technology, https://www.theverge.com/2015/3/15/8218215/ microsoft-windows-10-updates-p2p (March 2015).

[11] G. Kreitz, F. Niemela, Spotify–large scale, low latency, p2p music-on-demand streaming, in: Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on, IEEE, 2010, pp. 1–10.

[12] E. Van der Sar, Bittorrent makes Twitter’s server

deployment 75x faster, https://torrentfreak.com/ -makes-twitters-server-deployment-75-faster-100716/ (July 2010).

[13] Using BitTorrent with Amazon S3, https://docs.aws.amazon.com/ AmazonS3/latest/dev/S3Torrent.html (2018).

[14] O. Leiba, Y. Yitzchak, R. Bitton, A. Nadler, A. Shabtai, Incentivized delivery network of iot software updates based on trustless proof-of-distribution, in: 2018 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), IEEE, 2018, pp. 29–39.

[15] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system (2008).

[16] CoinMarketCap, https://coinmarketcap.com/.

[17] L. Luu, B. Bünz, M. Zamani, Flyclient: Super light clients for

cryptocurrencies, https://scalingbitcoin.org/stanford2017/Day1/ flyclientscalingbitcoin.pptx.pdf (2017).

76 [18] A. Kiayias, A. Miller, D. Zindros, Non-interactive proofs of proof-of-work, Tech. rep., Cryptology ePrint Archive, Report 2017/963, 2017. Accessed: 2017-10-03 (2017).

[19] N. Szabo, The idea of smart contracts, ’s Papers and Concise Tuto- rials 6.

[20] V. Buterin, et al., A next-generation smart contract and decentralized applica- tion platform, white paper.

[21] Rsk white paper, https://docs.rsk.co/RSK_White_Paper-Overview.pdf.

[22] R. Gennaro, C. Gentry, B. Parno, M. Raykova, Quadratic span programs and succinct NIZKs without PCPs, in: Annual International Conference on the Theory and Applications of Cryptographic Techniques, Springer, 2013, pp. 626– 645.

[23] N. Bitansky, A. Chiesa, Y. Ishai, O. Paneth, R. Ostrovsky, Succinct non- interactive arguments via linear interactive proofs, in: Theory of Cryptography, Springer, 2013, pp. 315–333.

[24] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, M. Virza, SNARKs for C: Verifying program executions succinctly and in zero knowledge, in: Advances in Cryptology–CRYPTO 2013, Springer, 2013, pp. 90–108.

[25] E. Ben-Sasson, A. Chiesa, E. Tromer, M. Virza, Succinct non-interactive zero knowledge for a von Neumann architecture., in: USENIX Security Symposium, 2014, pp. 781–796.

[26] B. Parno, J. Howell, C. Gentry, M. Raykova, Pinocchio: Nearly practical veri- fiable computation, in: 2013 IEEE Symposium on Security and Privacy, IEEE, 2013, pp. 238–252.

[27] Bitcoin Wiki, Zero knowledge contingent payment, https://en.bitcoin.it/ wiki/Zero_Knowledge_Contingent_Payment (2018).

77 [28] Bitcoin Wiki, Bitcoin script, https://en.bitcoin.it/wiki/Script (2018).

[29] S. Bowe, Pay-to-sudoku (2016).

[30] H. Pagnia, F. C. Gärtner, On the impossibility of fair exchange without a trusted third party, Tech. rep., Technical Report TUD-BS-1999-02, Darmstadt University of Technology . . . (1999).

[31] N. Asokan, M. Schunter, M. Waidner, Optimistic protocols for fair exchange, Citeseer, 1996.

[32] M. Blum, How to exchange (secret) keys, in: Proceedings of the fifteenth annual ACM symposium on Theory of computing, ACM, 1983, pp. 440–447.

[33] K. Liu, D. Zou, H. Jin, UaaS: software update as a service for the IaaS cloud, in: Services Computing (SCC), 2015 IEEE International Conference on, IEEE, 2015, pp. 483–490.

[34] X. Zhen-hai, Y. Yong-zhi, Automatic updating method based on maven, in: Computer Science & Education (ICCSE), 2014 9th International Conference on, IEEE, 2014, pp. 1074–1077.

[35] T. Yu, V. Sekar, S. Seshan, Y. Agarwal, C. Xu, Handling a trillion (unfixable) flaws on a billion devices: Rethinking network security for the Internet-of- Things, in: Proceedings of the 14th ACM Workshop on Hot Topics in Networks, ACM, 2015, p. 5.

[36] Y. Onuma, Y. Terashima, R. Kiyohara, ECU software updating in future vehicle networks, in: Advanced Information Networking and Applications Workshops (WAINA), 2017 31st International Conference on, IEEE, 2017, pp. 35–40.

[37] C. Huth, P. Duplys, T. Güneysu, Secure software update and IP protec- tion for untrusted devices in the Internet of Things via physically unclonable functions, in: Pervasive Computing and Communication Workshops (PerCom Workshops), 2016 IEEE International Conference on, IEEE, 2016, pp. 1–6.

78 [38] D.-Y. Kim, S. Kim, J. H. Park, Remote software update in trusted connection of long range IoT networking integrated with mobile edge cloud, IEEE Access.

[39] B. Lee, J.-H. Lee, Blockchain-based secure firmware update for embedded de- vices in an Internet of Things environment, The Journal of Supercomputing 73 (3) (2017) 1152–1167.

[40] A. Boudguiga, N. Bouzerna, L. Granboulan, A. Olivereau, F. Quesnel, A. Roger, R. Sirdey, Towards better availability and accountability for IoT updates by means of a Blockchain, in: IEEE Security & Privacy on the Blockchain (IEEE S&B 2017) an IEEE EuroS&P 2017 and Eurocrypt 2017 affiliated workshop, 2017.

[41] J. Lee, Patch transporter: Incentivized, decentralized software patch system for WSN and IoT environments, Sensors 18 (2) (2018) 574.

[42] S. Popov, The Tangle (2017).

URL https://iota.org/IOTA_Whitepaper.pdf

[43] E. Adar, B. A. Huberman, Free riding on gnutella, First monday 5 (10).

[44] D. Hughes, G. Coulson, J. Walkerdine, Free riding on Gnutella revisited: the bell tolls?, IEEE distributed systems online 6 (6).

[45] S. Kaune, R. C. Rumin, G. Tyson, A. Mauthe, C. Guerrero, R. Steinmetz, Unraveling BitTorrent’s file unavailability: Measurements and analysis, in: Peer-to-Peer Computing (P2P), 2010 IEEE Tenth International Conference on, IEEE, 2010, pp. 1–9.

[46] S. Wilkinson, T. Boshevski, J. Brandoff, V. Buterin, Storj a peer-to-peer cloud storage network.

[47] D. Vorick, L. Champine, Sia: Simple decentralized storage.

[48] Filecoin: A decentralized storage network, https://filecoin.io/filecoin. pdf (2017).

79 [49] J. Poon, T. Dryja, The Bitcoin Lightning network: Scalable off-chain instant payments, See https://lightning. network/lightning-network-paper. pdf.

[50] A. Miller, I. Bentov, R. Kumaresan, P. McCorry, Sprites: Payment channels that go faster than lightning, arXiv preprint arXiv:1702.05812.

[51] D. Dolev, A. Yao, On the security of public key protocols, IEEE Transactions on information theory 29 (2) (1983) 198–208.

[52] I. Baumgart, S. Mies, S/kademlia: A practicable approach towards secure key- based routing, in: Parallel and Distributed Systems, 2007 International Con- ference on, IEEE, 2007, pp. 1–8.

[53] R. C. Merkle, Protocols for public key cryptosystems, in: Security and Privacy, 1980 IEEE Symposium on, IEEE, 1980, pp. 122–122.

[54] P. Maymounkov, D. Mazieres, Kademlia: A peer-to-peer information system based on the XOR metric, in: International Workshop on Peer-to-Peer Systems, Springer, 2002, pp. 53–65.

[55] D. Boneh, C. Gentry, B. Lynn, H. Shacham, Aggregate and verifiably encrypted signatures from bilinear maps, in: International Conference on the Theory and Applications of Cryptographic Techniques, Springer, 2003, pp. 416–432.

[56] D. Boneh, M. Drijvers, G. Neven, Compact multi-signatures for smaller , in: International Conference on the Theory and Application of Cryptology and Information Security, Springer, 2018, pp. 435–464.

[57] I. Eyal, E. G. Sirer, Majority is not enough: Bitcoin mining is vulnerable, in: International conference on financial cryptography and data security, Springer, 2014, pp. 436–454.

[58] G. Wood, Ethereum: A secure decentralised generalised transaction ledger,

https://ethereum.github.io/yellowpaper/paper.pdf (2018).

80

צקת י ר

בע ו הד ז ה יצמ הג תא IOTPATCHPool pay per piece עמ ר תכ הצפה ועמ תדד רמת י צ םי לשל יצירתתדומהפ כדע ו נ י ג הסר לש שכמה י ר י ם ״ יא טנרטנ לש ״םירבדה צמאב תוע הריסמ יתגרדה ת

עמה ר תכ תשמתשמ יתרשב וסחא ן ובמ םירז וקתב הו רוהל ד ה סמוע שמ ר ת י ה י צ ר ן להתב י ך הצפהה לש וכדע נ י הסרג לוטיבלו תודוקנ לשכ נדחי תי . גינב דו תוכרעמל הצפה תססובמ תססובמ הצפה תוכרעמל דו שמתשמ ל שמתשמ ( גכ ו ן וט טנר ) רשא תלבוס ישוקמ הצפה לש םיצבק אל ירלופופ י ם , , רפה וקוטו ל שמתשמ וחב ז םי ח םיכ ולבב ׳צק י ן המישרכ לש סקנפ ובמ רז ליבשב עיצהל עיצהל ליבשב רז ובמ סקנפ לש המישרכ ן י ׳צק מת ר י צ י ם ל פמ י צ י ם כבו ך דדועל הצפה לש דעה כ ו נ י ם .

רפה וקוטו ל שמתשמ וחב הז ח םכ ל אל אשרה ה ו אלל רד השי לש ומא ן ךכב רשפאמ רשפאמ ךכב ן ומא לש השי רד ישמתשמל ם םישדח לב י רד תושי ומח הד ימ דחו תו ףתתשהל להתב י ך .הצפהה

ורצי ן לש ירישכמ ״ יא טנרטנ לש דה ב ר י ״ם י פ סר ם וח הז םכח ו יקפי ד ומגתכ ל וצב הר לש עבטמ עבטמ לש הר וצב ל ומגתכ במ ו ז ר לכל ףתתשמ רשא קפסי וה החכ הצפהל לש דעה כ ו ן וא קלח ממ נ ו . פמה י צ י ם םיציפה .ונמ רחתמה י ם פהב הצ לש דעה כ ו ן ושמתשי יבאשמב בשחמה ן הו ירושיק תו אל י רטנ טנ קה י י .םימ

נחנא ו שמ םישמת ורקיעב ן לש הריסמ רדה תיתג רתפכ ו ן לש הלחה וה תנג וכיה הל לצפל וק ץבץ רפסמל םיקלח רשפאמ לכל דצ דירוהל תא וכיסה ן ושארה נ י היסמב ו נבל תו ומא ן לככ לככ ן ומא תו נבל ו היסמב י נ ושארה ן וכיסה תא דירוהל דצ לכל רשפאמ םיקלח רפסמל חהש ל תפ ה ק ו ב ץ קתמ ד תמ .

בעב ו הד גצומ חותיפ לש וחה הז םכחה ומכ ןכ תינ ח ומ ל תוטיש תורחא ו חותינ לכלכ י לש לש י לכלכ תפה ור ן .

וא נ תטיסרבי ןב ןוירוג בגנב

תזת גמ י רטס

תכרעמ הצפה עמ ו תדד רמת י צ י ם לש כדע ו נ י הסרג לש

אה י נ רט נ ט לש רבדה םי אצמאב ו ת סמ י הר תיתגרדה

גמ :שי :החנמ

באיחי קחצי רפ ו פ ׳ ףסא אתבש י

רוביח הז המ ו ו ה קלח רדהמ ושי ת תלבקל ראות גמ רטסי הב נ הסד

הקלחמב נהל תסד כרעמ ו ת הנכות עדימו

קפה ו הטל עדמל י הה נ הסד

תח י תמ רבחמ ...... : . . ראת י ך :5/5/2020 רושיא החנמ ...... : ראת י ך :

וי ר" תדעו ראות נש י תקלחמ י ת ....: ...... ראת י ך : 06/05/2020

וא נ תטיסרבי ןב ןוירוג בגנב

תזת גמ י רטס

תכרעמ הצפה עמ ו תדד רמת י צ י ם לש כדע ו נ י הסרג לש

אה י נ רט נ ט לש רבדה םי אצמאב ו ת סמ י הר תיתגרדה

גמ :שי :החנמ

באיחי קחצי רפ ו פ ׳ ףסא אתבש י

רוביח הז המ ו ו ה קלח רדהמ ושי ת תלבקל ראות גמ רטסי הב נ הסד

הקלחמב נהל תסד כרעמ ו ת הנכות עדימו

קפה ו הטל עדמל י הה נ הסד

27/2/2019