Using Blockchain Technology to Improve Security of Financial Transactions - a Design Proposal

(1)

(2)

(3)

Using Blockchain Technology to Improve Security of Financial Transactions - a Design Proposal

Terese Timander tereset@kth.se March 4, 2020

Degree project in Computer Science and Engineering Second cycle, 30 credits

Master of Science in Engineering Supervisor: Robert Lagerstr¨om Examiner: Carlo Fischione

(4)

Abstract

Blockchain technology is a relatively new research area. Nonetheless, it is surrounded by a great deal of interest due to its promise of heightened security. This project focuses on blockchain technology as applied to the financial industry. More specifically, within the scope of this project a decision

support system for implementing blockchain is constructed. A product, akin to a calculator, for banks and financial industries to use when having decided

to implement blockchain technology. The result of this project is a finished product, namely such a support system. This also entails presenting an analysis of which algorithms and protocols are to be used and why, as well as a

comment on the legal requirements of such a system. Finally, results from running the finished product are shown and the overall quality and usability of

the constructed support system is analyzed.

Sammanfattning

Blockchainteknik är ett relativt nytt forskningsomr˚ade, omgivet av ett stort intresse tack vare de möjligheter tekniken för med sig i termer av ökad säkerhet. Det här arbetet kommer betrakta blockchainteknik s˚asom det appliceras inom den finansiella industrin. Mer specifikt s˚a resulterar det här

projektet i konstruktionen av ett beslutsstödssystem. Detta beslutsstödssystem kommer vara en produkt, likt en miniräknare, vilken banker och andra finansiella institutioner kommer kunna använda sig av om

de beslutat implementera blockchainteknik. S˚aledes kommer detta projekt resultera i en färdig produkt, detta innefattar dock även att en analys kommer presenteras gällande vilka algoritmer och protokoll som är bäst lämpade för ett

dylikt beslutsstödssystem. Även en kommentar gällande de juridiska förutsättningarna kommer inkluderas. Slutligen presenteras resultaten som f˚as

vid användande av den färdiga produkten, liksom en analys av systemets kvalitet och användbarhet.

(5)

Acknowledgements

I would like to thank my supervisor, Robert Lagerstr¨om, for providing feedback throughout the scope of this thesis. I would also like to thank Richard

Gendal Brown, Ittay Eyal, Jonathan Jogenfors and G¨oran Gr¨aslund. Their feedback helped greatly to improve the quality of this project. Thank you also

to Alexander Tingstr¨om and Ksenia Loskutova for proofreading the report.

Moreover, I would like to thank my parents, Pia and Tomas Timander, for their constant support.

Finally I would like to thank my mentor, Mari Heidenborg, for all her guidance.

(6)

1 Introduction

This segment aims to introduce the reader to the background out of which this thesis subject arose. Moreover, it aims to explain the purpose of the project in some detail, including in what sense it hopes to offer a scientific contribution to existing literature.

1.1 Project Background

At the time of writing, blockchain technology is a research topic subjected to a great deal of interest, both from an industry perspective and from an academic point of view. The main appeal of blockchain technology is the possibilities it brings in terms of heightened security, transparency and a near non exis- tent corruptibility. One of the main factors contributing to these properties is the innate concept of ”majority rule” implemented by a blockchain infrastructure, this is to say that actions carried out by such an infrastructure need to be approved by a majority of its participants before taking place. As a direct result of this, a blockchain system is to be considered increasingly secure the larger it becomes (i.e. a larger group of participants composing a majority)[14].

Given this property, much existing research focuses on the possible scalability of blockchain systems, i.e. limits of expansion or what the effects of a large scale blockchain infrastructure has on related parameters such as energy consumption and energy cost. Moreover, due to the novelty of the technology itself, much of existing literature is recently published and much research remains to be done.

As for who would stand to benefit most from this new technology, it seems to carry promise of usefulness to many different sectors. However, as can be seen with the emergence of cryptocurrencies such as Bitcoin and Etherium[3], one of the earliest and most prominent of these is within the context of handling money. Thus an interesting and highly relevant question to be examined is how it would be possible to implement this new technology, not only in the form of decentralized currencies but how to best incorporate it into the existing financial industry, bound by restrictions on usability and legality in a way that cryptocurrency is not. At the time of carrying out this project, there already exists several well known attempts to apply blockchain technology to the world of finance. Perhaps the best known of these is the Corda[17] project, aimed specifically at creating a blockchain solution tailored to the financial market and the Hyperledger Fabric, a more general blockchain solution intended to have several possible areas of implementation, finance simply being one among them[19].

With the introduction of the General Data Protection Regulation within the European Union, as of 2018, rules of how larger companies are allowed to handle client information were clarified.¹ Moreover, it carries with it strict financial

1”Protection of personal data (from 2018)”

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=LEGISSUM:310401 2 (accessed 2020-01-21)

(10)

penalties for those companies who fail to comply with its regulations.² Thus it can be assumed that any technology incapable of being made compatible with the General Data Protection Regulation will not be deemed useful for as long as current regulations remain in effect.

1.2 Contribution and Aim

This segment hopes to introduce the reader to the specific aim of this project.

Moreover, it intends to clarify how this project hopes at contribute to existing literature.

1.2.1 Overview

