Secure Cloud Applications with Intel SGX - OSDI 2014 Presentation Summary
This presentation discusses the challenges of trusting cloud environments and proposes solutions utilizing Intel SGX technology. It explores the need for secure execution of applications on untrusted cloud platforms, presents existing solutions, and introduces the concept of Haven for private execution of unmodified applications. The discussion covers the limitations of current security approaches, such as hardware security modules, trusted hypervisors, and remote attestation, highlighting the vulnerabilities they aim to address in cloud computing. The ultimate goal is to establish secure and private execution within cloud environments using Intel SGX and commodity hardware to mitigate security concerns and enhance cloud adoption.
Uploaded on Oct 05, 2024 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Shielding Applications from an Untrusted Cloud Andrew Baumann, Marcus Peinado, and Galen Hunt. OSDI 2014. Fall 2014 Presenter: Kun Sun, Ph.D. Most slides are borrowed from https://www.usenix.org/sites/default/files/conference/protected- files/osdi14_slides_baumann.pdf
Outline Problem: can we trust the Cloud? Existing solutions New hardware solution Intel SGX Future work
The Goal of Haven Secure, private execution of unmodified applications (bugs and all) in an untrusted cloud on commodity hardware (Intel SGX)
Can we trust the Cloud? Huge trusted computing base Privileged software Hypervisor, firmware, ... Management stack Staff (physical access) Sysadmins, cleaners, security Law enforcement (e.g., Snowdon) Security soncerns limits cloud adoption Hierarchical security model Observe or modify any data Even if encrypted on disk / net
Current Approaches Hardware Security Modules Trusted Hypervisor Remote Attestation
Hardware Security Modules Dedicated crypto hardware Tamper-proof Expensive Limited set of APIs Key storage Crypto operations Unprotected transient data Protects the crown jewels , not general-purpose
Trusted Hypervisor Use a small, secure, hypervisor Ensures basic security, such as strong isolation Problem #1: system administrators Problem #2: physical attacks (e.g. memory snooping) Problem #3: tampering with hypervisor
Remote Attestation Trusted hardware: TPM chip Specific software has been loaded Basic idea: Signed measurement (hash) of privileged software Remote user checks measurement Incorrect attestation compromised software Problem: what is the expected measurement? Cloud provider applies patches and updates Must trust provider for current hash value
Shielded Execution Protection of specific program from rest of system cf. protection, process isolation, sandboxing, etc. New term (older concept) Program unmodified, na ve to threats Confidentiality and integrity of: The program Its intermediate state, control flow, etc. Input and output may be encrypted Host may deny service, cannot alter behavior
Threat Model We assume a malicious cloud provider Convenient proxy for real threats All the provider s software is malicious Hypervisor, firmware, management stack, etc. All hardware except the CPU is untrusted DMA attacks, DRAM snooping, cold boot We do not prevent: Denial-of-service (don t pay to cloud!) Side-channel attacks
Intel SGX Software Guard Extension (SGX) Hardware isolation for an enclave New instructions to establish, protect Call gate to enter Remote attestation Processor manufacturer is the root of the trust
SGX vs. Haven SGX was designed to enable new trustworthy applications to protect specific secrets by placing portions of their code and data inside enclaves Self-contained code sequence V2.0 supports dynamic memory allocation Haven aims to shield entire unmodified legacy applications written without any knowledge of SGX Challenge 1: execute legacy binary code Challenge 2: interaction with untrusted OS and hardware Iago attack
Unmodified Binary SGX only supports a subset of application logic Challenging properties in Enclave load code and data at runtime dynamically allocate and change protection on virtual memory execute arbitrary user-mode instructions raise and handle Solution: emulating unsupported instructions, carefully validating and handling exception
Iago Attacks A malicious OS attempts to subvert an isolated application that assumes correct OS behavior malloc() returns pointer to user s stack Scheduler allows two threads to race in a mutex System has 379,283 cores and -42MB of RAM read() fails with EROFS Our approach: Reduce the interface (attack surface) by including a simplified OS into trusted computing base Carefully checking the remaining interface with the untrusted host, e.g., validation of untrusted input
Shield Module Memory allocator, region manager 64GB virtual address space Host commits/protects specific pages No address allocation Private file system Encrypted, integrity-protected VHD Scheduler Don t trust host to schedule threads Exception handler Emulation of some instructions Sanity-check of untrusted inputs Anything wrong panic! 23 KLoC (half in file system)
Untrusted Interface Host/guest mutual distrust Policy/mechanism with a twist Virtual resource policy in guest Virtual address allocation, threads Physical resource policy in host Physical pages, VCPUs ~20 calls, restricted semantics
Untrusted Runtime Primarily bootstrap and glue code, It is not trusted by either enclave or host kernel. Main tasks are creating the enclave, loading the shield, and forwarding calls between the enclave and host OS. Open question: Any potential attacks?
SGX Limitations 1. Dynamic memory allocation and protection New instructions needed 2. Exception handling SGX doesn t report page faults or GPFs to the enclave 3. Permitted instructions RDTSC/RDTSCP needed, for practicality and performance 4. Thread-local storage Can t reliably switch FS and GS
SGX Limitations 1. Dynamic memory allocation and protection New instructions needed 2. Exception handling SGX doesn t report page faults or GPFs to the enclave 3. Permitted instructions RDTSC/RDTSCP needed, for practicality and performance 4. Thread-local storage Can t reliably switch FS and GS
Performance Evaluation Implemented and tested using SGX emulator Thanks, Intel! Problem: no SGX implementation yet Solution: measure Haven s sensitivity to key SGX performance parameters TLB flush on Enclave crossings Variable spin-delay for critical SGX instructions 1. 2. Enclave crossings Dynamic memory allocation, protection Penalty for access to encrypted memory 3. Slow overall system DRAM clock
Performance Summary Depends on model parameters, details in paper 35% (Apache) 65% (SQL Server) slowdown vs. VM Assumes 10k+ cycles SGX instructions, 30% slower RAM and you don t have to trust the cloud!
TCB TCB is large; however, all the code is under the client s control, instead of cloud
Whats next? Rollback of persistent storage Requires more hardware or communication Untrusted time Network time sync, RDTSC Cloud management Suspend / resume / migrate applications Encrypted VLANs
Conclusions Closer to a true utility computing model Utility provides raw resources Doesn t care what you do with them Why trust the cloud when you don t have to?
