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.


What is SGX?

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

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:

  1. Among the online participants, the majority of the stake is controlled by honest or rational participants.
  2. The network is highly synchronous, i.e. recipients receive messages within a known, short, bounded delay.
  3. 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.
  4. 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

Running Ethereum full nodes in SGX enclaves which can provide the latest validator set to users in the network

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

A naive delegation protocol in Casper which allows users with less than the Casper minimum stake, i.e. 1000 ETH in this example, to indirectly participate in the Casper protocol.

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.

Running the code of the delegate nodes inside SGX protect users from malicious delegator

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

Hardening initial peer-joining

Acknowledgement: Special thanks to Virgil Griffith, Yaoqi Jia, Shweta Shinde and Vitalik Buterin for their feedback in the early version of this blog post.

KyberNetwork, SmartPool

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store