This project contains an enclave, which is capable of scanning, encrypting and sending a snapshot of one of its threads' stack to a remote Endpoint. The executable ships with a test public key of the Endpoint and outputs:
*_watcher.meta
files containing a pair generated by each Watcher thread which is comprised by a PoW challenge and a hash of the Worker's stack snapshot.*_worker.meta
files containing a pair generated by the Worker which is comprised by a PoW challenge and its PoW solution.*.enc
files containing the current symmetric key encrypted with RSA-3072.*.maciv
files containing the MAC and IV used for the encryption of the current stack snapshot.*.stackshot
files containing a stack snapshot encrypted with AES-128 GCM.
The *.enc
files are named using IDs (numbers) in ascending order. The *.meta
, *.maciv
and *.stackshot
files are named using the ID of their key, as well as their own ID. In the case of *.stackshot
files, the file ID (own) will also be compared with the additional associated data of that payload.
Example: The key 1.enc
can decrypt:
1_0.stackshot
with1_0_watcher.meta
,1_0_worker.meta
,1_0.maciv
,1_1.stackshot
with1_1_watcher.meta
,1_1_worker.meta
,1_1.maciv
,- etc.
In order to validate the signature of a captured stack snapshot s
, a Watcher W
must prepend it with the result of its given proof-of-work before hashing. After hashing, a new proof-of-work with the stack hash as seed must be generated. This is also the value verified by the Endpoint. Let sig
be the value to be sent. Furthermore, let PoW: int x int -> int
be a function which returns a proof-of-work using n_W
as Watcher challenge and D_W
as Watcher difficulty. Then, we can write the following:
sig = PoW(SHA256(PoW(n_W, D_W) || s), D_W)
- C++17
- Intel SGX for Linux (tested with version 2.15.1)
The default path for Intel SGX is /opt/intel/sgxsdk
. To change it, modify SGX_SDK
in buildenv.mk
. Please refer to the Options Section for more details regarding available settings.
In the root directory MemExporter
, execute:
make
The project can be cleaned with:
make clean
The executable is placed in the ./Build
directory and is named app
.
cd Build && ./app
Beside the options available in buildenv.mk
, there are further options available in source files.
-
In
App/App.cpp
. These options are stored as variables at the beginning of the file:num_watchers
Integer (change together withTCSNum
andTCSMinPool
) = indicates the number of watcher threads which will run the attestation process in parallel. All will be given a proof-of-work puzzle before starting the stack scan. Afterwards, one of these threads will be randomly selected to output the Worker's stack snapshot.min_log_level
{-1 | 0 | 1 | 2} = indicates which logs should be printed tostdout
.- -1 = Trace, all logs will be displayed.
- 0 = Debug, all but the Trace logs will be displayed.
- 1 = Info, only the Info and Error logs will be displayed.
- 2 = Error, only Error logs will be displayed.
run_cycles
Integer = indicates the number of scans the watchers will perform. In a real-world scenario, the enclave would run indefinitely, until instructed otherwise by the endpoint.
-
In
Enclave/Enclave.config.xml
:TCSNum
Integer (change together withnum_watchers
andTCSMinPool
) = indicates the number of thread control structures to be generated. Should be equal to the total thread number (num_watchers
+ 1).TCSMinPool
Integer (change together withnum_watchers
andTCSNum
) = inddicates the minimum number of thread control structures available at any time during the enclave's runtime. Should be equal to the total thread number (num_watchers
+ 1).
-
In
Enclave/EnclaveSGXUtils.h
. These options are stored as macros at the beginning of the file:WATCHER_POW_DIFFICULTY
Integer = indicates the difficulty of the PoW Watcher puzzle before the attestation process begins.WORKER_POW_DIFFICULTY
Integer = indicates the difficulty of the PoW Worker puzzle before the attestation process begins.
Note: The PoW difficulty is the number of leading zero bits the SHA256 digest must have for a proof-of-work to be valid. The hash seed results from the concatenation of the received challenge together with the discovered solution.