PoCo #3 — Enclaves and Trusted Executions

Enclaves are paradigm shifting tools in the world of Cloud computing. Thanks to the security they offer, anyone will soon be able to run its applications on any computer without the fear of disclosing sensitive data to a third party.

What are enclaves?

Enclaves are solutions which are built into the CPU and provide hardware security. Using a dedicated set of instruction codes, enclaves are isolated regions of memory which are protected from processes running at any privilege level, including the operating system.

The most well-known enclave solution is Intel® SGX, which Lei discussed in the iExec dev letter 14.

Aren’t enclaves and PoCo contradictory?

By now you should be familiar with the Proof-of-contribution protocol discussed in this series. This protocol is in charge of providing a trusted computing environment on top of untrusted resources. This is achieved through incentives mechanisms that make the actors of the platform want to behave correctly.

These incentives, combined with the use of cryptographic signature and the properties of the blockchain, ensure that workers have no economic advantages of producing fake results (i.e claiming reward without doing the actual computation).

However, the story does not end here! The PoCo orchestrates the various contributions of workers, schedulers, dapp providers and soon data providers. On the other hand enclaves ensure that a worker is not able to interfere with the execution, thus removing the need for result certification.

This particularly appealing for non-deterministic computations because results cannot be certified by comparing their signatures. Thus using enclaves can significantly improve the security providing that blockchain-level enclave certification is implemented. In short, it means that the PoCo algorithm that runs on the blockchain must have a proof that a worker has actually executed the application within an enclave.

However the enclave technology is not a magic wand. First, it’s not yet available on all processors and even when available, the BIOS has to support it and support must be enabled by the user (which is usually not by default). Plus, there is a performance overhead when running an application within an enclave. Finally, no GPU has support for enclave and it probably wouldn’t makes sense for GPU to implement that. As a result, despite being a very promising technology, there are at the moment very few Cloud providers that offer servers with enclaves enabled.

This is why our solution uses the PoCo in conjunction with enclaves.

PoCo is in charge of the orchestration of all contributions. This includes a layer of certification that relies on the reputation of the workers. In the PoCo vision, enclaves are not considered as inviolable solutions (which recent news unfortunately confirms), but rather as an accelerator that, when enabled, increase the trust of workers that run them.

PoCo can, therefore, have enclaves and traditional runtimes participate in the same job. Still, using the PoCo parameters, a user can fall back to having its application running on a single enclave if he so desires. This is as simple a requiring a low trust requirement (achievable by a single worker) and using a tag restricting the job to enclave providing workers.

So when will PoCo be enclave ready?

It already is!

The PoCo smart contracts are visible on Github. In the WorkerPool.sol you can see it in action in the method allowWorkerToContribute where the scheduler registers the enclave wallet address. When publishing its contribution, the worker has to provide a valid signature that passes this challenge. This will then be used to boost the user score when computing the reward.

Indeed, the application result calculated on Intel® SGX worker can be signed by enclave private key or a private key protected by enclave, the signature can then be transferred to on-chain network for verification via the corresponding public key that is registered on Blockchain.

The first appearance of the enclave challenge goes back to a commit pushed by Francois on February 8th 2018. Despite the previous articles of this series not insisting on it, enclaves integration has always been a part of the PoCo development.

Building the PoCo with enclaves in mind is one thing, having the middleware implement it is another with still require some development. Rest assure that the smart contracts currently deployed on the main net support this feature which will soon come into action. On going developments focus on helping the users to protect application and data privacy.

How does PoCo recognize enclaves?

A specific signature mechanism is required to certify, on-chain, that a job was in fact executed in a secure enclave. This signature mechanism is integrated in the PoCo transactions detailed in the previous articles of this series.

Let’s go through the process of certifying an Intel® SGX enclave:

An enclave is provisioned on a worker with Intel® SGX capability and a pair of public/private keys is generated inside the enclave. These keys are secure and no one outside the enclave can access them.
The worker sends the public key to the scheduler using a certified channel (signed by Intel® SGX).
Using the Intel Attestation Server (IAS), the scheduler can verify that the public key it received was actually produced by an enclave running the iExec middleware.
As part of the PoCo, the scheduler sends a message to the blockchain authorizing the worker to contribute to a specific work order. This message includes the enclave’s public key. This public key is registered (enclaveChallenge) and will restrict the submission of contributions.
The worker runs the dapp in the enclave and signs the result with the enclave’s private key. The dapp could run outside an enclave, but the iExec enclave is designed such that for the result to be signed must be computed inside the secure environment.
The worker sends the contribution report to the blockchain. This report includes a signature of the contribution by the enclave, which can be verified on-chain.

The verification of the enclave using Intel Attestation Server is specific to Intel® SGX, and introduce some form of centralization. However, other attestation approaches are being developed and will be considered in the future. Still, once a secure communication channel is established between the enclave and the scheduler the logic stays the same. Therefore, the on-chain part is agnostic of the actual enclave technology, meaning iExec should support any enclave technologies in the future.

So, what’s next ?

In this article, you have learned how PoCo integrates enclaves attestation. At the moment the team is finalizing the protocol extensions between the workers and schedulers. We are also working on a new version of the SDK that makes a regular Docker image “Intel® SGX enabled”.

At Devcon4, the iExec team will announce the first end-to-end solution which allows to protect user’s input data and the results in a simple and secure way.