Announcements
Author:

Fleek Network Update: Intel SGX Integration

The Fleek Foundation is excited to announce that the core protocol team has successfully integrated Intel SGX capabilities into Fleek Network. Below is an overview of the SGX integration, as well as a breakdown of the technical architecture including spotlights on features like Remote Attestation and Edge-Optimization that make this SGX service unique, performant, and more developer-friendly than most existing SGX alternatives.

Overview

The Fleek SGX service allows you to utilize Intel SGX TEE (Trusted Execution Environments) for private and secure compute. Similar to how Fleek’s Javascript service functions, you can provide this service with a program to be run for you in a decentralized, serverless environment. But with the addition of Intel SGX, you can also provide encrypted data that can only be decrypted from inside your program while running inside the TEE.

This encrypted data can not be decrypted by anyone, even the node that gets your request cannot read or decrypt it. Currently, we support WASM in the execution environment with additional support coming soon - for now, any code that compiles to WASM is supported.  Our SGX service is verifiable via remote attestations, and any node runner that alters their enclave's code will no longer be able to decrypt data even from within their TEE.

TLDR:

  • Fleek Network’s alpha SGX service is now available.
  • Developers can leverage Intel SGX’s TEEs (Trusted Execution Environments) for private and secure, decentralized compute.
  • Uses Intel SGX DCAP ECDSA Remote Attestations to verify enclave-to-enclave communication.
  • This is just an alpha preview of the service, not the final version of the enclave. We highly recommend testing this feature, but avoid using it in production builds at this time.
  • Over the next few weeks, expect to see full open-source of our enclave → enclave remote attestations, libraries you can use to do remote attestations from your websites or applications on SGX enclaves, and a Ra-TLS library written in Rust.

Technical details

SGX & TEEs: How the encryption works

Typically when you want to save private data from an enclave, you do a process called “Sealing” the data. Sealing is done with a key known as the Sealing key that is only available inside the enclave.

After data is sealed it can then be sent to untrusted userspace or elsewhere to be saved. The data can then only ever be used inside the enclave that sealed it. You would use a similar process if you wanted to send private data into an enclave, where you would encrypt it with the public key of that Private Sealing Key before sending it to the enclave. Even if the data is intercepted or has to pass through untrusted userspace, it would be useless until it is inside the Enclave with the corresponding Sealing key.

sgxdiagram1

With that in mind, we decided to take things a step further: since a sealing key is unique to a specific instance of an Intel SGX CPU, your data would have to be encrypted individually for every node in our network. Otherwise, only one node would be able to handle your requests, and if that node were to go offline, you would need to redo the entire process, including re-uploading the data with new encryption to a different node.

To solve this, the first node that joins our network uses private data in its enclave to generate a “Shared Sealing Key”. That node's enclave will share this key, through a secure connection, with any other Intel enclave that it can verify is a trusted Intel SGX, and additionally is running the same program in its enclave (via a remote attestation- more on this below).

We know this program has no code paths to leak this key, and if we can verify the SGX TCB we don't have to worry about the memory being read.

sgxdiagram2

After this exchange, we end up with a very similar flow to the way you would seal data but now all of our nodes have the same Sealing key. Data only has to be encrypted once--and it can be decrypted inside any node’s SGX enclave in our network.

Additionally, since everything on Fleek Network is content addressable, we also include the hash of your WASM program with the encrypted data before encrypting it. Our enclave will only decrypt the data if the hash matches the program that was requested to run. This is to prevent someone from uploading another WASM program that takes your decrypted secrets and sends them out in plain text.

Remote attestation

We use Intel SGX DCAP ECDSA Attestations to verify enclave-to-enclave communications. You can read more about DCAP here or here. This verification is also integrated into mTLS communications between nodes, so once they are verified by each other, we have a secure channel to send messages between the enclaves.

Doing enclave-to-enclave communications this way was outlined by Intel in this paper if you would like to take a deeper dive. But the TLDR is:

  1. We append the data to our TLS Cert that is needed to do the remote attestation
  2. We then make a mutual TLS connection

Meaning certificate verification and encryption are done by both parties in the exchange, but the connection is only trusted and used if the remote attestation is successful and they are running the same program.

Using the service

Using Fleek’s Edge SGX service is simple and follows a similar process to our Javascript service:

  1. Get the Fleek CLI

  2. Run this command to auth your CLI tool:

fleek login
  1. Run this command to deploy:
fleek functions deploy --name Myfunction --path my.wasm --sgx
  1. You can invoke this function at https://fleek-test.network/services/3 with a payload containing hash, inputs, and whether its encrypted or not (always yes with the current tool), and any inputs you need:
curl fleek-test.network/services/3 --data '{"hash": "<hash>", "decrypt": true, "input": "foo"}'

SGX Kit

Development toolkit for building wasm modules on the Fleek Network SGX Service.

Examples

Example WASM binaries can be compiled like so:

# Build hello wasm
cargo build -r --example sgx-wasm-hello --target wasm32-unknown-unknown

# Or do the same with the echo example
cargo build -r --example sgx-wasm-echo --target wasm32-unknown-unknown

Loading data onto the node

The resulting binaries can then be uploaded to IPFS and cached on a node:

fleek storage add target/wasm32-unknown-unknown/release/examples/sgx-wasm-hello.wasm
curl fleek-test.network/services/0/ipfs/<CID>

The SGX service only supports raw blake3 hashes at this time. To get the hash of the cached WASM file, you can use the 'b3sum' utility:

b3sum target/wasm32-unknown-unknown/release/examples/sgx-wasm-hello.wasm

Calling the SGX service directly

The WASM can then be called on the service like so:

curl fleek-test.network/services/3 --data '{"hash": "<b3sum hash>", "decrypt": true, "input": "foo"}'

Private wasm modules

The WASM can also be encrypted/sealed for the enclave before uploading. Using sgxencrypt:

sgxencrypt --pubkey <network seal pk> target/wasm32-unknown-unknown/release/examples/sgx-wasm-hello.wasm -o hello.wasm.cipher
fleek storage add hello.wasm.cipher

The service will decrypt with a request like so:

curl fleek-test.network/services/3 --data '{"hash": "<b3sum hash>", "input": "foo"}'

Important Notes/FAQs

Anything you deploy on the alpha preview of the SGX service will not work and needs to be re-uploaded after we move from alpha.

This is an alpha preview of the service, not the final version of the enclave.

To be clear, this does not change the aforementioned security assumptions — we do not and will never have access to the Private Sealing Key. This means that when we move out of Alpha, we will have a new Public Sealing Key and the network will not be able to decrypt anything you encrypted with the Seal Key during this Alpha release.

We highly recommend that you test this feature, share what you build, and reach out to the team on Discord with any questions or help needed. At this time, we suggest you avoid using it in production builds until we deploy the longstanding, permanent release in a few weeks.

Upcoming

We will be diligently working to get this service out of alpha, but here are things you can expect over the next few weeks:

  • Full open-source of our enclave → enclave remote attestations and Ra-TLS library
    • Written in Rust
  • We learned that doing remote attestations can be pretty tricky-- so we will also be releasing some libraries you can use to do remote attestations from your websites or applications on SGX enclaves.

As Fleek Network continues to deliver decentralized, high-performance cloud infrastructure and web services, the integration of Intel SGX processors and Trusted Execution Environments is key to enabling secure, scalable, and privacy-preserving applications within the network.

We invite developers to join the alpha and start exploring the possibilities with SGX on Fleek Network. You can learn more about getting started here, or within our docs.

Stay tuned for more updates and get involved by joining our Discord Server or following Fleek Network on X.

⚡Fleek Foundation ⚡