1 / 25

Oblivious Parallel RAM: Improved Efficiency and Generic Constructions

Oblivious Parallel RAM: Improved Efficiency and Generic Constructions. Binyi Chen UCSB. joint work with Huijia (Rachel) Lin Stefano Tessaro. Cloud Computing. File 5 is important. R ead file 5. ……. R ead file 5. Client. ……. Honest. Read file 5. Access pattern

virginian
Télécharger la présentation

Oblivious Parallel RAM: Improved Efficiency and Generic Constructions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Oblivious Parallel RAM:Improved Efficiency and Generic Constructions Binyi Chen UCSB jointworkwith Huijia (Rachel)Lin Stefano Tessaro

  2. Cloud Computing File5isimportant Readfile5 …… Readfile5 Client …… Honest Read file5 Access pattern reveals information Honestbutcurious

  3. Oblivious RAM wrt(b1,v1) ORAM Read(a) va rd(b2) rd(b3) Client Translateseverylogicalaccessintoactualaccessesonserver Correctness:Alwaysreturn/updatethecorrectvalue Obliviousness:Advonlyknow#of logicalaccesssesgiventheactualaccesses

  4. Efficiency Bandwidth overhead: Client-servercommunication/blocksize Efficiency:communication/computationcomplexityoftheclientissignificantlysmallerthanO(N)(e.g.polylog(N)) N=# oflogical blocks

  5. ORAM in the parallel setting Multiple clients TraditionalORAMdoes not supportparallelaccess Parallelprogram • Crucialforrealworldapplication • Scalablecloudstorageservices • Multi-processorarchitectures • Performanceenhancement • Parallelcomputing

  6. ObliviousParallelRAM[BCP’16] read(a1) Honestbutcurious C1 va1 msg2 Channels … Round i read(am-1) Cm-1 vam-1 rd(bi) msg1 wrt(bj,vj) write(am,v’am) Cm Adv’sview= clientscomm+dataaccesses vam Honest

  7. Correctness: Always return/updatethecorrectvalue Obliviousness: Only know the # of rounds of clients’ logical accesses after observing the communication/actualaccesses Efficiency: Smallinter-client&client-servercommunication

  8. TheonlyOPRAM[BCP’16] w(log3N)client-server commoverhead BestORAM O(log2N)overhead Result1:AnOPRAMwith(amortized)client-servercommoverheadO(log2N). Weclosethegap! ORAM&OPRAM Equivalent? Result2:EveryORAMcanbetransformedintoanOPRAMwithO(logN)factorincreaseincomplexity Generictransformation

  9. The challenge Inthe parallelsetting: Multipleclientsmightneed to access thesamestoragecellsimultaneously Howtocoordinateobliviously? [BCP’16]: Expensivecoordinationprotocol Oursolution: Partitioning:Eachclient managesdisjointpartition

  10. Roadmap Startingpoint ReviewofPath-ORAM EfficientOPRAM: thepartitioningtechnique GenericconstructionfromORAMtoOPRAM

  11. Path-ORAM[Stefanov et. al. 13] Bucket: Z=O(1) blocks B randomL N=#oflogicalblocks Server Canbemovedto theserver with recursion Stash Client

  12. Path-ORAM[Stefanov et. al. 13] Shouldonlyaccessa randompathforeach logicalaccess Stash AccessB B manyblocks Moveto theleaf? Client L’ randomL N

  13. Path-ORAM[Stefanov et. al. 13] OnlyFlush pathL Stash small Re-encrypt&puttothe lowestpossibleposition Fetcheveryblock onpathL B Client manyblocks L’ randomL N

  14. TreeORAM TreeOPRAM Simplifyingassumptions Allclientswanttoaccessadistinctlogical address Allclientssharethe positionmaplocally

  15. FirstAttempt M clients retrieveandflushmpaths independently, w/o coordination Paths always overlap!! Our solution Partitioning C2 C3 C1

  16. Partitioning Simulateour firstattempt: Retrieve&flushmpaths Stash BlocksfromStash& upperlogmlevelsgotostashi ifitspathendsinsubtreei Clientiresponsibleforall blockswhosepathendsin subtreei logm Subtree1 Subtree3 Subtree2 Subtree4 Stash4 Stash1 Stash3 Stash2

  17. Howtoretrievevalues? EachclientjisresponsibleforretrievingtherequestedblocksbytraversingsubtreeSTj Clientisendstheblock-pathrequesttoclientj IfBi’spathendsinsubtreej Therequestedblocks’pathsinsubtreejformarandomsubtreeSTj Security, so far:Addresses are all distinct Path-assignments are independentand random Subtree1 Subtree3 Subtree2 Subtree4 ST1 ST2 ST3 ST4 B3? B2? B4? B1? Stash4 Stash1 Stash3 Stash2

  18. How to re-inserttheblockstothenewpaths? L’3 L’2 B2 B3 L’4 B1 B4 L’1 Oblivious Routing[BCP’16] Hides L’iwhile obliviously sending Bi to corresponding client Sending back the block into the subtreethat the new pathbelongs to Efficient! O(logmlogN) Leaks information: Bi’snew assignment Subtree 1 Subtree 2 Subtree 3 Subtree 4

  19. SubtreeFlushing Clientjflushes blocksinsubtreeSTj DistinctiontoPathORAM Optimizethepositionswithintheentiresub-treeinsteadofan individualpath Overflowanalysis Blocksareplacedatevenlowerposition Stashsizeisbounded Tricky!

  20. Removingrestrictions Multipleclientsaccessthesame(logical)block? Theaccesspatternscoincide Electleader+randomfakereads [BCP’16] MovethepositionmaptotheserverbyRecursion See our paper!

  21. Generic OPRAM ? AnewORAM AnewOPRAM Genericconstruction OPRAMisnotmuchharder! Partitioning

  22. Subtreepartitioning Subtree 1 Subtree 2 Subtree 3 Subtree 4 Stash4 Stash1 Stash3 Stash2

  23. Partitioning P2 P3 P1 P4 Queueing process& cuckoo hashing enter the game Replace the subtree partitions with ORAMs Server O3 O4 O2 O1 ORAM4 ORAM2 ORAM3 ORAM1 Stash Stash Stash Stash

  24. Wrap-up Result1:AnOPRAMwith(amortized)client-servercommoverheadO(log2N). Partitioning Result2:ORAMOPRAM

  25. Thank you! https://eprint.iacr.org/2015/1053.pdf

More Related