Ensuring Security in Persistent Key-Value Stores using Shielded Execution
This content discusses the challenges and solutions for securing LSM-based Key-Value stores in untrusted computing environments using Shielded Execution. It addresses the need for confidentiality, integrity, and freshness of data in persistent storage systems. The research explores Trusted Execution Environments (TEEs) such as Intel SGX and ARM TrustZone, and proposes a secure LSM-based KV store with key security properties like preventing unauthorized data access and detecting unauthorized data changes. The focus is on extending trust beyond volatile memory to persistent state on untrusted storage mediums.
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
Speicher Securing LSM-based KV Stores using Shielded Execution Maurice Bailleu, J rg Thalheim, Pramod Bhatotia Michio Honda NEC Labs Kapil Vaswani Microsoft Research Christof Fetzer TU Dresden
Storage security in the cloud Untrusted infrastructure Storage or query operations User Data How do we ensure security of data in the cloud?
Trusted computing Address space Trusted Execution Environments (TEEs): Hardware extensions for trusted computing, e.g. Intel SGX and ARM TrustZone Secure memory region (or enclave) Shielded execution: Run-time framework based on TEE to provide strong security, e.g. HAVEN [OSDI 14] and SCONE [OSDI 16] Shielded application Can we also use shielded execution for securing legacy storage systems? TEE Intel SGX or ARM TrustZone
Research GAP Unfortunately NOT! At least not directly ;-) Shielded execution is mainly designed for securing (volatile) in-memory computation However, storage systems require securing non-volatile state, i.e., persistent state on an untrusted storage medium across reboot, crash, or migration Research challenge: How to extend the trust beyond the "secure but stateless enclave" to the "untrustedstorage in stateful setting"?
Our contribution A secure persistent LSM-based KV store for the untrusted computing infrastructure Security properties: Confidentiality Unauthorized data access is prohibited Integrity Unauthorized change to data is detected Freshness Stale state of data is detected (rollback / forking attacks)
Outline Motivation Challenges Design Evaluation
Challenge #1: Enclave physical memory KV stores keep data in-memory for fast operations Enclave physical memory (EPC) Unfortunately, EPC is limited (only ~94MiB available) 128MiB To support larger memory region, SGX supports secure paging > EPC paging 128MiB However, EPC paging incurs high overheads (2-2000X) Redesigned in-memory LSM data structure (MemTable) to overcome the enclave physical memory limitation
Challenge #2: Untrusted storage Trusted enclave (Volatile memory Region) Persistent KV stores persist data on untrusted storage (SSDs) Trust of the enclave does not naturally extends to untrusted storage Further, the security properties need to valid across system reboot, crash, or migration Untrusted storage Redesigned on-disk LSM data structures (SSTable and log files) to extend the trust beyond the enclave memory
Challenge #3: I/O syscall Storage systems issue frequent I/O syscalls Trusted enclave Thread executing the syscall need to exit the enclave I/O call Enclave exit operations are expensive since they require TLB flushing, security checks, etc. Exit enclave to issue the syscall Designed a direct I/O library for shielded execution based on SPDK for fast I/O without exiting enclave
Challenge #4: Trusted counter To protect system against rollback or forking attacks, we need trusted monotonic counters SGX counters are extremely slow (250ms) and wear out in a couple of days! SGX trusted counters Unsuitable for modern KV stores Designed an asynchronous trusted counter interface taking advantage of persistency guarantees of modern KV stores
Outline Motivation Challenges Design Evaluation Background System components Algorithms
Background: LSM-based KV store Main memory MemTable Level 0 Persistent storage (SSD) SST SST Level 1 SST . SST SST SST Level 2 . . . Log files MANIFEST Write Ahead Log (WAL)
Outline Motivation Challenges Design Evaluation Background System components Algorithms
System overview Host memory Trusted enclave memory MemTable Trusted counter Storage engine (RocksDB) DMA I/O lib Speicher controller SSD SSTable Log files Operating system
MemTable Enclave (Key part) Host (Value part) Value Value K H P K H P Key Hash Ptr Value Split the MemTable into two parts: (1) Key part --> stored in the enclave (2) Value part --> stored in the untrusted host memory
SSTable KV KV KV Block #1 Merkle tree KV KV KV Block #n H1 Hn Storing the hashes of the blocks allows to make integrity checks for every KV pair, while still allowing fast lookup.
Log files: WAL and Manifest Trusted Counter Value 1 Record 1 Hash 1 R2 C2 H2 ... Append #1 Append #2 Log files guarantee freshness of the data based on the trusted counter
Asynchronous monotonic counter Unstable period Time Synchronous point Synchronous point Async Async increment () increment () Expected time Time to persist data in modern KV stores can overlap with the unstable period
Outline Motivation Challenges Design Evaluation Background System components Algorithms See the paper for more algorithms
Algorithm #1: Put 1. Put request 2. Write record to WAL 3. Increment trusted counter 5. Write to MemTable 4. Get stable counter and expected time 6. Return success and expected time Host Memory Enclave MemTable Trusted Counter Storage engine I/O lib DMA Speicher controller SSD Client SST, Log files
Algorithm #2: Get 3. Search in SST files 2. Search in MemTable 1.Get Request 4. Return Value Host Memory Enclave MemTable Trusted Counter Storage engine I/O lib DMA Speicher controller SSD Client SST, Log files
Outline Motivation Challenges Design Evaluation
Evaluation Questions: 1. What is the performance of the direct I/O library? 2. What is the performance overhead of SPEICHER? See the paper for more results Experimental setup: Intel Xeon E3-1270 v5 (3.60 GHz, 4 cores, 8 hyper-threads) -- Skylake w/ SGX Intel DC P3700 SSD (400GB, PCIe x4) -- w/ SPDK
Q1 : Throughput of the I/O lib 1.4 Speicher Native Throughput [GB/s] 1.2 1 0.8 0.6 0.4 0.2 0 2 4 8 16 Blocksize [KiB] Our I/O library performance at par to native SPDK
Q2: Overheads of Speicher 40 Relative Overhead 30 Lower is better 20 10 0 90/10 80/20 100/0 Workload [R/W] Reasonable overhead, which results mostly from en-/decryption of KV pairs!
Summary Speicher: A secure LSM based KV-Store Security properties: confidentiality + integrity + freshness Challenge: How to extend the trust beyond the "secure but stateless enclave" to the "untrustedstorage in stateful setting"? Contributions Implementation based on Secure LSM data structure Direct I/O library Asynchronous counters Algorithms for secure storage and query operations Reasonably overheads
Native MemTable Memory K V K V Key Value 30
Native SSTable KV KV KV KV KV KV 31
Native log files: WAL and MANIFEST Record 1 Record 2 ... Append #1 Append #2
