APPLICATION OF NETWORK FOR THE USE OF INFORMATION SHARING by Linir Zamir

A Thesis Submitted to the Faculty of The College of Engineering and Computer Science in Partial Fulfillment of the Requirements for the Degree of Master of Science

Florida Atlantic University Boca Raton, FL August 2019 Copyright 2019 by Linir Zamir

ii

ACKNOWLEDGEMENTS

I would like to thank my committee members: Dr. Feng-Hao Liu, my commit- tee chair; Dr. Mehrdad Nojoumian and Dr. Elias Bou-Harb for their encouragement, insightful comments and hard questions. I would also like to thank my mother, who supported me with love and understanding. Without you, I could never have made it this far in my academical studies and generally in life.

iv ABSTRACT

Author: Linir Zamir Title: Application of Blockchain networkfor the use of Information Sharing Institution: Florida Atlantic University Thesis Advisor: Dr. Feng-Hao Liu Degree: Master of Science Year: 2019

The Blockchain concept was originally developed to provide security in the network, where trust is achieved through the provision of an agreed-upon and immutable record of transactions between parties. The use of a Blockchain as a secure, publicly distributed is applicable to fields beyond finance, and is an emerging area of research across many other fields in the industry. This thesis considers the feasibility of using a Blockchain to facilitate secured infor- mation sharing between parties, where a lack of trust and absence of central control are common characteristics. Implementation of a Blockchain Information Sharing system will be designed on an existing Blockchain network with as a communicative party members sharing secured information. The benefits and risks associated with using a public Blockchain for information sharing will also be discussed.

v APPLICATION OF BLOCKCHAIN NETWORK FOR THE USE OF INFORMATION SHARING

1 Introduction ...... 1 1.1 Preliminaries...... 2 1.1.1 and Cryptocurrency...... 2 1.1.2 Blockchain Technology...... 2 1.1.3 Bitcoin...... 6 1.1.4 ...... 8 1.1.5 EOSIO...... 9 1.1.6 Byzantine Generals Problem...... 10 1.1.7 (PoW)...... 14 1.1.8 (PoS)...... 16 1.1.9 Smart Contracts...... 16 1.1.10 Information Sharing...... 18 1.2 Problem Definition...... 20

2 Literature Review ...... 21 2.1 Protecting Personal Data...... 21 2.2 Medical Implementation...... 24 2.3 Technology Implementations...... 27 2.3.1 Mobile Technology...... 27 2.3.2 Smart Cars...... 29 2.3.3 Cybersecurity...... 30 2.3.4 Big Data...... 32

vi 3 Research Methods and Analysis ...... 35 3.1 Prerequisites...... 35 3.2 Design...... 37 3.2.1 System Design...... 37 3.2.2 Implementation...... 39 3.2.3 Testing...... 41 3.2.4 Types of Data...... 43 3.3 Analysis...... 43 3.3.1 Resources...... 44 3.3.2 Performance...... 46 3.3.3 CIA Model...... 47 3.3.4 STRIDE Model...... 48

4 Concluding remarks and future directions ...... 51 4.1 Conclusion...... 51 4.2 Future Work...... 52

Bibliography ...... 53

vii CHAPTER 1 INTRODUCTION

Secured Information Sharing has always been an interest in the Crypto Security community, especially in the recent years with the increase in exposure technology. There are many industries that need to have efficient, and secured Information Sharing as part of their activities. Solving This problem is not an easy task, and it is good to look at different technologies as a possible solution for secured sharing platform. One such platform is the Blockchain. Blockchain technology is an open, decentralized digital ledger where transactions are recorded between people so that the record can’t be altered without the alternation of all subsequent blocks on the network. This technology was first introduce in 2008 by a Satashi Nakamoto [1] to serve as the public transaction ledge of the cryptocurrency Bitcoin, a digital currency that has been used ever since. Bitcoin, the decentralized peer-to-peer digital currency, is the most popular example that uses Blockchain technology, but Blockchain technology has worked flawlessly and found wide range of applications in both financial and non-financial world. The wide range of applications include Authentications, Electronic music industry, storage and much more [2]. One possible application for the Blockchain technology is to use it as the platform for Secured Information Sharing. This application has only recently been discussed, and there is much more to learn in that area.

1 1.1 PRELIMINARIES

1.1.1 Digital Currency and Cryptocurrency

Digital currency is a payment method which exists only in electronic form and is not tangible. Digital currency is transferred between parties with the help of some algorithm in order to make the transaction secured. Digital currencies can be used to purchase goods and services but can also be restricted to certain online communities such as a gaming or social networks. Digital Currency is the term used to describe all electronic money, that includes both and cryptocurrency. It is only available in digital or electronic form and unlike a bill or a coin, it is intangible. This currency is usually decentralized, and the lack of intermediaries means transactions are typically instantaneous and have no or very little fees. Cryptocurrency are currencies that have encryption algorithm as part of its creation. Now a days, many operate on a Blockchain decentralized systems without the need for a trusted third-party. Unlike cash, which is entirely anonymous, transactions carried out with cryptocurrencies are stored.

1.1.2 Blockchain Technology

Blockchain, as the name suggests, is a chain of blocks that contains information. The first time this type of data structure was introduced was in 1990 by Stuart Habert and W.Scott Strornetta [3] and was originally intended to timestamp digital documents so that it is not possible to temper with them. However, it was mostly unused until it was adapted by an unknown person goes by the name of Satoshi Nakamoto in 2008 [1] as a core component to support transactions of the digital currency, specifically Bitcoin. These transactions are stored on a constantly growing ledger, as new transactions, or blocks, are added to it. Each block includes the

2 cryptographic hash of the prior block (a timestamp and a link), linking the two. The linked blocks form a chain, hence the name ’Blockchain’. Blockchain Technology is based on the idea that each participant has access to a shared ledger. This system provided a reasonable solution to the problem of establishing trust in an unsecured environment without relying on a third-party. This technology gives a solution to a problem with digital cash, the double-spend problem [4], a case where an individual can use the same ’coin’ for more than one purchases. Blockchain technology solves the double-spend problem by combining the P2P (peer-to-peer) file sharing technology with public-key cryptography [5] to make a new form of digital money. Coin ownership is recorded in the public ledger and confirmed by cryptographic protocols and the mining community. The Blockchain is trustless in the sense that a user does not need to trust the other party in the transaction, or a central interme- diary, but does need to trust the system: the Blockchain protocol software system. The ”blocks” in the chain are groups of transactions posted sequentially to the ledger, that is, added to the ”chain”. The basic idea behind the Blockchain Technology is that it allows parties to transact digital assets using a P2P network that stores these transactions in a distributed way across the network. The owners of the assets, and the transactions involving change of ownership, are registered on the ledger by the use of public key cryptography and digital signatures. Every transaction is validated by the nodes in the network by employing some kind of a ’consensus mechanism’ (a consensus protocol). This works as follows. Whenever a transaction is entered into the P2P network, the nodes first validate the transaction. If the nodes agree on its legitimacy, they confirm the transaction and this decision is laid down in a block. This new block is added to the previous chain of blocks and is then locked. In this way, the latest block maintains a shared, agreed-upon view of the current state of the Blockchain. All transactions are stored in a ledger which all involved nodes hold a copy of. For security reasons,

3 Figure 1.1: Example of Blockchain [6] each block includes the hash of the prior block. The hash is used to identify the information and to ensure the integrity of the data. The linked blocks form a chain, hence the name Blockchain. A ledger contains the shared and agreed-upon state of the Blockchain and the list of transactions that were processed by the nodes. Every node in this decentralized system has a copy of the Blockchain which is continuously synchronized with the other copies. In this way there is no centralized point of vulnerability that computer hackers can exploit. Taking one node down will not lead to a breakdown of the chain of blocks. An example of such a list is given in Fig.1.1. One security issue is that computers now a days can be extremely fast, and they can tamper with a specific block, and all the following blocks, and in that way to ’fool’ the community by removing or adding transactions that were not in the origi- nal Blockchain. This, however is dealt with using ’Proof-of-work’. It’s a mechanism that basically slows down the creation of new blocks [7]. In Bitcoin, for example, it takes about 10 minutes to add a new block and add it to the chain. This mechanism makes it hard to tamper with the blocks, since tampering with one block, makes it so the adversary needs to calculate the proof-of-work for all the following blocks. Since its origin in 2009, Blockchain technology use cases have expanded into a wide range of sectors beyond the financial domain such as economic, political, humani- tarian, and legal system. it is clear that this is potentially an extremely disruptive

4 technology that could have the capacity for re-configuring all aspects of society and its operations. For organization and convenience, the different kinds of existing and potential activities in the Blockchain revolution are broken down into three categories, Blockchain 1.0, 2.0, and 3.0 [8]. Blockchain 1.0 is currency, the deployment of cryptocurrencies in applications re- lated to cash, such as currency transfer, remittance, and digital payment systems. Blockchain 2.0 is contracts, the entire slate of economic, market, and financial appli- cations using the Blockchain that are more extensive than simple cash transactions, stocks, bonds, futures, loans, mortgages, titles, smart property, and Smart Contracts. Blockchain 3.0 is Blockchain applications beyond currency and finance, in the areas of government, health, science, culture, arts and more.. The following chapters discusses a new way of Blockchain implementation, and how it can be used to synchronize any number of drones as a decentralized environment [9].

