Harmony is a sharded Proof-of-Stake (PoS) blockchain [1,2,3,4] with Fast Byzantine Fault Tolerance (FBFT) consensus protocol . The FBFT protocol has Blockwise-Byzantine Agreement (Blockwise-BA) that achieve the immutability of every single block via a full execution of a Byzantine Agreement (BA). Harmony’s FBFT requires at least 66% (two-thirds) of the nodes be honest for progress and liveness.
Given the consensus model described above, we reviewed a list of vulnerabilities and attack vectors [8,9,10] to analyze and report the applicability and our mitigation measures to ensure highest level of security of our blockchain. Our external security audit report from PeckShield is available here.
Figure 1: A list of vulnerabilities and security attacks
Data Layer Attacks
The data layer contains the blockchain datastructures such as accounts, transactions, blocks, and events.
This vulnerability happens when the transactions published on a blockchain does not account for the chain id. Such transactions created on one chain can be reused on other chains. Harmony blockchain requires that every transaction is signed and published using a chain id to prevent this vulnerability.
Empty account in the state trie
Empty accounts have zero nonce, zero balance, and no code is associated with them. If empty accounts are allowed, an attacker can create a large number of such accounts to increase the node synchronization and state processing time. Harmony does not allow empty account creation.
Consensus Layer Attacks
The consensus layer ensures a consistent state of the blockchain. Different components of the consensus layer includes: validators, leader selection, block production/verification, and stake/reward mechanism.
Outsourceable puzzle, 51% hashrate, 67% voting power (double spend)
These vulnerabilities are only applicable to Proof-of-Work blockchains. Harmony is a Proof-of-Stake blockchain, hence they are not directly application. However, by controlling the majority, an attacker or a group of attackers can perform Denial of Service (DoS), double spending, and many such attacks. In Harmony chain, we assume 66% honest nodes which makes these attacks infeasible. Our future implementation on resharding will eliminate the assumption.
Fixed consensus termination
This vulnerability is mainly applicable to blockchains that have probabilistic consensus mechanism in which consensus for block 𝑖 will terminate when the chain depth reaches 𝑖+𝑚 and all of the transactions contained in block 𝑖 are committed. Our model is blockwise byzantine agreement, where every block has instant finality.
DoS with block stuffing
In this vulnerability, attackers can offer higher gas prices for their transactions to incentivize validators to select their transactions. In our model, the leader selection (or view change) is based on a mechanism that first attempts to randomize (select/order) our internal validating nodes over other nodes. While this mechanism sacrifices fairness over security, our resharding implementation will address the issue (true randomness).
Selfish mining, Fork-after-withhold, and Rewards for uncle blocks
These vulnerabilities are related to selfish mining, where certain block producers can withhold the blocks and release at later point to benefit them. In our model, the block producers (leaders) are internal nodes (the leader selection selects internal nodes first, and the probability of external node getting selected as leader is very low). Even in case of dishonest block producers, performing selfish mining without controlling the majority is impossible. Moreover, a malicious leader not producing a block for a pre-defined period of time (currently 60 seconds) leads to the invocation of the leader change process to prevent malicious leader. Also, leader change happens every 40 blocks.
34% voting power (network stalling)
For our consensus to work correctly at least two-thirds of the validating nodes are active all the time. To stall consensus 34% of the network must go offline simultaneously, which includes at least few of the internal validating nodes on top of the one-third external validating nodes. Further, our current network is validated by sufficient trusted external partners that strengthens our network against this attack.
Transaction malleability attack
In this attack, the attacker tricks a victim into paying twice by altering transaction hash and getting it confirmed. This attack is infeasible in Harmony chain because identical transactions with same nonce will never get confirmed.
In this attack, the attacker alters the network time counter of the node and forces the node to accept an alternative blockchain. This attack cannot happen in Harmony chain because we do not perform wall-clock-based block validation, instead rely on epoch/block height in the blockwise-BA validation.
Routing or BGP (partition, delay)
There are two forms of routing attacks: partition and delay. A malicious Internet Service Provider (ISP) can partition the blockchain network into groups or delay the block propagation. As a result of this attack, Harmony’s consensus process may be stalled, however FBFT shields against invalid blocks from getting accepted. We are in the process of implementing a heuristic-based approach to prevent this attack.
This attack is recently reported for mainly Proof-of-Stake blockchains. It is about the attack on the RAM/disk of a victim’s node by sending a large number of dummy blocks with valid headers (without the actual block contents). PoS blockchains whose codebase is forked from Bitcoin are susceptible to this attack due to the header-first new block verification mechanism that simplifies block verification of the blocks that contains coinstake transactions. Harmony chain does not have the concept of coinstake transactions. Further, verification of the block header and the actual block is done at once and not stored in memory or disk until the complete verification is performed.
Long-range, Stake-bleeding and Stake-bleeding after eclipse attack
In long-range attack, a malicious leader builds a longer private chain and claims its validity. For this attack to be feasible, the consensus model should be eventual (longest chain rule). However, Harmony’s consensus model is blockwise-BA, which is not amenable to this attack.
A form of long-range attack that is possible under the following criterias: when the chain has no checkpointing, it is longest chain rule based, and has trasaction fee and rewards. Currently, Harmony chain has strict chain density (meaning the number of validator slots for chain construction is fixed), which disallows any chain with smaller densities. Further, by holding the majority in terms of the validating nodes, this attack is impossible to perform.
A form of the stake-bleeding attack that first performs eclipse attack (described in the network layer attacks). In this attack, a set of victim nodes (that are validating) are shielded by the adversary nodes to make them accept the adversary chain (an alternative chain).
Race, Finney and Vector76 attacks
These attacks are not directly relevant for Harmony chain mainly because we do not rely on longest-chain rule instead our model is blockwise-BA. In race attack, the attacker creates two conflicting transactions and the victim accepts payment before confirmation. In finney attack (a form of double spend), the attacker pre-mines an identical transaction into a block and releases it to invalidate the actual transaction. In Harmony chain, the signed/submitted transactions once finalized or confirmed cannot be altered by the block producers, hence it is not possible to produce identical transactions or alter the transactions.
In this attack, the adversary influences the slot leader selection process to improve it’s chances of being selected. This attack is only possible if the slot leader selection process is based on a randomness that uses raw blockchain data (block hearder/content). Our randomness is based on VRF/VDF which is uniformly random, unbiased and unpredictable, hence the leader selection cannot be influenced.
Transaction denial (censorship) attack
In this attack, the adversary tries to prevent transactions of certain account from getting confirmed. This attack is possible in case of malicious leader. Since, Harmony’s leader selection currently picks internal validating nodes (this is temporary, until the resharding is implemented), it is safe to assume that this attack is infeasible. In the event of leader becoming malicious, a monitoring mechanism can trigger the leader change process (future work).
In this attack, honest validators are incapable of synchronizing correctly with the network due to time server synchronization issues or message delivery problems, ending up stalling the network or preventing liveness. If our internal validating nodes are unable to synchronize and the protocol cannot obtain majority, then our protocol may fail. However, we have built multi-layer monitoring mechanisms to monitor all possible failure scenarios that may happen to our internal validating nodes.
This attack is caused by a malicious leader building alternative chain by bribing other validators. By our assumption of 66% honest nodes, it is not possible to form groups and build alternative chains. Further, Harmony’s fixed density rule for chains (chains of smaller density is not accepted) protects from such alternative chains. Nothing at stake is similar in which a set of active validators tries to build an alternative chain, and the past majority attack in which a set of past validators tries to build an alternative chain are also not possible in Harmony chain for the similar reasons.
Network Layer Attacks
A network layer consists of peer-to-peer (p2p) network of nodes such that a node can get the updated state of the blockchain from some set of active nodes. The components of this layer include node discovery and information propagation and verification [6,7]. Below we list general network attacks that are common to any service in the internet (even Ethereum is susceptible to some of these attacks). Harmony uses libp2p with some enhancements to prevent/mitigate some of these attacks.
Unlimited nodes creation can happen in blockchains that use public-key as node ID which are susceptible to attacks that creates a large number of nodes on a single machine (same IP address) to monopolize the incoming/outgoing connections to victim nodes. To mitigate this, the combination of public-key and IP address are used as node ID (#2054).
Uncapped incoming connections can lead to victimization of certain nodes by creating a large number of connections. Enforcing an upper limit could mitigate this issue.
Public peer selection vulnerability is related to crafting the list of peers to which a node connects to perform state sync. Harmony’s libp2p uses a variant of S/Kademila that is not susceptible to this vulnerability.
Sole block synchronization does not apply to Harmony blockchain as any node that is synchronizing uses multiple peers and not just a single peer.
RPC API exposure can lead to unauthorized access to the remote client (via RPC API) to obtain sensitive data or perform unauthorized actions. Configuring the listening port (instead of using the default port) and adding access control to filter remote RPC calls can mitigate this problem.
In Eclipse attack, an adversary can launch a large number of nodes to surround its victim and can end up stalling the consensus. However, it is impossible to create invalid blocks due to fixed density chain requirements of Harmony.
Attacks on Wallets
Harmony is supported in several hardware and software wallets, such as MathWallet, TrustWallet, Nano Ledger, and SafePal. Below we discuss the applicability of well-known wallet attacks.
For security against Phishing, we rely on our wallet partners. In Dictionary attack, an attacker attempts to break a victim’s cryptographic hash and salt by picking the hash values of common passwords like ‘password1'. This attack does not apply to our case because our wallets are ECSDA based.
Vulnerable signatures that leads to same random value in more than one signature is less likely due to ECDSA and Secp256k1 curve, which is also used in Bitcoin/Ethereum.
Flawed key generation attack happened on ECDSA due to poor randomness. We are using CSPRNG to mitigate this.
Running Environment Issues
A blockchain environment often consists of components such as web interfaces to interact with applications, databases for storing blockchain data, cryptographic mechanisms to support consensus protocol, and internet service for the network layer. Below we list several security issues in the environment that can expose any blockchain to attacks. However, these issues are not directly addressed in any blockchain, but relied on secure software engineering practices.
- Weak password is related to low-entropy passwords and insecure password storage
- Unvalidated URL redirection
- Broken access control can lead to an attacker breaking into the web server and replacing the original contract address with its own
- Unreliable BGP messages
- Sensitive DNS servers can be attacked to incorrectly resolve DNS queries and redirect users to malicious websites.
Application Layer Attacks
Application layer is mainly concerned with how smart contracts are handled by the blockchain. While there exists smart contract best practices , if vulnerable contracts are deployed to a blockchain, it is easy for an attacker to exploit it. We recommend smart contract users to verify their contracts using the state of the art analyzers before deploying to our network. Since we use EVM for smart contract layer, our chain is susceptible to any smart contract vulnerability attacks (just like Ethereum). We our in the process of building an integrated IDE with tools to verify smart contracts against well-known vulnerabilities.
To conclude, most of the well-known vulnerabilities and attacks are either not applicable or not possible in Harmony chain. Figure 1 summarizes the list of vulnerabilities and security attacks that are considered in our internal security analysis. This analysis provided us an opportunity to self evaluate different aspects of our blockchain to ensure highest security standards. This report only provides informal reasonings and our mitigation steps. By no means it is comprehensive. However, it is intended to help the readers understand at high-level the security aspects of our blockchain. This security analysis is performed based on the current state of our mainnet for the upcoming token swap release. We plan to repeat this process for our open staking release in the upcoming month. We encourage the readers to leave comments and suggestions if we have missed out any particular security issue or how we can improve the security of our blockchain in general.
Thanks Rongjian Lan, Howard and Eugene Kim for help with analyzing the vulnerabilities and security attacks, and Leo Chan for help with proof-reading.