Sha-Gate Risk Analysis
Risks can only be allieviated after we identify and analyze them. In the design of sha-gate, we have identified the following possible risks:
The code of smartbchd nodes has bugs related to sha-gate.
The operators collect to fake smartbchd nodes (intentionally or get hacked)
One or more operators get unavailable (intentionally or get hardware fault)
The private key of an operator is stolen out from the enclave (by the administrator or an attacker)
The monitor's EVM private key is stolen
The monitor's BCH private key is stolen
The monitor's EVM private key is lost
The monitor's BCH private key is lost
The node proposers elect a wrong node set
Risk 1: Some kinds of bugs can be discovered by the monitor, while some kinds can not. Anyway, the monitor needs to read the events generated by smartbchd nodes to find potential bugs. Currently, the monitor does not check the amount: for example, if a user can spend 0.1 SBCH to get 10 BCH on main chain, then such a bug cannot be discovered by the monitor currently.
No matter how we refine the code of monitor, there are always some kinds of bugs that cannot be discovered by it. So the monitors use another scheme for safeguard: if the total redeemed amount is larger than a given threshold in the last 24 hours, the monitors pause sha-gate. This scheme is used for damage control.
Risk 2: Let's consider the case that the nodes are hacked (DNS get polluted or something). Firstly we can use cloudflare or some other application firewalls to avoid such attacks. Secondly the RPC results related to chain-crossing are signed by a special private key, and the attacker can not do any harm without knowing this key. Thirdly the operators will do nothing if the nodes do not all return the same result, which means the attacker must hack all the nodes connected by the operator. Finally, monitors will also check that the operators are connecting to correct nodes and stop the operators if necessary.
Now let's consider the case that the administrator of an operator makes it connect to wrong nodes intentionally. The administrator inputs wrong bootstrap nodes to the operator enclave and he blocks out the monitors' stop commands.
To alleviate such a risk, we hard-coded two nodes in the operator's source code as bootstrap nodes. In case of these two nodes crashing, a special private key can authenticate other nodes to act as bootstrap nodes in a given period.
Risk 3: If the operator's SGX instance get power supply problem or networking problem, it will be unavailable for a while. If the server's CPU is damaged, the operator's private key will be lost forever. The 7-of-10 signature scheme can alleviate such a risk. If no more than three operators get such problems, we can always elect new operators to replace the fault ones.
Risk 4: Intel SGX2 enclaves have never leaked private key from inside, even when the administrators are evil. Even someday in the future a hacker can break into SGX2 enclaves, he must steal at least 7 private keys. This risk is low. But we still use proxies to protect the operators from directly facing internet traffic.
Risk 5: If a monitor's private key is stolen by an attacker, the attacker can pause the sha-gate and stop all the operators. But it cannot steal any coins as long as the operators do not collude. We can use a hard fork to exclude the evil monitors.
Risk 6: Only when at least seven operators get unavailable, the monitors' BCH private key are used to move the cc-UTXOs. In such cases, an attacker needs to steal two monitors' private keys to do evil. This risk is low.
Risk 7: If no more than two monitors lose their private keys, the other monitors can still do the duty of pausing sha-gate and stoping operators. We just need to elect new monitors.
Risk 8: Only when at least seven operators get unavailable, the monitors' BCH private key are used to move the cc-UTXOs. In such cases, the cc-UTXOs are stuck only when at least two monitors' private keys are lost. This risk is low.
Risk 9: The nodes proposers elects smartbchd nodes in a public process on the smartbch chain. And when the operators' enclaves get the new election result, they will delay some time before using it. So if the nodes proposers elects a set of evil smartbchd nodes, it is easy to be found by the community. The operators' administrators and monitors can stop the operators to deal with such cases.
Last updated