Types of Blockchain

Blockchain can be public or private, depending on the permission level [10]. Here are the three common types:

1. Public Blockchain - A public Blockchain is permissionless, and anyone can easily participate and validate the transactions. Transactions are public and anonymous/pseudonymous. The Blockchain is maintained by the public com- munity, so there is the highest level of decentralized trust. Bitcoin is the pioneer public Blockchain. Bitcoin, [11], and Bitshares [12] are few examples of public . Ethereum [13] is the most popular public Blockchain de- ployment.

2. Federated/Permissioned Blockchain - A federated Blockchain is a permis- sioned Blockchain operating under the leadership of a group often called the

5 consortium. Predefined consortium nodes control the consensus. The transac- tions may or may not be public. Some examples includes R3 Corda [14] and B3i.

3. Private Blockchain - A private Blockchain is a permissioned Blockchain cen- tralized to one governing organization. Transactions are validated internally and may or may not be public readable. Private Blockchains usually have faster block times and can higher transaction throughput. However, these are vulnerable to security breaches. The value of private Blockchain can be seen as a trust transformer where trust is based on an algorithm rather than an authority.

1.1.3 Bitcoin

Bitcoing is money, cryptocurrency, and is used for buying and selling over the inter- net. This cryptocurrency works on three different layers [8]. The first layer is the underlying technology, the Blockchain. The Blockchain is the decentralized transpar- ent ledger with the transaction records. The database that is shared by all, updated by miners, monitored by everyone and controlled by no one. The middle layer is the software system that transfers the currency over the Blockchain ledger. Then, the top layer is the currency itself, Bitcoin. There are hundreds of different cryptocurrencies, of which Bitcoin is the first and largest. Bitcoin has been growing rapidly in the past couple of years, see Fig.1.2. The key point is that these three layers are the general structure of any modern cryptocurrency. Blockchain, protocol and currency. Each coin is typically both a protocol and a currency, and it may have its own Blockchain or may run on the Bit- coin Blockchain. For example, the currency runs on the Litecoin protocol, which runs on the Litecoin Blockchain [15]. A separate blockchain means that the coin has its own decentralized ledger (in the same structure and format as the Bitcoin 6 Figure 1.2: Bitcoin Graph

Blockchain ledger). Other protocols, such as , have their own currency (XCP) and run on the Bitcoin Blockchain. Bitcoin, as explained before, was created in 2008 by an unknown person or entity using the name Satoshi Nakamoto [1]. Payments using the decentralized virtual cur- rency are recorded in a public ledger that is stored on manypotentially allBitcoin user’s computers, and continuously viewable on the Internet. Bitcoin is the first and largest decentralized cryptocurrency. They are created as a reward for computational processing work, known as mining, in which users offer their computing power to ver- ify and record payments into the public ledger. Individuals or companies engage in mining in exchange for transaction fees and newly created . Besides mining, Bitcoins, like any currency, can be obtained in exchange for fiat money, products, and services. Users can send and receive Bitcoins electronically for an optional transaction fee using wallet software on a personal computer, mobile device, or web application.

7 1.1.4 Ethereum

Ethereum was first introduced by Vitalik Buterin in 2014 [13] and addressed several limitations of the Bitcoin’s scripting language. The main contributions are full Turing- completeness, meaning that Ethereum supports all types of computations, including loops. Then Ethereum supports the state of the transaction, as well as several other improvements over the Blockchain structure. It provides an abstract layer enabling anyone to create their own rules for ownership, formats of transactions, and state transition functions. This is done by involving Smart Contracts, a set of cryptographic rules that are executed only if certain conditions are met. The Ethereum state is consisted of accounts, where each account has a 20-byte address and state transitions. The world state is a mapping between addresses and account states [16] Bitcoin mining is based on the so-called Proof of Work (PoW) algorithm. Within this concept, the probability of one mining a block is based on the amount of computa- tional work he has done. The mining reward will be given to the very first miner who manages to solve a complex cryptographic puzzle of each block. As per the concept of PoW, each network miner competes with all of the other in using computational power. Ethereum mining, on the other hand, is based on another algorithm called Proof of Stake (PoS). The probability of validating a new block within this consensus algorithm is determined by how large of a stake a certain person holds, or, in other words how many coins does he have. Within the PoS algorithm, block validators dont receive a block reward they instead collect network fees as their reward. In the case of Ethereum, the reward is called gas. With PoS there are no mathematical puzzles to solve and the creator of the new block is chosen in a deterministic way. This explains later in the ’PoS’ section. One of the nicest things about Ethereum, is how easy it is to write and to deploy

8 on this network. The Ethereum uses different high level programming languages, such as , a JavaScript based language which allows to develop contracts and compile them to Ethereum Virtual Machine (EVM) for easy access. Serpent, a Python based language which can be used to develop contracts and com- pile to EVM. It is much more clean and simple. LLL, stands for Lisp Like Language, a low level language similar to Assembly. It is meant to be very minimalistic and fast.

1.1.5 EOSIO

EOSIO is a recently new Blockchain platform that aims to completely remove the transaction fees, and to be able to process millions of transactions per seconds. This ease of use, and how fast it is makes it a perfect candidate for many other decentralized applications which are outside of the Cryptocurrency scope. It was introduce in 2017, and started June 1st 2018 [?]. The fast processing of transactions per second is probably one of the best thing about this new platform, it means that it can deploy and process Smart Contracts very quickly! For comparison, Ethereum which is a very popular Smart Contract Blockchain, can only handle 15 transactions per second. A good example to understand why this is such a big deal, is to imagine having an app running on EOSIO, where there is a wall and every user can leave a message using Smart Contract. On Ethereum, only 15 users per seconds will be able to to send a message at the same time. With EOSIO, a lot more. Another great thing about EOSIO is its usability. It uses a ++ based language that is easy to use which makes it perfect for developers to develop new Smart Contract based applications. As explained before, Bitcoin uses Proof-of-Work, Ethereum uses Proof-of-Stake, and now EOSIO uses Delegated-Proof-of-Stake (DPoS) [17]. DPoS is different from PoS in that anyone who holds a tokens on a Blockchain in the EOSIO software can select the block producers through a continuous approval voting system. Anyone can participate in the block producer election and they will be given an opportunity

9 to produce blocks proportional to the total votes they receive relative to all other producers. Once important aspect of EOSIO is its Multi Index Tables. These tables are the systems way to cache data in RAM for quick access. These tables are stored on the EOSIO RAM cache, and they are a way for the Smart Contracts to access stored data. Multi Index Tables provide a fast to access data store and are a practical way to store data for use in Smart Contract. The Blockchain records the transactions, the Multi Index Tables stores the data.

1.1.6 Byzantine Generals Problem

Until Blockchain, digital currency was, like any other digital asset, infinitely copyable, and there was no way to confirm that a certain amount of digital cash had not already been spent. There had to be some sort of trusted third party (Bank, for example) in all transactions, which kept a ledger confirming that each portion of digital cash was spent only once. This is the double-spend problem. A related problem is the Byzantine General’s Problem, first introduced by Lamport, Shostak and Pease in 1982 [18]. This problem refers to an army of generals in which each general commands one part of the army and are situated at distributed locations. The generals can communicate with one another only by messenger, and together the generals must make a common decisions whether to attack, retreat or take any other actions. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement. A general can pretend to be a correct one, but presenting different answers to different generals to manipulate the outcomes. The goal for this problem is to achieve a secured consensus, in which the generals attack as planned by the right generals, and not the traitors. In this section, this problem is transformed to a commander-lieutenant setup, such as the one in Lamport,

10 Shostak and Pease paper. In order to achieve consensus here, the commander and every lieutenant must agree on the same decision (for simplicity attack or retreat).

Definition 1.1.1. Byzantine Generals Problem A commanding general must send an order to his n − 1 lieutenant generals such that

• All loyal lieutenants obey the same order

• If the commanding general is loyal, then every loyal lieutenant obeys the order he sends

Without diving too much into this problem, the algorithm to reach consensus in this case is based on the value of majority of the decisions a lieutenant observes. Lamport, Shostak and Pease describe such an algorithm that can reach a consensus as long as 2/3 of the actors are honest. If the traitors are more than 1/3, consensus is not reached, the armies do not coordinate their attack and the enemy wins.

Theorem 1. For any m, Algorithm OM(m) reaches consensus if there are more than 3m generals and at most m traitors.

Proof. Algorithm OM(0)

1. The commander sends his value to every lieutenant

2. Each lieutenant uses the value he receives from the commander, or uses the value RETREAT if he receives no value

Algorithm OM(m), m > 0

1. The commander sends his value to every lieutenant

2. For each i, let vi be the value lieutenant i receives from the commander, or else be RETREAT if he receives no value. Lieutenant i acts as the commander in

Algorithm OM(m−1) to send the value vi to each of the n−2 other lieutenants 11 3. For each i, and each i 6= j, let vi be the value lieutenant i received from lieu- tenant j in step (2) (using Algorithm OM(m − 1)), or else RETREAT if he

received no such value. Lieutenant i uses the value majority (v1, ..., vn−1)

This can be more clear with a visual example. Let C be Commander and Li be lieutenant i.

Figure 1.3: L3 is a traitor - L2 point of view [18]

Fig. 1.3 shows lieutenant 2’s point of view. Following the algorithm, the steps should be:

1. Commander sends v to all lieutenants

