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