This repo contains two unstrusted apps A and B, each having an associated secure enclave. Two users have apparently made the same discovery, but don't trust each other to share their results of their discovery. This project aims to verify that both have indeed found the same discovery (here, as an example, the challenge is to perform the addition of two integers), without actually disclosing one's result to the other user. Enclave A creates a challenge (a pair of integers) encrypts it (with a shared key obtained through DHKE). App A sends the challenge to App B, then Enclave B decrypts and solves the challenge (do the sum), and return the encrypted result. App B sends this result to App A, and Enclave A decrypts the result and compare it to its own result, then finally tells App A if both solution are equal or not.
You will need the Intel SGX SDK. This repo was made on Linux with this version of Intel SGX for Linux.
In the folder EnclaveProtocol
, run the script run.sh
.
This will first clean eventual files that are used for communication between the two applications.
It will then compile both SGX applications. Then, it will run the challenge 20 times,
and will finally display results, separated into four catgeories:
executions with successful and failed challenges, executions with errors and timeouts.
Note: executions in the timeout category should be considered as executions with errors —
they often happens when an error occurs in App B and so App A timeouts after waiting for B's response.
Details of the executions are provided in the files trace_A.out
and trace_B.out
.
The time of execution is of 30 seconds per challenge, so about 10 minutes with the default
number of 20 challenges.
The following files are used for communication between the two applications,
and can appear in the EnclaveProtocol
folder:
p_public_A
p_public_B
encrypted_PSK_B
encrypted_PSK_A
encrypted_challenge
encrypted_challenge_response
They should not be modified, and will be cleaned up automatically using the run.sh
script.
Otherwise, for manual testing, they also can be removed with the script clean.sh
(that will also remove execution traces trace_A.out
and trace_B.out
).
The file communication uses some assumptions that led me to hardcode some values. The most important is that the PSK should have a length of 10 characters. The communication will not work properly otherwise.
Moreover, the integers chosen
for the challenge should be uint32_t
, meaning that they should be integers storable on
four bytes.
I wasn't able to make the given functions sgx_aes_ctr_encrypt
and sgx_aes_ctr_decrypt
work reliably.
After a lot of time trying to make it work, I finally chose to use sgx_rijndael128GCM_encrypt
and sgx_rijndael128GCM_decrypt
based on this code.
If necessary, some modifications can be made:
- For debugging purposes, some additional traces — that can violate the enclave confidentiality —
can be displayed by setting the boolean
verbose_debug
to true, at the beginning of the filesApp.cpp
andEnclave.cpp
in both foldersEnclave_A
andEnclave_B
. - If the
run.sh
script indicates a lot of timeouts, the variabletimeoutFileReception
can be modified (in seconds) at the beginning of the fileApp.cpp
in both foldersEnclave_A
andEnclave_B
. - If the
run.sh
script indicates some errors, and the traces are inconsistent, it may be due to the timeout assumption in therun.sh
script. By default, the challenge is supposed to be completed under 30 seconds. It has always been the case in my testing, but if it not your case, you can modify this line 35 ofrun.sh
.