diff --git a/DockerfileM5 b/DockerfileM5 new file mode 100644 index 0000000..f246078 --- /dev/null +++ b/DockerfileM5 @@ -0,0 +1,136 @@ +# BSD License +# +# Copyright (C) 2017-2018 Baidu, Inc. All Rights Reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Baidu, Inc., nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +# +# Copyright 2019 Supercomputing Systems AG + +FROM ubuntu:18.04 +MAINTAINER Yu Ding + +ENV sdk_bin https://download.01.org/intel-sgx/linux-2.5/ubuntu18.04-server/sgx_linux_x64_sdk_2.5.100.49891.bin +ENV psw_deb https://download.01.org/intel-sgx/linux-2.5/ubuntu18.04-server/libsgx-enclave-common_2.5.101.50123-bionic1_amd64.deb +ENV psw_dev_deb https://download.01.org/intel-sgx/linux-2.5/ubuntu18.04-server/libsgx-enclave-common-dev_2.5.101.50123-bionic1_amd64.deb +ENV psw_dbgsym_deb https://download.01.org/intel-sgx/linux-2.5/ubuntu18.04-server/libsgx-enclave-common-dbgsym_2.5.101.50123-bionic1_amd64.ddeb +ENV substratee_node https://github.com/scs/substraTEE-node/archive/M5.zip +ENV substratee_worker https://github.com/scs/substraTEE-worker/archive/M5.zip +ENV rust_toolchain nightly +ENV DEBIAN_FRONTEND=noninteractive +ENV TERM xterm + +SHELL ["/bin/bash", "-c"] + +# prepare the linux system +RUN apt-get update && \ + apt-get install -y build-essential ocaml ocamlbuild automake autoconf \ + libtool wget python libssl-dev libcurl4-openssl-dev protobuf-compiler \ + libprotobuf-dev sudo kmod vim curl git-core libprotobuf-c0-dev \ + libboost-thread-dev libboost-system-dev liblog4cpp5-dev libjsoncpp-dev \ + alien uuid-dev libxml2-dev cmake pkg-config expect systemd-sysv gdb unzip \ + clang libclang-dev rsync && \ + rm -rf /var/lib/apt/lists/* && \ + rm -rf /var/cache/apt/archives/* + +# install the Intel SGX PSW and SDK +RUN mkdir /root/sgx && \ + mkdir /etc/init && \ + wget -O /root/sgx/psw.deb ${psw_deb} && \ + wget -O /root/sgx/psw_dev.deb ${psw_dev_deb} && \ + wget -O /root/sgx/psw_dbgsym.deb ${psw_dbgsym_deb} && \ + wget -O /root/sgx/sdk.bin ${sdk_bin} && \ + cd /root/sgx && \ + dpkg -i /root/sgx/psw.deb && \ + dpkg -i /root/sgx/psw_dev.deb && \ + dpkg -i /root/sgx/psw_dbgsym.deb && \ + chmod +x /root/sgx/sdk.bin && \ + echo -e 'no\n/opt' | /root/sgx/sdk.bin && \ + echo 'source /opt/sgxsdk/environment' >> /root/.bashrc && \ + rm -rf /root/sgx/* + +# installing rust-sgx-sdk +RUN wget 'https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init' -O /root/rustup-init && \ + chmod +x /root/rustup-init && \ + echo '1' | /root/rustup-init --default-toolchain ${rust_toolchain} && \ + echo 'source /root/.cargo/env' >> /root/.bashrc && \ + /root/.cargo/bin/rustup component add rust-src && \ + /root/.cargo/bin/cargo install xargo && \ + rm -rf /root/.cargo/registry && rm -rf /root/.cargo/git + +# downloading and extracting the substraTEE components +RUN mkdir /substraTEE && \ + wget -O /substraTEE/substraTEE-node.zip ${substratee_node} && \ + wget -O /substraTEE/substraTEE-worker.zip ${substratee_worker} && \ + cd /substraTEE && \ + unzip substraTEE-node.zip && \ + mv substraTEE-node-M5 substraTEE-node && \ + unzip substraTEE-worker.zip && \ + mv substraTEE-worker-M5 substraTEE-worker && \ + rm substraTEE-*.zip + +# install the needed nightly version of rust and the wasm32 for the default toolchain +# FIXME: synchronize and fix the used version (see below) +RUN /root/.cargo/bin/rustup install nightly-2019-08-01 && \ + /root/.cargo/bin/rustup default nightly-2019-08-01 && \ + /root/.cargo/bin/rustup target add wasm32-unknown-unknown + +# init the rust environment +RUN source /opt/sgxsdk/environment && \ + source /root/.cargo/env && \ + /substraTEE/substraTEE-node/scripts/init.sh + +# build the substraTEE-node +RUN source /opt/sgxsdk/environment && \ + source /root/.cargo/env && \ + cd /substraTEE/substraTEE-node && \ + cargo build --release + +# build the substraTEE-worker +# the substratee-worker (or more precisly, the rust-sgx-sdk compiles only with nightly-2019-08-01) +RUN source /opt/sgxsdk/environment && \ + source /root/.cargo/env && \ + /root/.cargo/bin/rustup default nightly && \ + /root/.cargo/bin/rustup target add wasm32-unknown-unknown && \ + cd /substraTEE/substraTEE-worker && \ + /root/.cargo/bin/rustup override set nightly-2019-08-01 && \ + make + +# copy the shell scripts to the docker to launch to node and the workers +COPY scriptsM5/* /substraTEE/ + +# copy the certificates for the RA +COPY intel_cert/* /substraTEE/substraTEE-worker/bin/ + +# install ipfs +RUN mkdir /ipfs && \ + cd ipfs && \ + wget -O go-ipfs.tar.gz https://dist.ipfs.io/go-ipfs/v0.4.21/go-ipfs_v0.4.21_linux-amd64.tar.gz && \ + tar xvfz go-ipfs.tar.gz && \ + cd go-ipfs && \ + ./install.sh + +WORKDIR /substraTEE diff --git a/M1_DEMO.md b/M1_DEMO.md new file mode 100644 index 0000000..5346499 --- /dev/null +++ b/M1_DEMO.md @@ -0,0 +1,174 @@ +### M1 PoC1: single-TEE confidential state transition function +The following requirements are needed to run the M1 demo: +* Docker installed +* Active internet connection + +To build and execute the code, follow these instructions: +1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: + ``` + $ git clone https://github.com/scs/substraTEE.git + ``` +2. Build the docker image: + ``` + $ docker build -t substratee -f DockerfileM1 . + ``` + This may take some time (~2h on a recent MacBook), so grab a cup of :coffee: or :tea: - or two. +3. Start the docker image and get an interactive shell: + ``` + $ docker run -v $(pwd):/substraTEE/backup -ti substratee + ``` + The `-v $(pwd):/substraTEE/backup` is used to save the files generated by the enclave for later use and can also be omitted. + + If you are in a PowerShell on Windows, replace the `$(pwd)` with `${PWD}`. +4. Start the development substraTEE-node in the background and log the output in a file: + ``` + root@:/substraTEE# /substraTEE/substraTEE-node-M1/target/release/substratee-node --dev > node.log 2>&1 & + ``` + The node now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/node.log`. +5. Start the substraTEE-worker and generate the keys: + ``` + root@:/substraTEE# cd /substraTEE/substraTEE-worker-M1 + root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker getpublickey + root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker getsignkey + ``` + This will generate the sealed (= encrypted) RSA3072 keypair (`./bin/rsa3072_key_sealed.bin`), the sealed ED25519 keypair (`./bin/ed25519_key_sealed.bin`) and the unencrypted public keys (`./bin/rsa_pubkey.txt` and `./bin/ecc_pubkey.txt`). The sealed keypairs can only be decrypted by your specific SGX enclave. +6. Start the substraTEE-worker in the background and log the output in a file: + ``` + root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker worker > /substraTEE/worker.log 2>&1 & + ``` + The worker now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/worker.log`. +7. Start the substraTEE-client to send an extrinsic to the substraTEE-node that is then forwarded and processed by the substraTEE-worker (incrementing a counter): + ``` + root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_client | tee /substraTEE/client.log + ``` + The output of the client is also logged to the file `/substraTEE/client.log` and can be inspected by `less /substraTEE/client.log`. + + You will see on the last lines of the output the two hashes of the transaction (expected and actual). These should match indicating that all commands were processed successfully. + ``` + Expected Hash: [...] + Actual Hash: [...] + ``` +8. Query the counter from the substraTEE-worker: + ``` + root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_client getcounter | tee /substraTEE/counter.log + ``` + +Whenever you perform the steps 7. and 8., you will see the counter incrementing. + +#### IMPORTANT +If you exit the container (`exit`), you will loose the sealed counter state and the generated keys. + +To backup the files: +``` +root@:/substraTEE# cp /substraTEE/substraTEE-worker-M1/bin/*.txt /substraTEE/backup/ +root@:/substraTEE# cp /substraTEE/substraTEE-worker-M1/bin/*.bin /substraTEE/backup/ +``` + +To restore the files: +``` +root@:/substraTEE# cp /substraTEE/backup/*.txt /substraTEE/substraTEE-worker-M1/bin/ +root@:/substraTEE# cp /substraTEE/backup/*.bin /substraTEE/substraTEE-worker-M1/bin/ +``` + +#### Enabling Debug output +To enable debug output, call the substraTEE-worker or the substraTEE-client with the following command, respectivly: `RUST_LOG=debug ./bin/substratee_client`. + +### M2 PoC2: single-TEE confidential state transition function in WASM +The following requirements are needed to run the M2 demo: +* Docker installed +* Active internet connection + +The main principle is the same as M1. The big difference is that the code that implements the business logic (in our case, incrementing a counter) is stored as WASM code. When starting the client (step 8), we tell the worker the SHA256 hash of the WASM that we want to execute. If the desired and the computed hashes don't match, the STF must not be executed. This ensures that we know which code was executed in the SGX enclave. + +To build and execute the code, follow these instructions: +1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: + ```shell + $ git clone https://github.com/scs/substraTEE.git + ``` + +2. Build the docker image: + ```shell + $ docker build -t substratee -f DockerfileM2 . + ``` + This may take some time (~2h on a recent MacBook), so grab a cup of :coffee: or :tea: - or two. + +3. Start the docker image and get an interactive shell: + ```shell + $ docker run -v $(pwd):/substraTEE/backup -ti substratee + ``` + The `-v $(pwd):/substraTEE/backup` is used to save the files generated by the enclave for later use and can also be omitted. + + If you are in a PowerShell on Windows, replace the `$(pwd)` with `${PWD}`. + +4. Start the development substraTEE-node in the background and log the output in a file: + ```shell + root@:/substraTEE# /substraTEE/substraTEE-node-M1/target/release/substratee-node --dev > node.log 2>&1 & + ``` + The node now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/node.log`. + +5. Start the substraTEE-worker and generate the keys: + ```shell + root@:/substraTEE# cd /substraTEE/substraTEE-worker-M2 + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getpublickey + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getsignkey + ``` + This will generate the sealed (= encrypted) RSA3072 keypair (`./bin/rsa3072_key_sealed.bin`), the sealed ED25519 keypair (`./bin/ed25519_key_sealed.bin`) and the unencrypted public keys (`./bin/rsa_pubkey.txt` and `./bin/ecc_pubkey.txt`). The sealed keypairs can only be decrypted by your specific SGX enclave. + +6. Start the substraTEE-worker in the background and log the output in a file: + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker worker > /substraTEE/worker.log 2>&1 & + ``` + The worker now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/worker.log`. + +7. Get the SHA256 hash of the WASM module: + ```shell + root@:/substraTEE/substraTEE-worker-M2# sha256sum ./bin/worker_enclave.compact.wasm + ``` + This will output something like the following, where the actual values may be different: + ```shell + d7331d5344a99696a8135212475e2c6b605cea88e9edd594773181205dda1531 ./bin/worker_enclave.compact.wasm + ``` + The first long number is the SHA256 hash of the WASM code. Copy this value (in the example case `d733...1531`) into the clipboard (Control-C). + +8. Start the substraTEE-client to send an extrinsic to the substraTEE-node that is then forwarded and processed by the substraTEE-worker. The code to increment the counter comes from the WASM file (`bin/worker_enclave.compact.wasm`). The user provides the hash of the code he wants to execute. + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client --sha256wasm | tee /substraTEE/client.log + ``` + The output of the client is also logged to the file `/substraTEE/client.log` and can be inspected by `less /substraTEE/client.log`. + + You will see on the last lines of the output the two hashes of the transaction (expected and actual). These should match indicating that all commands were processed successfully. + ```shell + Expected Hash: [...] + Actual Hash: [...] + ``` + +9. Query the counter from the substraTEE-worker: + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client getcounter | tee /substraTEE/counter.log + ``` + After the first iteration, the counter of Alice will have the value 52. This is correct as the following code is executed in the WASMI in the enclave: `new = old + increment + 10` (see `substraTEE-worker/enclave/wasm/src/lib.rs`). + +10. Check the output of the substraTEE-worker by calling `less /substraTEE/worker.log`. The most important section is (near the end) + ``` + [>] Decrypt and process the payload + ... + [Enclave] SHA256 of WASM code identical + ... + [<] Message decoded and processed in the enclave + ``` + which indicates that the SHA256 hash passed by the client matches the calculated hash of the code that should be executed. + +11. When sending a different hash from the substraTEE-client to the substraTEE-worker, the code will not be executed and the counter therefore not updated. + + The client will wait infinitely for the callConfirmed event which will never be sent by the worker as the code was not executed. The client must be killed (Control-C) and the log file of the worker can be inspected with `less /substraTEE/worker.log`. At the end of the log file there is a different output than before + ``` + [>] Decrypt and process the payload + ... + [Enclave] SHA256 of WASM code not matching + [Enclave] Wanted by client : [...] + [Enclave] Calculated by worker: [...] + [Enclave] Returning ERROR_UNEXPECTED and not updating STF + ``` + which indicates that the SHA256 hash passed by the client **DOES NOT** match the calculated hash of the code that should be executed. + +Whenever you perform the steps 8. and 9., you will see the counter incrementing. \ No newline at end of file diff --git a/M2_DEMO.md b/M2_DEMO.md new file mode 100644 index 0000000..ac45c53 --- /dev/null +++ b/M2_DEMO.md @@ -0,0 +1,99 @@ +### M2 PoC2: single-TEE confidential state transition function in WASM +The following requirements are needed to run the M2 demo: +* Docker installed +* Active internet connection + +The main principle is the same as M1. The big difference is that the code that implements the business logic (in our case, incrementing a counter) is stored as WASM code. When starting the client (step 8), we tell the worker the SHA256 hash of the WASM that we want to execute. If the desired and the computed hashes don't match, the STF must not be executed. This ensures that we know which code was executed in the SGX enclave. + +To build and execute the code, follow these instructions: +1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: + ```shell + $ git clone https://github.com/scs/substraTEE.git + ``` + +2. Build the docker image: + ```shell + $ docker build -t substratee -f DockerfileM2 . + ``` + This may take some time (~2h on a recent MacBook), so grab a cup of :coffee: or :tea: - or two. + +3. Start the docker image and get an interactive shell: + ```shell + $ docker run -v $(pwd):/substraTEE/backup -ti substratee + ``` + The `-v $(pwd):/substraTEE/backup` is used to save the files generated by the enclave for later use and can also be omitted. + + If you are in a PowerShell on Windows, replace the `$(pwd)` with `${PWD}`. + +4. Start the development substraTEE-node in the background and log the output in a file: + ```shell + root@:/substraTEE# /substraTEE/substraTEE-node-M1/target/release/substratee-node --dev > node.log 2>&1 & + ``` + The node now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/node.log`. + +5. Start the substraTEE-worker and generate the keys: + ```shell + root@:/substraTEE# cd /substraTEE/substraTEE-worker-M2 + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getpublickey + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getsignkey + ``` + This will generate the sealed (= encrypted) RSA3072 keypair (`./bin/rsa3072_key_sealed.bin`), the sealed ED25519 keypair (`./bin/ed25519_key_sealed.bin`) and the unencrypted public keys (`./bin/rsa_pubkey.txt` and `./bin/ecc_pubkey.txt`). The sealed keypairs can only be decrypted by your specific SGX enclave. + +6. Start the substraTEE-worker in the background and log the output in a file: + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker worker > /substraTEE/worker.log 2>&1 & + ``` + The worker now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/worker.log`. + +7. Get the SHA256 hash of the WASM module: + ```shell + root@:/substraTEE/substraTEE-worker-M2# sha256sum ./bin/worker_enclave.compact.wasm + ``` + This will output something like the following, where the actual values may be different: + ```shell + d7331d5344a99696a8135212475e2c6b605cea88e9edd594773181205dda1531 ./bin/worker_enclave.compact.wasm + ``` + The first long number is the SHA256 hash of the WASM code. Copy this value (in the example case `d733...1531`) into the clipboard (Control-C). + +8. Start the substraTEE-client to send an extrinsic to the substraTEE-node that is then forwarded and processed by the substraTEE-worker. The code to increment the counter comes from the WASM file (`bin/worker_enclave.compact.wasm`). The user provides the hash of the code he wants to execute. + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client --sha256wasm | tee /substraTEE/client.log + ``` + The output of the client is also logged to the file `/substraTEE/client.log` and can be inspected by `less /substraTEE/client.log`. + + You will see on the last lines of the output the two hashes of the transaction (expected and actual). These should match indicating that all commands were processed successfully. + ```shell + Expected Hash: [...] + Actual Hash: [...] + ``` + +9. Query the counter from the substraTEE-worker: + ```shell + root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client getcounter | tee /substraTEE/counter.log + ``` + After the first iteration, the counter of Alice will have the value 52. This is correct as the following code is executed in the WASMI in the enclave: `new = old + increment + 10` (see `substraTEE-worker/enclave/wasm/src/lib.rs`). + +10. Check the output of the substraTEE-worker by calling `less /substraTEE/worker.log`. The most important section is (near the end) + ``` + [>] Decrypt and process the payload + ... + [Enclave] SHA256 of WASM code identical + ... + [<] Message decoded and processed in the enclave + ``` + which indicates that the SHA256 hash passed by the client matches the calculated hash of the code that should be executed. + +11. When sending a different hash from the substraTEE-client to the substraTEE-worker, the code will not be executed and the counter therefore not updated. + + The client will wait infinitely for the callConfirmed event which will never be sent by the worker as the code was not executed. The client must be killed (Control-C) and the log file of the worker can be inspected with `less /substraTEE/worker.log`. At the end of the log file there is a different output than before + ``` + [>] Decrypt and process the payload + ... + [Enclave] SHA256 of WASM code not matching + [Enclave] Wanted by client : [...] + [Enclave] Calculated by worker: [...] + [Enclave] Returning ERROR_UNEXPECTED and not updating STF + ``` + which indicates that the SHA256 hash passed by the client **DOES NOT** match the calculated hash of the code that should be executed. + +Whenever you perform the steps 8. and 9., you will see the counter incrementing. \ No newline at end of file diff --git a/M4_DEMO.md b/M4_DEMO.md new file mode 100644 index 0000000..3b035ab --- /dev/null +++ b/M4_DEMO.md @@ -0,0 +1,52 @@ +### M4 Redundancy and Secret Provisioning +The M4 demo differs from the proposed architecture in the following points: +- There is only one docker image that contains the substraTEE-node, the substraTEE-worker and the substraTEE-client (named _substratee_) +- There will be 4 docker containers running the following components: + - Docker container 1: substraTEE-node + - Docker container 2: substraTEE-client + - Docker container 3: substraTEE-worker 1 + - Docker container 4: substraTEE-worker 2 +- The substraTEE-node has only one module (called substratee-registry module) that includes all the required functionality +- The substraTEE-client not only talks to the substraTEE-node, but also communicates directly with the substraTEE-worker (in order to get the shielding key) +- The encrypted state is exchanged between the two substraTEE-workers by the use of IPFS (https://ipfs.io) + +The following requirements are needed to run the M4 demo: +* Intel SGX installed, enabled and working (see https://github.com/intel/linux-sgx) +* Intel account information for Remote Attestion. These files (`key.txt` and `spid.txt`) must be placed in the folder `intel_cert` +* Docker installed +* Tmux installed +* Active internet connection + +To build and execute the code, follow these instructions: +1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: + ```shell + $ git clone https://github.com/scs/substraTEE.git + $ git checkout M4 + ``` +2. Execute the shell script to build the docker image and start the containers: + ```shell + $ cd substraTEE + $ ./M4.sh + ``` + +The script performs the following steps: +1. Clone the `rust-sgx-sdk` repository into the direcotry `rust-sgx-sdk` as this is needed to execute the code in the docker containers. +2. Build the docker iamge `substratee` based on the `DockerfileM4` (setup Ubuntu 18.04, install the Intel SGX Linux SDK and drivers, compile the substraTEE components, installs IPFS, copy the required file to the Docker image). +3. Create a docker network so that the 4 containers can communicate with each other. +4. Setup a tmux session with 4 panes running the corresponding docker containers (see following screenshot): + - Upper left: substraTEE-node + - Upper right: substraTEE-client + - Lower left: substraTEE-worker 1 + - Lower right: substraTEE-worker 2 + +![Diagram](./substraTEE-M4.png) + +#### Flow of the demo +- The **substraTEE-node** is started immediately in development mode and begins to generate blocks. +- The **substraTEE-worker 1** is started 3 seconds after the substraTEE-node and registers it's enclave at the substraTEE-node. +- The **substraTEE-client** is started 30 seconds after the substraTEE-node and performs a first transaction. As only one worker is registered, the substraTEE-worker 1 performs the state transition function. +- The **substraTEE-worker 2** is started 60 seconds after the substraTEE-node and registers it's enclave at the substraTEE-node. It detects that another enclave is already registered, performs a mutual remote attestation (MU-RA), exchanges the state encryption key and the encrypted state (over IPFS). At this point, two enclaves are registerd in the substraTEE-node. +- The **substraTEE-client** performs another transaction 30 seconds after the first. There are now two enclaves registered and both react on the transaction and calculate the new state. +- The **substraTEE-client** queries finally the counter from one of the workers which verifies the signature. + +After the demo has run, the local directory `./output` contains the log files of the different components. \ No newline at end of file diff --git a/M5.sh b/M5.sh new file mode 100755 index 0000000..5a29abe --- /dev/null +++ b/M5.sh @@ -0,0 +1,87 @@ +#!/bin/bash + +# clone the rust-sgx-sdk (used to run the substratee-worker in the docker) +git clone https://github.com/baidu/rust-sgx-sdk.git + +# prepare the docker image +docker build -t substratee -f DockerfileM5 . + +# prepare the docker specific network +docker network rm substratee-net +docker network create --subnet 192.168.10.0/24 substratee-net + +# prepare the output log directory +mkdir -p output + +# start the tmux session +SESSION=substraTEEM5Demo +tmux has-session -t $SESSION + +if [ $? != 0 ] +then + tmux -2 new -d -s $SESSION -n "substraTEE M5 Demo" + + # create a window split by 4 + tmux split-window -v + tmux split-window -h + tmux select-pane -t 1 -T "pane 1" + tmux split-window -h + + # enable pane titles + tmux set -g pane-border-status top + + # set length of left status to 50 + tmux set -g status-left-length 50 + + # color the panes + tmux select-pane -t 1 -P 'fg=colour073' # node + tmux select-pane -t 2 -P 'fg=colour011' # client + tmux select-pane -t 3 -P 'fg=colour043' # worker 1 + tmux select-pane -t 4 -P 'fg=colour083' # worker 2 + + + # start the substratee-node in pane 1 + tmux send-keys -t1 "docker run -ti \ + --ip=192.168.10.10 \ + --network=substratee-net \ + -v $(pwd)/output:/substraTEE/output \ + -v /home/marcel/substraTEE-worker:/substraTEE/worker_local \ + substratee \ + \"/substraTEE/start_node.sh\"" Enter + + # start the substratee-worker 1 in pane 3 + tmux send-keys -t3 "docker run -ti \ + --ip=192.168.10.21 \ + --network=substratee-net \ + --device /dev/isgx \ + -v $(pwd)/output:/substraTEE/output \ + -v $(pwd)/rust-sgx-sdk:/root/sgx \ + -v /var/run/aesmd:/var/run/aesmd \ + -v /home/marcel/substraTEE-worker:/substraTEE/worker_local \ + substratee \ + \"/substraTEE/start_worker1.sh\"" Enter + + # start the substratee-worker 2 in pane 4 + tmux send-keys -t4 "docker run -ti \ + --ip=192.168.10.22 \ + --network=substratee-net \ + --device /dev/isgx \ + -v $(pwd)/output:/substraTEE/output \ + -v $(pwd)/rust-sgx-sdk:/root/sgx \ + -v /var/run/aesmd:/var/run/aesmd \ + -v /home/marcel/substraTEE-worker:/substraTEE/worker_local \ + substratee \ + \"/substraTEE/start_worker2.sh\"" Enter + + # start the substratee-client in pane 2 + tmux send-keys -t2 "docker run -ti \ + --ip=192.168.10.30 \ + --network=substratee-net \ + -v $(pwd)/output:/substraTEE/output \ + -v /home/marcel/substraTEE-worker:/substraTEE/worker_local \ + substratee \ + \"/substraTEE/start_client.sh\"" Enter +fi + +# Attach to session +tmux attach -t $SESSION diff --git a/M5_DEMO.md b/M5_DEMO.md new file mode 100644 index 0000000..5601932 --- /dev/null +++ b/M5_DEMO.md @@ -0,0 +1,94 @@ +# M5 Private-tx demo +## with docker on any hardware +``` +./M5.sh +``` + +## on SGX hardware +To run a demo for private tokens (without docker containers) do the following: + +Assumptions: +* your machine has SGX support +* Intel SGX SDK installed. +* rust toolchain is ready to build substrate + +in terminal 1 run a substraTEE-node +``` +git clone https://github.com/scs/substraTEE-node +cd substraTEE-node +git checkout tags/M5 +cargo build --release +./target/release/substratee-node --dev --ws-port 9979 --rpc-port 9969 +``` + +in terminal 2, run the worker +``` +git clone https://github.com/scs/substraTEE-worker +cd substraTEE-worker +git checkout tags/M5 +make +cd bin +RUST_LOG=info ./substratee_worker -p 9979 worker +``` + +in terminal 3, run the client +``` +cd substraTEE-worker/bin +./substratee_client --node-ws-port 9979 +``` + +Then you should see this in terminal 3: +``` +*** Getting the amount of the registered workers +[<] Found 1 workers + +[>] Getting the first worker's from the substraTEE-node +[<] Got first worker's coordinates: + W1's public key : "5Gkzji8EtE1hTjVzTmZXWqrs6sqcHcbCooGqVH7iRRuxdnar" + W1's url: "127.0.0.1:2000" + +[>] Get the shielding key from W1 (=5Gkzji8EtE1hTjVzTmZXWqrs6sqcHcbCooGqVH7iRRuxdnar) +[<] Got worker shielding key Rsa3072KeyPair: { n:CF67550FB00AB959A76219EA35188B360380037123FCAA77B683A791A1F980331F9D9E11D04C7F5FB3B63787F8AAB579FDFFE1DCE79A29B6ACED2628635C8463965D5D839BD58072AA77B8CAE124E40562955FE9936DAE2976CD57B41A2DE89EEDBF9DA77C155365E8BB45DCA1E0EC3B32604D9489712762BE63B3D1F04801D796887F70115BFDD440450A04BFE81DEE7BE718F56F766E6B0C2D9DE270583C4DFBA64FD59B4DE39C07977F1FD2956588DDBF73987EECB5BB303AF2115C4E72879C5EC69B7CD5C00DAEF9F9B062B40ADA16984C574246C8AB882A79D2E1C2F597C1017FBA69D7449BAD85ADE822D92A775DB1766F21C886E762C3E260390B72C82515F1D48FD190059B419C639E3688BCC2070E9CDB6BDDD49202B7296EA2AB01EA2D3AC2990C5078446582A4C03194BBF8D7E557B4503FF4645C053D7288398C79781F642F3A8D399195E6D2E6F74B434791D881BC97BAA0F0B228BD031C40E357BC61644E68CC40F3E08BDCBBD92E306FA9353FAEA05FDCBFCF4729FECC008C, e:01000001 } + +[+] Alice's Incognito Pubkey: 5Dt1Wg85pXGLstt36t6TDdvXXoCtG6zkUL17KkyVaPYSrzGH + +[+] Bob's Incognito Pubkey: 5GTTq4EnvMk4oTXYJp2kqTd2T9hbnARuee5awLiKFKsxWgRy + +[+] pre-funding Alice's Incognito account (ROOT call) +[+] Subscribed, waiting for event... + +[+] Received confirm call from 5Gkzji8EtE1hTjVzTmZXWqrs6sqcHcbCooGqVH7iRRuxdnar +[+] query Alice's Incognito account balance + got getter response from worker: Ok("State is 1000000") +[+] query Bob's Incognito account balance + got getter response from worker: Ok("State is 0") + +*** incognito transfer from Alice to Bob + +[+] Subscribed, waiting for event... + +[+] Received confirm call from 5Gkzji8EtE1hTjVzTmZXWqrs6sqcHcbCooGqVH7iRRuxdnar +[+] query Alice's Incognito account balance + got getter response from worker: Ok("State is 900000") +[+] query Bob's Incognito account balance + got getter response from worker: Ok("State is 100000") + +``` + +### So, what happens here? + +Alice wants to transfer 100k tokens privately to Bob. She doesn't use her substraTEE-node account for this as the transfer would be publicly visible. + +Instead, she creates an *incognito* account and she keeps her account secret (also the public key). This account will never hit the substraTEE-node blockchain transparently. + +The *Demo God* then gives Alice some initial Balance of 1M. + +Bob also creates an *incognito* account and tells Alice (and only her) his public key. + +Alice now uses SubstraTEE's *shielded transaction* feature to send 100k to Bob. + +### under the hood + +TODO: +* block diagram +* sequence diagram \ No newline at end of file diff --git a/README.md b/README.md index cea1a39..fabec9d 100755 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ *substraTEE* enables use cases demanding transaction privacy as well as atomic cross-chain transfers (bridges). ![vision](./substraTEE-vision.png) -*SubstraTEE Target Architecture with Direct Invocation* +*SubstraTEE Target Architecture with Direct Invocation (future scenario)* What substraTEE aims to provide: @@ -77,7 +77,7 @@ Since M5, the STF is modular and has its own crate which can easily be swapped. * testnet for stress-tests and showcasing * use cases: bridges, payment hubs, ... -## Overview M1 +## Indirect Invocation (M1-M5) The high level architecture of the current implementation can be seen in the following diagram: @@ -88,10 +88,9 @@ The main building blocks can be found in the following repositories: * [substraTEE-node](https://github.com/scs/substraTEE-node): (custom substrate node) A substrate node with a custom runtime module * [substraTEE-worker](https://github.com/scs/substraTEE-worker): (client, worker-app, worker-enclave): A SGX-enabled service that performs a confidential state-transition-function -## Overview M2 -The architecture of M2 corresponds with M1. The main difference is that the STF (block *update state* in the figure above) is WASM code which is executed inside the enclave. +## Redundancy (M3-M5) +The goal of redundancy is to allow multiple workers to operate on the same state to be resilient against outage of one or more workers. -## Overview M3 and M4 The high level architecture of the proposed architecture for M3 and M4 can be seen in the following diagram: ![Diagram](./substraTEE-architecture-M4.svg) @@ -119,6 +118,12 @@ The exchange of critical information between the enclaves is performed over a se This repo hosts docker files to showcase the milestones. +The following demos are available: + * [M1 Demo](./M1_DEMO.md) Private Counter + * [M2 Demo](./M2_DEMO.md) Private Counter in WASM + * [M4 Demo](./M4_DEMO.md) Redundancy with Private Counter + * [M5 Demo](./M5_DEMO.md) Private Transactions + #### Enabling SGX HW support The demos are by default compiled for [Simulation Mode](https://software.intel.com/en-us/blogs/2016/05/30/usage-of-simulation-mode-in-sgx-enhanced-application) meaning that you don't need an actual SGX platform to run the example. This is specified in the `DockerfileM*` on line 99 (`SGX_MODE=SW make`). If you are on a platform that supports the SGX, you can enable HW support by: * Installing the Intel SGX Driver 2.5 and make sure that `/dev/isgx` appears @@ -142,233 +147,7 @@ If you run the Hardware Mode on a platform that does not support SGX, you get th [2019-05-15T05:15:03Z ERROR substratee_worker::enclave_wrappers] [-] Init Enclave Failed SGX_ERROR_NO_DEVICE! ``` -### M1 PoC1: single-TEE confidential state transition function -The following requirements are needed to run the M1 demo: -* Docker installed -* Active internet connection - -To build and execute the code, follow these instructions: -1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: - ``` - $ git clone https://github.com/scs/substraTEE.git - ``` -2. Build the docker image: - ``` - $ docker build -t substratee -f DockerfileM1 . - ``` - This may take some time (~2h on a recent MacBook), so grab a cup of :coffee: or :tea: - or two. -3. Start the docker image and get an interactive shell: - ``` - $ docker run -v $(pwd):/substraTEE/backup -ti substratee - ``` - The `-v $(pwd):/substraTEE/backup` is used to save the files generated by the enclave for later use and can also be omitted. - - If you are in a PowerShell on Windows, replace the `$(pwd)` with `${PWD}`. -4. Start the development substraTEE-node in the background and log the output in a file: - ``` - root@:/substraTEE# /substraTEE/substraTEE-node-M1/target/release/substratee-node --dev > node.log 2>&1 & - ``` - The node now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/node.log`. -5. Start the substraTEE-worker and generate the keys: - ``` - root@:/substraTEE# cd /substraTEE/substraTEE-worker-M1 - root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker getpublickey - root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker getsignkey - ``` - This will generate the sealed (= encrypted) RSA3072 keypair (`./bin/rsa3072_key_sealed.bin`), the sealed ED25519 keypair (`./bin/ed25519_key_sealed.bin`) and the unencrypted public keys (`./bin/rsa_pubkey.txt` and `./bin/ecc_pubkey.txt`). The sealed keypairs can only be decrypted by your specific SGX enclave. -6. Start the substraTEE-worker in the background and log the output in a file: - ``` - root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_worker worker > /substraTEE/worker.log 2>&1 & - ``` - The worker now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/worker.log`. -7. Start the substraTEE-client to send an extrinsic to the substraTEE-node that is then forwarded and processed by the substraTEE-worker (incrementing a counter): - ``` - root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_client | tee /substraTEE/client.log - ``` - The output of the client is also logged to the file `/substraTEE/client.log` and can be inspected by `less /substraTEE/client.log`. - - You will see on the last lines of the output the two hashes of the transaction (expected and actual). These should match indicating that all commands were processed successfully. - ``` - Expected Hash: [...] - Actual Hash: [...] - ``` -8. Query the counter from the substraTEE-worker: - ``` - root@:/substraTEE/substraTEE-worker-M1# ./bin/substratee_client getcounter | tee /substraTEE/counter.log - ``` - -Whenever you perform the steps 7. and 8., you will see the counter incrementing. - -#### IMPORTANT -If you exit the container (`exit`), you will loose the sealed counter state and the generated keys. - -To backup the files: -``` -root@:/substraTEE# cp /substraTEE/substraTEE-worker-M1/bin/*.txt /substraTEE/backup/ -root@:/substraTEE# cp /substraTEE/substraTEE-worker-M1/bin/*.bin /substraTEE/backup/ -``` - -To restore the files: -``` -root@:/substraTEE# cp /substraTEE/backup/*.txt /substraTEE/substraTEE-worker-M1/bin/ -root@:/substraTEE# cp /substraTEE/backup/*.bin /substraTEE/substraTEE-worker-M1/bin/ -``` - -#### Enabling Debug output -To enable debug output, call the substraTEE-worker or the substraTEE-client with the following command, respectivly: `RUST_LOG=debug ./bin/substratee_client`. -### M2 PoC2: single-TEE confidential state transition function in WASM -The following requirements are needed to run the M2 demo: -* Docker installed -* Active internet connection - -The main principle is the same as M1. The big difference is that the code that implements the business logic (in our case, incrementing a counter) is stored as WASM code. When starting the client (step 8), we tell the worker the SHA256 hash of the WASM that we want to execute. If the desired and the computed hashes don't match, the STF must not be executed. This ensures that we know which code was executed in the SGX enclave. - -To build and execute the code, follow these instructions: -1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: - ```shell - $ git clone https://github.com/scs/substraTEE.git - ``` - -2. Build the docker image: - ```shell - $ docker build -t substratee -f DockerfileM2 . - ``` - This may take some time (~2h on a recent MacBook), so grab a cup of :coffee: or :tea: - or two. - -3. Start the docker image and get an interactive shell: - ```shell - $ docker run -v $(pwd):/substraTEE/backup -ti substratee - ``` - The `-v $(pwd):/substraTEE/backup` is used to save the files generated by the enclave for later use and can also be omitted. - - If you are in a PowerShell on Windows, replace the `$(pwd)` with `${PWD}`. - -4. Start the development substraTEE-node in the background and log the output in a file: - ```shell - root@:/substraTEE# /substraTEE/substraTEE-node-M1/target/release/substratee-node --dev > node.log 2>&1 & - ``` - The node now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/node.log`. - -5. Start the substraTEE-worker and generate the keys: - ```shell - root@:/substraTEE# cd /substraTEE/substraTEE-worker-M2 - root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getpublickey - root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker getsignkey - ``` - This will generate the sealed (= encrypted) RSA3072 keypair (`./bin/rsa3072_key_sealed.bin`), the sealed ED25519 keypair (`./bin/ed25519_key_sealed.bin`) and the unencrypted public keys (`./bin/rsa_pubkey.txt` and `./bin/ecc_pubkey.txt`). The sealed keypairs can only be decrypted by your specific SGX enclave. - -6. Start the substraTEE-worker in the background and log the output in a file: - ```shell - root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_worker worker > /substraTEE/worker.log 2>&1 & - ``` - The worker now runs in the background and the output can be inspected by calling: `tail -f /substraTEE/worker.log`. - -7. Get the SHA256 hash of the WASM module: - ```shell - root@:/substraTEE/substraTEE-worker-M2# sha256sum ./bin/worker_enclave.compact.wasm - ``` - This will output something like the following, where the actual values may be different: - ```shell - d7331d5344a99696a8135212475e2c6b605cea88e9edd594773181205dda1531 ./bin/worker_enclave.compact.wasm - ``` - The first long number is the SHA256 hash of the WASM code. Copy this value (in the example case `d733...1531`) into the clipboard (Control-C). - -8. Start the substraTEE-client to send an extrinsic to the substraTEE-node that is then forwarded and processed by the substraTEE-worker. The code to increment the counter comes from the WASM file (`bin/worker_enclave.compact.wasm`). The user provides the hash of the code he wants to execute. - ```shell - root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client --sha256wasm | tee /substraTEE/client.log - ``` - The output of the client is also logged to the file `/substraTEE/client.log` and can be inspected by `less /substraTEE/client.log`. - - You will see on the last lines of the output the two hashes of the transaction (expected and actual). These should match indicating that all commands were processed successfully. - ```shell - Expected Hash: [...] - Actual Hash: [...] - ``` - -9. Query the counter from the substraTEE-worker: - ```shell - root@:/substraTEE/substraTEE-worker-M2# ./bin/substratee_client getcounter | tee /substraTEE/counter.log - ``` - After the first iteration, the counter of Alice will have the value 52. This is correct as the following code is executed in the WASMI in the enclave: `new = old + increment + 10` (see `substraTEE-worker/enclave/wasm/src/lib.rs`). - -10. Check the output of the substraTEE-worker by calling `less /substraTEE/worker.log`. The most important section is (near the end) - ``` - [>] Decrypt and process the payload - ... - [Enclave] SHA256 of WASM code identical - ... - [<] Message decoded and processed in the enclave - ``` - which indicates that the SHA256 hash passed by the client matches the calculated hash of the code that should be executed. - -11. When sending a different hash from the substraTEE-client to the substraTEE-worker, the code will not be executed and the counter therefore not updated. - - The client will wait infinitely for the callConfirmed event which will never be sent by the worker as the code was not executed. The client must be killed (Control-C) and the log file of the worker can be inspected with `less /substraTEE/worker.log`. At the end of the log file there is a different output than before - ``` - [>] Decrypt and process the payload - ... - [Enclave] SHA256 of WASM code not matching - [Enclave] Wanted by client : [...] - [Enclave] Calculated by worker: [...] - [Enclave] Returning ERROR_UNEXPECTED and not updating STF - ``` - which indicates that the SHA256 hash passed by the client **DOES NOT** match the calculated hash of the code that should be executed. - -Whenever you perform the steps 8. and 9., you will see the counter incrementing. - -### M4 Redundancy and Secret Provisioning -The M4 demo differs from the proposed architecture in the following points: -- There is only one docker image that contains the substraTEE-node, the substraTEE-worker and the substraTEE-client (named _substratee_) -- There will be 4 docker containers running the following components: - - Docker container 1: substraTEE-node - - Docker container 2: substraTEE-client - - Docker container 3: substraTEE-worker 1 - - Docker container 4: substraTEE-worker 2 -- The substraTEE-node has only one module (called substratee-registry module) that includes all the required functionality -- The substraTEE-client not only talks to the substraTEE-node, but also communicates directly with the substraTEE-worker (in order to get the shielding key) -- The encrypted state is exchanged between the two substraTEE-workers by the use of IPFS (https://ipfs.io) - -The following requirements are needed to run the M4 demo: -* Intel SGX installed, enabled and working (see https://github.com/intel/linux-sgx) -* Intel account information for Remote Attestion. These files (`key.txt` and `spid.txt`) must be placed in the folder `intel_cert` -* Docker installed -* Tmux installed -* Active internet connection - -To build and execute the code, follow these instructions: -1. Clone the [substraTEE](https://github.com/scs/substraTEE) repository to your favorite location: - ```shell - $ git clone https://github.com/scs/substraTEE.git - $ git checkout M4 - ``` -2. Execute the shell script to build the docker image and start the containers: - ```shell - $ cd substraTEE - $ ./M4.sh - ``` - -The script performs the following steps: -1. Clone the `rust-sgx-sdk` repository into the direcotry `rust-sgx-sdk` as this is needed to execute the code in the docker containers. -2. Build the docker iamge `substratee` based on the `DockerfileM4` (setup Ubuntu 18.04, install the Intel SGX Linux SDK and drivers, compile the substraTEE components, installs IPFS, copy the required file to the Docker image). -3. Create a docker network so that the 4 containers can communicate with each other. -4. Setup a tmux session with 4 panes running the corresponding docker containers (see following screenshot): - - Upper left: substraTEE-node - - Upper right: substraTEE-client - - Lower left: substraTEE-worker 1 - - Lower right: substraTEE-worker 2 - -![Diagram](./substraTEE-M4.png) - -#### Flow of the demo -- The **substraTEE-node** is started immediately in development mode and begins to generate blocks. -- The **substraTEE-worker 1** is started 3 seconds after the substraTEE-node and registers it's enclave at the substraTEE-node. -- The **substraTEE-client** is started 30 seconds after the substraTEE-node and performs a first transaction. As only one worker is registered, the substraTEE-worker 1 performs the state transition function. -- The **substraTEE-worker 2** is started 60 seconds after the substraTEE-node and registers it's enclave at the substraTEE-node. It detects that another enclave is already registered, performs a mutual remote attestation (MU-RA), exchanges the state encryption key and the encrypted state (over IPFS). At this point, two enclaves are registerd in the substraTEE-node. -- The **substraTEE-client** performs another transaction 30 seconds after the first. There are now two enclaves registered and both react on the transaction and calculate the new state. -- The **substraTEE-client** queries finally the counter from one of the workers which verifies the signature. - -After the demo has run, the local directory `./output` contains the log files of the different components. ## Acknowledgements diff --git a/scriptsM5/start_client.sh b/scriptsM5/start_client.sh new file mode 100755 index 0000000..6ad3f57 --- /dev/null +++ b/scriptsM5/start_client.sh @@ -0,0 +1,26 @@ +#!/bin/bash + +clear + +# wait until the worker 1 is ready +sleep 32s + +# start the client and send first transaction +cd /substraTEE/substraTEE-worker/bin +./substratee_client -p 9977 -a 192.168.10.10 2>&1 | tee /substraTEE/output/client_first.log + +# wait until worker 2 registered +sleep 30s + +# start the client and send second transaction +cd /substraTEE/substraTEE-worker/bin +./substratee_client -p 9977 -a 192.168.10.10 2>&1 | tee /substraTEE/output/client_second.log + +# wait until transaction is processed +sleep 30s + +# start the client and send third transaction +cd /substraTEE/substraTEE-worker/bin +./substratee_client -p 9977 -a 192.168.10.10 2>&1 | tee /substraTEE/output/client_second.log + +read -p "Press enter to continue" \ No newline at end of file diff --git a/scriptsM5/start_node.sh b/scriptsM5/start_node.sh new file mode 100755 index 0000000..7bff38d --- /dev/null +++ b/scriptsM5/start_node.sh @@ -0,0 +1,8 @@ +#!/bin/bash + +# clear the console +clear + +# start the dev node +# with specific ws-port and listening to external connections +/substraTEE/substraTEE-node/target/release/substratee-node --dev --ws-port 9977 --ws-external 2>&1 | tee /substraTEE/backup/node.log diff --git a/scriptsM5/start_worker1.sh b/scriptsM5/start_worker1.sh new file mode 100755 index 0000000..1271e0e --- /dev/null +++ b/scriptsM5/start_worker1.sh @@ -0,0 +1,19 @@ +#!/bin/bash + +clear + +# configure and start the ipfs daemon +ipfs init +ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/8080 +ipfs daemon > /substraTEE/output/ipfs_daemon1.log & + +# allow the node to get ready +sleep 3s + +# start the worker 1 +cd /substraTEE/substraTEE-worker/bin +./substratee_worker getsignkey 2>&1 | tee /substraTEE/output/worker1_getsignkey.log +./substratee_worker getpublickey 2>&1 | tee /substraTEE/output/worker1_getpublickey.log +./substratee_worker -p 9977 -w 9111 -r 8111 --ns 192.168.10.10 --ws 192.168.10.21 worker 2>&1 | tee /substraTEE/output/worker1.log + +read -p "Press enter to continue" \ No newline at end of file diff --git a/scriptsM5/start_worker2.sh b/scriptsM5/start_worker2.sh new file mode 100755 index 0000000..f64d713 --- /dev/null +++ b/scriptsM5/start_worker2.sh @@ -0,0 +1,19 @@ +#!/bin/bash + +clear + +# configure and start the ipfs daemon +ipfs init +ipfs config Addresses.Gateway /ip4/0.0.0.0/tcp/8080 +ipfs daemon > /substraTEE/output/ipfs_daemon2.log & + +# wait until the worker 1 and the client have interacted +sleep 1m + +# start the worker 2 +cd /substraTEE/substraTEE-worker/bin +./substratee_worker getsignkey 2>&1 | tee /substraTEE/output/worker2_getsignkey.log +./substratee_worker getpublickey 2>&1 | tee /substraTEE/output/worker2_getpublickey.log +./substratee_worker -p 9977 -w 9112 -r 8112 --ns 192.168.10.10 --ws 192.168.10.22 worker 2>&1 | tee /substraTEE/output/worker2.log + +read -p "Press enter to continue" \ No newline at end of file