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

β–Ά
aarhus mpc workshop 2016
SMART_READER_LITE
LIVE PREVIEW

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

May 10, 2023 420 likes β€’958 views

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

slide-1
SLIDE 1

Tarik Moataz June 2nd 2016 Aarhus MPC workshop 2016

*Joint work with Travis Mayberry and Erik-Oliver Blass

slide-2
SLIDE 2

Part I

ORAM Overview

Part II

C-ORAM*: Constant Communication ORAM with homomorphic Encryption

Part III

CHf-ORAM**: Constant Communication ORAM without homomorphic Encryption

2 * published at CCS’15 ** Work in progress

slide-3
SLIDE 3
  • ORAM first introduced by Goldreich in 87 further enhanced by Goldreich and Ostrovsky in

96

3

CPU MEM

…

Set of registers (Privat ate e Storage) age) Instruction 1 Instruction t Program πœŒπ‘’ Set of memory blocks (Public ublic Storage) age) RAM program

slide-4
SLIDE 4

4

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

slide-5
SLIDE 5

5

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

slide-6
SLIDE 6

𝑏𝑑𝑑𝑓𝑑𝑑1, … , π‘π‘‘π‘‘π‘“π‘‘π‘‘π‘œ 𝑏𝑑𝑑𝑓𝑑𝑑′1, … , π‘π‘‘π‘‘π‘“π‘‘π‘‘β€²π‘œ π‘π‘ž1 = 𝐡(𝑏𝑑𝑑𝑓𝑑𝑑1), … , 𝐡(π‘π‘‘π‘‘π‘“π‘‘π‘‘π‘œ) π‘π‘ž2 = 𝐡(𝑏𝑑𝑑𝑓𝑑𝑑′1), … , 𝐡(π‘π‘‘π‘‘π‘“π‘‘π‘‘β€²π‘œ)

  • An access is either Read or Write
  • For any probabilistic polynomial time adversary, the sequence π‘π‘ž1and π‘π‘ž2 are indistinguishable
  • We say that ORAM hides the access pattern

6

slide-7
SLIDE 7

7

Access … Access Oblivious simulation of RAM

slide-8
SLIDE 8

8 * Joint work with Shruti Tople, Yaoji Jia and Prateek Saxena to appear at USENIX’16

Software Protection G87 Cloud Storage SS13a, SS13b Secure RAM computation, MPC OS97, GKKKMRV12, GGHJRW13 Garbled RAM LO13 Privacy-preserving WNLCSSH14, JMTS16*

slide-9
SLIDE 9
  • Computational/non-computational (e.g., Onion ORAM, C-ORAM)
  • One-server/Multi-servers (e.g., Multi Cloud SS13, Oblivious Network RAM DLPSV15,

Private information Storage OS97)

9

Access Access (possible like in PIS)

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

10

Multiple CPUs Shared Memory

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

11

slide-12
SLIDE 12
  • We want:
  • Constant Communication ORAM
  • Constant number of rounds
  • Very small Block Size
  • No Computation on the server Size
  • Constant Private Storage

12

𝑃(1) private storage 𝑃(1) constant number of blocks

slide-13
SLIDE 13

Unfortunately not possible

  • Goldreich and Ostrovsky (GO96) lower bound of at least log 𝑂 blocks
  • In a one-server setting and without computation:

13

𝑃(log 𝑂) private storage 𝑃(log 𝑂) number of blocks …

Ring/P g/Path ath ORAM

Block size in Ξ©(log2 𝑂)

slide-14
SLIDE 14
  • GO lower bounds is based on Balls/bins and does not capture:
  • Encoding stored data and performing computation on outsourced data BN’15

14

𝑃(1) private storage 𝑃(1) number of blocks

Onion

  • n ORAM

Block size in

Ξ©(log5 𝑂)

Very slow

Can we reduce computational overhead and block size?

slide-15
SLIDE 15

15

𝑃(1) private storage 𝑃(1) number of blocks

C-ORAM RAM Block size in

Ξ©(log4 𝑂)

10 times faster

slide-16
SLIDE 16
  • GO lower bound does not capture multiple servers

16

𝑃(1) private storage 𝑃(log 𝑂) number of blocks

Lu and Ostr trovsky vsky 13 13

… 𝑃( 𝑂) 𝑃(1) number of blocks

Shi and Stef efano anov 13 13

𝑃(log 𝑂) number of blocks No blocks …

