The goal of attestation is to convince a third party that a specific piece of code is running on a genuine Intel SGX HW.
A user that interacts with substraTEE wants to be sure that the shielding pubkey she uses to encrypt her call to the STF originates form an enclave that
- is running on genuine Intel SGX HW
- runs the official code
- accesses the correct STF state
The standard use case for remote attestation involves a service provider (SP) like a video streaming service which wants to be sure his viewer application runs on a genuine SGX HW and respects DRM. The SP therefore requests a quote from the application and sends that quote to Intel Attestation Services (IAS) who sign off the quote if it is genuine.
The issue here is that IAS only talks to registered clients. You need to register in order to get a SPID which needs to be supplied along with requests.
It isn't practical to ask every client to register with Intel and perform RA before every request. Therefore we'd rather let the substraTEE-worker operators attest their enclaves with IAS and write the signed quote and their certificate to the blockchain for everyone to verify.
This does change the the attestation protocol. Now the SP and the enclave in the above scheme are both running on the same machine. substraTEE-worker will itself perform an attestation protocol with its enclave and get the quote signed by IAS. Like this, only substraTEE operators need to register with IAS.
The attestation report which is written to an on-chain registry contains:
- enclave quote
- report body
- MRENCLAVE (hash of enclave build)
- Product ID (hard-coded in substraTEE source)
- Security Version (hard-coded in substraTEE source)
- user data is hash of context:
- enclave-individual signing pubkey
- latest block hash
- ...
- report body
- IAS response
- body
- status (OK||CONFIGURATION_NEEDED|GROUP_REVOKED....)
- timestamp
- enclave quote
- ...
- IAS certificate
- IAS signature over above body
- body
Any user can now verify IAS signature and MRENCLAVE (given the substraTEE enclave can be built deterministically). See the example how you can extract MRENCLAVE after building the enclave
The worker can now publish his sealing pubkey, signed with its enclave-individual signing key stated in the quote.
workers will repeat remote attestation in reasonable regular intervals (i.e. once per month)
In order for the chain validator to be able to verify MRENCLAVE, there must be a consensus about MRENCLAVE of the valid version of substraTEE.
substraTEE developers will propose code updates to be voted on. Validators check the code and vote on behalf or against each proposal. MRENCLAVE can be reproduced by cloning the substraTEE-worker repo, building it and then:
sgx_sign dump -enclave enclave.signed.so -dumpfile out.log
TODO: we might need to provide a docker environment the achieve deterministic builds.
In order to establish shared secrets among workers, they need to convince themselves mutually that they are genuine before entering some Distributed Key Generation (DKG) protocol.
provisioned secrets are sealed with Intel's SGX Sealing. Two different kinds of sealing exist. MRENCLAVE is unique for each build and each piece of HW. MRSIGNER is based on the authority of a SW vendor. The latter is practical for proprietary software because vendors can update their SW without re-provisioning secrets.
However, for decentralized open source projects, MRSIGNER cannot apply as there is no authority that could sign builds.
Therefore, enclave identity MRSIGNER must be applied.
As SW updates will have a different measurement, the new build can't read the state that was encrypted by the old build. Local attestation allows the new version to request the provisioned secrets.
We assume reproducible builds for enclaves which should be possible with Rust subject to some assumptions. For now, watch this issue and cargo-repro.
Simplified Protocol
- new version's TCB hash gets voted for by onchain consensus
- new version registers its attestation on-chain
- old version shares provisioned secret with new version running on same machine by means of local (intra-platform) attestation if new version's tcb corresponds to onchain registry
Intel defines different modes for running enclaves.
compilation modes: Debug, Release, Pre-Release, Simulation lanching modes: Debug, Production
Enhanced Privacy ID (EPID). A group signature key known only to the quoting enclave. Only used for remote attestation.
A Service Provider ID (SPID) is needed to talk to IAS. Developers can obtain their SPID by registering with Intel (only allows to attest DEBUG encalves!)
You can request either linkable or unlinkable quote.
tl;dr: selecting UNLINKABLE is a safe choice. But don't expect to be anonymous.
In both cases, the quoting enclave uses a group signature for a quote. You can just decide if you wish two subsequent signatures to be linkable (an observer learns "quote was signed by same platform") or not.
In any case, Intel can identify YOU by SSID as you use your SSID for remote attestation with IAS. It just doesn't learn about which HW platform the quote originates from.
Due to Intel policy, developers can only compile enclaves in Debug, Pre-Release or Simulation mode. This means that the enclave will always be launched in Debug mode which doesn't provide confidentiality as enclave memory isn't encrypted.
In order to compile enclaves in Release mode (and run them in Production mode), the SW vendor has to apply for a SGX production license. Moreover, remote attestation in production mode can only be taken out with such production license.
SCS is looking into options how to apply such policy to a decentralized system with Intel.
solution candidate
- A set of companies (i.e. SCS, web3 foundation) register a production license with Intel
- substraTEE-workers send their RA quotes to the chain.
- the company listens to new RA quotes and sends them to IAS with the company's SPID.
- the company sends the IAS report to the chain.
chaotic list of pointers: