In this article, we mainly introduce several aspects of public chain audit which are worthy of attention. For security auditors and public chain developers, this is a project worthy of reference and thinking.
Before introducing the construction of public chain system, let's take a look at the architecture of blockchain:
Blockchain 1.0 era：
Architecture: as shown in the figure below
Representative products: bitcoin, reborn coin, dogcoin, Leyte coin, MasterCard coin, etc
Blockchain 2.0 era：
Architecture: as shown in the figure below
Representative products: Ethereum, lisk, hyperledger, etc
Major changes:
- Application layer: added smart contract
- Excitation layer: shorten the block time to 16 seconds
- Consensus layer: add dpos, POS, pbft
- Data layer: expanded the block, support sending data and variables, using optimized encryption algorithm and Merkle tree
Blockchain 2.0 era
Architecture: as shown in the figure below
Representative products: EOS, VaR, AE, ash, ELA, dfinity
Main changes: the application scenarios of blockchain in all walks of life outside the financial industry can meet more complex business logic
Next, we will give a brief introduction to the problems worthy of consideration in the security construction of the blockchain public chain according to the architecture of the blockchain. About 75% of the problems have caused public chain security problems, which are also some points worthy of attention in the public chain security audit. Here, we give them in the form of questions to arouse our thinking, If you want to have a further discussion, you can do it directly in issue：
Data layer is the bottom layer technology, and its main functions are data storage, account and transaction implementation and security. Data storage is mainly based on Merkle tree, which is realized by block and chain structure. Most of them are persistent by kV database, such as bitcoin and leveldb adopted by Ethereum.
The data layer is worth thinking about as follows:
- Is the data structure design of public chain block reasonable?
- Does the public chain encryption algorithm meet the requirements of cryptography?
- Is the design of Merkle tree reasonable?
- Is the CRUD design of Merkle tree node reasonable?
- Is the design of public chain block timestamp verification logic reasonable?
- Public chain database data storage and data CURD security?
- Is the public key/mnemonic generation algorithm secure enough?
- Is public key/mnemonics encrypted?
- Is there any abuse/memory residue in public key/mnemonics?
The main purpose of the network layer is to realize the information interaction between the nodes of the blockchain network. The essence of the blockchain is a peer-to-peer (P2P) network. Each node can receive information and also produce information. The nodes maintain communication by maintaining a common blockchain. In the blockchain network, each node can create a new block. After the new block is created, other nodes will be notified by broadcasting. In turn, other nodes will verify the node. When more than 51% of the users in the blockchain network pass the verification, the new block will be added to the main chain.
There are several points worth thinking about the network layer
-
Is the design of public chain node discovery algorithm reasonable?
-
Is the design of public chain nodes reasonable?
-
Is the design of punishment mechanism reasonable?
-
Is the design of communication protocol reasonable?
-
Is the request processing design of public chain node reasonable?
-
Is there a limit on the size of the request processing packet?
-
Is the design of public chain transaction communication mechanism reasonable?
-
Is the block data synchronization mechanism reasonable?
-
Is the logic design of transaction processing reasonable?
The consensus layer enables highly dispersed nodes to reach a consensus on the effectiveness of block data in a decentralized system. Every running blockchain needs a consensus algorithm to ensure the effectiveness and order of block output. Common consensus algorithms include pow, POS, dpos, Poa, POC, etc.
On the consensus level, we should consider the following points：
-
Is the design of public chain consensus algorithm safe?
-
Is the design of public chain consensus verification reasonable?
-
Is the design of public chain consensus forfeiture reasonable?
-
Is the design of public chain service fee reasonable?
-
Is the design of public chain mining reasonable?
-
Is the block difficulty dynamic adjustment design reasonable?
-
Is the logic design of block difficulty check reasonable?
-
Design of chain reorganization, chain reset, chain bifurcation, etc?
The purpose of the public chain incentive layer is to provide certain incentive measures to encourage nodes to participate in the security verification of the blockchain, and to ensure the balance and healthy development of the blockchain ecology. In the decentralized common chain, it is necessary to set up the corresponding incentive mechanism to encourage the participating accounting nodes who comply with the rules, and establish the punishment mechanism to punish the participating accounting nodes who do not comply with the rules. The incentive layer of blockchain introduces economic factors into the blockchain technology system, which improves the efficiency of organizational cooperation and value exchange within the ecology. The incentive mechanism of public chain is an important mechanism to ensure the virtuous development of blockchain.
There are several points worthy of our consideration about the incentive level
-
Is the design of public chain issuing mechanism reasonable?
-
Is the design of public chain punishment mechanism reasonable?
The contract layer encapsulates all kinds of script codes and algorithms of the blockchain system, as well as the more complex smart contracts generated from them. If the three levels of data, network and consensus, as the underlying "virtual machine" of the blockchain, respectively undertake the functions of data representation, data dissemination and data verification, the contract layer is the business logic and algorithm based on the blockchain virtual machine, which is the basis for realizing the flexible programming and data operation of the blockchain system. Most digital cryptocurrencies, including bitcoin, use non Turing complete simple script code to program and control the transaction process, which is also the rudiment of smart contract. With the development of technology, there are Turing complete script languages such as Ethereum that can realize more complex and flexible smart contract, Blockchain can support many applications of macro financial and social systems.
We should consider the following points about the contract layer:
-
Contract virtual machine security design?
-
Contract deployment / execution / interface?
-
Security related to smart contract?
The application layer encapsulates various application scenarios and cases of blockchain, which is similar to various software programs in computers. It is a product that ordinary users can really use directly, and it can also be understood as the browser of B / S architecture products.
We should consider the following points about the application layer (only public chain, not wallet App/Exchange/DEFI, etc.):
-
CRUD logic design of wallet account?
-
Check the import and export permission of wallet?
-
Design of wallet password complexity?
-
Check the validity of wallet account address?
-
Does the public RPC interface need an external public network?
-
Is the public chain RPC interface authority clearly divided?
-
Does the public RPC interface have sensitive class operations?
-
Does the public RPC interface handle exceptions?
-
The maximum data processing limit of public chain RPC interface?
-
Public chain RPC interface requests data encoding and decoding?
-
Is SSL enabled for public chain RPC request processing?
-
Design of high concurrency request processing in public chain?
-
Set the maximum number of connections?
-
Does the public Chain Web UI interface allow remote access?
-
Is there a web class vulnerability in the public chain webui interface?
-
Is the public chain webui interface allowed to store password information locally?
It is true that there is no "code layer" in the public chain. Here, the author proposes it mainly to classify the problems that may need to be considered in the process of public chain development:
-
Common chain development language features, such as readall (), append features in go language data reading
-
Public chain development language version, for example, some versions of go language have remote command execution
-
Public chain development specification coding, such as null pointer, slicing, exception handling and other operations
-
Public chain encryption and decryption processing, such as high complexity encoding and decoding without length check
-
Data type conversion processing, such as hextobyte, integer. Parseint(), etc
-
Basic business logic design, for exam
In addition to the above issues worthy of consideration at the level of blockchain architecture, we also need to consider the following security issues:
-
Is the data storage encrypted?
-
Is the file permission reasonable?
-
Is the running environment safe?
-
Is the node not root started?
-
Is there a vulnerable web service on the node side?
-
Is there any unsafe configuration on the server side of the node?
-
Is there an unauthorized access vulnerability on the server side of the node?
-
Is the SSH account password leaked on the server side of the node?
-
51% attack
-
Hard bifurcation of common chain
-
Computing hijacking (worms infect mining machines)
Whether to use the third-party libraries with vulnerabilities, such as Jackson databind, fastjson, etc
Use vulnerable middleware, such as the lower version of tendermint
-
Is the cross chain mode reliable and appropriate?
-
Isomorphic cross chain & heterogeneous cross chain implementation scheme?
-
Repeat the safety issues in the above section
- Al1ex@Heptagram
Directly participate in the discussion of related issues in issue