Keystone: An Open Framework for Architecting TEEs

Lee, Dayeol; Kohlbrenner, David; Shinde, Shweta; Song, Dawn; Asanović, Krste

doi:10.48550/arxiv.1907.10119

Cited by 7 publications

(16 citation statements)

References 51 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…TEEs separate userspace code and data from the rest of the system, including higher privileged system software such as the OS kernel [37]. Multiple TEE implementations are commercially available, including Intel SGX [24], ARM TrustZone [7] and AMD SEV [4], with several others under way [57,74,86].…”

Section: Trusted Execution Environments In Cloudsmentioning

confidence: 99%

“…They exploit flaws in specific TEE implementations and can be mitigated through hardware and/or microcode changes [51]. As the maturity of different TEE implementations, especially new open-source ones [4,49,57], grows over time, such attacks will become rarer. Cache side channel attacks [16,41,68] are not specific to TEEs because they are enabled by micro-architectural resource sharing.…”

Section: Security Goals and Threat Modelmentioning

confidence: 99%

See 1 more Smart Citation

SGX-LKL: Securing the Host OS Interface for Trusted Execution

Priebe¹,

Muthukumaran²,

Lind³

et al. 2019

Preprint

View full text Add to dashboard Cite

Hardware support for trusted execution in modern CPUs enables tenants to shield their data processing workloads in otherwise untrusted cloud environments. Runtime systems for the trusted execution must rely on an interface to the untrusted host OS to use external resources such as storage, network, and other functions. Attackers may exploit this interface to leak data or corrupt the computation.We describe SGX-LKL, a system for running Linux binaries inside of Intel SGX enclaves that only exposes a minimal, protected and oblivious host interface: the interface is (i) minimal because SGX-LKL uses a complete library OS inside the enclave, including file system and network stacks, which requires a host interface with only 7 calls; (ii) protected because SGX-LKL transparently encrypts and integrity-protects all data passed via low-level I/O operations; and (iii) oblivious because SGX-LKL performs host operations independently of the application workload. For oblivious disk I/O, SGX-LKL uses an encrypted ext4 file system with shuffled disk blocks. We show that SGX-LKL protects TensorFlow training with a 21% overhead.

show abstract

Section: Trusted Execution Environments In Cloudsmentioning

confidence: 99%

Section: Security Goals and Threat Modelmentioning

confidence: 99%

SGX-LKL: Securing the Host OS Interface for Trusted Execution

Priebe¹,

Muthukumaran²,

Lind³

et al. 2019

Preprint

View full text Add to dashboard Cite

show abstract

“…As a result, even if the state persistent on block B n for a smart contact C eventually becomes dirty due to dApp failure, subsequent dApps can still load clean state for the contract C from a block (prior to B n ) agreed by all parties. Although this design imposes additional requirements on underlying blockchains, it is practical and deliverable using "layertwo" protocols where smart contract executions could be decoupled from the consensus layer, for instance, via the usage of Trusted Execution Environment (e.g., Intel SGX [30] and Keystone [49]).…”

Section: Complete Atomicity For Dappsmentioning

confidence: 99%

HyperService: Interoperability and Programmability Across Heterogeneous Blockchains

Liu,

Xiang,

Shi

et al. 2019

Preprint

View full text Add to dashboard Cite

Blockchain interoperability, which allows state transitions across different blockchain networks, is critical functionality to facilitate major blockchain adoption. Existing interoperability protocols mostly focus on atomic token exchange between blockchains. However, as blockchains have been upgraded from passive distributed ledgers into programmable state machines (thanks to smart contracts), the scope of blockchain interoperability goes beyond just token exchange. In this paper, we present HyperService, the first platform that delivers interoperability and programmability across heterogeneous blockchains. HyperService is powered by two innovative designs: (i) a developer-facing programming framework that allows developers to build cross-chain applications in a unified programming model; and (ii) a secure blockchain-facing cryptography protocol that provably realizes those applications on blockchains. We implement a prototype of HyperService in approximately 35,000 lines of code to demonstrate its practicality. Our experiment results show that (i) HyperService imposes reasonable latency, in order of seconds, on the end-to-end execution of cross-chain applications; (ii) the HyperService platform is scalable to continuously incorporate additional production blockchains. CCS CONCEPTS• Security and privacy → Distributed systems security; Security protocols.

show abstract

“…Enclaves allow for a coarsegrained but strong protection against adversaries in privileged software layers. TEE architectures have been proposed for a variety of computing platforms 1 , in particular for modern high-performance computer systems, e.g., industry solutions like Intel SGX [35], AMD SEV [38], ARM TrustZone [3], or academic solutions such as Sanctum [22], Sanctuary [10], Keystone [48], or Komodo [27] to name some.…”

Section: Introductionmentioning

confidence: 99%

“…On cloud servers, massive amounts of sensitive data are aggregated and used to train proprietary machine learning models, often outside of the CPU, offloaded to hardware accelerators [84]. However, TEE architectures such as SGX [35], SEV [38] and Sanctum [22], do not consider secure I/O at all, solutions such as Keystone [48] would require additional hardware to support DMA-capable peripherals, solutions like Graviton [96] require hardware changes at the peripheral side. TrustZone [3], Sanctuary [10] and Komodo [27] cannot bind peripherals directly to individual enclaves.…”

Section: Introductionmentioning

confidence: 99%

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Bahmani¹,

Brasser²,

Dessouky³

et al. 2020

Preprint

View full text Add to dashboard Cite

Security architectures providing Trusted Execution Environments (TEEs) have been an appealing research subject for a wide range of computer systems, from low-end embedded devices to powerful cloud servers. The goal of these architectures is to protect sensitive services in isolated execution contexts, called enclaves. Unfortunately, existing TEE solutions suffer from significant design shortcomings. First, they follow a one-size-fits-all approach offering only a single enclave type, however, different services need flexible enclaves that can adjust to their demands. Second, they cannot efficiently support emerging applications (e.g., Machine Learning as a Service), which require secure channels to peripherals (e.g., accelerators), or the computational power of multiple cores. Third, their protection against cache side-channel attacks is either an afterthought or impractical, i.e., no fine-grained mapping between cache resources and individual enclaves is provided.In this work, we propose CURE, the first security architecture, which tackles these design challenges by providing different types of enclaves: (i) sub-space enclaves provide vertical isolation at all execution privilege levels, (ii) userspace enclaves provide isolated execution to unprivileged applications, and (iii) self-contained enclaves allow isolated execution environments that span multiple privilege levels. Moreover, CURE enables the exclusive assignment of system resources, e.g., peripherals, CPU cores, or cache resources to single enclaves. CURE requires minimal hardware changes while significantly improving the state of the art of hardwareassisted security architectures. We implemented CURE on a RISC-V-based SoC and thoroughly evaluated our prototype in terms of hardware and performance overhead. CURE imposes a geometric mean performance overhead of 15.33% on standard benchmarks. This paper will be published in the proceedings of the 30th USENIX Security Symposium (USENIX Security '21 ).1 TEE architectures for resource-constrained embedded systems (e.g., Sancus [66], TyTAN [8], TrustLite [47] or TIMBER-V [98]) are not the subject of this paper.

show abstract

Keystone: An Open Framework for Architecting TEEs

Cited by 7 publications

References 51 publications

SGX-LKL: Securing the Host OS Interface for Trusted Execution

SGX-LKL: Securing the Host OS Interface for Trusted Execution

HyperService: Interoperability and Programmability Across Heterogeneous Blockchains

CURE: A Security Architecture with CUstomizable and Resilient Enclaves

Contact Info

Product

Resources

About