Aarhus MPC workshop 2016 *Joint work with Travis Mayberry and - PowerPoint PPT Presentation

Tarik Moataz June 2 nd 2016 Aarhus MPC workshop 2016 *Joint work with Travis Mayberry and Erik-Oliver Blass

Part I ORAM Overview Part II C-ORAM*: Constant Communication ORAM with homomorphic Encryption Part III CH f -ORAM**: Constant Communication ORAM without homomorphic Encryption * published at CCS’15 ** Work in progress 2

 ORAM first introduced by Goldreich in 87 further enhanced by Goldreich and Ostrovsky in 96 Instruction 1 RAM program … Program 𝜌 𝑢 CPU MEM Instruction t Set of registers Set of memory (Privat ate e Storage) age) blocks (Public ublic Storage) age) 3

Access pattern = Accessed blocks 1,4, 5 + Their Values ! Read(1) Write(4) Write(5) 4

Picture from http://radix-communications.com/randomness/ 5

𝑏𝑑𝑑𝑓𝑡𝑡 1 , … , 𝑏𝑑𝑑𝑓𝑡𝑡 𝑜 𝑏𝑞 1 = 𝐵(𝑏𝑑𝑑𝑓𝑡𝑡 1 ), … , 𝐵(𝑏𝑑𝑑𝑓𝑡𝑡 𝑜 ) 𝑏𝑑𝑑𝑓𝑡𝑡′ 1 , … , 𝑏𝑑𝑑𝑓𝑡𝑡′ 𝑜 𝑏𝑞 2 = 𝐵(𝑏𝑑𝑑𝑓𝑡𝑡′ 1 ), … , 𝐵(𝑏𝑑𝑑𝑓𝑡𝑡′ 𝑜 ) • An access is either Read or Write • For any probabilistic polynomial time adversary, the sequence 𝑏𝑞 1 and 𝑏𝑞 2 are indistinguishable • We say that ORAM hides the access pattern 6

Access Oblivious simulation of RAM … Access 7

Software Protection G87 Cloud Storage SS13a, SS13b Garbled RAM LO13 Secure RAM computation, MPC Privacy-preserving OS97, GKKKMRV12, WNLCSSH14, JMTS16* GGHJRW13 * Joint work with Shruti Tople, Yaoji Jia and Prateek Saxena to appear at USENIX’16 8

 Computational/non-computational (e.g., Onion ORAM, C-ORAM) Access  One-server/Multi-servers (e.g., Multi Cloud SS13, Oblivious Network RAM DLPSV15, Private information Storage OS97) (possible like in PIS) Access 9

 One-CPU/Multiple CPUs (e.g., Oblivious Parallel RAM BCP16, CLT16) Shared Memory Multiple CPUs  Computational HA / Information-theoretic secure (DMN11, A10) 10

 Worst-case communication overhead  Private Storage  Minimum Block Size  Number of rounds  MEM storage overhead  Computational overhead 11

 We want:  Constant Communication ORAM  Constant number of rounds  Very small Block Size  No Computation on the server Size  Constant Private Storage 𝑃(1) constant number of blocks 𝑃(1) private storage 12

Unfortunately not possible  Goldreich and Ostrovsky (GO96) lower bound of at least log 𝑂 blocks  In a one-server setting and without computation: 𝑃(log 𝑂) number of blocks … Block size in Ring/P g/Path ath ORAM Ω ( log 2 𝑂 ) 𝑃(log 𝑂) private storage 13

 GO lower bounds is based on Balls/bins and does not capture:  Encoding stored data and performing computation on outsourced data BN’15 𝑃(1) number of blocks Block size in Onion on ORAM Ω ( log 5 𝑂 ) 𝑃(1) private Very slow storage Can we reduce computational overhead and block size? 14

