According to some estimates, blockchain technology companies can expect business volumes of 6 billion euros by 2020. However, they must first deal with blockchain security vulnerabilities, which, despite their relevance, continue to be underestimated when It deals with the so-called “distributed accounting” technology (or DLT).
A comment here, to clarify the “distributed ledger” (DLT) widespread term that in my opinion should be renamed as “distributed accounting”, or better, “RJT Replicated Journal Technology” since it really registers entries in the log as they are produced, not reflecting the accounting itself.
Security vulnerabilities in block chains
Some aspects of security have to do with the use of cryptography, and given that cryptography is used intensively in blockchain contexts, there is a widespread belief that blockchain systems are inherently safe.
However, in complex systems, different attack vectors appear that must be identified and remedied, so that excessive confidence in the technology can be dangerous.
In fact, the technology called DLT is subject to a series of problems that centralized databases do not have.
The security risks of Blockchain exist, and must be recognized and mitigated so that Blockchain fulfills its promise to transform the way in which data is stored and how it affects the projects that use it.
As more government, industrial and commercial sectors adopt technology, the need to address these problems sooner rather than later becomes paramount.
Blockchain Vulnerabilities
Vulnerabilities of the interface system
One of the most likely vulnerabilities with DLT originates outside of the blockchain itself.
The interface system is the equipment that a user uses to access services based on blockchain.
In this system credentials are introduced, enough reason to attract attackers who exploit vulnerabilities. Other times, manipulating the “clipboard” the memory area used for copy and paste functions can allow an attacker to change the destination account of a transaction.
Malware detection is a desirable feature in tools that anticipate minimizing attacks on the interface system.
Security of public key cryptography
Those who propose transactions to form part of the chain (for example, value transfers in the case of crypto-assets and cryptocurrencies) sign them with a private key and give information about their public key. The private key is filed with the portfolio or equivalent mechanism. The protection of the equipment is again essential. But there are certain risks (for example, based on quantum computing) that in the future could allow obtaining the private key from the public one. To minimize risk, there are techniques associated with single-use portfolios that can be adopted.
Key backups should not be kept on the system that is used daily. And even less without encrypting.
Third party platforms
As cyber-currencies and applications using related technologies (such as DLT) become popular, the third-party solutions market will experience growth. Some possible services to be offered by third parties are:
- Blockchain integration platforms
- Payment processors
- Wallets
- Fintech entities
- Cryptocurrency payment platforms
- Smart contracts
These platforms use different vulnerable technologies, in addition to blockchain-specific ones. They are true Providers of Digital Trust Services and should comply with the standard EN 319 401 that the EIDAS Regulation imposes on Qualified Providers.
Control of deployment
When a project starts or evolves within it, exhaustive tests must be carried out to detect vulnerabilities in the code before it passes to the final execution environment. This is especially relevant in smartcontracts. In the smarcontracts languages such as Solidity are frequently used, with “defects” similar to those of Javascript. A case of special relevance may be to include the addresses of the portfolios in quotes. If not, the addresses are truncated and the amounts remitted can end up in an irrecoverable limbo.
Size of the block chain
Depending on the type of cryptoactive and how its transaction management system has been designed for its annotation in the block chain, it may be necessary to preserve the entire chain of blocks from its origins. Some variants allow converting the transaction history into a “status photo” from which the previous history can be discarded. Be that as it may, the more transactions are made, the more the chain grows, which can create sizing problems in the equipment in which they are managed.
51% attacks
Some cryptoactive systems with different block confirmation philosophies (PoW, Proof of Work, PoS, Proof of Stake, …) could be attacked by groups that exceed the 51% participation in the consensus mechanism. Therefore, it would be advisable to anticipate the need for reversion mechanisms and the responsibility for the execution of such mechanisms.
There have been real cases of this type of attack on Pow mechanism (theoretical until recently) that is understood knowing that a large number of mining equipment accumulation centers are built in countries where electricity is cheap and supervision is scarce
Lack of maturity of blockchain technology
In all technologies, essential lessons are learned as they are adopted and generalized. Problems are discovered and reselled. Blockchain technology is still in the early stages of development and all risks and their effects are not understood.
Risks due to insufficient standardization
Many of the blockchain systems are deployed with a “Whitepaper” and source code of the project available on Github. Although it is an exercise in transparency, it is often revealed that the promoters of such projects have little interest in knowing the standards or adopting them.
It is particularly striking in the field of electronic signature, whose main market has matured over the years giving rise to various laws and technical standards that create legal presumptions for those who adopt technology and that define the standards that facilitate their interoperability.
In contrast, the use of electronic signature technology in blockchain projects seems to come from undergraduate students who have read the basics of electronic signature theory and who ignore the advance of the standards. They look like academic exercises, instead of responding to market demands that require systems to interoperate and that their developers know the laws and standards.
Fortunately UNE and ISO (among other standardization bodies) are beginning to propose standards for the blockchain world, which should not ignore the advances made in common technologies with a certain level of maturity.
It should be remembered that standardization, against what its critics affirm, does not limit innovation but opens up new possibilities for it. And leaves solved problems that were undertaken in the past minimizing the risk of reinventing the wheel each time.
Subtle vulnerabilities
There are vulnerabilities difficult to detect that are visible after incidents of a certain magnitude. It is advisable to provide for reversion mechanisms before deployment in order to manage problems that have not been previously identified.
An example is shown by the case of “The DAO”
A “DAO” (Distributed Autonomous Organization) is a Decentralized Autonomous Organization built on some types of blockchain, with code execution functionality for intelligent contracts associated with investments in the capital of markedly digital companies. You could say that a DAO is a crowdsourcing venture capital fund that is managed on the basis of embedded smartcontracts in a chain of blocks. There are many DAOs, each created to host and execute smart contracts for specific organizations.
One of those DAO, known as “The DAO”, was founded in 2016 by members of the Ethereum team. During its creation period, The DAO made history in the field of crowdfunding by raising 150 million dollars. Shortly after, The DAO made history, once again, by being the first DAO to be pirated.
During the crowdsale, many members of the Ethereum community expressed concern that the DAO code could be attacked. Subsequently, a member of the DAO team found a “recursive error” but erroneously believed that there were no DAO funds at risk. A hacker proved he was wrong.
The attack occurred when the attacker exploited two vulnerabilities in the DAO code. The hacker knew that the code was designed to allow both a split and a transfer of tokens between accounts. The hacker also realized that the code would not update account balances fast enough to prevent the transfer of the same tokens more than once.
The hacker executed a spinoff function, creating a “child DAO” account and made repeated transfer requests from his first account in quick succession. Since the code did not decrease the original account balances after each transfer, there was nothing to prevent the same tokens being repeated about 40 times each, without destroying the original tokens.
After transferring $ 55 million in Ether, the hacker terminated the attack and some additional events happened, so I invite you to investigate this issue from which great lessons are drawn.
Call us if you need us
When serious blockchain projects are proposed, their promoters invest in technology developments that help define transaction types, identity management models, block confirmation mechanisms, block production rates and transaction limits. per block. There are many aspects that make each project different.
One that should begin to be taken into account is that of the project audit. Maybe he does not detect all the problems, but he will discover the main ones. We must begin to value what is already known and avoid making mistakes that have already been committed.
Contact the Trust Conformity Assessment Body (TCAB) if you need to audit a blockchain project.
Español