iExec Dev Letter #14: Intel® SGX Security and R— 14 Feb 2018
Hello everyone! While the last Dev Letter is only a few days old, we would like to already share a new one with you. We received many questions concerning security on the iExec infrastructure, and while there are many layers of security to take into account such as our Proof-of-Contribution, we wanted to focus this week’s Dev Letter on the Intel® SGX technology. In the present article, we’ll explain how does Intel® SGX protect the privacy of dapps and efficiently control their execution. We’ll also end this Dev Letter by announcing the addition of a new application to the iExec DApp Store.
What Is Intel® SGX?
Intel processor technologies provide unique capabilities that can improve the privacy, security, and scalability of distributed ledger networks.
Intel® SGX (Software Guard Extensions) is a set of CPU instruction codes from Intel that allows user-level code to allocate private regions of memory, called enclaves, which are protected from processes running at higher privilege levels. It means that even higher privileged systems — such as root, kernel or hypervisor — cannot access the application running inside an enclave.
It is an Intel’s recent security technology which is based on Intel CPUs since the Skylake architecture (autumn 2015). Intel® SGX employs security mechanisms which are based on the CPU key which is fused inside the CPU during production.
It is just like a top classified secret sealed in the heart of the CPU hardware, and no one is able to inspect this key including the manufacturer Intel. This key is used to protect applications running inside an enclave. The security brought by Intel® SGX technology is therefore guaranteed at the hardware level, which leaves very small attack interface for malicious hackers.
Due to this great feature, Intel® SGX makes it possible for the first time to use Intel CPUs to protect an application running on a remote system. SGX is more and more used to guarantee the security of executing cloud applications.
Secret Provisioning 🔒
You can find a detailed presentation of Intel® SGX here[1]. Let me introduce you briefly one of the most important features of Intel® SGX : secret provisioning. This feature is very interesting and the protection of the iExec distributed applications will mainly be based on this feature.
Basically, when an Intel® SGX application is triggered on a remote node, an enclave is generated, and a remote entity (e.g. client, user who deploys the Intel® SGX application) can verify the validity of the enclave via remote attestation to make sure the remote application enclave is the expected one, and is neither modified nor replaced by a malicious attacker.
After this verification, the remote entity may provision some secrets to this Intel® SGX enclave. Typically, secret provisioning is conducted through a very secure channel. The secure channel is established between the remote entity and the enclave, and the communication between them is encrypted by the Intel® SGX enclave key that is generated randomly based on CPU key. This enclave key is never exposed outside of enclave scope, and thus no one else is able to inspect this key to decrypt the secrets during communications.
Our Intel® SGX implementation is currently based on SCONE[2] — Secure Linux Containers with Intel Intel® SGX.
In the following section, we introduce how Intel® SGX technology can be integrated to the iExec platform to protect applications; and we conclude in section 3.
How Does Intel® SGX Protect iExec Applications?
In distributed cloud computing, iExec dapps can be distributed in different remote nodes across networks and are not managed by a centralized cloud service provider who can offer the necessary centralized control security tools to protect the applications, such as firewalls or encryption mechanisms. How to protect these applications residing/running on distributed systems is becoming a big challenge.
On the iExec platform, we need a novel mechanism that is able to:
- Protect the privacy of dapps and their data
- Efficiently control the execution of dapps
- Protect the execution of dapps and their result
Why is Intel® SGX an ideal solution to solve the above issues? Because Intel® SGX can offer a highly secure bubble (Intel® SGX enclave) which is totally isolated from the untrusted system. When your application runs in this bubble, it is encrypted and protected by a classified key derived from the CPU key. Even the higher-privileged root, kernel or hypervisor is not able to invade into this bubble.
In this article, we will firstly show you how Intel® SGX can be used in the iExec platform to solve the first two issues. We will detail the solution to the third issue in a future technical article.
Protect the privacy of dapps and their data
In distributed cloud computing, protection of an application and its sensitive data is essential. For example, the application may need to access third-party data services with its privacy token to retrieve data which feeds the app calculation. It’s not a problem if the application runs at local side or on a centralized cloud where the cloud manager can encrypt the privacy token and take charge of the security issues. However, if it is running on an untrusted distributed system, the application and its sensitive data are exposed to all the distributed nodes across the network.
Our proposal based on Intel® SGX allows encrypting the application and/or data (e.g. token/key allowing the application to access data services) before deploying them over networks, and the encryption key can be transferred to an Intel® SGX enclave via a highly secure channel to decrypt the application and/or data at run time. This way, no one across the network is able to inspect the application/data because the application/data is encrypted, and the decryption is done inside the Intel® SGX enclave which is protected by the secret key derived from the CPU, and no one is able to inspect the decrypted data neither.
For example, let’s say we have an application which allows predicting stock variations in the upcoming 3 months. When the application starts running, it will firstly access a financial data server with its privacy token to retrieve financial data. The privacy token is stored in a key file, and this key file cannot be built directly inside the application because it increases the dependency and it is just not secure. If we encrypt the token with another key, the problem is how to securely distribute this key to thousands of distributed nodes at runtime?
This is how Intel® SGX can help us on this point. With Intel® SGX, we can encrypt this key file (i.e. stores token), and when the application starts running at a remote node (i.e. even on a untrust node without any protection), the application creates a secure Intel® SGX enclave and the decryption key is transferred to the enclave via the secure channel automatically, and then the token which is used to access the data service can be decrypted in the enclave at runtime.
This way, application and data (e.g. token/key allowing apps to access data service) can be encrypted before being deployed over networks (i.e. iExec DApp Store, Docker Hub, etc.), and no one is able to inspect them but a selected enclave.
Efficiently control the execution of dapps
Application execution can also be fully controlled, as it is like a licensing control: everyone can download the app, but only the authorized ones can decrypt the app and execute it.
In the above section, we introduced the Secret Provision, namely that the application and/or data can be initially encrypted. As soon as the secure channel is established at runtime between a remote entity and the enclave, the remote entity can then send the decrypt key to the enclave to decrypt the application for it to correctly run.
This remote entity can be the iExec scheduler of a given worker pool, and the establishment of the enclave channel is totally under its control; the secured channels are only established with the authorized nodes (i.e. iExec inscribed workers), so the decrypt key can only be sent to the iExec inscribed workers to decrypt and run the application, and no one else is able to execute the app.
Our Intel® SGX implementation is currently based on SCONE — a Secure Linux Containers with Intel® SGX, and we will show you more details of our implementation in a future technical article.
Conclusion
In this Dev Letter, we briefly presented you the Intel® SGX technology and how it can be employed in the iExec ecosystem to protect distributed cloud applications running on remote workers.
“This solution is currently considered as an option to our security extension, because this solution must be based on the Intel® SGX hardware support on iExec workers (i.e. Intel CPU since Skylake series — after autumn 2015); and we believe that SGX-enabled machines will be much more largely deployed in the near future. iExec is the pioneer to employ this promising Intel® SGX technology in blockchain-based cloud computing”, explains Lei Zhang, Cryptography Expert at iExec.
Lei has also made a video detailing a PoC he conducted on Intel® SGX to protect iExec applications. You may watch this video below:
In the future technical article, we will show you our Intel® SGX implementation, and how Intel® SGX can be used in our platform to protect application execution and its results: namely how we can make sure that the correct application on worker is running; and that the application correctly executes, not interfered or interrupted by workers; and make sure the result is valid, neither copied nor fabricated by workers; and how to protect the privacy of results.
A New Addition to the iExec DApp Store: R
Whether measured by more than 10,000 add-on packages, the 95,000+ members of LinkedIn’s R group or the more than 400 R meetup groups currently in existence, there can be little doubt that interest in the R statistics language, especially for data analysis, is soaring [3].
Why R? It’s free, open source, powerful and highly extensible. These reasons led our developers to work an implementation of R on top of iExec. Thanks to our recent support for Docker containers, R is now one more application available on the iExec DApp Store.
You can try it out and let us now what you think. We have a #beta-testers channel on our Slack where we can answer your questions and feedback.
Other Interesting News and Achievements
January has been a month of many surprises. Here’s a short summary of our recent achievements:
- iExec now supports Docker and Blender for 3D rendering.
- iExec partnered with Stimergy and Cloud&Heat to provide greener computing solutions.
- iExec joined the OpenFog Consortium, which was founded by ARM, Cisco, Dell, Intel and Microsoft. The consortium’s aim is to accelerate the deployment of fog computing technologies that will support intelligence at the edge of IoT.
- RLC tokens can be traded on Binance, Bitfinex, Bancor, Godex and BestRate.
- RLC tokens can now also be stored on the Exodus wallet.
- We’ve started a series of short regular updates on the progress made by the iExec team. Here’s the last one, you may subscribe to r/iexec to not miss the upcoming ones.
- You’re also invited to join our 2 Telegram groups.
That’s it for this Dev Letter. Credits to our cryptography expert Lei Zhang for his explanations on Intel® SGX. Stay tuned for the next one as we still have exciting news to share with you! 🚀
[1] The Intel® Software Guard Extensions (Intel® SGX) Developer Guide: https://software.intel.com/en-us/documentation/sgx-developer-guide
[2] SCONE: https://sconecontainers.github.io/
[3] Beginner’s Guide to R: Introduction, by Sharon Machlis (AUG 18, 2017)
