SecureKeeper

Abstract

Cloud computing, while ubiquitous, still suffers from trust issues, especially for applications managing sensitive data. Third-party coordination services such as ZooKeeper and Consul are fundamental building blocks for cloud applications, but are exposed to potentially sensitive application data. Recently, hardware trust mechanisms such as Intel's Software Guard Extensions (SGX) offer trusted execution environments to shield application data from untrusted software, including the privileged Operating System (OS) and hypervisors. Such hardware support suggests new options for securing third-party coordination services.We describe SecureKeeper, an enhanced version of the ZooKeeper coordination service that uses SGX to preserve the confidentiality and basic integrity of ZooKeepermanaged data. SecureKeeper uses multiple small enclaves to ensure that (i) user-provided data in ZooKeeper is always kept encrypted while not residing inside an enclave, and (ii) essential processing steps that demand plaintext access can still be performed securely. SecureKeeper limits the required changes to the ZooKeeper code base and relies on Java's native code support for accessing enclaves. With an overhead of 11%, the performance of SecureKeeper with SGX is comparable to ZooKeeper with secure communication, while providing much stronger security guarantees with a minimal trusted code base of a few thousand lines of code.

Securely deploying distributed computation systems on peer-to-peer networks

“…Another class of attacks that we consider out-of-scope for this paper are side-channel attacks. While attackers might learn something about the computations performed by computation services by using a variety of side-channels such as for the sizes of network messages [35], the execution time of the computation [6,14,36], or other observable side-effects of the computations happening [8,9,26,45], we consider protection against such side-channel a separate and orthogonal topic, and we do not counter such attacks in our design. Furthermore we assume that any attack breaking the SGX security objectives are mitigated by future Intel microcode updates.…”

TrustJS

“…While page swapping is supported, recent publications have shown a higher memory demand results in a severe performance penalty [5,11]. Thus, the memory demand of enclaves should be kept low.…”

“…Additionally, it can enable secure execution of nearly or even totally unmodified legacy applications [5,34,12,8], help securing pub/-sub systems [31] and coordination services [11]. However, none of these works addresses client-side web applications enabling trusted execution of JavaScript code within commodity browsers.…”

SecureStreams

“…ese systems rely on the Java virtual machine (JVM) [36]. However, SGX currently imposes a hard memory limit of 128 MB to the enclaved code and data, at the cost of expensive encrypted memory paging mechanisms and serious performance overheads [26,41] when this limit is crossed. Moreover, executing a fully-functional JVM inside an SGX enclave would currently involve signi cant re-engineering e orts.…”