2. L1 sends v to L2, L3 sends x to L2

3. L2 reads the majority of values (v, v, x) == v

The final decision is the majority vote from L1,L2,L3 and as a result consensus has been achieved. One very clear distinction we have between this model and Blockchain, is the fact that in Blockchain we are dealing with decentralized system. For that, we are then going to assume that the Commander is the traitor one. If the algorithm

12 Figure 1.4: Commander is a traitor [18] handles that case, we can easily reduce this problem to a decentralized system. Fig.1.4 shows the case where the Commander is the traitor. Following the algorithm, again, the steps should be:

1. Commander sends x, y, z to L1,L2,L3 respectively

2. L1 sends x to L2,L3 ; L2 sends y to L1,L3 ; L3 sends z to L1,L2

3. L1 ← (x, y, z); L2 ← (x, y, z); L3 ← (x, y, z)

They all have the same value and thus consensus is reached. Even if x, y, z are all different, the value of the majority of (x, y, z) is the same for all 3 lieutenants. In the case they are all different commands, we can assume that they act on the default option, RETREAT. However, this algorithm is only one possible solution to the problem, and it is one example of the Byzantine Fault Tolerance. Byzantine Fault Tolerance (BFT) is the characteristic which defines a system that tolerates the class of failures that belong to the Byzantine General’s Problem [19]. Byzantine Faults are the most severe and 13 difficult to deal with. Byzantine Fault Tolerance has been needed in airplane engine systems, nuclear power plants and pretty much any system whose actions depend on the results of a large amount of sensors. Other variations exist which make solving the problem easier, including the use of digital signatures or by imposing communication restriction between the peers in the network. Blockchains are decentralized ledges which, by definition, are not controlled by a cen- tral authority. Due to the value stored in these ledgers, bad actors have huge economic incentives to try and cause faults. That said, Byzantine Fault Tolerance, and thus a solution to the Byzantine Generals Problem for Blockchains is much needed. In the absence of BFT, a peer is able to transmit and post false transactions effectively nullifying the blockchains reliability and there is no central authority to take over and repair the damage. The big breakthrough when Bitcoin was invented, was the use of Proof-of-Work as a probabilistic solution to the Byzantine Generals Problem.

1.1.7 Proof of Work (PoW)

The algorithm in the previous section is a valid solution to achieve BFT. However, this solution has some issues such as not being efficient, and it has the constraint that less than a third of the network is dishonest. Proof-of-work (PoW) is the most popular consensus algorithm being used by curren- cies such as Bitcoin and Ethereum. In Blockchain, this algorithm is used to confirm transactions and produce new blocks to the chain. The key part is the PoW aspect of the hashchain [20]: a block contains information must be set in such a way that the hash of the entire block is smaller than a known target, which is typically a very small number. Given that the hash function used is secured, this problem is NP-Hard [21]. This means that the solution to such a problem is possible only by bruteforce, and is depends on the available computing power. It also means that once a solu- tion is achieved, it is easy to validate it. Actors who try and solve this problem also

14 called miners. In fact, in Bitcoin, the difficulty of mining is adjusted dynamically throughout the lifetime of the system. The adjustment is made with respect to the block-mining rate and, indirectly, with respect to the computational power of nodes participating in the system, to maintain the expected block-mining rate at roughly one block every 10 min [1]. This latency of 10 minutes (per block) is often referred to as the block frequency and is one of the two critical ”magic numbers” in Bitcoin, the other being the block size, which is set in Bitcoin to 1 MB [22]. The mining process is based on consensus algorithm to elect a leader who will decide the contents of the next block. Whenever a new block is mined, The first miner to complete the mining process gets to be the leader of the block. The elected leader also responsible for broadcasting the block to the network, so that other peers can verify the validity of its contents. the block leader then gets rewarded with some cur- rency (block reward, transaction fees) and thus are motivated to keep mining. After a block has been mined, other nodes verify the validity of the block by checking that the hash of the data of the block is less than the preset number. The most widely used proof-of-work scheme is based on SHA-256 and was introduced as a part of Bitcoin and few other cryptocurrencies. The problem with PoW is that it was depends on the computational power, and so people started to invest in large machines that capable of solving the problem relatively fast. This process consumes a lot of energy, and it gives more awards to people with better equipment, better computational power. The better equipment, the higher the chance to create the next block, and thus receive the mining awards. Another problem with PoW was that miners started to organize in groups called ’mining pools’ where they combine their computational power, and then if they create the next block, they distribute the award evenly across everyone in the pool. This brings the two main problem with PoW. The first being the amount of electricity used. Early calculations indicated that the energy requirement of the protocol were comparable to that of a small country [23]. The second problem is that

15 PoW encourage the use of ’mining pools’ which makes the Blockchain more central- ized in oppose to decentralized. This problem called for a substitution of other protocol, more energy efficient, that can provide similar guarantees. A natural alternative mechanism is called ”Proof of Stake”.

1.1.8 Proof of Stake (PoS)

Cryptocurrency with Proof of Stake, was first introduce in 2012 by King and Nadal [24]. Rather than miners investing computational resources in order to participate in the leader election process, they instead use a process that randomly elect one of them proportionally to the stake that each possesses according to the current Blockchain ledger. The elected is called Validator (equivalent to ’miner’ in PoW). Each validator own some stakes in the network, and this money is also used as a way to build trust between peers. Validators will lose part of their stake if they approve fraudulent transactions. As long as the stake is higher than what the validator gets from the transaction fees, they will have no reason to scam.

1.1.9 Smart Contracts

Nick Szabo introduce this concept in 1994 and defined a Smart Contract as ”a com- puterized transaction protocol that executes the terms of a contract” [25]. Szabo suggested translating contracts into codes, or small programs, and embedding them into property (Hardware or Software) that can self enforce them [26]. This minimize the need for trusted intermediaries between parties and also the possibility of having malicious or accidental transaction. The Blockchain implementation of Smart Con- tracts is basically a scrip that contains some sort of contractual information, that is stored on a Blockchain [27]. Since they reside on a Blockchain, they each have an address, stored on the ledger. Addressing a transaction triggers the contract. It is

16 then executed independently and automatically in a prescribed manner on every node in the network. Smart Contracts excel when they are tasked with managing data- driven interactions [28] between entities on the network. For further understanding, consider a Blockchain network where Alice, Bob, and Carol participate, and where digital assets of type X and Y are being traded. Bob starts a Smart Contract on the network that defines:

• deposit function allowing him to deposit units of X into the contract

• trade function that sends back 1 unit of X (from the contracts own deposits) for every 5 units of Y it receives

• withdraw function that allows to withdraw all the assets that the contract holds.

For this example, we say that Bob is the creator of these contracts, so only Bob can call the deposit and withdraw functions. Bob starts with a deposit contract, and sends 3 X’s to the contract. This transaction is recorded on the Blockchain. Alice, who owns 12 unites of Y, starts a trade transaction for 10 of her Y’s, and gets back 2 unites of X. This transaction is also recorded on the Blockchain. Bob then uses the withdraw transaction to withdrawal the remaining X’s and Y’s units. In our case, he asks for 1 X and 10 Y’s. The contract checks to see if Bob is the owner of the contract, and then sends the units to him. This transaction is also stored on the network. In this example, Alice, Bob and Carol (the nodes on the network) have the access to the ledger, allowing them to validate the output of the contract. Smart Contracts are used in many different application. Banks, for example uses this method for Loans and Automatic payments, Insurance companies use this to process claims and many more other real life applications of Smart Contracts [29].

17 1.1.10 Information Sharing

Information sharing describes the exchange of data between various organizations, people and technologies. There can be several types of information sharing, Infor- mation shared by individuals (such as a video shared on Facebook or YouTube), Information shared by organizations (such as the RSS feed of an online weather re- port), Information shared between firmware/software (such as the IP addresses of available network nodes or the availability of disk space). The advent of wide distributed networks, intranets, cross-platform compatibility, ap- plication porting and standardization of IP protocols have all facilitated the huge growth in global information sharing. When it comes to personal information how- ever, no matter how easy it is to port the actual data, there are laws in most countries prohibiting the sharing of personal data without explicit permission being granted. In the U.S. and Europe it is a criminal offense to share any personal data about anyone without such explicit permission. There is plenty of other information sharing that does not fall under the law and information sharing is increasing as more networks and organizations connect and information becomes easier to share across the inter- net. Data was formerly frequently kept in silos and often not shared among other entities due to its proprietary, non-portable format or the inability to import/export data. Even simple items such as dates were stored in a whole range of different formats, making the sharing of such a simple field a potential nightmare. The same applied to a whole range of data, and even if it was compatible, it was often not possible to physically transfer the data from one platform to another. Today these problems have all been coded out and information sharing is common between computer networks; information sharing has become especially prevalent due to social networking. These 21st century network models actively encourage the shar- ing of information across social networks. Social networking sites and applications

