Path Oram An Extremely Simple Oblivious RAM Protocol

Slides:



Advertisements
Similar presentations
Oblivious Branching Program Evaluation
Advertisements

Kai-Min Chung (Academia Sinica) joint work with Zhenming Liu (Princeton) and Rafael Pass (Cornell NY Tech)
Quick Review of Apr 10 material B+-Tree File Organization –similar to B+-tree index –leaf nodes store records, not pointers to records stored in an original.
CS7380: Privacy Aware Computing Oblivious RAM 1. Motivation  Starting from software protection Prevent from software piracy A valid method is using hardware.
2010/3/81 Lecture 8 on Physical Database DBMS has a view of the database as a collection of stored records, and that view is supported by the file manager.
1 Indexing Structures for Files. 2 Basic Concepts  Indexing mechanisms used to speed up access to desired data without having to scan entire.
File Structures Dale-Marie Wilson, Ph.D.. Basic Concepts Primary storage Main memory Inappropriate for storing database Volatile Secondary storage Physical.
ObliviStore High Performance Oblivious Cloud Storage Emil StefanovElaine Shi
Indexing. Goals: Store large files Support multiple search keys Support efficient insert, delete, and range queries.
1 Physical Data Organization and Indexing Lecture 14.
Oblivious Data Structures Xiao Shaun Wang, Kartik Nayak, Chang Liu, T-H. Hubert Chan, Elaine Shi, Emil Stefanov, Yan Huang 1.
IP Address Lookup Masoud Sabaei Assistant professor
1 CPS216: Advanced Database Systems Notes 04: Operators for Data Access Shivnath Babu.
© 2006 Pearson Addison-Wesley. All rights reserved13 B-1 Chapter 13 (continued) Advanced Implementation of Tables.
Introduction to DFS. Distributed File Systems A file system whose clients, servers and storage devices are dispersed among the machines of a distributed.
MA/CSSE 473 Day 28 Dynamic Programming Binomial Coefficients Warshall's algorithm Student questions?
Merkle trees Introduced by Ralph Merkle, 1979 An authentication scheme
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Chapter 13 C Advanced Implementations of Tables – Hash Tables.
Onion ORAM: A Constant Bandwidth Blowup ORAM
Keyword search on encrypted data. Keyword search problem  Linux utility: grep  Information retrieval Basic operation Advanced operations – relevance.
CAM Content Addressable Memory
Jonathan Walpole Computer Science Portland State University
CPS216: Data-intensive Computing Systems
Indexing Structures for Files and Physical Database Design
Oblivious Parallel RAM: Improved Efficiency and Generic Constructions
Multiway Search Trees Data may not fit into main memory
Tree-Structured Indexes
OblivP2P: An Oblivious Peer-to-Peer Content Sharing System
CS 332: Algorithms Hash Tables David Luebke /19/2018.
OblivP2P: An Oblivious Peer-to-Peer Content Sharing System
Database Management Systems (CS 564)
B+ Tree.
COSC160: Data Structures Linked Lists
Program based on pointers in C.
Oblivious RAM: A Dissection and Experimental Evaluation
TaoStore Overcoming Asynchronicity in Oblivious Data Storage
External Methods Chapter 15 (continued)
Searching.
Database Applications (15-415) DBMS Internals- Part III Lecture 15, March 11, 2018 Mohammad Hammoud.
Verifiable Oblivious Storage
Hash Tables.
CS7380: Privacy Aware Computing
B+-Trees and Static Hashing
Data Structures and Algorithms
CS222/CS122C: Principles of Data Management Notes #07 B+ Trees
Tree-Structured Indexes
Indexing and Hashing Basic Concepts Ordered Indices
B+Trees The slides for this text are organized into chapters. This lecture covers Chapter 9. Chapter 1: Introduction to Database Systems Chapter 2: The.
Tree-Structured Indexes
File Storage and Indexing
B-Trees CSE 373 Data Structures CSE AU B-Trees.
Advanced Implementation of Tables
File Storage and Indexing
Database Design and Programming
Chapter 16 File Management
CSE 373, Copyright S. Tanimoto, 2002 B-Trees -
CPS216: Advanced Database Systems
Chapter 15: File System Internals
CSE 373: Data Structures and Algorithms
General External Merge Sort
CSE 373: Data Structures and Algorithms
B-Trees CSE 373 Data Structures CSE AU B-Trees.
CS210- Lecture 16 July 11, 2005 Agenda Maps and Dictionaries Map ADT
Tree-Structured Indexes
Indexing, Access and Database System Architecture
OblivP2P: An Oblivious Peer-to-Peer Content Sharing System
CS222/CS122C: Principles of Data Management UCI, Fall 2018 Notes #06 B+ trees Instructor: Chen Li.
CS222P: Principles of Data Management UCI, Fall Notes #06 B+ trees
Presentation transcript:

