Skip to content

Latest commit

 

History

History
121 lines (105 loc) · 17.2 KB

M4_code_documentation.md

File metadata and controls

121 lines (105 loc) · 17.2 KB

Code Documentation for M4

This page describes the implemented functions of M4 with corresponding code references.

substraTEE-node

substraTEE-worker

Description of the functionality

The substraTEE-worker implements mainly the following functions:

  1. Instruct the enclave to generate a RSA3072 key pair which is used for encrypting the payload sent from the substraTEE-client to the substraTEE-worker. This is done with the command getpublickey.

    • Important: only the public key leaves the enclave while the private key stays in the enclave.
  2. Instruct the enclave to generate a ED25519 key pair which is used for signing the extrinsic sent from the substraTEE-worker to the substraTEE-node. This is done with the command getsignkey.

    • Important: only the public key leaves the enclave while the private key stays in the enclave.

With the worker command the following functions are executed in subsequent order:

  1. Get a remote attestation report from Intel and send the report as an extrinsic (computed in the enclave) to the substraTEE-registry that checks validity of the report and adds the worker to the set of registered workers.

  2. Upon successful registration it checks in the substraTEE-registry if more workers are registered. If yes, it performs mutual remote attestation with the first registered worker and fetches afterwards the RSA3072 key, the state encryption key and the state with a TLS connection.

  3. Subscribe to substraTEE-registry events, forward any received payload to the enclave and send a confirmation as an extrinsic (that is composed in the enclave) back to the substraTEE-node. All registered workers now compute redundantly the state updates. This part remains almost unchanged since M2.

Since M2, the substraTEE-worker compares the SHA256 hash of the WASM to be executed to the SHA256 hash given by the substraTEE-client. The code is executed only if the two hashes match - this gives the end user the confirmation and trust that the correct STF is executed.

Implementation

The functions are implemented at the following places:

Important: The functions defined in the enclave/Enclave.edl are the only entry points from the untrusted world to the trusted world inside the enclave. All arguments and return values need to be defined there.

Funtion 1: RSA3072 key pair generation

Function 2: ED25519 key pair generation

Same principle as Function 1 but starting at line 163 in the worker/src/enclave_wrappers.rs

Function 3: Perform remote attestation

Function 4: Mutual Remote Attestation

  • worker/src/main.rs:251: Query the node for the amount of registered workers.
  • worker/src/main.rs:261: If other workers are registered. Get a worker's information from the node in order to connect to it via a websocket.
  • worker/src/main.rs:265: Query the other worker for the port it has running the mutual remote attestation server.
  • worker/src/main.rs:269: Perform a mutual remote attestation with the other worker.
    • worker/src/enclave_tls_ra.rs: Setup a TCP connection and hand the socket into the enclave to perform the mutual remote attestation.
      • enclave/src/tls_ra.rs
        • Server (line #94) and client (line #161) both get a remote attestation report from Intel.
        • A TLS session is established. The rustls Server (line #62) and client (line #26) authentication procedure has been extended to automatically check the remote attestation report upon session establishment.
        • [MU-RA Server] Reads the keys from storage and sends them via TLS (line #112)
        • [MU-RA Server] Writes the encrypted state to an IPFS node through a call to the host system (line #141), which returns a CID (= a hash corresponding to an IPFS address).
        • [MU-RA Server] Sends the CID to the client (line #152).
        • [MU-RA Client] Reads the keys and the CID (line 183).
        • [MU-RA Client] Reads the encrypted state from the IPFS node through a call to the host system (line 265).

Function 5: Process encrypted payload from the substraTEE-node

substraTEE-client

The client is a sample implementation and only serves the purpose to demonstrate the functionalities of the substraTEE-node and substraTEE–worker. It implements the following sequence:

  • client/src/main.rs:70: The number of registered enclaves (or substraTEE-workers) is queried from the substraTEE-node
    • If (at least) one enclave is registered, the public key and the URL of the first substraTEE-worker is extracted
  • client/src/main.rs:97: The SHA256 hash of the WASM file is calculated. This is either the same file as the enclave is using or the user can specify a custom file.
  • client/src/main.rs:105: The free balance from //Alice is queried
  • client/src/main.rs:108: The current account nonce of //Alice is queried
  • client/src/main.rs:111: The account //Alice is funded with 1_000_000 units
  • client/src/main.rs:115: 1000 units are transferred from //Alice to the account of the enclave (identified by the public ED25519 key of the enclave)
  • client/src/main.rs:119: The public RSA3072 key of the enclave is requested from the substraTEE-worker
  • client/src/main.rs:131: An extrinsic with an encrypted payload (using the public RSA3072 key of the enclave) is composed
    • The payload contains the account (default //Alice), the increment (default 42) and the SHA256 hash of the WASM
  • client/src/main.rs:136: The extrinsic is sent to the substraTEE-node to the function “call_worker” of the substratee-registry module. The client waits for the confirmation that the transaction got finalized
  • client/src/main.rs:143: Use the substrate-api-client to subscribe to the event CallConfirmed of the substraTEE-node
  • client/src/main.rs:145: When the event was received, print out the calculated and the received hash of the (unencrypted) payload