Substrate runtime in SGX enclave

[brenzi]

Grant Application

This application is (select one):

• Speculative (use this by default)
• an RFP response

This application is (select one):

• Public (fully)
• Public with private finances

Abstract

SCS suggests an extension to substrate allowing to call the runtime modules inside an Intel SGX enclave. This would allow modules to read and modify an encrypted state that can't be accessed outside a set of provisioned enclaves. The application also includes the implementation of an enclave provisioning procedure allowing to modify the set of enabled enclaves dynamically.

Use cases demanding transaction privacy could be implemented on substrate with this extension.

Checklist

• The grants document has been read and understood.
• The Google Form will be completed accurately. Note that the Google Form requires the pull request URL.
• Abstract (above) is succinct and complete.
• The application is being included into the correct directory: either 'targeted' or 'speculative'.
• The application includes a project description.
• The application includes all names of team members.
• The application includes a description of the team's experience.
• The application includes all necessary GitHub and LinkedIn links.
• The application specifies the development language and the reason for choosing it.
• The "Development Roadmap" section in the application has a timeline of development.
• The "Development Roadmap" section in the application has an estimate of funds required.
• The "Development Roadmap" section gives an indication of the team's long term plans.

[burdges]

I'm extremely dubious about using this for privacy, but several use cases exist, including bridges, so sounds reasonable.

We should review the attacks on SGX like FORESHADOW to see if they benefit from being inside an enclave. Assuming so, we should keep access completely under the node operator's control, meaning parachains that use this would interact differently with polkadot's shared security model. In this case, we should be extra careful about anything unaudited like smart contracts running in an enclave.

[brenzi]

edit: this statement is not correct according to Intel (see below

@burdges I need to do more research on FORESHADOW myself. It does concern me in the case of unpermissioned blockchains as we can't be sure validators are patched (adversaries would run unpatched SGX). Use cases might be restricted to permissioned chains running validators on patched systems because we can't allow anyone to join the validator set if SGX remote attestation is broken by FORESHADOW. However, I'm wondering if we can leverage secure boot to make sure a remote party is running on a patched system.

[burdges]

I'm no expert in this area but I doubt patching completely fixes anything, simply because they vulnerabilities run so deep, and the patches are a combined effort across microcode, os, and applications, which sounds fragile. It's still better than nothing for applications like bridges. Instead, I think the primary defense comes through node specialization, which complicates on-chain upgrades, but hey.

[brenzi]

I'd like to adjust my statement above. I was pointed to a thread and an issue where Intel states about IAS:

The CONFIGURATION_NEEDED status is returned under two separate conditions:
An EPID has been provisioned to the platform and sealed against the most recent Trusted Computing Base (TCB) specification for the platform but hyper-threading is enabled.
The platform has not been provisioned against the current platform TCB (GROUP_OUT_OF_DATE) and the platform does not have the security sensitive BIOS microcode update applied.

So IAS (API V3) can actually tell if hyperthreading is enabled and the latest microcode is active.

My fear that remote attestation may not work for unpermissioned chains seems incorrect. All the better. But of course, it is a race against time....