Path Oram An Extremely Simple Oblivious RAM Protocol Aaron Chu Presentation for the course of Network Security Saturday, July 13, 2019

Cheat Engine

Access patterns leak: 80% of search queries to encrypted database! Why it Concerns us ? Access patterns leak: 80% of search queries to encrypted database!

The Solution Oblivious RAM (Random Access Machine) : The goal is to access data without revealing the access patterns. ORAM Algorithms: Naïve ORAM Square Root ORAM Path ORAM

What to hide? Which data is being accessed. How old it is when it was last accessed. Whether the same data is being accessed. Whether it is sequentially accessed or randomly accessed. Whether the access is read or write.

What is a Good ORAM Algorithm? Correctness: The construction is correct, i.e., it returns data consistent with the request sequence. Obliviousness: For any two request sequences 𝑦 , 𝑧 with 𝑦 = 𝑧 , we have: 𝐴( 𝑦 ) ≈ 𝑐 𝐴( 𝑧 ) for anyone except the client Performance

The Model Client Storage Server Application Capacity: 𝑁 blocks

Naïve Solution For each block we do the following operations: Server 𝑇: table of N blocks Works: - Correct - Oblivious For each block we do the following operations: Get the bock from the server. Decrypt the block. Read or write to the block if necessary. Re-encrypt the block with a different key. Write back the block to the storage system. Overhead: O(N) - Read the entire table for every access

Square Root Algorithm For each of N½ requests: After N½ requests: N blocks N½ dummy blocks N½ block shelter For each of N½ requests: Look for block in the shelter If not found, get block from permuted memory, put it in shelter Otherwise access the next dummy block After N½ requests: Reshuffle permuted memory, obliviously update with values in shelter Permuted memory - Correct - Oblivious Overhead: O(N½)