18 have established between them a sharing network of over a billion people. In terms of information sharing, this is a global proportion with almost 10 percent of the world’s population sharing information across common networks regularly. After the terrorist attacks of September 11th, information sharing became one of the United States government’s goals in developing their resources to try to avert such atrocities. It was mandated among government agencies and departments that personnel create a methodology for regularly sharing relevant information. The U.S. needed information sharing improvements to respond to various threats more effec- tively. The lesson was learned that when information is hoarded instead of shared, those needing it may not be able to react in a timely manner. Using information sharing intelligently has been shown to be a more effective way to manage any organization: a government or a business. Information sharing is crucial to many businesses, helping to promptly meet customer and client needs through customer relationship systems which share information about products and services and improve access to their customers. Information sharing has also allowed easy availability of credit history details, which helps consumers access more services. Consumers can have access to banking, financial and credit products from across the nation and even internationally where appropriate. Hospitals sharing medical records (under stringent conditions) about people so that their medical personnel can make better decisions, is a good example of how organizations can share information for productive purposes. Overall, when used intelligently, information sharing is a useful way of lowering costs, improving overall accuracy of public data and allowing organi- zations and individuals alike to have access to information that they might need and entertainment that they want to experience.

19 1.2 PROBLEM DEFINITION

This thesis addresses the privacy concern users have while sharing information be- tween themselves. The focus will be primarily on message sending and receiving, where users can write and send text messages to other users on the Blockchain. In- formation sharing between can have many implementations in many different areas. It describes the exchange between various organizations, people or technologies. It can be used in every day areas such as video sharing online, or it can be used for more ’word’ areas, of which by nature, required a more secured environment for the sharing. This paper present such a secured information sharing method, based on Blockchain. Blockchain is the underlying technology used to secure the Bitcoin digital currency. through its design, a Blockchain implementation keeps an agreed, permanent and immutable record of all the transactions that have ever taken place across its net- work. A Blockchain runs on a distributed network, on computers across the globe. The nodes in a Blockchain network are generally unknown to each other and have no trust or ownership relationship between them, but in spite of this the design of the Blockchain protocols ensure that the historical ledger of events is accurate, publicly available and trusted by everyone. Although the original implementation of Blockchain is from Bitcoin, the underlying technology has been recognized as having far-reaching potential, capable of providing an accurate decentralized ledger of transactions across many diverse fields. By us- ing a programmable Blockchain ledger as an immutable record of shared information transactions, this paper aims to develop an application which provides a secure com- munication channel for information sharing among members. The goal is to develop a system which can be considered secured when measured against different security models (presented in the following chapters).

20 CHAPTER 2 LITERATURE REVIEW

This literature review goes over papers that discuss the different possible implemen- tation for Blockchain in areas that are not cryptocurrency. This will help understand the need for such a decentralized system, and there are many similar ideas that can be used in the information sharing. The different implementations of Blockchain can vary from finance [30], [31] and healthcare [32][33], to utilities [34], real estate [35], [36] and even the government sector [37]. The reason for this explosion of interest is that now when Blockchain is in place, applications that could previously run only through a trusted intermediary, can now operate in a decentralized fashion, without the need for a central authority, and achieve the same functionality with the same amount of certainty. As explained in previous section, this is what Blockchain 2.0 and Blockchain 3.0 addresses.

2.1 PROTECTING PERSONAL DATA

One of the more recent applications of Blockchain is in the sector of protecting per- sonal data. This implementation of Blockchain is possible due to the theory of it that allows to modify a block record only if the adversary can present a history of transactions, a long chain of blocks that is longer than the rest of the miners, which is very difficult to achieve. This means, that if we only look at the transaction ledger of Blockchain, it provides integrity and trustworthiness. Many papers took this idea and expended it to create a well secured personal data. A lot of what is written in this chapter will be later used for the research itself.

21 In 2015, Zyskind, Nathan and Pentland used a combination of Blockchain and stor- age management to construct a personal data management platform focused mainly on privacy [38]. Their implementation deals with the problem of how exposed per- sonal data is now a days. Due to the globalization, people have access to the internet 24 hours a day, 7 days a week and this makes people’s data being easily accessible. This means that third-parties companies can collect and control massive amount of personal data [39]. In Zyskind el al implementation, they describe a decentralized personal data management system that ensures an individual’s privacy while giving him the ability to controlling his data. Their solution is focused mainly on Smart

Contracts that use two types of transactions: Taccess which is used for access control management; and Tdata for data storage and retrieval. Whenever a user uses this platform, he first needs to sign up, and a new shared identity is generated and sent to the Blockchain, along with the associated permissions on a Taccess transaction. Any data that needs to be stored is encrypted using a shared encryption key, and is then sent to the Blockchain in a Tdata transaction. At this point, the data is stored on an off-Blockchain key-value database, while retaining only a pointer to the data on the public ledger (The pointer is the SHA-256 hash of the data).

Whenever the user or wishes to access the data, he can do it using Tdata transaction with the pointer (key) associated to it. The Blockchain then verifies that the digital signature belongs to either the user or the service. For the service, its permissions to access the data are checked as well. Finally, the user can change the permissions granted to a service at any time by issuing a Taccess transaction with a new set of permissions, including revoking access to previously stored data. The data is stored on a distributed hashtable (or DHT) as described by Kademilia [40]. But the off-Blockchain data storage can be altered to any fitting technology, for example the use of centralized cloud. The data must never be on the Blockchain itself, because all of the transactions and data is publicly available.

22 Figure 2.1: Overview of the decentralized platform [38]

Another similar implementation of Data Secure system was introduce in 2017, called ProvChain [41]. It is a Blockchain based data provenance architecture that provides a secured data storage on a application, with privacy and availability. In this application, the data we wish to store is hashed and then stored into Merkle tree nodes [42]. A list of hashes of data will constitute a Merkle tree while the root node will be anchored to a Blockchain transaction. A list of Blockchain transactions will be used to form a block and the block needs to be confirmed by a set of nodes in order to be included in the Blockchain. An attempt to modify a provenance data record will require an adversary to locate the transaction and the block. Similar implementation can be used for Identity-based cryptosystem, as was de- scribed by Lin, Yan, Huang, Chen, Shen and Tang in 2018 [43]. Their implementation

23 of Blockchain is the concept and security model of ID-based linearity homomorphic signature system. This means that the signer can produce a linearly homomorphic signature in identity-based cryptosystem. Another implementation involves the security of Smart-Home, using Blockchain. Ali, Salil, Raja and Praveen [44] outline how the IoT devices are initialized and then explain how transactions are processed, under the security of Blockchain. A local and private Blockchain is employed for providing secure access control to the IoT devices and their data. The design security comes from diverse features including:

1. indirectly accessible devices

2. different transaction structures in the smart home and the overlay

To achieve a lightweight security, the paper uses symmetric encryption for smart home devices. They provide arguments to demonstrate that the smart home tier achieves confidentiality, integrity, and availability and also explains how key security attacks such as linking attack [45] and Distributed Denial of Service (DDOS) are deflected. Finally, the paper presents its results using simulations to show that the overheads induced by the framework are relatively small.

2.2 MEDICAL IMPLEMENTATION

The medical industry has increased a lot in the recent years thanks to the development in the technology that allowed patients to have wearable medical technology that can monitor and store different parameters. This data is confidential and one of the increased demands is a way to have this data to be shared only with the appropriate people. Because this data is very sensitive, it is very important to have it shared in a secured way, preferably without any ’man in the middle’ that can have access to that data. This is why, in the past couple of years, the Blockchain has proven to 24 be the perfect environment for such application. Liang el al [46] introduce a user- centric health data sharing solution by utilizing a decentralized system to protect privacy where the individual can manage its data and there is a ’membership service’ that allows only specific members to have access to that data. There is also a mobile application that collect health data from personal wearable and other medical devices, and its synchronize the data to the cloud for data sharing with the specific members (Can be insurance company for example). To preserve the integrity of health data, within each record, a proof of integrity and validation is permanently retrievable from cloud database and is anchored to the Blockchain network. Their implementation can also handle large data sets of personal health data.

Figure 2.2: Personal Health Data Integrity Protection [46]

As seen in Fig 2.2, There is a cloud Database storage that the individual have access to, and an assorted of allowed members (Doctors and insurance companies in this example). The individual have different types of medical devices that collect health data. This data is then uploaded to the cloud database on a trusted platform using the mobile application. The Doctors and Insurance companies can have access 25 to that data (The user can revoke their permission whenever he wishes to). The Blockchain network is used in this implementation for two purposes. For health data collection, each of the hashed data entry is uploaded to the Blockchain for integrity protection. The other party members wishes to access that data have to send a request and it needs to be approved. This is done as a transaction on the Blockchain network [47]. Another similar implementation is done using the MeDShare, which is an appli- cation for sharing medical data among cloud service providers using Blockchain [48]. It is similar to the previous application, however in this one the medical records is the data that is being stored on the Blockchain, and it is more suitable to handle Big Data of medical records. In other words, they solve the issue of medical data sharing among medical big data entities in a trust-less environment. The system is Blockchain-based and provides data storing, and control for shared medical data in cloud repositories among big data entities. MeDShare [48], The application name, monitors all entities that access the data, and can points to any malicious activities from a data custodian system. All the transitions of data from one entity to another, along with all actions performed on the system, are recorded. This design employs Smart Contracts and an access control mechanism to effectively track and revoke sus- picious behavior. By implementing MeDShare, cloud service providers and other data guardians will be able to share data in a secured manner with entities with minimal risk. Another similar implementation of Blockchain in the medical industry is the work of Patel V [49]. His work focuses on the use of Smart Contracts to achieve consensus without relying on a central authority to share sensitive health data. He developed a platform for information sharing that uses a Blockchain as a distributed data to establish a ledger of health related studies and patient-defined access permissions. The management of medical data which includes storage, access control, and shar-

