In the Dev Letter #14, Lei Zhang explained how to protect the privacy of dapps and their data and also how to efficiently control the execution of dapps. The first part of this Dev Letter is focusing on how to protect the execution of dapps and their result based on SGX.

By the way, iExec is invited to a discussion panel on this specific topic IBM Think on March 19–22, 2018 in Las Vegas.

Also we’ll present the latest developments of the project. We’ve updated the documentation and the resources about the iExec SDK, we added two new applications on the Dapp Store, and we’ll share the dapp example we’ve deployed during the live coding session we had at EthCC, actually inside the Conservatoire national des arts et métiers (a museum of technological innovation in Paris).

Protect DApp execution and its result.

Since applications are running on different distributed nodes over the networks, and are out of our control; We do not have full visibility whether the applications are correctly running. For example, malicious worker can modify the application, or halt the running application and fabricate a fake result (or copy a result distributed by a sybil attacker) to feed iExec scheduler.

In the SGX enabled iExec worker, the application is not triggered directly, the worker always call a loader which is encrypted and protected by SGX enclave, the loader is the only entrypoint for the worker to trigger the application.

Our SGX based solution allows solving these issues — namely, our solution is able to:

Make sure the CORRECT application on worker is running.

Make sure the application CORRECTLY EXECUTES, not tampered or interrupted by workers.

Make sure the result is VALID, neither copied, nor fabricated by workers.

Privacy of result (optional): Make sure the result is encrypted by user-provided key in enclave (i.e. not a fake key from malicious attacker), and the result can never be inspected by anyone else (e.g. including the worker and scheduler).

Impact of recent Meltdown Spectre attack on SGX

SGX is not impacted by Meltdown, however, Intel SGX enclaves are indeed vulnerable to the Spectre attack; but exploiting the chip-level vulnerabilities requires local access: a miscreant must be able to log in, and malware must be running in order to leverage the design blunder to attack an SGX enclave, etc. which is a barrier for the attackers.

iExec is also working with industrial partners to integrate the full protection against Spectre (variants 1 and 2) into our SGX solution.

Live Coding Session at EthCC

At the Ethereum Community Conference, François Branciard had a great Live Coding session with around 50 people in the room. He shown how to deploy an app on iExec. If you need more context, the general presentation of iExec is also available on Youtube.