iExec will be supporting Intel SGX (Secure Enclave) promising to allow for private software execution in the decentralized cloud

in #iexec7 years ago (edited)

The adoption of Intel SGX in my opinion offers a major competitive advantage over all other similar attempts in it's class to the iExec platform. Golem will not have this capability for quite a while and the only other platform which will have privacy of this nature is Enigma.

The benefit of hardware privacy at the CPU level

The benefit of this level of privacy is that you get the most bang for your buck. In other words you get the most potential privacy for the cheapest cost in terms of implementation, performance, and other measures. The benefits of using Intel SGX in my opinion far outweigh the risks. There of course has been the exposure of Intel CPUs being vulnerable to Meltdown and Spectre. These risks must be considered and because of this we can say Intel does not have the greatest track record currently. The vulnerabilities are based on a technique called "speculative execution" which by it's very name sounds in my opinion ridiculous.

Intel processors built since 1995 are reportedly affected by Meltdown, while Spectre affects devices running on Intel, AMD, and ARM processors. Meltdown is related to the way privileges can be escalated, while Spectre entails access to sensitive data that may be stored on the application’s memory space.

So how does this impact Intel SGX?

Intel SGX is vulnerable to Spectre and an attack has been demonstrated as successful in code. For this reason, it may be the case that Intel SGX is not sufficiently secure for all use cases. This could give the Enigma Protocol an edge over iExec in the fact that Enigma will provide the option to take security to a level beyond the limits of Intel SGX by using the SHE (somewhat homomorphic encryption) scheme they mention in the Enigma Whitepaper.

This quote in particular should be deeply understood:

The most important security finding currently available is that there is no credible engineering rationale to support the contention that SGX enclaves will provide confidentiality guarantees in the face of these new micro-architectural cache probing attacks. This is disappointing for a technology that was designed to provide security guarantees in the face of an IAGO threat model or in the previously described service provider models.

In summary:

  • Current Intel SGX offers limited security and cannot guarantee privacy due to the exploit/backdoor micro-architectural cache probing attacks.
  • Future Intel SGX may offer fixes to this which could make it secure but can we trust Intel? This is the variable which in my opinion creates the majority of the risk for using future iterations of Secure Enclave.
  • While Secure Enclave is a promising idea in theory the implementation which currently exists on the market is for sure vulnerable and should not be trusted. This means Enigma and iExec both are going to be vulnerable to whatever issues exist with Intel architectures and in my opinion both teams must seek to control the risks involved by offering additional security and privacy guarantees. At minimum, new hardware will likely need to be created and for this reason current expectations of privacy must realistically be low for either iExec or Enigma data in the early days until this gets resolved.

Conclusion

I'm still quite content with the progress being made by iExec. The Team is working to provide decentralized computation capabilities for decentralized apps. That said, I am not satisfied with Secure Enclave simply because it doesn't currently work to achieve confidentiality for data in motion based on the listed vulnerabilities discussed above. This means iExec will have to invest additional resources and conduct additional research to improve upon the security guarantees they try to achieve with Intel SGX.

References

  1. https://medium.com/iex-ec/iexec-dev-letter-14-intel-sgx-security-and-r-14-feb-2018-544d87e28869
  2. https://www.trendmicro.com/vinfo/us/security/news/vulnerabilities-and-exploits/meltdown-and-spectre-intel-processor-vulnerabilities-what-you-need-to-know
  3. https://idfusionllc.com/2018/01/25/sgx-after-spectre-and-meltdown-status-analysis-and-remediations/
Sort:  

🎉 Congrats 🍾

Top Trending Post Today in:

#iexec
#enigma
#cybersecurity
#crypto
#crypto-news

It is a success, you truly deserved. It is an achievement you have truly earned. Well Done.

One of the best investment opportunities in crypt asset! RLC! Watch and learn! ;-)

On progress! Still..

iExec relies on XtremWeb-HEP, a mature, solid, and open-source Desktop Grid software which implements all the needed features : fault-tolerance, multi-applications, multi-users, hybrid public/private infrastructure, deployment of virtual images, data management, security and accountability, and many more.

But not privacy of the data. All of that is fine but don't expect the computation to be anything secret or private.

Lei Zhang in my opinion is basing his choice on an assumption. That assumption is that Intel will get it's act together and release a future version of SGX which is not vulnerable to the current attacks which render the current versions of SGX insecure. So yeah of course it's a bet on Intel, but I think iExec needs a backup plan because it's not wise to pin all bets in one company.

I even tend to agree that sooner or later Intel will get SGX right, but this will be in a future chip which isn't released yet. iExec will not be able to guarantee data privacy with current SGX in my opinion.

Yes Exactly, I agree with that the real essence of cloud computing is to provide a decentralized network of computers around the world with remote users being able to leverage their resources or pay for them as part of the network.

informative!

Running processes with a secure VPN enabled makes hacks less likely, though for a truly determined and talented hacker, even that is not a complete guarantee, as occasionally connections to the VPN can drop for various reasons.

That said, I'll continue connecting via Proton VPN, until a better solution is presented.