Cloud Enclaves and their Applications in Blockchains

By Wang Kui (kui.wang@smartbch.org)

Top cloud computing vendors have recently been actively marketing confidential computing services, i.e., enclaves. Enclaves provide the features of integrity, isolation, data sealing, and attestation, through which relying parties only need to trust the CPU hardware and the code running inside enclaves. The cloud computing vendors and the administrators of enclave instances cannot tamper or peek at the execution inside enclaves.

Blockchains enforce "code is law" by consensus algorithms, while enclaves enforce "code is law" by CPU hardware. The similarity between them hints to us that it's possible to improve blockchain applications' security, privacy, and efficiency with enclaves

In this article, we'll introduce the mainstream enclave solutions of the top cloud computing vendors and discuss several applications which may benefit from enclaves.

Enclave Solutions

Traditionally, confidential computing means how we can trust a physical device's hardware-software stack. It follows a bottom-up scheme:

1. A secure cryptoprocessor measures the firmware and hardware of the device. If they are trustable, start the firmware.

2. The firmware measures the OS. If it is trustable, start it.

3. The OS measures application programs and starts only the trustable ones.

In the cloud computing era, the vendors still need to make the hardware-software stack secure and trustable. But their customers want more: even if the vendors are evil or their cloud infrastructures are vulnerable, the computing instances and containers are still trustable.

So today's confidential computing solutions start from some middle point in the hardware-software stack, instead of the bottom. The major server CPU manufacturers, i.e., Intel and AMD, take different choices:

1. AMD's SEV technology enables enclaves on top of hypervisors, which contain OS kernel and application programs.

2. Intel's SGX technology enables enclaves on top of OSes, which contain only (a part of) one program and one process (with multi-threading).

Currently, Microsoft and Google provide enclaves based on AMD CPUs, while Microsoft and Alibaba provide enclaves based on Intel CPUs. Despite the implementation details, their products all support the following features:

1. Integrity: a program in the enclave executes exactly as its source code specifies, no party can tamper with it, even the hypervisor and/or OS under it. A hacker or evil administrator with privilege cannot change how the code runs.

2. Isolation: the program(s) executing context (registers status and DRAM status) cannot be viewed or changed by any other party, even the hypervisor and/or OS under it.

3. Data sealing: the data written to persistent storage from the programs in an enclave are encrypted and can only be decrypted in the enclave later.

4. Attestation: after hardware-assistant measurement of the program running in an enclave, the hash digest of the measurement is signed by a key kept by hardware to convince the relying parties that it IS the predefined trustable program running.

When an enclave is providing services on the cloud, the relying parties can trust it even if the cloud computing vendor and its customer who rents and operates the enclave are both dishonest. The human factor threatening the service's security is reduced dramatically.

Manipulation-proof Random Number Generator

Various blockchain applications need random numbers for fairness, such as gaming, consensus, and stochastic payment. Since blockchain is deterministic, a true random number generator (RNG) based on physical entropy cannot be used.

Many applications directly use block hashes as a random source. Block hashes are cheap to use because there is always a hash for every block and no more computation is needed. But block hashes are prone to be manipulated. The block proposer can try different transaction sets and pick a block hash that is most beneficial to it. On PoW chains, this trial process may delay the proposer from successfully mining a block, so there is some potential penalty. On a PoS chain, it is almost riskless for the proposer to try different block hashes.

VRF (verifiable random function) is a special kind of hash function. Using a private key, VRF computes the hash result and proof from the input pre-image. With the corresponding public key and the proof, the hash result can be verified against the pre-image. If an honest party is holding VRF's private key, then the VRF results of block hashes can be used as fair random numbers, because the validators have no way to know the VRF results before proposing a new block.

An enclave can act as such an honest party: it does exactly as the source code specifies, and never reveal anything it should keep as a secret, including the VRF private key. When a DApp needs the random number corresponding to a block, it queries the enclave for the VRF result and the proof and then verifies them on-chain against the VRF public key and the block hash, i.e., the VRF input. If the check passes, the DApp will have confidence that this random number is not manipulated.

Improve privacy of CoinJoin

CoinJoin has long been used to improve the privacy of cryptocurrencies. It was first implemented by the Dash coin and later Bitcoin Cash also got an implementation of CoinJoin named CashShuffle.

CoinJoin's idea is quite simple: a UTXO-based transaction has multiple inputs and multiple outputs; by combining inputs and outputs from what would otherwise be separate transactions, into one jumbo transaction, the correspondence of the original transaction's inputs and outputs are obfuscated. Just make your UTXO set undergoes several levels of such jumbo transactions, and an external viewer cannot match the resulting UTXO set owned by you to the original UTXO set.

