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

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!