This project aimed to result in an actual, tangible finished product, namely a blockchain decision support system. The target market for said product was professionals within the financial sector, lacking a technical background but having an interest in the possibility of developing a blockchain infrastructure within their company. The intention was that this decision support system would function as a digital aid, akin to a calculator, when evaluating how to best implement a blockchain system. This while taking into consideration factors such as data amount, cost and risks of any legal repercussions. However, this will be done under the assumption that blockchain technology has already been decided to be a preferable approach. Thus, the decision support system will not in any way take into consideration if blockchain implementation should be carried out but simply how this should best be done.

Much information regarding block capacity and blockchain energy consumption and similar could be found (to some extent) within the frame of research regarding cryptocurrencies, such as in Bitcoin. Any legal financial repercussions could also easily be retrieved.

The field in which this project hopes to add a contribution to existing literature is the field of security analysis. Specifically, this project aimed to inves- tigate the possibility of the existence of a direct correlation between the total number of blocks within a blockchain infrastructure and the percentile risks of different security breaches occurring. If on the other hand no such direct correlation could be stated in a way that was to be considered academically sound, then this itself would be considered a result and therefore a contribution in itself.

In conclusion, when having read this report in its entirety, the intent is to have given the reader some further insight into what goes into constructing a useful decision support system for blockchain implementation. More specifically, this report aims to clarify which theoretical principles are relevant to such a system, whether or not currently existing literature is sufficient basis for constructing such a system and if the finished support system could be considered useful in

2”What are the GDPR Fines?” https://gdpr.eu/fines/ (accessed 2020-01-21)

(11)

its current state. Furthermore, this report aims to point to the existing flaws (if any) in said support system as well as some commentary on suggested future work.

1.2.2 Research Question

Commence by recalling the title of this project, ”Using Blockchain Technology to Improve Security of Financial Transactions - a Design Proposal”. The research question that forms basis of this is whether of not a useful decision support system for blockchain implementation can be constructed. That is to say if there exists enough literature and research such that any parameters used in a support system are trustworthy and that they generate useful results. In order to address this question, a necessary preceding question is that of determining which research and what litterature would be necessary in order to carry out the construction of a blockchain decision support system. Moreover, if a useful support system can be constructed, how good are the security predictions it provides?

1.2.3 Limitations

There are two aspects to address regarding limitations placed on this project.

On one hand those placed on time and computational capacity. This project was carried out within the scope of 20 weeks where the computational memory available was that of an ordinary computer. Another limitation was that which was due to the novelty of blockchain technology itself. Blockchain being a novel field of research opened for the risk that some information needed would not yet exist.

1.2.4 Method and Implementation

As for the method used, much of it consisted of selecting which aspects would be suitable to use in a constructed support system. This is to say that the methodology as such came to deciding on protocols, algorithms and limitations. Moreover, there was a need to consider the legal framework surrounding blockchain. A significant part of the methodology was how to handle the lack of existing research. As for the implementation, some part of it consisted of coding and testing the desired blockchain decision support system. Prior to doing so, however, a significant part of the implementation was spent on determining rea- sonable values and parameters to implement, in cases where existing research did not provide them.

1.2.5 Report Structure

Initially a theoretical background segment will be presented. The content of this segment will provide the reader with information regarding the nature of a blockchain and threats relevant to it. Moreover, this segment will address why it is that implementations using blockchain are considered secure. The same

(12)

section will also present the notion of if and how to apply blockchain to the financial sector. Finally, the theoretical segment addresses relevant legal frame- works regarding the usage of blockchain technology. Following this is a segment explaining the method used when constructing the intended blockchain decision support system. After that a segment explaining the implementation itself.

Having been presented the implementation segment, the reader is presented a series of representative results obtained by using the constructed support system. This is followed by a discussion section and a section suggesting future work. As a final note, a conclusion is presented at the end of this report.

2 Theoretical Background

The aim of this segment is to introduce the reader to the underlying workings of blockchain technology. Beyond that, it aims to make a clear connection between blockchain and finance. Within the scope of this segment, all relevant theory will be presented for the reader to fully understand the choices made when constructing the actual support system. This means that the theoretical background segment will cover what a blockchain actually is, from a technical perspective, as well as what constitutes a block therein. Moreover, the reader will be introduced to what a protocol is within the context of blockchain technology, as well as an explanation of those most commonly used. The same goes for the most commonly used consensus algorithms. Some security threats, namely those deemed most relevant to the support system, will be introduced and briefly explained. The reader will also be presented information on why it is that blockchain is indeed considered so secure, as well as the technical and legal implications of applying this new technology to the financial sector specifically.

2.1 Blockchain: Structure

Commencing by looking at the blockchain itself, this segment aims to give a brief yet clear and structured overview of blockchain technology, divided into its main components. Initially the reader will be presented information regarding the cryptographic side of blockchain. Following this will be introduced information regarding the structure itself, namely the blocks and trees that a blockchain contains.

2.1.1 Hashing function

This segment will cover the SHA-256 hashing function. The reason for choosing to focus on the SHA-256 is a combination of two factors. Firstly, it is currently considered the hashing function that is the most secure. Secondly, it is the hashing function implemented by the bitcoin cryptocurrency infrastructure. As for the abbreviation SHA, it stands for Secure Hash Algorithm, where 256 denotes the 256 bits in length resulting from the hash. This 256 bit value is what results is a highly secure hashing, since it results in a total of 2²⁵⁶ possible hash