CoinJoin uses a client-server model. The servers coordinate which users are shuffling and know which user owns which inputs/outputs. This is a risk for privacy because servers may leak their knowledge. How to alleviate this risk? Dash coin uses multiple masternodes for coordinating and CashShuffle has decentralized servers. If you scatter the many levels of jumbo transactions among these servers (masternodes), then your UTXOs cannot be fully tracked as long as a few of these servers are honest. The more levels and servers you use, the harder your coins are to track.

The isolation feature of enclaves makes sure no information leaks out from the servers. If the client confirms the server runs inside an enclave through attestation, it would have the confidence no third party can steal the information sent to the server. Thus, fewer servers and levels are necessary and the total solution can be more efficient.

Blackbox Execution of Pure Functions

A common scenario of blockchain applications is that you need to convince the public that you have the solution of an equation but you don't want to reveal this solution to the public. For example, you want to prove that you know a pre-image that hashes to a given output but you do not want to show this pre-image to the public for verifying.

Let's generalize such a scenario to any pure function. A pure function has no side-effect and its outputs depend only on its inputs. We have:

1. A predefined specification of the pure function without ambiguity

2. Some public input arguments for this pure function, which can be revealed to anyone

3. Some private input arguments for this pure function, which cannot be known by anyone else except their owner

We want a reliable blackbox, which is trustworthy to compute the correct outputs from the given public and private input arguments. At the same time, the provider of private arguments does not need to worry about information leakage.

Several cryptographic technologies can implement a blockbox with relatively simple functions and we usually refer to them as "zero-knowledge-proof". Such technologies need a lot of expensive cryptographic computations and the function's logic cannot be too complex, or else the proof circuit would be extremely large. Furthermore, if the pure function has an unbounded loop inside, zero-knowledge-proof technologies would be infeasible because the proof circuit cannot be constructed. Another shortcoming of zero-knowledge-proof technologies is the hardness to use. If the engineer does not have enough cryptography knowledge, it is hard to get things working and prone to leave vulnerabilities.

Enclaves can also implement such blockboxes. Isolation ensures enclaves never leak private input arguments, while attestations ensure enclaves compute just as the source code specifies.

Compared to zero-knowledge-proof technologies, enclaves are weaker in the trust model: we only need to trust math to use zero-knowledge-proof but must trust CPU vendors to use enclaves. However, enclaves are much easier to use: the pure function's source code can be used directly in enclaves. There are no circuit constructions and unbounded loops are permitted.

Off-chain enclaves can easily interact with on-chain smart-contract. An enclave can be denoted by a public key stored on-chain. With the private key, it signs the pure function' public input arguments and the outputs. On-chain logic verifies the signature with the public key and accepts the outputs.

Reliable Witnesses for Chain-Crossing

All the chain-crossing technologies need witness. To make a cross-chain transaction from Chain A to Chain B happen, Chain B must be aware of Chain A's state change. The only trustless way for Chain B to keep track of Chain A's state is running a full-node client of Chain A to provide information for every Chain B's full-node client. This is a very rigorous requirement.

We do require that every smartBCH full-node client must have a corresponding BCH full-node client for querying transactions on BCH main chain. But it is impossible to require a BCH full-node client to watch a smartBCH node when running. It is also impossible for other chain-crossing scenarios, such as Ethereum to BSC, Ethereum to Solana, etc.

So it is unavoidable for cross-chain bridges to rely on some witnesses providing state information about another chain. The problem of witness collusion threatens all the cross-chain bridges. For some bridges, the witness set is the same set of validators and the state information is the Merkle root of the whole state tree, which leads to a little safer design but still cannot avoid collusion.

A witness runs a full-node client of Chain A and publishes its state to Chain B with its signature. If it turns evil, it may publish any information to Chain B, despite the actual state of Chain A. Even if the witness is a trustworthy organization, the machine administrator can still be bribed and the private key for generating signatures onto Chain B may get stolen.

As an enhancement, the witness can run its daemon process inside an enclave. The attestation process prevents corrupted administrators and isolation protects the private key.

When we implement SHA-Gate, the cross-chain bridge which transfers BCH between the main chain and smartBCH sidechain, enclaves will be taken into consideration since the blueprint.

Conclusion

Major cloud computing vendors provide several enclaves solutions. Enclaves' features of integrity, isolation, data sealing, and attestation, can help users build better blockchain applications. We the smartBCH developers will utilize them to improve the ecosystem of Bitcoin Cash.