Blockchain’s Threats and Vulnerabilities
Of course, the blockchain technology itself and the distributed applications using it are also information assets associated with certain threats and vulnerabilities. To decide on the use of blockchain technology in solving a specific problem or by preferring or leaving a traditional solution, it is necessary to include the results of the analysis of the information risks associated with the use of both types.
Note: We will continue to use the term risk, as defined above, as the resulting combination concepts of threat, vulnerability and impact on an information asset.
In the previous sections, various risks of blockchain solutions have already been mentioned, such as:
• Risks associated with the management of asymmetric encryption keys, in particular with secure storage of a private key (which, however, is an important issue outside the blockchain discussion).
• Risks and many practical complications associated with life cycle management of the blockchain technology itself and applications using blockchain and their integration into the surrounding IT environment (analysis, design, development, testing, deployment, change management, operations management).
• Risks associated with relying on the proper functioning of consensus algorithms, smart management contracts and other "modern" elements of blockchain technology (which, unlike, for example, used cryptographic algorithms or network protocols have not undergone such development and have not been subjected "testing in practice" to such an extent) – Is the correctness of these algorithms and mechanisms demonstrated by mathematical evidence? Or at least are all aspects of these algorithms and mechanisms sufficiently tested?
Note: Currently, many types of problems and attacks are theoretically refined depending on
specific implementation of blockchain technology. E.g. when using PoS (proof of stake) consensus algorithm can be dealt with topics[1]: Nothing at stake problem, Initial Distribution Problem, Long Range Attack, Bribe Attack, Coin Age Accumulation Attack, Precomputing Attack and the like.
• Risk of disclosure of all data stored in the blockchain in encrypted form (in order to protect them confidentiality) in case of breaking the used cipher (typically using brute computing force using the so-called quantum computer). In this case, it will be extremely difficult (given the invariability and distribution of data in a blockchain) to "encrypt" this original and compromised data using additionally modernized encryption algorithms, or more complex keys.
Note: At the same time, we understand that this risk is mainly associated with the use of asymmetric cryptography RSA and the probability of breaking the cipher is when using cryptography based on elliptic curves (which is typically used in modern blockchain solutions instead of RSA cryptography) substantially lower, almost negligible.
• Risks associated with inserting incorrect or unauthorized data into the blockchain contained in it remain "forever" (this can be solved by a suitable communication protocol, which, for example, then will include a correction or reversal record to blockchain and logically link it to the original erroneous record). Similarly, it is necessary to manage the risks associated with the quality of data and their further processing and interpretation at their exit from the blockchain, i.e. from the moment the blockchain ceases to ensure their unchangeability.
Note: Sometimes it is incorrectly stated in connection with a blockchain that “a blockchain is a guarantee of the truth”. However, a blockchain is not even a "guarantee of correctness", but a "guarantee unchangeability” (which is a very useful feature). Whether the blockchain contains information that is "true" or "correct" is decided by the source of this data (human or integrated information system) - its semantics, validation rules and other control mechanisms.
To these risks it is necessary to add other risks discussed today, such as:
• Loss of decentralization of blockchain network nodes when gaining control over more than 50% of nodes of this network (the so - called 51% attack, e.g. from the perspective of preparation of this document recently documented incident[2]).
Note: Such an attack is in fact a permanent condition in blockchain solutions referred to as private. It seems that experimenting with such "not honest" blockchain solutions will prevail, until this innovative technology gains enough confidence and while it will not be able to answer all relevant doubts and will not be prepared to respond to relevant risks. This may also apply to some extend to the so-called consortium blockchains in the case when members of the consortium (otherwise typically legally separate entities or at first sight independent users) have a common “owner” (see e.g. the case of using a blockchain in section 5.4.2 Extending visibility in supply chains).
· Risks of gradual system degradation and loss of ability to provide distributed applications enough performance and operating parameters, e.g. in the uncontrolled addition of network nodes, or inserting smart contracts (complex, or without termination conditions, often and on many nodes launched, etc.)
· Risks related to the lack of regulations and standards for decentralized solutions (if the effort to regulate and standardize in an environment that excludes authorities is at all meaningful and possible).
· Risks associated with the unclear division of powers and responsibilities related to strategic (governance) and project management and operations management, including sufficient motivation for node operators (a key part of the blockchain infrastructure) to approach generating of new data blocks responsibly.
Note: One of the strongest features of blockchain seems to be decentralization and exclusion of central authorities can also be a significant weakness. Who is going to be sponsor and who the solver of the project and what will be their motivation for the implementation of distributed and a decentralized solution serving equally several independent entities when their roles typically end up at the time the solution is commissioned?
Given that the development and operation of blockchain and other decentralized solutions is a relatively young industry in software engineering (not to mention that the SW engineering itself is a relatively young field e.g. compared to construction), it is necessary to remember the fact that we do not even know about some relevant risks today and we only know about some, but not yet we have practically verified the course and impacts of incidents associated with them, such as how to respond to them and whether this is possible at all.
A more detailed risk analysis of blockchain technology is not the subject of this document. Considering very diverse possibilities of implementation of blockchain technology (used cryptographic algorithms, the chosen method of reaching consensus in the network, the scope and types of services provided at the application level, rules and network topology, etc.), nor is it possible to generalize such an analysis. A risk analysis is needed for a specific implementation of blockchain technology and then for a specific distributed application and its integration into the surrounding IT environment (e.g. the original enterprise system, resp. public administration information system).