(13)

values to iterate through in order to find the correct one. SHA-256 is, due to its large amount of hash possibilities, to be considered highly collision resistant³. First composed by the United States National Security Agency (NSA) in 2001 as a further development of the SHA algorithm. In short what the algorithm does is to convert a 512 bit string to a 256 bit equivalent⁴. As previously mentioned, SHA-256 is to be considered collision resistant. Collision resistance in a hash function means that it can be viewed as improbable almost to the point of impossible to find two input values that, when inserted into the function, generates the same output vale. To explain this from a more mathematical point of view, referring here to the definition given by Delfs and Knebl in their book

”Introduction to Cryptography. Principles and applications”[1]. Assume any hash function H such that H takes a string of bits of any size and changes it into a string of bits of a fixed, predetermined size a as follows:

H : {0, 1}^∗−→ {0, 1}^a where in −→ H(in)

Moreover, in this above equation, in denotes the input message. Using this notation, having a collision resistant hash function is the same as saying that it is improbable to the point of impossible to find two input values in1and in2

such that one can obtain H(in1) = H(in2) if simultaneously in16= in2[1].

2.1.2 Asymmetric cryptography

Blockchain technology uses so called public-to-private asymmetric cryptography. To explain what that entails in a satisfying manner it is appropriate to commence by briefly explain what constitutes symmetric cryptography. In his book ”Blockchain Basics. A Non-Technical Introduction in 25 Steps”[2] author David Drescher defines symmetric cryptography as a kind of cryptography method in which the same key that is used to encrypt can also be used to decrypt. This thus brings on the possibility of a security risk. Looking instead at asymmetric cryptography, encryption and decryption is done using not one key but rather a pair of keys. Both keys in this pair are capable to encrypt and decrypt data. What makes this differ from its symmetric counterpart, however, is the fact that encryption key one decrypts what was encrypted by key two and vice versa.This adds another layer of security to the encrypted data since anyone wanting to obtain encrypted information without permission would have to obtain not one but both keys within a key pair[2].

2.1.3 Smart contracts

In their publication ”Do you need a Blockchain?”[3], authors W¨ust and Ger- vais describe a smart contract as a contract that governs and executes itself.

Simultaneously, they do make a point of mentioning that the concept of smart

3E. Kotow. ”What is Blockchain Hashing?” Hedgetrade.com

https://hedgetrade.com/what-is-blockchain-hashing/ (accessed 2019-10-10)

4”SHA-256 Argorithm Overview” SolarWindsMSP

https://www.solarwindsmsp.com/blog/sha-256-encryption (accessed 2020-01-21)

(14)

contracts is still new enough to not be guaranteed legal. Be that as it may, such a self governing type of contract structure is implemented in cases where the parties entering the contract cannot be assumed to trust each other. More specifically, using a smart contract in such a scenario also renders any trusted third party redundant. Smart contract technology is not limited to either public or private blockchain protocols but instead works as intended (and just as well) regardless of choice of protocol[3].

2.1.4 Merkle Tree

Figure 1: Merkle Tree

To best explain the Merkle Tree structure, commence by regarding Figure 1.

The Merkle Tree consists of three different kinds of nodes; the leaf nodes, the nodes and the root note (i.e. the node at the top of Figure 1 above). All these nodes contain hash values. Note that they do not in fact contain the actual information being sent only the hashed values of said information. How the Merkle Tree works is that all pieces of data are hashed into hash values (leaf nodes). Then the hashed values are paired up two by two such that one hash value is appended to the other. This new value is then run through the hash algorithm, creating a brand new hash value. This new hash value then becomes a node in the above tier. This process is repeated until reaching the root node, the so called Merkle Tree root, shown as the top node in Figure 1. So what is the point, or rather the benefit, of the Merkle Tree structure? To best explain the benefit of the Merkle Tree, consider a case where the structure is a chain rather than a tree. When wanting to prove that any message is in fact correct, all hash values between the message and the root is sent to then be compared to the calculated root hash value. The number of necessary hashes between message and root decreases significantly in a tree structure compared to a chain structure⁵.

5”IOTA Tutorial 18 Merkle Tree” mobilefish.com

https://www.mobilefish.com/download/iota/merkle tree part18.pdf (accessed 2020-01-03)

(15)

2.1.5 Blockchain Block

To best explain the structure of a blockchain block, commence by regarding Figure 2.

Figure 2: Blockchain Block

In short, a blockchain block can be divided into two different entities. These are the so called block body and block header. Out of these two, the block body is the part of the block that contains the actual transactions, as well as a counter that keeps track of the total number of transactions kept in that block. As for the block header, this contains a greater variety of of necessary information. This information is block version, parent block hash, merkle tree hash, timestamp, nBits and finally nonce[4]. To fully understand the block header, these terms will now be further explained. The block version tells the rest of the infrastructure what version is the most recent, i.e. which version is to be used (which rules to follow and so on). The parent block hash is a pointer to the preceding block, in form of the hash value of the previous block. The merkle tree root hash is the root hash value such as is mentioned in section 2.1.4. The timestamp of the block header is a timer that shows how many seconds have passed since January 1st 1970. As for the nBits segment, this denotes the correct ”answer” to the hash puzzle used to attach new blocks to the chain. Finally, the nonce field increases for each new hash calculation[4].