26 ing of the data is an important aspect of the medical industry. It is also important for the medical industry to be efficient. However, managing medical data is a challenging task due to its sensitive nature and subsequent trust issues. This is the reason why Blockchain proven to be the perfect candidate for handling this [50].

2.3 TECHNOLOGY IMPLEMENTATIONS

2.3.1 Mobile Technology

Mobile security is something that has always been very important. People use their mobile for everything, including shopping, in-app purchases, mobile banking and more... all of which can go under the umbrella of ’m-commerce’. Blockchain has been used as a security solution for many different applications, and it might also help the mobile industry. In 2018, Kongrath et al introduced a new m-commerce application using Blockchain technology called ’MobiChain’ [51]. This application can be used to secure transactions in the m-commerce. The mining processes can be executed efficiently on mobile devices using a proposed Android core module. The proposed MobiChain system is illustrated in Fig.2.3, which consists of multiple mobile devices and multiple server nodes. Each mobile node has a backlog or queue to store pending tasks. The mobile node is connected to a server node either via the Internet or a local direct connection. All server nodes are installed Sync Gateway [52] to broadcast data, and they are always connected to other server nodes via the Internet. In this case, consider a message passing scenario, e.g., Mobile Node A sends a message to Mobile Node C. This message can be a data transfer request or a radio resource sharing request, which needs to be verified. This message is referred to as a transaction. Assume that all the mobile nodes are installed the MobiChain application, and they have already registered user accounts. These accounts are to provide public and private keys which are unique to the users. The message passing process includes the following steps: 27 Figure 2.3: The MobiChain system model [51]

• Step 1: The author creates a transaction. In general, a transaction consists of three parts, text message, author’s information, and destination’s information. After that, the author puts the transaction into the authors backlog

• Step 2: The author uploads the transaction to its connected server

• Step 3: The Sync Gateway broadcasts the transaction to every node in the network. As in the example in Fig 2.3, node B, C and D have the same trans- action in their backlogs as they are connected to the network. Node E does not have the same transaction because it is currently not connected to the network

Whenever node E is reconnected to the network, it will be updated and synchronized with the current Blockchain and transactions in the backlog.

28 2.3.2 Smart Cars

Another area that Blockchain can be used is the ’Smart cars’, or ’Intelligent Trans- portation System’ (ITS). With having the car connected to the internet, it needs to have some sort of security in order to prevent adversaries to have access to any infor- mation the car might be sending. Blockchain can be utilized to establish a secured, trusted and decentralized autonomous ITS ecosystem. In 2016, Yong et al presented a way to achieve such security in ITS with a Blockchain-based ITS (B2ITS) [53]. Their paper goes over all the possible data layers ITS-Oriented Blockchain might have. The layers are presented in Fig 2.4

Figure 2.4: An ITS-Oriented Blockchain Model [53]

These 7 layers can be projected on almost any other industry. The layers are:

1. Physical Layer - Encapsulate different kinds of physical entities that can be a part of the ITS.

2. Data Layer - The chains of data blocks, together with the related techniques needed to achieve the security. 29 3. Network Layer - What mechanism of distributed networking, data forwarding and data verification are used.

4. Consensus Layer - This layer packages all possible consensus algorithms. Blockchain technology have different methods to achieve consensus, PoW, PoS, DPoS and more..

5. Incentive Layer - This layer incorporates economic reward into the Blockchain, and specifically, oncce a new block is created, a certain amount of coins will be generated as reward to motivate the network continuing their efforts in data verification.

6. Contract Layer - What is the form of which the data is going to be stored and shared. It can be done using some special algorithm, or Smart Contract for example.

7. Application Layer - What is the use of the ITS. It can be used for Ride- Sharing information, sending logistics and so on.

This paper presents a preliminary study on the emerging Blockchain technology and its potential applications in transportation research. Another similar approach was presented in 2017 by Sharma et al [54]. They propose a Block-VN (Blockchain Vehicular Network) model, which is an Blockchain based architecture for a vehicle network in smart cities. Block-VN model allows vehicles to discover and share their resources to create a network of vehicles on which they work together to produce different services. The architecture can be seen in Fig 2.5

2.3.3 Cybersecurity

Cybersecurity is an ongoing challenge where the protector of data and the adversaries keep challenge each other. The aim of cybersecurity is to detect and prevent cyber- attacks, especially to prevent the exposure of private information. In 2018, Danda 30 Figure 2.5: Block-VN model architecture [54] et al developed cybersecurity framework designed to protect confidential information using Blockchain as its foundation [55]. Their system is called iShare, and it is uses the same concept used in Bitcoin system where the main aim of this framework is to constantly collect high-resolution, cyberattak information across predetermined boundaries. In the proposed framework, the decentralized nature of the Blockchain and Digitally signed transactions ensure that an adversary cannot pose as legitimate user. The basic idea is the use of Blockchain protocol over the public internet. This idea is shown in Fig 2.6 and it has three entities:

1. Organization - This refers to the parties participating in the cyberattack in-

31 formation sharing with a collective goal to prevent future cyberattacks.

2. Services - Refers to the providers of the cyberattack-related information and applications that process data.

3. Manager nodes - Trusted devices that are dedicated to maintaining the Blockchain as well as the distributed cryptographic keys.

This system accepts two types of transactions:

• transactions for access control management (Tacc)

• transactions for information storage and retrieval (Tinfo)

While maintaining their privacy, each participating organization shares its cyberat- tack information using the presented system. Upon signing up, each organization is assigned an identity with associated permissions, which are sent to the Blockchain

using the Tacc transaction. As an integral part of this system, shared information is

sent to the Blockchain using Tinfo transaction after being encrypted using a shared encryption key. Subsequently, when participating organizations retrieve such infor- mation by querying, only a pointer to the data on the public ledger is used. Services and organizations are verified using the digital signature. This system consists of transaction blocks, as described in Fig 2.6. The blocks are chained together using a hash, and it means that the hash of block n depends on block n − 1. That makes the Blockchain immune to malicious actions, as a change in one block would require change in the predecessor blocks [56].

2.3.4 Big Data

Big Data is another aspect where the Blockchain technology can be useful in. The rise of big data age in the Internet has led to the explosive growth of data size [57]. With that, trust issues became the biggest problem of big data, leading to the 32 Figure 2.6: A typical Blockchain-based information sharing framework among multi- ple organizations [55] difficulty in data management and storing. It is required, then, to find an elegant way to store, organize and process Big Data, and Blockchain technology has proven to be, yet again, a suitable candidate for such a solution. It is doing so by combining non-tampering, traceable features with smart contracts that automatically execute default instructions. In 2017 Karafiloski published a paper with detailed implementation of Blockchain as a solution for Big Data challenges [58]. In her implementation, the sensitive data is encrypted with a shared encrypted key, and is then sent with a data transaction to the Blockchain. The Blockchain then sends the data to an off-Blockchain key-value storage (DHT) and keeps only the hash value as a pointer to the data. Every time someone tries to access the data, its permissions are checked against the last access transaction. This implementation also uses the

Taccess and Tdata transactions, as shown in Fig 2.7.

33 Figure 2.7: Overview of Decentralized Permissions System [58]

The ledger is publicly available for everybody to inspect the blocks and the trans- actions within . However, the data stays secured, it can only by accessed with a secret key. The transactions are encrypted too. Invalid transactions are rejected and are not included in the blocks. Attempts for malicious changes in the transactions will require repeated calculation of the proof of work for the attached block and all the blocks afterwards. These calculations are infeasible unless majority of the nodes in the network are malicious.

34 CHAPTER 3 RESEARCH METHODS AND ANALYSIS

3.1 PREREQUISITES

After reviewing similar papers, the main idea for this research is to have a system of which registered users can send data in a secured way to any other registered users, on the Blockchain network. Such a system will includes four main components: The first one is what Blockchain network would be used. After reviewing possible candidates, Ethereum seems like the right choice, at first, due to its availability to develop and deploy Smart Contract in a local environment (Which can later be ex- pended to global). Ethereum is also relatively easy to code, using Solidity [59] which is a Java based programming language specifically for Ethereum. However, Ethereum has one major drawback, which is its Transaction Per Second (TPS). Ethereum can have up to 15 TPS which is very low if we want to achieve fast communication be- tween devices. A different candidate was then considered, the EOSIO (Or EOSIO). This Blockchain platform is also based mostly on Smart Contracts, it has its own programming language based on C++, and it is possible to deploy its contract lo- cally on a testing environment. EOSIO TPS time is extremely fast, more than 4000 transactions per second. After choosing the Blockchain platform, the second component is to choose how the data is going to be uploaded to the network. For this implementation, a User Interface (UI) is going to be used. The UI will allow users to log in and send messages to different users of their choice. The user interface is built using React, a JavaScript tool that can connect with the EOSIO code. React provides an interface between the

