TaoStore Overcoming Asynchronicity in Oblivious Data Storage C E T - PowerPoint PPT Presentation

TaoStore Overcoming Asynchronicity in Oblivious Data Storage C E T I N S A H I N , V I C TO R Z A K H A R Y, A M R E L A B B A D I , H U I J I A ( R A C H E L ) L I N , S T E FA N O T E S S A R O U N I V E R S I T Y O F C A L I F O R N I A , S A N TA B A R B A R A I E E E S E C U R I T Y A N D P R I VA C Y, 2 0 1 6

Outsourced Private Data read (a) ACK write (c, data) read (b) Alice Security Concerns? Confidentiality of Data Is encryption Encryption enough? Encryption alone is not enough!!! Access patterns can leak sensitive information [Islam et al. NDSS’12] vs read(1), write(3) read(1), read(1)

Outsourced Private Data Secret State ORAM Alice Goal: Oblivious Access Translate each logical access to a sequence of random-looking accesses OBLIVIOUS RAM (ORAM) Goldreich and Ostrovsky ’96 More practical solutions: MG’11, DB’11, ES’11, EK’12, ES’12, PW’12, ES’13, CG’13, KC’13, KC’14, LR’15, TM’15 , SD’16, …

Multi-Client Scenario read (a) Alice Secret Secret State State ACK Single read (a) Bob ORAM ORAM Client Client write (c, data) Carolyn PrivateFS [Williams et al. CCS’12] Concurrency ObliviStore [Stefanov et al. Oakland’13] Asynchronicity CURIOUS [Bindschaedler et al. CCS’15]

Contributions A security model for asynchronous ORAM and attack TaoStore: A new asynchronous and concurrent tree-based oblivious storage

Asynchronous ORAM – Threat Model Honest-but-curious adversary • Sees raw storage data • Network communication Storage Asynchronous links • Adversarially controlled schedule ORAM Client Access operations • Adaptively scheduled by adversary • Adversary learns response timing New Important: • Network Intruder Alice Bob • Adaptive Scheduling • Side Channel ObliviStore [Stefanov et al’13] non-adaptive scheduling + no response time

Asynchronous ORAM - Security We formalize obliviousness in this setting Two timing-consistent executions should be indistinguishable in threat model aaob-security: adaptive asynchronous obliviousness Indistinguishability-based security definition. See the paper!

Are existing systems aaob-secure? ObliviStore is not secure [Bindschaedler et al.] CURIOUS is secure in ObliviStore’s threat model We show CURIOUS is not aaob-secure Note: No claims are incorrect in CURIOUS

CURIOUS [Bindschaedler et al CCS’15] Partition storage space RET(b) RET(a) RET(b) RET(a) Secret Secret Secret State State State SubORAM SubORAM SubORAM Proxy Proxy Secret State GET(a) GET(b) Every access to a random partition Items randomly re-assigned after every access Conc accesses to diff partitions READ(a) READ(b) How about conc accesses on same item? Alice Bob

CURIOUS [Bindschaedler et al CCS’15] RET( $ ) RET(a) RET(a) RET(a) Secret Secret Secret State State State SubORAM SubORAM SubORAM Proxy GET( $ ) Secret State GET(a) How about conc accesses on same item? READ(a) READ(a) Only one real access Others fake (random) accesses Alice Bob

Attack Against CURIOUS Reminder Controls scheduling of messages + operations Knows response timings Access same item Access distinct items Server Server real real real fake Proxy Proxy READ(a) RET(a) RET(b) READ(a) RET(a) READ(b) READ(a) RET(a) Attacker learns whether the accesses are on same item or not Fix? See later …

Contributions A security model for asynchronous ORAM and attack TaoStore: A new asynchronous and concurrent tree-based oblivious storage

CURIOUS: Modular, but two drawbacks 1. Security: Not aaob-secure 2. Efficiency: partitioning → concurrency (Underlying single-client ORAM not concurrent) Wanted: Native Partitioning as simple concurrency! add-on

Our solution – TaoStore Tree-Based Asynchronous Oblivious Store Simple Fully concurrent Enables easy partitioning Many tree-based single-client ORAMs available: ES’11, ES’13, CG’13, KC’13, KC’14, XW’15, LR’15, SD’16, TM’15, … Main challenge How to make tree-based ORAM concurrent?

Starting point – Path ORAM [Stefanov et al CCS’13] Server Storage is organized as a binary tree O(1) blocks a Every access to a random path Items randomly re-assigned after every Leaf 2 Leaf 3 Leaf 4 Leaf 1 access Proxy Possible to outsource position map recursively Stash a→3 Stores the assignment Pos Map

Starting point – Path ORAM Server Read/Write block a 1) Read path a a Fetch associated path • Read/Modify block • Assign block to a new random path in • position map Leaf 2 Leaf 3 Leaf 4 Leaf 1 2) Flush If root is full Push every block to the lowest non- • Proxy move to stash full node that intersects with its a assigned path (otherwise à stash) a 3) Write-back Stash Re-encrypt w/ fresh • randomness a→1 a→3 Pos Map

TaORAM – Basic Approach How to handle Server ≤ k concurrent requests? Two problems STAGE 1 Process k operations • Fetch corresponding k Concurrent accesses paths Leaf 2 Leaf 3 Leaf 4 Leaf 1 on same block • Form a subtree in proxy Proxy STAGE 2 • Re-assign k items to Blocking new random paths Stash flush and write-back • Flush along the entire subtree and write-back Pos Map

From Partial to Full Concurrency Server Non-blocking write-back Continue processing operations while write-back is ongoing Acknowledgement Proxy What should we delete?

What should we delete? now Acknowledgement fresh Server Proxy Proxy ? Req WB ACK Res keep! stale Server Proxy waiting for Req WB Res ACK + more cases

TaoStore Achieves Full Concurrency by maintaining Fresh-Subtree Invariant “The items in the local subtree and stash are always up-to-date” *See the correctness analysis in the paper.

Concurrent accesses on same item security Use Fake Access (as in CURIOUS) problem Our solution: Sequencer Ensures logical requests replied in the same order they arrive Server TaORAM Sequencer Proxy requests replies READ(a) RET(a) READ(b) serialized RET(b) Generic solution: Also fixes CURIOUS

Cloud-based performance analysis Block Size: 4 KB - 1 GB dataset • Proxy@UCSB (commodity workstation) + Storage Server: AWS EC2 (NorCal) • Upstream/DownStream: 11 Mbytes/s. RTT: 12 ms • Benchmark schedule: Adaptive requests • saturation due to Throughput 50 bandwidth Throughput (ops/s) 40 exhaustion 30 20 10 Bandwidth matters! 0 1 5 10 15 Number Of Concurrent Clients 22 3/1/2016 PHD PROPOSAL – CETIN SAHIN

Cloud-based performance analysis Block Size: 4 KB - 1 GB dataset • Proxy@UCSB (commodity workstation) + Storage Server: AWS EC2 (NorCal) • Upstream/DownStream: 11 Mbytes/s. RTT: 12 ms • Benchmark schedule: Adaptive requests • Throughput Max Outsource Ratio a low-memory 41 0.06 Throughput (ops/s) utilization 0.05 40 0.04 achieves 39 Ratio 0.03 38 similar performance 0.02 37 0.01 36 0 40 80 160 240 k write-back in batches after k (240) path fetches 23 3/1/2016 PHD PROPOSAL – CETIN SAHIN

THANKS! A security model for asynchronous ORAM and attack TaoStore: A new asynchronous and concurrent tree-based oblivious storage