slide-17
SLIDE 17
  • GO lower bounds does not capture multiple servers, Great!

17

𝑃(1) private storage 𝑃(1) number of blocks … No blocks

Block size in

Ξ©(log3 𝑂)

slide-18
SLIDE 18
  • We want:
  • Constant Communication ORAM
  • Constant number of rounds
  • Very small Block Size
  • No Computation on the server Size
  • Constant Private Storage

18

Maybe, TWORAM, Bucket ORAM

Computation should not annihilate constant communication

slide-19
SLIDE 19

Tree-based ORAM SCSL’11

19

slide-20
SLIDE 20
  • Read and Write operations

–

Every element is defined by a leaf identifier

–

Every element read/updated is written in the root

  • Eviction (Memory shuffle) process to percolate

elements towards the leaves

  • Recursive position Map

Position Map recursively stored

Bucket

e2 leaf1 e1 leaf2 e3 leaf4 e4 leaf3

  • Search complexity is polylog
  • g
  • Bucket size is a security parameter

Leaf bucket 20

slide-21
SLIDE 21

e3 e2 e1 e4

e2 leaf1 e1 leaf2 e3 leaf4 e4 leaf3

Step 1 e3 e2 e1 e4

e2 leaf1 e1 leaf1 e3 leaf4 e4 leaf3

Step 2 e3 e2 e1 e4

e2 leaf1 e1 leaf1 e3 leaf4 e4 leaf3

Step 3 21

slide-22
SLIDE 22

Part I ORAM Overview

Part II

C-ORAM*: Constant Communication ORAM with homomorphic Encryption

Part III CHf-ORAM**: Constant Communication ORAM without homomorphic Encryption

22

slide-23
SLIDE 23

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

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

24

slide-25
SLIDE 25
  • Components and primitives:
  • Tree based ORAM
  • Additive homomorphic encryption such as Pailler or Damgard-Jurik
  • Private Information Retrieval (Kushilivitz et al.’97)
  • Select
  • Eviction without downloading the bucket

25

123 10 Q = (E(0), E(1), E(0) ) E(123)

  • 123. E(1)

10 . E(0) E(123) E(0)

slide-26
SLIDE 26

Bucket 1 Bucket 2 headers PIR query

𝑭(π’‡πŸ’) βˆ™ 𝑭(𝟐) 𝑭(π’‡πŸ“)

Header

  • Onion layers
  • Select operation is the most

expensive operation in Onion ORAM

𝑭(π’‡πŸ’) 𝑭(𝟏) βˆ™ 𝑭(𝟏) 𝑭(π’‡πŸ“) βˆ™ 𝑭(𝟏) 𝑭(𝟏) βˆ™ 𝑭(𝟏)

Header

𝑭(𝑭 π’‡πŸ ) 𝑭(𝑭 π’‡πŸ‘ ) 𝑭(𝑭 π’‡πŸ’ ) 𝑭(𝑭 𝟏 )

Bucket 2

Header

𝑭(𝑭 π’‡πŸ ) 𝑭(𝑭 π’‡πŸ‘ ) 𝑭(𝑭 π’‡πŸ’ ) 𝑭(𝑭 π’‡πŸ“ )

𝑭(𝟐), , 𝑭(𝟏), , 𝑭(𝟏), , 𝑭(𝟏)

26

slide-27
SLIDE 27

Bucket 1 Bucket 2

Headers Header

Merged bucket headers Permutation 𝜌 Homomorphic Addition

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’)

1 0 1 0 0 1 1 0 Generate 𝜌

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’)

Headers

𝑭(π’‡πŸ) 𝑭(π’‡πŸ‘)

Headers

𝑭(π’‡πŸ) 𝑭(π’‡πŸ‘)

Apply 𝜌 on bucket 2

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’)

Header

𝑭(π’‡πŸ‘) 𝑭(π’‡πŸ) 27

slide-28
SLIDE 28
  • Oblivious merge saves a log2 𝑂 multiplicative factor over Onion ORAM’s select

permutation

  • From log 𝑂 PIR operation to 1 PIR operation
  • Main challenges: Security and correctness

1 1 1 1 1 1 1-positions: 1, 3, 4 0-positions: 2, 5, 6 1-positions: 1, 4, 6 0-positions: 2, 3, 5 1, 3, 4 2, 3, 5 2, 5, 6 1, 4, 6 Bucket 1 Bucket 2 Bucket 1 Bucket 2 Random mapping Random mapping 1 3 4 2 3 5 2 5 6 1 4 6 3 1 5 2 6 4 𝜌

