1 / 32

Secure and Shielded Execution for LSM-based KV Stores

This paper explores securing LSM-based KV stores using shielded execution. Challenges are addressed through trusted computing environments to ensure data integrity, confidentiality, and freshness. The proposed solution redesigns in-memory and on-disk data structures for secure persistence.

debbiem
Download Presentation

Secure and Shielded Execution for LSM-based KV Stores

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. SpeicherSecuring LSM-based KV Stores using Shielded ExecutionMaurice Bailleu, JörgThalheim, PramodBhatotia Michio Honda NEC Labs Kapil Vaswani Microsoft Research Christof Fetzer TU Dresden

  2. Storage security in the cloud Untrusted infrastructure Storage or query operations User Data How do we ensure security of data in the cloud?

  3. Trusted computing Trusted Execution Environments (TEEs): Hardware extensions for trusted computing, e.g. Intel SGX and ARM TrustZone Shielded execution:Run-time framework based on TEE to provide strong security, e.g. HAVEN [OSDI’14] and SCONE [OSDI’16] Address space Secure memory region (or enclave) Shielded application Can we also use shielded execution for securing legacy storage systems? TEE Intel SGX or ARM TrustZone

  4. 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 "untrusted storage in stateful setting"?

  5. Our contribution 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) A secure persistent LSM-based KV storefor the untrusted computing infrastructure

  6. Outline Motivation Challenges Design Evaluation

  7. Challenge #1: Enclave physical memory KV stores keep data in-memory for fast operations Unfortunately, EPC is limited (only ~94MiB available) To support larger memory region, SGX supports secure paging  However, EPC paging incurs high overheads (2-2000X) Enclave physical memory (EPC) 128MiB > 128MiB EPC paging Redesigned in-memory LSM data structure (MemTable) to overcome the enclave physical memory limitation

  8. Challenge #2: Untrusted storage 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 Trusted enclave (Volatile memory  Region) Untrusted storage Redesigned on-disk LSM data structures (SSTable and log files) to extend the trust beyond the enclave memory

  9. Challenge #3: I/O syscall Storage systems issue frequent I/O syscalls Thread executing the syscall need to exit the enclave Enclave exit operations are expensive since they  require TLB flushing, security checks, etc. Trusted enclave I/O call Exit enclave toissue the syscall Designed a direct I/O library for shielded execution based on SPDK for fast I/O without exiting enclave

  10. 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!  Unsuitable for modern KV stores SGX trusted counters Designed an asynchronous trusted counter interface taking advantage of persistency guarantees of modern KV stores

  11. Outline Motivation Challenges Design • Background • System components • Algorithms Evaluation

  12. Background: LSM-based KV store Main memory MemTable Level 0 Persistent storage (SSD) SST SST Level 1 SST SST SST SST Level 2 …. …. …. …. MANIFEST Write Ahead Log (WAL) Log files

  13. Outline Motivation Challenges Design • Background • System components • Algorithms Evaluation

  14. System overview Trusted enclave memory Host memory MemTable Storage engine (RocksDB) Trusted counter DMA I/O lib Speicher controller Operating system  SSD SSTable Log files

  15. MemTable Host Enclave (Value part) (Key part) Value Value … K K H P 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

  16. SSTable KV KV Block #1 … KV … Merkle tree KV KV Block #n … KV H1 … Hn Storing the hashes of the blocks allows to make integrity checks for every KV pair, while still allowing fast lookup.

  17. Log files: WAL and Manifest Append #1 ... Append #2 Record 1 Hash 1 Trusted Counter Value 1 R2 C2 H2 Log files guarantee freshness of the data based on the trusted counter 

  18. Asynchronous monotonic counter Unstable period Time  Synchronous   point Synchronous  point Async increment () Async increment () Expected time Time to persist data in modern KV stores can overlap with the unstable period

  19. Outline Motivation Challenges Design • Background • System components • Algorithms Evaluation See the paper for more algorithms

  20. Algorithm #1: Put (K,V)

  21. Algorithm #1: Put 6. Return success and expected time 4. Get stable counter and expected time 3. Increment trusted counter 5. Write to MemTable 2. Write record to WAL 1. Put request Enclave Host Memory MemTable Storage engine Trusted Counter I/O lib DMA Speicher controller Client SSD SST, Log files

  22. Algorithm #2: Get (K)

  23. Algorithm #2: Get Enclave 1.Get Request 3. Search in SST files 2. Search in MemTable 4. Return Value Host Memory MemTable Storage engine Trusted Counter I/O lib DMA Speicher controller Client SSD SST, Log files

  24. Outline Motivation Challenges Design Evaluation

  25. Evaluation Questions: • What is the performance of the direct I/O library? • What is the performance overhead of SPEICHER? 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  See the paper for more results

  26. Q1 : Throughput of the I/O lib Our I/O library performance at par to native SPDK

  27. Q2: Overheads of Speicher Lower is better Reasonable overhead, which results mostly from en-/decryption of KV pairs!

  28. SummarySpeicher: A secure LSM based KV-Store Security properties: confidentiality + integrity + freshness Implementation based on Challenge: How to extend the trust beyond the "secure but stateless enclave" to the "untrusted storage in stateful setting"? Reasonably overheads

  29. Backup!

  30. Native MemTable Memory K K Key Value V V

  31. Native SSTable KV KV … KV … KV KV … KV

  32. Native log files: WAL and MANIFEST Append #1 ... Append #2 Record 2 Record 1

More Related