Cybersecurity Consulting for Blockchain
The security of blockchain systems must be distinguished from the security of blockchain applications. For example, if a particular wallet software has serious security vulnerabilities, this does not imply anything about the security properties or the quality of the implementation of the underlying blockchain system.
Security of Blockchain Systems
The following is a selection of security issues related to blockchain systems.
Consensus Algorithms
Under certain conditions, multiple, equal parties (so-called peers) in a communication network can reach a mutual consensus. Consensus is reached in a decentralized manner, which enables a higher fault tolerance and a stronger trust model for many critical applications than centralized approaches. In a centralized approach, e.g., with only one central authority, this authority typically represents the bottleneck in terms of trust and availability. In the decentralized case, consensus can be reached even if some of the parties do not communicate (e.g., because they are offline) or otherwise do not contribute toward consensus, e.g., because they are faulty or corrupt. “Corrupt” here means that these parties attempt to maliciously thwart or manipulate the consensus—typically for unfair self-interest.
The Bitcoin blockchain is permissionless and public; any actor worldwide can join it. The Bitcoin blockchain employs a proof-of-work mechanism that ensures fair agreements are reached even when it is currently unknown which actors are uncooperative and in what ways. However, certain conditions must be met during operation for this to work, such as ensuring that a certain ratio of computing power held by uncooperative parties relative to cooperative parties is not exceeded (see also the >50% attack). Incentivizing miners in the Proof-of-Work scheme is also intended to ensure that a network-based attack and selfish mining become more expensive than compliant mining. However, there is a trade-off here between efficiency and security: the higher the value of a transaction, the longer one must wait before the transaction can be considered reliably recorded.
For distributed consensus, a whole range of algorithms are available, such as Byzantine algorithms, Proof-of-X methods (Proof-of-Work is just one of these), and combination algorithms. These are designed for different requirements such as functionality (e.g., current altitude in the event of conflicting data from independent altimeters in an aircraft), efficiency (e.g., real-time requirements), compliance (e.g., audit requirements for banks), privacy protection (e.g., for data that can be traced back to individuals), and security (e.g., assumed attack model). For example, the security requirements of permissioned blockchains differ significantly from those of permissionless blockchains.
A security analysis by Fraunhofer SIT supports the decision regarding which consensus algorithm to select for blockchains.
Transparency of all transactions
When it comes to the disclosure of information, security and privacy considerations must also be weighed. Even in a private blockchain, all authorized parties gain access to the blockchain’s entire ledger; in a public blockchain, potentially the whole world does. This transparency can mean both a gain and a loss in security and/or privacy—depending on the protection objective and purpose of the blockchain (especially regarding the range of applications it is intended to support).
Code = Code?
The dogma that (program) code = (legal) code—i.e., that the programming code irrefutably establishes the rules for a blockchain or smart contracts, even in cases of conflict, and cannot be corrected—must be viewed critically. Simply because it is unlikely that programs will be free of errors once they exceed a certain number of lines. Therefore, it is highly recommended to coordinate and announce sets of rules (especially regarding the potential “failure” of program code, both in terms of functionality and IT security) as early as the introduction of blockchains and smart contracts, and to design them and their interconnection with the program code in a way that allows for agile changes throughout the entire lifecycle. The question of what it means when a minority does not wish to abide by the decisions of the majority is highly relevant in this context (see, for example, previous hard forks).
Cryptography
The cryptographic methods used in a blockchain system must be evaluated in terms of their current security level (including potential implementation weaknesses), their adaptability to changes, and their anticipated future-proofing.
“Classic” attack vectors
The implementation of a blockchain must, of course, be protected against attacks that are not specific to blockchains, in accordance with its underlying attack model.
Attack vectors on blockchain applications
In addition to the security of blockchain as a technology, the security of the applications it enables must also be considered. Prominent examples from the cryptocurrency sector include hacking attacks on wallets (where are private keys stored: “hot storage” vs. “cold storage”?) and attacks on exchanges (e.g., Mt. Gox, Cryptsy, Bitfinex hack).
