Graphene-ng demo Part 2 and FAQs

We’ve said, presented and most importantly, developed quite a lot in regards to Graphene-ng. What we have yet to do is deep dive into every component of this outstanding solution to show how it can be used.

Graphene-ng, as mentioned in our last post, can be used to run arbitrary binaries in a trustworthy and privacy-preserving enclave. This means that any developer that needs to run (reasonably) secure and private computations, can use this framework for SGX enclave execution, without any app-specific tweaks. Our goal is to deliver a developer-friendly, robust tool. One that works (primarily) and that does not require significant overhead from other adopters.

This new video will explain more clearly, why we are developing this signature, and how it works.

In addition, we have gathered some FAQs you asked on social media and during DEVCON4 and answered in detail below :

Why use enclaves and not other solutions for security, confidentiality, and attestation?

Enclaves provide secure execution environments in which to run binaries. As Golem is a P2P marketplace for computing power, we need to ensure our users and the network, that the computations will be reasonably secure and trustworthy. We not only need to verify the computations will be correct, but also that the data won’t be compromised by the provider host or any possible attacks.

Our decision to focus on SGX, and subsequently develop Graphene-ng, comes after researching for a long time and consulting with experts on the matter (Joanna who now is part of Golem, announced Graphene-ng with her previous project, Invisible Things Lab, in collaboration with us).

Out of the existing TEEs, SGX is the most mature one and provides the best guarantees and efficiency (even though it is slower than native CPUs, it’s still very fast and may become even faster in a foreseeable future, when the EPC becomes bigger). Algorithmic solutions, such as homomorphic encryption are nowhere close efficiency-wise, let alone current implementations not necessarily being Turing-complete; so, SGX seems to provide the best tradeoffs between security requirements and the overhead (efficiency, ease of use and so on).

Is Golem basing its platform on SGX? Does this mean that Golem will only work on Intel processors?

No, Golem is not limited to SGX. This is an optional target hardware to be used with all the benefits and limitations of it. You can use Golem on any processor, but only Intel ones will run this technology.

If the users would like to use SGX, then they will need to use Intel’s CPUs, because this is an Intel hardware technology. However, our decentralized cloud computing platform is composed by CPUs and GPUs in general, and not limited to Intel. Due to the high percentage of existent Intel processors, choosing SGX gets us to a good security level. However, it is not necessary to have an Intel CPU to use Golem.

In addition, keep in mind that the requestors don’t need to have SGX on their machines at all: they access remote SGXs in the providers’ machines.

We are as well continuously researching, so we don’t discard the option of using other TEEs, as long as they are as feature-rich as the current SGX, and have the same or more security guarantees.

What does it take to use SGX in Golem? Does the user need to do anything?

Graphene-ng’s Golem integration is currently on the PoC (Proof-of-Concept) stage of development, meaning we need some more work to finish it. The PoC integration of Graphene-ng addresses two problems: “how to use SGX” and “how to run arbitrary binaries in enclaves”. We are also working on Graphene-ng as a product, as we always mention, which needs work on its stabilization, among other things.

From the requestors’ side, as mentioned, they won’t need to do anything to set this up. The requestors will need to access remotely. Providers will need to enable SGX on their machine (they may also need to be registered on Intel) but this is not something Golem-specific, but more regarding each providers’ hardware setup. Concerning user overhead, depending on the BIOS version they have, the user may need to do a one-time setup to enable SGX on their machine.

How do I know that my hardware is running Graphene-ng?

This will be pretty simple to spot in Golem, as shown in our demo, in the statuses. We are also planning to provide an in-app testing feature.

However, from the users’ standpoint, Graphene-ng is a regular Golem instance. The high-level explanation of this is that there is a Docker image which “automagically” — meaning via Graphene-ng — provides access to SGX and other additional features.

Why rely on Intel’s proprietary solutions if you are developing open-source software?

As Joanna mentioned on her presentation, the aspect we are working on as a community is to liberate the remote attestation, which would allow SGX to work in decentralized architectures, and to open-source it, in a way.

A simple explanation of this? The key (cert) which is used to verify that the signature was generated by an SGX enclave is kept by Intel, and this way only Intel can verify these signatures. This liberation would remove the dependency (there is no technical reason to keep this key secret). The second issue is keeping a list of untrusted enclaves (for whatever reasons) which is also Intel-specific. These are not hard requirements, and such lists and keys can be stored by anyone.

What would happen if the SGX code has bugs, as it happened a few months ago? Is Graphene-ng compromised?

We can provide a level of security up to the SGX guarantees, as we mention in our demo. Golem is not, nor can be, responsible for potential vulnerabilities in the SGX technology.

WithForeshadow (the last vulnerability) this attack is possible due to microcode optimizations, but fortunately, this also means that this attack can be mitigated by Intel. Nevertheless the above holds — in this scenario we’re only secure up to SGX guarantees.

Anything Graphene-ng specific is no less secure than SGX itself. Additionally, it has a clearly specified (and rather limited) attack surface, which means that programmers implementing integrations are less exposed to the security bugs that may show up when a programmer tries to implement her own interface between an enclave and the external world.

Is it the goal of Graphene-ng to allow SGX technology to be functional in a decentralized environment in the future?

Decentralized networks can benefit from SGX (and TEEs in general), in terms of security and confidentiality for their users. Graphene-ng allows users to run their binaries seamlessly in SGX. Obviously, this combination will bring great value for users in decentralized networks in the long term, given that all parts coordinate on the aspects that need improvement.

Please take a look, in case you haven’t, at our Graphene-ng demo where we explain how this technology works on the application level, with Golem and Blender as the example, but as we mentioned, this technology will be able to be used to run arbitrary binaries in other applications, as we have not tweaked anything to make it work in Golem.

If you have any new questions, please get in touch! We will be happy to keep expanding the Graphene-ng/ TEEs knowledge base for our community, by answering your questions!