1. TaoStore Overcoming Asynchronicity in Oblivious Data Storage
Cetin Sahin, VICTOR Zakhary, AMR El Abbadi, HUIJIA (RACHEL) Lin, STEFANO Tessaro
University of California, Santa barbara
IEEE Security and Privacy, 2016

2. Outsourced Private Data
Alice
read (a)
write (c, data)
ACK
 outsource 
read (b)
Security Concerns?
Confidentiality of Data
Is encryption enough?
Encryption
Outsourcing private data has become increasingly popular and every day we have more and more cloud based storage services. These services provides useful features but what about security concerns? We need to secure the confidentiality of the data and encryption is a tool to secure the confidentiality. The question that we need to ask is whether encryption is enough or not. Unfortunately the answer to this question is no! Access patterns leak sensitive information.  next slide
Encryption alone is not enough!!!
Access patterns can leak sensitive information
[Islam et al. NDSS’12]
read(1), read(1) vs
read(1), write(3)

3. Outsourced Private Data
Secret State
Alice
ORAM
Goal: Oblivious Access
Translate each logical access
to a sequence of random-looking accesses
To hide access pattern, we would like to achieve oblivious access. Basically, we are looking for a way to translate each logical access to a sequence of random-looking accesses. Oblivious Ram ensures Oblivious access. It was initially proposed by Goldreich and Ostrovsky in 96 and this has been followed up by more practical ORAM solutions. These solutions usually store secret state that contains some information about the storage on the client site. Are these solutions enough? No. these solutions work only for single client.
 Next slide
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, …
Single client

4. Multi-Client Scenario
 outsource 
read (a)
trusted
Alice
ORAM Client
Secret State
Single ORAM Client
Secret State
ACK
read (a)
Bob
Limited concurrency
We consider a different scenario where a company outsources its data and the trusted authorized employees access this shared data. The access can be concurrent. In such a scenario, to achieve oblivious access the straightforward solution would be using single ORAM client in the middle if we don’t care about the efficiency and performance since this will sequentialize the accesses. To date, limited number of solutions leverages parallelism to increase the throughput. PrivateFS enables parallel accesses however it support small number of concurrent access. ObliviStore considers a proxy model where the oram client mediates the client requests. The secret state is stored in oram client and it performs concurrent accesses to storages. The similar design is also used in CURIOUS. Another important variable in such a scenario is asynchronicity, which is important for both security and efficiency. However, it was not captured well by earlier works previously.  Next Slide
write (c, data)
Carolyn
PrivateFS [Williams et al. CCS’12]
Concurrency
ObliviStore [Stefanov et al. Oakland’13]
Asynchronicity
CURIOUS [Bindschaedler et al. CCS’15]

5. Contributions A security model for asynchronous ORAM and attack
TaoStore: A new
asynchronous and concurrent
tree-based oblivious storage
We have two main contributions: - A security model for asynchronous ORAM and attack - TaoStore: Tree-based asynchronous and concurrent oblivious storage Let me start explaining our initial contribution

6. Asynchronous ORAM – Threat Model
Honest-but-curious adversary
Sees raw storage data
Network communication
Storage
Asynchronous links
Adversarially controlled schedule
trusted
ORAM Client
Access operations
Adaptively scheduled by adversary
Adversary learns response timing
New
Our threat model assumes a honest-but-curious adversary which can see raw storage and network communication of the server. It controls the asynchronous link where she can delay the messages arbitrarily long. Additionally, an adversary can schedule access operations adaptively and learn the timing of the responses. ObliviStore’s security model is inherently non-adaptive and does not leak the response time information. However, this information is important. The network might be intruded or the clients will have different behaviors triggered with the answers. There might also be a side channel leakeage.  Next slide
Important:
Network Intruder
Adaptive Scheduling
Side Channel
Alice
Bob
ObliviStore [Stefanov et al’13]
non-adaptive scheduling + no response time

7. Asynchronous ORAM - Security
We formalize obliviousness in this setting
Two timing-consistent executions should be indistinguishable in threat model
aaob-security: adaptive asynchronous obliviousness
Considering the threat model we formalize the obliviousness. Two timing consistent executions should be indistinguishable. We have an indistinguishability based security definition: adaptive asynchronous obliviousness, or aaob security for short. I will not get into the details of the definition here, and please refer to paper for more details.
 Next Slide
Indistinguishability-based security definition.
See the paper!

8. Are existing systems aaob-secure?
ObliviStore is not secure [Bindschaedler et al.]
CURIOUS is secure in ObliviStore’s threat model
Bindschaedler and his team showed that ObliviStore has security problem, though, CURIOUS is secire in ObliviStore’s threat model. In this work we show that CURIOUS is not aaob secure.
 Next Slide
We show
CURIOUS is not aaob-secure
Note: No claims are incorrect in CURIOUS

9. CURIOUS [Bindschaedler et al CCS’15]
SubORAM
Secret
State
SubORAM
Secret
State
SubORAM
Partition
storage space
RET(a)
RET(b)
RET(b)
RET(a)
Proxy
Proxy
Secret State
Secret
State
GET(a)
GET(b)
Every access to a random partition Items randomly re-assigned after every access
Before presenting our attack, let me briefly explain how CURIOUS. It considers a modular design and partitions the storage space. a single oram client is run each partition and every access is performed on a random partition. items are randomly re-assigned after every access. Concurrency is achieved through partitioning. If there are concurrent accesses on distinct items they are likely will go to different partitions. How does CURIOUS handle concurrent accesses on same item?
 Next Slide