28

slide-29
SLIDE 29

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

29

slide-30
SLIDE 30

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

30

slide-31
SLIDE 31

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

31

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

slide-33
SLIDE 33
  • Noisy blocks
  • Increasing bucket size by factor πœ’
  • 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

Headers

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’)

Headers

𝑭(π’‡πŸ‘) 𝑭(π’‡πŸ)

Headers

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’)

Headers

𝑭(π’‡πŸ) 𝑭(π’‡πŸ‘)

Headers

𝑭(π’‡πŸ“) 𝑭(π’‡πŸ’) 𝑭(π’‡πŸ‘) 𝑭(π’‡πŸ)

Ad Addit itiona

  • nal

blocks

  • cks

33

πœ’ is constant equal to 4 (empirically 2.2)

slide-34
SLIDE 34

Simplified block size Homomorphic additions Homomorphic scalar multiplications Onion ORAM

Ξ©(log5 N) N) 𝚰(π¦π©π‘πŸ— 𝑢) 𝚰(π¦π©π‘πŸ— 𝑢)

C-ORAM

Ξ©(log4 N) N) 𝚰(π¦π©π‘πŸ• 𝑢) 𝚰(π¦π©π‘πŸ” 𝑢)

34

𝑃(log4 𝑂 + 𝐢)

Meta-information: |PIR vectors| + |headers|+ |Permutations|

slide-35
SLIDE 35

Computation Storage 4000 % smaller er block

  • ck

size e for the same e datase set 10 000 % fewer er homomor

  • morphic

hic operat ations

  • ns

35

However C-ORAM still needs 5~10 minutes per access?

slide-36
SLIDE 36

Part I ORAM Overview

Part II

C-ORAM: Constant Communication ORAM with homomorphic Encryption

Part III

CHf-ORAM: Constant Communication ORAM without homomorphic Encryption

36

slide-37
SLIDE 37

37

How can we get rid of the ver

ery e y exp xpen ensi sive e Homomorphic

encryption?

slide-38
SLIDE 38

38

  • 1. Replace Homomorphic encryption with secret shared block
  • 2. Replace computational PIR with Information-theoretic PIR
slide-39
SLIDE 39
  • We use secret sharing and replace a homomorphically encrypted block by two shares:

39 𝑭(π’‡πŸ‘) 𝑭(π’‡πŸ)

Bucket

π’‡πŸ‘βŠ• r2 π’‡πŸβŠ• r1 r2 r1

Share 2 Share 1

slide-40
SLIDE 40

Bucket 1 Bucket 2

Headers

π’‡πŸ“ βŠ• r4 π’‡πŸ’ βŠ• r3

Headers

π’‡πŸ βŠ• r1 π’‡πŸ‘ βŠ• r2 40 r’1 r’2 r’3 r’4

Server 1 Bucket 1 Bucket 2

Headers

r4 r3

Headers

r1 r2 r’1 r’2 r’3 r’4

Server 2

Headers

π’‡πŸ βŠ• r1 βŠ• r’2 π’‡πŸ‘ βŠ• r2

2 βŠ• r’1

π’‡πŸ’ βŠ• r3

3 βŠ• r’4

π’‡πŸ’ βŠ• r3

3 βŠ• r’3

Permutation 𝜌

Headers

r1 βŠ• r’2 r2

2 βŠ• r’1

r3

3 βŠ• r’4

r3

3 βŠ• r’3

Same Permutation 𝜌

slide-41
SLIDE 41

41

Download all headers of the selected path Determine the exact position of the block π‘Š1 = 0,1, 0,0, 1,0,1,1, 0,1,1,1 π‘Š2 = 0,1, 0,0, 1,1,1,1, 0,1,1,1

slide-42
SLIDE 42

42

Compute Result1 βŠ• Result2 Result2 = σ𝑗=1

log 𝑂 π‘Š2 [𝑗]βŠ•Bi

Result1 = σ𝑗=1

log 𝑂 π‘Š1 [𝑗]βŠ•Bi

slide-43
SLIDE 43
  • Replace C-PIR with IT-PIR while taking advantage of the obliviousness of tree-based ORAM

43