2.1.6 Blockchain Transaction Overview

Using cryptography, the node that desires to carry out a transaction using the blockchain generates a private key. This key is used to sign the transaction that the participant wishes to have carried out. The rest of the blockchain structure

(16)

is then informed of the existence of this new transaction. Other actors in the blockchain then need to validate the transaction in question. When validated, the requested transaction is embedded into a block, a block whose existence is then broadcast to the rest of the infrastructure. Thus concluding a transaction.

It is worth noting that transactions need to be confirmed anew when adding a novel block to the system⁶.

Figure 3: Blockchain Transaction Overview

2.2 Blockchain: Types of Protocol

Within the context of blockchain technology, a protocol denotes a composition of different rules that every actor in the network is obligated to follow when exchanging data⁷. This segment will introduce the reader to two of the most common such protocols, namely public blockchain and private blockchain. More- over, the reader will be introduced to two additional ones, namely consortium blockchain and hybrid blockchain.

2.2.1 Public Blockchain

The idea behind a public blockchain protocol (sometimes also referred to as a permissionless blockchain protocol) is that a completely decentralized infrastructure is obtained. Moreover, the public blockchain protocol entails that any blockchain system implementing it is completely open for any new actors to en- ter or leave at will. A key aspect of this protocol is the complete absence of any form of governing authority, rather the infrastructure governs itself. Well known

6I. Siddiqui. ”What The Hell Is Blockchain And How Does It Work? (Simplified)”

medium.com https://medium.com/coinmonks/what-the-hell-is-blockchain-and-how-does-it- works-simplified-b9372ecc26ef (accessed 2020-01-17)

7The Editors of Encyclopaedia Britannica. ”Protocol Computer Science” britannica.com https://www.britannica.com/technology/protocol-computer-science (accessed 2019-10-21)

(17)

examples of applications of the public blockchain protocol are cryptocurrencies such as Bitcoin and Etherium[3].

2.2.2 Private Blockchain

In the case of a private blockchain protocol (also referred to as a permissioned blockchain protocol), the idea of complete decentralization is abandoned. In- stead there exists a central entity that monitors possible new actors in the private blockchain infrastructure. It is this moderator that decides which party will be allowed to join the blockchain[3]. Well known examples private blockchain protocols are Corda and Hyperledger, more on these in section 2.6[5].

2.2.3 Consortium Blockchain

The consortium blockchain protocol has a great many similarities to its private counterpart. The main difference between the two is that where a private blockchain infrastructure is overlooked by one single authority, the consortium blockchain is instead governed by an authoritative body consisting of several parties⁸.

2.2.4 Hybrid Blockchain

With public, private and consortium blockchain protocols defined in the seg- ments above, the hybrid blockchain protocol should lastly be mentioned as well.

Where the public and private protocols have mirrored strengths and weaknesses (one being decentralized while the other holds greater privacy and so on), the main aim of the hybrid blockchain protocol is to maximize benefits while simultaneously minimizing the drawbacks⁹.

2.3 Blockchain: Types of Consensus Algorithms

The purpose of this section is to introduce the reader to three main categories of consensus algorithms, these three being Proof-of-Work, Proof-of-Stake and the Practical Byzantine Fault Tolerance Algorithm.

2.3.1 Proof-of-Work

The idea behind the Proof-of-Work consensus algorithm is that each participant, or miner, within the network try to solve a computationally demanding task as rapidly as possible. The first node to solve the task is then appended to the blockchain. In instances when more than one miner manage to simultaneously

8”What Different Types of Blockchains are There?” dragonchain.com

https://dragonchain.com/blog/differences-between-public-private-blockchains (accessed 2019- 10-12)

9T. Kumar Sharma ”What is Hybrid Blockchain? How Can It Help to Solve Everyday Problems?” blockchain-council.org https://www.blockchain-council.org/blockchain/what-is- hybrid-blockchain-how-can-it-help-to-solve-everyday-problems/ (accessed 2019-10-12)

(18)

solve the computation, a phenomenon known as a fork, both are added and thus form branches in the chain. If branches are undesired, there are ways of attempting to circumvent them. For instance, as is the case with the cryptocurrency Bitcoin, a lower limit of succeeding block can be added. That is to say that, before a new block is added to the blockchain, the algorithm investigates how many blocks have been attached after said block and if there are not a sufficient amount of them then the original block is not added to the chain at all.

The most prominent downside to the Proof-of-Work algorithm is the fact that it is greatly time-consuming, due to the vast amount of calculations required. For instance, if once again regarding Bitcoin, this cryptocurrency requires roughly ten minutes to attach a new block to an existing blockchain. In their article

”Untangling Blockchain: A Data Processing View of Blockchain Systems”[6], authors T.T.A. Dinh et. al. present the following relation used to determine the time needed to add a block to a chain:

H(n||H(b)) < t

