Cybersecurity solution for applications based on blockchain infrastructure: general problems and specific solutions point by point
My name is Maxim Zavgorodny, I have been working at DataArt for seven years. For the last three, as a solutions architect. My professional interests are ML/AI. Prior to that, I was involved in the design and development of blockchain-based decentralized systems, where I was closely involved in security issues.
In this article, I will try to explain the basic principles that should be followed when designing a blockchain solution, and draw the attention of readers to certain points, such as creating wallets, as well as generating, storing, and using keys. The text will not analyze the technical nuances for each of them. Rather, the highlighted points can be used as a checklist to check your project plan for compliance with safety standards.
Blockchain-based solutions are actively used in financial projects e.g. in the design of payment systems, exchanges, and cryptocurrency trading platforms. But blockchain can just as well be used in insurance, healthcare, and other areas of business. At the same time, the clients interested in using a relatively new and popular technology are often not sufficiently aware of the security issues that arise in blockchain projects. This is why their applications are so often hacked. For example, more than 30 major trading platforms were hacked in 2019 alone.
Let’s start with the fact that the importance of cybersecurity in cryptocurrency projects is obvious. But what about other areas? Let’s look at the main aspects of blockchain technology that require implementation in accordance with high security standards, regardless of the nature of the client’s business. Transactions, certificates, creation, and storage of private keys — every aspect or process of implementation can equally be insufficiently secure. These aspects themselves remain exactly the same in any blockchain infrastructure. The good news is that financial best practices can be safely followed in medical projects, for example.
The easiest and fastest way to secure a blockchain project is to use existing open source libraries (such as bitcoinJ) or RPC integration with products such as Electrum or Geth. This will allow us to manipulate keys, transactions, seeds, etc. through the existing RPC. This approach can indeed be justified at the proof of concept stage, when timelines and budget are usually limited. But this option should not be considered for production mode.
Libraries and any software for generating confidential cryptographic information should be free of any additional features. All programs used for this must successfully pass legal and security audits, and any transfer of generated keys and seeds within the system must be prohibited. Moreover, it is worth prohibiting trust in any open libraries and third-party services.
Here is a list of security sensitive issues that should be covered when designing a system:
● Key/seed generation
● Wallet creation
● Key storage
● Key usage
Let’s take a rough look at exactly what high safety standards require for each of these points.
1. Generation of a key and/or seed
All cryptographic seeds and transaction keys must be generated internally. Such information is absolutely confidential and must not be passed on to third parties. Algorithms for generating keys and seeds must follow confidential and unpredictable rules.
1.1 Operator-generated key/seed
Sensitive cryptographic information such as keys or seeds must be generated by the operator who is responsible for the signature that confirms the transaction. If we are talking about a decentralized application such as a crypto wallet, the key and seed must be generated by the application’s user without transferring this sensitive data to anyone else.
In the case of a centralized application (online wallets or classic cryptocurrency exchanges), the creation process will be performed on these centralized platforms.
Generation methodologies should be verified to rule out determinism. The security of algorithms for generating confidential cryptographic information must be confirmed by independent auditors.
Key seed generation must be performed in the appropriate demilitarized zone (DMZ) or autonomous system. Backups of cryptographic secrets must be encrypted and transferred to a secret storage to a trusted person for backups and restores.
1.2 Random Bit Generators (DRBG)
We are looking at generating keys that should be used with approved cryptographic algorithms.
For example, true random number generation (TRNG), like deterministic random bit generators (DRBG), is considered an accepted standard in the industry. Keys are generated using mathematical output processing using random bit generators and additional parameters. For more information, see the Guidelines for Generating Cryptographic Keys (NIST Special Publication 800–133).
2. Creating a wallet
The logic of implementing a wallet or private key storage for working with blockchain transactions should cover a set of issues: address management, using private keys to confirm an operation, and implementing multisignature.
Also, the wallet can be implemented for each individual account. The deterministic method allows you to create a set of addresses/key pairs in the form of a common pool of addresses from one master seed. Also, when implementing a wallet, you need to pay attention to various risks, such as loss, theft, and compromise of keys. Combining a wallet with a specific user’s account must be accompanied by the introduction of additional levels of identification.
2.1 Implementing a hierarchical deterministic (HD) Wallet
The value of the master seed can be used to create a sufficient number of unique addresses linked only using the generation algorithm, that is, independent from each other for an outside observer. Each subsidiary address gets a place in the forked structure and is associated with a specific path through the HD tree. It is important that the implementation of the HD wallet complies with the standard, i.e. BIP44.
2.2 Unique address for each transaction
A unique address must be generated for every anonymous transaction.
2.3 Multisignature. Multiple keys for signing
Any address that generates an HD wallet requires at least two signatures to use as the input for a transaction. Moreover, in order to protect the user’s funds from theft, it is necessary to place the keys in DMZs isolated from each other.
2.4 Backup recovery key
A common method is to create 2 of 3 possible signatures to use as the input of a transaction.
2.5 Use of hierarchically deterministic (HD) wallets
All addresses are assigned deterministically based on seeds, which must be private.
2.6 Wallet backup
It is imperative to regularly create backups for each new generation of keys and master seed.
2.7 Wallet encryption
All wallet data must be encrypted using secure algorithms. Decryption data should be located on separate nodes with strong security policies, e.g. Identity service, Vault HashiCorp, etc.
3. Storing keys
When keys are not in use, they must be stored securely encrypted. In addition to encryption itself, it is necessary to pay attention to the separate storage of keys (they should be placed in a completely independent infrastructure) and the physical security of information carriers where possible.
3.1 Primary keys are stored encrypted
A strong encryption level must be used to store keys and/or seeds. For example, AES-256-CBC.
3.2 Key storage location
Encrypted keys and/or seeds and encrypted passwords must be stored across platforms. Moreover, this information must be physically spaced between different locations and providers.
3.3 Backup key
Keys/seeds must be backed up (digital, hardware, paper, etc.).
3.4 Key backup policy
Keys must be protected from the risk of physical destruction, including natural and man-made disasters, such as floods, fires, etc. Store backups in locations geographically remote from the place of use. All backups must be protected by access controls.
4. Using keys
All operations to interact with seeds must be carried out safely. It is necessary to exclude the possibility of copying or changing the keys by malicious programs.
Keys must be protected from unscrupulous users who use authorized access for unauthorized transactions. The implementation of the decryption and signature mechanism must be multi-layered and reliable.
4.1 To generate keys, it is recommended to use the path “user/pass/nth factor”
Key usage access must be protected using a multi-factor authentication model. For example, an identifier (it can be a username, email, etc.), Google Authenticator tokens, digital signatures from a private key, and personal ID verification might be required.
4.2 Keys must only be used in a trusted environment
Using keys exclusively in a trusted DMZ environment reduces the risk of unauthorized malware copying, pasting copies, and storing keys. This approach will also protect against malicious key recovery attempts and confidential data theft.
4.3 Operator reference and operation log checks
It is necessary to do background checks on all employees who access the system. All operator actions must be registered and saved in logs.
4.4 One device — one key
Two keys from a wallet cannot be stored on the same device, access to which requires multiple signatures.
4.5 Multi-factor authentication
Signing transactions must be protected by multi-factor authentication.
4.6 Operations auditor
For important transactions, you need to add an additional layer of authentication with mandatory manager approval.
We have reviewed the basic layers required to securely secure a system based on a blockchain solution. However, technical implementation is not enough to ensure safety.
In addition, you should:
● Capture and document all log operations, system audits, security audits, procedures and policies for key users. All operations and changes in the system must be recorded in the logs.
● Provide transaction logging tracing and log backup.
Sources for the article:
●Withdrawn NIST Technical Series Publication
●Most Significant Hacks of 2019 — New Record of Twelve in One Year
●CryptoCurrency Security Standard