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

▶
taostore overcoming asynchronicity in oblivious data
SMART_READER_LITE
LIVE PREVIEW

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

Nov 09, 2022 7 likes •250 views

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

slide-1
SLIDE 1

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

slide-2
SLIDE 2

Outsourced Private Data

Alice read (a)

ACK

write (c, data)

read (b)

Security Concerns?

Confidentiality of Data Encryption Encryption alone is not enough!!! Access patterns can leak sensitive information [Islam et al. NDSS’12] vs Is encryption enough? read(1), read(1) read(1), write(3)

slide-3
SLIDE 3

Outsourced Private Data

Alice

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, …

Goal: Oblivious Access OBLIVIOUS RAM (ORAM) Translate each logical access to a sequence of random-looking accesses

Secret State ORAM

slide-4
SLIDE 4

Multi-Client Scenario

Alice Bob Carolyn read (a) read (a) write (c, data)

Concurrency Asynchronicity ObliviStore [Stefanov et al. Oakland’13] CURIOUS [Bindschaedler et al. CCS’15] PrivateFS [Williams et al. CCS’12]

ORAM Client Secret State ACK Single ORAM Client Secret State

slide-5
SLIDE 5

A security model for asynchronous ORAM and attack

Contributions

TaoStore: A new asynchronous and concurrent tree-based oblivious storage

slide-6
SLIDE 6

ORAM Client

Asynchronous ORAM – Threat Model

Storage

Alice Bob

Asynchronous links

  • Adversarially controlled schedule

Important:

  • Network Intruder
  • Adaptive Scheduling
  • Side Channel

Honest-but-curious adversary

  • Sees raw storage data
  • Network communication

Access operations

  • Adaptively scheduled by adversary
  • Adversary learns response timing

ObliviStore [Stefanov et al’13] non-adaptive scheduling + no response time

New

slide-7
SLIDE 7

Asynchronous ORAM - Security

aaob-security: adaptive asynchronous obliviousness

Indistinguishability-based security definition.

See the paper!

We formalize obliviousness in this setting Two timing-consistent executions should be indistinguishable in threat model

slide-8
SLIDE 8

Are existing systems aaob-secure?

Note: No claims are incorrect in CURIOUS

CURIOUS is secure in ObliviStore’s threat model ObliviStore is not secure [Bindschaedler et al.]

We show CURIOUS is not aaob-secure

slide-9
SLIDE 9

Proxy

Secret State

Proxy

SubORAM

CURIOUS [Bindschaedler et al CCS’15]

Secret State

SubORAM

Secret State

SubORAM

Secret State

READ(a)

Alice Bob

READ(b) GET(a) GET(b) RET(a) RET(a) RET(b) RET(b)

Partition storage space Every access to a random partition

Items randomly re-assigned after every access

How about conc accesses on same item? Conc accesses to diff partitions

slide-10
SLIDE 10

Proxy

Secret State

SubORAM

CURIOUS [Bindschaedler et al CCS’15]

Secret State

SubORAM

Secret State

SubORAM

Secret State

READ(a)

Alice Bob

READ(a) GET(a) GET($) RET(a) RET(a) RET($) RET(a)

Only one real access Others fake (random) accesses How about conc accesses on same item?

slide-11
SLIDE 11

Attack Against CURIOUS

Access distinct items Access same item Server Proxy READ(a) READ(a) Server Proxy READ(a) RET(a) READ(b) RET(b)

fake

Reminder Controls scheduling of messages + operations Knows response timings

Attacker learns whether the accesses are on same item or not Fix? See later …

RET(a) RET(a)

real real real

slide-12
SLIDE 12

A security model for asynchronous ORAM and attack

Contributions

TaoStore: A new asynchronous and concurrent tree-based oblivious storage

slide-13
SLIDE 13

CURIOUS: Modular, but two drawbacks

  • 1. Security: Not aaob-secure
  • 2. Efficiency: partitioning → concurrency

(Underlying single-client ORAM not concurrent) Wanted: Native concurrency! Partitioning as simple add-on

slide-14
SLIDE 14

Our solution – TaoStore

Tree-Based Asynchronous Oblivious Store

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?

Simple Fully concurrent

slide-15
SLIDE 15

Starting point – Path ORAM [Stefanov et al CCS’13]

Server

Storage is organized as a binary tree Every access to a random path

Items randomly re-assigned after every access

Stores the assignment

Leaf 1 Leaf 2 Leaf 3 Leaf 4 Stash

Pos Map Proxy a→3 a

O(1) blocks

Possible to outsource position map recursively

slide-16
SLIDE 16

Starting point – Path ORAM

Server 1) Read path

  • Fetch associated path
  • Read/Modify block
  • Assign block to a new random path in

position map

2) Flush

  • Push every block to the lowest non-

full node that intersects with its assigned path (otherwiseàstash) 3) Write-back

  • Re-encrypt w/ fresh

randomness Read/Write block a

Leaf 1 Leaf 2 Leaf 3 Leaf 4 Stash

Proxy a→3 a a a→1 a

If root is full move to stash

a Pos Map

slide-17
SLIDE 17

TaORAM – Basic Approach

How to handle ≤ k concurrent requests?

Server

Leaf 1 Leaf 2 Leaf 3 Leaf 4

Proxy

Stash

Process k operations

  • Fetch corresponding k

paths

  • Form a subtree in proxy

STAGE 1

  • Re-assign k items to

new random paths

  • Flush along the entire

subtree and write-back

STAGE 2

Blocking flush and write-back Concurrent accesses

  • n same block

Two problems

Pos Map

slide-18
SLIDE 18

From Partial to Full Concurrency

Server Proxy

Non-blocking write-back Continue processing

  • perations while write-back

is ongoing

Acknowledgement

What should we delete?

slide-19
SLIDE 19

What should we delete?

Proxy

+ more cases

Acknowledgement

?

now

ACK WB Req Res ACK WB Req Res

fresh stale

waiting for

keep!

Proxy Server Proxy Server

slide-20
SLIDE 20

TaoStore Achieves Full Concurrency

*See the correctness analysis in the paper.

“The items in the local subtree and stash are always up-to-date”

Fresh-Subtree Invariant

by maintaining

slide-21
SLIDE 21

Concurrent accesses on same item

Server Proxy READ(a) RET(a) READ(b) RET(b)

Our solution: Sequencer Ensures logical requests replied in the same order they arrive Generic solution: Also fixes CURIOUS

TaORAM

Sequencer

requests replies serialized Use Fake Access (as in CURIOUS)

security problem

slide-22
SLIDE 22
  • 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

10 20 30 40 50 1 5 10 15 Throughput (ops/s) Number Of Concurrent Clients Throughput

3/1/2016 PHD PROPOSAL – CETIN SAHIN

22

Cloud-based performance analysis

saturation due to bandwidth exhaustion Bandwidth matters!

slide-23
SLIDE 23

0.01 0.02 0.03 0.04 0.05 0.06 36 37 38 39 40 41 40 80 160 240 Ratio Throughput (ops/s) k Throughput Max Outsource Ratio

3/1/2016 PHD PROPOSAL – CETIN SAHIN

23

Cloud-based performance analysis

a low-memory utilization achieves similar performance

  • 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

write-back in batches after k (240) path fetches

slide-24
SLIDE 24

THANKS!

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