Should We Kick Hardware out of Blockchain?
You may think blockchain technology has little to do with hardware aside from mining. After all, from Bitcoin to Etherum, the actual functionality of blockchains is all software-defined. Hardware-based solutions are usually more centralized. However, in search of more private use-cases needed for businesses, decentralized finance, and other blockchain-native applications, we could design a solution with the best balance between scalability and confidentiality, while still keeping it trustless. This can be achieved by carefully combining the software properties of blockchains and innovations in hardware.
TEE based blockchain confidentiality
Phala Network provides a global private computation cloud. It can be used as a platform for confidential smart contracts. They differ from “traditional” contracts on networks like Ethereum in that Phala smart contracts run inside a special hardware enclave in a CPU, i.e. Trusted Execution Environment(TEE). The program running inside TEE is highly isolated, using its hardware-encrypted RAM. A malicious attacker can neither read the data in the memory without authorization (i.e. a cryptographic key that is stored inside the same TEE, only visible to the device itself and not external hardware or software it interacts with) 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, or an “operating system” to put simply, 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 that is running inside pRuntime is not just an emulator that doesn’t provide any real data security? Here comes the core concept: Remote Attestation.
Remote Attestation
“An application that hosts an enclave can also ask the enclave to produce a report and then pass this report to a platform service to produce a type of credential that reflects enclave and platform state. This credential is known as a quote. This quote can then be passed to entities off of the platform, and verified…”
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.
Secret Provisioning
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 user and TEE. Intel SGX, the only TEE currently supported by Phala, 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 code
- pRuntime 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 pair
- The 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 that 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.
All of the steps mentioned above are automated and kept “under the hood” by Phala in quick succession.
As the chain-of-trust is 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 under the assumption of no TEE hardware breach (which will be discussed later).
How about upgrading?
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 so-called governance pallet on the blockchain. 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 enabled on Phala.
Both kinds of node operators on Phala, gatekeepers, and miners, have to upgrade pRuntime once a new version is accepted on-chain. It is easier for miners 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 pRuntime version, and wait for a natural gatekeeper set rotation in the next election period, or do an emergency encryption dump of their most recent state, and recover it to the new pRuntime.
Though there are risks of loss of data when dumping 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, effectively allowing such an emergency migration.
To mitigate the risks for hardware security exploits, the keys in the gatekeeper nodes are distributed by a Shamir secret sharing scheme, which means that even if the TEE sealing is broken (which is an extreme case — see below), the host still cannot get the original keys without massive collusion with other gatekeeper nodes.
Attack and defense
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 cannot plan the attack ahead of time, significantly reducing the risks. Second, if affected by the so-called zero-day attacks, other applications running on this CPU (outside of the TEE) are generally at risk.
Also, we have seen actual hardware exploits of TEEs come in the past — so far mostly theoretical and coming from computer science researchers. Fortunately, those vulnerabilities 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. Given the specific design of Intel’s SGX TEE 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 got rejected by the remote attestation, effectively deeming the vulnerable devices broken. It’s important to note that the micropatch came in very quickly and we are not aware of any SGAxe-related real-world breaches.
But you might ask, what if someone still finds zero-day hardware vulnerable? Suppose the vulnerability requires physical access to exploit it, as some other papers suggest, miners may be able to steal data from the confidential contract. In order to mitigate this, we apply randomness to Phala. The blockchain randomly assigns miners to the confidential contracts in each period. The miners shuffle after every such period. As long as the malicious party doesn’t have control over a significantly large portion of miners such an attack is impossible. Also, the cost to do run an attack would be extremely high because it requires maintaining control over the network for 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 the confidential contract. In order to allow the blockchain to distinguish manipulated execution from a genuine one, we allow replications of smart contracts on multiple miner devices.
The replication factor doesn’t affect the execution because all the inputs are routed from users and ordered by the blockchain and thus deterministic. However, if more than one replica exists, multiple TEEs will try to commit the updated smart contract 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 adding replications to the TEE-based execution of smart contracts that otherwise don’t require them for enhancing trust properties, we maintain a fall-back security model similar to Polkadot’s validator-based security. The attacker must control a sufficient amount of miners to break the correctness, even if SGX’s security model is completely broken.
Finally, we are planning to add support to other TEE hardware, such as AMD SEV and Arm TrustZone. If other chip manufacturers jump into the race to eliminate Intel’s hegemony in this nascent hardware space, we will be quick to adopt them as well to ensure the reliability of Phala and resistance to any exploits.
Summary
Up to this day, blockchains were only software-based in architecture. However, the lack of confidentiality has long been a limitation for mass adoption. With the help of hardware and carefully designed protocol, we explained that it’s possible to build a secure and scalable confidentiality-preserving blockchain for personal and enterprise-scale use. Only a public blockchain with a transparent codebase of its runtime and a sufficiently decentralized set of miners and gatekeepers can allow this. And that is exactly what we’re building at Phala.
Phala Calender
SoonTestnet campaign (and a secret little game)6.28AMA with another famous project7.5-7.6Present at Hangzhou blockchain week jointly hold by Hangzhou government and 8bit.
About Phala
A Substrate-based confidential smart contract blockchain on which you can develop confidential-preserving and privacy-first blockchain apps. Member of Substrate Builders Program starting lineup. Recipient of Web3 Foundation Grant.