Data Shuffling Use a sorting network: Permuted memory Use a sorting network: Oblivious shuffling: sort based on a PRF 𝐹 𝑠 (⋅) Enc 𝑘 ((𝑥, 𝐹 𝑠 (𝑖)) Enc 𝑘 ((𝑦, 𝐹 𝑠 (𝑗)) Sorted based on: 𝐹 𝑠 𝑖 < 𝐹 𝑠 (𝑗)

Path oram Most practical ORAM construction to date. Highly efficiency and low overhead. Simple algorithm (16 lines of code is enough). Structure Server side: Binary Tree (It doesn’t have to be a binary tree) Client side: Position Map, Stash

Path oram – Server end layout some nodes are empty nodes can contain multiple blocks bucket block N : number of blocks B: block size in bits. Z: Bucket size. L: Height of the tree L = log 𝑁 -1. Data blocks stored in nodes of the tree on server end. It’s a complete binary tree. Blocks can just be arranged as an array.

Path oram – Block position 7 8 3 4 5 6 1 2 Position comes from the leave sequence number. The position of the block is chosen randomly from 1 – 2^L (total number of leaves).

Path oram – Block position 7 8 3 4 5 6 1 2 A block must be placed on the path to its “position”, if the block is at position 5 it can only be place in this path.

Path oram – Block Position 7 8 3 4 5 6 1 2 A block must be placed on the path to its “position”, if the block is at position 1 it can only be place in this path.

Position map 1 2 3 4 Server Client Block No. 1 2 … … …. …. 13 14 3 3 4 1 2 14 9 3 2 1 7 4 11 13 5 10 6 Server Client Block No. 1 2 … … …. …. 13 14 3 Position

Stash one block Stash is a cache for blocks. Stash is used to store blocks overflowed from the server. Stash (size is 9) one block

The logic Read the entire path which contains the block requested. Update the block if necessary. Remap the block to a new position randomly. Re-encrypt the block with a different key. Writeback the whole path.

Example – Modify Block 7 1 2 3 4 Server Client Block No. 1 2 3 4 5 6 7 3 4 1 2 14 3 12 1 7 4 11 13 2 5 10 6 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position Stash 8 9

Example 1 2 3 4 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 3 4 1 2 14 3 12 1 7 4 11 13 2 5 10 6 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position 1. Lookup block’s position Stash 8 9

Example 1 2 3 4 2. Read the entire path Server Client Block No. 1 2 3 3 4 1 2 14 3 12 1 7 4 11 13 2 5 10 6 2. Read the entire path Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position Data is decrypted and stored in the stash. Stash 8 9 1 7 13 10 6

Example 1 2 3 4 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 3 4 1 2 14 3 12 1 7 4 11 13 2 5 10 6 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position 3. Client read/modify block 7. Stash 8 9 1 7 13 10 6

Example 1 2 3 4 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 3 4 1 2 14 3 12 1 7 4 11 13 2 5 10 6 Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position 4. Assign a new random position. Stash 8 9 1 7 13 10 6

Example 1 2 3 4 The deepest bucket first. Try the upper level if full. 3 4 1 2 14 3 12 4 11 2 5 The deepest bucket first. Try the upper level if full. 5. Write path back Blocks should be pushed down as deep as possible. Blocks should be always on the path to its position. Server Try root level if full. Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position Store in the stash if root is full. Stash 8 9 1 7 13 10 6

Example 3 4 1 2 14 3 12 4 11 2 5 Block 8, 1, 13 can end up at any buckets on the entire path. Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position 2 1 2 1 2 1 1 Stash 8 9 1 7 13 10 6

Example 1 2 3 4 Block 9, 7, 10, 6 can end up at these buckets. Server 3 4 1 2 14 3 12 4 11 2 5 Block 9, 7, 10, 6 can end up at these buckets. Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position 2 1 2 1 2 1 1 Stash 8 9 1 7 13 10 6

Example 1 2 3 4 When writing back: 3 4 1 2 14 3 12 8 13 4 11 1 7 2 5 9 6 When writing back: Client pads dummy bocks if the bucket is not full. All the blocks are re-encrypted using a randomized encryption scheme. Server Client Block No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Position Stash 10

Size of the postion map log 𝑁 bits are need to store the position for each block in the position map. 𝑁 log 𝑁 bits are needed in total. Position map needs to be stored on the client side. What if the position map is too large for a client to keep ?

Recursive Paht ORAM ORAM #1 ORAM #2 Position Map for #1 ORAM #3 Server Client Position Map

Overhead of Path Oram

Pr 𝑝 = 𝑖=1 𝑞 Pr⁡{ pos 𝑖 𝑎 𝑖 } = 2 −𝐿 q Why it is secure? Obliviousness: Server sees 𝐴( 𝑦 ) which is a sequence 𝑝 = pos 1 [ 𝑎 1 ],…, pos 𝑞 [ 𝑎 𝑞 ] pos 𝑖 [ 𝑎 𝑖 ] is the position of address 𝑎 𝑖 based on the position map, together with a sequence of encrypted paths 𝑃( pos 𝑖 𝑎 𝑖 ) Proof: For 𝑖<𝑗: pos 𝑗 𝑎 𝑗 is statistically independent of pos 𝑖 𝑎 𝑖 Observe that: If 𝑎 𝑖 = 𝑎 𝑗 : Once pos 𝑖 𝑎 𝑖 is revealed, it is remapped to a new random label If 𝑎 𝑖 ≠ 𝑎 𝑗 : positions of different addresses are independent Therefore by Bayes rule: Pr 𝑝 = 𝑖=1 𝑞 Pr⁡{ pos 𝑖 𝑎 𝑖 } = 2 −𝐿 q

Stash Size When Z = 5, stash size is R. The probability that the stash overflows is : The size of the stash is independent on N. A constant number is enough to keep the possibility low enough.

Integrity – Merkel Tree

Evaluation – Stash size vs Security

Evaluation – Stash size vs Security

Evaluation – Bucket Loads

Evaluation – Stash size vs Blocks

Thank you

References https://www.slideshare.net/ShijieZhang2/path-oram https://eprint.iacr.org/2013/280.pdf http://web.cs.ucla.edu/~rafail/PUBLIC/09.pdf https://www.slideshare.net/DibyenduNath/oram-a-brief-overview https://www.cs.utah.edu/~lifeifei/papers/oramvldb16.pdf https://en.wikipedia.org/wiki/Merkle_tree