Should We Kick Hardware out of Blockchain?

You may think blockchain has little to do with hardware. After all, from Bitcoin to Etherum, blockchains are all software-defined. The hardware-based solution is usually more centralized.

However, in the privacy-preserving blockchain world, by carefully combining software and hardware, we could design a solution with the best balance between scalability and confidentiality, while still keeping it trustless. 

Phala Network implements a confidential smart contract. It differs from traditional contracts because contracts run inside a special hardware enclave in CPU, i.e. Trusted Execution Environment. The program running inside TEE is highly isolated from the rest of the world. A malicious attack can neither read the data in the memory without authorization nor manipulate the program to produce any unintended behavior.

In Phala Network, we call the supportive program running inside TEE “

pRuntime

”.

pRuntime

is the runtime environment that maintains the basic TEE miner and Gatekeeper protocol inside the TEE. It handles the TEE remote attestation, on-chain registration, key management, and confidential contract execution.

But how to convince a user the smart contract is running inside

pRuntime

, not an emulator that doesn’t provide any data security? Here comes the core concept: Remote Attestation.

Remote Attestation

Remote Attestation is the key to ensure the security of a TEE system. Quoted from Intel, it proves that a certain code (measured by the hash of the code), optionally with some customized data generated by the code, is running inside an up-to-date genuine Intel SGX enclave.

Remote Attestation is a basic building block for confidential smart contracts. But it’s not very useful if we cannot establish an end-to-end secure communication channel between a party to TEE. Intel SGX also provides a Secret Provisioning protocol to solve the problem elegantly.

By adopting the Secret Provisioning protocol, a chain of trust from the user to

pRuntime

can be established:

The blockchain has the hash of the canonical

pRuntime

codepRuntime runs the remote attestation protocol, gets a report with the data: hash of the attested code (

pRuntime

itself); and the public key of an ephemeral identity key pairThe RA report is submitted to the blockchain and validated on-chain. The blockchain compares the hash from the RA report (implies: the participant is a canonical

pRuntime

in TEE)The identity public key is registered on the blockchain (implies: only the current

pRuntime

has control over this identity key)

As a result, as long as a message is signed by the identity key, it must be produced by the registered

pRuntime

. Users can further establish a TLS-like connection to a

pRuntime

with its registered public key.

To communicate with TEE, the user can get the public key of a certain

pRuntime

from the blockchain (from TEE registration). Then the user can use the public key of his substrate account to run a Diffie-Hellman protocol. It derives a secret key for communication between the user and the

pRuntime

.

As the chain-of-trust established, it also implies the identity key is sufficient to uniquely represent the identity of the

pRuntime

. So a single Remote Attestation can protect all the future communication with the pRuntime, if under the assumption of no TEE hardware breach (which will be discussed later).

On-chain upgrading is a critical requirement as it greatly reduces the security risks exposed by a hard-fork upgrade. Substrate natively supports on-chain runtime upgrade. It’s done by the on-chain governance pallet. On the TEE side, the runtime is also upgradable.

When upgrading pRuntime, we should submit the hash of the new pRuntime version to the blockchain. Then the community can review the code, discuss, and vote for the upgrade by an on-chain governance process similar to Substrate.
Both Gatekeepers and miners have to upgrade pRuntime once a new version is accepted on-chain. Miners are easier because they can simply stop mining, do the upgrade, and resume mining. This is possible because miners are not required to be always online. Gatekeepers have high availability requirements. So they either run another TEE client with the newer version, and wait for a natural Gatekeepers switch in the next election period, or do an emergency encryption dump of the states, and recover it to the new pRuntime.

Though there are risks to dump the state, it’s still useful in case of an emergency. SGX provides a “seal to enclave” feature, which can produce a cipher that can only be decrypted by the same enclave.

To mitigate the risks for hardware security exploits, the keys in the Gatekeepers are distributed by a Shamir secret sharing scheme, which means that even the sealing is broken, the host still cannot get the original keys without massive collusion.

Our threat model partially assumes the TEE manufacturer can be trusted. This is reasonable. First, they don’t know how their hardware will be used and thus only can plan the attack ahead of time, reducing the risks. Second, if affected by zero-day attacks, the other applications running on this CPU are generally at risk.

Though we have the above assumption, we see actual hardware exploits come in the past. Fortunately, the vulnerable can usually be mitigated in a few ways.

It’s common to think software vulnerabilities are patchable while hardware vulnerabilities are not. This is not always the case. CPU can be patched by microcode updates. With the special design of Intel SGX architecture, most of the vulnerabilities can be fixed. Recently there was an attack called SGAxe, it was fixed by a microcode upgrade followed by a group key rotation. After the key rotation and revocation, all the out-of-date devices get rejected by the remote attestation.

But you might ask, what if someone still finds zero-day hardware vulnerable? Suppose the vulnerability requires physical access to exploit it, miners will be possible to steal data from the confidential contract. In this case, can apply randomness to mitigate. The blockchain can randomly assign some miners to the confidential contracts in a period. The miners shuffle in every such period. As long as the malicious party doesn’t have control over a great number of miners, the cost to do such an attack will be significantly high because it requires a massive control in a relatively long time.

In the worst case where the enclave is fully cracked, exposing the confidential data available to the attacker and allowing the attacker to arbitrarily manipulate the execution, we still don’t want to give up the correctness of confidential contract. Therefore we have the design that confidential contracts can require one or more replications.

The replication number doesn’t affect how the contract is executed because all the inputs are from the blockchain and thus deterministic. However, if more than one replica exists, multiple TEEs will try to commit the states back to the blockchain. In this case, there will be a simple on-chain voting process. We require a simple majority to “finalize” the states.

By having replications, it failed-back to a Polkadot’s validator-like security model. The attacker must control a sufficient amount of miners to break the correctness, even if SGX’s security assumption is broken.

In the past, blockchains are only software. The miss of confidentiality has long become a limitation for mass adoption. With the help of hardware and carefully designed protocol, we showed that it’s possible to build a secure, scalable, and confidential-preserving blockchain.

An early Substrate-based confidential smart contract blockchain on which you can develop confidential-preserving and privacy-first blockchain apps. Member of Parity Builders Program starting lineup. Recipient of Web3 Foundation Grant.

🌐Official Website | Twitter | Github