EGo: Effortlessly build confidential apps in Go

We just unveiled our new open-source project EGo. EGo makes it super-easy to build, debug, and run Go apps in secure enclaves. In essence, all you need are the following three commands.

ego-go build myapp.go

ego sign myapp

ego run myapp

Awesome, huh? Ok, if you haven’t heard about confidential computing and secure enclaves before, you’re surely wondering what this is good for. Let’s take a look…

What are secure enclaves and why would I want to run my Go code in them?

Confidential computing is an emerging security paradigm. With it, data and code are protected inside secure enclaves at runtime. Enclaves protect against potentially compromised OSes, hypervisors, or even malicious cloud admins with hardware access.

Enclaves are created and enforced by the CPU. An enclave’s contents remain always encrypted in memory at runtime. Yes, correct, data and code remain always encrypted! This is one of the key features that make confidential computing so exciting for many, e.g., for Forbes.

In addition, enclaves have access to unique cryptographic keys, which can be used to store secrets on untrusted storage (“sealing”). it is possible to verify the integrity of an enclave and set up secure channels to it (“remote attestation”).

In one sentence: secure enclaves enable the always encrypted and verifiable execution of workloads in the cloud and elsewhere.

The most prominent enclave implementation to date is Intel SGX. SGX is available on many recent Intel-based systems. Several cloud vendors already have corresponding offerings.

Apart from unprecedented security, confidential computing enables new types of data-driven applications. The verification aspect is key here: users can verify precisely how data is processed, who provides the inputs, and who gets access to the results. For instance, this enables zero-trust data sharing, super-secure crypto wallets, and many other exciting things.

However, previously, developing confidential apps used to require arcane knowledge, significant code changes, and cumbersome build steps.

With EGo, this changes!

The easiest way to build confidential and cloud-native apps

With EGo, you can build and debug your Go code as you are used to. In essence, ego-go is a modified Go compiler that works just like the original go command. Apps built with ego-go run on all systems that normal Go apps run on — even if those systems are not SGX-enabled. Thus, EGo can be nicely integrated into your existing development and build processes.

Of course, at one point, you’ll certainly want to run your EGo app in an actual enclave. All you need for this is to

(1) sign it once via ego sign and

(2) run it via ego run.

Running your EGo app will work on any SGX-enabled Ubuntu 18.04 (support for 20.04 coming soon) system and potentially also other environments. If you tell ego sign that you want a debuggable enclave, you can even debug your app inside the enclave using ego-dbg and GDB-compatible IDEs like Visual Studion Code. Note that, probably unsurprisingly, debuggable enclaves are not secure.

In contrast to enclave SDKs for programming languages like C++ (e.g., Open Enclave) or Rust, EGo does not require you to split your app between enclave and non-enclave code. It simply keeps all of your data and code inside the enclave. We believe that this is the most intuitive and practical approach.

If you happen to don’t have an SGX machine at your disposal, you for example may just spin up a DCsv2-series VM on Azure and be ready to go. (Alternatively, you may also run in a simulated enclave by setting the OE_SIMULATION=1 environment variable.)

So what is a good app to start with?

Well, essentially any Go app that handles sensitive data like cryptographic keys or personal data benefits from the greatly increased security provided by EGo and confidential computing.

An example of a minimal app that makes meaningful use of confidential computing features is a web server that gets a remote-attestation report for its TLS certificate. You can find such an app in the EGo GitHub repository here. The interesting code parts are shown below:

The code first creates a TLS certificate and private key. It then uses EGo’s enclave library to get a remote-attestation report for the certificate (line 12). And that is basically it. The code then uses the standard http library to set up an HTTPS server with the certificate and makes its certificate and the corresponding report available under “/cert” and “/report” for clients to download and verify. A sample client can be found here.

Note that in EGo, TLS connections terminate inside enclaves. Thus the OS etc. cannot mess with the traffic except for denial-of-service.

Interested in more real world apps? Take a look at our HashiCorp Vault example GitHub here.

What does it mean to verify a remote-attestation report?

Ok, we’ve talked quite a bit about remote-attestation reports already, without having actually explained what they are.

Simplifying a bit, you can think of remote-attestation report as an ECDSA signature over an enclave’s initial data and code, its configuration, and some app-provided data. The signature comes from the SGX-enabled CPU. Each CPU has its own ECDSA private key and corresponding X.509 certificate. The certificate is issued by Intel. (The remote attestation scheme described here is called DCAP.)

In the case of the example above, the app-provided data is the web server’s TLS certificate. A web client would get the report over an untrusted connection and validate it via VerifyRemoteReport() in EGo’s client library. The function will validate the certificate chain from the CPU to Intel etc.

In case the report is valid. The function returns the following info about the remote enclave:

The client would now do the following:

• Check if report.Data matches the server’s TLS certificate.
• Check if UniqueID is the expected value.

UniqueID is a cryptographic hash over the enclave’s initial data and code and its configuration. You can get the UniqueID of an enclave app by simply running the following after building and signing:

ego uniqueid <enclave app>

A simple client would just have the expected UniqueID of the server hardcoded.

In the end, the client knows precisely (1) that it is talking to the expected server software with certain functionality; (2) that the server runs in a secure enclave; and (3) that the server has a certain TLS certificate. The client can now trust the TLS connection to the server and send over sensitive data.

You can’t have that without confidential computing! And without EGo it’s going to be rather tricky :-)

Now how does this fit into my existing cloud-native infrastructure?

Glad you asked! At Edgeless Systems, we believe that cloud-native and confidential computing are destined for each other and will increasingly grow together. In fact, our primary motivation for EGo was to be able to use existing cloud-native technology in our confidential-computing projects.

However, distributing and scaling confidential cloud-native apps brings a range of new and interesting challenges, for example:

• How does a client verify a whole confidential Kubernetes cluster?
• How do pods verify each other and talk securely enclave-to-enclave?

To address these and many more, we recently released our open-source project Marblerun. We call Marblerun “the service mesh for confidential computing”. Marblerun runs alongside your normal service mesh on Kubernetes and takes care of all things confidential computing. To learn more about Marblerun, check out this recent blog post.

Marblerun has native support for EGo-based apps and we will discuss this in more detail in one of our next posts. Also, there’ll be a talk and Q&A on EGo and Marblerun at the free Open Confidential Computing Conference on March 11. See you there!

Summary

To summarize, EGo comes with the following key features:

• Super secure: All your data and code are kept inside the secure enclaves at runtime. No need to partition your app.
• Easy to use: Start by lifting & shifting your existing Go code without changing a line. Use the EGo runtime library to effortlessly access SGX-specific features.
• Easy to scale: Our other tool Marblerun (“the service mesh for confidential computing”) has native support for EGo-based microservices and makes it easy to scale them securely on Kubernetes.
• Built on industry standards: EGo builds upon the industry standard Open Enclave. This makes it future-proof and portable to other hardware platforms. EGo also supports the latest DCAP attestation protocol.
• Runs everywhere: Don’t have SGX-enabled hardware? No problem, EGo apps run in simulation mode on any host. Also, many cloud providers already offer SGX-enabled VMs.
• Lightweight: EGo does not try to simulate a full POSIX environment in your enclave. It just loads as much code as necessary for the Go runtime to work well, keeping the trusted computing base (TCB) small.