In this above relation, b denotes the amount of data in a block, H denotes a hash function and t denotes the necessary amount of time. Finally n denotes the numerical solution to the respective computed task[6]. Assuming a decentralized network, all miners must keep computing values of n until one of the computed values matches the hash value of the header of the last block in the chain. Having achieved this, all other blocks in the chain must confirm that the matching of the hash value is in fact valid. This concludes the adding of a new block. As a final note should be mentioned that the Proof-of-Work consensus is particularly sensitive to so called mining threats, with only 25 percent of total hash power needed in order to dominate the infrastructure. More on this in section 2.4.2[4].

2.3.2 Proof-of-Stake

The Proof-of-Work consensus algorithm, as mentioned in the previous segment, is notably labour intensive. This thus means that Proof-of-Work requires a significant amount of energy in order to be implored. The Proof-of-Stake algorithm offers an alternative to this, a consensus algorithm where the energy need is less substantial. As the name ”Proof-of-Stake” implies, this algorithm is based on the fact that all participating nodes own stake within the infrastructure[7]. So what is the stake exactly? The stake of a node can be regarded as an account attributed to the node in question, where the number in the account is a measure of how invested that specific node is to making the infrastructure work. The Proof-of-Work consensus algorithm introduced the reader to the concept of a fork, i.e. multiple branches within a blockchain. In the case of the Proof-of-Stake algorithm, such forks do not occur but rather does the blockchain consistently maintain its one-branch structure. The way that the Proof-of-Stake achieves this is by adapting the blockchain hash to be inversely proportional to the stake of the node. This is to say that, the higher the stake of the node, the more the node can be considered to be invested in making the chain work. The more invested the node is to make the infrastructure work, the

(19)

easier the hash will be that is required before joining the system. The analogue to the formula given for the Proof-of-Work algorithm would in the case of the Proof-of-Stake algorithm instead be the following (this also from the article by T.T.A. Dinh et al.):

H(n||H(b)) < s(M ).t.

In this above formula, just like in the case of Proof-of-Work, b denotes the amount of data in a block, H denotes a hash function and t denotes the necessary amount of time. Moreover n denotes the numerical solution to the respective computed task in this case as well. What is new in this Proof-of-Stake computational formula is the s(M). The s(M) terms denotes the stake of a certain miner M [6].

BlackCoin Cryptocurrency

Just like cryptocurrencies Bitcoin and Etherium serve as well-known examples of currencies applying Proof-of-Work, the cryptocurrency BlackCoin is a good example of when Proof-of-Stake is being used instead. According to a Black- Coin whitepaper written by Pavel Vasin, there exist several coins that attempt Proof-of-Stake by implementing a combination of Proof-of-Work and Proof-of- Stake. However, as Vasin points out, BlackCoin is the first cryptocurrency that is based solely on a Proof-of-Stake protocol¹⁰.

2.3.3 Practical Byzantine Fault Tolerance Algorithm

In 1982, Leslie Lamport, Robert Schostack and Marshall Peace published the Byzantine Generals Problem[8]. The Byzantine Generals Problem comes down to explaining miscommunication within a digital infrastructure. The means by which this is done are by, instead of a digitized system, imagining byzantine generals agreeing on a battle tactic solely by communicating via messenger. At its essence it comes down to making sure that the existence of corrupt (i.e.

treacherous) generals will not be allowed to influence loyal generals into making poor strategic decisions.[8] In response to the Byzantine Generals Problem, Miguel Castro and Barbara Liskov formulated what is known as the Practical Byzantine Fault Tolerance Algorithm. The purpose of this algorithm is that it is capable of handling any system of nodes such that

n = 3f + 1

where n denotes the total number of nodes in the structure and f denotes the total number of faulty messages permitted within the system. This is to say that an infrastructure is to be considered manageable if the total number of incorrect messages is one third or less of the total number of nodes[9]. How the algorithm itself works is that it consists of three consecutive steps; pre-prepare, prepare and commit. In the pre-prepare stage of the algorithm execution, a new block is created and introduced to the existing blockchain network (i.e.

10P. Vasin ”BlackCoin’s Proof-of-Stake Protocol v2” blackcoin.co

https://blackcoin.org/blackcoin-pos-protocol-v2-whitepaper.pdf (accessed 2019-12-28)

(20)

each and every single node in the blockchain network will be notified of the existence of this newly created block). Following this, a pre-prepare message is sent to all nodes within the system, who then validate said message. With the pre-prepare stage now finished, the algorithm moves on into the prepare stage.

In the prepare stage, a so called prepare message will be broadcast by nodes receiving information of a novel block. This broadcast will reach the entire network of nodes, including the node responsible for the actual broadcast. At this point, the node awaits receiving a total of 2f+1 prepare messages of exactly the same type that the node itself had just sent (from all other nodes in the infrastructure). Having done so, the prepare stage is to be considered completed.

Finally, the algorithm enters the commit stage. The first thing that happens when reaching this stage is that the node in question sends a commit message to the network in its entirety (again including itself). Much like was the case in the previous, preparing stage, the commit stage is considered completed when the node receives 2f+1 commit messages (of exactly the same type) in return¹¹.

2.4 Blockchain: Possible Security Issues