35 JavaScript and the EOSIO smart contract code, so functions in the smart contract are mapped to local JavaScript calls. The third component is the JsonRPC, which is a tool to connect to the EOSIO Blockchain. JsonRPC, which is a light-weight remote procedure call (RPC), can execute transaction on the Blockchain network in a simulated environment. This means that there is no delay while waiting for transactions to be mined. This tool makes the development process much more efficient. The fourth and final component is EOSIO Studio. This is a command line interface for the EOSIO Blockchain that can start the Blockchain locally. EOSIO Studio starts a VM under which a EOSIO Blockchain is deployed. EOSIO Studio combined with JsonRPC can provide an efficient and secured way to test Smart Contracts. In summary, this research develops a React JavaScript UI that can connect to a EOSIO local network where a user can send encrypted messages that will be stored on the EOSIO Blockchain. Smart Contracts are written using the C++ EOSIO language, and are then compiled to a WebAssembly (WASM) file using EOSIO.CDT (Contract Development Toolkit). This file can then run on the EOSIO network using EOSIO Studio, and any connection between the user interface and the deployed contract is done using JsonRPC. In the EOSIO Blockchain, every user is given a private and a corresponding public key (Public-key cryptography). These keys are stored in the users wallet (either securely online or offline) and this is how a user can made transaction on the EOSIO network. A user address is its public key, this is also called the user identity, and this is how other users can find and communicate with one another. For example, if user1 have a public key of 5X9, and user2 have a public key of 0J3, in order for user1 to have any transaction with user2, he needs to know its public key (0J3). Fig.3.1 shows the basic components needed for the implementation for this re- search. Users are interacting with the UI that is built on React and JsonRPC com-

36 Figure 3.1: Components for the EOSIO Information Sharing

ponents. The information is then sent to the EOSIO Studio, where the contracts are compiled to a WASM, and then deployed to the EOSIO network. Another important aspect is to understand the way a user can ’register’ to be on the EOSIO network. Users who want to access the Blockchain network have to sign-up and they then receive a set of 2 keys, a public key (noted as Pk) and a private/secret key (noted as Sk). This set of keys is generated as follows, A generator, Gen, first generates 2 points, s and t on an Elliptic Curve for Cryptography (ECC) [60], specifically the secp256k1 Elliptic Curve. These points are then then encoded using the Wallet Import Format which makes them work as a general keys for other Blockchain networks.

3.2 DESIGN

3.2.1 System Design

The system needs to be design in such a way that it encrypts and decrypts the message off-Blockchain on a UI system, and then can have a connection from that UI to the Blockchain network. The key part of the encryption is using the Elliptic Curve pre-generated public key and secret key that every user on the EOSIO network have, in an Elliptic Curve Diffie Hellman (ECDH) key exchange protocol. The system will work as follows: 37 Every user who wishes to send a message to someone else on the Blockchain first need to have a secret key and a private key. He can then chose a recipient he wishes to send the message to. This recipient must also have a public and a secret key. For every message the sender wishes to send, the off-Blockchain UI first uses a Random Number Generator (RNG) to generate both an Initialization Vector (Will be use in the following steps), and helps generating the ECDH shared secret. This is done as follows: Assume G, a point on graph secp256k1, is given, order q of the graph is given.

1. Sender generates d ∈ Zq, used as the temporary private key

2. Sender computes Q = d · G, used as the temporary public key

3. Given the recipient public key, noted R, sender computes S = d · R

4. S is the shared secret generated

Once the shared secret is calculated, the sender uses any key encryption protocol to encrypt the message. In this thesis, the implementation is going to be using AES protocol with the Initialization Vector (IV), the shared secret and the message. The ciphertext, IV and the temporary public key are then sent to the recipient on the Blockchain as a transaction. This Transactions’ ID is then saved and stored for the recipient. A graph of the top level idea for the off-Blockchain application is given in Fig.3.2. This is the process from the sender side. Now we will go over the recipient actions. The first step is to access the UI. The UI can query and find transactions that have been sent to the recipient based on his public key. The UI can then decrypt the messages using the recipients’ secret key as follows:

1. Recipient is given the ciphertext, the IV and the temporary public key (Q). Denote recipients’ private key as e. 38 Figure 3.2: Top level idea of the EOSIO ECDH Protocol

2. Recipient can compute S = e · Q = e · d · G

The UI can then use the secret shared key and the IV to decrypt the ciphertext that was sent to the recipient. This process is done automatically as an off-Blockchain application.

3.2.2 Implementation

This is the description of the underlying protocol used in the system. When a user enters the EOSIO network, he is given a set of 2 keys, a public key (Pk) and a secret key (Sk). The public key is the address of the user, and the secret key is stored in the user’s wallet and it is the way a user can make transaction on the network. Once a user is registered, he needs to be approved to send and receive messages on the network, that way we can create groups of data, where each group can only share data within itself. In this implementation, a user is granted access with the use of 39 Figure 3.3: Example for accessing data on EOSIO transaction simple table. If a user is on the table this means he is allowed to send and receive data on this network. This is the simplest way to add users, however it can be done in more secured way, with the use of MPC but this is not described in this paper. Now that the user is approved on the network, he can start sending and receiving data to and from other approved users. When a user wishes to send information, he must deploy the Tdata contract. The contract takes the information of the user sending the data, along with the data itself, and he then makes a transaction with the data stored. However, When deploying this contract, and when the transaction is made, the data is public and can be accessed by everyone. An example for it can be seen in Fig.3.3 where Alice is sending data to Bob with the message ’Hello Bob’, and it can be easily accessed using the Block.io engine. The data needs to be encrypted before sending to the Blockchain, in an off- Blockchain location. In this implementation, it is done as part of the UI. When a user wishes to send information, he must fist go to the User-Interface and log in. The user needs to register using its Secret Key, and the UI then check to see if the user is authorized to send and receive data. In case it does, the user is then being

40 Figure 3.4: Example of Alice sending data to Bob redirected to the ’Send Message’ page, where he can enter any message he wishes and send it to his chosen recipient (He can choose more than one if he wishes). The UI then takes the data, and encrypts it using the users secret key, and the recipient public key. The UI last step is to take the ciphertext that was just created, and to upload it to the Blockchain under the Tdata transaction. This transaction ID is sent to the recipient. The UI other job is to fetch messages that are send to the logged user. This is done after receiving the transaction ID, the UI query that transaction and gets the en- crypted information in it. Because this data was encrypted with the recipient public key, he can now have access to it using his secret key, and the authors public key.

3.2.3 Testing

To test the effectiveness of this system, here is an example scenario where user Alice wants to share a text with user Bob. Fig.3.4 illustrates the process from Alice’s point of view. For this process, we assume both Alice and Bob are approved users, meaning they can both send and receive messages. An example of such a table can be seen Fig.3.5 Alice starts by accessing the Web UI, where she needs to enter her username (which is whatever username is stored on the approved users table) and her secret 41 Figure 3.5: Example of approved users on EOSIO Studio

key. To share information with Bob, Alice would need to have Bob’s unique address. This could have been given to Alice directly by Bob or by a third party. Bob’s address is his public key, so his address doesn’t need to be kept a secret, so long as only bob has access to his secret key. After logging to the system, Alice will be able to send message to any recipient she wishes (as long as he is an approved user) using the UI. And example for the send message UI is in Fig.3.6. After writing all the details, including Bob’s public key and the message, she can hit the ’Send Message’ button. This will take the information of Bob, as entered by Alice, and it will first check to see if Bob is an approved user. If he is, then the system encrypt the message using Bob’s public key, and Alice’s secret key. The encrypted text goes to the EOSIO.CDT which is the C++ platform, where the encrypted text and the recipient address are

being executed on a Smart Contract to the EOSIO Blockchain on a Tdata transaction. This transaction is public, but since the data is encrypted, it is impossible to achieve any information from it. The transaction address is then being sent to Bob, and when

42 Figure 3.6: Example of the UI of Alice

Bob logs into the system, the JavaScript UI can already get the information from the Blockchain, decrypt it using Bobs secret key, and present it to him.

3.2.4 Types of Data

In this implementation, the data that being sent is a simple text message. However, this can be used for much more then that, with the use of Distributed Hash Tables (DHT). DHT is a class of decentralized distributed system that provides a lookup service similar to hash table with the use of a key and a value. (Key, Value) tuples are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key. This table can then be used to store large data, and then have its hashed value sent over the Tdata transaction.

3.3 ANALYSIS

This section will analyze the system in 2 different aspects. The first one is how expansive it is, meaning how much power is needed and how will it be acquired. The second is the security of the system. This is done using 2 different analyzing 43 methods. The first one is the Confidentiality, integrity and availability, also known as the CIA triad. This model designed to guide policies for information security within an organization [61]. The second method is the STRIDE technique that was introduce in 2008 by Shostack [62]. STRIDE stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of privilege.

3.3.1 Resources

As explained, to run this system on a Blockchain network, specifically EOSIO, it will need to use some resources. One of the key things to understand about EOS is its 3 types of resources, CPU, NET and RAM.

• CPU - It signifies the processing time of an action. When a user wants to execute an action on the Blockchain, it will take some time to complete. This time is measured in microseconds of CPU (µs)

• NET - NET or Network bandwidth is measured as the average consumption of bytes. Net bandwidth is temporarily consumed every time a transaction is sent.

Both CPU and NET are staked allocations. Rather than being bought and sold, they’re obtained through staking, in which a network participant delegates EOS to- kens. This means that to use them in this system, there will have to be some EOS tokens at stake from the user. Fig.3.7 shows an example of possible token to CPU and NET distribution. Say that a user stake 2.5 EOS for CPU and 2.5 EOS for NET. This corresponds to 31,200 µs of CPU and 10,000 Bytes of NET. If sending a message requires 700 µs of CPU to be executed, the the total messages that a user can send using 5 EOS tokens is 44 (31200/700). As to calculate how much CPU power is need to be used, EOS have a nice tool called EOS Charge [63] that lets you calculate the how much CPU power any transaction might need. These resources are rechargeable,