𝑃(1) number of blocks Block size in C-ORAM RAM Ω ( log 4 𝑂 ) 𝑃(1) private 10 times storage faster 15

 GO lower bound does not capture multiple servers 𝑃(log 𝑂) number of blocks … Lu and Ostr trovsky vsky 13 13 𝑃(1) No blocks private storage 𝑃(1) number of blocks … Shi and Stef efano anov 13 13 𝑃(log 𝑂) 𝑃( 𝑂) number of blocks 16

 GO lower bounds does not capture multiple servers, Great! 𝑃(1) number of blocks Block size in … Ω ( log 3 𝑂 ) 𝑃(1) No blocks private storage 17

 We want:  Constant Communication ORAM  Constant number of rounds Maybe, TWORAM, Bucket ORAM  Very small Block Size  No Computation on the server Size  Constant Private Storage Computation should not annihilate constant communication 18

Tree-based ORAM SCSL’11 19

e 2 leaf 1 Bucket e 1 leaf 2 e 3 leaf 4 Leaf e 4 leaf 3 bucket Position Map recursively stored Read and Write operations ● Search complexity is polylog og • Every element is defined by a leaf identifier – • Bucket size is a security parameter Every element read/updated is written in the root – Eviction (Memory shuffle) process to percolate ● elements towards the leaves Recursive position Map ● 20

Step 1 Step 3 Step 2 e 1 e 2 e 4 e 2 e 4 e 2 e 4 e 1 e 1 e 3 e 3 e 3 e 2 leaf 1 e 2 leaf 1 e 2 leaf 1 e 1 leaf 2 e 1 leaf 1 e 1 leaf 1 e 3 leaf 4 e 3 leaf 4 e 3 leaf 4 e 4 leaf 3 e 4 leaf 3 e 4 leaf 3 21

Part I ORAM Overview Part II C-ORAM*: Constant Communication ORAM with homomorphic Encryption Part III CH f -ORAM**: Constant Communication ORAM without homomorphic Encryption 22

Meta - information blocks ORAM tree We say that an ORAM is a constant communication ORAM if: • Constant number of blocks • Meta-information is dominated asymptotically by the size of constant number blocks The server in this model is a computational server rather than a storage-only server 23

 Recent ORAM offers sublinear communication overhead  Onion ORAM by Devadas et al. (TCC’16) first solution offering constant communication overhead, but  With a large block size and a high number of homomorphic multiplications  Onion ORAM block size example:  For N = 2 20 , the block size equals 33Mbit  Total data set size: 34 Tbit 24

 Components and primitives:  Tree based ORAM  Additive homomorphic encryption such as Pailler or Damgard-Jurik  Private Information Retrieval (Kushilivitz et al.’97) 123 Q = (E(0), E(1), E(0) ) 10 E(123) E(123) 123. E(1)  Select E(0) 10 . E(0)  Eviction without downloading the bucket 25

Bucket 1 Bucket 2 headers Header Header 𝑭(𝒇 𝟒 ) 𝑭(𝑭 𝒇 𝟑 ) PIR query 𝑭(𝒇 𝟓 ) 𝑭(𝑭 𝒇 𝟐 ) 𝑭(𝟐) , , 𝑭(𝟏) , , 𝑭(𝟏) , , 𝑭(𝟏) 𝑭(𝒇 𝟓 ) ∙ 𝑭(𝟏) 𝑭(𝒇 𝟒 ) ∙ 𝑭(𝟐) 𝑭(𝟏) ∙ 𝑭(𝟏) 𝑭(𝟏) ∙ 𝑭(𝟏) 𝑭(𝑭 𝒇 𝟒 ) 𝑭(𝑭 𝟏 ) Header 𝑭(𝑭 𝒇 𝟒 ) • Onion layers 𝑭(𝑭 𝒇 𝟑 ) • Select operation is the most Bucket 2 𝑭(𝑭 𝒇 𝟓 ) expensive operation in Onion ORAM 𝑭(𝑭 𝒇 𝟐 ) 26

