Want to dive deeper into the concepts of Confidential Computing? Here is a collection of relevant research papers (co-)authored by Edgeless Systems employees.
We present CCF, a framework to build permissioned confidential blockchains. CCF provides a simple programming model of a highly-available data store and a universally-verifiable log that implements a ledger abstraction. CCF leverages trust in a consortium of governing members and in a network of replicated hardware-protected execution environments to achieve high throughput, low latency, strong integrity and strong confidentiality for application data and code executing on the ledger. CCF embeds consensus protocols with Byzantine and crash fault tolerant configurations. All configurations support strong service integrity based on the ledger contents. Even if some replicas are corrupt or their keys are compromised, they can be blamed based on their signed evidence of malicious activity recorded in the ledger. CCF supports transparent, programmable governance where the power of the consortium members is tunable and their activity is similarly recorded in the ledger for full auditability. We are developing an open-source implementation of CCF based on SGX-enabled Azure Confidential Compute, built on top of the Open Enclave SDK. Experimental results show that this implementation achieves throughput/latency tradeoffs up to 3 orders of magnitude better than previous confidential blockchain designs.
Modern processors, eg, Intel SGX, allow applications to isolate secret code and data in encrypted memory regions called enclaves. While encryption effectively hides the contents of memory, the sequence of address references issued by the secret code leaks information. This is a serious problem because these leaks can easily break the confidentiality guarantees of enclaves.
In this paper, we explore Oblivious RAM (ORAM) designs that prevent these information leaks under the constraints of modern SGX processors. Most ORAMs are a poor fit for these processors because they have high constant overhead factors or require large private memories, which are not available in these processors. We address these limitations with a new hierarchical ORAM construction, the Pyramid ORAM, that is optimized towards online bandwidth cost and small blocks. It uses a new hashing scheme that circumvents the complexity of previous hierarchical schemes.
We present an efficient x64-optimized implementationof Pyramid ORAM that uses only the processor’s registers as private memory. We compare Pyramid ORAMwith Circuit ORAM, a state-of-the-art tree-based ORAMscheme that also uses constant private memory. PyramidORAM has better online asymptotical complexity thanCircuit ORAM. Our implementation of Pyramid ORAMand Circuit ORAM validates this: as all hierarchicalschemes, Pyramid ORAM has high variance of access latencies; although latency can be high for some accesses,for typical configurations Pyramid ORAM provides access latencies that are 8X better than Circuit ORAM for99% of accesses. Although the best known hierarchical ORAM has better asymptotical complexity, PyramidORAM has significantly lower constant overhead factors, making it the preferred choice in practice.
Cache-based side-channel attacks are a serious problem in multi-tenant environments, for example, modern cloud data centers. We address this problem with Cloak, a new technique that uses hardware transactional memory to prevent adversarial observation of cache misses on sensitive code and data. We show that Cloak provides strong protection against all known cache-based side-channel attacks with low performance overhead. We demonstrate the efficacy of our approach by retrofitting vulnerable code with Cloak and experimentally confirming immunity against state-of-the-art attacks. We also show that by applying Cloak to code running inside Intel SGX enclaves we can effectively block information leakage through cache side channels from enclaves, thus addressing one of the main weaknesses of SGX.
For the first time, we practically demonstrate that Intel SGX enclaves are vulnerable against cache-timing attacks. As a case study, we present an access-driven cache-timing attack on AES when running inside an Intel SGX enclave. Using Neve and Seifert's elimination method, as well as a cache probing mechanism relying on Intel PMC, we are able to extract the AES secret key in less than 10 seconds by investigating 480 encrypted blocks on average. The AES implementation we attack is based on a Gladman AES implementation taken from an older version of OpenSSL, which is known to be vulnerable to cache-timing attacks. In contrast to previous works on cache-timing attacks, our attack is executed with root privileges running on the same host as the vulnerable enclave. Intel SGX, however, was designed to precisely protect applications against such root-level attacks. As a consequence, we show that SGX cannot withstand its designated attacker model when it comes to side-channel vulnerabilities. To the contrary, the attack surface for side-channels increases dramatically in the scenario of SGX due to the power of root-level attackers, for example, by exploiting the accuracy of PMC, which is restricted to kernel code.
Privacy-preserving multi-party machine learning allows multiple organizations to perform collaborative data analytics while guaranteeing the privacy of their individual datasets. Using trusted SGX-processors for this task yields high performance, but requires a careful selection,adaptation, and implementation of machine-learning algorithms to provably prevent the exploitation of any side channels induced by data-dependent access patterns.We propose data-oblivious machine learning algorithms for support vector machines, matrix factorization,neural networks, decision trees, and k-means clustering. We show that our efficient implementation based on Intel Skylake processors scales up to large, realistic datasets, with overheads several orders of magnitude lower than with previous approaches based on advanced cryptographic multi-party computation schemes.
Two big trends that can be observed in the way that software is developed and used are the commoditization of software components and computing infrastructure: It has long become the norm that software products are not entirely developed by a single trusted entity. Instead, even large software vendors routinely rely on software components from different and numerous external sources. These sources include typically public open source projects or external contractors.
Changes of similar nature can be observed in the ways that software is used and deployed; without doubt has cloud computing been one of the biggest trends in IT in recent years. The central concept of cloud computing is that the users’ software no longer runs on their own systems but rather on demand, in a cost-effective manner, in the data centers of a cloud provider. This arrangement is also referred to as “infrastructure as a service”. Due to these developments new attack surfaces for application software arise: Classically, the security of application software is considered in adversarial settings where a trusted application is running in a largely trusted environment. The attacker is only foreseen to partly control inputs and outputs of the application. A typical concrete scenario is here for example a web browser in which the attacker triggers a buffer overflow vulnerability using a malicious web site.
This one-dimensional attacker model appears not always appropriate in the context of software components from external sources and cloud computing as it disregards important risks: a software component could contain a “backdoor” or a malicious cloud administrator could access the code and data of a cloud application at runtime.
Hence, this dissertation explores the topic of application software security in three modern adversarial settings: (i) the classic setting, (ii) the backdoor setting in which the attacker may additionally add a backdoor to a component of a software, and (iii) the cloud setting in which the attacker largely controls hardware and software and may at different places read or manipulate a cloud applications code and data.
We present VC3, the first system that allows users to run distributed MapReduce computations in the cloud while keeping their code and data secret, and ensuring the correctness and completeness of their results. VC3 runs on unmodified Hadoop, but crucially keeps Hadoop, the operating system and the hypervisor out of the TCB; thus, confidentiality and integrity are preserved even if these large components are compromised. VC3 relies on SGX processors to isolate memory regions on individual computers, and to deploy new protocols that secure distributed MapReduce computations. VC3 optionally enforces region self-integrity invariants for all MapReduce code running within isolated regions, to prevent attacks due to unsafe memory reads and writes. Experimental results on common benchmarks show that VC3 performs well compared with unprotected Hadoop: VC3’s average runtime overhead is negligible for its base security guarantees, 4.5% with write integrity and 8% with read/write integrity.
Cold boot attacks exploit the fact that data in RAM gradually fades away over time, rather than being lost immediately when power is cycled off. An attacker can gain access to all memory contents by a restart or short power-down of the system, a so called cold boot. Consequently, sensitive data in RAM like cryptographic keys are exposed to attackers with physical access. Research in recent years found software-based solutions to the cold boot problem in terms of CPU-bound or memory-less encryption. To date, however, the focus has been set on symmetric ciphers, particularly concerning disk encryption systems. Contrary to that, the work in hand aims to close the gap to asymmetric ciphers. With PRIME, we present a cold boot resistant infrastructure for private RSA operations. All private RSA parameters reside symmetrically encrypted in RAM and are decrypted only within CPU registers. The modular exponentiation algorithm for RSA is implemented entirely on the CPU, such that no sensitive state of RSA ever goes to RAM.
