1 / 18

SecureCell : An Architecture for Computing with Private Data on the Cloud.

SecureCell : An Architecture for Computing with Private Data on the Cloud. Eric Love, Soham Mehta. CS252, May 2012. Prof. John D. Kubiatowicz. Motivation. }. A Cloud setting includes: Users’ private data Untrusted applications Untrusted operating system

ratkins
Download Presentation

SecureCell : An Architecture for Computing with Private Data on the Cloud.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SecureCell:An Architecture for Computing with Private Data on the Cloud. Eric Love, Soham Mehta. CS252, May 2012. Prof. John D. Kubiatowicz

  2. Motivation } • A Cloud setting includes: • Users’ private data • Untrusted applications • Untrusted operating system • Strong incentives to exploit private data • Strong desire for selective sharing On public provider’s servers!

  3. Related Work • AEGIS Architecture for Tamper-Evident Computing • (Suh et al.) • Protecting Critical Secrets in Microprocessors • (Lee et al.) • Intel AES Instruction Set Extensions • Overshadow (VMWare) • Information Flow: HiStar etc. • Private Data Capsules • (Maniatis et al.) • OceanStore • (Kubiatowicz et al.) CPU Extensions Hypervisor OS “Big Data”

  4. Threat Model • We assume that: • The OS Kernel could be malicious • Applications can execute arbitrary (possibly malicious) code • The Kernel and Apps could collude with each other • An adversary is assumed *NOT* to be able to: • Modify or observe arbitrary CPU state (registers) • Access DRAM except through the CPU • Initiate arbitrary read/write transactions on the memory bus

  5. SecureObjects • A way to store private data in the Cloud • Can only be accessed under controlled circumstances: • Trusted CPU required to decrypt data • ACL could (possibly) be implemented in software • Remain encrypted while at rest • Only decrypted when needed, for duration of computation • Contents not to be shared with anyone but owner of key • Arbitrary apps can still compute with them!

  6. SecureCell: High-level Vision • A “sealed container” for working with SecureObjects • The only place where plaintext data exists! • Present different views of memory to applications and OS • Resembles Overshadow, but no hypervisor, allow untrusted apps • Ensures that all data is re-encrypted before it leaves • Corresponds to notion of “cell” in Tessellation OS • Provides security isolation, where Tess provides QoS

  7. Keys as Capabilities • Taken from Lee et al. (ISCA’05) • No one other than processor ever sees keys! • To access a SecureObject, the processor: • Is given an encrypted key • Decrypts key (with own private key) • Stores decrypted key in private memory, associates with Cell • Like having a “capability” for access to a SecureObject key • Data’s owner has additional capability to declassify data

  8. SecureCell Architecture • CPU must know about ASIDs • To determine what is “inside” or “outside” of a SecureCell • Have to validate physical mem access/page table updates • Need to store keys in CPU-owned memory: • So no one can see them • In order to enforce re-encryption with correct key • Need new instructions to • Associate a Key with a SecureCell • Decrypt data • Make new SecureCell context

  9. SecureCell  SecureObjects • To use a SecureObject: • Read data from disk • Read key cap into mem • Tell HW to “load” key • Ask HW to decrypt data • Can think of obj as simply range of VMem

  10. Experimental Platform • GEM5 Architecture Simulator • Modified 1CPI processor model • Syscall emulation mode, rather than full OS support • Interposes on open()/read()/write() calls • ARM ISA • Supported in full-system and syscall emulation mode • Actually still relevant, unlike ALPHA • May eventually use coprocessor instructions • OpenSSL’s libcrypto for AES implementation • Will replace with simulated Intel AES instructions (next few days) • Benchmark: bzip2 recompiled for ARM, linked with SCLIB

  11. Implemented Features • SecureCell Library (SCLIB): • Written in C, linked into benchmark apps • Manages layout of SecureObjects on disk / “at rest” • Keeps a buffer of chunk data not yet returned to read() • Contains replacements for open()/read()/write() • Memory Tracking Unit • C++ classes inserted into GEM5 CPU model • Keeps track of data returned from read() • Monitors memory access to data in read() buffer • Used to determine “window of opportunity” for decrypting data transparently

  12. Modifications to GEM5 • Derive “SimpleSCCPU” from TimingSimpleCPU base • Don’t add new instructions, but use “special” memory refs • mov r3, #268435456 ; 0x10000000 is sim. open ptr loc. • ldr r2, [pc, #100] ; [pc, #100] contains &open • str r2, [r3] ; store &open at 0x10000000 • CPU model’s writeMem() handler method: • detects stores to these addresses • saves values into MemTracker class (per thread context) • Instruction execution (completeIfetch() method) • Replaces call to saved pointer with call to SCLIB func

  13. SecureObject Layout • AES Algorithm divides data into 128-bit blocks • Key size of 128, 192, or 256 bits • Chaining-Block Cipher Mode (CBC) • Provides semantic security: • Requires initialization vector (IVEC) • Encrypts data in chunks of multiple blocks • Must decrypt entire chunk to access bytes at the end • Decreases random-access performance as chunk size grows • SCLIB divides file into • Preamble: specifies chunk size (# blocks) and key size • Chunks: contain IVEC, length (bytes of real data in chunk), data • Future: use a B-Tree on data to achieve high security & performance

  14. Evaluation: Crypto Overhead • How low can we make the overhead of encryption/decryption? • “Time Of read() to Time Of Use” (TOrTOU): • How many cycles between return of read() data to use by app? • Modified CPU to track accesses • Sometimes app immediately copies from buffer before “using” • Can track which registers contain “encrypted data” • Don’t count use until non load/store inst performed • Limitations: • “Cheating” if no fine-grained tracking hardware • Premature “use” by functions like getchar() • (extracts byte from word) • Actual cycle counts appear to be “off”

  15. TOrTOU: Workload Analysis

  16. Future work… • Implement parallel decryption • Using coprocessor • With OoO pipeline in GEM5 • Something beyond GEM5? Make real hardware? • Use $-Coherence Directory to track which bits of memory need to be encrypted/decrypted • Full-system implementation • Modify CPU to work with multiple address spaces • Add logic to cause encryption when code outside of Cell’s address space access it (inverse TLB: map phys memASID of owner)

  17. Open Questions • Multicore setting: • How to limit IPIs to between cores in same SecureCell? • Where is central storage of info about cells+keys kept? • How to implement syscalls? • Depends on threat model… • Is choice of syscall a leakage of arbitrary bits? • What state can be visible to kernel? • Maybe apps don’t need much from the system • TessOS implements much OS functionality inside of Cell runtime…

  18. Conclusion • More results in paper! (Hopefully) • Compare bzip2 performance for various chunk sizes to base case • Simulate AES instruction delay with cycle counts from Intel manual • Plenty of room for low-overhead access to encrypted objects • No reason to sacrifice richness of applications for privacy • Much work left to do building a complete system model • Thank you!

More Related