SECURE COMPUTATION FOR RANDOM ACCESS MACHINESC R A I G G E N T R Y , S H A I H A L E V I , C H A R A N J I T J U T L A , M A R I A N A
R A Y K O V A , D A N I E L W I C H S
2
SECURE TWO PARTY COMPUTATION
YX
Secure computationprotocol
F(X,Y) F(X,Y)
Security means: the parties cannot learn more than what is revealed by the result
COMPUTATION WITH CIRCUITS
Evaluate (garbled) circuit gate by gate
COMPUTATION WITH RANDOM ACCESS MACHINES (RAMS)
LOAD #5EQUAL 15JUMP #6HALT STORE 15LOAD #0ADD #1JUMP #3
LOAD #5EQUAL 15JUMP #6HALT STORE 15LOAD #0ADD #1JUMP #3
LOAD #5EQUAL 15JUMP #6HALT STORE 15LOAD #0ADD #1JUMP #3
RAM representation always more efficient than circuitRAM running time T ⇒ circuit size O(T3 log T) [CR73][PF79]
CPU
memory
SUBLINEAR COMPUTATIONS
• Each record must be “touched” • Circuit as big as the memory even if
computation is sublinear
Find all records for AliceAccess
edNot
Accessed
Alice’s records
must be on the left!
SECURE COMPUTATION WITH RAMS
CPU
memory
Secure computation with circuits of constant size
Oblivious RAM (ORAM) [GO’96]• Hides access pattern• Efficient – polylog access
complexity• Shared ORAM parameters
Amortized secure two party computation proportional to the running time of the RAM [OS’97, GKKKMRV’12]Reveals running time
OUR WORK
Two Party Protocol: Private Keyword Search
• Optimizations for Binary tree ORAM constructions• Binary search in a single ORAM operation not log N• Better concrete storage and computation overhead• Lower depth binary tree• Higher branching factor• Deterministic eviction algorithm
• Use homomorphic encryption for two party computation steps• Devise protocols using low degree polynomials• Explore benefits from such alternative implementation• Communication• Computation - particular protocols, e.g. comparison
ORAM STRUCTURE – BINARY TREE[SCSL’11]
ORAM STRUCTURE – BINARY TREEDatabase size: N
Node size: log N
[SCSL’11]
RECORD LEAF IDENTIFIER
1 2 3 4 5 6 7 8
3
[SCSL’11]
POSSIBLE RECORD LOCATIONS
1 2 3 4 5 6 7 8
3
[SCSL’11]
ORAM LOOK-UPv
1 2 3 4 5 6 7 8
[SCSL’11]
FIND LEAF IDENTIFIER3
v
1 2 3 4 5 6 7 8
[SCSL’11]
SEARCH NODES ON THE PATH3
v
1 2 3 4 5 6 7 8
[SCSL’11]
INSERT IN ROOT NODE
1 2 3 4 5 6 7 8
3
[SCSL’11]
ASSIGN NEW LEAF IDENTIFIER
1 2 3 4 5 6 7 8
7
[SCSL’11]
EVICTION
1 2 3 4 5 6 7 8
After each ORAM access [SCSL’11
]
EVICTION
1 2 3 4 5 6 7 8
After each ORAM accessevict two nodes per level
[SCSL’11]
EVICTION
1 2 3 4 5 6 7 8
After each ORAM accessevict two nodes per level
4
OBLIVIOUSLY:touch both children[SCSL’11
]
LOOK MORE CAREFULLY: “FIND LEAF IDENTIFIER”
3v1
1v2
7v3
2vN
Client memory:size of database
[SCSL’11]
RECURSIVE SOLUTION
3v1
1v2
7v3
2vN
Store recursively in a treePACK multiple address-leaf pairs in one record
Reco
rd
1Re
cord
2
Reco
rd
n/2
[SCSL’11]
RECURSIVE SOLUTION
Tree 1
Tree 2
Tree 3
Scan to find leaf identifier in Tree 2
Search path to find leaf identifier in Tree 1Search path to find
record
ORAM OPTIMIZATION
REDUCE TREE DEPTH
• Storage: from kN to 2N • Computation: from klog2 N to k log2(N/k)
log N
k items per node log (N/k)
• Reduce the depth of the tree
• N/k leaves instead of N• Node size – 2k
INCREASING BRANCHING FACTOR
• More nodes per level and smaller depth logk (N/k)• Computation: k log2
k (N/k)
2 children k children
DETERMINISTIC EVICTION
• Eviction:• Access all k children – factor k overhead• New eviction: • Try to evict along a path from the root to a leaf• Deterministic schedule for eviction: L = DigitReversek(t mod kheight)
• nodes at each level accessed in round-robin order
k children Path ORAM [SDSFRYD’13]Eviction on look-up path
BINARY SEARCHlog N ORAM accesses → 1 ORAM access
ORAM MODIFICATION
Start with sorted data!
1 5 data1
2 20 data2
3 100 data3
4 500 data4
5 1001
data5...
......
INTERMEDIATE TREE RECORD
3vi
1
1vi
2
7vi
3
2vi
k
Reco
rd 1
Reco
rd 2
Reco
rd n
/2
Each data item in an intermediate tree consists of value-leaf pairs
SEARCH FOR A VIRTUAL ADDRESS
3
1vi
2Mat
ched
Rec
ord
vi1
During search in an intermediate tree Ti:• Use a leaf label Li found in the
previous tree• Search for virtual address vi
derived from v and the tree number i
• Identify the data for vi - address-leaf pairs
• Find the pair (vi-1, Li-1): vi-1 derived from v
v
ADDITIONAL DATA IN INTERMEDIARY NODE
3
1vi
2Reco
rd vi1
v1 -> d1
v2 -> d2
vk -> dk
vk+1 -> dk+1
vk+2 -> dk+2
v2k -> d2k
Larg
est t
ree
reco
rds
d1 , dk
dk+1 , d2k
vi-11 -> di-1
2
vi-1k’ -> di-
1k’
vi-1k’+1 -> di-
1k’+1
vi-12k’ -> di-1
2k’
Store the data range corresponding to the items in top tree that map to each virtual address in the intermediate tree
SEARCH FOR A DATA VALUE
3
1
Reco
rd vi1 d1 , dk
dk+1 , d2kvi2 dk+1 <= d <=
d2k
search value
During search in an intermediate tree Ti:• Use a leaf label Li
found in the previous tree
• Search for virtual address vi from the previous tree
• Identify the data for vi
- address-leaf pairs• Check the range for
each pair and select the one that contains d
d
TWO PARTY COMPUTATION WITH HOMOMORPHIC ENCRYPTION
EQUAL-TO-ZERO PROTOCOL
• Client chooses random -bit , sends to server 𝑛 𝑅 = 𝐶 𝐻𝐸𝑠𝑒𝑟𝑣𝑒𝑟( + )𝑋 𝑅• Note, encrypts iff = 0 𝐶 𝑅 𝑋
• Also sends 𝐶𝑖 = 𝐻𝐸𝑐𝑙𝑖𝑒𝑛𝑡(𝑅𝑗)• ’𝑗 th bit of , plaintext space mod-2𝑅 𝑚, 2𝑚 > n
• Server decrypts + , xors the bits into 𝑋 𝑅 𝐶j’s • Using a⊕ = + −2 ( 2𝑏 𝑎 𝑏 𝑎𝑏 𝑚𝑜𝑑 𝑚) • Gets ’𝐶 𝑗 = 𝐻𝐸𝑐𝑙𝑖𝑒𝑛𝑡(𝑅𝑗 ⊕ ( + 𝑋 𝑅𝑗))• Note: = 0 iff all the ’𝑋 𝐶 𝑖’s encrypt 0’s
EQUAL-TO-ZERO PROTOCOL
• Summing up the ’𝐶 𝑖 ’s, server gets 𝐻𝐸𝑐𝑙𝑖𝑒𝑛𝑡( ) 𝑌• 𝑌=0 iff =0 𝑋• Gain: plaintext space mod 2𝑚 rather than 2𝑛
• Repeat this procedure again, reducing the plaintext space to ≈ log𝑙 2 𝑚• After log iterations get plaintext space mod-4 𝑛• At this point we can use depth-2 circuits
(ROUGH) COMPARISON
GC implementationDB size = 218
item size = 512 bits
[GKKKMRV’12]
✦
22
HE implementationDB size = 222
item size = 112 bits
CONCLUSIONS
• Use RAMs for secure computation
• Specialized ORAM – integrate computation for the functionality in the ORAM access algorithm
• Low degree homomorphic encryption with SIMD operations can be efficient
THANK YOU!
Top Related