After experimenting further with Intel’s SGX instructions, we have learned that, surprisingly, our machines do not support Intel’s software guard extensions, despite it being available on our CPUs. Take heart, however! Since this work has already been explored and implemented by others, we have decided to shift the main focus of this project from systems-heavy compilation of binaries for SGX enclave to providing two major language extensions to Python, both of which would harden binaries created by our compiler from various recently proposed attacks against SGX enclaves. As such, we will leave the SGX itself as a stretch goal and primarily focus on adding various AST-level side-channel mitigation techniques to the programs we are compiling, rendering them safer for execution in SGX. We are planning on referencing the work done in the paper "Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing"[1], which introduced a novel branch-obfuscation technique coined "Zigzagger", along with the technique described by the paper "Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory"[2], which describes a method to prevent the CPU caches from being used to infer program secrets. Together, these would patch the two major attack vectors against programs running in enclaves.
A major side channel for gaining knowledge of secret data within an enclave we hope to eliminate is the data shared between processes through the CPU’s branch predictor, which could be probed by a host OS whenever the enclave pauses execution. To defend against this attack, we will use the Zigzagger branch obfuscation technique, which allows branching to happen while hiding the specific paths taken from the branch predictor. Introducing the obfuscation to the assembly code generated by our compiler will require us to add a new pass before liveness analysis which will transform branches in our x86 intermediate representation. This technique works by replacing conditional branches with a series of equivalent conditional move and unconditional jump instructions, which will need to be added to our IR. These added instructions will require us to update the liveness analysis, interference graph building, and structured control flow removal phases of our current compiler. This will allow an opportunity to explore implementing a liveness optimization specific to the introduced obfuscation.
Another family of side channels relates to the CPU cache, which is shared between enclave and other processes, such that a host OS could interrupt execution and probe which cache lines were used, and use that knowledge to determine which branch was taken by the enclave. This attack was shown[3] to recover a full RSA private key in an automated attack from 11 traces within 5 minutes. Note that pinning sensitive data from both execution branches into single cache line would fix the side-channel. Pinning is not directly allowed by hardware, but it is possible with Intel TSX -- Transactional Synchronization Extensions. TSX was designed for atomic commits, and it also aborts the transaction if cache line gets evicted (in this case by the host OS). This property, if combined with code and sensitive data preloading, defeats the cache-based side-channels. Preloading allocation strategies are complicated and are different for read-only data, write data, and code; and since cache-set index only depends on virtual address, allocation has to be done at runtime. As a result, TSX-based side-channel mitigation could prove too big or difficult to implement in our compiler, but we still would like to explore applications of this technique in Python.
[1] Gruss, Daniel, et al. "Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory." (2017).
[2] Lee, Sangho, et al. "Inferring fine-grained control flow inside SGX enclaves with branch shadowing." arXiv preprint arXiv:1611.06952 (2016).
[3] Schwarz, Michael, et al. "Malware guard extension: Using SGX to conceal cache attacks." arXiv preprint arXiv:1702.08719 (2017).