19,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
The gold standard in up-to-date blockchain cybersecurity handbooks In Blockchain Security from the Bottom Up: Securing and Preventing Attacks on Cryptocurrencies, Decentralized Applications, NFTs, and Smart Contracts, accomplished blockchain and cybersecurity consultant and educator Howard E. Poston delivers an authoritative exploration of blockchain and crypto cybersecurity. In the book, the author shows you exactly how cybersecurity should be baked into the blockchain at every layer of the technology's ecosystem. You'll discover how each layer can be attacked and learn how to prevent and respond to those attacks in an environment of constant technological change and evolution. You'll also find: * Illuminating case studies of real-world attacks and defenses at various layers in the blockchain ecosystem * Thorough introductions to blockchain technology, including its implementations in areas like crypto, NFTs, and smart contracts * Comprehensive explorations of critical blockchain topics, including protocols, consensus, and proof of work A can't-miss resource for blockchain and cybersecurity professionals seeking to stay on the cutting-edge of a rapidly evolving area, Blockchain Security from the Bottom Up will also earn a place on the bookshelves of software developers working with cryptocurrencies and other blockchain implementations.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 244
Veröffentlichungsjahr: 2022
Ähnliche
Table of Contents
Cover
Title Page
CHAPTER 1: Introduction to Blockchain Security
The Goals of Blockchain Technology
Structure of the Blockchain
Inside the Blockchain Ecosystem
Threat Modeling for the Blockchain
Conclusion
CHAPTER 2: Fundamentals
Cryptographic Primitives
Data Structures
Conclusion
Notes
CHAPTER 3: Protocols
Consensus
Block Creation
Conclusion
Notes
CHAPTER 4: Infrastructure
Nodes
Networks
Conclusion
Notes
CHAPTER 5: Advanced
Smart Contracts
Blockchain Extensions
Conclusion
Notes
CHAPTER 6: Considerations for Secure Blockchain Design
Blockchain Type
Privacy and Security Enhancements
Legal and Regulatory Compliance
Designing Secure Blockchains for the Future
Index
Copyright
Dedication
Acknowledgments
About the Author
About the Technical Editor
End User License Agreement
List of Illustrations
Chapter 1
Figure 1.1: Structure of the blockchain ecosystem
Figure 1.2: Structure of the blockchain network
Figure 1.3: Structure of a blockchain block
Figure 1.4: Structure of a blockchain block
Figure 1.5: Structure of a blockchain transaction
Chapter 2
Figure 2.1: Example of a Merkle tree
Chapter 4
Figure 4.1: Routing attack
Figure 4.2: Sybil attack
Chapter 5
Figure 5.1: Integer overflow
Figure 5.2: Frontrunning attack on a decentralized exchange
Guide
Cover
Table of Contents
Title Page
Copyright
Dedication
Acknowledgments
About the Author
About the Technical Editor
Begin Reading
Index
End User License Agreement
Pages
iii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
137
138
139
140
141
142
143
145
146
147
148
149
150
151
152
153
154
iv
v
vii
ix
xi
155
Blockchain Security from the Bottom Up
Securing and Preventing Attacks on Cryptocurrencies, Decentralized Applications, NFTs, and Smart Contracts
Howard E. Poston III
CHAPTER 1Introduction to Blockchain Security
Blockchain is a new and exciting technology that provides alternative ways of accomplishing common goals. Blockchains make it possible to maintain distributed, decentralized, and immutable digital ledgers. The contents of these ledgers are also designed to be publicly visible, enabling anyone in the blockchain network to independently verify the legitimacy of the data and transactions that the ledgers contain.
However, blockchain technology is also complex. Even the original, basic blockchains like Bitcoin are multilayered systems that use an array of algorithms to ensure the validity and immutability of the distributed ledger. Smart contract platforms go even further, allowing programs to run on top of the distributed ledger.
Before diving into blockchain security and how these systems can be attacked, an understanding of some fundamentals is necessary. This chapter starts with a discussion of the goals of the blockchain and how it works at a high level. In the second half, I'll break down the blockchain ecosystem into more manageable chunks and discuss threat modeling for the blockchain.
The Goals of Blockchain Technology
Blockchain technology provides an alternative means of maintaining a digital ledger. The design of the blockchain offers certain promises or guarantees that are fulfilled at varying levels.
Anonymity
One of the biggest promises of blockchain technology is anonymity. Blockchain-based systems are designed to tie asset ownership and transaction creation to an address rather than a real-world identity. Since account addresses are based on public/private keys that are randomly generated, which in theory should provide a level of anonymity.
In reality, though, blockchain technology provides pseudonymity, not anonymity. By collecting publicly available information from the blockchain's distributed ledger, it may be possible to infer information about an account owner, breaking anonymity.
Decentralization
One of the primary objectives of blockchain technology is to create a distributed, decentralized digital ledger system. In the past, maintaining a single, official ledger required a centralized authority or group. Blockchain technology uses consensus algorithms, cryptographic primitives, and other tools to replace this central authority.
Most blockchain systems are not as decentralized as intended. Blockchain consensus algorithms tend to encourage centralization. For example, Proof of Work miners tend to form pools to guarantee more consistent rewards, and with the Proof of Stake consensus algorithm, the rich get richer and more able to control the blockchain over time.
Fault Tolerance
Resiliency and fault tolerance are vital features for an IT system. On multiple occasions, the failure of a single critical component has knocked a company or a significant portion of the Internet offline.
Blockchain systems are inherently fault tolerant because of their decentralization. Theoretically, no node in the blockchain network is essential to its operation, and the network can continue to operate—with greatly reduced performance and security—if only a single node remains online. However, as blockchains become more centralized, disruptions are easier to accomplish and with higher impact.
Immutability
Blockchains are designed to create an immutable, decentralized distributed ledger. Each node in the blockchain network is responsible for maintaining its own copy of the distributed ledger.
If each node maintains its own copy of the ledger, some mechanism needs to exist to prevent them from making changes to their copies of the ledger. The blockchain uses hash functions, digital signatures, and other algorithms to make it infeasible to forge blocks and make changes to the ledger that would be accepted by the rest of the network.
Transparency
Centralized systems for maintaining ledgers are generally not very transparent. For example, the internal processes of a bank are very opaque, making it difficult to determine how fairly it maintains its internal ledger. As a result, customers need to trust the bank to behave fairly and in their best interest in order to give banks their business.
In contrast, the blockchain implements a very transparent digital ledger. All nodes in the blockchain network are responsible for maintaining a copy of the ledger and validating all blocks before including them in the ledger. This transparency allows anyone to verify the validity of any transaction on the blockchain ledger.
Trustless
As mentioned, traditional systems for maintaining a ledger required trust in a centralized authority. Blockchain is designed to eliminate this need for trust while still maintaining a trusted ledger.
Blockchain systems accomplish this to some degree by using Byzantine Fault Tolerant consensus algorithms to maintain a decentralized digital ledger. Byzantine Fault Tolerant algorithms are resistant against a certain number of traitors, eliminating the need for blockchain nodes to trust in one another. This resistance is augmented by algorithms that reward users for acting honestly and in the best interests of the blockchain.
Structure of the Blockchain
The blockchain is a complex, multilayered environment. Figure 1.1 shows a drill-down from the blockchain network to the contents of a single transaction.
Figure 1.1: Structure of the blockchain ecosystem
The complexity of the blockchain network can make this figure difficult to read and understand. In the following sections, I'll break it down into its component parts.
The Blockchain Network
The blockchain is designed to create a distributed, decentralized digital ledger. This ledger is maintained by a network of blockchain nodes as shown in Figure 1.2.
Figure 1.2: Structure of the blockchain network
The blockchain network uses a peer-to-peer network to communicate. Each node in the network is connected to only a few neighbors that they directly communicate with.
Transactions and blocks sent out over the network propagate across via multiple hops. Each node in the network can then store and process the transactions for inclusion in a new block and blocks it receives for inclusion in its copy of the distributed ledger.
The Blockchain Node
Blockchain's decentralization means that each blockchain node is responsible for performing all of the operations that make the blockchain work. Figure 1.3 illustrates some of the key components.
Figure 1.3: Structure of a blockchain block
Each node in the blockchain network is responsible for maintaining and updating a complete copy of the digital ledger, which consists of a chain of blocks. The node must store the full blockchain and may also maintain a more accessible version. For example, Ethereum maintains a database of the current state that is derived from and updated by the blockchain and reflects the current state of the blockchain.
Additionally, a node may be involved in the process of creating new blocks. This requires knowledge of transactions that have not yet been included in blocks and the outputs of previous transactions that could be used in new transactions. For example, these unused outputs may describe the current allocation of a blockchain's cryptocurrency.
A blockchain node may also have other responsibilities beyond maintaining the basic blockchain. For example, smart contract platforms are designed to create a decentralized computer. For this to work, each node will also host a virtual machine (VM) in which instructions (contained in transactions) will be executed as each new block is added to the blockchain.
A Blockchain Block
Blocks are the fundamental components of the blockchain. As shown in Figure 1.4, a blockchain block is composed of two main parts.
The block header, shown on the left in Figure 1.4, is the portion of the block that actually is part of the blockchain. Each block header contains metadata about a block, including the root hash of the block's Merkle tree.
Block headers are chained together using hash functions, with each block header containing the hash of the previous block. Hash functions are collision- resistant, meaning that it is infeasible to find two inputs that produce the same hash output. By including the previous block hash in each block header, the blockchain makes it infeasible to change one block without also changing every block following it. This makes it much more difficult to forge blocks and attempt to rewrite the history of the distributed ledger. The body of a block contains a list of the transactions within that block. While these transactions may be communicated as a list, they are designed to be organized into a Merkle tree as shown on the right in Figure 1.4.
Figure 1.4: Structure of a blockchain block
In a Merkle tree, the leaf nodes contain the hashes of transactions, and all internal nodes contain the hash of their two children. Due to the properties of hash functions, this structure makes it infeasible to find two versions of a Merkle tree (of a particular size) that have the same root hash value. As a result, the single root hash contained within the block header securely summarizes the list of transactions and grants them the protection of blockchain immutability.
A Blockchain Transaction
The original blockchain, Bitcoin, was designed to be a cryptocurrency. The blockchain's distributed ledger was intended to record the transfers of Bitcoin between various accounts.
For this reason, the data stored on the blockchain's digital ledger are called transactions. Figure 1.5 shows an example of a blockchain transaction.
The name transaction is a bit misleading because a blockchain transaction can include multiple transfers of value between different accounts. Figure 1.5 shows transfers of the same cryptocurrency, where all inputs are pooled before being allocated to outputs; however, a transaction can also include multiple transfers of distinct tokens or independent actions.
Figure 1.5: Structure of a blockchain transaction
At a minimum, an input to a blockchain transaction must contain a source address, amount, and digital signature. These fields describe the purpose of the transaction and demonstrate that it was authorized by someone with access to the private key associated with the account (ideally the account owner). Additionally, a transaction input must be valid, which often means that it is an unused output of another transaction.
Most blockchains do not require transactions to be authorized by the recipient, so they must include only an address and an amount. If a transaction is valid, its outputs can be used by their recipients as inputs to new transactions.
Inside the Blockchain Ecosystem
As mentioned earlier, blockchain environments are complex and multilayered. Cyberattacks and security vulnerabilities can exist at multiple layers of the blockchain ecosystem, and attackers can achieve the same goals in multiple different ways.
When discussing blockchain security, it can be helpful to break the blockchain ecosystem into a few different layers. This book will explore four different layers of the blockchain with two sublayers within each layer.
Fundamentals
The goal of the blockchain is to maintain a distributed digital ledger while eliminating the need for a trusted, centralized authority. Instead, each node in the network maintains a copy of the ledger that it updates in sync with the rest of the network. To accomplish this goal, the blockchain relies heavily on cryptographic primitives and defines certain data structures for storing and communicating the information stored on the distributed ledger.
Primitives
Distributed ledger technology is built on cryptography. One of the major goals of blockchain is to transfer the requirement for trust from a centralized authority to cryptographic and other algorithms.
Cryptographic primitives, such as hash functions and public key cryptography, provide vital security guarantees for the blockchain. Between them, hash functions and public key cryptography can ensure confidentiality, integrity, and authentication for data.
These primitives are used throughout the blockchain for a variety of different purposes, which makes their security vital for blockchain security. If the security of hash functions or public key cryptography is broken due to compromised keys, algorithmic vulnerabilities, and so on, the blockchain falls apart.
Data Structures
The purpose of the blockchain is to create a distributed, immutable digital ledger. A core part of this role is data storage.
Information is stored in the ledger in a specific format, which may vary from implementation to implementation. If the way that data is stored opens the system to attack, it can affect the security of the data stored in the ledger.
Protocols
Distributed ledger systems are defined as set protocols rather than specific implementations. Like the web protocol, HTTP, client software designed by different vendors can interact as long as they follow the set rules of the protocol. While blockchains can have implementation errors that create security issues, a blockchain protocol may also be vulnerable to theoretical attacks.
A 51% attack on a Proof of Work blockchain is an example of such a protocol-level attack. This type of attack is an acknowledged risk in the design of a Proof of Work blockchain and takes advantage of how security and decentralization are enforced within the system.
Consensus
Blockchains are designed to create a shared, distributed digital ledger. Each node in the blockchain network independently maintains and updates its own copy of the ledger. For this to work, these nodes require the ability to synchronize their updates and reach consensus on the current state of the digital ledger.
Blockchain consensus algorithms make it possible for blockchain nodes to agree on the ledger's contents in a trustless environment, assuming that a certain percentage of the blockchain's nodes are honest. Exploiting consensus is necessary for attacks designed to modify the contents of the blockchain's distributed ledger, which is why the 51% attack is the most well-known blockchain attack. This attack takes advantage of the fact that Proof of Work implements a majority vote, and if the attacker controls the majority, they can force the network to accept any valid version of the blockchain that they want.
Block Creation
The blockchain has a defined process for adding new information to the distributed ledger. After creation, transactions are distributed to all blockchain nodes via the peer-to-peer network. Block creators periodically collect transactions into blocks containing these transactions and distribute these blocks to the rest of the network. Nodes then validate these blocks and add them to their copies of the distributed ledger.
This process leaves multiple opportunities for disruption or for an attacker to take advantage. For example, an attacker who identifies the selected creator of the next block could perform a distributed denial-of-service (DDoS) attack against that node to delay or prevent the creation of a block.
Infrastructure
The concept of the blockchain was initially defined theoretically in the Bitcoin white paper. However, to be useful, the blockchain needs to be implemented using modern technology.
A few months after the release of the Bitcoin white paper, Satoshi Nakamoto released the first implementation of the Bitcoin software. This and other blockchain software run on nodes and communicate over the network.
Nodes
Distributed ledger systems are implemented as software that runs on a user's computer. This software interacts with the user, other software on the computer, and the computer's operating system and core functionality (memory management, network stack, etc.).
An attacker can use malware and other techniques to attack the security of the blockchain at this level. For example, malware may be used to steal the private key associated with a blockchain account or to perform a denial-of-service attack to prevent a node from building a block or updating its copy of the ledger.
Network
Blockchain nodes communicate using a peer-to-peer network to send transactions and blocks to one another. These peer-to-peer communications occur over traditional network infrastructure such as the public Internet or an internal enterprise network.
These communications are vital to ensuring that the blockchain achieves consensus and that nodes have access to the latest transactions and blocks. An attacker who can disrupt these communications can perform a DoS attack on the network or facilitate other attacks. For example, an attack that breaks the blockchain network into isolated fragments can make a 51% easier and less expensive to perform.
Advanced
The original Bitcoin blockchain was designed to implement a decentralized financial system that tracked ownership and transfers of the Bitcoin cryptocurrency. Over time, the purpose and functions of blockchain have expanded. Today, many blockchains support execution of smart contracts on top of the blockchain or enable integration of blockchain software with external applications.
Smart Contracts
Smart contract platforms are blockchains designed to allow programs to run on top of the distributed ledger. Blockchain nodes host a virtual machine and execute instructions contained within blockchain transactions.
Smart contracts introduce new security risks and means by which a blockchain can be attacked. Vulnerable smart contracts can cause harm to themselves, their users, or the blockchain network as a whole.
Extensions
Distributed ledger systems are often not designed to be self-contained. External applications can connect to the system via the built-in API or through smart contracts running on the platform.
These extensions are part of the system's threat surface and potentially allow an attacker to compromise the security of the blockchain and vice versa. For example, exploitation of a vulnerable system that holds blockchain private keys could allow an attacker to perform transactions on the user's behalf.
Threat Modeling for the Blockchain
Threat modeling is an exercise designed to help with identifying potential security threats to a system. By using a defined threat modeling framework, security researchers can better target their investigations and decrease the probability of potential oversights.
In this book, I'll use the STRIDE threat model to explore blockchain security threats. This model, combined with the various blockchain layers discussed previously, helps to clarify the discussion of various blockchain security threats.
Threat Modeling with STRIDE
STRIDE is a mnemonic created by Microsoft employees to help with identification and classification of potential threats to a system. The letters in STRIDE stand for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
While STRIDE was designed for traditional IT environments, it can also be mapped to the blockchain. Each of the six threat classes applies to the blockchain as well.
Spoofing
Spoofing refers to attacks that threaten the authenticity of data within the system. If an attacker can masquerade as a legitimate user within the system, the security of the system could be damaged.
In a blockchain system, the primary way in which a user interacts with the blockchain is by creating transactions. A spoofing attack in a blockchain environment would involve generating fake transactions that pass validation and digital signature checks.
Tampering
Tampering attacks involve modifying stored data. This could include deleting or changing stored data.
Distributed ledger technology uses hash functions and digital signatures to help maintain the integrity of the ledger at different levels. An attack on the security of the digital signature or hash function is an example of tampering within a blockchain environment.
Repudiation
Repudiation, or more accurately non-repudiation, addresses a user's ability to deny taking an action. Protection against repudiation requires strong authentication and the ability to accurately attribute actions to a particular user.
On the blockchain, repudiation deals with the ability of a user of the distributed ledger to deny that they took certain actions, such as generating and signing a transaction. With asymmetric cryptography, only someone with knowledge of a private key can generate a valid digital signature, making it difficult to deny actions (assuming that the key is properly protected).
Information Disclosure
Information disclosure addresses unauthorized access to sensitive information. In traditional IT environments, this threat is prevented through the use of access controls and data encryption.
While most data is publicly visible on the ledger, some level of privacy can be achieved using a private ledger or encryption of data in the ledger. If an attacker can gain access to a private ledger or steal a private key to decrypt data, sensitive information may be leaked.
Denial of Service
Denial-of-service attacks are designed to degrade or destroy a system's ability to perform its function and respond to legitimate requests. In traditional IT environments, a DDoS attack is the most famous form of this threat and attempts to overwhelm a system with fake, spam requests.
Blockchain systems are designed to be distributed and decentralized, which should provide strong protection against DoS attacks. However, DoS attacks can occur at every level of the distributed ledger implementation. Any attack that makes the system unusable or decreases its efficiency or effectiveness is a DoS attack.
Elevation of Privilege
Privilege escalation refers to an attacker gaining access to protected functionality without the appropriate authorization. With distributed ledger technology, there are several different levels of unauthorized access that an attacker can gain, including at the account, blockchain, and smart contract level.
An attacker should not have access to a legitimate user's account on the distributed ledger system. If an unauthorized user is able to access an account, this is an example of an account-level escalation of privilege.
Most attacks on distributed ledger systems are designed to gain an elevated level of control over the distributed ledger. For example, a 51% attack allows an attacker to rewrite the history of the ledger to meet their needs.
Smart contracts are programs that run on the distributed ledger and are often designed to have protected functionality not accessible to the general public. Vulnerabilities in the smart contract code or a failure to take the system environment into account when designing the smart contract can allow an attacker to gain access to this protected functionality.
Applying STRIDE to Blockchain
The various threats described by the STRIDE threat model can occur at different levels of the blockchain ecosystem. For example, privilege escalation can be accomplished by stealing a user's private key, performing a 51% attack against consensus, or gaining unauthorized access to a smart contract. These are three very different threats that all fall under the same STRIDE category.
In this book, I'll discuss threats and attacks as a combination of the level of the blockchain ecosystem and the associated STRIDE threat. This clarifies the potential threats and impacts of an attack. For example, a 51% attack is an attack against consensus algorithms that could lead to modification of the distributed ledger, which not only breaks the integrity of the ledger but allows an attacker to delete past transactions from the record (repudiation).
Conclusion
Blockchain technology is complex and multilayered, which makes blockchain security a complicated topic as well. Blockchain systems face a variety of different threats at various levels of the blockchain ecosystem.
This chapter broke the blockchain into four layers and eight sublayers and discussed how the STRIDE threat model can be mapped to the blockchain. The next four chapters of this book will explore each of these layers individually and discuss the potential security threats to each level of the blockchain ecosystem.
CHAPTER 2Fundamentals
The goal of blockchain technology is to create a shared, decentralized digital ledger. In this system, no centralized authority exists to dictate what the official version of the digital ledger is.
Blockchain technology transfers trust in the digital ledger away from a centralized authority to a set of protocols designed to provide the same guarantees as a centralized ledger. These protocols are created using smaller building blocks with certain properties that can provide these desired guarantees.
This chapter explores the fundamentals of blockchain security. This includes the cryptographic primitives and the data structures that are used to build blockchain protocols and make the decentralized digital ledger possible.
Cryptographic Primitives
Financial institutions maintain an internal accounts ledger, enabling value to be transferred from one party to another by simply updating the relevant values in this ledger. Each financial institution is responsible for maintaining the accuracy of its ledger, and customers must trust the financial institution to properly track their financial transactions.
Blockchain is designed to transfer this trust from these centralized authorities to cryptographic algorithms and protocols. The cryptographic algorithms are relied upon to ensure the authenticity and integrity of the transactions recorded on the blockchain's ledger.
Blockchain technology began with Bitcoin, and since then, many different blockchains have emerged, each with its own tweaks on the underlying protocols and methods of implementing them. However, all of these protocols are reliant on the same set of cryptographic building blocks.
The design of the blockchain makes data integrity and authenticity protections vital for the system to work. To provide these protections, blockchain technology uses public key cryptography and hash functions.
Public Key Cryptography
Cryptographic algorithms are divided into two main categories based on how they use encryption keys. Symmetric algorithms use a single key for both encryption and decryption. This symmetry means that the algorithms are generally more efficient, making them better suited for bulk data transfer. However, they require the shared secret key to be distributed to all participants via a secure channel.
Asymmetric, or public key, cryptography uses a public key for encryption and a private key for decryption. This makes it possible to send a secret message to anyone without setting up a shared secret key. However, these algorithms are generally less efficient than their symmetric counterparts.
Blockchain technology is heavily dependent on public key cryptography. Its use of two related keys and the ability to create and validate digital signatures using them provides the invaluable ability to authenticate the sender of a message.
Introducing “Hard” Mathematical Problems
Public key cryptography is built using “hard” mathematical problems. These mathematical functions are defined by an asymmetric relationship between how hard they are to perform versus how hard they are to reverse. For these problems, F(x) has polynomial complexity, while F−1(x) has exponential complexity.
This relationship makes it possible to develop cryptographic algorithms that are both usable and secure. The algorithms are designed so that a legitimate user only has to perform the easy operation, F(x), while any attacker must solve the harder problem, F−1(x).
Several of these mathematically “hard” problems exist. The two most commonly used in “classical” (i.e., not post-quantum) cryptography are the factoring problem, which is the basis for RSA, and the discrete logarithm problem, which is the basis for the Digital Signature Algorithm (DSA). Algorithms based on these problems can also be implemented more efficiently using elliptic curve cryptography (ECC).