44 Figure 3.7: Example of EOS token meaning that a user can spend all his CPU power to send the number of messages he wishes to send, and after 24 hours these tokens recharge, so he can use them again for sending messages. RAM - The RAM is a very important resource on the EOS network. Everything that is saved on the Blockchain network is essentially kept in RAM. This is how EOSIO function, and this helps when it comes to speed. Unlike CPU and NET, RAM is purchasable. Meaning, that we can have the data stored on the RAM, but that means the space is going to need to be purchased. In the previous example, we can have the user store the message on the RAM for faster transaction, and the system will have to pay for that RAM (The user does not need to pay for it). In this system, the allocation of the CPU, NET and RAM will be handled by the system itself, that means that the system will have to purchase enough EOS tokens to be able to have it for the users. To calculate how many EOS tokens are needed, we will assume having a relatively small system, with only 1,000 users. Assume also that every user will be sending 5 messages per day. From the information on the EOS Charge data, each transaction takes about 200 bytes of net, and 1,000 µs. This means:

• Total CPU needed = 1000 · 5 · 1000 = 5000000 µs/day, or 5000 ms/day

45 • Total NET needed = 200 · 5 · 1000 = 1000000 Bytes/day, or 1000 KB/day

The total EOS (CPU+NET) needed can then be calculated based on the current prices of NET and CPU [64]. Total CPU cost: 0.0019 · 5000 = 9.5 EOS tokens Total NET cost: 0.00035 · 1000 = 0.35 EOS tokens The total EOS tokens needed for this system of 1000 users with 5 messages per day is 9.85 EOS tokens. As of today, the price for 9.85 EOS tokens stands on 43.73$/day. This does not include RAM which can be beneficial for this sort of implementation (faster transaction time). The problem with RAM, however, is how expensive it is. So RAM is a good sort of implementation when only a few messages are needed.

3.3.2 Performance

This systems performance will be tested on a real-time local network that can have a record of all the actions and transactions. Testing will be on the following:

• Block Size - The average memory space of an individual block

• Network Latency - The average time it takes for message to be deployed on the Blockchain, in ms

• CPU Usage - The overall CPU usage, in µs

• NET Usage - The overall NET usage, in Bytes

Test

The test worked as follows, there were 50 users on the local Blockchain network, and they have each sent transaction Tdata to the another user on the Blockchain network at 1 second interval for the total time of 10 minutes. The transactions were messages that had their data generated randomly and the recipient chosen randomly among

46 the 50 users on the Blockchain. After a transaction had been made, it was possible to access the Blockchain and see what was the network latency for that transaction. This test ran 3 times, each time with different messages and recipients generated.

Test 1 Test 2 Test 3

Avg. Block Size 75KB 82KB 62KB

Avg. Network Latency 19ms 31ms 21ms

CPU Usage 3472 4521 3966

NET Usage 6955 6553 7952

3.3.3 CIA Model

Confidentiality

Using Smart Contract on the EOSIO Blockchain provides anonymous transfer of information between users, where only the users public key is exposed. However, leakage of information is possible. If the users address is used again, then it is possible to follow the user past transactions, and see what other users are associated with this user, and that way an adversary can build up a network of interactions between address identities, even if the real identity of the users are not known. Goldfeder [65] discussed this type of information leakage on a Bitcoing Blockchain scenario, where different types of web trackers and even internet cookies can be used to link information between users. This information leakage could be prevented by using a unique wallet address identifier for every interaction, or at least using a different identity for each interaction with a different party - i.e. Alice should use identify A to communicate with Bob and A0 to communicate with charlie - then Bob would not be able to identify that A and A0 were the same party and identify other communication paths.

47 This solution is possible, and it requires the users to keep changing identities for every single transaction.

Integrity

Due to its nature, the EOSIO Blockchain network works in such a way that every transaction is written permanently on the ledger and it cannot be changed. Thus it is one of the central conditions of a Blockchain system that integrity of data on the chain is preserved, so anything written to the Blockchain will be written there forever.

Availability

EOSIO is a decentralized system, which means everybody can have access to it, and it system runs globally across thousands of computers. Since the data is stored on each and every node in the network, even if some nodes are down for maintenance or compromised, the data will remain available.

3.3.4 STRIDE Model

Spoofing

Spoofing means that an adversary can pretend to be an allowed user, even though he is not, or in other words, the adversary can forge a secret key that is corresponds to one of the approved users secret key. However, it has been proven that the adversary can forge existing secret keys only with negligible probability [66]. This means that the adversary only way to spoof the system is to somehow acquire an existing key from an approved user. This, however, is depends on how the user keeps his secret keys.

48 Tampering

As explained before, tampering or changing the data on a Blockchain is impossible. The only possible tampering in this scenario is the tamper of the UI, or the React components in such a way that expose personal information. However, this is a risk for every action on the internet.

Repudiation

The data on the Blockchain is immutable, as well as transactions that are written on the ledger.

Information Disclosure

This is the biggest problem that this system tries to handle. The data is encrypted using the user’s secret key, meaning that the data cannot be read by unauthorized users, even when the ciphertext is available (cca secured [67]). However, as explained before, the address of users on the network is accessible, and this can be used by adversaries to gain unwanted information.

Denial of Service

A Denial of Service attack can be made on the UI, which in that case it will cause the server to crash, however no information should be exposed. An attack can also be made on the EOSIO Blockchain network itself. However, such an attack is very diffi- cult to achieve and it will have minimum effect, because of how fast the transactions can be made on the network.

Elevation of Privilege

In this system, there is a list of allowed users that is stored on an Multi Index Table, which is stored on the Blockchain. This means that in order to add approved users,

49 a Smart Contract need to be executed. This can only be done with the authorization of one of the users that are already listed on the table. This makes that the adversary might have access to the table, but it is impossible for him to add his information or to change the information of users.

50 CHAPTER 4 CONCLUDING REMARKS AND FUTURE DIRECTIONS

4.1 CONCLUSION

This paper presents a very basic system for sharing information between parties with Blockchain as its underlying technology. Blockchain has proven to be a very powerful tool that can be integrated in many different aspects in technology and life. This form of decentralized system makes the information written on to be immutable, and even though it can be accessed by anyone, it cannot be changed which makes it ideal for storing information. This system shows that the information need to be encrypted before sending to the Blockchain, otherwise adversaries will have access to the information. This is done off-Blockchain on the JavaScript web front-end, and the encryption is using Both the author secret key and the recipient public key, to achieve an asymmetric encryption of the data. This way, once sent to the Blockchain, adversaries have access only to the encrypted text. The bottom line is that approved users can control and share information between themselves in a decentralized fashion, without the use of any third party authority or company. This system uses EOSIO Blockchain network for its speed, security and ease of use, but other Blockchain networks can be used with the same fashion to achieve similar results.

51 4.2 FUTURE WORK

This work uses very basic tools to achieve secured information sharing on the plat- form of Blockchain. However, this platform can be used in many different ways, for example, instead of having a UI on the web, the whole encryption of the data can be done automatically and internally (when using independent units for example). This is one way to have secured data shared on different platforms and in different environments.

52 BIBLIOGRAPHY

[1] Nakamoto S, et al. Bitcoin: A peer-to-peer electronic cash system. 2008;. [2] Iansiti M, Lakhani KR. The truth about blockchain. Harvard Business Review. 2017;95(1):118–127. [3] Haber S, Stornetta WS. How to time-stamp a digital document. In: Conference on the Theory and Application of Cryptography. Springer; 1990. p. 437–455. [4] Bradbury D. The problem with Bitcoin. Computer Fraud & Security. 2013;2013(11):5–8. [5] Rivest RL, Shamir A, Adleman L. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM. 1978;21(2):120–126. [6] Nojoumian M, Golchubian A, Njilla L, Kwiat K, Kamhoua C. Incentivizing blockchain miners to avoid dishonest mining strategies by a reputation-based paradigm. In: Science and Information Conference. Springer; 2018. p. 1118– 1134. [7] Gervais A, Karame GO, W¨ustK, Glykantzis V, Ritzdorf H, Capkun S. On the security and performance of proof of work blockchains. In: Proceedings of the 2016 ACM SIGSAC conference on computer and communications security. ACM; 2016. p. 3–16. [8] Swan M. Blockchain: Blueprint for a new economy. ” O’Reilly Media, Inc.”; 2015. [9] Crosby M, Pattanayak P, Verma S, Kalyanaraman V, et al. Blockchain technol- ogy: Beyond bitcoin. Applied Innovation. 2016;2(6-10):71. [10] Zheng Z, Xie S, H, Chen X, Wang H. An overview of blockchain technol- ogy: Architecture, consensus, and future trends. In: 2017 IEEE International Congress on Big Data (BigData Congress). IEEE; 2017. p. 557–564. [11] Duffield E, Diaz D. Dash: A privacycentric cryptocurrency. No Publisher. 2015;. [12] Schuh F, Larimer D. Bitshares 2.0: General overview. ac- cessed February-2019[Online] Available: https://cryptorating eu/whitepapers/BitShares/bitshares-general pdf. 2017;. [13] Buterin V, et al. Ethereum white paper: a next generation smart contract & decentralized application platform. First version. 2014;. 53 [14] Brown RG, Carlyle J, Grigg I, Hearn M. Corda: an introduction. R3 CEV, August. 2016;1:15.