This segment will cover some of the more common security attacks regarding blockchain technology. Mainly, the focus will lie on the threats associated with the construction side rather the encryption flaws related to the blockchain structure itself. What will be covered more specifically is double-spending threats (caused by faults in transaction verification (and consensus, in the case of the so called 51% attack)), mining threats (caused by faults in the consensus algorithm, among other factors), network threats (caused by faults in routing and protocol) and finally smart contract threats (caused by faults in design)[12].

2.4.1 Double-Spending Threats

In his book ”Blockchain Basics. A Non-Technical Introduction in 25 Steps”[2], author Daniel Drescher points out the fact that a double-spending threat could really imply three different things:

1. Peer-to-Peer distributed ledger issues. This issue really comes down to the fact that each and every party in a blockchain infrastructure needs to contain the same information. Thus any information entering the infrastructure needs to be distributed between all. Such distribution take time. As a result of this, there is a period during the distribution process where not all parties contain the same amount of information, i.e. some have obtained information and some are yet to. This provides the informed nodes with a possibility to repeatedly claim ownership of data, i.e. double spending.

2. Peer-to-Peer integrity violation issues. This double-spending issues ties in

11L. Steeley ”Introduction to Sawtooth BPFT” hyperledger.org

https://www.hyperledger.org/blog/2019/02/13/introduction-to-sawtooth-pbft (accessed 2020-01-01)

(21)

with the previous. The difference is that in this case, within this definition, the double-spending comes as a result of it being difficult to evenly and consistently distribute all information to all parties involved. With inconsistent information distribution comes thus the issue of information in some node at some point in time being inconclusive.

3. Issues regarding the copying of digital entities. Out of the three issues mentioned here, this is the one that is the most self explanatory. It simply alludes to the fact that any piece of digital information can be freely copied without affecting the original. This creates obvious issues when it comes to transactions, especially those of a financial nature. If data can be freely copied and if - within the scope of a transaction - all money is purely digital, then this opens for the possibility to simultaneously both spend and keep a fixed amount of money, i.e. double spending. Money is created where it should not be[2].

Moreover, authors Karame et. al. mention in their publication ”Double-Spending Fast Payments in Bitcoin”[10] three different factors that need to be put in place in order for a double spending attack to occur. These are the following:

1. A transaction is confirmed by the blockchain at large.

2. The vendor of the transaction has as service time that is small enough not to detect its malicious activities.

3. A transaction is added to the wallet belonging to the vendor of said transaction[10].

2.4.2 Mining Threats

There are a couple of different mining threats, whereas this report will mainly focus on two of them. namely so called ”selfish mining” and ”pool mining”.

Selfish mining, briefly explained, is when a miner mines not only a block but a chain of blocks entirely in private, before announcing this new private chain to the rest of the of the blockchain network. In somewhat greater detail, selfish mining consists of two main steps; the mining procedure and the release procedure. As for the mining procedure, this in turn consists of two separate possible scenarios. One of these is when the selfish miner continues to mine the public blockchain. This is done when the selfish miners private chain is shorter than the chain in the public network. The other of the two scenarios is when the selfish miner continues mining on the private chain. This is done in cases where the selfish miner realizes that the chain belonging to the public network is shorter than the private counterpart of the selfish miner itself. Moving on to the release procedure, this procedure consists of three possible scenarios. In one of these cases, the selfish miner realizes that the public network chain is longer and simply gives up the private chain entirely. Thus conforming solely to public chain mining. On the contrary, if the selfish miner releases its private network to the public network and it turns out that the private network is the longer

(22)

one, then the honest miners in the system also chooses to start appending to the newly introduced, formerly private network. As for another of the three possible scenarios, this is where the difference in size between the private chain and the public network chain is not to be considered significantly large but with the private still being the larger one. In such a case the selfish miner will be prone to choose to release its private network, simply not to loose it advantage altogether. Finally for the third possible scenario regarding the release procedure. This scenario is based on the existence of more than one selfish miner within a network. In cases of this happening, when one selfish miner releases its private network then the other selfish miner chooses to do so as well[11].

As for the so called pool mining, this is when a number of different miners come together toward mining a new block in a blockchain. Having done so they then divide the reward among them in relation to how much processing power each of the miners invested in this new block. This is, from the point of view of the miners, a compelling approach since the computational power needed to mine a single blockchain block is significant and increasing. Where the risks come into this scenario are either from the inside of the pool itself or from the outside of it[12]. A good example of when threats come from within the pool itself is the occurrence of a so called block withholding attack. In the case of such an attack, the malicious participant joins a pool under the pretence of having honest intentions. This malicious participants chooses, however, not to contribute with any Proof-of-Work solution (and thus not to contribute to the pool effort). The rest of the pool will nevertheless share any obtained revenue with the malicious participant[13]. As an example of how a mining pool can serve as an outer threat to a blockchain network, look at the so called 51%

attack. A 51% attack is where an actor (miner) acquires 51% or more of the total blockchain infrastructure, thus gaining majority and therefore control of the system¹².

2.4.3 Network Threats

Within the scope of network threats related to blockchain fall DDOS, transaction maillability attacks, routing attacks and timejacking attacks. There are others beyond these but this report will focus on explaining the above four at some depth. A DDOS attack, or distributed denial of service attack on the application layer of the blockchain infrastructure, is when an infrastructure is fed an excessive amount input requests. This to a point where an overload is reached. A DDOS attack entails consuming a significant portion of the available bandwidth[12]. Moving on to the router attack. Either this can consist of dividing a network into several disconnected parts (i.e. making any information transfer between these parts impossible). This will then result in the creation of parallel blockchain structures. The other possibility is that an attack results in