For any constant #π‘»π’‡π’”π’˜π’‡π’” β‰₯ πŸ‘ and for any π‘ͺ β‰₯ 𝒍 βˆ™ 𝑢, there exists an IT-PIR construction with communication complexity O(B) bit. For any constant #π‘»π’‡π’”π’˜π’‡π’” β‰₯ πŸ‘ and for any π‘ͺ β‰₯ 𝒍 βˆ™ π’Žπ’‘π’‰ 𝑢, there exists an IT-PIR construction with communication complexity O(B) bit.

slide-44
SLIDE 44

44

Tree 1 Tree 2 Tree 3 Tree 4

  • Tree 1 and Tree 2 are secret

shared (block per block)

  • Tree 3 is a replica of Tree 1
  • Tree 4 is a replica of Tree 2
slide-45
SLIDE 45

C-ORA RAM

  • O(log2 𝑂) homomorphic multiplications
  • O(log 𝑂) C-PIR query generation
  • Encrypt the block homomorphically
  • Computational HA

CH CHf-OR ORAM AM

  • O(log 𝑂) XOR operations
  • O(log 𝑂) Random bit generations
  • Secret share the block
  • IT-secure

45

CHf-ORAM is as good as PIS in communication enjoying a polylog in computation (rather than linear)

slide-46
SLIDE 46

46

  • 1. block size of 1 MB.
  • 2. network speed of 20 Mbps.
  • 3. XOR of two 1 MB blocks in 1 ms

(2012 Macbook Pro with 2.4 Ghz Intel i7)

slide-47
SLIDE 47
  • In SCORAM, eviction circuit size in tree-based ORAM is a bottleneck for secure RAM

computation

  • Best ORAM for secure RAM computation are those with constant private storage
  • Tree-based ORAM with stash are not good for secure RAM computation due to the
  • blivious sorting

47

CHf-ORAM has consta stant t cir ircuit uit siz ize, wit ith consta stant t priva ivate stora rage wit ith no nee eed f d for r OS

slide-48
SLIDE 48

48

Scheme eme Circu cuit it Size SCSL’11 𝑃(log4 𝑂 + 𝐢 βˆ™ log2 𝑂) CLP’14 𝑃(log4 𝑂 + 𝐢 βˆ™ log2 𝑂) Path SC ORAM 𝑃(log log N (log3 𝑂 + 𝐢 βˆ™ log 𝑂)) LO’13 𝑃(log 𝑂 βˆ™ 𝐷𝑄𝑆𝐺 + 𝐢 βˆ™ log 𝑂) Circuit ORAM 𝑃(log3 𝑂 + 𝐢 βˆ™ log 𝑂)

CHf-ORAM 𝑃(log4 𝑂 + 𝐢)

If 𝐢 is larger than log4 𝑂, then circuit size is constant in B

slide-49
SLIDE 49

Simplified block size in bits Private Storage in block Communicat ion in block Homomorphic additions Homomorphic scalar multiplications #Servers C-ORAM

Ξ©(log4 N) N) 𝑷(𝟐) 𝑷(𝟐) 𝚰(π¦π©π‘πŸ• 𝑢) 𝚰(π¦π©π‘πŸ” 𝑢) 1

CHf-ORAM

Ξ©(log3 N) N) 𝑷(𝟐) 𝑷(𝟐) βˆ’ βˆ’ 4

49

slide-50
SLIDE 50
  • We have:
  • Constant Communication ORAM
  • Constant number of rounds
  • Very small Block Size
  • No Computation on the server Size
  • Constant Private Storage
  • One-server

50

Reduce the block size to be in 𝑃(log2 𝑂) (No heavy computation)

slide-51
SLIDE 51

Simplified block size in bits Private Storage in block Communica tion in block Homomorphic additions Homomorphic scalar multiplications #Servers C-ORAM

Ξ©(log4 N) N) 𝑷(𝟐) 𝑷(𝟐) 𝚰(π¦π©π‘πŸ• 𝑢) 𝚰(π¦π©π‘πŸ” 𝑢) 1

CHf-ORAM

Ξ©(log3 N) N) 𝑷(𝟐) 𝑷(𝟐) βˆ’ βˆ’ 4 Ξ©(log g N) or Ξ©(log2 N) 𝑷(𝟐) 𝑷(𝟐) βˆ’ βˆ’ 1

51

Picture from http://www.deviantart.com/browse/all/fanart/?q=super-sheep&order=9

slide-52
SLIDE 52

Thanks!

52