[15] Haferkorn M, Diaz JMQ. Seasonality and interconnectivity within cryptocurrencies-an analysis on the basis of Bitcoin, Litecoin and . In: International Workshop on Enterprise Applications and Services in the Finance Industry. Springer; 2014. p. 106–120.

[16] Wood G, et al. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper. 2014;151(2014):1–32.

[17] Larimer D. Delegated proof-of-stake (dpos). Bitshare whitepaper. 2014;.

[18] Lamport L, Shostak R, Pease M. The Byzantine generals problem. ACM Trans- actions on Programming Languages and Systems (TOPLAS). 1982;4(3):382–401.

[19] Castro M, Liskov B, et al. Practical Byzantine fault tolerance. In: OSDI. vol. 99; 1999. p. 173–186.

[20] Dwork C, Naor M. Pricing via processing or combatting junk mail. In: Annual International Cryptology Conference. Springer; 1992. p. 139–147.

[21] Biryukov A, Khovratovich D. : Asymmetric proof-of-work based on the generalized birthday problem. Ledger. 2017;2:1–30.

[22] Vukoli´cM. The quest for scalable blockchain fabric: Proof-of-work vs. BFT replication. In: International workshop on open problems in network security. Springer; 2015. p. 112–125.

[23] O’Dwyer KJ, Malone D. Bitcoin mining and its energy footprint. 2014;.

[24] King S, Nadal S. Ppcoin: Peer-to-peer crypto-currency with proof-of-stake. self- published paper, August. 2012;19.

[25] Szabo N. Smart contracts. Unpublished manuscript. 1994;.

[26] Szabo N. The idea of smart contracts. Nick Szabos Papers and Concise Tutorials. 1997;6.

[27] Christidis K, Devetsikiotis M. Blockchains and smart contracts for the internet of things. Ieee Access. 2016;4:2292–2303.

[28] Bocek T, Stiller B. Smart contracts–blockchains in the wings. In: Digital Mar- ketplaces Unleashed. Springer; 2018. p. 169–184.

[29] Trees M, Storage DF. A next-generation smart contract and decentralized ap- plication platform. 2018;.

[30] Kelly J, Williams A. Forty big banks test blockchain-based bond trading system. Online] Reuters, March. 2016;3. 54 [31] Anand A, McKibbin M, Pichel F. Colored coins: Bitcoin, blockchain, and land administration. In: Annual World Bank Conference on Land and Poverty; 2016. .

[32] Kar I. Estonian citizens will soon have the worlds most hack-proof health-care records. Online] Quartz, March. 2016;3.

[33] Suberg W. Factoms Latest Partnership Takes on US Healthcare. Critical Infor- mation Infrastructures Security. 2015;.

[34] Lacey S. The energy blockchain: How bitcoin could be a catalyst for the dis- tributed grid. GreenTech Media. 2016;26.

[35] Oparah D. 3 ways that the blockchain will change the real estate market. Re- trieved from Tech Crunch: https://techcrunch. com/2016/02/06/3–ways–that ; 2016.

[36] Mizrahi A. A blockchain-based property ownership recording system. A Blockchain-based Property Ownership Recording System. 2015;.

[37] Walport M, et al. technology: Beyond blockchain. UK Gov- ernment Office for Science. 2016;1.

[38] Zyskind G, Nathan O, et al. Decentralizing privacy: Using blockchain to protect personal data. In: 2015 IEEE Security and Privacy Workshops. IEEE; 2015. p. 180–184.

[39] Zimmer M. But the data is already public: on the ethics of research in Facebook. Ethics and information technology. 2010;12(4):313–325.

[40] Maymounkov P, Mazieres D. Kademlia: A peer-to-peer information system based on the xor metric. In: International Workshop on Peer-to-Peer Systems. Springer; 2002. p. 53–65.

[41] Liang X, Shetty S, Tosh D, Kamhoua C, Kwiat K, Njilla L. Provchain: A blockchain-based data provenance architecture in cloud environment with en- hanced privacy and availability. In: Proceedings of the 17th IEEE/ACM inter- national symposium on cluster, cloud and grid computing. IEEE Press; 2017. p. 468–477.

[42] Merkle RC. Protocols for public key cryptosystems. In: 1980 IEEE Symposium on Security and Privacy. IEEE; 1980. p. 122–122.

[43] Lin Q, Yan H, Huang Z, Chen W, Shen J, Tang Y. An ID-based linearly ho- momorphic signature scheme and its application in blockchain. IEEE Access. 2018;6:20632–20640.

55 [44] Dorri A, Kanhere SS, Jurdak R, Gauravaram P. Blockchain for IoT security and privacy: The case study of a smart home. In: 2017 IEEE international conference on pervasive computing and communications workshops (PerCom workshops). IEEE; 2017. p. 618–623. [45] Narayanan A, Bonneau J, Felten E, Miller A, Goldfeder S. Bitcoin and cryp- tocurrency technologies: A comprehensive introduction. Princeton University Press; 2016. [46] Liang X, Zhao J, Shetty S, Liu J, Li D. Integrating blockchain for data sharing and collaboration in mobile healthcare applications. In: 2017 IEEE 28th Annual International Symposium on Personal, Indoor, and Mobile Radio Communica- tions (PIMRC). IEEE; 2017. p. 1–5. [47] Azaria A, Ekblaw A, Vieira T, Lippman A. Medrec: Using blockchain for medical data access and permission management. In: 2016 2nd International Conference on Open and Big Data (OBD). IEEE; 2016. p. 25–30. [48] Xia Q, Sifah EB, Asamoah KO, Gao J, Du X, Guizani M. MeDShare: Trust- less medical data sharing among cloud service providers via blockchain. IEEE Access. 2017;5:14757–14767. [49] Patel V. A framework for secure and decentralized sharing of medical imaging data via blockchain consensus. Health informatics journal. 2018;p. 1460458218769699. [50] Katuwal GJ, Pandey S, Hennessey M, Lamichhane B. Applications of Blockchain in Healthcare: Current Landscape & Challenges. arXiv preprint arXiv:181202776. 2018;. [51] Suankaewmanee K, Hoang DT, Niyato D, Sawadsitang S, Wang P, Han Z. Per- formance analysis and application of mobile blockchain. In: 2018 international conference on computing, networking and communications (ICNC). IEEE; 2018. p. 642–646. [52] Ostrovsky D, Rodenski Y. Synchronizing Data with the Couchbase Sync Gate- way. In: Pro Couchbase Server. Springer; 2014. p. 301–312. [53] Yuan Y, Wang FY. Towards blockchain-based intelligent transportation systems. In: 2016 IEEE 19th International Conference on Intelligent Transportation Sys- tems (ITSC). IEEE; 2016. p. 2663–2668. [54] Sharma PK, Moon SY, Park JH. Block-VN: A distributed blockchain based vehicular network architecture in smart City. JIPS. 2017;13(1):184–195. [55] Rawat DB, Njilla L, Kwiat K, Kamhoua C. iShare: Blockchain-based privacy- aware multi-agent information sharing games for cybersecurity. In: 2018 Inter- national Conference on Computing, Networking and Communications (ICNC). IEEE; 2018. p. 425–431. 56 [56] Dai F, Shi Y, Meng N, Wei L, Ye Z. From Bitcoin to cybersecurity: A compar- ative study of blockchain application and security issues. In: 2017 4th Interna- tional Conference on Systems and Informatics (ICSAI). IEEE; 2017. p. 975–979.

[57] Yue L, Junqin H, Shengzhi Q, Ruijin W. Big data model of security sharing based on blockchain. In: 2017 3rd International Conference on Big Data Computing and Communications (BIGCOM). IEEE; 2017. p. 117–121.

[58] Karafiloski E, Mishev A. Blockchain solutions for big data challenges: A litera- ture review. In: IEEE EUROCON 2017-17th International Conference on Smart Technologies. IEEE; 2017. p. 763–768.

[59] Dannen C. Introducing Ethereum and Solidity. Springer; 2017.

[60] Koblitz N. Elliptic curve cryptosystems. Mathematics of computation. 1987;48(177):203–209.

[61] Rouse M, Haughn M, Gibilisco S. Confidentiality, integrity, and availability (CIA triad). Retrieved. 2014;11(30):2017.

[62] Shostack A. Experiences Threat Modeling at Microsoft. In: MODSEC@ MoD- ELS; 2008. .

[63] EOS Charge;. Calculate CPU power for EOS transaction. https://www. eoscharge.io.

[64] EOS Resource Planner;. Resources prices for EOS transactions. https://www. eosrp.io.

[65] Goldfeder RN Kalodner. Bitcoin Transactions Arent as Anonymous as Everyone Hoped. 2017;.

[66] Bach L, Mihaljevic B, Zagar M. Comparative analysis of blockchain consensus algorithms. In: 2018 41st International Convention on Information and Commu- nication Technology, Electronics and Microelectronics (MIPRO). IEEE; 2018. p. 1545–1550.

[67] Cramer R, Shoup V. A practical public key cryptosystem provably secure against adaptive chosen ciphertext attack. In: Annual International Cryptology Confer- ence. Springer; 1998. p. 13–25.

57