12Jimi S. ”Blockchain explained: how a 51% attack works (double spend attack) blog.goodaudience.com https://blog.goodaudience.com/what-is-a-51-attack-or-double- spending-attack-aa108db63474 (accessed 2020-01-02)

(23)

block delivery being delayed.This is to say that the network under attack will be completely unaware of the most recently created block. A delay of this nature can last up to 20 minutes at most¹³. Looking now at the so called timejacking attacks. Very briefly, this is when an attacker tries to modify the timestamps of the blocks in the blockchains. This is done as an attempt to, for instance, drain resources or enabling double spending attacks[12].

2.4.4 Smart Contract Threats

In essence any flaw in a smart contract will, along with the contract itself, be public to the entire network. This in itself poses a security threat to the contract since any flaw or bug in a contract can be exploited. Moreover, this security threat becomes more complex due to the very nature of the blockchain. Since by its construction it is not possible to alter a blockchain when an action has been carried out, there is no possibility to ”fix the problem” in the conventional sense when finding a bug or flaw in the code. Instead the best approach in such a scenario is to find a way around the discovered bug.¹⁴ A well known example of a smart contract breach occurred in 2016 when a hacker managed to obtain a significant amount of cryptocurrency from a so called decentralized autonomous organization calling itself simply ”the DAO”. In this case, a so called ”recursive call bug” was exploited to a point where the attacker managed to obtain roughly 3.6 million units of the Ether cryptocurrency¹⁵.

2.5 Blockchain: Why it is Considered Secure

The presumption on which this project in its entirety is founded is that a blockchain based transaction framework would be more beneficial to the financial sector than any digital infrastructure currently in use. So even when taking into consideration all of the security risks mentioned in section 2.4. This section aims to, at some depth, explain the reasoning behind said presumption.

2.5.1 Academic Reasoning

In his book ”Blockchain. The ultimate guide to the world of blockchain technology”[14], author Ikuya Takashima argues for five different factors that put together make up why blockchain technology is to be considered a secure alternative. One of these five is the fact that all data is stored on a permanent basis, i.e. impossible to remove or loose. This in turn follows from the fact that data within a blockchain structure is linked together, much as the name itself

13”Blockchain meets Internet Routing” btc-hijack.ethz.ch https://btc-hijack.ethz.ch (accessed 2020-01-02)

14M. Orcutt. ”Once hailed as un-hackable, blockchains are now getting hacked” technologyreview.com https://www.technologyreview.com/s/612974/once-hailed-as-unhackable- blockchains-are-now-getting-hacked (accessed 2019-10-16)

15David Spiegel ”Understanding the DOA attack for Journalists” published 19 Jan 2016 https://medium.com/@pullnews/understanding-the-dao-hack-for-journalists-2312dd43e993 (accessed 2020-01-22)

(24)

suggests. This is to say that each individual block of data is directly linked to its predecessor. Moreover, each individual transfer of data across the chain is assigned a time stamp. Recall now that all changes within a block infrastructure requires approval from each and every party involved. Changing any aspect of a transaction would mean changing the entire transaction over the entire infrastructure as a whole. Security here comes as a consequence of the fact that convincing all parties of such a change would be highly unlikely. This distribution of data is also the basis of the second of the five factors, namely that all of the transported data (in other words, the entire database) is stored in more than one place. This enables access to all of the data by all participants without any need for any third party, with the added benefit of knowing that the data obtained is indeed correct due to the very nature of blockchain construction. As third of the five factors can be mentioned that any data transfer carried out by implementing blockchain technology can be carried out by means of predetermined logic. This is to say in an automated fashion. Though it is worth noting that all the necessary steps of blockchain interaction and methodology still need to be followed as would be expected, automation does come with certain benefits. Examples of such is that automation creates the possibility of scheduling when any one transaction is to be carried out. As the second to last of the five factors, note the possibility of combining transparency within a transaction with a certain level of anonymity still maintained. This is to say that each node in the blockchain infrastructure is assigned a specific so called identifier. It is possible for each and every user to make an active choice to reveal their actual identity and not only their identifier. This is not however a requirement, the identifier alone is sufficient. Finally, for the fifth and final factor, any transmission done by using blockchain is done using peer-to-peer rather than going through a server[14].

2.5.2 Comment from Industry

This segment offers the reader a brief insight into the industry perspective on the security aspect of blockchain technology. Information presented will, in its entirety, be based on an interview with Jonathan Jogenfors, research manager at Sectra Communications AB. When addressing security of blockchain, Jogenfors commences by wishing to define exactly what the term security entails in this specific context. The three possible meanings mentioned are confidentiality, correctness and availability. If referring to security as correctness, then Jogenfors is of the opinion that blockchain technology is to be considered highly secure, given that every aspect of the system can be digitized. The reasoning behind Jogenfors’ conclusion is that blockchain based transactions are all but impossible to re-route or intercept. If instead of correctness, the term security is used to refer to availability, Jogenfors makes note of a few flaws. An example of such would be that if any key is lost, then so is the associated Bitcoin. This is to say that blockchain technology takes no regard to the human performance or any human flaw of any kind. Looking into the future, Jogenfors hypothesises that availability, or rather lack thereof, will make for possible security issues.