Bucket 1 Bucket 2 headers Headers 1 0 1 0 Headers 𝑭(𝒇 𝟒 ) Generate 𝜌 𝑭(𝒇 𝟑 ) Permutation 𝜌 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟐 ) 0 1 1 0 Homomorphic Header Headers Header Addition 𝑭(𝒇 𝟒 ) 𝑭(𝒇 𝟒 ) 𝑭(𝒇 𝟑 ) 𝑭(𝒇 𝟑 ) 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟐 ) 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟐 ) Apply 𝜌 on Merged bucket bucket 2 27

1 3 4 Random Bucket 1 Bucket 2 Bucket 1 mapping 1 1 1, 3, 4 2, 3, 5 1-positions: 1, 3, 4 2 3 5 0 0 𝜌 0-positions: 2, 5, 6 1 0 3 1 5 2 6 4 Bucket 2 1 1 Random 1-positions: 1, 4, 6 0 0 2 5 6 mapping 0-positions: 2, 3, 5 2, 5, 6 1, 4, 6 0 1 1 4 6 Oblivious merge s aves a log 2 𝑂 multiplicative factor over Onion ORAM’s select • permutation • From log 𝑂 PIR operation to 1 PIR operation • Main challenges: Security and correctness 28

Headers of root PIR vector Headers of bucket1 PIR vector Headers of leaf node 3 4 1 2 PIR vector 29

Block 3 4 1 2 Adding the block to the root with PIR-Writ ite 30

Oblivious Copy bucket merging Headers of root Permutation Headers of bucket 1 and 2 Permutation Headers of leaf nodes 1 and 3 Permutation 31

• Adversary, given 𝜌, does not get any additional knowledge over • load of a bucket • distribution of real, empty blocks • Permutation outputted by oblivious merging is indistinguishable from a random permutation 32

Headers Headers 𝑭(𝒇 𝟑 )  Noisy blocks 𝑭(𝒇 𝟐 )  Increasing bucket size by factor 𝜒 Headers Headers 𝑭(𝒇 𝟒 ) 𝑭(𝒇 𝟒 ) Headers 𝑭(𝒇 𝟐 ) 𝑭(𝒇 𝟒 ) 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟐 ) 𝑭(𝒇 𝟑 ) 𝑭(𝒇 𝟓 ) 𝑭(𝒇 𝟑 ) Ad Addit itiona onal blocks ocks  Oblivious merge fails if at a given level and eviction #empty blocks of parent < #real blocks of child #empty blocks of child < #real blocks of parent 𝜒 is constant equal to 4 (empirically 2.2) 33

𝑃(log 4 𝑂 + 𝐶) Meta-information: |PIR vectors| + |headers|+ |Permutations| Simplified block size Homomorphic additions Homomorphic scalar multiplications Ω (log 5 N) 𝚰(𝐦𝐩𝐡 𝟗 𝑶) 𝚰(𝐦𝐩𝐡 𝟗 𝑶) Onion ORAM N) Ω (log 4 N) 𝚰(𝐦𝐩𝐡 𝟕 𝑶) 𝚰(𝐦𝐩𝐡 𝟔 𝑶) C-ORAM N) 34

10 000 % fewer er homomor omorphic hic operat ations ons 4000 % smaller er block ock size e for the same e datase set Computation Storage However C-ORAM still needs 5~10 minutes per access? 35

Part I ORAM Overview Part II C-ORAM: Constant Communication ORAM with homomorphic Encryption Part III CH f -ORAM: Constant Communication ORAM without homomorphic Encryption 36

How can we get rid of the ver ery e y exp xpen ensi sive e Homomorphic encryption? 37

1. Replace Homomorphic encryption with secret shared block 2. Replace computational PIR with Information-theoretic PIR 38

 We use secret sharing and replace a homomorphically encrypted block by two shares: 𝒇 𝟐 ⊕ r 1 Share 1 𝒇 𝟑 ⊕ r 2 𝑭(𝒇 𝟐 ) 𝑭(𝒇 𝟑 ) r 1 Bucket Share 2 r 2 39