Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se
Linköping University | Department of Computer Science
Bachelor thesis, 16 ECTS | Datateknik
2018 | LIU-IDA/LITH-EX-G--18/006--SE
A Security Analysis of a
Credit Card Payment System
for Bitcoin Transactions
Niklas Grundström
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Abstract
Cryptocurrencies has become a very hot topic recently, with Bitcoin being the most popular. The increase in interest has led to an incentive to create payment systems for the currency that makes it easier to use for day-to-day shopping. A lot of companies are inves-tigating possible solutions for credit cards that are used for cryptocurrencies. This thesis aims to present and perform a security analysis on an already created concept of a credit card payment system for Bitcoin. The security analysis is done in a systematical approach where the modules were analyzed with predetermined restrictions and assumptions. The restricitons and assumptions are then removed one-by-one to find potential threats in the system. The outcome of the analysis is then evaluated in an attempt to find possible im-plementation methods that would mitigate or prevent the discovered threats. The possible implementations are also evaluated in terms of how they would affect the system.
Acknowledgments
I would like to thank my examinator Mikael Asplund as well as my supervisor Jonas Wallgren for providing me with insightful
viewpoints as well as constructive criticism, and feedback throughout this entire thesis. I would also like to thank Mikael and Linköpings university for providing me with an office while working on this thesis which made it a lot easier to keep a consistent work schedule.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures viii
List of Tables ix
1 Introduction 1
1.1 Motivation . . . 4
1.2 Aim of this Thesis . . . 4
1.3 Research questions . . . 4 1.4 Method Overview . . . 4 2 Theory 5 2.1 Bitcoin . . . 5 2.1.1 Bitcoin Wallets . . . 5 2.2 Blockchain . . . 6 2.2.1 Proof of Work . . . 6 2.2.2 Forks . . . 7 2.3 Transactions . . . 9 2.3.1 Replace-By-Fee . . . 9 2.3.2 Zero-conf transaction . . . 9 2.3.3 Transaction Malleability . . . 10 2.4 EMV . . . 10 2.5 Propagation . . . 10 2.6 Double-Spending attack . . . 11 2.7 Sybil Attack . . . 12 2.8 Previous Work . . . 12 2.8.1 System Design . . . 13 3 Method 16 3.1 System Model . . . 16
3.1.1 Card and Card Reader Manufacturer . . . 16
3.1.2 Modules . . . 17
3.1.3 Communication . . . 19
3.2 Security Analysis . . . 20
3.3 Assumptions and Restrictions . . . 20
3.4 Threat Model . . . 20
3.4.1 Threats . . . 21
3.5 Evaluation . . . 21
4 Threat Taxonomy 22
4.1 Dishonest Card Owner . . . 22
4.1.1 Initial Threats . . . 22
4.1.2 Threats Regarding the Card . . . 23
4.1.3 Threats Regarding the Network . . . 23
4.1.4 Threats Regarding the Store . . . 23
4.1.5 Assumptions and Restrictions With No Effect . . . 24
4.2 Dishonest Store . . . 24
4.2.1 Initial Threats . . . 24
4.2.2 Threats Regarding the Communication . . . 24
4.2.3 Threats Regarding the Card Reader . . . 25
4.2.4 Assumptions and Restrictions With No Effect . . . 25
4.3 Dishonest Card Manufacturer . . . 25
4.3.1 Initial Threats . . . 25
4.3.2 Threats Regarding the Card . . . 26
4.3.3 Threats Regarding the Card Reader . . . 26
4.3.4 Assumptions and Restrictions With No Effect . . . 26
4.4 Outside-Attacker Targeting the Card, Store, Backup Server, Bitcoin Network or the Card and Card Reader Manufacturer . . . 27
4.4.1 Initial Threats . . . 27
4.4.2 Threats Regarding the Card . . . 27
4.4.3 Threats Regarding the Communication . . . 27
4.4.4 Assumptions and Restrictions With No Effect . . . 28
4.5 Physical Security Threats . . . 28
4.5.1 Initial Threats . . . 28
4.5.2 Assumptions and Restrictions With No Effect . . . 29
4.6 Communication Reliability Between Card User, Store, Backup Server, Bitcoin Network, or the Card and Card Reader Manufacturer . . . 29
4.6.1 Initial Threats . . . 29
4.6.2 Threats Regarding the Backup Server . . . 30
4.6.3 Threats Regarding Connections . . . 30
4.6.4 Assumptions and Restrictions With No Effect . . . 31
4.7 Summary . . . 31
5 Security Analysis 34 5.1 Threats and Vulnerabilities . . . 34
5.1.1 Double-Spending Attack . . . 35
5.1.2 Separate Card Reader . . . 35
5.1.3 Finding the Private Key from the Public Key . . . 36
5.1.4 Visible Private Key . . . 36
5.1.5 Lost Connection to the Bitcoin Network . . . 36
5.1.6 Interrupting the Store’s Connection . . . 36
5.1.7 Anonymity of Backup Transaction . . . 36
5.1.8 Malleability Attack . . . 37
5.1.9 Malicious Card Reader . . . 37
5.1.10 Storage and/or Misuse of Private Keys . . . 37
5.1.11 Tampered Card Readers . . . 37
5.1.12 Dishonest Miners . . . 38
5.1.13 Leaked Private Keys . . . 38
5.1.14 Denial-of-Service Attack . . . 38
5.1.15 Sybil Attack . . . 38
5.1.16 Package Sniffing . . . 38
5.1.18 Incomplete Backup Transaction for a Lost and/or Stolen Card . . . 38
5.1.19 Hardware Error in the Card . . . 39
5.1.20 Inconsistent Backup . . . 39
5.1.21 Inaccessible Backup . . . 39
5.1.22 Backup Failure . . . 39
5.1.23 No Access to the Internet . . . 39
5.1.24 Man-in-the-Middle Attack . . . 39
5.2 Design Issues and Mitigations . . . 39
5.2.1 Acceptance Conditions for Transactions . . . 40
5.2.2 How and/or When Backups are Created . . . 41
5.2.3 Where Transactions are Created . . . 42
5.2.4 Card and Card Reader Manufacturer . . . 47
5.2.5 Network Security . . . 48
6 Discussion 49 6.1 Results . . . 49
6.1.1 Acceptance Conditions for Transactions . . . 49
6.1.2 How and/or When Backups are Created . . . 51
6.1.3 Where Transactions are Created . . . 51
6.1.4 Card and Card Reader Manufacturer . . . 51
6.1.5 Excluded Issues . . . 52
6.2 Method . . . 52
6.3 Source Criticism . . . 53
6.4 The work in a wider context . . . 53
7 Conclusion 54
List of Figures
1.1 Every block contains a reference to the previous block in the blockchain. . . 1 1.2 Some exchange facilities provides a service for customers that enables them to
make purchases with their bitcoins, however, the store receives the payment in form of their "normal" currency, the exchange facility will trade the customers bitcoins to the requested currency at the current exchange rate. . . 3 2.1 When two blocks are completed in a similar time frame, a race conditions
deter-mines which one is the honest chain. When one end of the blockchain becomes longer, it will announce the height of the blockchain to its neighbouring nodes and the neighbouring nodes will announce it to their neighbouring nodes. Once the propagation has gotten through the entire network, the network has agreed on a honest chain and the other blocks become invalid or orphaned blocks. In the figure block 2 and block 2 (orphaned) are completed in a similar time frame but when one of the nodes that follow block 2 completes block 3 the information that there is a new longest blockchain propagates through the network, and any node that used to consider block 2 (orphaned) as the blockchain head then changes to the new, longer part of the blockchain. . . 8 2.2 Not everything in the transaction is signed by both parties, but all of the data
is included in the completed hash. The sender could thus change parts of the transaction (marked in red in the figure), which would create a new valid and signed transaction with a different completed hash. . . 10 2.3 Blocks are propagated through the Bitcoin network using inv and getdata messages
to avoid sending unecessary blocks. The inv message announces that the transac-tion or, in this case, the block, exists. The getdata message is the request response a node sends back if they have no knowledge of the announced transaction or block. [decker2013information] . . . . 11 2.4 If the attacker chain becomes longer than the honest chain that information will start
to spread through the network and eventually make the honest chain invalid. . . 12 2.5 High-level diagram of how the communication between user, store, backup server,
and Bitcoin network is intended to work in the system presented by Lövhall [lovhall]. The numbers represent the order of execution for a new transaction. . . . 13 2.6 Sequence diagram of the presented system design with a separate backup server. . 15 3.1 System model diagram of the intended system. . . 17 6.1 The maximum transaction size, in BTC, that can be considered as safe
depend-ing on how much of the network’s hash rate the adversary possesses (q) and how many block confirmations one can wait before accepting the transactions (n). Source: M. Rosenfeld [rosenfeld2014analysis]. . . . 50
List of Tables
2.1 A block header consists of different fields with different values, these values are used to generate the hash value that is compared with the target. When a hash that is equal to or lower than the target is generated, the block gets added to the blockchain. . . 7 3.1 Assumptions and restrictions for the designed system . . . 20 5.1 Summary of the advantages and disadvantages of having the card create the
trans-action. . . 46 5.2 Summary of the advantages and disadvantages of having the card reader create
the transaction. . . 47 5.3 Summary of the advantages and disadvantages of having the store create the
transaction. . . 47
1
Introduction
The last ten years cryptocurrencies have sky-rocketed in value. More and more people are looking to start investing into cryptocurrencies. The largest and most common being Bitcoin followed by Ethereum, the focus in this thesis is primarily on Bitcoin. Cryptocurrency was first introduced in an article by Satoshi Nakamoto[25], in the form of Bitcoin, as a currency without the need of a third-party, like a bank, to keep a ledger. The idea behind Bitcoin is that anyone that invests in the cryptocurrency gets connected to the network together with everyone else invested in the cryptocurrency. Everyone in the network also have access to the the ledger. The ledger consists of a record of every transaction ever made with the cryp-tocurrency. Every transaction ever made can be traced within the ledger. All transactions are stored inside of blocks. One block can contain many transactions but a transaction can only be in one block. The blocks are linked together by order of completion, meaning that they form a chain that always leads back to the first block, called the genesis block. This chain is called the blockchain (section 2.2).
The blocks contain a block-ID, a hash value that references the previous block (figure 1.1) and a list of transactions containing information regarding where the money is sent from, where it is going and how much it is [25]. The hash value to the previous block is the link between the blocks and this is what creates the blockchain.
Figure 1.1: Every block contains a reference to the previous block in the blockchain. When someone invests in the currency, which usually means opening a Bitcoin wallet (section 2.1.1), they get a set of public and a private keys and become a part of the network. These keys are used to validate transactions while keeping the user as anonymous as possible. When someone makes a transaction, it gets announced into the network (section 2.3). When a new block is created, a definite number of new transactions are added to the block and the block gets attached to the blockchain.
Generating a new block uses proof of work (section 2.2.1), this is commonly called mining. Every block contains a mathematical problem that needs to be solved before the new block
can be accepted into the chain [17]. In bitcoin, the problem consists of generating a SHA-256 hash value that is lower than or equal to a target value in order to be accepted by the network. This target value fluctuates over time so that the average time of generating one block remains the same, in bitcoin, the average time for one block to be completed is ten minutes. When a problem is solved, it is very easy for the rest of the network to confirm that the solution is valid, and the one who solved the problem is rewarded with some currency as well as the transaction fees of all the transactions that are included in the block. This means that there is a constant race towards who will complete the next block [25].
If two people solve a block at a similiar time, it will create a fork in the chain. When a fork is created, a race condition determines which one will be part of the blockchain (section 2.2.2). A problem with this is if someone controls a large part of the hash rate in the network they could deliberately perform multiple transactions using the same funds, and then start working towards completing the next block. If they complete the next block before the first transaction gets included in a block the first transaction becomes invalid. This is called a double-spending attack (section 2.6). A double-spending attack is when someone uses the same bitcoins (BTC) to make multiple different transactions or purchases making everyone except one invalid. By doing this the person who performs the attack only have to pay for one of the transactions or purchases but can still claim the purchased item or received bitcoins [18].
As an additional security measure to this, a common solution is to wait for a number of blocks to be completed before a transaction is considered safe. It is commonly cited that waiting for six blocks to be completed before accepting a transaction is good safety rule. The more blocks that gets chained after the block with the made transaction gets completed, the higher the chances of the transaction being safe. The downside to this is that it takes a lot of time to wait for new blocks to be generated, which means slower transactions. According to M. Rosenfeld [28], if someone controls 10% of the hash rate, it would take waiting for two blocks to be generated to reduce the risk of a successful double-spend attack to below 10%, four blocks for the risk to be below 1%, and six blocks for the risk to be below 0.1%. The often cited number of six block confirmation stems from the assumption that an attacker would unlikely posses more than 10% of the networks hash rate (section 2.2.1).
A downside to cryptocurrencies today is that there is no way to pay with a credit card without the involvement of a third-party. Currently, the most common way to provide a service for making payments with a card using cryptocurrency is a service distributed by ex-change facilities [23]. When something is purchased from a store in bitcoin, the store displays the price of the product in bitcoin. The customer then pays the store using a provided service, often a application for their smartphone or a normal card. The exchange facility creates a Bit-coin transaction with the customer and a normal transaction with the store. The exchange facility requests a Bitcoin transaction from the customer who then sends the required amount of bitcoins to the exchange facility. Simultaneously, the exchange facility pays the store the worth of the bitcoins in the stores usual currency (figure 1.2). Since the store never receives the actual cryptocurrency, they avoid any of the risks involved in trading with cryptocurren-cies. The risk is entirely held by the service provider who risks losing the transaction if the customers bitcoin transaction becomes invalid after the purchase has been made. This also requires the involvement of the service provider in every purchase, making the privacy and anonymity of the cryptocurrency almost redundant. Another service that a lot of companies provide is the possibility of tagging the bitcoin wallet to a MasterCard or Visa, this again requires the involvement of a third party.
Figure 1.2: Some exchange facilities provides a service for customers that enables them to make purchases with their bitcoins, however, the store receives the payment in form of their
"normal" currency, the exchange facility will trade the customers bitcoins to the requested currency at the current exchange rate.
But, since one of the main incentives behind Bitcoin is to have a decentralized electronic payment system based on proof of work instead of trust to eliminate the involvement of a third-party [25], having a service that requires the involvement of a third-party is somewhat contradictory.
Implementing a credit card for bitcoins without any involvement from a third party would require that it is secure and fast in order for both stores and customers to want to use it. The store needs to be able to make sure that they receive their money before they give the customer their product. As seen in the example earlier this creates a problem, since if one were to wait for six blocks to be added onto the chain before accepting the transaction, the customer would have to wait in the store for around an hour before the store can confirm that the transaction is safe. That would not be convenient or appealing for the customer.
One solution to this could be to use a second account that is only accessible by a unique credit card, a concept introduced by J. Lövhall[22]. The credit card contains a unique private key hidden from everyone except the card itself. The card can then be used to sign trans-actions between a customer and a store. The card would presumable work like a normal credit card that needs to be placed in a card reader. When a purchase is made with the card, it is being communicated with in order to sign the transaction. This would reduce the risk of a double-spending attack since there would only be one card per account and the reader would be able to check previously sent transactions from the card, and since there is a time constraint when moving between payment terminals. The second account would also act as a backup server which means that the card owner does not lose all his money if the card were to be lost.
1.1. Motivation
1.1
Motivation
Many companies are currently investigating possible solutions for credit cards with cryp-tocurrency, however, most of them use the concept of having the company work as a third-party. Lövhall [22] presents a possible solution to a decentralized credit card with his design of a Bitcoin payment system that uses a card with a local storage that can make bitcoin trans-actions just like a normal credit card. The card also uses a backup server to restore any lost bitcoins in case the user lose their card.
For this solution to be valid, it needs to be fast and secure, for both the customer and the merchant in order to be able to compete with the existing credit cards of today. For the store, there is a positive side to giving their customers the possiblity of paying with bitcoins. It is of course beneficial to the store to give the customer as many ways as possible to pay for their purchases. For the customer, the main concept is to be able to pay in a fast and efficient way while keeping the same privacy and anonymity that Bitcoin provides. This requires that no third-party is involved between the customer and the store when a transaction is made.
However, the solution presented by Lövhall [22] does not contain a satisfying security analysis of the intended system. For this to be considered a good solution, it has to be secure, fast and reliable enough to be able to compete with the already existing credit and debit cards. This requires an analysis of the potential vulnerabilities of the system if the presented design would be implemented.
1.2
Aim of this Thesis
The aim in this thesis is to perform a security analysis of the system presented in Lövhall’s thesis [22] using a systems modeling approach. By setting up restrictions and making as-sumptions in the systems model every module and the communication between the modules will be evaluated and analyzed in order to find as many vulnerabilities as possible in a struc-tured way. This is performed by setting up restrictions and assumptions and then looking at every module individually. Then each assumption and restriction are removed one by one in order to discover what threats exists in the system and what causes them.
1.3
Research questions
1. What vulnerabilities and threats can be found in the presented system while assuming different restrictions and assumptions, and what vulnerabilities and threats would be found when different restrictions and/or assumptions are removed?
2. What kind of mitigations could be implemented for the discovered vulnerabilities, and how would they affect the usability of the system?
1.4
Method Overview
The security analysis is done by creating a model of the system and then looking at a set of adversaries and what vulnerabilities they could present in the presented model. The vulner-abilities are found by setting up restrictions and stating assumptions regarding every adver-sary and then analyzing what effects they could have on the modules in the system and the communication between the modules. The aim is to first setup a restricted system with few possible vulnerabilities and then removing the restrictions gradually and change assump-tions to open up the system to more hazards. By gradually exposing the system to more vulnerabilities the risk and probability of them occurring becomes more evident.
2
Theory
This chapter explains terms that the reader needs to know in order to understand the concepts behind this thesis. It also explains the designed system in the previous work by Lövhall [22].
2.1
Bitcoin
Bitcoin is a decentralized virtual cryptocurrency introduced in 2008 in a paper by Satoshi Nakamoto [25]. The main concept behind Bitcoin is a peer-to-peer cryptocurrency without the involvement of a third-party financial institution, it is based on cryptographic proof in-stead of trust. The transactions are purely between the sender and receiver and they are broadcasted over a peer-to-peer network. Everything is public but still anonymous. Bitcoin uses a distributed ledger that every node in the network downloads as soon as they become part of the network. The transactions work similarly to the information released in stock exchanges, it shows when it was sent and how much money has been traded, and it gives information that it was sent from someone to someone. The transactions stay anonymous by giving the owner a set of private and public keys. The only way of finding out who a public key belongs to is if you know the private key, which is only known to the owner. As an ad-ditional security, the keys are frequently replaced to disable someone from linking a specific key to a common owner.
2.1.1
Bitcoin Wallets
Bitcoins are usually tracked in something called a bitcoin wallet. The wallet contains a list of the user’s private keys. Bitcoins are traded between users as transactions, and new bit-coins are only created by miners. A user’s available bitbit-coins, or unspent transactions, are any transactions sent to them that have not yet been used as inputs in a new transaction (section 2.3). A bitcoin wallet helps the user to keep track of his or hers unspent transactions. A wallet can also be refered to as the client software that is used to keep track of, and create, transac-tions in the bitcoin network. A bitcoin wallet can be seen as a digital bank for bitcoins. The wallet also stores a list of all bitcoin transactions ever made by that wallet. Every transaction can therefore be validated by the wallet using references to the previous transactions [16]. If
2.2. Blockchain
a wallet is lost without any backup, the bitcoins on that wallet are lost and gone from the system forever.
2.2
Blockchain
The concept of a blockchain was first introduced by Satoshi Nakamoto [25]. Every block contains data of newly added transactions and a hash value that works as a reference to the previous block. This hash value creates a link between the new block and the previous block and thus forms a chain that goes all the way back to the first block ever created, called the genesis block. The blockchain contains every transaction ever made with bitcoins. The blockchain acts as a public ledger. The blockchain is shared by every full node in the bitcoin network. This means that every full node can see how much value belongs to each address at any point in time. Every computer that is connected to the network and uses some form of client to relay and validate transactions is considered a full node [30]. Blocks are created by so-called miners competing against each other to solve a mathematical problem, in a so-called Proof of Work (section 2.2.1) system [17].
If one would try to change the information in a block not at the end of the blockchain, they would also have to recalculate the proof of work for all the successors to that block. This would require an enormous amount of computational power. The only way of successfully doing this is if someone would own over 50% of the hash rate in the entire network, since they also must catch up to the end of the blockchain and therefore competes against the en-tire network. If someone owns over 50% of the hash rate, they would be in majority and therefore always catch up to the end of the blockchain, eventually. If a majority of the nodes are honest nodes, an attacker would have a decreasing chance of successfully changing pre-vious transactions the further back into the blockchain they go. A security risk with this is the possibility of a double-spending attack (section 2.6). The more hash rate someone possesses, the higher the risk of a double-spending attack.
2.2.1
Proof of Work
Proof of Work (POW) works by confirming that when a solution to a problem is found, a significant amount of computational work has been made in a certain amount of time. By increasing the difficulty of the problem the average time it takes for the network to find a solution can be adjusted. In the Bitcoin protocol, the difficutly is adjusted so that one block is solved every ten minutes, on average. When a solution is found, it is very easy for the rest of the network to verify that the solution is correct, regardless of the difficulty of the problem. Bitcoin uses a POW system called Hashcash-SHA256.
SHA-256 (Secure Hash Algorithm) is the algorithm used in the POW system. It compares a computed hash value with a expected hash value to determine the integrity of the data [12]. Hash rate is meassured in hashes per second which translates to the number of double SHA-256 computations can be performed in one second. Currently, the bitcoin network performs over 14 quintillion hashes per second [14].
Hashcash is a POW system introduced by Adam Back [2]. It works by having miners try-ing to compute a hash value that is equal to or lower than a current target by trytry-ing different values using brute force. The target is a 256-bit number that is the same for every client in the Bitcoin network. The hash value generated by the miners is obtained from hashing the values in the block’s header. The block header consists of the following fields; Version, hash-PrevBlock, hashMerkleRoot, Time Bits and Nonce. The hash derived from the block’s header is changed by changing the Nonce field, usually by incrementing it (table 2.1). The target value can be changed to fluctuate the average time it takes for a problem to be solvled and a new block added to the blockchain. In Bitcoin, the difficulty of the work that needs to be done is adjusted so that the average amount of blocks added to the chain is six per hour, or one every ten minutes. When a miner manages to find a hash that matches or is lower to the target, 6
2.2. Blockchain
their block gets added to the blockchain and they are rewarded with some BTC. The number of BTC the miner is awarded with is regulated depending on how many blocks currently ex-ists in the blockchain. In the beginning, the bounty was 50 BTC, this value is halved every 210 000 blocks mined. Currently, as of September 2017, the bounty is at 12.5 BTC.
Table 2.1: A block header consists of different fields with different values, these values are used to generate the hash value that is compared with the target. When a hash that is equal
to or lower than the target is generated, the block gets added to the blockchain.
Field Purpose Updated when... (Bytes)Size Version Block version number Software is upgraded and itspecifies a new version 4 hashPrevBlock 256-bit hash of the previous block header A new block comes in 32 hashMerkleRoot 256-bit hash based on all of the transactions
in the block A transaction is accepted 32
Time Current timestamp in seconds Every few seconds 4
Bits Current target in compact format The difficulty is adjusted 4 Nonce 32-bit number (starts at 0) A hash is tried (increments) 4
2.2.2
Forks
Sometimes two or more miners manages to solve a problem and complete a block before the information about the block being completed gets propagated through the network. When this happens they both get added to the blockchain. This creates a fork in the blockchain (Fig-ure 2.1). When a fork is created the network disagrees on which end is the current blockchain head, the head is the node with the highest block height in the blockchain. If there are two equally long chains, a node considers the one it received knowledge of first as the blockchain head. This creates a race condition regarding which part of the chain can add another block to their part of the chain the fastest. When one part of the chain becomes longer than the other, that information gets sent through the network. The blockchain head is always the longest possible chain, this means that once one part of the chain becomes longer then the other the information about a new longest chain will get propagated through the network. The nodes who previously followed the other part of the blockchain will now know that there is a longer blockchain and will disregard the other part of the blockchain and all the blocks in that part of the chain will be considered invalid. The transactions contained in the invalid blocks will revert to unconfirmed and then be mined into a new block that goes into the longest chain [9]. A fork can become longer than one node if both parts of the chain manages to solve another block before one part of the chain becomes out-propagated.
2.2. Blockchain
Figure 2.1: When two blocks are completed in a similar time frame, a race conditions determines which one is the honest chain. When one end of the blockchain becomes longer, it
will announce the height of the blockchain to its neighbouring nodes and the neighbouring nodes will announce it to their neighbouring nodes. Once the propagation has gotten through the entire network, the network has agreed on a honest chain and the other blocks
become invalid or orphaned blocks. In the figure block 2 and block 2 (orphaned) are completed in a similar time frame but when one of the nodes that follow block 2 completes
block 3 the information that there is a new longest blockchain propagates through the network, and any node that used to consider block 2 (orphaned) as the blockchain head then
changes to the new, longer part of the blockchain.
2.3. Transactions
2.3
Transactions
BTC is created by miners, and the ownership of the coins are then traded through transac-tions. Every transaction contains a reference to the previous transaction that the BTC was used in, this validates ownership of the BTC used in the transaction. When someone wants to make a transaction with BTC, a new one is made between the sender and the receiver. The transaction consists of an input and one or more outputs. A transaction must spend the entire cumulative sum of the input, or the BTC is lost. Therefore, it is common to have two or more outputs, where one output refers to the sender and sends back the change from the transaction.
A person’s available BTC are often called unspent transactions. Unspent transactions are any transaction that is not yet used as an input in another transaction.
The input has a reference to previously made transactions with the BTC to verify that they are not already spent.
When a transaction is accepted, it gets announced to the nodes and spread through the network [3]. It is then up to the miners to include the new transaction in a new block. If the transaction is not a part of the blockchain, it is not considered completed. The transaction is only completed once it enters a block that gets linked to the blockchain. If a transaction gets completed, there is no way of reverting it since reverting a transaction would mean redoing the block the transaction exists in and thereby redoing every block in the chain succeeding that block [9].
2.3.1
Replace-By-Fee
In the Bitcoin protocol there is a feature called opt-in Replace-By-Fee (RBF). Wallets that use this function enables the user to send a signal together with the transactions to let the receiv-ing nodes’ know that the transaction can be replaced with a updated version of the transac-tion with a higher transactransac-tion fee [27]. A transactransac-tion that uses RBF can be updated until it gets confirmed and enters a new block.
The idea behind RBF is to create a way to manually speed up the confirmation process of a transaction. For example, if there is a sudden surge of new transactions in the memory pool after the transaction is sent, the same transaction could be sent again with a higher transaction fee to replace the old transaction and to encourage the miners to include the new transaction over other transactions since the miners receive an overall higher earnings from accepting transactions with higher transaction fees.
This means that RBF deliberately gives the payer an easy way of performing a double-spending attack. Both parties of the transaction can however see if the transaction uses RBF or not. It is also up to the individual miners if they want to accept RBF transactions and if they want to replace the older transaction. If there is no RBF signal together with the transaction and a node receives an updated version of the transaction, the new transaction will be flagged as a double-spending attack (section 2.6).
2.3.2
Zero-conf transaction
Zero-conf transactions are transactions that are accepted by the receiver before they enter the blockchain [19]. The name comes from zero confirmations, since the transactions are accepted with zero block completion confirmations. By accepting zero-conf transactions the receiver takes a risk by assuming that the payment is valid. If a transaction becomes invalid after the initial payment the store lose all the money since they already accepted the transaction. It is often discussed whether zero-conf transactions is a good thing or not. One side thinks it is an unnecessary risk while the other side considers that the convenience of fast payments for the customers outweighs the drawbacks of the monetary loss.
2.4. EMV
2.3.3
Transaction Malleability
A transaction needs to be signed in order to be completed. However, the hash generated from the transaction contains the whole transaction, while the signature used to sign the transaction only uses parts of the transaction [1].
Figure 2.2: Not everything in the transaction is signed by both parties, but all of the data is included in the completed hash. The sender could thus change parts of the transaction (marked in red in the figure), which would create a new valid and signed transaction with a
different completed hash.
This means that the receiver can change the input script in the transaction after the sender signs the transaction (figure 2.2), which would generate a different hash. When those two hashes are compared in the final stages of the transaction, they will not be equal and thereby be viewed as invalid [10].
2.4
EMV
EMV is a standard for smartcards, it stands for Europay, Mastercard and Visa, the companies involved in creating the standard. Currently, the standard is managed by EMVCo LLC, a privately-owned corporation. EMVCo is owned by American Express, Discover, JCB, Mas-tercard, UnionPay and Visa. All the owners have equal shares in the company. Devices under the EMV standard are tested by EMVCo to make sure that they meet the requirements set by the technical standard and that they provide a secure payment method. EMV cards are smart cards, or Integrated Circuit Cards, that are created to be tamper-resistant [26]. The payment method is often referred to as “Chip and PIN” since it uses the chip together with a PIN for authentication when making transactions. Since the chip is a programmable integrated circuit it can use cryptographic algorithms and encryptions to protect the information used during transactions [29].
2.5
Propagation
Originally all blocks are introduced to the network in a single node and then broadcasted through the rest of the network. Propagation of blocks and transactions in the Bitcoin network works by having every node to inform the neighboring nodes about the information of newly added blocks and transactions. When updating the ledger there are two different types of messages that are relevant, transaction (tx) and block (Block) messages [9].
2.6. Double-Spending attack
When a node completes a block or transaction and it gets verified, it sends an inv mes-sage to its neighbors announcing its existence. The neighboring nodes then return a getdata message and then the first node sends the tx or Block message. Once a new node receives the block or transaction, it will announce that to its neighbors and so on, until everyone in the network has received the block or the transaction (figure 2.3) [9].
Figure 2.3: Blocks are propagated through the Bitcoin network using inv and getdata messages to avoid sending unecessary blocks. The inv message announces that the transaction or, in this case, the block, exists. The getdata message is the request response a
node sends back if they have no knowledge of the announced transaction or block. [9]
The idea of sending an inv message before sending the block is to avoid sending blocks or transactions to nodes that already know of its existence. Due to this broadcast method, there is a propagation delay in the spreading of new blocks. Decker and Wattenhofer [9] found that the median time for a node to find out about a block is 6.5 seconds, and the mean is 12.6 seconds. The distribution of the time showed that 5% of the nodes still had not received the block after 40 seconds.
The propagation time for a block enables the use of invisible double-spending attacks due to merchants not knowing about contradicting transactions until it is too late [9].
2.6
Double-Spending attack
A double spending attack is when someone tries to use the same BTC to pay for multiple things simultaneously. This is done by making two or more transactions with the same BTC as input at the same time. If someone pays for something with BTC and then makes another transaction with the same BTC a race starts to decide which transaction gets accepted into the blockchain (figure 2.4). The attacker need to out-calculate the rest of the network in order to make his second transaction valid by completing the block before the rest of the network [25]. By doing that, the attacker can create a fork that becomes longer than the previous longest chain. The network will then accept the new fork as the new blockchain head, and any blocks on the other tail will of course be discarded. When one of the transactions gets accepted into the blockchain, the other transaction will be deemed invalid, and the attacker might have been able to purchase something without paying anything.
2.7. Sybil Attack
Figure 2.4: If the attacker chain becomes longer than the honest chain that information will start to spread through the network and eventually make the honest chain invalid. Another way of performing a double-spending attack is if the receiver accepts transactions that are not yet accepted in a block, so called zero confirmation transactions (section 2.3.2). The attacker could spend the same BTC for multiple purchases and only one of them would be accepted, while the others would be detected as contradicting transactions and therefore invalid [18].
The likelihood of a double-spending attack being successful depends on how much hash rate the attacker possesses. A way of mitigating the risk of double-spending attacks is to wait for a specific number of blocks to be added onto the blockchain before accepting a transaction. The probability of a double-spending attack succeeding is determined by how much of the hash rate the attacker controls and how many blocks the transaction decides to wait before being completed [28]. It is often said that the safe number of block confirmations before accepting a transaction is six. This is because it is unlikely that an attacker controls more than 10% of the hash rate, and if they control 10% there is a 0.06% success rate for the attacker. If the attacker controls over 50% of the hash rate, the probability of a successful double-spending attack will always be 100%, since sooner or later they will out-calculate the honest network .
2.7
Sybil Attack
A sybil attack is when an adversary creates multiple nodes in a peer-to-peer network. The nodes can be pseudonymous identities or real entities [11]. By controlling large portions of a network an adversary achieves a larger influence and can control what information or data gets shares between the peers. In a Bitcoin network an sybil attack means that an adversary creates or controls many nodes and can use them to isolate parts of the network from the honest network. By isolating a node, they can stop transactions from propagating to, or from that node, they can also choose what information gets propagated to the isolated node. A sybil attack in a Bitcoin network usually aims to increase the chances of performing a double-spending attack once a node has been isolated.
2.8
Previous Work
In this section, the work previously done by Lövhall [22] will be explained, both an overview of the presented system and the design choices he made for the payment system.
2.8. Previous Work
2.8.1
System Design
This section will describe the different design methods Lövhall [22] chose in his suggested solution for a debit card payment system using bitcoin.
System Overview
The proposed system is based on a card that is used like a normal credit card in a card reader. The card keeps track of the user’s unspent transactions and contains a unique private key that is hidden, even to the user. Since the key is unique, a person can only possess one card per account at a time. When a payment is made with the card, the remaining funds on the card after the required amount for the transaction is withdrawn, are sent to a backup server using a separate transaction sent through a normal Internet connection. This transaction also has a time-lock. If the user were to lose the card, the backup server still holds the remaining funds. This way the users monetary losses are minimized. Once the backup is completed, the store will announce the transaction through the network (figure 2.5).
Figure 2.5: High-level diagram of how the communication between user, store, backup server, and Bitcoin network is intended to work in the system presented by Lövhall [22]. The
numbers represent the order of execution for a new transaction.
Time-Lock
The backup transaction has a time-lock with a globally known lock time that is assumed to be set in advance for all cards during manufacturing. If the card user makes another transaction using any of the inputs that exists in the backup transaction, the backup becomes perma-nently invalid. If the time-lock expires, the backup transaction becomes valid. Since the lock
2.8. Previous Work
time is globally known, the store can check if any transactions has been made with the card within the time frame of the time-lock. If no transaction has been made, the store can choose to not accept the payment from the card to avoid the risk of a double-spending attacks. If a transaction has been made, the store knows that the backup is invalid and can accept the pay-ment without any risks. If the card user wants to make a purchase while a backup is valid, he either needs to find a store that accepts these conditions or make a transaction between his own accounts to invalidate the backup [22].
Backup
The backup protocol that was chosen to avoid losing bitcoins in the case that the card was lost in the presented system is a personal backup that uses a server thats stores the remaining bitcoins on the card. Every card owner has their own backup server. The criterias for the protocol is a fast and secure solution where the card owner does not need to trust a third-party and is able to retrieve his lost bitcoins in the case that the card is lost [22].
When the seller asks for payment, the card owner will first create a transaction for the payment, then a separate backup transaction that holds the remaining money on the card and a receiving address (figure 2.6). This is done by using the card in a card reader, just as a normal credit card payment. The backup transaction will then be sent from the card to the card reader. The card reader will then forward it to the backup server using the address given by the card. Once the backup server returns a confirmation to the card reader, the card reader sends a confirmation to the card. Then the card sends the payment to the card reader and the payment gets added to the Bitcoin network in the same way as any other type of BTC transaction [22].
Since the backup is sent and the confirmation is returned before the payment is sent, there is no need for the card owner to trust the store to send the backup transaction. The transaction can be cancelled without receiving a confirmation about the backup transaction from the store [22].
2.8. Previous Work
Figure 2.6: Sequence diagram of the presented system design with a separate backup server.
Local Storage
The card needs to know about unspent transactions in order to be able to create new pay-ments and to create the backup transactions. The method chosen for this was a local storage on the card. The card therefore needs to be updated about the current blockchain in order to know about all the unspent transactions [22].
3
Method
This chapter will describe the methods used in the security analysis.
The analysis is divided into three parts, the purpose of the steps are to find, evaluate, and mitigate vulnerabilities in the targeted system. The method used for finding vulnerabilities in the presented system is based on setting up a threat model with a set of restrictions and assumptions [20]. Every discovered vulnerability will be evaluated.
Restrictions in the system refers to how many involved members the transactions have, the amount of involved nodes in the network and how many links there are between the different nodes. At first the analysis is performed in a very strict environment with many restrictions, (i.e. number of nodes and links). The restrictions will then be reduced step by step as the analysis progresses. The goal is to reach a realistic environment at the end of the analysis.
3.1
System Model
This section explains the intended systems model in this thesis (figure 3.1 for overview).
3.1.1
Card and Card Reader Manufacturer
For the system to maintain the decentralization that cryptocurrencies strive towards, it would be preferred if a third party was not involved in the manufacturing of the cards or the card reader. That would however, lead to the manufacturing being put into the hands of the owners of the card readers or the users of the cards, which could be considered an even bigger risk. A feasible solution is to have a similar system as with the EMV smart cards (section 2.4), where multiple partners go together and form a corporation that makes sure that the payment cards, payment terminals and automatic teller machines (ATMs) are secure and tamper-proof. The incentive for the manufacturing process lies in the earnings received from selling the cards and the card readers. For this thesis, we assume that this is the implemented method, meaning that the payment cards, payment terminals and ATMs work the same way and have the same security as the existing EMV smart cards.
3.1. System Model
3.1.2
Modules
This section includes explanations for every module in the systems model.
3.1. System Model
Card
The card is assumed to work as a normal smart card with a readable cryptographic chip that can be used in a card reader. The chip is an integrated circuit that enables the card to store information. The integrated circuit also enables the card to perform calculations which enables the use of data encryption.
The card contains a private key that should be hidden to everyone. The private key is generated during the manufacturing of the card by the manufacturer. The private key is used to sign transactions from the card. A card owner is restricted to one card per account. The card’s local storage contains information of all the unspent transactions on the card. This information needs to be updated regularly since when the card receives funds, the new card balance is unknown until the information is updated. The card needs to be able to keep track of the available balance on the account. There are different possibilities on how this information is updated, in Lövhall’s design [22] it was suggested that it would be done using special ATMs or by connecting the card to a reader with an internet connection. The design choice is left open at this point and it should be decided and evaluated after the analysis.
We assume that the card has the same security and tamper-proofing as the EMV standard. This implies that the communication between the card and the card reader is encrypted.
As with EMV cards, when the card user inserts the card into the card reader he must enter a PIN consisting of four integers to start the transaction.
Card Reader
The card reader works like a normal card reader for smart cards. The card reader is connected to a Bitcoin node and has access to the Internet. Since the reader is connected to a Bitcoin node it has knowledge of the Bitcoin ledger. Same as with the card, we assume that the card reader has the same security and tamper-proofing as the EMV standard. This implies that the communication between the card and the card reader is encrypted in some way.
Backup Server
The backup server could be anything with a Internet connection that can receive Bitcoin trans-actions, for example a third-party company or the card owner’s smartphone. For this thesis the card owner’s smartphone will act as a backup server since it can be used as a Bitcoin wallet, making it very easy to implement, would give a high availability and it would be easy to use. The backup server can communicate with the card reader through an Internet connection.
The backup itself is a different Bitcoin account owned by the card owner. The smartphone can easily keep track of the backup account using any type of Bitcoin wallet. The backup transaction is a Bitcoin transaction with a globally known time-lock.
The lock time is set for all cards during manufacturing. If any other purchases are made using the card within the lock time the backup becomes invalid. If the lock time expires and no changes have been made to the unspent transactions on the card, the backup transaction gets announced to the Bitcoin network and once it enters the blockchain it becomes valid.
Backup transactions are stored in the server, regardless of them becoming valid or not, for a predetermined amount of time.
Bitcoin Network
The Bitcoin network is a cluster of nodes that communicate with each other. The nodes send information about newly discovered transactions to its neighbors using inv and getdata mes-sages. This way new transactions get propagated through the network, when one of the nodes with information about the transaction finishes a block, it can include transaction in the block and then the transaction enters the blockchain and becomes valid.
3.1. System Model
3.1.3
Communication
This section explains the communication between the modules in the systems model.
• Payment Request
The card reader sends a payment request to the card. This request is sent through the physical connection between the card and the card reader. The payment request consists of a unique Bitcoin address and the requested amount of bitcoins. The unique address is generated by the Bitcoin wallet used by the card reader.
• Backup Transaction to Card Reader
The card sends the backup transaction to the card reader. The backup transaction con-tains a Bitcoin transaction containing the unspent transactions on the card, an address to the backup account and a globally known time-lock that becomes invalid if the card owner makes another transaction with the card. This transaction is sent through the physical connection between the card and the card reader. This transaction is sent through the physical connection between the card and the card reader.
• Backup Transaction to Backup Server
The card reader sends the backup transaction to the specified address. This transaction is sent through an Internet connection.
• Backup Confirmation to Card Reader
The backup server sends a confirmation back to the card reader stating that the backup transaction is received and accepted. The confirmation message is sent through an In-ternet connection.
• Backup Confirmation to Card
The card reader forwards the backup confirmation message to the card. This request is sent through the physical connection between the card and the card reader.
• Payment Transaction
Once the card has received the confirmation that the backup was successful it signs and sends the payment transaction to the card reader. This transaction is sent through the physical connection between the card and the card reader.
• Announce Transaction
When the card reader receives the payment transaction it propagates it to the network by sending a inv message to the neighboring nodes in the Bitcoin network. The nodes who answer with a getdata message stating they have not yet received information about this transaction will then receive the content of said transaction 2.5.
3.2. Security Analysis
3.2
Security Analysis
The security analysis follows a systematic approach to find possible threats and vulnerabil-ities in the system. The idea behind this approach is to look at the different modules and communications steps in the system design and find possible threats and vulnerabilities pre-sented in every step with a selected assumed adversary.
The first step is to find important assets in every module and communication step and how they are protected in the presented system with a very strict set of assumptions and restrictions on the system.
The second step is to assume an adversary and observe what threats it would introduce to the designed system, which assets are at risk and if there are any existing methods to protect said assets. This will be done for every adversary stated in the earlier chapter one by one. Once the entire system has been observed while assuming every adversary on its own, multiple adversaries will be assumed simultaneously and then the system will be observed again. This will be done for every combination of adversary that is feasible. The assumptions and restrictions stated on the system will then be removed one by one to open up the system to more threats.
The threats presented are then evaluated in terms of their likelihood and the impact it would have on the system and what methods could be used to prevent said threats.
3.3
Assumptions and Restrictions
This section describes the different assumptions and restrictions implied in the system in the beginning of the security analysis. These assumptions and restrictions can then be removed one by one to make the analysis more systematic.
Table 3.1: Assumptions and restrictions for the designed system
Modules
Card
The private key is hidden from everyone in the system
including the manufacturer.
The information stored on the card is hidden and encrypted.
Card Reader
The card reader cannot be tampered with.
The internet access is available.
Backup Server
The backup always succeeds.
The backup is always available.
The backup cannot be tampered with.
The internet access is available.
Bitcoin Network
The network is always available.
Communication
Messages sent through the system cannot be altered
after being sent.
The connection between the modules cannot be interrupted.
3.4
Threat Model
Threats to the system could be either an adversary or reliability issues within the system. To find adversaries in the presented system, we assume an adversary with the worst possible in-tentions. The adversary could be someone attacking from the outside, one of the participants in the transactions, or reliability issues with either the Bitcoin network or the backup server. If one of the participants in the transactions is the adversary, we assume that they are willing to risk all the assets they involved in the transaction. If the adversary is someone from the
3.5. Evaluation
outside, we assume they can threaten every step of the communication in the systems model. We also assume that they can perform the most common types of attacks on the targeted sys-tem. To find reliability issues we assume that every step in the communication path between the modules could be altered or disrupted.
3.4.1
Threats
This section describes the different kinds of threats that are considered in this thesis.
• Dishonest Card OwnerA threat where the card owner is an adversary with malicious intentions towards the store.
• Dishonest Store A threat where the store is an adversary with malicious intentions towards the card owner.
• Dishonest Card ManufacturerA threat where the card manufacturer is an adversary where the intentions are to either steal money from the card owner or use the card owner’s credentials to perform actions with malicious intent.
• Outside-Attacker Targeting the Card, Store, Backup Server, Bitcoin Network or the Card and Card Reader ManufacturerA threat where an adversary is someone trying to penetrate any of the modules in the designed sytem with the intention of either dis-abling the access to or stealing assets. For example a hacker.
• Physical Security ThreatsA threat where the adversary is someone or something that could threaten the physical condition of the card, store or backup server. This could be environmental threats such as power outage, fire, earthquakes. But also threats where adversary is a person, such as theft, break-ins or vandalism or if the card user loses possession of the card in any other way.
• Communication Reliability Between Card User, Store, Backup Server, Bitcoin Net-work, or the Card and Card Reader ManufacturerThe threat is a reliability issue that could be anything that could change the transaction or disrupt the communication be-tween the modules in the presented system.
3.5
Evaluation
The vulnerabilities found in the suggested system are evaluated by determining the risk and probability of them occurring, and the cost and impact they would have on the system if they occurred. For the threats that are deemed too significant to be ignored there should be an attempt to find implementations or changes to the presented system that could mitigate the threat.
4
Threat Taxonomy
This chapter contains the results conducted from the security analysis described in the previous chap-ter (chapchap-ter 3).
The system was first observed with all the assumptions and restrictions listed in the pre-vious chapter (section 3.3).
4.1
Dishonest Card Owner
This section states the threats and vulnerabilities that exists in the system when assuming a dishonest card owner together with the previously stated assumptions and restrictions.
4.1.1
Initial Threats
These are the threats that were discovered while assuming all the initial assumptions and restrictions.
Double-Spending Attack
With the card owner as the adversary, the biggest threat is the possibility of a double-spending attacks (section 2.6). The card owner could purchase something from a store and then try to purchase something else from a different store using the same bitcoins as transac-tion input. If the attack succeeds the card owner would manage to purchase two items while only paying for one of them. The faster the card owner can reach a different terminal and use the card again, the higher are the risks of the attack being successful.
Separate Card Reader
The card user could purchase a card reader of their own and use it together with another Bitcoin wallet they own. This could be used to perform double spending attacks after a purchase in a store has been made. This would put the store’s assets at risk.
4.1. Dishonest Card Owner
4.1.2
Threats Regarding the Card
These are the threats that were discovered when the following assumptions and restrictions were removed:
• Card
– The private key is hidden to everyone in the system including the manufacturer.
– The stored information on the card is hidden and encrypted.
Finding the Private Key from the Public Keys
Since the card uses the same private key every time it signs a transaction the card owner could theoretically find the private key from the signature used in the backup transaction. If the card user were to find the card’s private key, the card could be duplicated, or the private key could be used to sign transactions without the card. This would enable more ways to perform double-spending attacks.
Visible Private Key
If the card user has access to the private key on the card, the card user could sign transactions without the card or create counterfeit cards to increase the chances of performing double-spending attacks. The store’s assets would be at risk if this was to happen.
4.1.3
Threats Regarding the Network
These are the threats that were discovered when the following assumptions and restrictions were removed:
• Bitcoin Network
– The network is always available.
Lost Connection to the Bitcoin Network
If the Bitcoin network was unreachable for the store for some time, the card owner would have a longer time span to propagate a new transaction and increase the chances of succeed-ing with a double-spendsucceed-ing attack. This puts the store’s assets at risk.
4.1.4
Threats Regarding the Store
These are the threats that were discovered when the following assumptions and restrictions were removed:
• Card Reader
– The internet access is available. • Communication
– The connection between the modules cannot be interrupted.
Interrupting the Store’s Connection
The card owner could interrupt the messages sent from the store to the Bitcoin network by either denial of service or sybil attacks (section 2.7). This could delay the transactions enough for the card owner to create a new transaction of his own and propagate it to the Bitcoin network and receive a headstart against the store. This would increase the chances for the card owner of successfully performing a double-spending attack. This puts the store’s assets at risk.
4.2. Dishonest Store
4.1.5
Assumptions and Restrictions With No Effect
The following assumptions and restrictions did not affect this adversary: • Card Reader
– The card reader can not be tampered with. • Backup Server
– The backup always succeeds.
– The backup is always available.
– The backup cannot be tampered with.
– The internet access is available. • Communication
– Messages sent through the system cannot be altered after being sent.
4.2
Dishonest Store
This section states the threats and vulnerabilities that exists in the system when assuming a dishonest store together with the previously stated assumptions and restrictions.
4.2.1
Initial Threats
These are the threats that were discovered while assuming all the initial assumptions and restrictions.
Anonymity of Backup Transaction
Since the card user always uses the same address as receiver for the backup transaction and all transactions made with bitcoins are public, the store could potentially find all the transactions made by the card. This would affect the card user’s privacy.
4.2.2
Threats Regarding the Communication
These are the threats that were discovered when the following assumptions and restrictions were removed:
• Communication
– Messages sent through the system cannot be altered after being sent.
Malleability Attack
A malleability attack is a variant of a double-spending attack but where the attacker is the receiver instead of the sender. It works by abusing the fact that Bitcoin transactions are mal-leable (section 2.3.3).
The store can change either the backup transaction or the transaction it announces to the network. If the store successfully changes the backup transaction it would become invalid and not accepted since the store has no knowledge of the public and private keys used to generate the completed hash. If the backup transaction becomes invalid no backup confir-mation will be sent back to the store and the card owner would know that something went wrong. If the store changes the transaction it announces to the network it could potentially invalidate the purchase while still claiming the bitcoins transferred. This would cause the card user to lose bitcoins.
4.3. Dishonest Card Manufacturer
4.2.3
Threats Regarding the Card Reader
These are the threats that were discovered when the following assumptions and restrictions were removed:
• Card Reader
– The card reader can not be tampered with.
Malicious Card Reader
The store could tamper with the card reader to display one cost and require the card to sign with more bitcoins without the knowledge of the card user. The card user has no way of knowing how much money has been sent to the store or how much has been sent through the backup transaction. This puts the card user’s assets at risk.
4.2.4
Assumptions and Restrictions With No Effect
The following assumptions and restrictions did not affect this adversary: • Card
– The private key is hidden to everyone in the system including the manufacturer.
– The stored information on the card is hidden and encrypted. • Card Reader
– The internet access is available. • Backup Server
– The backup always succeeds.
– The backup is always available.
– The backup cannot be tampered with.
– The internet access is available. • Bitcoin Network
– The network is always available. • Communication
– The connection between the modules cannot be interrupted.
4.3
Dishonest Card Manufacturer
This section state the threats and vulnerabilities that exists in the system when assuming a dishonest card manufacturer with the previously stated assumptions and restrictions.
4.3.1
Initial Threats
There were no threats found for this adversary with all the initial assumptions and restric-tions.