(25)

He points out that any possibility of error will eventually result in one and that any system that cannot be considered usable cannot be considered safe either.¹⁶

2.6 Applying Blockchain to Finance

In a 2017 white paper publication titled ”Applications of blockchain technology to banking and financial sector in India”[15] issued by the Institute for Devel- opment and Research in Banking Technology, blockchain is mentioned to be a possible solution to the three most prominent issues within the field of information. More precisely, blockchain is though to offer a manner of simultaneously handling availability, confidentiality and integrity issues.When regarding the financial benefits of implementing blockchain technology within the financial sector, the above mentioned white paper lists three main aspects that are likely to improve. These are the aspect of efficiency, the aspect of transparency and the aspect of saving on costs. Moreover, each of these tree are further divided into several subgroups. When discussing the matter of efficiency, the four subcategories mentioned are ”Reduced time for processing” and ”Resiliense through redundancy” as well as ”Saving in decision making time” and ”Faster settlements”. As for the second aspect, transparency, there are two subcategories listed; ”Provenance” and ”Immutable Transactions”. Finally, when regarding the issue of saving on costs, the three factors listed are ”Save costs on forex volatility”, ”Save cost over delayed settlements” and ”Fraud Preven- tion”[15]. Furthermore, in his book ”Blockkedjan. S˚a fungerar den, s˚a anv¨ander du den”[16], author Christoffer De Geer argues that the upside to blockchain technology as applied to the financial sector at large is that the technology offers means to increase efficiency when it comes to processes carried out internally by a body or organization. Moreover, he mentions that it also offers a degree of flexibility of transaction that would not otherwise be. However, De Geer also offers a word of caution. Today’s current banking structure, which includes banks as trusted third parties, has some benefits that a blockchain based counterpart would lack. Was an error to occur in a transaction using the current system, the trusted third party would still be capable of stepping in and attempt to fix it. This will be rendered impossible if blockchain is implemented and trusted third parties removed[16].

On another note, Ikuya Takashima mentions in his book ”Blockchain. The ultimate guide to the world of blockchain”[14] a few other ways in which the financial industry may come to experience an impact from the introduction of blockchain. This report will focus on three of these. Takashima points out that fraud related to transaction would be preventable and thus stopped before any damage is done to either the client or the service provider. This due to the fact that every step of any transaction will leave a traceable footprint. The risk of credit card hijacking also goes away entirely since implementing a blockchain

16Interview via email with Jonathan Jogenfors, research manager at Sectra Communications AB, 12 November 2019

(26)

infrastructure would make the use of credit card information altogether redundant. Finally, Takashima leaves an interesting comment on the future of the retail sector. At present, the time necessary to verify a financial transaction is far too long to within reason be implemented in everyday retail purchases.

Assuming however that that obstacle goes away with further research and development, two possible benefits are on the horizon for the retail industry. The benefit seen from the point of view of the customer is more or less the same as the one previously stated, i.e. the risk of credit card copying diminishes.

From the perspective of the service provider blockchain with rapid verification enabled would make it possible to see money from a purchase arrive at their bank account far more rapidly than what is currently possible[14].

In an interview with Jonathan Jogenfors, as introduced in section 2.5.2, he expresses growing scepticism regarding the actual usability of blockchain technology. He is of the opinion that few individuals living in the west will stand to gain from it, this since very few actually carry out financial transactions across national borders. Moreover, the existing issues regarding scalability constitutes a major obstacle. Furthermore, he points out that the hard limitations that exist regarding transaction time as well as the staggering energy consumption that blockchain requires. Jogenfors’ opinion is that banks need not worry too much about cryptocurrencies. In addition, he would advise financial institutions to focus on improving currently existing digital infrastructure, rather than putting resources into developing blockchain technology. When asking Jogenfors to comment on the difference between private blockchain protocol and currently existing databases in order to explain why the blockchain option is preferable he made several interesting remarks. According to Jogenfors, there is no defi- nite, adequate reason why blockchain would be preferable. Contrarily, he argues that a significant majority of cases where a private blockchain protocol is being used, a traditional database is likely to work just as well if not better. He also mentions that a large part of the conversation surrounding blockchain can be credited to hype. Having said that, he comments that blockchain technology in and of itself is likely to remain. The use cases that do exist, however specific, are still situations where blockchain is being actively used. Therefore there might be reason, for financial institutions, to keep track of how this technology devel- ops. With that said, Jogenfors’ personal advice regarding the matter would be for banks and other financial institutions to not in fact implement blockchain technology. Instead, those resources would be better spent improving already existing digital infrastructure.¹⁷

In a 2017 paper titled ”Blockchain Technology: Transforming Libertarian Cryp- tocurrency Dreams to Finance and Banking Realities”[5], by Ittay Eyal at Cor- nell University. Eyal mentions two different types of blockchain solutions currently implemented by industry, namely one called Corda and another called

17Interview via email with Jonathan Jogenfors, research manager at Sectra Communications AB, 12 November 2019

Using Blockchain Technology to Improve Security of Financial Transactions - a Design Proposal