eTEEreum: adapt SubstraTEE-worker for use with ethereum

[brenzi]

SubstraTEE-worker could be abstracted from substrate and used with ethereum. Working title: eTEEreum. This issue lists the main steps.

The substrate blockchain serves two purposes for substraTEE:

1. trusted registry of substraTEE-worker enclaves. IAS remote attestation is verified on-chain by all validators. This way, running a worker is unpermissioned. everyone with a SGX machine can join.
2. indirect transaction invocation: In M5, the requester sends opaque incognito transactions through the blockchain to the worker and gets on-chain receipts as confirmation.

Key Differences between chains

Differences substrate -> ethereum

• Ethereum does not provide the necessary tools to verify Intel IAS RA reports on-chain. this can be mitigated by having the client check the RA signatures
• crypto primitives
  • substrate supports sr25519/ed25519/secp256k1 so we're fine
  • blake2b/twoxx -> keccak256
• account encoding
  • ss58 -> hex (public -> keccak -> with checksum)
• RPC client implementations in Rust
  • substrate-api-client -> web3

expected difficulties

Without further investigation, I'd expect the following obstacles and cost-drivers:

• no_std support for ethereum-specific crates like rust-web3
• crypto primitives support within enclave: check if everything is already supported either with no_std or in rust-sgx-sdk forks (i.e. https://github.com/mesalock-linux/ring-sgx or https://github.com/mesalock-linux/rust-crypto-sgx

  Strategy

  In order to minimize maintenance for both SubstraTEE-worker and eTEEreum-worker we should start with refactoring the code to have better abstraction from the underlying chain. Then we can replace substrate-specific interfaces with ethereum ones.

Here are a few seleceted dependencies showing that our current architecture is very much entangled with substrate and needs some refactoring:

crypto primitives

substrate already features abstraction of ecc curve as well as hashes. It should be straight-forward to support ethereum primitives within substrate crate-forks (patching paritytech/substrate crates). I'd even expect parity to accept a PR with additional primitives support

See: https://github.com/paritytech/substrate/blob/0cfe7438b6cf2a2a3cb1f4ba98a83a17d3fe866c/core/primitives/src/crypto.rs#L570

tasks

The following tasks are a preliminary plan, TBD.

1. support ethereum crypto primitives with a fork of https://github.com/paritytech/substrate/blob/0cfe7438b6cf2a2a3cb1f4ba98a83a17d3fe866c/core/primitives/
2. fork substraTEE-worker
3. implement abstraction for substrate-api-client (i.e. chain_api-client), to be implemented either for substrate or ethereum. (introduce trait chain_interface?)
4. implement abstraction for everything coming from paritytech/substrate (except substrate-primitives, which will support ethereum primitives)
5. client code should verify RA reports

code pointers

enclave key generation

• https://github.com/scs/substraTEE-worker/blob/53398cb3270665e3b76bba908e8a12c0b9b6a7ee/enclave/src/lib.rs#L131
• https://github.com/scs/substraTEE-worker/blob/53398cb3270665e3b76bba908e8a12c0b9b6a7ee/enclave/src/lib.rs#L200

untrusted side key generation

• https://github.com/paritytech/substrate/blob/0cfe7438b6cf2a2a3cb1f4ba98a83a17d3fe866c/core/primitives/src/crypto.rs#L570
• https://github.com/scs/substraTEE-worker/blob/5ac1676d443944e03b2cf9384d540e36b3e6c7aa/client/src/lib.rs
• https://github.com/scs/substraTEE-worker/blob/53398cb3270665e3b76bba908e8a12c0b9b6a7ee/worker/src/main.rs#L198

creating extrinsics/transactions with substrate-api-client

• search for compose_extrinsic and compose_extrinsic_offline
• https://github.com/scs/substraTEE-worker/blob/5ac1676d443944e03b2cf9384d540e36b3e6c7aa/worker/src/enclave_wrappers.rs#L194

[electronix]

Does ethereum also provide the possibility to register to events and get the payload of such an event? This is currently the solution for substraTEE (indirect invocation), but could also be replaced with direct invocation (the client talks directly to the worker).

The separation and re-factoring of the substraTEE codebase may be a painful process. The current solution looks pretty much like an Italien pasta dish (see section Strategy) and a clear architecture must be established before starting the refactoring.

[brenzi]

@electronix Yes, the web3 library allows you to listen to events. About the refactoring: yes, there is architectural work to be done before jumping into the hacking.

[brenzi]

substrate now supports secp256k1 in master. some problems resolve themselves just like that ;-)