Using Secure Hardware to Harden Casper for Greater Defense In Depth
Loi Luu
National University of Singapore
(This work was done while interning at the Ethereum Foundation)
Tl;dr. We discuss several use cases of hardware root of trust, particularly Intel SGX, to harden proof of stake protocols, particularly Casper, for defense-in-depth. Specifically, we show how SGX can: help resolve long-range forks, harden efficient delegation, harden network time synchrony, and harden connectivity to trusted peer servers. We do not propose a SGX-based proof of stake protocol but propose solutions that omni-harden the security of existing PoS protocols. Although we use Casper, our proposals are agnostic to the underlying PoS protocol.
Background
What is SGX?
Many good references about SGX are available (e.g. this MIT paper and this documentation from Intel). I quote the description about SGX from this.
SGX is a set of instruction set extensions for CPUs released in Fall 2015 and available on recent CPUs. The key ability SGX provides is the notion of confidential, private execution with integrity guarantees. In essence, the chip has a special construct called an enclave. An enclave is like an ordinary program, except that the memory contents of an enclave are encrypted whenever they are off-chip, and accessible only on-chip, and only while the special enclave code is running. Further, the decryption keys are available solely to code with a certain hash: if you or a hacker were to hack the enclave code and change its hash, that hacked code will no longer have access to the encryption keys, repelling attacks. As a result, this ingenious technology does not permit anyone, even the owner of the machine who can modify the code arbitrarily, to peek at the contents of the enclave or to modify execution within an enclave. Further, the SGX hardware enables remote attestation, that is, the ability to prove to a remote computer that a given enclave is running a particular software distribution. In essence, the chip is able to issue a statement that says “I guarantee to any remote party that I am running this code with this particular hash,” which is a critical bootstrapping mechanism.
The nice thing about SGX is that the security guarantees are built into the CPU. SGX enclaves are secure against an attacker who has placed probes on the system bus, has special attack hardware on the USB ports, has modified disk contents and is able to forge network packets any which way. The only way to compromise these guarantees is to shave off the CPU packaging and place probes on the silicon wafer, a costly undertaking requiring a clean room and significant reverse-engineering effort. And users currently already trust Intel (or AMD) to execute their transaction signing code correctly.
Basically, SGX allows:
- Executing one’s applications on an untrusted machine with guaranteed confidentiality and integrity of output.
- Users to run the desired software in an untampered environment in a remote machine.
It is worth noticing that many recent works have leveraged SGX to build a new consensus protocol (e.g. SawTooth Lake with proof of elapsed time), or a trusted payment channel (e.g. Teechan protocol).
Proof of Stake Protocols and Casper
Most popular cryptocurrencies are using proof of work as a mechanism to probabilistically elect leaders who propose new blocks of transactions. Proof of Work has successfully secured several billion dollars worth of cryptocurrencies. However, proof of work requires miners to burn huge amounts of energy. For instance, the Bitcoin platform may consume as much electricity as the entire country of Ireland, this motivates researchers to propose protocols using proof of stake. The high level idea here is to require users to control coins, or stake in the system, in order to generate new blocks. The protocol randomly selects users as the leaders who will propose and sign new blocks to extend the blockchain. Thus, often mining in proof of stake is called virtual-mining in which the cost of mining is much cheaper than in Proof of Work.
Several proposals for a provably secure proof of stake protocol have been presented recently (e.g. SnowWhite, Ouroboros) . Here we consider the Casper protocol, constructed and proposed by researchers from the Ethereum Foundation, in our discussion. Although the Casper protocol remains unfinalized, many details can be found from these blog posts (See Vlad’s the history of Casper series, Vitalik’s blog posts). In general, Casper makes following assumptions:
- Among the online participants, the majority of the stake is controlled by honest or rational participants.
- The network is highly synchronous, i.e. recipients receive messages within a known, short, bounded delay.
- It is not possible to reverse the chain from a block which is too far in the history (ie., more than X blocks behind the latest block) (in SnowWhite), or users must know who are the latest participants in the protocol (Casper) in order to determine which chain is the correct one. This assumption solves the long-range fork attack in which an attacker, after cashing out, forks the chain at some previous block to create a new valid-looking chain.
- There exists some mechanism to incentivize users to participate in the protocol, otherwise no protocol is secure against an attacker who controls even 10% of the coin if only 15% of the stakes are used in the protocol. This assumption builds atop assumption (1). If we can incentivize users to join the protocol, condition (1) is easily satisfied.
This article shows how one can leverage SGX to realize these assumptions practically, thus strengthen existing protocols.
Hardening against long-range forks
New users joining the system are vulnerable to long-range fork attacks if they happen to be on the incorrect chain. Long-range fork is hard to defend against because rational users after sending their coins are incentivized to fork the chain from some previous block to control the coins again. Value at Loss (i.e. the amount of coins will be forfeited if some blockchain is not the correct, or “longest” one) approach in Casper alone does not work because it may turn out that 100% of the stakes have changed hands, so the new chain may have 100% of stakes backing it. Thus, new users just join the fake chain, because they see more stake invested there.
In Casper, we assume users will be able to fetch the latest set of validators, and tracing down to the latest finalized block. Where do users fetch such information? Presumably from a third party like EtherScan, wallet providers, etc. Regardless of where users get the latest set of validators, this step is very important as getting a wrong set results in the users reading from the wrong chain. Thus, not having to trust any third party is ideal, since the whole point of going decentralized is to not have to trust on a single party.
Our improvement. We propose a solution to securely provide new users the latest set of validators. In our solution, we run a full node inside an SGX enclave and allow users to fetch the latest validator set from our node. Thus, instead of trusting some third party, users only have to trust:
- Intel Corporation didn’t backdoor SGX.
- The hardware protecting the enclave.
Our proposal is for users to run full Ethereum nodes inside SGX (there exists framework which helps you easily port your software to run within enclaves). Further, users can remotely attest if the software running inside the enclave is up to date before interacting. The connections between users and SGX are encrypted, so even the malicious OS cannot tamper the network packages. These are some properties that existing third parties like EtherScan cannot provide.
Lowering the barrier to validator participation
We next address incentivizing more users to participate. With the current design, not all coin holders can deposit their coins and be Casper validators because the minimum deposit amount may be of thousands of ether — -a high barrier to entry. Delegation protocols basically allow users to authorize some delegate to vote on their behalf (see Figure X). Thus, thousands of users each has only a few ether can still participate in the protocol, indirectly though, and do not need to be online. However, obviously if the delegates sign invalid blocks, delegated coins may be forfeited.
Our solution. We propose a solution to overcome the byzantine delegates problem. Our idea is to run the delegates inside SGX enclaves, thus guaranteeing that the delegates will follow the protocol directly (see the figure below). Each delegate will have a contract to allow users to deposit their coins to. Users also specify how long they want to keep their coins in the contract, i.e. allow the delegate to represent for them. After some time, users can withdraw their coins from the contract, and earn their reward from participating in the protocol.
There is some potential threat here since the OS which hosts the delegate enclave may be compromised and deny the enclave from participating in the protocol. However, such a threat won’t allow any attacker to steal user deposits. Users will still be able to get their coins back after their deposit periods are over, but without the expected reward (since the delegates couldn’t participate in the protocol). With further analyses, we expect to show that the attacker can only lock users’ coins for awhile.
One approach to resolve the coin-locking problem is to design a proper validation code in Casper, so users can directly request to withdraw their coins from the delegate once they detect that the delegate is malicious. This will be discussed further with more details later (thanks to Vitalik for suggesting this).
Hardening time-synchrony
We can also use SGX to build a globally shared timestamp to improve network synchrony. In the current Ethereum client implementation, a new node gets the global timestamp from a ntp server. These one-time trusts are also required in Bitcoin to some certain extent, and are often omitted from the public logic. A compromised ntp server is also able to disconnect a node from the network by returning incorrect timestamp. Using SGX, one can run ntp servers within different SGX enclaves to implement a global timestamp service for Ethereum nodes. However, this is not complete security as the os can delay the message from the enclave, thus making the timestamp returned from the enclave stale information to the clients. This is to say that SGX only slightly improves the security of the timestamp servers, but does not provide the highest security guarantee.
Hardening initial peer-joining
We can also use SGX to establish trusted peer servers. When joining, an Ethereum client talks to some peer servers which provide some seed nodes (or peers) for the node to connect to and fetch the latest state of the blockchain. It is easy to see that malicious peer servers can easily eclipse attack a node by providing a list of malicious nodes. Using SGX, we make it more difficult for a peer server to return a malicious subset of peers. Nonetheless, the protection is not complete. For example, an adversary can compromise the OS and control the network coming to/from the enclaves. Thus, a peer server inside an enclave may only receive information from malicious peers (the os drops all connections from good peers). Thus, the enclave ends up having information of malicious peers only.
Acknowledgement: Special thanks to Virgil Griffith, Yaoqi Jia, Shweta Shinde and Vitalik Buterin for their feedback in the early version of this blog post.