READ(a)
READ(b)
Conc accesses to diff partitions
How about
conc accesses on same item?
Alice
Bob

10. CURIOUS [Bindschaedler et al CCS’15]
SubORAM
Secret
State
SubORAM
Secret
State
SubORAM
RET(a)
RET($)
RET(a)
RET(a)
Proxy
Secret State
Secret
State
GET(a)
GET($)
How about
conc accesses on same item?
Uses Fake access. Only one of the requests will trigger a real access and the others trigger fake random accesses.  Next slide
READ(a)
READ(a)
Only one real access
Others fake (random) accesses
Alice
Bob

11. Attack Against CURIOUS
Reminder
Controls scheduling of messages + operations
Knows response timings
Access same item
Access distinct items
Server
Proxy
Server
Proxy
real
real
real
fake
READ(a)
READ(b)
RET(b)
RET(a)
READ(a)
READ(a)
RET(a)
Now it is time to see our attack. We consider two cases: - First two concurrent accesses on same item which will be shown on the left hand side of the slide
- Second, two concurrent accesses on distinct items with similar timing. Initial request invokes real accesses for item a on both sides. The second concurrent access invokes a fake access operation on the left hand side since there is an ongoing access for a. On the other hand, there is a real access for item b. Since the network is asynchronous and under the control of an adversary, the response the second requests can return earlier. When this is the case, the response for item b is returned on the right however, the second request on the left hand side cannot be replied since the item has not been fetched yet. When the response for the first request returns, proxy return answers to for a’s. The attacker learn whether the accesses are on same item or not and this violates the obliviousness. We will see the fix for it later.  Next slide
Attacker learns whether the accesses are on same item or not
Fix? See later …

12. Contributions A security model for asynchronous ORAM and attack
TaoStore: A new
asynchronous and concurrent
tree-based oblivious storage
Now it is time to present TaoStore… 

13. CURIOUS: Modular, but two drawbacks
Security: Not aaob-secure
Efficiency: partitioning → concurrency (Underlying single-client ORAM not concurrent)
Curious is modular but it has two drawbacks:
As we just covered, it is not aaob secure
And the underlying oram client is not concurrent and it achieves concurrency by partitioning
Here we would like to achieve native concurrenct where partitioning can be a simple add-on
Wanted: Native concurrency!
Partitioning as simple add-on

14. Our solution – TaoStore
aaob-secure
Tree-Based Asynchronous Oblivious Store
Simple
Atomic semantics
Fully concurrent
Enables easy partitioning
We developed TaoStore: Tree based Asynchronous Oblivious Store. It is simple, fully concurrent and enables easy partitioning. It ensures aaob security and atomic semantics.
There are many single client tree based oram solutions available, but the main challenge is how to make tree-based oram concurrent.
 Next slide
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?

15. 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 access
Leaf 1
Leaf 2
Leaf 3
Leaf 4
Proxy
Let’s initially understand how tree based orams work. Consider a popular solution Path-Oram. Path ORAM organizes the storage as a binary tree and the nodes of the tree contains constant number of blocks. Every access operation happens to a random path and items are re-assigned after every access. The assignment is stored in position map in proxy. It is possible to outsource position map recursively, but we don’t consider this case in our work.
Possible to outsource position map recursively
Stash
a→3
Stores the assignment
Pos Map

16. Starting point – Path ORAM
Server
Read/Write block a
1) Read path
Fetch associated path
Read/Modify block
Assign block to a new random path in position map a a
Leaf 1
Leaf 2
Leaf 3
Leaf 4
2) Flush
Push every block to the lowest non-full node that intersects with its assigned path (otherwisestash)
If root is full
move to stash
Proxy a a
The access operation on block a happens in three steps. The first step is reading the path. The associated path of item a is fetched to the proxy and then the item is processed. Then, it is assigned to a new random path. The second step is flush. It tries to push every block to a lowest node that intersects with its associated path. Here two cases might happen. First, if the root is full, then move a to a stash. Otherwise, place the a into subtree. Third, re-encrypt the path with fresh randomness and write-back.
3) Write-back
Re-encrypt w/ fresh randomness
Stash
a→1
a→3
Pos Map

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

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

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

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

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

22. Cloud-based performance analysis
Block Size: 4 KB - 1 GB dataset
(commodity workstation) + Storage Server: AWS EC2 (NorCal)
Upstream/DownStream: 11 Mbytes/s. RTT: 12 ms
Benchmark schedule: Adaptive requests
saturation due to bandwidth exhaustion
Bandwidth matters!
3/1/2016
PhD Proposal – Cetin Sahin

23. Cloud-based performance analysis
Block Size: 4 KB - 1 GB dataset
(commodity workstation) + Storage Server: AWS EC2 (NorCal)
Upstream/DownStream: 11 Mbytes/s. RTT: 12 ms
Benchmark schedule: Adaptive requests
a low-memory utilization
achieves
similar performance
write-back in batches after k (240) path fetches
3/1/2016
PhD Proposal – Cetin Sahin

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